mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Rolf Evers-Fischer <embedded24@evers-fischer.de>
To: "Lucas Stach" <dev@lynxeye.de>,
	"\"Uwe Kleine-König\"" <u.kleine-koenig@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Beaglebone white: Kernel doesn't start with barebox-2014.03.0
Date: Tue, 22 Apr 2014 09:08:33 +0200 (CEST)	[thread overview]
Message-ID: <1195890232.163334.1398150513811.open-xchange@email.1und1.de> (raw)
In-Reply-To: <1398093878.5899.1.camel@antimon.intern.lynxeye.de.Speedport_W_504V_Typ_A>

Hi Lukasz and Uwe,

> Lucas Stach <dev@lynxeye.de> hat am 21. April 2014 um 17:24 geschrieben:
>
>
> Am Mittwoch, den 16.04.2014, 22:02 +0200 schrieb Uwe Kleine-König:
> > On Wed, Apr 16, 2014 at 05:35:52PM +0200, Lucas Stach wrote:
> > > Hi Rolf,
> > >
> > > Am Dienstag, den 15.04.2014, 13:28 +0200 schrieb Rolf Evers-Fischer:
> > > > Dear all,
> > > > after update to barebox-2014.03.0, the kernel on my beaglebone-white
> > > > doesn't
> > > > start anymore.
> > > > The last line, which appears, is "booting kernel with devicetree".
> > > > I discovered that the problem is caused by the commit [1]. When I revert
> > > > this
> > > > commit, everything works fine.
> > > >
> > > > Here is some more info, which I gathered with additional printfs:
> > > > Without this commit, the '__do_bootm_linux()' function is called with
> > > > data->initrd_address = 0xffffffff
> > > > data->os_res->start = 0x80008000
> > > > data->os_entry = 0
> > > > swap = 0
> > > > Finally it invokes the 'start_linux()' function with
> > > > kernel = 0x80008000
> > > > swap = 0
> > > > initrd_start = 0x80808000
> > > > initrd_size = 0
> > > > data->oftree = 0x8b1e0000
> > > >
> > > > With this commit (i.e. when the kernel doesn't start), the
> > > > '__do_bootm_linux()'
> > > > function is called with the same parameters as above plus
> > > > free_mem = 0x8041f000
> > > > It invokes the 'start_linux()' function with
> > > > kernel = 0x80008000
> > > > swap = 0
> > > > initrd_start = 0x8041f000
> > > > initrd_size = 0
> > > > data->oftree = 0x8041f000
> > > >
> > > > Do you have any idea, how to fix this problem? For now I will continue
> > > > using
> > > > barebox-2014.03.0 without the problematic commit.
> > > >
> > > > [1] http://www.spinics.net/lists/u-boot-v2/msg17345.html
> > > > "ARM: bootm: pass free memory to __do_bootm_linux"
> > >
> > > I think you are trying to boot a uImage. Is this right?
> > >
Yes, I've tried to boot a uImage.

> > > Could you please test with a zImage? If it still fails, can you try the
> > > following patch?
> > >
> > > --------------------------------->8------------------------------------------
> > > From 6e51388bda025508b28d723960055656fa50784d Mon Sep 17 00:00:00 2001
> > > From: Lucas Stach <l.stach@pengutronix.de>
> > > Date: Wed, 16 Apr 2014 17:23:33 +0200
> > > Subject: [PATCH] ARM: bootm: be more clever while deciding where to put
> > > zImage
> > >
> > > For small systems we would put the zImage at 8MiB after
> > > the start of memory, and put the DT a bit after the zImage.
> > > When we encounter an image which is bigger than 8MiB
> > > uncompressed, the kernel would try to relocate itself
> > > and overwrite the DT.
> > >
> > > Try to be more clever at zImage placement to avoid
> > > triggering the kernel relocation.
> > >
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > ---
> > > arch/arm/lib/bootm.c | 31 ++++++++++++++-----------------
> > > 1 file changed, 14 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> > > index c63cbc02e35f..2d4b18b7f794 100644
> > > --- a/arch/arm/lib/bootm.c
> > > +++ b/arch/arm/lib/bootm.c
> > > @@ -245,23 +245,6 @@ static int do_bootz_linux(struct image_data *data)
> > > if (ret)
> > > return ret;
> > >
> > > - if (load_address == UIMAGE_INVALID_ADDRESS) {
> > > - /*
> > > - * The kernel should stay in the first 128MiB of RAM, recommended
> > > - * is 32MiB into RAM so that relocation prior to decompression
> > > - * can be avoided.
> > > - */
> > > - if (mem_size > SZ_64M)
> > > - data->os_address = mem_start + SZ_32M;
> > > - else
> > > - data->os_address = mem_start + SZ_8M;
> > > -
> > > - load_address = data->os_address;
> > > - if (bootm_verbose(data))
> > > - printf("no os load address, defaulting to 0x%08lx\n",
> > > - load_address);
> > > - }
> > > -
> > > fd = open(data->os_file, O_RDONLY);
> > > if (fd < 0) {
> > > perror("open");
> > > @@ -292,6 +275,20 @@ static int do_bootz_linux(struct image_data *data)
> > > if (swap)
> > > end = swab32(end);
> > >
> > > + if (load_address == UIMAGE_INVALID_ADDRESS) {
> > > + /*
> > > + * Just use a conservative default of 4 times the size of the
> > > + * compressed image, to avoid the need for the kernel to reocate itself
> > s/reocate/relocate/
> >
> Thanks, will fix this.
>
> > > + * before decompression.
> > > + */
> > > + data->os_address = mem_start + PAGE_ALIGN(end * 4);
> > I'm not sure if that really matters, but end isn't necessarily[1] holding
> > the size of the compressed image. Even if it doesn't matter, using
> >
> > + data->os_address = mem_start + PAGE_ALIGN((end - start) * 4);
> >
> > is more clear here.
> >
> Right, I've also noticed this. But this error is is spread in a few more
> places, so I'll cook another patch for this.
>
> Regards,
> Lucas
>
Thank you for your suggestions.
If you don't mind, I'll wait for another patch and try booting a zImage (with
and without the upcoming patch).

Kind regards,
 Rolf

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

  reply	other threads:[~2014-04-22  7:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 11:28 Rolf Evers-Fischer
2014-04-16 15:35 ` Lucas Stach
2014-04-16 20:02   ` Uwe Kleine-König
2014-04-21 15:24     ` Lucas Stach
2014-04-22  7:08       ` Rolf Evers-Fischer [this message]
2014-04-22  8:26         ` Lucas Stach
2014-04-22 10:34           ` Rolf Evers-Fischer

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=1195890232.163334.1398150513811.open-xchange@email.1und1.de \
    --to=embedded24@evers-fischer.de \
    --cc=barebox@lists.infradead.org \
    --cc=dev@lynxeye.de \
    --cc=u.kleine-koenig@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