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

[Dirk Behme]

On 21.12.2010 01:46, John Rigby wrote:
> On Mon, Dec 20, 2010 at 5:25 PM, John Rigby<john.rigby at linaro.org>  wrote:
>> On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler<holler at 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.

Just to not loose the overview:

This is fixed by your patch

http://patchwork.ozlabs.org/patch/76250/

?

But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional 
ldrb    r3, [r3]) is still open? Has anybody tried to replace it with 
a nop in the binary to be sure this is the root cause?

Thanks

Dirk