2016-03-13 18:20 GMT+03:00 Alexander Graf <[email protected]>: > > > On 13.03.16 16:17, Matwey V. Kornilov wrote: >> 2016-03-13 18:11 GMT+03:00 Alexander Graf <[email protected]>: >>> >>> >>> On 13.03.16 16:05, Matwey V. Kornilov wrote: >>>> 2016-03-13 18:03 GMT+03:00 Matwey V. Kornilov <[email protected]>: >>>>> 2016-03-13 16:44 GMT+03:00 Alexander Graf <[email protected]>: >>>>>> >>>>>> >>>>>> On 13.03.16 14:39, Matwey V. Kornilov wrote: >>>>>>> 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? >>>>>> >>>>>> It usually doesn't. To limit the problem scope, please also make sure >>>>>> you don't load the initrd. >>>>>> >>>>> >>>>> That works, but it ends up with not found init. >>>>> >>>>> [ 1.700159] devtmpfs: error mounting -2 >>>>> [ 1.706736] Freeing unused kernel memory: 1320K (c1034000 - c117e000) >>>>> [ 1.713459] Kernel panic - not syncing: No working init found. Try >>>>> passing init= option to kernel. See Linux Documentation/init.txt for >>>>> guidance. >>>>> [ 1.726667] CPU: 0 PID: 1 Comm: swapper/0 Not tainted >>>>> 4.5.0-rc7-1.g924f2b7-default #1 >>>>> [ 1.734535] Hardware name: Generic AM33XX (Flattened Device Tree) >>>>> [ 1.740722] [<c0227b90>] (unwind_backtrace) from [<c0220c50>] >>>>> (show_stack+0x20/0x28) >>>>> [ 1.748530] [<c0220c50>] (show_stack) from [<c0586f3c>] >>>>> (dump_stack+0x98/0xac) >>>>> [ 1.755816] [<c0586f3c>] (dump_stack) from [<c037f440>] >>>>> (panic+0xec/0x270) >>>>> [ 1.762745] [<c037f440>] (panic) from [<c0b20a90>] >>>>> (__irq_alloc_descs+0x0/0x1d8) >>>>> [ 1.770205] Rebooting in 90 seconds.. >>>>> >>>>> However, md.b 0x812bfc30 shows zeroes. It would be great to learn how >>>>> to properly use it. >>>>> >>>>>> If you load the kernel and fdt to the same addresses that grub put them, >>>>>> set bootargs to the cmdline in grub and do bootz, does the kernel come >>>>>> up? >>>>> >>>>> It says the following: >>>>> http://paste.opensuse.org/32160189 >>>>> >>>>> But seems, bootz relocates initrd and fdt. >>>>> >>>> >>>> Now it is clean, that it is run out of free RAM probably: >>>> >>>> [ 0.637547] Unpacking initramfs... >>>> [ 3.655300] Initramfs unpacking failed: write error >>>> [ 3.740465] Freeing initrd memory: 46032K (cc251000 - cef45000) >>>> >>>> But the question, why output doesn't work with grub. >>> >> >> I found that bootz works when rootfstype=tmpfs (or no rootfstype, >> because it is default) >> and when rootfstype=ramfs there is also no any output. >> >>> With grub you're using the advanced command line that sets >>> rootfsflags=size=100%, so it can theoretically occupy too much ram. >>> >>> With grub, try and remove all command line arguments except for console= >>> (like you have it in pastebin). Does that get you to the same boot log? >> >> Yes, it seems that rootffstype=ramfs breaks the things! > > Well, ramfs is slightly different than rootfsflags=size=100%, but it's > great to see that we're getting closer. > > So how much ram does your device have? Also, can you try > rootfsflags=size=95% instead to see whether that at least gives us output? >
Where should It come from? I don't have any rootfsflags in my grub2. Unfortunately, my board has only 256MB of RAM, so last time I need to use rootfstype=ramfs to cope with huge initrd and it worked somehow. > > 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]
