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. > >> >>>>>>> '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 > >> >>> 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. > >> >>>>>>> Once all those little problems fixed manually, u-boot loads kernel and >>>>>>> initrd, but I get: >>>>>>> ******************************************************************************** >>>>>>> Starting kernel ... >>>>>>> >>>>>>> undefined instruction >>>>>>> pc : [<8000012c>] lr : [<00000090>] >>>>>> Which instruction is that? Just run objdump -d on the vmlinux file and >>>>>> check for the instruction at 0x12c Maybe the one before. >>>>> objdump -d linux.vmx >>>>> objdump: linux.vmx: File format not recognized >>>> You need to run objdump on the vmlinux file. linux.vmx is a uImage. >>> I have: >>> c000812c <__turn_mmu_on_loc>: >>> c000812c: c000812c .word 0xc000812c >>> c0008130: c05558f8 .word 0xc05558f8 >>> c0008134: c0555918 .word 0xc0555918 >> Hrm. That is 0x812c. There is nothing earlier? In fact, looking at the lr >> address, we might be in self-extract code here... > > I uploaded my objdump here: > http://guillaume.gardet.free.fr/openSUSE/objdump.txt > > Please download it, so that you can have a look at it. Hrm. Maybe the kernel gets relocated down? I have no idea. Either way, __turn_mmu_on_loc only contains addresses to 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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
