[U-Boot] OMAP3 Regression after merging ARM relocation code for custom board
Hi,
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.
More in detail, my code base works perfectly if merged with the upstream code (from git://git.denx.de/u-boot.git) until the commit before the ARM relocation series: 4fff329 nand_boot_fsl_nfc.c: make "nfc" a "static const" pointer
It stops working when I merge these 3 commits (plus an arbitrarily large amount of the following ones): f1d2b31 ARM: add relocation support e48b7c0 ARM: implement relocation for ARM11 561142a ARM: implement relocation for ARM V7 (OMAP) plus this patch to my code (copied from the Beagle code changes in commit 561142a above):
diff --git a/board/mycompany/myboard/config.mk b/board/mycompany/myboard/config.mk index 150b30c..a9c88d2 100644 --- 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 diff --git a/include/configs/omap3_myboard.h b/include/configs/omap3_myboard.h index c62febd..be0d9a9 100644 --- a/include/configs/omap3_myboard.h +++ b/include/configs/omap3_myboard.h @@ -333,4 +333,9 @@ extern unsigned int boot_flash_sec; extern unsigned int boot_flash_type; #endif
+/* additions for new relocation code, must added to all boards */ +#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* __CONFIG_H */
The result is that U-boot does not print any single character on the serial console, and I'm lost since I can't use a JTAG emulator.
As I am not expert in the low-level U-boot code, I don't know where to look at. Any suggestion would be appreciated.
Here are a few more details that might be relevant.
The board is a BeagleBoard derivative, with the same CPU (OMAP3530, Cortex-A8) and NAND flash chip. The RAM chip is the same model, but we have only one 128 MB chip instead of two. There's also a LAN chip (SMC911x family).
I started my porting from the upstream repository at git://git.denx.de/u-boot.git and created a branch.
Here I added a new board, initially equal to Beagle, then I removed some unwanted features (JFFS2, board detection), added some wanted ones (UBI/UBIFS, LAN driver, CONFIG_CMD_NET) and adapdet the default environment.
I also changed CONFIG_SYS_MALLOC_LEN from 128kB to 1MB, as it was not enough for UBI to work.
Thanks in advance, Luca
Dear "Luca Ceresoli",
In message LI3YLF$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.
--- 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.
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
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
Dear Luca Ceresoli,
In message 4D7FDD06.5080009@lucaceresoli.net you wrote:
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.
This really doesn't matter at all in regards of wether you can push your code upstream to have it maintained with the rest of the mainline code.
Do you think it would be feasible to give support even with such restrictions, if the software were publicly available?
I'm not talking about "publicly available". I'm talking about coe that has been merged into the mainline U-Boot distribution. That's the only code that gets free community support.
Pardon the question, I'm just trying to understand how the U-boot community does things as I'm pretty new here.
It works like other, similar communites, too. Take Linux for example.
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.
Such an approach is painful. Learn a lesson from it. Sync against mainline frequently, eventually even on a daily base, or at least every few days. Use tools (git - like pulling mainline into your repository, or maintaining your code in a brnch that you rebase against mainline).
I'll try the other way around with a big merge-all.
No. Create a branch, and try to rebase your branch.
Best regards,
Wolfgang Denk
Le 15/03/2011 17:46, Luca Ceresoli a écrit :
Hi,
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.
More in detail, my code base works perfectly if merged with the upstream code (from git://git.denx.de/u-boot.git) until the commit before the ARM relocation series: 4fff329 nand_boot_fsl_nfc.c: make "nfc" a "static const" pointer
It stops working when I merge these 3 commits (plus an arbitrarily large amount of the following ones): f1d2b31 ARM: add relocation support e48b7c0 ARM: implement relocation for ARM11 561142a ARM: implement relocation for ARM V7 (OMAP) plus this patch to my code (copied from the Beagle code changes in commit 561142a above):
diff --git a/board/mycompany/myboard/config.mk b/board/mycompany/myboard/config.mk index 150b30c..a9c88d2 100644 --- 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 diff --git a/include/configs/omap3_myboard.h b/include/configs/omap3_myboard.h index c62febd..be0d9a9 100644 --- a/include/configs/omap3_myboard.h +++ b/include/configs/omap3_myboard.h @@ -333,4 +333,9 @@ extern unsigned int boot_flash_sec; extern unsigned int boot_flash_type; #endif
+/* additions for new relocation code, must added to all boards */ +#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE)
- #endif /* __CONFIG_H */
The result is that U-boot does not print any single character on the serial console, and I'm lost since I can't use a JTAG emulator.
As I am not expert in the low-level U-boot code, I don't know where to look at. Any suggestion would be appreciated.
Here are a few more details that might be relevant.
The board is a BeagleBoard derivative, with the same CPU (OMAP3530, Cortex-A8) and NAND flash chip. The RAM chip is the same model, but we have only one 128 MB chip instead of two. There's also a LAN chip (SMC911x family).
I started my porting from the upstream repository at git://git.denx.de/u-boot.git and created a branch.
Here I added a new board, initially equal to Beagle, then I removed some unwanted features (JFFS2, board detection), added some wanted ones (UBI/UBIFS, LAN driver, CONFIG_CMD_NET) and adapdet the default environment.
I also changed CONFIG_SYS_MALLOC_LEN from 128kB to 1MB, as it was not enough for UBI to work.
Thanks in advance, Luca
Hi Luca,
As several fixes were introduced after the ARM relocation commits you are talking about, I would suggest not to try and progressively merge U-boot into your changes, but rather to rebase your branch directly on top of the current master of u-boot or u-boot-arm, so that you have all fixes which followed ARM relocation work.
Amicalement,
participants (3)
-
Albert ARIBAUD -
Luca Ceresoli -
Wolfgang Denk