Update the README with your config.txt settings

Question

Update the README with your config.txt settings

smithwinston opened this issue 12 years ago · 17 comments

At the moment, I can't get any of the .bin files to work despite meticulously following your instructions. Could you update the README with your config.txt settings? I'm using the bootloader.bin, loader.bin and start.elf as of today (6/19/2012) along with the appropriate .bin file copied in as kernel.img.

Answer 1 · 2012-06-20T04:40:31.000Z

I do not have a config.txt on the sd card. And I have the latest (well maybe a week ago now) boot files from github.com/raspberrypi/firmware

Answer 2 · 2012-06-20T04:48:49.000Z

just tried blinker05 with the latest files from github. I did have to plug in for power, unplug then plug in again (didnt boot right the first time). Did 10 power cycles in a row (after the first fail) no problems. I was noticing that before if I have not had it on in a while it takes two tries. Dont know whats up with that...

Answer 3 · 2012-06-20T05:03:02.000Z

updated readme and uart examples.

Answer 4 · 2012-06-21T19:23:19.000Z

Thanks for the info, I just don't seem to be able to get mine to boot anything, with the latest firmware I just get the "rainbow square of death" when it tries to load kernel.img. Just to check, as far as you know with the latest firmware the RPi is loading kernel.img at 0x8000?

Answer 5 · 2012-06-22T00:38:33.000Z

Yes, using the current firmware from github as described in the readme, no config.txt file, kernel.img will be copied to address 0x8000 and then the arm will start at address 0x8000. More than one config.txt setting will change that. Many of my examples are actually position independent since they are so small.

Try the sd card with a stock debian or whatever raspi images and make sure it boots linux okay, then replace that kernel.img file. I ended up formatting a fresh sd card, smaller cards did not work (32meg and 64 meg) so I think I have a 2 gig card in there now...

Answer 6 · 2012-06-28T16:44:16.000Z

Was this ever resolved? I've been unable to get any of the blink examples to execute on the Pi, it just hangs :/

I've tried with multiple SD cards, as well as trying to load a stock deb/arch image, replacing the kernel.img - none work, and I'm completely stumped at this point - any pointer to the right direction would be good.

Answer 7 · 2012-06-28T19:03:42.000Z

Yes, I believe it was. Or lets say a couple of folks who have contacted me have gone from no success to success. The key issue is that the older (GPU) firmware (bootcode.bin, loader.bin, start.elf) copies kernel.img to address 0x0000 in arm space. The more recent github.com/raspberrypi firmware repo (as described in my README) uses 0x8000. I compile for 0x8000. you can change the linkerscript (memmap) to use 0x0000 instead of 0x8000. It may also be the way you are using your tools compared to the way I use mine. I have placed the binaries for uart02 and a disassembly (uart02.list) so you can compare yours to mine. This helped at least one person. I am going to put binaries there for some blinker programs since not everyone will have a uart solution. I am told it is due to caching, but sometimes I have to power my board twice to get the program to load from the sd card.

There are settings you can add to config.txt to change what the gpu does with kernel.img. I am for now trying to run with no config.txt file, going with the default behavior that the distributed linuxes use.

Answer 8 · 2012-07-01T14:38:18.000Z

Interesting. Using the current firmware on the /raspberrypi repo, and your binaries for blinker01 on my Pi, I get three solid blinks (which I assume are the bootloader reading from the card) then nothing. I swapped the start address out for 0x0000 and rebuilt on my toolchain, just on the off-chance, and the same output is observed, so neither are running after the initial load. (?)

I've posted the objdumps from both binaries (mine@0x8000 and yours) here: (Pastebin)[http://pastebin.com/6hLx7Qp7] and beyond slightly different binary output (due, I suspect to me using the Linaro compiler vs. the Sourcery Codebench) I see nothing that would cause it not to work.

Edt: I'm fairy sure that this is just me doing something stupid, but I can't see it for the life of me!

Answer 9 · 2012-07-01T16:25:38.000Z

All of those dumps look the same in the sense that .text starts at 0x8000 and _start is at 0x8000 and the first few instructions are the same.

00008000 l d .text 00000000 .text
00008000 g .text 00000000 _start
8000 02d9a0e3 050000eb feffffea 001080e5 ................

The first few words in the binary (blinker01.bin) should match the 0x8000 lines above, if they dont that is the problem. try hexdump. You dont have a config.txt file on the sd card right? Only the four files on the card.

