[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