13.03.2016 14:30, Alexander Graf пишет:

...

Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov :

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 :).

This doesn't help. There are also no any warnings, except gfxterm related. Environment size: 3985/131068 bytes => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 37937 bytes read in 71 ms (521.5 KiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 461312 bytes read in 41 ms (10.7 MiB/s) ## Starting EFI application at 0x82000000 ... Scanning disks on usb... Scanning disks on mmc... Card did not respond to voltage select! MMC Device 2 not found MMC Device 3 not found Found 1 disks Welcome to GRUB! error: terminal `gfxterm' isn't found. error: no suitable video mode found. error: can't find command `terminal'. error: file `/boot/grub2/themes/openSUSE/ascii.pf2' not found. GNU GRUB version 2.02~beta3

Or do I misunderstand things and you're using the beaglebone image?

https://build.opensuse.org/project/monitor/home:matwey:pcm051:13.3

Alex

...

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

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

2016-03-13 15:09 GMT+03:00 Alexander Graf :

On 13.03.16 12:30, Alexander Graf wrote:

...

...

Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov :

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

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.

Also, the reset "after some time" could be 2 things. It could either be the watchdog or it could be Linux in a panic handler resetting after 90 seconds. How long does it take for the board to reset?

It takes about 60 seconds, so it is watchdog most likely.

Alex

-- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2016-03-13 16:21 GMT+03:00 Alexander Graf :

On 13.03.16 14:13, Matwey V. Kornilov wrote:

...

2016-03-13 15:09 GMT+03:00 Alexander Graf :

...

On 13.03.16 12:30, Alexander Graf wrote:

...

...

Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov :

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://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2016-03-13 16:44 GMT+03:00 Alexander Graf :

On 13.03.16 14:39, Matwey V. Kornilov wrote:

...

2016-03-13 16:21 GMT+03:00 Alexander Graf :

...

On 13.03.16 14:13, Matwey V. Kornilov wrote:

...

2016-03-13 15:09 GMT+03:00 Alexander Graf :

...

On 13.03.16 12:30, Alexander Graf wrote:

...

> Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov : > > 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.

Alex

-- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 13.03.16 16:05, Matwey V. Kornilov wrote:

2016-03-13 18:03 GMT+03:00 Matwey V. Kornilov :

...

2016-03-13 16:44 GMT+03:00 Alexander Graf :

...

On 13.03.16 14:39, Matwey V. Kornilov wrote:

...

2016-03-13 16:21 GMT+03:00 Alexander Graf :

...

On 13.03.16 14:13, Matwey V. Kornilov wrote:

...

2016-03-13 15:09 GMT+03:00 Alexander Graf : > > > On 13.03.16 12:30, Alexander Graf wrote: >> >> >>> Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov : >>> >>> 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.

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? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 13.03.16 16:17, Matwey V. Kornilov wrote:

2016-03-13 18:11 GMT+03:00 Alexander Graf :

...

On 13.03.16 16:05, Matwey V. Kornilov wrote:

...

2016-03-13 18:03 GMT+03:00 Matwey V. Kornilov :

...

2016-03-13 16:44 GMT+03:00 Alexander Graf :

...

On 13.03.16 14:39, Matwey V. Kornilov wrote:

...

2016-03-13 16:21 GMT+03:00 Alexander Graf : > > > On 13.03.16 14:13, Matwey V. Kornilov wrote: >> 2016-03-13 15:09 GMT+03:00 Alexander Graf : >>> >>> >>> On 13.03.16 12:30, Alexander Graf wrote: >>>> >>>> >>>>> Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov : >>>>> >>>>> 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? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 13.03.16 16:50, Matwey V. Kornilov wrote:

2016-03-13 18:20 GMT+03:00 Alexander Graf :

...

On 13.03.16 16:17, Matwey V. Kornilov wrote:

...

2016-03-13 18:11 GMT+03:00 Alexander Graf :

...

On 13.03.16 16:05, Matwey V. Kornilov wrote:

...

2016-03-13 18:03 GMT+03:00 Matwey V. Kornilov :

...

2016-03-13 16:44 GMT+03:00 Alexander Graf : > > > On 13.03.16 14:39, Matwey V. Kornilov wrote: >> 2016-03-13 16:21 GMT+03:00 Alexander Graf : >>> >>> >>> On 13.03.16 14:13, Matwey V. Kornilov wrote: >>>> 2016-03-13 15:09 GMT+03:00 Alexander Graf : >>>>> >>>>> >>>>> On 13.03.16 12:30, Alexander Graf wrote: >>>>>> >>>>>> >>>>>>> Am 13.03.2016 um 11:56 schrieb Matwey V. Kornilov : >>>>>>> >>>>>>> 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.

It gets added to the kernel command line by the pre_checkin.sh script.

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.

Phew. So with EFI enabled, we need to have all of grub2 inside the initrd (thanks to kiwi). Since your initrd with grub2 is almost 50mb packed, I'd say we really just exceed the 256MB in your case. I don't have a great idea on how to fix that. The nicest solution would be to have a zram backed swap file (tmpfs can be swapped). But we can't set that up until we are in the initrd, which we can't get into because we're running out of ram.... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 13.03.16 17:58, Matwey V. Kornilov wrote:

2016-03-13 19:16 GMT+03:00 Alexander Graf :

...

On 13.03.16 16:50, Matwey V. Kornilov wrote:

...

Where should It come from? I don't have any rootfsflags in my grub2.

It gets added to the kernel command line by the pre_checkin.sh script.

Now I see, I've grepped rootfsflags instead of rootflags.

Meh, I always get those wrong :).

...

...

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.

Phew. So with EFI enabled, we need to have all of grub2 inside the initrd (thanks to kiwi). Since your initrd with grub2 is almost 50mb packed, I'd say we really just exceed the 256MB in your case.

Hm, two weeks ago it was 33MB. Now it is clear, except why there is no output on console with ramfs.

#define USE_EFI adds grub2 to the initrd, bloating it up by a few mb... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2016-03-13 18:35 GMT+03:00 Alexander Graf :

On 13.03.16 16:03, Matwey V. Kornilov wrote:

...

[ 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.

Maybe it's the wrong address after all. Try to run "nm" on the vmlinux binary (should be gzipped in /boot) and check for all occurences of log_buf (and __log_buf). 0xc0000000 is the "start of physical memory" in Linux. Since your SoC starts ram at 0x80000000, all you need to do is replace the c with an 8.

c12bfc30 b __log_buf c11c065c d log_buf c1365588 b log_buf no luck with any of them.

Alex

-- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org