Re: How to port ppc-linux to new custom boards? (virtexII)

Re: How to port ppc-linux to new custom boards? (virtexII)

[Patrick Huesmann]

Hi,

> Where did you download the Montavista 2_4_devel?

via anonymous rsync from montavista server. i followed the instructions at
http://penguinppc.org/dev/kernel.shtml

>> 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).
>
>See the following two valuable docs:
>http://www.denx.de/twiki/bin/view/PPCEmbedded/Introduction
>http://www.denx.de/twiki/bin/view/DULG/Manual

Unfortunately, neither of these docs talks about tailoring the kernel to
custom hardware. They only state that "some changes" have to be applied to
the startup code. I need some more specific information, because I'm not a
expert PPC guru.

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

this means that i also have to port u-boot and use 2 bootloaders in
sequence, or port u-boot's decompressor code to our own bootloader. Sigh.

Arm Linux provides a self-decompressing zImage. I thought it could be
possible to configure the ppc kernel just like that.

Thanx anyway,
Patrick


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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Marc Leeman]

> > Where did you download the Montavista 2_4_devel?

If size is an issue for your distrib, have a look at uclibc [1],
busybox [2] (buildroot [3] and ptxdist [4] for configuring your final
system). When compared to MVL (configured with devrocket), you'll end
up with a much cleaner and smaller system (about half the size).

buildroot is a Makefile based system to setup your cross compilation
environment and creates your target FS.

ptxdist is a kconfig based all but the kitchen sinck approach, haven't
really checked it out but it looks really impressive, supports uclibc
and busybox (IIRC).

A very good general development environment can be found in ELDK [5].

Zhe bootloader is of course das U-Boot [6].

Unless you have very specific requirements, the normal kernel is as good
as a branched version:
$ make ARCH=ppc CROSS_COMPILE=powerpc-linux-
$ make ARCH=ppc CROSS_COMPILE=ppc_82xx-

If you are using GNU/Debian, there is a nice tutorial for creating the
cross packages [7].

Finally, do not overestimate the commercial support, to my experience;
the collaborative mailing lists are often as good if not better to point
you in the correct direction due to the diverse expertises of the ppl on
the list.

[1] http://www.uclibc.org/
[2] http://www.busybox.net/
[3] http://www.pengutronix.de/software/ptxdist_en.html
[4] http://uclibc.org/cgi-bin/cvsweb/buildroot/
[5] http://www.denx.de/ELDK/
[6] http://u-boot.sourceforge.net/
[7] http://people.debian.org/~debacle/cross.html

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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Marius Groeger]

On Tue, 24 Aug 2004, Marc Leeman wrote:

> Finally, do not overestimate the commercial support, to my experience;
> the collaborative mailing lists are often as good if not better to point
> you in the correct direction due to the diverse expertises of the ppl on
> the list.

Correct.

I'd like to add, though, that commercial support is somthing you payed for,
and which you can *claim*, so IMHO you shouldn't underestimate it. A
guaranteed support line can be very critical at certain stages of your
project.

Regards,
Marius

--
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com


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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Marc Leeman]

On Wed, Aug 25, 2004 at 09:34:32AM +0200, Marius Groeger wrote:

> I'd like to add, though, that commercial support is somthing you payed
> for, and which you can *claim*, so IMHO you shouldn't underestimate
> it. A guaranteed support line can be very critical at certain stages
> of your project.

Yeah you're right. Commercial support can help you by putting in more
resources when the problem is quite obvious (newly porting) and they do
have expertise in that particular area. If the problem is not that
obvious, the replies get very slow and very vague.

I'm just being negative (perhaps a bit too much) after having a meeting
last week with a commercial representative and claimed much more credit
where none or little was due to their company in an effort to accept
their licensing which resembles a typical hammer and anvil situation.

I just like the mailing list discussions: I think they are much more
productive in the middle to long run if you want to learn and are not
focussed on your little backyard.

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

Re: How to port ppc-linux to new custom boards? (virtexII)

[David Ho]

> > Finally, do not overestimate the commercial support, to my experience;
> > the collaborative mailing lists are often as good if not better to
point
> > you in the correct direction due to the diverse expertises of the ppl
on
> > the list.
>
> Correct.
>
> I'd like to add, though, that commercial support is somthing you payed
for,
> and which you can *claim*, so IMHO you shouldn't underestimate it. A
> guaranteed support line can be very critical at certain stages of your
> project.
>

Sorry to stick my nose in your discussion, but I have a strong opinion on
commerial support.  Working in a small company, we have never gotten the
level of commitment we would expect from companies like ISI (vendor of
pSOS) and Timesys.  You can get the basic installation support fine.  But
when you need to get into the nitty gritty detail their value is a lot less
compared to mailing lists.

The way I see it is being large commercial OS vendor that they are, they
seem to funnel their resource to the big customers who are willing to pay
the big bucks to get stuff done.

When choosing commercial support, one critical factor is their customer
base.  Big fish don't go after the tiny ticks in the sea, they go for
seals.  And you really have to find the right sized OS vender to give you
the attention you need.

Regards,
David Ho
Nanometrics Inc.


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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Peter Vandenabeele]

On Wed, Aug 25, 2004 at 09:52:58AM -0400, David Ho wrote:
> > > Finally, do not overestimate the commercial support, to my experience;
> > > the collaborative mailing lists are often as good if not better to point
> > > you in the correct direction due to the diverse expertises of the ppl on
> > > the list.

I would be very careful with generalisation ...

> > Correct.
> >
> > I'd like to add, though, that commercial support is somthing you payed for,
> > and which you can *claim*, so IMHO you shouldn't underestimate it. A
> > guaranteed support line can be very critical at certain stages of your
> > project.
>
> Sorry to stick my nose in your discussion, but I have a strong opinion on
> commerial support.  Working in a small company, we have never gotten the
> level of commitment we would expect from companies like ISI (vendor of
> pSOS) and Timesys.  You can get the basic installation support fine.  But
> when you need to get into the nitty gritty detail their value is a lot less
> compared to mailing lists.

Would the base problem not be that the classic model of "1-year support for a
fixed fee" creates a false illusion ? How can you expect a support company to
get into intensive research of a complex problem if this just creates additional
cost, but no additional revenue ? For a big customer, that is paying hefty
yearly fees, it is obvious to do this investment, but for a small customer ...

> The way I see it is being large commercial OS vendor that they are, they
> seem to funnel their resource to the big customers who are willing to pay
> the big bucks to get stuff done.

Seems very logical. Those who pay extra for extra work, will get extra
work delivered. Those who rely on the 1-year support for a fixed fee
will get what remains. IMHO this is best resolved with just charging
hourly: you pay for what you actually got ...

> When choosing commercial support, one critical factor is their customer
> base.  Big fish don't go after the tiny ticks in the sea, they go for
> seals.  And you really have to find the right sized OS vender to give you
> the attention you need.

I have seen a number of "small" support companies deliver excellent
support to e.g. large semiconductor companies.

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

Handling of cascaded interrupt controllers

[Jeff Domogala]

I have a Marvell GT-64260A based custom board.  The interrupt line out of
the GT is cascaded into a CPLD, which also has 15 other interrupt sources.
The way I handled this situation in VxWorks was to define interrupt vectors
for the CPLD interrupts, minus the one cascaded interrupt from the GT (so 15
interrupt vectors), then use 64 more interrupt vectors for the GT
interrupts.  The cascaded interrupt would then call the GT's normal
interrupt handler to determine the interrupt source.

Is there a way to define two interrupt controller devices in this fashion in
Linux, where a single interrupt from one controller (the CPLD) can somehow
manage multiple interrupts for the other controller (the GT), with all
interrupt sources having unique vectors?  This appears to be identical to a
cascaded pair of 8259 controllers.  Or, do I do something similar to my
VxWorks implementation and create one interrupt controller device with
unique interrupt vectors for all sources except the cascaded CPLD interrupt
for the GT?

Regards,

Jeff


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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Marc Leeman]

> cost, but no additional revenue ? For a big customer, that is paying
> hefty yearly fees, it is obvious to do this investment, but for a
> small customer ...

Two motivations play here with the fixed fee:
1. We already got the money, so why should we bother?
2. We should at least bother enough or make it appear so, so we can
motivate our fees for next year.

Oh, what a tangled web we weave...

> Seems very logical. Those who pay extra for extra work, will get extra
> work delivered. Those who rely on the 1-year support for a fixed fee
> will get what remains. IMHO this is best resolved with just charging
> hourly: you pay for what you actually got ...