I am told it is an l2 cache thing but try power cycling again. when the first power on doesnt work for me there are no green led blinks. just the red coming on. when it blinks a few times quickly that is the gpu loading from the card.

Also you have renamed the file kernel.img when copying to the sd card cp /path/blinker01.bin /path/kernel.img

Answer 10 · 2012-07-01T17:43:39.000Z

I've been renaming the bin's as kernel.img, and I've yet to see the two-power cycle thing on my board, but I've been power cycling multiple times just in case all along anyway, and I've not been using any config files in any of the tests thus far.

Hexdumps for the .hex files are here: http://pastebin.com/nJYePHaW
Hexdumps for the .bin files are here: http://pastebin.com/ykW7uZ37

I'm perplexed as to why even your binaries are failing on my board...

Answer 11 · 2012-07-01T23:40:53.000Z

They appear to match up to the beginning of the C code, the compilers
producing different code is not a problem necessarily.

00008000 <_start>:
8000: e3a0d902 mov sp, #32768 ; 0x8000
8004: eb000005 bl 8020

00008008 :
8008: eafffffe b 8008

0000800c :
800c: e5801000 str r1, [r0]
8010: e12fff1e bx lr

00008014 :
8014: e5900000 ldr r0, [r0]
8018: e12fff1e bx lr

0000801c :
801c: e12fff1e bx lr

00008020 :
8020: e92d4038 push {r3, r4, r5, lr}

Can you somehow provide your .elf and .bin to me if you have a
dissassembly (similar to my .list) then that would be useful as well.
can email to dwelch@dwelch.com.

You are using the current gpu files from the raspberry pi guthub site
not the files from the linux sd card image?

David

On 07/01/2012 01:43 PM, John Vidler wrote:

I've been renaming the bin's as kernel.img, and I've yet to see the two-power cycle thing on my board, but I've been power cycling multiple times just in case all along anyway, and I've not been using any config files in any of the tests thus far.

Hexdumps for the .hex files are here: http://pastebin.com/nJYePHaW
Hexdumps for the .bin files are here: http://pastebin.com/ykW7uZ37

I'm perplexed as to why even your binaries are failing on my board...

Reply to this email directly or view it on GitHub:
#1 (comment)
.

Answer 12 · 2012-07-01T23:51:50.000Z

Just downloaded the latest files from github.com/raspberrypi->firmware->boot

11 hours ago which would be files from the the morning of Jul 1st

added blinker01.bin to get:

ls -al /media/9208-BB09/
total 2308
drwx------ 2 root root 4096 2012-07-01 19:47 .
drwxr-xr-x 19 root root 4096 2012-07-01 19:45 ..
-rwxr-xr-x 1 root root 16532 2012-07-01 19:47 bootcode.bin
-rwxr-xr-x 1 root root 172 2012-07-01 19:47 kernel.img
-rwxr-xr-x 1 root root 275235 2012-07-01 19:47 loader.bin
-rwxr-xr-x 1 root root 2050184 2012-07-01 19:47 start.elf

David

On 07/01/2012 07:40 PM, David Welch wrote:

They appear to match up to the beginning of the C code, the compilers
producing different code is not a problem necessarily.

00008000 <_start>:
8000: e3a0d902 mov sp, #32768 ; 0x8000
8004: eb000005 bl 8020

00008008 :
8008: eafffffe b 8008

0000800c :
800c: e5801000 str r1, [r0]
8010: e12fff1e bx lr

00008014 :
8014: e5900000 ldr r0, [r0]
8018: e12fff1e bx lr

0000801c :
801c: e12fff1e bx lr

00008020 :
8020: e92d4038 push {r3, r4, r5, lr}

Can you somehow provide your .elf and .bin to me if you have a
dissassembly (similar to my .list) then that would be useful as well.
can email to dwelch@dwelch.com.

You are using the current gpu files from the raspberry pi guthub site
not the files from the linux sd card image?

David

On 07/01/2012 01:43 PM, John Vidler wrote:

I've been renaming the bin's as kernel.img, and I've yet to see the
two-power cycle thing on my board, but I've been power cycling
multiple times just in case all along anyway, and I've not been using
any config files in any of the tests thus far.

Hexdumps for the .hex files are here: http://pastebin.com/nJYePHaW
Hexdumps for the .bin files are here: http://pastebin.com/ykW7uZ37

I'm perplexed as to why even your binaries are failing on my board...

Reply to this email directly or view it on GitHub:
#1 (comment)
.

Answer 13 · 2012-07-01T23:52:36.000Z

