Le 07/11/2013 15:46, Alexander Graf a écrit : > 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.
In upstream u-boot, you have findfdt function for omap3, 4, 5 and am335x. But $fdtfile is used for all boards using DT. Please accept SR #206130. Guillaume > > > 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
