From: Patrick Boettcher <patrick.boettcher@posteo.de>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: barebox@lists.infradead.org, Mikael Pann <Mikael.pann@stimio.fr>
Subject: Re: IMX6UL: Booting kernel with initramfs blocks
Date: Sun, 28 Oct 2018 15:29:55 +0100 [thread overview]
Message-ID: <20181028152955.74ecb97a@yaise-pc1> (raw)
In-Reply-To: <1540564611.2245.3.camel@pengutronix.de>
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
prev parent reply other threads:[~2018-10-28 14:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 10:05 Patrick Boettcher
2018-10-26 10:23 ` Sascha Hauer
2018-10-26 10:38 ` Patrick Boettcher
2018-10-26 11:24 ` Sascha Hauer
2018-10-26 14:25 ` Patrick Boettcher
2018-10-26 14:36 ` Lucas Stach
2018-10-28 14:29 ` Patrick Boettcher [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181028152955.74ecb97a@yaise-pc1 \
--to=patrick.boettcher@posteo.de \
--cc=Mikael.pann@stimio.fr \
--cc=barebox@lists.infradead.org \
--cc=l.stach@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox