[PATCH] 83xx: add support for the kmeter1 board.

Heiko Schocher hs at denx.de
Tue Apr 28 14:42:43 EST 2009

Hello Scott,

Scott Wood wrote:
> On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
>> 1) add in the soc node an "errata" node and in this "errata" node
>>    we can add all CPU specific errata as an example the qe_enet10
>>    errata, which above code covers:
> What about errata discovered after the device tree is deployed?

Didn;t know that there are such errata. Ok, this is a problem.

>>         soc8360 at e0000000 {
>> 	[...]
>>                 errata {
>>                         device_type = "errata";
> device_type is deprecated except for a couple of legacy uses.  Please do
> not add new ones.


>>                         compatible = "fsl,mpc83xx_errata";
> To be bound to by an "errata driver"? :-P

Why not ;-) ?

>>                         #address-cells = <1>;
>>                         #size-cells = <1>;
>>                         qe_enet10 at 14a8 {
>>                                 device_type = "errata";
>>                                 compatible = "fsl,mpc83xx_errata_qe_enet10";
>>                                 reg = <0x14a8 0x08>;
> But that register is part of the "QE parallel I/O port" block (even if it
> happens to be undocumented within that block), not part of the "QE ENET10
> erratum" block.  The device tree describes the hardware, not what you
> want to do with it.

Hmm.. isn;t this an errata for a buggy hardware? Why not describing this
in the dts?

> The presence of the erratum itself is indicated by the presence of the
> buggy device, possibly in conjunction with SVR if the device tree is not
> specific enough.

Ah, Ok, that was just an idea ... so, where and how to solve the qe_enet10
errata without using get_immrbase() (and I vote not to solve it as it
actuall is in board specific code, maybe as i proposed in an earlier mail
in the ucc_geth.c driver?)?

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

More information about the Linuxppc-dev mailing list