linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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/ 

  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).