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

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.

quoted

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.

quoted

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.

quoted

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?

quoted

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?

quoted

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/