query on ppc/kernel/head.S for generic 8240

query on ppc/kernel/head.S for generic 8240

[Ron Bianco]

I'm working on a kernel for our custom 8240 board, starting with MontaVista's Sandpoint
config.
The only config changes I've done so far are the SCSI and Ethernet driver choices.
Attempting to remove the mac keyboard causes linking problems I don't want to deal with
right now.
And as I don't have a UART I'll have to do a special console driver at some point, but for
now I modified printk() to just put the strings into a large buffer that I can monitor
with the JTAG debugger.

I'm concentrating on the kernel itself at the moment so I can use it to help me verify
that the PCI SCSI and Ethernet chips are working OK, so I can get the Rev B version of the
board into the fabrication pipeline, and then continue with further software dev.

When I first started looking at the Linux kernel code, I thought the loader/decompressor
portion might do some required initialization before decompressing, loading and starting
the kernel.   Thanks to Dan Malek for pointing out that one could concentrate on the
kernel itself with no worries.

So, since I'm ignoring the loader/decompressor and will have a custom loader,  I changed:

KERNELLOAD in file:  arch/ppc/Makefile from C0000000 to 00000000
PAGE_OFFSET and therefore KERNELBASE in file:  include/asm-ppc/page.h from C0000000 to
00000000

Would this break anything?  Is this sufficient?

In file:   arch/ppc/kernel/head.S,  I'm wondering if can branch directly to   start_here:
as I don't see anything useful in the code before that for my purposes?  All I have to do
is make sure the stack pointer is set to some innocuous place first?

Is there an advantage to using the residual data mechanism?  i.e. to create a version that
matches my hardware?
Or is this strictly for the pmac or some specific BootROM?

Thanks, Ron

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: query on ppc/kernel/head.S for generic 8240

[Tom Roberts]

Ron Bianco wrote:
> And as I don't have a UART I'll have to do a special console driver at some point, but for
> now I modified printk() to just put the strings into a large buffer that I can monitor
> with the JTAG debugger.

Yes. My boards have no UART either, but they do have a PCI interface to
a host, which can read/write memory. So I wrote a custom console driver
using that. Note that there are really _TWO_ consoles -- you will need
a console driver for printk-s and a serial I/O driver for /dev/console;
I made them use the same buffer so they appear at the same device on
the host. I don't think anything uses the input side of the console
driver (but am not certain).


> I'm concentrating on the kernel itself at the moment so I can use it to help me verify
> that the PCI SCSI and Ethernet chips are working OK, so I can get the Rev B version of
> the
> board into the fabrication pipeline

I personally would not be satisfied that the interfaces work without
running diagnostics on them (read/write the disks, ping other Ethernet
hosts, etc.) -- that will require the ability to run user programs in
Linux. If Linux is to be the only OS running on your board, then your
schedule should reflect the time it takes to port Linux to it. In my
case we had our proprietary OS running on the boards long ago and know
the hardware works....


> I'm ignoring the loader/decompressor and will have a custom loader,

So do I. I simply load vmlinux, as I had some difficulty with the
decompressor code; it only takes me 0.7 sec to download the uncompressed
vmlinux anyway. My loader knows about ELF files, and it just loads the
PROG section to physical address 0, puts the command-line at 0x00400000
(an arbitrary choice), and constructs a short startup at 0xFFF00000 and
each exception vector there. The short startup loads values into r3-r7
and jumps to physical address 0; r3=board ID, r4&r5=initrd image,
r6&r7=cmd line.


> I changed:
> KERNELLOAD in file:  arch/ppc/Makefile from C0000000 to 00000000
> PAGE_OFFSET and therefore KERNELBASE in file:  include/asm-ppc/page.h
> from C0000000 to 00000000

I don't think you want to do that -- virtual 0x00000000 is _USER_
space. Note that KERNELBASE, KERNELLOAD, and PAGE_OFFSET are all
virtual addresses. Linux/PPC implicitly assumes it is loaded at
physical address 0x00000000 because it sets the MSR to use the
exception vectors there (it expects some sort of boot ROM at
physical 0xFFF00000).


> Would this break anything?

