[Top] [All Lists]

Re: RBTX4927 with VxWorks boot loader crashes in prom_getenv()

Subject: Re: RBTX4927 with VxWorks boot loader crashes in prom_getenv()
From: Atsushi Nemoto <>
Date: Mon, 27 Oct 2008 23:04:28 +0900 (JST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
On Mon, 27 Oct 2008 14:39:32 +0100 (CET), Geert Uytterhoeven 
<> wrote:
> > BTW, it looks fw_arg0 is not 'argc'.  Fortunately current code just
> > ignores argv if argc was negative, but it is not intentional
> > behaviour, just a luck ;)
> Woops...
> The memory pointed to by fw_arg0 and fw_arg1 contains just zeroes.
> According to the sources, the VxWorks bootloader just jumps to the kernel's
> entry point, without passing any parameters in a0-a3 at all. So they're just
> leftovers.

Wow, what a simple loader ...

> > You can put a string starting with "-" in CONFIG_CMDLINE, so that
> > fw_arg0 is ignored regardless of its value.  Hmm... putting "noenv" or
> > something in CONFIG_CMDLINE (and check it in preprocess_cmdline()) can
> > be an another workaround for getenv problem...
> Prepending my command line in CONFIG_CMDLINE with `-' doesn't help.
> prom_getenv() is still called.
> So I came up with the patch below.

Oh, yes, the '-' does not prevent prom_getenv().  It just prevents
argc/argv parsing.  Anyway, checking invalid fw_argN should be good.

> Subject: [PATCH] txx9: Make firmware parameter passing more robust
> When booting Linux on a txx9 board with VxWorks boot loader, it crashes in
> prom_getenv(), as VxWorks doesn't pass firmware parameters in a0-a3 (in my
> case, the actual leftover values in these registers were 0x80002000,
> 0x80001fe0, 0x2000, and 0x20).
> Make the parsing of argc, argv, and envp a bit more robust by checking if argc
> is a number below CKSEG0, and argv/envp point to CKSEG0.
> Signed-off-by: Geert Uytterhoeven <>

Look OK for me, except for coding style :)

If TAB was used for indent,
Acked-by: Atsushi Nemoto <>

<Prev in Thread] Current Thread [Next in Thread>