Then you are in a consultancy like scenario. Let's just hope you wont
pay full charges for 3 engineers: 1 experienced and 2 trainees; as some
big IT consultancy firms tend to do... :)

Both have their disadvantages, but if you can trust the company in the
2nd option, I would tend to agree that this might offer you better value
for your money.

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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Oliver Fuchs]

Hi,

From:           	"Patrick Huesmann" <tricknology@gmx.de>

> Unfortunately, neither of these docs talks about tailoring the kernel to
> custom hardware. They only state that "some changes" have to be applied to
> the startup code. I need some more specific information, because I'm not a
> expert PPC guru.
>
I had to get up the kernel on two boards (MPC857T and MPC8280)
recently. I use the ELDK3.0 with the kernel 2.4.24 shipped with it.

I had to modify the following files:
arch/ppc/config.in
	machine type (my board) added
arch/ppc/boot/simple/embed_config.c
	there is a function emebd_config() for every board selected by
	#ifdefs; so I added one for my board
arch/ppc/platforms
	there are header files for every board; so I added one for my board
include/asm-ppc/mpc8xx.h
	#include <platforms/myboard.h> added; selected by #ifdef

This was enough to get the kernel up with a serial i/f.
It may be necessary to modify the ethernet driver a little bit to
adapt it to your pin configuration.

Flash support was no problem for the CFI chips on the boards.

I'm just a newbie too, so don't kill me if there is something missed
or wrong.

HTH,
Oliver

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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Peter Ryser]

>this means that i also have to port u-boot
>
U-Boot supports the ML300 board, again, with MLD technology (i.e. an
automatic way to setup address maps and number of peripherals directly
out of the EDK project). Read the README for the ML300 board in the
u-boot documentation directory for more information.

- Peter


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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Patrick Huesmann]

Hi,

> > Thank you very much. This is exactly the type of info I'm looking for.
> > Did you manage to get a self-decompressing zImage, or is this ALWAYS the
> > bootloader's job on ppc-linux?
> I guess in my case (U-Boot) it is the job of the bootloader.
> May be you have to add the decompressing code to your bootloader.
> This seems to be not so complicated for the code is available.
> Download the U-Boot sources and look for the function gunzip() within
> common/cmd_bootm.c

In the meantime, I managed to build a self-decompressing zImage. It is
fairly easy, the board type has to be added to the arch/ppc/boot/simple
Makefile and the zImage is then generated by using dd to strip the ELF
headers off the zvmlinux file. (There are already examples for this in the
Makefile).

BTW: The zImage is *MANDATORY* if there is no standard bootloader used,
because embed_config() sets up the board info structure and sets up some
essential magic cache stuff. I spent a few days just messing around,
wondering why I got strange errors and unreproducable behaviour. Eventually,
I found out that the cache was b0rken because I didn't do the initial cache
setup thing ;)

Thanks again to all folks who replied to my thread,
Patrick


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

How to port ppc-linux to new custom boards? (virtexII)

[Patrick Huesmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2088 bytes --]


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/

Re: How to port ppc-linux to new custom boards? (virtexII)

[Song Sam]

Patrick Huesmann <tricknology@gmx.de> 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

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

See the following two valuable docs:

http://www.denx.de/twiki/bin/view/PPCEmbedded/Introduction

http://www.denx.de/twiki/bin/view/DULG/Manual

> 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/

Re: How to port ppc-linux to new custom boards? (virtexII)

[Peter Ryser]

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


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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Peter 'p2' De Schrijver]

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/

Re: How to port ppc-linux to new custom boards? (virtexII)

[Patrick Huesmann]

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

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

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

> > 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/

Re: How to port ppc-linux to new custom boards? (virtexII)

[Peter 'p2' De Schrijver]

On Tue, Aug 24, 2004 at 11:14:35AM +0200, Patrick Huesmann wrote:
>
> > 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.

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

Cheers,

Peter (p2).

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

Re: How to port ppc-linux to new custom boards? (virtexII)

[Song Sam]

Patrick Huesmann <tricknology@gmx.de> wrote£º

> > > 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/

Re: How to port ppc-linux to new custom boards? (virtexII)

[Song Sam]

Peter 'p2' De Schrijver <p2@mind.be> wrote£º
>
> On Mon, Aug 23, 2004 at 05:17:15PM +0200, Patrick Huesmann wrote:

> > 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/