[Letux-kernel] letux-4.7-rc4

Belisko Marek marek.belisko at gmail.com
Tue Jun 21 10:07:20 CEST 2016


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
> [    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.
>
> So I will push the "fix" so that we can base further work on top of it.
>
> 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

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


More information about the Letux-kernel mailing list