wijnen at debian.org
Sun Mar 21 03:44:09 EDT 2010
I'm writing a new kernel, Iris. I don't know everything about the
GNU/Linux environment it is shipped with, but I do know a lot about the
On Sat, Mar 20, 2010 at 09:30:07PM -0500, Brian Stuart wrote:
> - Am I right in saying that the processor core of the 4720 is a
> little-endian MIPS?
> Does anyone know off-hand which member of the MIPS family it's closest
> to? Comparing the instruction set to Patterson and Hennessy, I'm
> guessing it's like an M3000 or M4000, but it's just a guess.
I don't know. All I know is I use -Wa,-mips32 on my gcc commandline to
make it accept all instructions I need in my inline assembly.
Note that the CPU timer (COUNT/COMPARE CP0 registers) is not running.
For the system clock, you need the on-chip OS-timer. Also, the RANDOM
register isn't very usable as a random counter, because it doesn't
increment every clock cycle, but only on a TLBWR instruction (which
makes it just as usable as tlb field manager).
> - I'm not entirely clear on what the [power]+[m] boot mode does currently.
> I see that in the recently-announced u-boot code, it can get a kernel from a
> VFAT partition on the SD card. Does the current one get the kernel image
> from the onboard flash or from a kernel partition on the SD card? I'd like
> to keep the Linux image on the onboard flash for the time being and boot
> Inferno off of the SD card. Can I do that with the currently stock code, or
> do I need to install the new u-boot code?
AFAIK the current code loads the kernel from on-board nand flash, and
the rootfs from SD. There were plans to change this, but I don't think
they've been implemented so far.
> - Does anyone have a pointer to the actual format the uImage file has to be
> for u-boot to load it? What kind of header does it need and what address
> does it load at? I've been searching around on the net, but all I'm finding
> are instructions about running some utility after building a Linux kernel
> with the GNU toolchain. That doesn't really help me. Inferno doesn't use
> the GNU toolchain, so the easiest thing, by far, will be to add an output
> format to the linker that makes u-boot happy. (At least that's what's been
> easiest for nearly every other port.) I don't suppose that I could be so
> lucky that u-boot is friendly enough to load a multiboot image, or some
> other simple format? Inferno builds everything it needs to get off the
> ground into one image, so I don't need the complexity that the FIT format
> allows. However, if I could at least find a description of what bytes go
> where in a file of that format, I could at least do that.
I don't know. Given that the name should be uImage, it is probably an
u-boot image. In debian there is a package named uboot-mkimage, which
can build it. I suppose the source can help you. But first check if
this is indeed the format it wants. ;-)
> - What kind of initialization has u-boot done before transferring control to
> the newly loaded kernel? For example, has it set the SDRAM configuration
> registers to the correct values? Has it done anything with the GPIO pins?
> the LCD panel? Or do I need to assume that the chip is in the reset state?
When booting over USB, I must first load a small program (max 4 kB) into
the device's cache, which is executed there. This program is used to
set up the SDRAM. After that, the kernel is loaded into the now working
SDRAM. Booting from nand, I expect the same sequence.
In my kernel, I do all initialization in the kernel, just to be sure
it's done right. For the SDRAM, this is certainly double work: the
kernel would not be executing if that wasn't properly initialized. For
all other things, I don't initialize them in the initial loader, because
that only makes it harder to see how it works.
U-boot probably does some initialization, although I don't know how
much. I would just assume it doesn't initialize anything. It only
costs a few microseconds to redo it. ;-)
> I'm sure I'll have more questions as I go, but from previous porting
> experiences, I know these are some of the first I'll have to address when I
> finally get my hands on it. In the mean time, I'm like a kid waiting for
As was mentioned, you may prefer to test using usbboot instead of
SD-card. With my kernel, I can compile and test my changed sources with
a single key press. That is very convenient. I was first working on
a different machine, where I needed to use SD. It gets annoying to do
"move card to desktop; copy image; move card to test machine; reset" all
I've also done debugging over LEDs, as you mentioned, which works. The
speaker (pwm4) is probably the best option to do something like that.
However, getting serial output (input has trouble with the keyboard and
isn't really needed for debugging anyway) isn't hard to achieve and much
easier to read. ;-) So that's certainly useful, if you plan to work on
things where the screen isn't working yet.
 The single key press only works because I have soldered the "boot
from usb" pins closed. This means it always boots from usb. If you
want to be able to boot normally as well, you need to hold down U while
booting (and get into software usbboot mode, which is very similar the
the hardware usbboot mode I use).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the discussion