Wolfgang, Albert,
On 03/15/11 20:07, Wolfgang Denk wrote:
Dear "Luca Ceresoli",
In messageLI3YLF$9F2AAC61C7A1BF5365F194AD9137206F@aruba.it you wrote:
I ported U-boot to a custom BeagleBoard-derivative board, which is running fine so far.
Now I'm trying to upgrade from the current codebase (v2010.06) to a more recent one. My custom U-boot stopped booting after merging the ARM relocation code implemented in september 2010 by Heiko Schocher, even though I think I've changed my code where needed.
That is one of the problems you will be facing again and again with out-of-tree ports. As we don't even know your code, we could not even help you if we wanted to.
I understand your point and fully agree.
I'll have to check with my company if I'm allowed to do so now, before the hardware and software are out for sale. Nevertheless, the board will never be publicly available unless one buys a quite expensive product, and I don't think detailed hardware specifications will ever be available (this definitely does not depend on me...). It's a product, not a development board or similar.
Do you think it would be feasible to give support even with such restrictions, if the software were publicly available?
Pardon the question, I'm just trying to understand how the U-boot community does things as I'm pretty new here.
--- a/board/mycompany/myboard/config.mk +++ b/board/mycompany/myboard/config.mk @@ -30,4 +30,4 @@ # (mem base + reserved)
# For use with external or internal boots. -TEXT_BASE = 0x80e80000 +TEXT_BASE = 0x80008000
If you still have such definitions in your code you are still so far away from current top of tree that any comments are in vain as more changes are still to be applied.
[In response to Albert too]
Merging little pieces at a time was my "divide et impera" approach to merge ~1 year of upstream history without facing a huge mountain of merge conflicts, compilation issues and runtime failures all at a time on a codebase that I'm not familiar with. On one hand, it allowed me to learn a bit about U-boot, but I understand it makes it difficult to obtain support.
I'll try the other way around with a big merge-all.
Maintaining out-of-tree ports _is_ a continuing pain. Don't do that. Push your changes upstream in time, i. e. when they are current. Best regards,
Wolfgang Denk
Thanks for the advice, Luca