All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Chain loading an u-boot from an u-boot
Date: Tue, 11 Feb 2014 10:38:02 +0100	[thread overview]
Message-ID: <52F9EF7A.5080805@denx.de> (raw)
In-Reply-To: <52F8B3F5.8050101@hale.at>

Hi Helmut,

On 10/02/2014 12:11, Helmut Raiger wrote:

> 
> So the idea was:
> 
> - use a small u-boot (<128kB) in the first PEB of the NAND (written with
> 1bit HW-ECC) that supports 4bit BCH
> - let it load a second u-boot (<512kB) from the next 4 PEBs (written
> with 4bit BCH)
> - jump to the second u-boot and load the kernel from an UBI volume using
> 1bit HW-ECC again

I understand the first two points, but why do you store the kernel again
with 1bit HW-ECC ? The second U-Boot is able to check with 4bit BCH and
your NAND requires 4bit.

> 
> I did all that and it seemed to work just fine, but jumping to the
> second u-boot almost always
> crashes the system. In detail we do:
> 
> - romboot loads the SPL (2kb)
> - SPL loads the first u-boot stage (which relocates and runs nicely)
> - the first u-boot 'boots' the second u-boot by loading it from the NAND
> - the second u-boot is loaded to the link address minus 2kB (for SPL)
> - this is the same for the first and the second u-boot  (link address
> 0x87e00000 - 0x800 = 0x87dff800)
> - it jumps to 0x87e00000 omitting the SPL for the second u-boot
> - the second u-boot should relocated itself again
> 
> The second u-boot is verified in RAM with crc32 and it is valid.
> 
> I've tested many configuration and found, that it only works if both
> u-boots are identical:
> 
> - different builds of the same code work (different build date, but same
> code)

I agree with Andreas' analyses. It seems that the second u-boot
overwrites your running U-Boot and only if they are identical you have
no problem, that means that you are not changing the running code.

Regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

  parent reply	other threads:[~2014-02-11  9:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 11:11 [U-Boot] Chain loading an u-boot from an u-boot Helmut Raiger
2014-02-10 12:14 ` Andreas Bießmann
2014-02-10 12:57   ` Helmut Raiger
2014-02-12 21:59     ` Scott Wood
2014-02-13  9:45       ` Helmut Raiger
2014-02-11  9:38 ` Stefano Babic [this message]
2014-02-12  9:56   ` Helmut Raiger
2014-02-12 10:41     ` Stefano Babic
2014-02-12 10:45     ` Andreas Bießmann
2014-02-13  9:03       ` Helmut Raiger
2014-03-31 11:29         ` Helmut Raiger
2014-04-03 23:13           ` Simon Glass
2014-04-04  9:25             ` Stefano Babic
2014-04-09 14:07               ` Helmut Raiger

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=52F9EF7A.5080805@denx.de \
    --to=sbabic@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 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.