Skip to contentSkip to conversation

Working on u-boot on panda board.

U-Boot Gilles Chanteperdrix 2 participants 5 messages Mar 17, 2011

lore
Share & tools
lore
#0 lore raw

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.

Signature · 1 line
                                                                Gilles.
#1 lore raw

Hi Gilles,

Quoted 9 lines · 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.

Quoted 8 lines

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

Quoted 3 lines

Regards.

#2 lore raw
Quoted 16 lines · Aneesh V

Hi Gilles,

Quoted 13 lines · 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.

Quoted 8 lines
Quoted 3 lines

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?

Quoted 3 lines

* 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.

Signature · 1 line
					    Gilles.
#3 lore raw
Quoted 26 lines · Gilles Chanteperdrix
Quoted 16 lines · Aneesh V

Hi Gilles,

Quoted 13 lines · 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.

Quoted 8 lines
Quoted 3 lines

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

Quoted 8 lines

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.

Quoted 7 lines
Quoted 4 lines

* 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.

#4 lore raw
In reply to Aneesh V
Quoted 20 lines · Aneesh V

Hi Gilles,

Quoted 8 lines · 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.

Quoted 8 lines

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?

Quoted 7 lines

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 !

Signature · 1 line
                                                                Gilles.