[U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

John Rigby
2010-12-21T00:46:29Z

On Mon, Dec 20, 2010 at 5:25 PM, John Rigby <john.rigby@linaro.org> wrote:
> On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>
>> There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
>> your hack, my kernel doesn't boot. Using gcc 4.3.5 and the same source to
>> compile u-boot the kernel comes up. Here is the output for the non-working
>> u-boot:
>>
>> ----------------
>> U-Boot 2010.12-rc3-00015-g3ae9687-dirty (Dec 20 2010 - 18:01:41, gcc 4.5.1)
>>
>> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
>> OMAP3 Beagle board + LPDDR/NAND
>> I2C: ? ready
>> DRAM: ?256 MiB
>> NAND: ?256 MiB
>> MMC: ? OMAP SD/MMC: 0
>> In: ? ?serial
>> Out: ? serial
>> Err: ? serial
>> Beagle Rev C4
>> timed out in wait_for_pin: I2C_STAT=0
>> No EEPROM on expansion board
>> Die ID #062a000400000000040365fa16019019
>> Hit any key to stop autoboot: ?0
>> reading boot.scr
>>
>> 422 bytes read
>> Running bootscript from mmc ...
>> ## Executing script at 82000000
>> reading uImage
>>
>> 2419940 bytes read
>> Booting from mmc ...
>> ## Booting kernel from Legacy Image at 82000000 ...
>> ? Image Name: ? Linux-2.6.37-rc5-beagleboard-000
>> ? Image Type: ? ARM Linux Kernel Image (uncompressed)
>> ? Data Size: ? ?2419876 Bytes = 2.3 MiB
>> ? Load Address: 80008000
>> ? Entry Point: ?80008000
>> ? Verifying Checksum ... OK
>> ? Loading Kernel Image ... OK
>> OK
>> ----------------
>>
>> Nothing else.
>>
>> Regards,
>>
>> Alexander
>>
>
> Yes, you are correct, I see the same here with 4.5.2. ?I noticed that
> bd did not have correct values of machine type and boot params:
>
> bd address ?= 0x8FF24FE0
> arch_number = 0xFF0084FF
> boot_params = 0xBB2000FE
> DRAM bank ? = 0x00000000
> -> start ? ?= 0x80000000
> -> size ? ? = 0x08000000
> DRAM bank ? = 0x00000001
> -> start ? ?= 0x88000000
> -> size ? ? = 0x08000000
> baudrate ? ?= 115200 bps
> TLB addr ? ?= 0x8FFF0000
> relocaddr ? = 0x8FF85000
> reloc off ? = 0x0FF7D000
> irq_sp ? ? ?= 0x8FF24F68
> sp start ? ?= 0x8FF24F60
> FB base ? ? = 0x00000000
>
> If we then look at board_init in beagle.c the problem is obvious:
>
> 800331ac <board_init>:
> 800331ac: ? ? ? e92d4008 ? ? ? ?push ? ?{r3, lr}
> 800331b0: ? ? ? ebff5a74 ? ? ? ?bl ? ? ?80009b88 <gpmc_init>
> 800331b4: ? ? ? e3a00000 ? ? ? ?mov ? ? r0, #0
> 800331b8: ? ? ? e5983000 ? ? ? ?ldr ? ? r3, [r8]
> 800331bc: ? ? ? e5983000 ? ? ? ?ldr ? ? r3, [r8]
> 800331c0: ? ? ? e8bd8008 ? ? ? ?pop ? ? {r3, pc}
>

Apparently this is a known issue mentioned in README:

NOTE: DECLARE_GLOBAL_DATA_PTR must be used with file-global scope,
or current versions of GCC may "optimize" the code too much.

With this fix I can boot again:

diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index d9b6f01..c066d6e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -51,6 +51,8 @@

#define BEAGLE_NO_EEPROM 0xffffffff

+DECLARE_GLOBAL_DATA_PTR;
+
static struct {
unsigned int device_vendor;
unsigned char revision;
@@ -66,8 +68,6 @@ static struct {
*/
int board_init(void)
{
- DECLARE_GLOBAL_DATA_PTR;
-
gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
/* board id for Linux */
gd->bd->bi_arch_number = MACH_TYPE_OMAP3_BEAGLE;

Please let me know if you find any other problems.

br,

John