All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] intended behavior of bootm
Date: Mon, 21 Apr 2008 16:58:25 +0200	[thread overview]
Message-ID: <200804211658.26095.matthias.fuchs@esd-electronics.com> (raw)
In-Reply-To: <200804211509.43558.matthias.fuchs@esd-electronics.com>

Hi,

after going through the boom code I found out, that
setting the 'autostart' variable to 'no' brings me a little closer
to what I want. But finally I end up
in the enable_interrupts() at the very end of do_bootm(). This freezes
my system. The reason for this is the Linux kernel image that is loaded to address 0
and that overwrites the vector table. So reenabling the interrupts in U-Boot with
Linux interrupt table is a bad idea.

So what's the best idea to fix this? I could copy the vector table onto the stack
in do_bootm() and copy it back just before reenabling the interrupts.

Any better idea?

Matthias

On Monday 21 April 2008 15:09, Matthias Fuchs wrote:
> Hi,
> 
> I am wondering if bootm behaves correctly on CRC errors in kernel and/or ramdisk images.
> This is what I observed:
> 
> 1) I loaded a Linux kernel into RAM at 0x200000 on a 405 system. I loaded an initial ramdisk images
> into RAM at address 0x300000. Now 'bootm 200000 300000' boots my system correctly.
> 
> 2) Same loading as above. But I made the kernel image CRC check fail (mw 220000 12345678).
> I get:
> ...
>    Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
> =>
> 
> That's ok.
> 
> 3) Same loading as above. But I make the ramdisk CRC check fail (mw 320000 12345678).
> I get:
> ## Booting kernel from Legacy Image at 00200000 ...
> ...
> ## Loading init Ramdisk from Legacy Image at 00300000 ...
> ...
>    Verifying Checksum ... Bad Data CRC
> <system reset>
> U-Boot 1.3.2-00450-g77dd47f (Apr 21 2008 - 14:43:23)
> 
> Hmm, I expected the same behavior as for a corrupted kernel image.
> So what should be the correct behavior? I would like to get back to the prompt
> on any CRC error. So is this a bug?
> 
> Matthias

  reply	other threads:[~2008-04-21 14:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-21 13:09 [U-Boot-Users] intended behavior of bootm Matthias Fuchs
2008-04-21 14:58 ` Matthias Fuchs [this message]
2008-04-21 15:16   ` Jerry Van Baren
2008-04-21 15:43     ` Matthias Fuchs
2008-04-21 16:28       ` Jerry Van Baren
2008-04-21 19:19 ` Wolfgang Denk
2008-04-21 21:02   ` Matthias Fuchs
2008-04-22 20:49     ` Wolfgang Denk
2008-04-23  8:43       ` Matthias Fuchs

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=200804211658.26095.matthias.fuchs@esd-electronics.com \
    --to=matthias.fuchs@esd-electronics.com \
    --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.