Yes. Moving the virtual address of the kernel to 0 can cause conflicts
with user programs, especially if you have more than 256 MB of physical
RAM (some of our boards do). It is possible that with less than that it
will work, as the user programs I have looked at start above 0x10000000,
but I would not want to count on that. I do not know if the BAT setup
in mm_init() will work properly for this, but it probably does -- you'd
better check.


> Is this sufficient?

Surely not. Here is the list of files I had to change to get Linux
up on our boards:
	head.S		_LOTS_ of changes
	setup.c		_LOTS_ of changes to things like powerdown
	main.c		need to init the lsps console driver early
	mm_init.c	need to map memory for my drivers
	ppc_ksyms.c	need to remove some undefined symbols
	arch/ppc/kernel/Makefile  remove unused stuff
	drivers/Makefile  remove unused stuff
	main/Makefile	add a make in my LSPS directory
Plus one new file:
	lsps_bd.c	console and network drivers for our LSPS board

Note that for every file I needed to change, I moved it to
/usr/local/src/linux/lsps and sym-linked it back where it belonged.
This way all changed files are in one place, and I can back them up.
All changes are #ifdef-ed with CONFIG_LSPS -- "lsps" is of course our
product name.


> In file:   arch/ppc/kernel/head.S,  I'm wondering if can branch directly to   start_here:
> as I don't see anything useful in the code before that for my purposes?

NO! the code to get to start_here uses the rfi instruction to enable
memory management synchronously, and there is a lot of code before that
to setup the BATs and SRs. You most definitely need all that. Note
that Linux turns the memory-management on and off several times during
its initialization.


> All I have to do
> is make sure the stack pointer is set to some innocuous place first?

It is _A_LOT_ more complicated than that. The stack is the least of
your worries....


> Is there an advantage to using the residual data mechanism?  i.e. to create a version that
> matches my hardware?
> Or is this strictly for the pmac or some specific BootROM?

I have never figured it out, and don't use it.


Note that everything I have learned about this came from reading the
code and playing with it to make it work on our boards. It is possible
that I have some details wrong, and likely that my style is different
from that of other kernel developers. But Linux does run solidly on our
boards.


Tom Roberts	tjroberts@lucent.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: query on ppc/kernel/head.S for generic 8240

[Ron Bianco]

Thanks Tom, for the very interesting insights in this and other emails.  Sorry that you
got this msg twice, I don't know how often you check the mail list.

BTW, I summarized our board and my dev. env. in an email dated: 7/7/00.

> > And as I don't have a UART I'll have to do a special console driver at some
> >point, but for
> > now I modified printk() to just put the strings into a large buffer that I can monitor
> > with the JTAG debugger.
>
> Yes. My boards have no UART either, but they do have a PCI interface to
> a host, which can read/write memory. So I wrote a custom console driver
> using that. Note that there are really _TWO_ consoles -- you will need
> a console driver for printk-s and a serial I/O driver for /dev/console;
> I made them use the same buffer so they appear at the same device on
> the host. I don't think anything uses the input side of the console
> driver (but am not certain).

Good point. Similar situation on our board.
Our board has 32kWords (32bit) of dual port SRAM at the BootROM location FFF00000 as PCI
mem, for word access only.
Our host will deposit boot code in there before taking the 8240 board out of reset.  Other
than config register init, the boot code's main job will be to handle packetized xfer of
the Linux kernel code from the host to SDRAM, and then start the kernel.
Once the kernel's running, I'll of course be able to telnet via ethernet for a pseudo
linux console.

In the meantime, since after start_kernel(), and maybe before,  the VisionClick debugger
will be mostly useless, I'll be desparate for console I/O.   I did a crude hack to
printk.c that only seems to work until MMU is turned on.  I was wondering if you would be
able & willing to share your custom console source code as an example.
I am just starting to learn PPC assembly lang. in addition to Linux, and it would be a
huge help.

> > I'm concentrating on the kernel itself at the moment so I can use it to help me verify
> > that the PCI SCSI and Ethernet chips are working OK, so I can get the Rev B version of
> > the  board into the fabrication pipeline

> I personally would not be satisfied that the interfaces work without
> running diagnostics on them (read/write the disks, ping other Ethernet
> hosts, etc.) -- that will require the ability to run user programs in
> Linux. If Linux is to be the only OS running on your board, then your
> schedule should reflect the time it takes to port Linux to it. In my
> case we had our proprietary OS running on the boards long ago and know
> the hardware works....

