[Letux-kernel] gta04 - reading nand from u-boot

H. Nikolaus Schaller hns at goldelico.com
Mon Jul 23 18:09:03 CEST 2018


Hi Josua,

> Am 23.07.2018 um 17:20 schrieb Josua Mayer <josua.mayer at jm0.eu>:
> 
> Hi Nikolaus,
> 
> see inline ...
> 
> Am 21.07.2018 um 15:23 schrieb H. Nikolaus Schaller:
>> Hi Josua,
>> 
>>> Am 21.07.2018 um 14:18 schrieb Josua Mayer <josua.mayer at jm0.eu>:
>>> 
>>> Hi Nikolaus,
>>> 
>>> Am 21.07.2018 um 13:56 schrieb H. Nikolaus Schaller:
>>>> Hi Josua,
>>>> I have now applied your U-Boot patches and have not found any problems.
>>> great!
>>>> Then I tried to read the u-boot environment from Linux, but it fails:
>>>> 
>>>> root at letux:~# fw_printenv 
>>> If u-boot uses 1-bit ham1 ecc scheme to save environment, and if linux
>>> uses a different, namely bch8,
>>> this won't work will it?
>>> So I checked what the letux-4.17.3 dts does:
>>> &gpmc {
>>>    nand at 0,0 {
>>>        ti,nand-ecc-opt = "bch8";
>>>    };
>>> };
>>> and then near the bottom:
>>> &gpmc {
>>>    nand at 0,0 {
>>>        ti,nand-ecc-opt = "ham1"; /* stay compatible with our old u-boot
>>> (does not support bch8) */
>>>    };
>>> };
>>> 
>>> So it should work. I don't think we want to upstream setting this to
>>> ham1 though.
>> The omap3-beagle.dts also has it as default which is IMHO enough argument...
> Yes. And it was quietly changed in u-boot to bch8!
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=4b37928d3577e1b540b12d709e9b551fee3ccbd6;hp=3ff0d8018105614a466b10265e6dff99de958135
> +#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> Which means do bch8 calculations in hardware and correction in software.

Interesting. So if someone uses upstream u-boot with upstream kernel they
are not compatible...

Maybe u-boot patches are not well reviewed and for kernel changes
this all might have been split up into ca. 5 separate patches...

>> 
>>> I believe we can eventually get our u-boot to use bch8!
>>> (I know SPL has to be written using ham1 for the Boot ROM to understand it)
>> Ok, if we switch U-boot then we can change it in the bottom setting and
>> try to upstream.
>> 
>>> BUT I noticed duplication!
>>> The first nand section defines all 4 partitions, and then the second
>>> section defines
>>> kernel at 280000 <0x280000 0x600000>
>>> filesystem at a80000 <0x880000 0>
>>> These do *not* match what has been declared earlier!
>> Ok! Yes. This fully explains my finding of the 6 partitions for NAND
>> vs. 5 for OneNAND. For OneNAND we /delete/ the partition scheme and build
>> a new one. But for standard NAND we have a redefinition with different node
>> name and no label... Hence the DTS compiler does not fold them to a single
>> DT node but keeps two.
>> 
>> In summary, the first section (upstream) seems to be correct and the second
>> section is wrong. We should keep the ham1 setting, but not the partition
>> redefinition. Or better we upstream the ham1 change.
>> 
>> The reason is the mess how our omap3-gta04.dtsi is set up.
>> 
>> The main problem is that we want something that can be merged on top
>> of mainstream. But not everything is mature. And not everything is
>> independent of each other. For example the git merge algorithm may trigger on
>> the same }; for two different commits and we unexpectedly get a merge
>> conflict :(
>> 
>> Therefore, quite some long time ago, I did split the omap3-gta04.dtsi in
>> an upstream section and a second one which contains the letux extensions
>> and uses DTS redefinitions to extend things.
>> 
>> Unfortunately it is still difficult to move things from the extensions
>> to the upstream part. This means careful code edits on two branches
>> so that they still can be merged, have the same result after compile
>> although the source is different... So we can't even diff to check.
>> 
>> And due to the quite fragile patch sequence it is also difficult to
>> reorder some patches without introducing regressions by manually fixing
>> merge conflicts.
>> 
>> Anyways, we should address this and I have set this gta04.dtsi cleanup
>> on higher priority on my ToDo list.
>> 
>> BR,
>> Nikolaus
>> 
>> 
>>>> Warning: Bad CRC, using default environment
>>>> bootargs=
>>>> bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
>>>> bootdelay=3
>>>> baudrate=115200
>>>> stdin=serial,cros-ec-keyb
>>>> stdout=serial,lcd
>>>> stderr=serial,lcd
>>>> root at letux:~# 
>>>> 
>>>> Config uses the mtd2 partition and defines the correct size.
>>>> 
>>>> root at letux:~# more /etc/fw_env.config
>>>> # Configuration file for fw_(printenv/setenv) utility.
>>>> # Up to two entries are valid, in this case the redundant
>>>> # environment sector is assumed present.
>>>> # MTD device name       Device offset   Env. size       Flash sector size
>>>> /dev/mtd2               0x0000          0x40000         0x40000
>>>> root at letux:~# 
>>>> 
>>>> And the kernel knows about the correct location:
>>>> 
>>>> [    2.506378] 5 ofpart partitions found on MTD device 4000000.onenand
>>>> [    2.512908] Creating 5 MTD partitions on "4000000.onenand":
>>>> [    2.518768] 0x000000000000-0x000000080000 : "X-Loader"
>>>> [    2.525787] 0x000000080000-0x000000240000 : "U-Boot"
>>>> [    2.532745] 0x000000240000-0x000000280000 : "U-Boot Env"
>>>> [    2.540161] 0x000000280000-0x000000880000 : "Kernel"
>>>> [    2.547332] 0x000000880000-0x000020000000 : "File System"
>>>> 
>>>> Note: this is all on GTA04A5 wth OneNAND. And kernel:
>>>> 
>>>> root at letux:~# uname -a
>>>> Linux letux 4.16.17-letux+ #2514 SMP PREEMPT Tue Jun 26 00:37:53 CEST 2018 armv7l GNU/Linux
>>>> root at letux:~# 
>>>> 
>>>> It looks as if reading NAND is completely broken - at least with letux-4.16.17.
>>>> 
>>>> root at letux:~# xxd /dev/mtd2 | head -8
>>>> 0000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> 0000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
>>>> root at letux:~# 
>>>> 
>>>> Next, I plan to do the same tests on GTA04A4 with NAND and other kernels.
>>>> 
>>>> BR,
>>>> Nikolaus
>>>> 
>>>> _______________________________________________
>>>> http://projects.goldelico.com/p/gta04-kernel/
>>>> Letux-kernel mailing list
>>>> Letux-kernel at openphoenux.org
>>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>>> 
>>> _______________________________________________
>>> http://projects.goldelico.com/p/gta04-kernel/
>>> Letux-kernel mailing list
>>> Letux-kernel at openphoenux.org
>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> Letux-kernel at openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel



More information about the Letux-kernel mailing list