[Letux-kernel] letux-4.7-rc4

[H. Nikolaus Schaller]

Hi,

> Am 20.06.2016 um 21:53 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> 
>> Am 20.06.2016 um 21:11 schrieb Belisko Marek <marek.belisko at gmail.com>:
>> 
>> Hi,
>> 
>> On Mon, Jun 20, 2016 at 5:50 PM, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>>> have merged / rebased / compiled / pushed.
>>> 
>>> first test results on GTA04:
>>> 
>>> NAND is working again :)
>>> 
>>> May need to reformat ubifs but if formatted it works fine.
>>> 
>>> Compare:
>>> 
>>>       http://projects.goldelico.com/p/gta04-rootfs/source/tree/master/config/root/flash-nand#L244
>>> 
>>> GTA04A5 OneNAND:
>>> 
>>> here we still have a bug in the gpmc config. It says "invalid configuration!":
>>> 
>>> root at letux:~# dmesg|fgrep gpmc
>>> [    0.709472] driver_register 'omap-gpmc'
>>> [    0.897430] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
>>> [    0.897766] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
>>> [    0.901153] gpmc_cs_program_settings: invalid configuration!
>>> [    0.901184] omap-gpmc 6e000000.gpmc: failed to probe DT children
>>> [    0.908325] omap-gpmc: probe of 6e000000.gpmc failed with error -22
>>> root at letux:~#
>>> 
>>>       http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap3-gta04a5.dts;h=5a27ab353b8ebb2ed336412af11285a318102833;hb=d0ed6fc898dc7575ec4683f6867402efff0d176b#l65
>>> 
>>> It looks to be the same as for N950 which was told me a while ago to be the right one:
>>> 
>>>       http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n950-n9.dtsi#L179
>>> 
>>> The error hints at: http://lxr.free-electrons.com/source/drivers/memory/omap-gpmc.c#L1602
>>> 
>>> but what does
>>> 
>>>       /* Address-data multiplexing not supported for NAND devices */
>>>       if (p->device_nand && p->mux_add_data)
>>> 
>>> mean? And how do we (not) run into that condition being true through our DT bits?
>> Probably this patch should fix it:
>> diff --git a/arch/arm/boot/dts/omap3-gta04a5.dts
>> b/arch/arm/boot/dts/omap3-gta04a5.dts
>> index 5a27ab3..a14991e 100644
>> --- a/arch/arm/boot/dts/omap3-gta04a5.dts
>> +++ b/arch/arm/boot/dts/omap3-gta04a5.dts
>> @@ -69,7 +69,8 @@
>> 
>>       /* FIXME: special pinmuxrequired? compare omap3-n900.dts */
>> 
>> -       nand at 0,0 { /* reuse the nand node instead of creating a new
>> onenand node */
>> +       onenand at 0,0 { /* reuse the nand node instead of creating a new
>> onenand node */
> 
> ^^^ that one breaks "inheriting" the partition scheme because it creates
> another child node instead of switching it from standard-nand to onenand.
> 
> And IMHO the node name should have no functional meaning, i.e. could
> be anything.
> 
> Well, this is probably not upstreamable), but it is easier for initial testing
> to keep partition schemes in sync. They will likelyrecommend to #include
> the partition scheme
> 
>> +               compatible = "";
> 
> ^^^ but this might be what we are missing!
> 
> I think we could also /delete-property/ compatible;
> 
>>               #address-cells = <1>;
>>               #size-cells = <1>;
>>               reg = <0 0 0x20000>;    /* CS0, offset 0, IO size 128K */
>> 
>>> 
>>> Anyone having a little time to investigate by code inspection?
>> the point is that we set compatible entry to compatible =
>> "ti,omap2-nand";
> 
> Ah, that might set gpmc_s.device_nand = true. Yes, sounds reasonable.
> 
>> in omap3-gta04.dtsi but when it's set then in
>> gpmc_probe_generic_child is set to: gpmc_s.device_nand = true; and we
>> also have p_mux_add_data set to 2 in DT (same as in n900). Can you
>> please try if my findings are correct? Many thanks.
> 
> Many thanks for these ideas. Will try asap.

Short report:
did work a little better with the compatible = "" but still did not correctly "probe children".

Now I have done the /delete-node/ and spent a fresh 'onenand' node. Now, the gpmc initializes well:

[    0.709960] driver_register 'omap-gpmc'
[    0.897216] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    0.897552] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
root at letux:~#

But still no nand:

root at letux:~# dmesg|fgrep nand 
[    0.000000] Kernel command line: console=ttyO2,115200n8 mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p2 rw rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait twl4030_charger.allow_usb=1 musb_hdrc.preserve_vbus=1 log_buf_len=8M ignore_loglevel earlyprintk
[    3.703521] driver_register 'omap2-nand'
[    3.717620] driver_register 'omap2-onenand'
[    3.722473] omap2_onenand_probe
[    3.727416] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base f0900000, freq 83 MHz
[    3.738922] onenand_chip_probe
[    3.755859] onenand_wait: timeout4! ctrl=0x0000 intr=0x0000
root at letux:~# 

This could now be hardware related (or pinmux like N900).

So I will push the "fix" so that we can base further work on top of it.

BR,
Nikolaus