Le 07/11/2013 15:12, Alexander Graf a écrit :
> On 07.11.2013, at 14:37, Guillaume Gardet <guillaume.gar...@free.fr> wrote:
>
>> Le 07/11/2013 14:19, Alexander Graf a écrit :
>>> On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gar...@free.fr> wrote:
>>>
>>>> Le 07/11/2013 14:04, Alexander Graf a écrit :
>>>>> On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gar...@free.fr>
>>>>> wrote:
>>>>>
>>>>>> Le 07/11/2013 13:34, Alexander Graf a écrit :
>>>>>>> On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gar...@free.fr>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Le 07/11/2013 11:17, Alexander Graf a écrit :
>>>>>>>>> On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gar...@free.fr>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> here are some tests results of 13.1 images. Results are pretty bad
>>>>>>>>>> ATM. :(
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * Beagleboard xM rev B :
>>>>>>>>>> - Image fails to boot with the following error message:
>>>>>>>>>> ********************************************************************************
>>>>>>>>>> [ 8.109588] Freeing unused kernel memory: 532K (c07e5000 -
>>>>>>>>>> c086a000)
>>>>>>>>>> setterm: cannot (un)set powersave mode: Inappropriate ioctl for
>>>>>>>>>> device
>>>>>>>>>> /usr/sbin/klogconsole
>>>>>>>>>> Thu Nov 7 00:00:00 UTC 2013
>>>>>>>>>> [ 13.670684] ehci-omap ehci-omap.0: Can't get PHY device for port
>>>>>>>>>> 1: -6
>>>>>>>>>> [ 15.271728] hub 1-0:1.0: Cannot enable port 1. Maybe the USB
>>>>>>>>>> cable is bad?
>>>>>>>>>> [437097081.923981] Including oem partition info file
>>>>>>>>>> [437097082.043030] Searching for boot device...
>>>>>>>>>> [ 16.471771] hub 1-0:1.0: Cannot enable port 1. Maybe the USB
>>>>>>>>>> cable is bad?
>>>>>>>>>> [ 17.671752] hub 1-0:1.0: Cannot enable port 1. Maybe the USB
>>>>>>>>>> cable is bad?
>>>>>>>>>> [ 18.925598] hub 1-0:1.0: Cannot enable port 1. Maybe the USB
>>>>>>>>>> cable is bad?
>>>>>>>>>> [ 18.933227] hub 1-0:1.0: unable to enumerate USB device on port 1
>>>>>>>>>> [437097110.607544] Failed to find boot device !
>>>>>>>>>> [437097110.639527] rebootException: reboot in 120 sec...
>>>>>>>>>> ********************************************************************************
>>>>>>>>>>
>>>>>>>>>> The USB problem seems to be known:
>>>>>>>>>> http://www.spinics.net/lists/linux-omap/msg90670.html
>>>>>>>>>> Is boot problem related? I do not know.
>>>>>>>>>>
>>>>>>>>>> D6 and D7 lights (related to MMC) are turned OFF when kernel start
>>>>>>>>>> whereas it was ON with u-boot.
>>>>>>>>>> So, MMC seems to be not working at all. It seems that kernel modules
>>>>>>>>>> (at least omap mmc modules) from initrd are not loaded. Very strange.
>>>>>>>>> If you boot with kiwidebug=1 you should be able to get a shell and
>>>>>>>>> check whether the modules are loaded or not.
>>>>>>>> Indeed, mmc modules are not loaded. But loading them manually does not
>>>>>>>> help to get mmc device to appear. I think we are missing other drivers
>>>>>>>> (maybe GPIO).
>>>>>>> Could you quickly compare the defconfig for omap4 and the one we have
>>>>>>> to see what we're missing?
>>>>>> I think it is missing from initrd only, not rootfs, since initrd has
>>>>>> only some of kernel modules. I will try to add some kernel modules to
>>>>>> our initrd and see if it helps.
>>>>>>
>>>>>>>>>> * Pandaboard rev A3 :
>>>>>>>>>> - Image hangs early with the following message: (Tested with 2 SD
>>>>>>>>>> cards).
>>>>>>>>>> ********************************************************************************
>>>>>>>>>> U-Boot SPL 2013.04 (Oct 21 2013 - 22:37:21)
>>>>>>>>>> OMAP4430 ES2.2
>>>>>>>>>> OMAP SD/MMC: 0
>>>>>>>>>> ********************************************************************************
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is there anyone who could test those images on their baords,
>>>>>>>>>> especially pandaboard?
>>>>>>>>> Andrew reported the same issue. Could you please try with 12.3's SPL
>>>>>>>>> (MLO) and/or u-boot.bin to boil down which component is at fault here?
>>>>>>>> I managed to get u-boot working using old MLO (and copying u-boot.bin
>>>>>>>> from boot/ folder to the root of the boot partition).
>>>>>>> Does only replacing one of the two help already?
>>>>>> Yes, replacing MLO only does help. I think our ext2 patch for MLO may be
>>>>>> broken for 13.1 u-boot. Maybe we could bump u-boot version at the same
>>>>>> time we check MLO patch?
>>>>> Hrm. We're at rc2 here. Maybe it is a good idea to bump the version after
>>>>> all. Sigh.
>>>> Could you do it, please? I will not have time for that ATM. :(
>>> I can try, but if I don't get around until Saturday it won't happen for at
>>> least another week.
>> Ok. Thanks.
>>
>>
>>>>>>>> But now, I get the following error in u-boot:
>>>>>>>> ********************************************************************************
>>>>>>>> U-Boot SPL 2013.04-rc2 (Apr 17 2013 - 07:35:53)
>>>>>>>> OMAP4430 ES2.2
>>>>>>>> OMAP SD/MMC: 0
>>>>>>>>
>>>>>>>>
>>>>>>>> U-Boot 2013.04 (Oct 21 2013 - 22:37:21)
>>>>>>>>
>>>>>>>> CPU : OMAP4430 ES2.2
>>>>>>>> Board: OMAP4 Panda
>>>>>>>> I2C: ready
>>>>>>>> DRAM: 1 GiB
>>>>>>>> MMC: OMAP SD/MMC: 0
>>>>>>>> Using default environment
>>>>>>>>
>>>>>>>> In: serial
>>>>>>>> Out: serial
>>>>>>>> Err: serial
>>>>>>>> Net: No ethernet found.
>>>>>>>> Hit any key to stop autoboot: 0
>>>>>>>> mmc0 is current device
>>>>>>>> SD/MMC found on device 0
>>>>>>>> 1562 bytes read in 12 ms (127 KiB/s)
>>>>>>>> Running bootscript from mmc0 ...
>>>>>>>> ## Executing script at 82000000
>>>>>>>> kerneladdr=0x80000000
>>>>>>>> ramdiskaddr=0x82000000
>>>>>>>> itest - return true/false on integer compare
>>>>>>>>
>>>>>>>> Usage:
>>>>>>>> itest [.b, .w, .l, .s] [*]value1 <op> [*]value2
>>>>>>>> mmc0 is current device
>>>>>>>> ** File not found boot/linux.vmx **
>>>>>>>> 4417952 bytes read in 241 ms (17.5 MiB/s)
>>>>>>>> ** File not found /boot/omap4-panda-es.dtb **
>>>>>>>> Booting from mmc0 ...
>>>>>>>> ERROR: Did not find a cmdline Flattened Device Tree
>>>>>>>> Could not find a valid device tree
>>>>>>>> ********************************************************************************
>>>>>>>> the problem is that bootpart has a bad value.
>>>>>>>> 'echo $bootpart' returns '0:2' instead of 0.
>>>>>>>> This is the default value in u-boot for panda but should be
>>>>>>>> overwritten by our script. Why not?
>>>>>> I found the problem. We must reset $bootpart otherwise value is not
>>>>>> updated.
>>>>> Or use a different variable name? ;)
>>>> bootpart is the right name I think, we just need to update it after
>>>> loading our script.
>>> IIRC I set everything up in a way that you can always override any variable
>>> from nvram, if you have persistent nvram.
>> At u-boot load, u-boot try to get a working environment from flash, if it
>> fails it redefines all vars. Moreover, in our script, we do not call saveenv
>> to save datas. So, it should be fine to reset bootpart before updating it.
>> No? Maybe I miss something, since I am not familiar with nvram.
> Ok, forget what I said.
>
> So you're saying that the for loop does not update $bootpart when it already
> contains a value? That sounds pretty broken. Yes, just reset it before the
> for loop then.
Yes, this is what I said. (Tested on pandaboard). Maybe it is not broken but a
feature? ;)
>
>>>>>>>> 'itest' error can easily be fixed by setting usefdt and loadfdt to 0
>>>>>>>> by default. (I could submit a patch for this one later).
>>>>>>> i thought we do an itest 0$var = 0 or so exactly to not run into this?
>>>>>> Yes. But it seems there is still a problem with one of the itest.
>>>>>> Defaulting to 0 is not a big deal.
>>>>> ok :)
>>>> I found the problem. U-boot already defines loadfdt:
>>>> echo $loadfdt
>>>> load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
>>>>
>>>> Do we want to change our var name our do we overwrite loadfdt?
>>> We want to change the var name.
>> Ok. load_fdt or something else?
> Let's make it obvious:
>
> should_load_fdt
> should_use_fdt
Ok.
One more thing. Upstream uses $fdtfile and we are using $fdt. Should we update
to $fdtfile? I think so, since beagle and panda have a special function
(findfdt) which set $fdtfile to the right file for a given board
version/revision.
>
>>>> I think overwriting a u-boot var is not a good idea. Moreover, why do we
>>>> have 2 vars: usefdt and loadfdt? if we want to use DT, we must load it.
>>>> And we do not need to load it if we do not use it. Isn't it?
>>>> I would like to remove loadfdt and only use usefdt. Are you ok?
>>> Not at all.
>>>
>>> On highbank and midway we already get a working device tree preloaded by
>>> firmware. There we do not have to load an fdt, but only use it.
>> Good to know. Thanks for info.
>> In melea1000/cubieboard, we load DT but we do not use it (in bootz cmdline).
>> Does the kernel read a specific addr for DT or is it a bug?
> I'd say it's a bug. But I know very little about the way Allwinner SoCs work.
Well, it seems it is not very a DT but they call this a sys_config file. So
let's it like this.
> Hrm. Maybe the kernel gets relocated down? I have no idea.
> functions it wants to call. We should never reach that as instructions that
> get executed.
>
> I'm also slightly confused why this happens. This is the same kernel as the
> beagle one, right? So there really should be no major difference between the
> two kernel execution paths.
Yes, this is very strange. Maybe a bad loading addr? Or an overlap with initrd?
I do not know.
Guillaume
>
>
> Alex
>
>
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