first power on blinks the green a couple-three times then nothing, pull
power then power again and it blinks the loader blinks then blinker01
takes over and keeps blinking.

David

On 07/01/2012 07:51 PM, David Welch wrote:

Just downloaded the latest files from
github.com/raspberrypi->firmware->boot

11 hours ago which would be files from the the morning of Jul 1st

added blinker01.bin to get:

ls -al /media/9208-BB09/
total 2308
drwx------ 2 root root 4096 2012-07-01 19:47 .
drwxr-xr-x 19 root root 4096 2012-07-01 19:45 ..
-rwxr-xr-x 1 root root 16532 2012-07-01 19:47 bootcode.bin
-rwxr-xr-x 1 root root 172 2012-07-01 19:47 kernel.img
-rwxr-xr-x 1 root root 275235 2012-07-01 19:47 loader.bin
-rwxr-xr-x 1 root root 2050184 2012-07-01 19:47 start.elf

David

On 07/01/2012 07:40 PM, David Welch wrote:

They appear to match up to the beginning of the C code, the compilers
producing different code is not a problem necessarily.

00008000 <_start>:
8000: e3a0d902 mov sp, #32768 ; 0x8000
8004: eb000005 bl 8020

00008008 :
8008: eafffffe b 8008

0000800c :
800c: e5801000 str r1, [r0]
8010: e12fff1e bx lr

00008014 :
8014: e5900000 ldr r0, [r0]
8018: e12fff1e bx lr

0000801c :
801c: e12fff1e bx lr

00008020 :
8020: e92d4038 push {r3, r4, r5, lr}

Can you somehow provide your .elf and .bin to me if you have a
dissassembly (similar to my .list) then that would be useful as well.
can email to dwelch@dwelch.com.

You are using the current gpu files from the raspberry pi guthub site
not the files from the linux sd card image?

David

On 07/01/2012 01:43 PM, John Vidler wrote:

I've been renaming the bin's as kernel.img, and I've yet to see the
two-power cycle thing on my board, but I've been power cycling
multiple times just in case all along anyway, and I've not been using
any config files in any of the tests thus far.

Hexdumps for the .hex files are here: http://pastebin.com/nJYePHaW
Hexdumps for the .bin files are here: http://pastebin.com/ykW7uZ37

I'm perplexed as to why even your binaries are failing on my board...

Reply to this email directly or view it on GitHub:
#1 (comment)
.

Answer 14 · 2012-07-02T00:15:49.000Z

Rebuilt my toolchain, cleaned all the sources, and rebuilt everything.

Reformatted the SD card, copied all the file anew (same set-up as before) and fired up the Pi. Now it works. What on Earth?

I can only guess that my fumbled connecting-of-the-USB did something to the SoC, now it works reliably on the blink tests - either that, or somehow, the toolchain has subtly altered somehow.

Answer 15 · 2012-07-02T00:36:51.000Z

I think I had the same thing happened once, things werent working,
reformatted repartitioned, downloaded all the files, and it came back to
life, never knew what actually changed things. Maybe there are subtle
issue with the gpu reading the file system that collides with something
the host computer is doing with the filesystem.

Glad to hear it is working.

On 07/01/2012 08:15 PM, John Vidler wrote:

Rebuilt my toolchain, cleaned all the sources, and rebuilt everything.

Reformatted the SD card, copied all the file anew (same set-up as before) and fired up the Pi. Now it works. What on Earth?

I can only guess that my fumbled connecting-of-the-USB did something to the SoC, now it works reliably on the blink tests - either that, or somehow, the toolchain has subtly altered somehow.

Reply to this email directly or view it on GitHub:
#1 (comment)
.

Answer 16 · 2012-07-02T00:39:06.000Z

Sounds about right - and thanks for all the help.

If I find out exactly what changed, I'll post back for the benefit of any other lost souls out there.

Answer 17 · 2012-07-02T12:51:07.000Z

Apologies for the double-post, but the problem has re-manifest.

I'm now (again) unable to run even the blink programs - investigating further, but as far as I can tell, nothing changed!

Edit For the record (in case anyone stumbles on this) there seemed to be a problem with the combination of the bootloader I was using and the particular partitioning on my SD card.

With proper 4GB SD-HC card, using the partition table from dd'ing arch-linux onto the card, and wiping all files on both partitions and using the latest bootloader files (start.elf and bootcode.bin) seems to have resolved the issues I was seeing.

This said, I am using an entirely different board to the one I was originally testing on, so it may have been board specific.