Good point and yes that's the plan.

> > I'm ignoring the loader/decompressor and will have a custom loader,
>
> So do I. I simply load vmlinux, as I had some difficulty with the
> decompressor code; it only takes me 0.7 sec to download the uncompressed
> vmlinux anyway. My loader knows about ELF files, and it just loads the
> PROG section to physical address 0, puts the command-line at 0x00400000
> (an arbitrary choice), and constructs a short startup at 0xFFF00000 and
> each exception vector there. The short startup loads values into r3-r7
> and jumps to physical address 0; r3=board ID, r4&r5=initrd image,
> r6&r7=cmd line.

You put the same startup code at all the initial exception vectors in the 0xFFF00000
range?

> > I changed:
> > KERNELLOAD in file:  arch/ppc/Makefile from C0000000 to 00000000
> > PAGE_OFFSET and therefore KERNELBASE in file:  include/asm-ppc/page.h
> > from C0000000 to 00000000
>
> I don't think you want to do that -- virtual 0x00000000 is _USER_
> space. Note that KERNELBASE, KERNELLOAD, and PAGE_OFFSET are all
> virtual addresses. Linux/PPC implicitly assumes it is loaded at
> physical address 0x00000000 because it sets the MSR to use the
> exception vectors there (it expects some sort of boot ROM at
> physical 0xFFF00000).

An objdump of vmlinux, built unmodified, shows vaddr and paddr == 0cC0000000.  This forces
a conventional elf loader to try to load it to 0xC0000000.
With the EST debugger/elf converter, if I had built conventionally, I have to force the
load to 00000000 but then the debugger refuses to single step or run with PC == 0.   Don't
know why.  And changing KERNELLOAD only, causes copy_and_flush() to copy the kernel
needlessly, then crashola when MMU turned on.   So I did it that way, at least for the
time being, and it runs OK up to MMU_init().
If I don't use an elf format image then I lose debugging info.

I'm still confused by this issue.  i.e. what is the virtual map that linux expects/uses.
How a debugger with no table walk can't still be useful if it is always looking at
physical addresses.  Or does a JTAG request for data at an address also get translated by
the MMU if it is enabled?

> > Would this break anything?
>
> Yes. Moving the virtual address of the kernel to 0 can cause conflicts
> with user programs, especially if you have more than 256 MB of physical
> RAM (some of our boards do). It is possible that with less than that it
> will work, as the user programs I have looked at start above 0x10000000,
> but I would not want to count on that. I do not know if the BAT setup
> in mm_init() will work properly for this, but it probably does -- you'd
> better check.

Right, thanks.

> Here is the list of files I had to change to get Linux
> up on our boards:
> 	head.S		_LOTS_ of changes
> 	setup.c		_LOTS_ of changes to things like powerdown
> 	main.c		need to init the lsps console driver early
> 	mm_init.c	need to map memory for my drivers
> 	ppc_ksyms.c	need to remove some undefined symbols
> 	arch/ppc/kernel/Makefile  remove unused stuff
> 	drivers/Makefile  remove unused stuff
> 	main/Makefile	add a make in my LSPS directory
> Plus one new file:
> 	lsps_bd.c	console and network drivers for our LSPS board

Thanks, this is helpful.   At this point, I'm unsure of what I can safely remove in terms
of unused stuff.  I changed the ethernet and scsi drivers used at least, OK.   Trial and
error for the rest I guess.

> Note that for every file I needed to change, I moved it to
> /usr/local/src/linux/lsps and sym-linked it back where it belonged.
> This way all changed files are in one place, and I can back them up.
> All changes are #ifdef-ed with CONFIG_LSPS -- "lsps" is of course our
> product name.

Good idea.

> Note
> that Linux turns the memory-management on and off several times during
> its initialization.

Right.  Seems kind of hackish.  Confusing to follow.

> Note that everything I have learned about this came from reading the
> code and playing with it to make it work on our boards. It is possible
> that I have some details wrong, and likely that my style is different
> from that of other kernel developers. But Linux does run solidly on our
> boards.

Wow.  Seems like reading the code sometimes raises more questions for me.  I'm currently
struggling to understand/modify the irq setup.
After that I'm going over the MMU init stuff.  Then, hopefully,  the kernel will start up
OK.

Cheers, Ron


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/