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

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