[Letux-kernel] letux-4.7-rc4

H. Nikolaus Schaller hns at goldelico.com
Mon Jun 20 21:53:38 CEST 2016


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.

BR,
Nikolaus



More information about the Letux-kernel mailing list