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)

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

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