From: Patrick Huesmann <hidden> Date: 2004-08-23 15:17:15
Hi,
I'm trying to port Linux to a custom board built around a virtexII-fpga
which features a PPC-405 cpu.
I've downloaded the Montavista 2_4_devel tree, which already has some
platform and driver support for the ml300 eval board, and made a few changes
to the xilinx specific header files to reflect our FPGA design.
Then I changed the tophys macro in include/asm/ppc_asm.h to have a sensible
initial mmu.
#define MY_PHYS_RAM 0x90000000
#define tophys(rd,rs) addis rd,rs,(MY_PHYS_RAM-KERNELBASE)@h;
#define tovirt(rd,rs) addis rd,rs,(KERNELBASE-MY_PHYS_RAM)@h;
My kernel gets past the initial mmu setup, enters the C code and freezes in
the middle of early_init in arch/ppc/kernel/setup.c when (after?) memset_io
is called to zero the BSS region.
I've some experience with porting ARM-Linux but, unfortunately, the PPC port
seems to be significantly different (there are no mach-types and ATAG lists,
for example).
1) Is there any comprehensive documentation / tutorial on how to port the
ppc-linux to new machines? Where does my board specific fixup stuff go (for
example, memory and IRQ declarations and such).
2) What requirements and responsibilities are imposed on the bootloader? I
suspect that I can't use u-boot or something like that, because we have our
own "company-specific" bootloader so that all our products use the same
protocol for firmware updates.
3) Is there a way to get a self-decompressing kernel image? ARM linux
provides a zImage which the cpu just has to jump into (with some registers
initialized) and then decompresses vmlinux by itself. Now I have to use a
vmlinux file and write it to flash directly, because zImage on powerpc lacks
decompressor code (at least with my configuration). But the 1.3meg vmlinux
file makes for pretty long turnaround times (I can only upload at 115k at
the moment).
Any help is greatly appreciated ;)
Regards,
Patrick
--
Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR*
Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I'm trying to port Linux to a custom board built around a
virtexII-fpga which features a PPC-405 cpu.
I've downloaded the Montavista 2_4_devel tree, which
Where did you download the Montavista 2_4_devel?
Recently, I need to upgrade the kernel on RPXlite DW.
already has some platform and driver support for the ml300 eval
[snip]
1) Is there any comprehensive documentation / tutorial on how to port
the ppc-linux to new machines? Where does my board specific fixup
stuff go (for example, memory and IRQ declarations and such).
2) What requirements and responsibilities are imposed on the
bootloader? I suspect that I can't use u-boot or something like that,
because we have our own "company-specific" bootloader so that all our
products use the same protocol for firmware updates.
Maybe this is your next problem exits.
3) Is there a way to get a self-decompressing kernel image? ARM linux
provides a zImage which the cpu just has to jump into (with some
registers initialized) and then decompresses vmlinux by itself. Now I
have to use a
ARM Linux can do like this. PPC Liunx also can make
it. :-)
vmlinux file and write it to flash directly, because zImage on powerpc
lacks decompressor code (at least with my configuration). But the
1.3meg vmlinux file makes for pretty long turnaround times (I can only
upload at 115k at the moment).
AFAIK, the key point of decompressing is boot loader
itself. It has NOTHING to do with ppc linux. Both
U-Boot and PlanetCore can do this job well.
Best regards,
Sam
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Peter Ryser <hidden> Date: 2004-08-24 04:14:10
You might want to have a look at
http://direct.xilinx.com/bvdocs/appnotes/xapp765.pdf
It explains on how to get started with Xilinx EDK and MontaVista Linux
Preview Kit on the ML300 board. The steps are pretty much the same for a
custom board.
- Peter
Patrick Huesmann wrote:
Hi,
I'm trying to port Linux to a custom board built around a virtexII-fpga
which features a PPC-405 cpu.
I've downloaded the Montavista 2_4_devel tree, which already has some
platform and driver support for the ml300 eval board, and made a few changes
to the xilinx specific header files to reflect our FPGA design.
Then I changed the tophys macro in include/asm/ppc_asm.h to have a sensible
initial mmu.
#define MY_PHYS_RAM 0x90000000
#define tophys(rd,rs) addis rd,rs,(MY_PHYS_RAM-KERNELBASE)@h;
#define tovirt(rd,rs) addis rd,rs,(KERNELBASE-MY_PHYS_RAM)@h;
My kernel gets past the initial mmu setup, enters the C code and freezes in
the middle of early_init in arch/ppc/kernel/setup.c when (after?) memset_io
is called to zero the BSS region.
I've some experience with porting ARM-Linux but, unfortunately, the PPC port
seems to be significantly different (there are no mach-types and ATAG lists,
for example).
1) Is there any comprehensive documentation / tutorial on how to port the
ppc-linux to new machines? Where does my board specific fixup stuff go (for
example, memory and IRQ declarations and such).
2) What requirements and responsibilities are imposed on the bootloader? I
suspect that I can't use u-boot or something like that, because we have our
own "company-specific" bootloader so that all our products use the same
protocol for firmware updates.
3) Is there a way to get a self-decompressing kernel image? ARM linux
provides a zImage which the cpu just has to jump into (with some registers
initialized) and then decompresses vmlinux by itself. Now I have to use a
vmlinux file and write it to flash directly, because zImage on powerpc lacks
decompressor code (at least with my configuration). But the 1.3meg vmlinux
file makes for pretty long turnaround times (I can only upload at 115k at
the moment).
Any help is greatly appreciated ;)
Regards,
Patrick
From: Peter 'p2' De Schrijver <hidden> Date: 2004-08-24 08:51:18
On Mon, Aug 23, 2004 at 05:17:15PM +0200, Patrick Huesmann wrote:
I'm trying to port Linux to a custom board built around a
virtexII-fpga which features a PPC-405 cpu.
I've downloaded the Montavista 2_4_devel tree, which already has some
platform and driver support for the ml300 eval board, and made a
few changes to the xilinx specific header files to reflect our FPGA
design. Then I changed the tophys macro in include/asm/ppc_asm.h
to have a sensible initial mmu. #define MY_PHYS_RAM 0x90000000
#define tophys(rd,rs) addis rd,rs,(MY_PHYS_RAM-KERNELBASE)@h; #define
tovirt(rd,rs) addis rd,rs,(KERNELBASE-MY_PHYS_RAM)@h;
My kernel gets past the initial mmu setup, enters the C code and
freezes in the middle of early_init in arch/ppc/kernel/setup.c when
(after?) memset_io is called to zero the BSS region.
That's a problem. A lot of the 405 specific kernel code relies on the
fact that main memory is mapped at address 0. It would require quite
some work to make it work on other addresses too.
I've some experience with porting ARM-Linux but, unfortunately, the
PPC port seems to be significantly different (there are no mach-types
and ATAG lists, for example).
Indeed. Although this is supposed to change some day...
1) Is there any comprehensive documentation / tutorial on how to port
the ppc-linux to new machines? Where does my board specific fixup
stuff go (for example, memory and IRQ declarations and such).
I haven't seen one. Most of the board specific fixup stuff resides in
platforms/boardname.[ch]. Look at arch/ppc/platforms/insightv2pro.[ch]
for an example how we did this for the insight V2Pro board.
2) What requirements and responsibilities are imposed on the
bootloader? I suspect that I can't use u-boot or something like that,
because we have our own "company-specific" bootloader so that all our
products use the same protocol for firmware updates.
The bootloader should load the kernel at address 0 and initialize the
registers as follows :
r3 - Board info structure pointer (DRAM, frequency, MAC address, etc.)
r4 - Starting address of the init RAM disk
r5 - Ending address of the init RAM disk
r6 - Start of kernel command line string (e.g. "mem=96m")
r7 - End of kernel command line string
(See also arch/ppc/kernel/head_4xx.S). The board info structure is
defined in asm-ppc/ppcboot.h (struct bd_info).
3) Is there a way to get a self-decompressing kernel image? ARM
linux provides a zImage which the cpu just has to jump into (with
some registers initialized) and then decompresses vmlinux by itself.
Now I have to use a vmlinux file and write it to flash directly,
because zImage on powerpc lacks decompressor code (at least with my
configuration). But the 1.3meg vmlinux file makes for pretty long
turnaround times (I can only upload at 115k at the moment).
Yes. look at arc/ppc/boot/simple for some targets which have a
self-decompressing kernel. (Amongst which is our port to the Insight
V2PRO board).
Any help is greatly appreciated ;)
You're welcome.
Cheers,
Peter (p2).
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Patrick Huesmann <hidden> Date: 2004-08-24 09:14:35
Hi,
A lot of the 405 specific kernel code relies on the
fact that main memory is mapped at address 0. It would require quite
some work to make it work on other addresses too.
You mean that RAM has to start at *physical* address zero? Well, then
perhaps I can convince the hardware guy to change the memory layout. It's a
softcore SDRAM controller, after all ;))
quoted
Where does my board specific fixup stuff go
(for
example, memory and IRQ declarations and such).
Most of the board specific fixup stuff resides in
platforms/boardname.[ch]. Look at arch/ppc/platforms/insightv2pro.[ch]
for an example how we did this for the insight V2Pro board.
Thanks for the suggestions. I'll be looking into that, once I've handled the
low-level stuff.
quoted
2) What requirements and responsibilities are imposed on the bootloader?
The bootloader should load the kernel at address 0 and initialize the
registers as follows (...)
(See also arch/ppc/kernel/head_4xx.S). The board info structure is
defined in asm-ppc/ppcboot.h (struct bd_info).
Thanks, I've already seen that one. Are there any other requirements (cache
flushing, cache turned on/off, interrupts disabled, etc.)?
quoted
3) Is there a way to get a self-decompressing kernel image?
Yes. look at arc/ppc/boot/simple for some targets which have a
self-decompressing kernel. (Amongst which is our port to the Insight
V2PRO board).
Hmm. The denx tutorial states that the bootloader *must* decompress the
kernel. If that's not true (anymore), then I might not have to use u-boot as
second stage bootloader.
Thanks,
Patrick
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Peter 'p2' De Schrijver <hidden> Date: 2004-08-24 09:42:11
On Tue, Aug 24, 2004 at 11:14:35AM +0200, Patrick Huesmann wrote:
quoted
A lot of the 405 specific kernel code relies on the fact that main
memory is mapped at address 0. It would require quite some work to
make it work on other addresses too.
You mean that RAM has to start at *physical* address zero? Well, then
perhaps I can convince the hardware guy to change the memory layout.
It's a softcore SDRAM controller, after all ;))
Yes. That's what I mean. Changing the hardware is probably easier in
this case then adapting the kernel yes :)
Thanks, I've already seen that one. Are there any other requirements
(cache flushing, cache turned on/off, interrupts disabled, etc.)?
Interrupts should be disabled. There is no real cache disable on the
405. You can only mark pages (or 128MB regions when running in
untranslated mode), cacheable or uncacheable. Caches are normally
flushed by the linux startup code, but it doesn't hurt to flush them in
the bootloader.
quoted
quoted
3) Is there a way to get a self-decompressing kernel image?
Yes. look at arc/ppc/boot/simple for some targets which have a
self-decompressing kernel. (Amongst which is our port to the Insight
V2PRO board).
Hmm. The denx tutorial states that the bootloader *must* decompress
the kernel. If that's not true (anymore), then I might not have to use
u-boot as second stage bootloader.
3) Is there a way to get a self-decompressing kernel image?
Yes. look at arc/ppc/boot/simple for some targets which have a
self-decompressing kernel. (Amongst which is our port to the Insight
V2PRO board).
Hmm. The denx tutorial states that the bootloader *must* decompress
the kernel. If that's not true (anymore), then I might not have to use
u-boot as second stage bootloader.
There isn't *MUST* decompress in U-Boot because U-Boot
can boot compressed and unconpressed kernel
respectively.In addition, if using U-Boot as second
stage bootloader,the process couldn't easier than
porting U-Boot on your custom board. I never thought a
so-called boot loader couldn't boot a standard linux
kernel.:-)
Good luck!
Sam
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, Aug 23, 2004 at 05:17:15PM +0200, Patrick Huesmann wrote:
quoted
3) Is there a way to get a self-decompressing kernel image? ARM
linux provides a zImage which the cpu just has to jump into (with
some registers initialized) and then decompresses vmlinux by itself.
[snip]
Yes. look at arc/ppc/boot/simple for some targets which have a
self-decompressing kernel. (Amongst which is our port to the Insight
V2PRO board).
OK, new things learned. But still one point I'd like
to add, that's both U-Boot and PlanetCore convert
linux kernel zImage.embedded image before booting.
U-Boot use mkimage, PlanetCore with dd. This depends
on bootloader.
Best regards,
Sam
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/