diff mbox

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

Message ID LI3YLF$9F2AAC61C7A1BF5365F194AD9137206F@aruba.it
State Not Applicable
Delegated to: Sandeep Paulraj
Headers show

Commit Message

Luca Ceresoli March 15, 2011, 4:46 p.m. UTC 
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):



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

Comments

Wolfgang Denk March 15, 2011, 7:07 p.m. UTC | #1 
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
Albert ARIBAUD March 15, 2011, 7:16 p.m. UTC | #2 
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,
Luca Ceresoli March 15, 2011, 9:41 p.m. UTC | #3 
Wolfgang, Albert,

On 03/15/11 20:07, Wolfgang Denk wrote:
> 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.
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
Wolfgang Denk March 15, 2011, 9:59 p.m. UTC | #4 
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
diff mbox

Patch

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