BrianSidebotham/arm-tutorial-rpi

Part-1 doesn't work on RPI-2

Closed this issue · 15 comments

Hi Brian, thank you for your great work on this tutorial !
I'm quite new to Raspberry Pi programming and I apologize in advance if I misunderstood something in your tutorial.

I tried to run your code on my Raspberry PI 2 and the LED remains off. I tried your pre-build binary which is not working for me. I also tried to build the code for Rasperry PI (the old one) and it's working great.

I also noticed something strange :

The following is working on the RPI2 is waiting a few seconds before turning on the LED (which is normal) :

while(1)
{
for(tim = 0; tim < 5000000; tim++);
gpio[LED_GPSET] = (1 << LED_GPIO_BIT);
for(tim = 0; tim < 5000000; tim++);
//gpio[LED_GPCLR] = (1 << LED_GPIO_BIT);
}

Whereas , the following code is not working at all on the RPI2 (I have uncommented the instruction to turn off the LED) :

while(1)
{
for(tim = 0; tim < 5000000; tim++);
gpio[LED_GPSET] = (1 << LED_GPIO_BIT);
for(tim = 0; tim < 5000000; tim++);
gpio[LED_GPCLR] = (1 << LED_GPIO_BIT);
}

NB : The rest of the code is just like yours

NB2 : I've tested it with your start.elf and bootcode.bin AND the latest start.elf and bootcode.bin from RPI firmware.

Louis (Original Comment )

Hi Louis,

Sorry, I'm having trouble replicating this problem. I've just formatted an SD card (FAT32), and put the files from the tutorial's boot directory on the card as well as the pre-built binary from the part-1/armc-03/bin-rpi-2 directory... ...and, it works!

So I'm not sure how to understand what's going on. I'll carry on trying to break things here. Perhaps I can...

Thank-you for reporting the error.

If possible, can you forward me a compiled version that doesn't work? That way, I may be able to at least load a kernel image that doesn't work!

Best Regards,
Brian.

Could you share that binary image, Brian?

The kernel.img is in the repo already: https://github.com/BrianSidebotham/arm-tutorial-rpi/tree/master/part-1/armc-03/bin-rpi-2

Or do you want me to share a complete card image, i.e. dd if=/dev/sdb of=./rpi2-sdcard.img ?

yes, complete card image would be great, for RPi2, with readme/info where each of the card files came from (version, url). Thanks!

Ok, no problem. Will sort that out

Hi,
Was this issue solved? I tried on a Pi2 too and had the following results:

  • It fails when the kernel.img file produced is put directly on the SD Card (even if renamed kernel7.img)
  • It succeeds when the kernel.img file is wrapped into an u-boot uImage, and then kickstarted by u-boot (after obtaining the uImage via TFTP)...
  • When compiled in Windows using the IAR Embedded Workbench, I can place the generated binary directly on the SD Card, and it works then.

So from the above, the binary generated by my Linux build is correct, since it works when a uImage is generated from it, and therefore it must be related to how this image is loaded and kickstarted by the start.elf firmware?

When peeking into the .elf file using readelf, the entry point address is set to 0x8000.

Any ideas ? Much appreciated!

KH Park.

I'm also having an issue similar to this on my RPi 2 Model B.

I haven't managed to get the LED flashing at all with any of the provided binary files, or my own compiled owns. I have also tried combinations of firmware.
One combination managed to get the LED to turn on and stay on, but when I tried to change the code to turn it off again, the LED just remains off.

Any ideas? It seems related to this issue. I'm fine to test and try out things if further troubleshooting is needed.

P.S. Do I need to have "#define RPI2 1" before the check to see if RPI2 is defined? Or is this something already defined?

@Sheepzez: The definition of the CPP symbol RPI2 is done in the .sh build script as -DRPI2

@Sheepzez Thanks for getting in touch via email. Now I have some time available we'll investigate this and get to the bottom of what's going on. These problems didn't exist before the RPI2, everything worked okay.

I'm sure we'll find out what it is. There is no stack initialisation in part-1, this was purposeful because it's something we do later in the tutorial, but perhaps the stack is being used and happens to work on some RPI and not on others. That is where I will be looking to begin with.

We have confirmed that identical code works on my RPI2, but not on @Sheepzez RPI2! So we're already closer!

Well, I just compiled and disassembled and found 8018: e52de004 push {lr} ; (str lr, [sp, #-4]!) which sucks! That means we'll have to set the stack pointer before running at least. Otherwise that's a sure fire way to go to an exception handler!

Let's do that and see if it fixes the issue. Who know's why the sp appears okay on my RPIs. I wanted to keep all of this out of part-1, but it's pointless keeping the necessary out!

I've just committed changes for part-1 which stop the code using the stack pointer so things look more sane now. Please test. I recompiled the binaries too.

Hi Brian, thanks for getting a prospective fix out so quickly! I'll test the code once I get home after work, about 6 hours from now.

Success! It successfully blinks when I compiled it myself using these flags:
-DRPI2 -O2 -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -march=armv7-a -mtune=cortex-a7 -nostartfiles -nostdlib -ffreestanding -g

I can also confirm that your pre-compiled binaries in bin-rpi-2 folder work as well.

Phew! It's been a lot of debugging work for that one-line fix, and @BrianSidebotham came up with it in a couple hours!

Ah, excellent! Thanks for your help @Sheepzez - it really helped! It's so much easier when someone can confirm the not-working to working state change! Your email coincided exactly with me having a bit of time spare.

Glad this issue is now fixed - now I can concentrate on putting the graphics code into a tutorial.

I made it under win8.1 using armc-02.There's no problem with Brian's code,My RPI2 works well,really.

I guess there's something wrong with Sheepzez's environment. Sheepzez uses -nostdlib which conflicts with Brian's spirit.We just want to reuse library,we don't want to deny other's prevous hard-working. What do you think, @BrianSidebotham ?