[U-Boot] new board with common code
Hi
I'm adding a new board. It's very similar to freescale's P2020DS, that's why I used this code as starting point. The problem is now that it still uses some code from board/freescale/common. At the first try this didn't get built and therefore I get link errors. What's the preferred way in this case?
- Is it allowed to use sources inside another board/vendor? - Is it better to link to it or should I just copy the files into our vendor or board directory? - If it's okay to link to objects from another place, how can I adjust the makefiles/config.mk so the freescale's common lib is built as well? I know makefiles but u-boot is quite high level usage.
Once we have it adjusted and running I will create a patch to have it added to the official version.
Thanks
bye Fabi
Dear Fabian Cenedese,
In message 5.2.0.9.1.20110114115035.036b5778@localhost you wrote:
I'm adding a new board. It's very similar to freescale's P2020DS, that's why I used this code as starting point. The problem is now that it still uses some code from board/freescale/common. At the first try this didn't get built and therefore I get link errors. What's the preferred way in this case?
- Is it allowed to use sources inside another board/vendor?
It is allowed, but not recommended. You are running the risk that the board vendor may make arbitrary changes to his board code, which may work fine for him, but break your board. And you cannot even blame him, because he probably is not even aware that this code gets used by others who rely on it.
It is recommended to move such code to a common directory.
- Is it better to link to it or should I just copy the files into our vendor or board directory?
Please do not copy any files. Duplication of code is the worst that can be done in such a szenario.
- If it's okay to link to objects from another place, how can I adjust the makefiles/config.mk so the freescale's common lib is built as well? I know makefiles but u-boot is quite high level usage.
Before we go into details we should define a strategy. Can you please be specific: which exact files are you talking about?
Then we can dicuss with the Freescale guys how to handle this situation.
Best regards,
Wolfgang Denk
On Jan 14, 2011, at 5:39 AM, Wolfgang Denk wrote:
Dear Fabian Cenedese,
In message 5.2.0.9.1.20110114115035.036b5778@localhost you wrote:
I'm adding a new board. It's very similar to freescale's P2020DS, that's why I used this code as starting point. The problem is now that it still uses some code from board/freescale/common. At the first try this didn't get built and therefore I get link errors. What's the preferred way in this case?
- Is it allowed to use sources inside another board/vendor?
It is allowed, but not recommended. You are running the risk that the board vendor may make arbitrary changes to his board code, which may work fine for him, but break your board. And you cannot even blame him, because he probably is not even aware that this code gets used by others who rely on it.
It is recommended to move such code to a common directory.
- Is it better to link to it or should I just copy the files into our
vendor or board directory?
Please do not copy any files. Duplication of code is the worst that can be done in such a szenario.
- If it's okay to link to objects from another place, how can I
adjust the makefiles/config.mk so the freescale's common lib is built as well? I know makefiles but u-boot is quite high level usage.
Before we go into details we should define a strategy. Can you please be specific: which exact files are you talking about?
Then we can dicuss with the Freescale guys how to handle this situation.
Agreed, if we know what code is common we could see about how best to refactor it for sharing.
- k
I'm adding a new board. It's very similar to freescale's P2020DS, that's why I used this code as starting point. The problem is now that it still uses some code from board/freescale/common. At the first try this didn't get built and therefore I get link errors. What's the preferred way in this case?
- Is it allowed to use sources inside another board/vendor?
It is allowed, but not recommended. You are running the risk that the board vendor may make arbitrary changes to his board code, which may work fine for him, but break your board. And you cannot even blame him, because he probably is not even aware that this code gets used by others who rely on it.
It is recommended to move such code to a common directory.
- Is it better to link to it or should I just copy the files into our vendor or board directory?
Please do not copy any files. Duplication of code is the worst that can be done in such a szenario.
- If it's okay to link to objects from another place, how can I adjust the makefiles/config.mk so the freescale's common lib is built as well? I know makefiles but u-boot is quite high level usage.
Before we go into details we should define a strategy. Can you please be specific: which exact files are you talking about?
One thing was pixis, but as we don't have that FPGA I could remove all references to it. Also missing was the eeprom so I got a link error for mac_read_from_eeprom. We mainly want to use U-Boot to initialize the CPU and DRAM. As this is a PCIe-card for the PC we can then download all other things we need. So I could also remove the EEPROM support.
I cleaned the config file up and removed things we don't have. I can now build for my board without using anything from freescale/common, so the problem is solved for now. I will think about it if we need to add something and the error comes up again.
Thanks for your help.
bye Fabi
On Jan 14, 2011, at 10:12 AM, Fabian Cenedese wrote:
Before we go into details we should define a strategy. Can you please be specific: which exact files are you talking about?
One thing was pixis, but as we don't have that FPGA I could remove all references to it. Also missing was the eeprom so I got a link error for mac_read_from_eeprom. We mainly want to use U-Boot to initialize the CPU and DRAM. As this is a PCIe-card for the PC we can then download all other things we need. So I could also remove the EEPROM support.
I cleaned the config file up and removed things we don't have. I can now build for my board without using anything from freescale/common, so the problem is solved for now. I will think about it if we need to add something and the error comes up again.
Thanks for your help.
bye Fabi
Ok, I'd be surprised if you need anything in freescale/common
- k
participants (3)
-
Fabian Cenedese -
Kumar Gala -
Wolfgang Denk