Operation: Try to Bare-Metal the Pi

Description

I've recently discovered that the RPi's can be bare-metalled!

The idea, as suggested in the comments, is "a microcontroller on crack" which sounds pretty awesome.

As for what to do with it...? Not sure, yet.

----------------------------------------------

Unfortunately, I bit off a lot more than I could chew with my plans for this and will not be pursuing it in the near-future.

Do Not Be Deterred,
If you're not concerned about keeping track of every clock-cycle, like I was, and most people probably won't be:
You Can Do This.

To anyone interested in pursuing a bare-metal-Pi, there are some GREAT LINKS in the "Details" and "Comments" sections (Thanks, all, for those!).

-----------------------------------------------
CONTEST JUDGES:
Nothing to see/judge, here... go out for a cup o' jo with your newfound free-time :)

Details

I'll leave this here as there were quite a few follows.

It seems bare-metal Pi-ing seems to be an interesting (and apparently hard to find) topic to quite a few folk!

So I'll let this stand as at least a resource for links/commentary...

Here's another great resource by @Vikas V: #Logic analyzer using raspberry pi

Looks like he's already much further along than I, so check it out!

Thanks again, @nistvan.86 in the comments of the Adafruit

Pi-Zero contest-page, for this link to what looks to be an

awesome collection of RPi

Bare-metal tutorials/examples.

Here's another I found prior, but admittedly hadn't given the thorough look-through it deserves. Another brief glance, and it seems quite informative.

And please check out the comment-threads, below... There're some *awesome*

resources and thought-points there. (Thanks, especially, @usedbytes!)

This's kinda turned into a resource for logic-analyzer type interfaces with the pi... in that light, @K.C. Lee had a great idea over at #sdramThing4.5 "Logic Analyzer" and might not even require bare-metal(?): "On the RPi, you might be able to use the SDIO in 4-bit mode to capture signals in high speed (50MHz or so). The timing is more deterministic for that port and probably DMA driven." --Cool! Hope someone finds that useful!

#Super low cost VGA output for the Pi Zero got me thinking... now, wait a minute... doesn't "Gert's VGA666" use the GPIO pins to generate VGA? Talk about needing precision-timing. Huh...

Another useful-resource for GPIO-stuff, though meant to run under Linux, is #C GPIO library for Raspberry Pi

If anyone wants to submit their own findings, or even link to their own projects, please do!

You can throw it in the comments, below, or request to join and add your own project-logs.

Come up with something better'n this, and I'll replace *all this* with a link to yours (or maybe there's some way to transfer ownership?) :)

Project Logs

Collapse

Bare-Metal Emulators
Eric Hertz • 10/13/2016 at 12:03 • 0 comments

Now here's an idea I hadn't thought of for bare-metalling... Emulators. Right? Why run an emulator atop an OS?
There're some great thought-points in the commentary, here... I'm no emulator-designer, and barely even use emulators... so I can't vouch for anything said.
http://hackaday.com/2016/10/12/raspberry-pi-boots-cpm/
--------------
I have, however, run VirtualPC on a 1GHz PowerBook-G4 and... running WindowsXP was *doable*; booting took about 20min, then... I used it for CircuitMaker2000, which... was I think written for Windows95/98... and... it was atrociously slow (but functional enough to slowly design several circuit boards). Were it a Win98 machine with CM2K, I think a 100MHz Pentium woulda been plenty. So, I think a 20:1 slow-down is a reasonable estimate... (1GHz G4 => 50MHz Pentium).
So... how much of that was due to OS overhead...? How much was due to MAC-OS overhead, and then, again, how much more of that was due to WinXP overhead...? If I'da done Win98, would it've been significantly faster? Who knows... Maybe I'll rerun those experiments when I acquire my "new" PBG4 replacement.
Regardless, it'd be hard to dispute that running a bare-metal emulator should certainly be faster than running one atop an OS...
Zero Acquired! And a good bare-metal starting-point
Eric Hertz • 10/09/2016 at 07:55 • 0 comments

Overly-wordy, too long, and much too blurry "proof" of this mythical electronic creature... If you believe the Sasquatch, UFO, or Unicorn-sighting videos, you'll believe this one!

[dwelch67] has what appears to be a great collection of bare-metal-pi examples... And really seems to know (and share) his/this shizzle.
And (interesting-timing?) recently my email's been getting some messages from his project... directly related to getting started with his project...

UPDATE: I've done the first "blinky" example from his code, and put my findings in the "Instructions" section of this project-page.
There might be some useful info, here, as well: https://github.com/dwelch67/raspberrypi/issues/24
So, this whole bare-metalling thing may be quite a bit easier than I pictured, and maybe even quite a bit more common... But either way, Be Sure To Enter Your Project In The Contest! before November 8, 2016
Oh Hey, That reminds me... You might like this...
Eric Hertz • 10/08/2016 at 15:04 • 0 comments

Hey, if you're interested in bare-metalling the Pi, you should look into this... BEFORE NOVEMBER NINTH:
Have an awesome Raspberry Pi project in mind (or maybe sitting on your bench right now)?
Show it off for the Enlightened Raspberry Pi contest and you can score some excellent loot.
Find out more here:
http://hackaday.com/2016/10/05/win-loot-with-the-enlightened-raspberry-pi-contest/
And be sure to click-through for the details (relinked-here):
https://hackaday.io/contest/15532-enlightened-raspberry-pi-contest
As far as I'm aware, there aren't many bare-metal Pi projects out there, and even fewer on .io... So I'm totally guessing here, but something little more complex than a bare-metal-blinky-pi could be surprisingly competitive.
Get to work!
Interesting inbox...
Eric Hertz • 10/08/2016 at 14:24 • 0 comments

"This project was last updated 7 months ago"
Sometime therebefore I put in the description that my pursuit of this "project" is mostly-dead, but not due to lack of information! So this "project page" remains as a placeholder for a bunch of great links brought to my attention.
Again, thank you to all who did and/or will!
-----
So it's kinda interesting that over the past day or so my email inbox is filled with new folks following this project! Weird! Cool, but weird!
Hey Newbies, and those who haven't already! Check out the profile pages of the folks who've suggested resources! Their profile-pages are linked in the comments-section, the description, and elsewhere 'round this page. Them's some smart folk!
-----
My original goals for this project kinda branched off to #sdramThingZero - 133MS/s 32-bit Logic Analyzer, but I have little intention to bare-metal that any time in the near future. But, who knows, these new follows are good reminder of bare-metalling... And, again, thanks to all the commenters for their links, 'round here... Should I go that route--now that I've finally ordered MyVeryFirstPi(TM)--I've got some great links here to start with!
And you, new-followers, do too!
Would be awesome to see if y'all come up with stuff, please leave a project-link in the comments-section!
Peripherals for clock-generation
Eric Hertz • 03/20/2016 at 10:12 • 0 comments

Here're some thoughts on R-Pi peripherals which could potentially be used to generate a steady high-speed clock-output...
https://hackaday.io/project/10119-sdramthingzero-133mss-32-bit-logic-analyzer/log/34149-potential-pi-sdram-clock-sources
(Note the R-Pi's peripheral data-sheet: https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf Not sure which particular Pi Revisions this is applicable to...)

View all 5 project logs

Build Instructions

Collapse

Step 1

OVERVIEW

Here's a QUICK-START to loading the "blinker01" binary from dwelch67 on a Pi Zero.

(These instructions may differ slightly for other Pis)

There's a *wealth* of info in there, but you have to jump around from README to README to get that first blinky going...

(Realistically, it's probably better to start with his READMEs, to get a sense of his style so you know where to go next with "blinker02", and further... And you can learn *a lot* about Raspberry Pi, ARMs, CPUs in general, and more, in the process.)

These instructions will *not* be enough to get further than "blinker01", but they are a portion of what's necessary to load any binary, once you've compiled your own...

Again, this is a compilation of the necessary info found in dwelch67's READMEs, so ReadThems!

Step 2

Gather The Files

There are THREE files you'll need:

bootcode.bin
start.elf
"kernel.img"

When downloading these files from these links, DO NOT right-click->download.

Instead, DO click the filename to open a new page, then click download. Took a while to figure that one out.

bootcode.bin and start.elf are FIRMWARE files from The Official Raspberry Pi Github:

https://github.com/raspberrypi/firmware/tree/master/boot

kernel.img is your binary... Whatever *.bin you compile, or the already-compiled "blinker01.bin" file from dwelch67:

https://github.com/dwelch67/raspberrypi/tree/master/boards/pizero/blinker01

Step 3

Copy The Files

Format a microSD card to FAT32.

Copy the three files to the card

Don't forget to rename your "blinker01.bin" file to "kernel.img"

(NOTE: Other Pi versions may require a different filename for kernel.img, e.g. kernel7.img, with a seven... Try that, or you'll need to check the READMEs).

Discussions

Stian Soreng wrote 12/28/2016 at 11:59

Just an addendum to your emulators section. I wrote "Apple Pi", a bare-bones Apple ][ emulator for the Pi a while back. It works fine but needs peripheral support, which I will take care of... one of these days. https://hackaday.io/project/391-apple-pi

Are you sure? yes | no

Eric Hertz wrote 12/28/2016 at 20:32

very cool. Thanks for that link!

By-far the most sophisticated bare-metal Pi project I've seen.

Are you sure? yes | no

Roberto wrote 03/03/2020 at 09:33

You should really take a look to BMC64 then :D

Are you sure? yes | no

usedbytes wrote 02/21/2016 at 13:44

Hey Eric, I'm going to top-level post because of the threading limitation.

It's not necessarily loaded slowly, it just can be unpredictable. The processor tries its very best to predict what the next instruction that's needed is, and will pre-fetch them. In addition, the cache loads 64 bytes at a time, which means instructions/data which are stored close to the bit being accessed are in the cache (i.e. quick access). The problem is when you take a branch that wasn't predicted, or load something that isn't in the cache - then the penalty can be very high. Potentially there's dirty data in the cache which needs to be written out to main RAM, then the new data needs to be read into the cache, then the processor can start going again.

With the caches turned off, it's more predictable (no uncertainty about whether you get a cache hit/miss), but *everything* runs at the main RAM speed then, which is very much slower than the CPU. In essence these kinds of processors aren't suited to real-time tasks for these reasons - that's why ARM makes the M and R class processors.

Modern processors have more fancy tricks to reduce the impact of the delays, but the ARM11 in the Raspberry Pi is pretty old and simple.

With regards to my idea, actually I was planning to give it a go under Linux. My idea would be have a kernel driver sampling the GPIO port with DMA (so little/no CPU involvement), and to pass that data over a USB-gadget ethernet interface to a PC. It's not top of my list at the moment as I don't have a Pi Zero to try it on, but perhaps I can win one and get started?? :-)

Are you sure? yes | no

Eric Hertz wrote 02/24/2016 at 12:42

Thanks for this explanation, yo!

Seems I keep running into this hurdle, so I guess I'll have to rethink my strategy... At this point, I think I've more than enough hardware to learn this stuff on... (Cache, branch-prediction, MMUs...) so I think I'll lessen the competition for others to win those Pis and implement their awesome ideas :)

But I may come back to this later down the road! Awesome info, thanks! And likely useful to others as well!

Are you sure? yes | no

usedbytes wrote 02/20/2016 at 08:06

I don't think you can realistically "cycle count" on the Pi in its default configuration because of the DRAM and caches. The core has two tightly-coupled memories (TCM) though (1 for instructions, 1 for data), I forgot how big but it's a few kilobytes. They have single-cycle access.

If you're looking to do high speed logic analyser, I'd sample the data into a TCM and get the DMA engine to transfer it to DRAM. When I'm back at my keyboard I'll dig out the info

Are you sure? yes | no

usedbytes wrote 02/20/2016 at 08:39

This is a great resource: http://sandsoftwaresound.net/raspberry-pi/arm11-microarchitecture/

The TCMs are 8 kB each. So if you can make your code and your data fit in 8 kB (and you become One with the Branch Predictor Gods[1]), and you don't need to access any off-CPU peripherals, you could *actually run* at 1 GHz, which is pretty awesome. Data dependencies will of course slow you down a bit, but it's still going to be blazing fast.

If you decide to use the MMU, you can pin pages (or superpages) which will make accesses more predictable. You're looking at ~100 cycles for a main memory access with a TLB miss though[2]

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/I1001570.html
[2]http://sandsoftwaresound.net/memory-access-time/

Are you sure? yes | no

Eric Hertz wrote 02/20/2016 at 10:03

Great info, thanks! Got some thinking to do...

---------------------

*** READERS: usedbytes' messages, here, were in-response-to my original project goals of trying to plan each assembly instruction's being executed in order on a precise and predictable schedule (e.g. the system clock)... the need for this is *rare.* So, if you're thinking about bare-metalling, don't be deterred by the density of information at those links ***

Are you sure? yes | no

Eric Hertz wrote 02/21/2016 at 11:37

Hah, 8kb, huh...? At full-on 1000MHz...?

I dig the idea... That's a really good point, you're saying most (all?) things coded in these realms are loaded slowly and executed fast, then bottlenecked again to load more stuff, right?

So a *small* program with *zero* OS/context-switching overhead could actually run *at* 1000MHz, I see it, I see it. Very intriguing. I wanna see a side-by-side benchmark on a calculation *of* Pi on this Pi system and the same on a Pi running Linux ;)

Unfortunately, Branch Prediction and MMUs make my head spin, and executing memory from anything other than FLASH has been quite elusive to me for some time... Otherwise, your info here looks quite useful, as well, for my crazy cycle-counted pin-change ideas.

Maybe some day!

And, seriously, thanks for those thoughts/links. If that someday comes this is where I'll be looking.

-------

Hah, seriously digging your idea... Enter it in the contest, yo!

Are you sure? yes | no

Jack Laidlaw wrote 02/20/2016 at 04:38

This sounds like an amazing project!! Way out of my skills/abilities. So does this mean you would be effectively turning the pi into a microcontroller on crack??

Are you sure? yes | no

Eric Hertz wrote 02/21/2016 at 10:37

That's the thought! "Microcontroller on crack!"

I, unfortunately, hit my skills/abilities ceiling, as well... but I'll throw in whatever new findings I come up with, and maybe others will, as well.

Are you sure? yes | no

davedarko wrote 02/18/2016 at 09:19

Looking forward to this :) I've known of only one project so far, a guitar FX board that was featured on the blog once.

Are you sure? yes | no

Eric Hertz wrote 02/18/2016 at 11:09

Oh, wow, I thought I hadn't heard of it before 'cause I've been living under a rock!

No promises I'll come up with anything (I don't even own one, yet). But thanks for watching :)

Those other RPis, I would feel like it was a waste using 'em without at least attaching a display, running linux, using USB, and/or connecting to the 'net... but at $5, it could be considered basically a really fast microcontroller... kinda changes the game.

Are you sure? yes | no

Operation: Try to Bare-Metal the Pi

Description

Details

Project Logs

Collapse

Bare-Metal Emulators

Zero Acquired! And a good bare-metal starting-point

Oh Hey, That reminds me... You might like this...

Interesting inbox...

Peripherals for clock-generation

Build Instructions

Collapse

Discussions

Similar Projects

Raspberry Pi Zero 2 W Active Cooling

DIY Raspberry Pi MP3-player

Raspberry Pi PortaStudio

PICO8 Real Console

Operation: Try to Bare-Metal the Pi

Become a Hackaday.io member

Just one more thing

Description

Details

Project Logs Collapse

Build Instructions Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse

Build Instructions

Collapse