[U-Boot] OMAP3 Regression after merging ARM relocation code for custom board

Luca Ceresoli luca at lucaceresoli.net
Tue Mar 15 22:41:26 CET 2011


Wolfgang, Albert,

On 03/15/11 20:07, Wolfgang Denk wrote:
> Dear "Luca Ceresoli",
>
> In message<LI3YLF$9F2AAC61C7A1BF5365F194AD9137206F at 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



More information about the U-Boot mailing list