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

[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...

> 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