Mailinglist Archive: opensuse-arm (170 mails)

< Previous Next >
Re: [opensuse-arm] u-boot+EFI: how to debug grub2?

On 13.03.16 16:17, Matwey V. Kornilov wrote:
2016-03-13 18:11 GMT+03:00 Alexander Graf <agraf@xxxxxxx>:

On 13.03.16 16:05, Matwey V. Kornilov wrote:
2016-03-13 18:03 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@xxxxxxxxx>:
2016-03-13 16:44 GMT+03:00 Alexander Graf <agraf@xxxxxxx>:

On 13.03.16 14:39, Matwey V. Kornilov wrote:
2016-03-13 16:21 GMT+03:00 Alexander Graf <agraf@xxxxxxx>:

On 13.03.16 14:13, Matwey V. Kornilov wrote:
2016-03-13 15:09 GMT+03:00 Alexander Graf <agraf@xxxxxxx>:

On 13.03.16 12:30, Alexander Graf wrote:

Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov


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
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,
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 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


Try to md.b from there after reset and you should spot the kernel output

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
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
[ 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>]
[ 1.748530] [<c0220c50>] (show_stack) from [<c0586f3c>]
[ 1.755816] [<c0586f3c>] (dump_stack) from [<c037f440>]
[ 1.762745] [<c037f440>] (panic) from [<c0b20a90>]
[ 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:

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?

To unsubscribe, e-mail: opensuse-arm+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-arm+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups