IMX6UL: Booting kernel with initramfs blocks

IMX6UL: Booting kernel with initramfs blocks

[Patrick Boettcher]

Hi,

we are using a Phytec IMX6UL-module and would like to use a
kernel+initramfs as a rescue/recovery system (when bootchooser bails
out).

We are building the initramfs-zIamge with Yocto using a
customized Phytec-distribution (not many changes). 

What we added to get an initramfs'd kernel is 

   INITRAMFS_IMAGE = "<image-name>"
   INITRAMFS_IMAGE_BUNDLE = "1"

to local.conf.

bitbaking the thing gives us the zImage-initramfs-file.

Then we created two static volumes within the UBI-partition on the
NAND one for the image, one for the dtb.

When trying to boot the image with bootm -o .. .. it takes some time
(to load I guess) and then blocks.

Putting the zImage "kernel-only" on the same volumes and booting works
(except that there is no rootfs).

Our zImage with initramfs is 28MiB big, the kernel alone 7.

Could anyone advise what's wrong with this setup? Is it is
size-problem in barebox? 

Is it a Yocto-problem? I'm aware that asking here might the wrong
thing, as barebox is only one part of the system.

Thanks in advance for any help.

best regards,
--
Patrick.






_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: IMX6UL: Booting kernel with initramfs blocks

[Sascha Hauer]

Hi Patrick,

On Fri, Oct 26, 2018 at 12:05:58PM +0200, Patrick Boettcher wrote:
> Hi,
> 
> we are using a Phytec IMX6UL-module and would like to use a
> kernel+initramfs as a rescue/recovery system (when bootchooser bails
> out).
> 
> We are building the initramfs-zIamge with Yocto using a
> customized Phytec-distribution (not many changes). 
> 
> What we added to get an initramfs'd kernel is 
> 
>    INITRAMFS_IMAGE = "<image-name>"
>    INITRAMFS_IMAGE_BUNDLE = "1"
> 
> to local.conf.
> 
> bitbaking the thing gives us the zImage-initramfs-file.
> 
> Then we created two static volumes within the UBI-partition on the
> NAND one for the image, one for the dtb.
> 
> When trying to boot the image with bootm -o .. .. it takes some time
> (to load I guess) and then blocks.

Could you copy the image out from UBI to /somefile first to get UBI out
of the equation first?

Doing bootm -v -v might reveal some more information then.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: IMX6UL: Booting kernel with initramfs blocks

[Patrick Boettcher]

Hi,

Thanks for your super fast answer.

On Fri, 26 Oct 2018 12:23:42 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > When trying to boot the image with bootm -o .. .. it takes some time
> > (to load I guess) and then blocks.  
> 
> Could you copy the image out from UBI to /somefile first to get UBI
> out of the equation first?

I copied 

  cp /dev/nand0.root.ubi.kernel-recovery test 
  md5sum test

The md5sum is identical with the one from my deploy dir.

Comparing the start of the zImage-initramfs file "manually" (some
bytes) with the zImage-image reveals that it is identical.

I'm using v2017.04.0-phy3 of phytec's fork of barebox, btw.
 
> Doing bootm -v -v might reveal some more information then.


  Loading ARM Linux zImage '/dev/nand0.root.ubi.kernel-recovery'
  OS image not yet relocated
  Passing control to ARM zImage handler
  no OS load address, defaulting to 0x888e1000
  no initrd load address, defaulting to 0x8a542000
  Loading devicetree from '/dev/nand0.root.ubi.oftree-recovery'
  Failed to fixup node in of_state_fixup+0x1/0x1ac: No such device
  commandline: consoleblank=0 console=ttymxc0,115200n8 rootwait ro fsck.repair=yes 
  {
    <device-tree dumped, looks good to me >
  };
 
  Starting kernel at 0x888e1000, oftree at 0x8a542000...
  nv variables modified, saving them
  <... blocks here ...>


--
Patrick.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: IMX6UL: Booting kernel with initramfs blocks

[Sascha Hauer]

On Fri, Oct 26, 2018 at 12:38:07PM +0200, Patrick Boettcher wrote:
> Hi,
> 
> Thanks for your super fast answer.
> 
> On Fri, 26 Oct 2018 12:23:42 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > When trying to boot the image with bootm -o .. .. it takes some time
> > > (to load I guess) and then blocks.  
> > 
> > Could you copy the image out from UBI to /somefile first to get UBI
> > out of the equation first?
> 
> I copied 
> 
>   cp /dev/nand0.root.ubi.kernel-recovery test 
>   md5sum test
> 
> The md5sum is identical with the one from my deploy dir.
> 
> Comparing the start of the zImage-initramfs file "manually" (some
> bytes) with the zImage-image reveals that it is identical.
> 
> I'm using v2017.04.0-phy3 of phytec's fork of barebox, btw.
>  
> > Doing bootm -v -v might reveal some more information then.
> 
> 
>   Loading ARM Linux zImage '/dev/nand0.root.ubi.kernel-recovery'
>   OS image not yet relocated
>   Passing control to ARM zImage handler
>   no OS load address, defaulting to 0x888e1000
>   no initrd load address, defaulting to 0x8a542000
>   Loading devicetree from '/dev/nand0.root.ubi.oftree-recovery'
>   Failed to fixup node in of_state_fixup+0x1/0x1ac: No such device
>   commandline: consoleblank=0 console=ttymxc0,115200n8 rootwait ro fsck.repair=yes 
>   {
>     <device-tree dumped, looks good to me >
>   };
>  
>   Starting kernel at 0x888e1000, oftree at 0x8a542000...

From what I can see these addresses look fine. You have an image that's
28MiB in size, we put it to roughly 5x size into memory and the
devicetree behind it. The kernel should then unpack itself to the start
of SDRAM. Looks good and It seems barebox actually jumps to the Kernel.

Next thing to try would be enabling CONFIG_DEBUG_LL,
CONFIG_DEBUG_UNCOMPRESS and CONFIG_EARLY_PRINTK in the Kernel. Pass
"earlyprintk" as kernel option and let's see what happens then.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: IMX6UL: Booting kernel with initramfs blocks

[Patrick Boettcher]

On Fri, 26 Oct 2018 13:24:38 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >   Starting kernel at 0x888e1000, oftree at 0x8a542000...
> 
> From what I can see these addresses look fine. You have an image
> that's 28MiB in size, we put it to roughly 5x size into memory and the
> devicetree behind it. The kernel should then unpack itself to the
> start of SDRAM. Looks good and It seems barebox actually jumps to the
> Kernel.
> 
> Next thing to try would be enabling CONFIG_DEBUG_LL,
> CONFIG_DEBUG_UNCOMPRESS and CONFIG_EARLY_PRINTK in the Kernel. Pass
> "earlyprintk" as kernel option and let's see what happens then.

(earlyprintk yet to be tried)

We made a step forward: Reducing the size of the image (from 28 down to
17 MiB) makes it boot correctly.

Not sure where the limitation can come from, if you have an idea.

Thanks again for the help so far, I will post a follow-up if the
root-cause is discovered.

--
Patrick.


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: IMX6UL: Booting kernel with initramfs blocks

[Lucas Stach]

Am Freitag, den 26.10.2018, 16:25 +0200 schrieb Patrick Boettcher:
> On Fri, 26 Oct 2018 13:24:38 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > >   Starting kernel at 0x888e1000, oftree at 0x8a542000...
> > 
> > From what I can see these addresses look fine. You have an image
> > that's 28MiB in size, we put it to roughly 5x size into memory and the
> > devicetree behind it. The kernel should then unpack itself to the
> > start of SDRAM. Looks good and It seems barebox actually jumps to the
> > Kernel.
> > 
> > Next thing to try would be enabling CONFIG_DEBUG_LL,
> > CONFIG_DEBUG_UNCOMPRESS and CONFIG_EARLY_PRINTK in the Kernel. Pass
> > "earlyprintk" as kernel option and let's see what happens then.
> 
> (earlyprintk yet to be tried)
> 
> We made a step forward: Reducing the size of the image (from 28 down to
> 17 MiB) makes it boot correctly.
> 
> Not sure where the limitation can come from, if you have an idea.
> 
> Thanks again for the help so far, I will post a follow-up if the
> root-cause is discovered.

My guess is that the kernel is just not able to find the start of RAM
for relocation in that case. With such a fat image and our pessimistic
placement at 5 times that size, the kernel ends up in a region above
the first 128MB of memory.
The kernel needs to be placed in the low 128MB, as this is the address
range that gets masked off from the location in order to find the start
of RAM.

Regards,
Lucas

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: IMX6UL: Booting kernel with initramfs blocks

[Patrick Boettcher]

On Fri, 26 Oct 2018 16:36:51 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:

> Am Freitag, den 26.10.2018, 16:25 +0200 schrieb Patrick Boettcher:
> > On Fri, 26 Oct 2018 13:24:38 +0200  
> > > Sascha Hauer <s.hauer@pengutronix.de> wrote:  
> > > >   Starting kernel at 0x888e1000, oftree at 0x8a542000...  
> > > 
> > > From what I can see these addresses look fine. You have an image
> > > that's 28MiB in size, we put it to roughly 5x size into memory
> > > and the devicetree behind it. The kernel should then unpack
> > > itself to the start of SDRAM. Looks good and It seems barebox
> > > actually jumps to the Kernel.
> > > 
> > > Next thing to try would be enabling CONFIG_DEBUG_LL,
> > > CONFIG_DEBUG_UNCOMPRESS and CONFIG_EARLY_PRINTK in the Kernel.
> > > Pass "earlyprintk" as kernel option and let's see what happens
> > > then.  
> > 
> > (earlyprintk yet to be tried)
> > 
> > We made a step forward: Reducing the size of the image (from 28
> > down to 17 MiB) makes it boot correctly.
> > 
> > Not sure where the limitation can come from, if you have an idea.
> > 
> > Thanks again for the help so far, I will post a follow-up if the
> > root-cause is discovered.  
> 
> My guess is that the kernel is just not able to find the start of RAM
> for relocation in that case. With such a fat image and our pessimistic
> placement at 5 times that size, the kernel ends up in a region above
> the first 128MB of memory.
> The kernel needs to be placed in the low 128MB, as this is the address
> range that gets masked off from the location in order to find the
> start of RAM.

That's exactly the problem. I sent a patch which makes bootm bail out
if the image is located outside the first 128MB of RAM. Please tell me
whether this is a good way to do things within barebox.

At least as a first step.

Another idea I would have is, why not putting the kernel image always
at the end of the 128MB limit (or at the end of the available memory if
it is lower than 128MB)? Is this where barebox has its stack/heap
already?

--
Patrick.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox