Comments (17)
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
from raspberrypi.
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...
from raspberrypi.
updated readme and uart examples.
from raspberrypi.
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?
from raspberrypi.
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...
from raspberrypi.
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.
from raspberrypi.
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.
from raspberrypi.
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!
from raspberrypi.
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 ................
00008000 l d .text 00000000 .text
00008000 g .text 00000000 _start
8000 02d9a0e3 050000eb feffffea 001080e5 ................
00008000 l d .text 00000000 .text
00008000 g .text 00000000 _start
8000 02d9a0e3 050000eb feffffea 001080e5 ................
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
from raspberrypi.
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...
from raspberrypi.
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 [email protected].
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/ykW7uZ37I'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)
.
from raspberrypi.
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 802000008008 :
8008: eafffffe b 80080000800c :
800c: e5801000 str r1, [r0]
8010: e12fff1e bx lr00008014 :
8014: e5900000 ldr r0, [r0]
8018: e12fff1e bx lr0000801c :
801c: e12fff1e bx lr00008020 :
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 [email protected].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/ykW7uZ37I'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)
.
from raspberrypi.
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->boot11 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.elfDavid
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 802000008008 :
8008: eafffffe b 80080000800c :
800c: e5801000 str r1, [r0]
8010: e12fff1e bx lr00008014 :
8014: e5900000 ldr r0, [r0]
8018: e12fff1e bx lr0000801c :
801c: e12fff1e bx lr00008020 :
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 [email protected].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/ykW7uZ37I'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)
.
from raspberrypi.
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.
from raspberrypi.
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)
.
from raspberrypi.
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.
from raspberrypi.
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.
from raspberrypi.
Related Issues (20)
- More detailed bootloader example steps HOT 4
- How to run the Raspberry Pi 2 blinker example? HOT 7
- a new way to avoid remove/insert SD card again and again HOT 22
- read/write capability
- uartx01 example HOT 1
- Problem with Enabling JTAG in RPI B HOT 1
- uart04 example unexpectedly reboots
- Where are PUT32 and GET32 defined? HOT 1
- Coroutines in ARM Assembly
- arm_control deprecated HOT 1
- Save ELR_hyp and cpsr in pi 2 blinker 5
- Raspberry Pi
- Rasp
- Can't bind RFCOMM socket: Address already in use
- Ordering
- Problem with record and play wav files on pi HOT 5
- Oi
- Raspberry pi Projects Discord
- I connected waveshare screen to raspberry pi zero w and thereโs no option to rotate screen to right or left. What to do?
- Success with Raspberry PI B+ jtag with Olimex ARM-USB-TINY-H
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from raspberrypi.