Re: AW: Submitting patches for Kontron-boards with Freescale processors

From: Kumar Gala
Date: Thu Dec 22 2005 - 10:24:34 EST


On Dec 21, 2005, at 4:56 AM, Claus Gindhart wrote:

Kumar,

Due to your E-Mail i have checked into the linuxppc mailing lists. I am aware now of the restructuring process in the Kernel regarding the flattened device tree for passing parameters from the Bootloader to the Kernel.

Actually all Kontron-PowerPC-Boards, (VME-, CompactPCI- and E²Brain- boards) are equipped with the Kontron NetBootLoader. This Ecos-based bootloader currently passes all parameters to the Kernel via an E²PROM-Device. We have also some custom projects using U- Boot, but our standard products all have the Kontron Bootloader.

The question is now: Will it be a mandatory requirement, that the Bootloader provides the flattened device list, or will it be allowed in future to provide a platform-specific function, which generates the flattened device tree (as we previously did within the embed_config() function, where we built the struct bd_t) ?

It is expected that the boot loader provide a flat device tree to the kernel. I'm not aware of anyone working on a wrapper to provide a flat device tree. Do realize there are tools like DTC that will produce a device tree blob based on an input file. This blob can than be handed to the kernel.

Take a look at:
http://ozlabs.org/git?p=dtc.git;a=summary

and
Documentation/booting-without-of.txt (in DTC) which talks about what arch/powerpc expects from the bootloader.

- kumar


-----Ursprüngliche Nachricht-----
Von: Kumar Gala [mailto:galak@xxxxxxxxxxxxxxxxxxx]
Gesendet: Montag, 19. Dezember 2005 16:07
An: Claus Gindhart
Cc: Linux Kernel List
Betreff: Re: Submitting patches for Kontron-boards with Freescale
processors



On Dec 19, 2005, at 2:07 AM, Claus Gindhart wrote:

Kumar,

in our department we have Linux 2.6 kernel ports for Kontron
embedded computer boards with freescale processors 8245, 405, 8540,
8541, 8347, 8270, ...

We would like to start now to submit all these board supports to
the vanilla kernel.

For the start we would select one of our common boards, e.g. the
one with 8540/8541 processor.

My question is now:
Should we try to provide a patch with all HW-features of the board
supported, or would it be better to start with a minimalistic
patch, and then add support for additional devices onboard (e.g.
IDE, RTC, SuperIO, ...) time by time ?

Or would it be better to provide the full feature set of this board
at one time ?

First, I would recommend posting such queries to the linuxppc lists
(linuxppc-dev@xxxxxxxxxx, linuxppc-embedded@xxxxxxxxxx).

Second, I'm no longer at Freescale so please email me at this address.

Ok, now to your question. In general if a given board port touch
files in arch/ppc/platforms/* than all of that code should be in one
patch. If you are touching anything in drivers/* you need to
separate out those patches and send them to the respective driver
maintainers. If you want to provide a more detailed list of changes
for 8540/8541 I can provide better directions on how to submit patches.

What boot loader are you using for your boards? I ask because for
the 85xx and 83xx subarchitectures I'm trying to limit new board
ports in arch/ppc as we try to transition to arch/powerpc. However,
this requires that the firmware provide a flatten device tree to the
kernel.

Hopefully that gets you a sense and feel free to ask any other
questions.

- kumar


-
To unsubscribe from this list: send the line "unsubscribe linux- kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/