From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex
Date: Fri, 29 Aug 2008 11:10:03 +0200 [thread overview]
Message-ID: <200808291110.03980.sr@denx.de> (raw)
In-Reply-To: <91386.7381.qm@web31101.mail.mud.yahoo.com>
Hi Jeff,
On Monday 25 August 2008, jeffhemstreet at yahoo.com wrote:
> I found the issue... it is with the NAND image (NUB). The NUB destination
> address is the TEXT_BASE address defined in the top level Makefile
>
> The SPL loads the NUB, and then the NUB relocates itself to the top of
> RAM (at 0xFF23000 in my case). This relocation fixes the Global table,
> but the tables for the iminfo command contain pointers to strings for
> the OS, ARCH, type etc. These string pointer all point back to the NUB
> TEXT_BASE address, which was set to 0x1000000 (16MB).
I just checked this issue on a NAND booting Canyonlands (460EX) board. I added
some debug code to print the "uimage_os" pointer from common/image.c. On my
target this pointer is relocated to the end of SDRAM too. So it's not
pointing to the NUB TEXT_BASE.
Are you sure that those string pointer are incorrect in your case? Perhaps
some other pointers or functions pointer are not relocated correctly.
> When downloading
> an image > 16MB to 0x200000, it overwrites the original image. I
> thought all the strings would be relative at this location, but the
> string pointers are global addresses. I relocated the NUB dest address to
> higher in RAM for now to get around the issue.
>
> The easiest way around this I believe is to hard code a location for the
> SPL to load the NUB to and then not relocate the NUB.
We don't really want to go this way. Biggest problem would be that we would
loose the ability to run with different memory size configurations. And if we
really have some relocation problems (which is very likely), then they will
hit us in the non NAND-booting case too. So all boards ports that relocate
will have those problems and they should be solved at the root.
> I thought I remembered something about some strings being accessed from the
> original location of the UBoot image.
It would be great if you could test a little more and let us know where
exactly the relocation problem lies. As mentioned above the string pointers
from image.c should be fine.
Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
next prev parent reply other threads:[~2008-08-29 9:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-25 16:54 [U-Boot] TFTP images larger than 16MB causing MachineCheck on 405ex jeffhemstreet at yahoo.com
2008-08-29 9:10 ` Stefan Roese [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-22 19:57 jeffhemstreet at yahoo.com
2008-08-22 20:41 ` vb
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=200808291110.03980.sr@denx.de \
--to=sr@denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox