2016-03-13 16:21 GMT+03:00 Alexander Graf <[email protected]>: > > > On 13.03.16 14:13, Matwey V. Kornilov wrote: >> 2016-03-13 15:09 GMT+03:00 Alexander Graf <[email protected]>: >>> >>> >>> On 13.03.16 12:30, Alexander Graf wrote: >>>> >>>> >>>>> Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov >>>>> <[email protected]>: >>>>> >>>>> Hello, >>>>> >>>>> I am trying to boot on Phytec Wega board (TI AM33xx based) with >>>>> u-boot+EFI+grub2 and just see >>>>> >>>>> Booting `openSUSE-Tumbleweed-ARM-JeOS-wega [ VMX ]' >>>>> >>>>> Loading linux.vmx... >>>>> Loading initrd.vmx... >>>>> >>>>> and then board is rebooted after some time (I think, by watchdog). >>>>> I am sure that kernel console parameter is correct. >>>>> >>>>> Before EFI was introduced to u-boot, I had booted this board >>>>> successfully. Is there a simple way to somehow understand what is going >>>>> wrong here? >>>> >>>> My guess is that the device tree doesn't get loaded. Do you see a warning >>>> about it on serial? Try to add a line in grub2 to manually select the >>>> device tree: >>>> >>>> Press e (edit current entry) >>>> at the end, add a new line saying "devicetree /boot/dtb/foo.dtb" >>>> Press ctrl-x (or f10) to boot >>>> >>>> If that makes it work, the default U-Boot environment does not set the >>>> "fdtfile" variable. Add it to the env (in your board header) and you >>>> should be set :). >>> >>> If that still doesn't help, try to add an earlycon parameter to the >>> kernel command line. If that still doesn't show you anything at all, you >>> can grab the kernel log_buf using md.b from the u-boot command line >>> after reset, but let's see whether you get to the kernel log / fix the >>> issue without that first :). >> >> in System.map I found the following: >> >> c12bfc30 b __log_buf >> >> I am not sure how to properly map this address when I know that kernel >> is loaded at 0x80008000 > > That means that the address should be > > 0x812bfc30 > > Try to md.b from there after reset and you should spot the kernel output > log.
When I attach panic=-1 to kernel, the pause is about 15 seconds (instead of 60 earlier), so I think that this parameter is taken into account. However, in any case the buffer log_buf is filled with zeroes according to md.b. Maybe u-boot resets the memory on start? > >> >>> >>> If you want to debug grub efi specifics, you can do >>> >>> Press e (edit current entry) >>> at the top, add a new line saying "set debug=all" >>> Pres ctrl-x (or f10) to boot >>> >>> That should give you all the glorious details from grub2 on what exactly >>> it's doing. >> >> At the end of long output I see the following: >> >> ??, er/arm/linux.c:238: atag: 0x88000000, 90, edfe0dd0, ? >> loader/arm/linux.c:246: Kernel at: 0x80008000 >> loader/arm/linux.c:184: linux_args: 'BOOT_IMAGE=/boot/linux.vmx >> plymouth.enable=0 console=ttyS0,115200n8 rootfstype=ramfs showopts' >> loader/arm/linux.c:199: Initrd @ 0x8800b000-0x8acfe33c >> loader/arm/linux.c:215: FDT updated for Linux boot >> loader/arm/linux.c:255: FDT @ 0x0x88000000 >> loader/arm/linux.c:267: Jumping to Linux... >> >> It seems that grub starts the kernel. I also checked that fdt fits >> into 0xb000 bytes. >> >> earlycon=uart8250,0x44e09000,115200n8 >> >> mmio mode prints the single one character '[' >> mmio32 mode prints some garbage >> mmio32be prints one space character. > > Phew. Well, at least it means that Linux is coming up... and doesn't > like something. > > > Alex -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://[email protected] -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
