[Letux-kernel] letux-4.7-rc4

Tue Jun 21 10:14:48 CEST 2016

> Am 21.06.2016 um 10:07 schrieb Belisko Marek <marek.belisko at gmail.com>:
> 
> Hi,
> 
> On Tue, Jun 21, 2016 at 10:02 AM, H. Nikolaus Schaller
> <hns at goldelico.com> wrote:
>> 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
> ^^^^ there is 2 times console but this shouldn't harm

Indeed. That is from having too much old stuff in here (to be able to boot old 2.6.32 from the same command line)...

>> [    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).
> Yes could be some pinmuxing problem but usally gpmc is muxed properly
> to be able to read data if you boot from nand.

I did boot from SD since we have no working OneNAND driver in our
old U-Boot yet. So I can't flash it with a boot loader. GPMC *might* be
initialized by BootROM...

Anyways we have some progress here :)

BR,
Nikolaus