All of lore.kernel.org
 help / color / mirror / Atom feed
From: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] u-boot stack overwrites end ramdisk
Date: Thu, 18 Mar 2010 10:35:07 +0100	[thread overview]
Message-ID: <4BA1F3CB.3050500@aimvalley.nl> (raw)
In-Reply-To: <4BA0FAAA.20604@aimvalley.nl>


I was not totally correct.
gunzip/inflate has nothing to do with this problem.

the problem is this:

- do_bootm->bootm_start->arch_lmb_reserve
   reserves "unused" memory as in cur_sp-1k upto end-of-mem
   in my case this is 0x0fb0cb28 - 0x10000000

- do_bootm->do_bootm_linux->boot_body_linux->boot_ramdisk_high
   places ramdisk as close to (and below) the "unused" memory
   reservation (0x1000 aligned)
   in my case ramdisk is copied to 0x0f8c0000 - 0x0fb0ca24

- the end of the ramdisk is overwritten while printing
   "Loading Device Tree to 00ffa000, end 00fff593 ... OK"
   this happens from:
   do_bootm->do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number

bootm_start and arch_lmb_reserve together use 40 + 32 = 72 bytes stack.
The assumption that u-boots' stack usage will not exceed
arch_lmb_reserve stack pointer - 1k is simply incorrect.
The "do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number"
call chain (called from that same do_bootm) uses
56 + 40 + 1112 + 56 + 104 = 1368 bytes

This problem will only occur with CONFIG_OF_LIBFDT #defined
and it depends on how the 0x1000 alignment of the ramdisk image
turns out.

Btw. It looks like latest u-boot also has this problem.

I'll send a patch later making it 4k.

I do wonder why it was set so tight in the first place.

      reply	other threads:[~2010-03-18  9:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 15:52 [U-Boot] u-boot stack overwrites end ramdisk Norbert van Bolhuis
2010-03-18  9:35 ` Norbert van Bolhuis [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=4BA1F3CB.3050500@aimvalley.nl \
    --to=nvbolhuis@aimvalley.nl \
    --cc=u-boot@lists.denx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.