[U-Boot] Working on u-boot on panda board.

[U-Boot] Working on u-boot on panda board.

[Gilles Chanteperdrix]

Hi,

I would like to make some changes to u-boot on pandaboard. Sometimes in
the past, in u-boot, I could "loadb" a new u-boot binary, then "go" to
it, and the new version of u-boot would start. This was far from
perfect, but it made testing small changes possible. This also works
with the version of u-boot provided on the pandaboard community site.

The magic which made this possible was in the "start.S" file, I see that
the code changed, but there still seems to be a relocation (somewhat
more complicated, since it handles ELF relocations), so it seems it
should work.

So my question is: is this "loadb+go" method still supposed to be
working, and only broken, somehow, on pandaboard? Or is it no longer
supposed to be working?

Regards.

-- 
                                                                Gilles.

[U-Boot] Working on u-boot on panda board.

[Aneesh V]

Hi Gilles,

On Thursday 17 March 2011 06:13 PM, Gilles Chanteperdrix wrote:
>
> Hi,
>
> I would like to make some changes to u-boot on pandaboard. Sometimes in
> the past, in u-boot, I could "loadb" a new u-boot binary, then "go" to
> it, and the new version of u-boot would start. This was far from
> perfect, but it made testing small changes possible. This also works
> with the version of u-boot provided on the pandaboard community site.
>
> The magic which made this possible was in the "start.S" file, I see that
> the code changed, but there still seems to be a relocation (somewhat
> more complicated, since it handles ELF relocations), so it seems it
> should work.
>
> So my question is: is this "loadb+go" method still supposed to be
> working, and only broken, somehow, on pandaboard? Or is it no longer
> supposed to be working?

Couple of things you might want to consider.
* According to the new relocation scheme u-boot should start running
from the address that it is linked to. You must load it to
CONFIG_SYS_TEXT_BASE
* Data cache enabled in U-Boot could be a problem. You will end up
having cache coherency issues unless you flush the caches after loadb.
Better keep them disabled using CONFIG_SYS_NO_DCACHE

>
> Regards.
>

[U-Boot] Working on u-boot on panda board.

[Gilles Chanteperdrix]

Aneesh V wrote:
> Hi Gilles,
> 
> On Thursday 17 March 2011 06:13 PM, Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I would like to make some changes to u-boot on pandaboard. Sometimes in
>> the past, in u-boot, I could "loadb" a new u-boot binary, then "go" to
>> it, and the new version of u-boot would start. This was far from
>> perfect, but it made testing small changes possible. This also works
>> with the version of u-boot provided on the pandaboard community site.
>>
>> The magic which made this possible was in the "start.S" file, I see that
>> the code changed, but there still seems to be a relocation (somewhat
>> more complicated, since it handles ELF relocations), so it seems it
>> should work.
>>
>> So my question is: is this "loadb+go" method still supposed to be
>> working, and only broken, somehow, on pandaboard? Or is it no longer
>> supposed to be working?
> 
> Couple of things you might want to consider.
> * According to the new relocation scheme u-boot should start running
> from the address that it is linked to. You must load it to
> CONFIG_SYS_TEXT_BASE

You mean the address where u-boot is currently loaded? But that will not
work, right? I mean, it would override the current u-boot while it is
currently running.

I do not really understand this answer, what does it mean? The
relocation code does not work if the address it is starting from is not
CONFIG_SYS_TEXT_BASE? What if I reinsert the memcpy in start.S which
copies to CONFIG_SYS_TEXT_BASE?

> * Data cache enabled in U-Boot could be a problem. You will end up
> having cache coherency issues unless you flush the caches after loadb.
> Better keep them disabled using CONFIG_SYS_NO_DCACHE

Ok, that is not really an issue for development.

-- 
					    Gilles.

[U-Boot] Working on u-boot on panda board.

[Aneesh V]

On Thursday 17 March 2011 07:14 PM, Gilles Chanteperdrix wrote:
> Aneesh V wrote:
>> Hi Gilles,
>>
>> On Thursday 17 March 2011 06:13 PM, Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> I would like to make some changes to u-boot on pandaboard. Sometimes in
>>> the past, in u-boot, I could "loadb" a new u-boot binary, then "go" to
>>> it, and the new version of u-boot would start. This was far from
>>> perfect, but it made testing small changes possible. This also works
>>> with the version of u-boot provided on the pandaboard community site.
>>>
>>> The magic which made this possible was in the "start.S" file, I see that
>>> the code changed, but there still seems to be a relocation (somewhat
>>> more complicated, since it handles ELF relocations), so it seems it
>>> should work.
>>>
>>> So my question is: is this "loadb+go" method still supposed to be
>>> working, and only broken, somehow, on pandaboard? Or is it no longer
>>> supposed to be working?
>>
>> Couple of things you might want to consider.
>> * According to the new relocation scheme u-boot should start running
>> from the address that it is linked to. You must load it to
>> CONFIG_SYS_TEXT_BASE
>
> You mean the address where u-boot is currently loaded? But that will not
> work, right? I mean, it would override the current u-boot while it is
> currently running.
>
> I do not really understand this answer, what does it mean? The
> relocation code does not work if the address it is starting from is not
> CONFIG_SYS_TEXT_BASE? What if I reinsert the memcpy in start.S which
> copies to CONFIG_SYS_TEXT_BASE?

Here is my understanding:
Eearlier the memcpy was done very early in start.S(before board_init_f)
and everything until that point was position independent. Copy was done
*to* CONFIG_SYS_TEXT_BASE

Now, this memcpy has been removed and we assume that we start from
CONFIG_SYS_TEXT_BASE. After board_init_f we copy the image *from*
CONFIG_SYS_TEXT_BASE to the end of available memory and do ELF
relocation. board_init_f will crash unless you are running from
CONFIG_SYS_TEXT_BASE

Since U-Boot is relocated to the end of available memory you will not
likely over-write existing U-Boot if you copy to CONFIG_SYS_TEXT_BASE,
certainly not on Panda with 1GB memory.

Re-inserting the memcpy may not be necessary I believe.
>
>> * Data cache enabled in U-Boot could be a problem. You will end up
>> having cache coherency issues unless you flush the caches after loadb.
>> Better keep them disabled using CONFIG_SYS_NO_DCACHE
>
> Ok, that is not really an issue for development.
>

[U-Boot] Working on u-boot on panda board.

[Gilles Chanteperdrix]

Aneesh V wrote:
> Hi Gilles,
> 
> On Thursday 17 March 2011 06:13 PM, Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I would like to make some changes to u-boot on pandaboard. Sometimes in
>> the past, in u-boot, I could "loadb" a new u-boot binary, then "go" to
>> it, and the new version of u-boot would start. This was far from
>> perfect, but it made testing small changes possible. This also works
>> with the version of u-boot provided on the pandaboard community site.
>>
>> The magic which made this possible was in the "start.S" file, I see that
>> the code changed, but there still seems to be a relocation (somewhat
>> more complicated, since it handles ELF relocations), so it seems it
>> should work.
>>
>> So my question is: is this "loadb+go" method still supposed to be
>> working, and only broken, somehow, on pandaboard? Or is it no longer
>> supposed to be working?
> 
> Couple of things you might want to consider.
> * According to the new relocation scheme u-boot should start running
> from the address that it is linked to. You must load it to
> CONFIG_SYS_TEXT_BASE
> * Data cache enabled in U-Boot could be a problem. You will end up
> having cache coherency issues unless you flush the caches after loadb.
> Better keep them disabled using CONFIG_SYS_NO_DCACHE

It works like a charm. Thanks !

-- 
                                                                Gilles.