[U-Boot] Cleaning up new port

[U-Boot] Cleaning up new port

[Remco Poelstra]

Hi all,

I've finished my port of U-boot 2008.10 to the LPC2468. I've based my 
port on code by Embedded Artists, which was based on U-boot 1.1.6.
The LPC2468 is an ARM processor with build in peripherals, so I need to 
divide my code into LPC2468 generic part and a part for my board only 
(which is not to be published). I have however no clue on how to do 
that. What code should belong where?
Is there any documentation on the exact code structure of U-boot? Is 
anyone here interested in LPC2468 support and willing to offer some help?

Kind regards,

Remco Poelstra

[U-Boot] Cleaning up new port

[Wolfgang Denk]

Dear Remco Poelstra,

In message <49BF91D5.2030602@duran-audio.com> you wrote:
> 
> I've finished my port of U-boot 2008.10 to the LPC2468. I've based my 
> port on code by Embedded Artists, which was based on U-boot 1.1.6.
> The LPC2468 is an ARM processor with build in peripherals, so I need to 
> divide my code into LPC2468 generic part and a part for my board only 
> (which is not to be published). I have however no clue on how to do 

Not pubslishing your code would be a stupid thing to do. Are you aware
how quickly out-of-mainline code rots? You are already two releases
behind against current mainline, and a lot of changes have already
been queued up in the "next" branch for the next release. 

Try to forward port your stuff to the "next" branch (you will have to
do that to submit any patches), and then think again if it makes sense
for you to maintain an out-of-tree port.  It doesn't.

> that. What code should belong where?
> Is there any documentation on the exact code structure of U-boot? Is 
> anyone here interested in LPC2468 support and willing to offer some help?

Apply common sense. Then submit your patches. We  will  tell  you  if
they  fit.  Note  that  so  far there is no LPC2468 support in U-Boot
mainline, so you must provide some complete working  board  port,  or
there would be code which cannot even be compiled, and we don't allow
that.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are some things worth dying for.
	-- Kirk, "Errand of Mercy", stardate 3201.7

[U-Boot] Cleaning up new port

[Remco Poelstra]

Wolfgang Denk schreef:
> In message <49BF91D5.2030602@duran-audio.com> you wrote:
>> I've finished my port of U-boot 2008.10 to the LPC2468. I've based my 
>> port on code by Embedded Artists, which was based on U-boot 1.1.6.
>> The LPC2468 is an ARM processor with build in peripherals, so I need to 
>> divide my code into LPC2468 generic part and a part for my board only 
>> (which is not to be published). I have however no clue on how to do 
> 
> Not pubslishing your code would be a stupid thing to do. Are you aware
> how quickly out-of-mainline code rots? You are already two releases
> behind against current mainline, and a lot of changes have already
> been queued up in the "next" branch for the next release. 

I fully understand. The problem is that there is a special Ethernet PHY 
on the board which is under a NDA, so I cannot publish code surrounding 
it. I can publish the general part of the ethernet driver.

> Try to forward port your stuff to the "next" branch (you will have to
> do that to submit any patches), and then think again if it makes sense
> for you to maintain an out-of-tree port.  It doesn't.
> 
>> that. What code should belong where?
>> Is there any documentation on the exact code structure of U-boot? Is 
>> anyone here interested in LPC2468 support and willing to offer some help?
> 
> Apply common sense. Then submit your patches. We  will  tell  you  if
> they  fit.  Note  that  so  far there is no LPC2468 support in U-Boot
> mainline, so you must provide some complete working  board  port,  or
> there would be code which cannot even be compiled, and we don't allow
> that.

I see, I will provide a working example.

Regards,

Remco Poelstra

[U-Boot] Cleaning up new port

[Wolfgang Denk]

Dear Remco Poelstra,

In message <49BF9EA5.5040805@duran-audio.com> you wrote:
>
> I fully understand. The problem is that there is a special Ethernet PHY 
> on the board which is under a NDA, so I cannot publish code surrounding 
> it. I can publish the general part of the ethernet driver.

So you cannot ever give anybody else a binary of your code or a board
whith this code installed. Keep in mind that U-Boot is under GPL, and
GPL violations are not accepted.

> I see, I will provide a working example.

Probably exclude the whole network support part from your code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain off-line, please wait.

[U-Boot] Cleaning up new port

[Jerry Van Baren]

Hi Remco,

Wolfgang Denk wrote:
> Dear Remco Poelstra,
> 
> In message <49BF9EA5.5040805@duran-audio.com> you wrote:
>> I fully understand. The problem is that there is a special Ethernet PHY 
>> on the board which is under a NDA, so I cannot publish code surrounding 
>> it. I can publish the general part of the ethernet driver.
> 
> So you cannot ever give anybody else a binary of your code or a board
> whith this code installed. Keep in mind that U-Boot is under GPL, and
> GPL violations are not accepted.

You should check if the PHY is already supported under linux.  You 
should also see if it is really necessary to use the PHY's Sooper 
Seecrit IP Magic Registers(R) for basic functionality.  Theoretically, 
all the necessary functionality of the PHY is available through just the 
commonly known (standard and possibly "defacto standard") registers.

Even NDAs are (should be) realistic in that they don't try to restrict 
you from using publicly available information, and PHYs implement a 
publicly available standard.

If the PHY isn't already supported by a GPLed driver and using the 
Sooper Seecrit registers is necessary, I would suggest Remco's Lawyer 
Department work with the PHY provider's Lawyer Department.  Many 
component suppliers are getting clued in that strict NDAs that prevent 
use in GPLed programs is extremely counterproductive to selling their 
parts... limiting their market to just proprietary OSes is not in their 
best interests.

I understand many component manufacturers don't have a problem with 
releasing GPLed drivers for their parts as long as you don't replicate 
their user's manual as comments in the driver.  You need permission to 
have sufficient comments and sufficient definition that someone reading 
the code understands what is happening.  Magic numbers slammed into 
magic registers is not acceptable in GPLed drivers (IMHO).

>> I see, I will provide a working example.
> 
> Probably exclude the whole network support part from your code.

...or, preferably, get permission from the PHY supplier.

> Best regards,
> 
> Wolfgang Denk

Best regards,
gvb