RE: [microblaze-uclinux] Source of kernel boot message, "MBVanilla flash probe..."?

["David Banas" <dbanas@xxxxxxxxxxxxxx>]

John,

I didn't find a "mbvanilla.c" in that directory, but I did find a
"mbvanilla-flash.c", which looks to be the culprit; is that the file you
meant?

Why does the code in that file "hard-wire" the FLASH base address and bus
width, a la:

--------- code excerpt begins here. --------
#ifdef CONFIG_MBVANILLA
#define FLASH_BASE      0xff000000
#define BUS_WIDTH       4
#elif defined(CONFIG_UCLINUX_AUTO)
#define FLASH_BASE      0xff000000
#define BUS_WIDTH       4
#endif
--------- code excerpt ends here. --------

instead of using a constant from the new "auto-config" flow?

Thanks,

David Banas
Field Applications Engineer
Nu Horizons Electronics Corp.
2070 Ringwood Avenue
San Jose, CA 95131
(408)434-0800 - office
(415)846-5837 - cell
http://www.nuhorizons.com

> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au [mailto:owner-microblaze-
> uclinux@itee.uq.edu.au] On Behalf Of John Williams
> Sent: Monday, March 21, 2005 6:51 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [microblaze-uclinux] Source of kernel boot message,
> "MBVanilla flash probe..."?
>
> Hi David,
>
> David Banas wrote:
> > Hi All,
> >
> > Does anyone know which source file is responsible for printing the
> following
> > line during kernel boot?
> >
> > MBVanilla flash probe(0xff000000,8388608,4): 800000 at ff000000
>
> linux-2.4.x/drivers/mtd/maps/mbvanilla.c
>
> > I haven't had any luck trying to find it using grep. I tried to find it
> by
> > backtracing in gdb (breakpointing at the function, which is responsible
> for
> > genereating the next line of printout), but I get one of those
> > infinitely-recursive stack traces. Incidentally, are there any theories
> > floating around regarding the cause of those?
>
> it will be a mismatch between the stack unwind logic built into mb-gdb,
> and the actual stack frame in the kernel.
>
> It may be useful to try placing a breakpoint inside a kernel system call
> routine, then let the board boot, and have some user program execute
> that syscall.  Take a look at the stack, the unwind should terminate
> cleanly at ret_from_syscall.
>
> John
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-
> uclinux/
>
>
> ________________________________________________________________________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ________________________________________________________________________



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/