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

Dirk Behme
2010-12-21T07:11:32Z

On 21.12.2010 01:46, John Rigby wrote:
> 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.

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