On 07.11.2013, at 15:45, Guillaume Gardet <guillaume.gar...@free.fr> wrote:
> > 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. Works for me, if this is truly universal in upstream u-boot and not just an OMAP specific thing. Alex > > >> >>>>> 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
