From: "Guillaume Dargaud" <dargaud@lpsc.in2p3.fr>
To: "ppcdev" <linuxppc-dev@ozlabs.org>
Subject: Re: Calling the kernel from a mini-bootloader
Date: Tue, 22 Jul 2008 18:01:28 +0200 [thread overview]
Message-ID: <04ea01c8ec14$36663c70$ad289e86@LPSC0173W> (raw)
In-Reply-To: 048601c8ebe8$acbfcc50$ad289e86@LPSC0173W
Answering to myself to try and provide more background info:
> As a follow up to my previous messages, I now have a working kernel and a
> working bootloader... but not when they are both together.
>
> Case in point:
> - load zImage.elf to DRAM 0x400000 with JTAG debugger. Run it. It runs
> fine.
>
> - Load Bootloader.elf to BRAM 0xFFFF0000 with JTAG debugger. Run it. It
> runs fine (but it doesn't do much yet).
>
> - Now load both of the previous ones, and have the bootloader perform a
> jump to kernel:
void main() {
typedef void tFunc(void);
((tFunc *)0x400000)();
}
Now if the bootloader _only_ contains the above code, the kernel runs
perfectly.
Unfortunately I need to do some things in the bootloader: I use 3 GPIOs to
control a frontal set of LEDs, to get a card number and to load/unload a
serial flash memory. Those operations work. But here is the strange thing
that leads me to believe there are interrupt interferences.
If I just read from a GPIO before launching the kernel, it boots fine, with
a few NFS errors when mounting the rootnfs:
[ 4.360060] Freeing unused kernel memory: 76k init
[ 11.432269] nfs: server 192.168.1.185 not responding, still trying
[ 11.441186] nfs: server 192.168.1.185 OK
init started: BusyBox v1.10.1 (2008-04-24 12:26:38 CEST)
genepy login:
Now if I also write to a 2nd GPIO, I get a lot more NFS errors.
And if I also access the flash through the 3rd GPIO, the kernel hangs:
> loaded at: 00400000 004EA19C
> board data at: 004E8120 004E819C
> relocated to: 0040405C 004040D8
> zimage at: 00404E48 004E7A7E
> avail ram: 004EB000 08000000
>
> Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
> Uncompressing Linux...done.
> Now booting the kernel
>
> But then it hangs for exactly 3 minutes, nothing on the serial port,
> before the bootloader restarts.
> Why should the behavior be different whether it's started from the
> debugger or from my bootloader ?
Now I've defined my hardware project using interrupts on the GPIOs, which I
don't need and frankly they don't make sense for an output GPIO. I would
like to try to compile a kernel without GPIO interrupts, unfortunately the
compilation fails:
$ make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc-
[...]
CC arch/ppc/syslib/virtex_devices.o
arch/ppc/syslib/virtex_devices.c:535: error: 'XPAR_INTC_0_GPIO_0_VEC_ID'
undeclared here (not in a function)
Question breakdown:
- do I need interrupts for GPIOs ?
- how can I compile the ppc 2.6.25 kernel without them ?
- Why do I have problems running the kernel if the bootloader makes use of
the GPIOs ?
- does the bootloader need to perform some kind of special cleanup before
calling the kernel ?
Thanks a lot for shedding a light on those mysteries.
--
Guillaume Dargaud
http://www.gdargaud.net/
next prev parent reply other threads:[~2008-07-22 16:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 16:14 Calling the kernel from a mini-bootloader Milton Miller
2008-07-18 3:47 ` David Gibson
2008-07-18 17:47 ` Milton Miller
2008-07-18 8:43 ` Guillaume Dargaud
2008-07-18 18:38 ` Milton Miller
2008-07-22 10:49 ` Guillaume Dargaud
2008-07-22 16:01 ` Guillaume Dargaud [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-07-17 13:22 Guillaume Dargaud
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='04ea01c8ec14$36663c70$ad289e86@LPSC0173W' \
--to=dargaud@lpsc.in2p3.fr \
--cc=linuxppc-dev@ozlabs.org \
/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;
as well as URLs for NNTP newsgroup(s).