Pi 3B+ Baremetal sample code

[Gavinmc42]

On a sidenote can I ask have you noticed how hot Ultibo gets the cpu on a Pi3 board

Yep, Ultibo baremetal seems to push it to the max, noticed it on the latest Julia NEON example, which is why I want to try a Aarch64 version as it is supposed to run cooler.

Raspbian must have more smarts for keeping the 3 cool, probably why youtube lags in Chromium
Smallest fan I have is a 30mm, was looking for a 20mm, just blowing from a few feet away is enough to make the icon disappear, but it is summer here.

Not sure where the thermometer icon graphics are, was trying to see what minimum files I needed and only used kernel7.img, start.elf, fixup.dat, bootloader.bin and only got a grey square with no graphics?

Might have to look for metal Pi3 cases?
As I want to use the 3's for development desktops, fan cooling is probably a must.
Does anyone make a tiny heat sink with fan for the Pi3?
Next PCB version to have a 3 pin header for plug on fan?
They probably never notice it in the UK, using the Pi's for room heaters?

Not sure on specs of the BCM2837, 0-70C or -25-85C, probably the latter these days.
The early Pi's had some 0-70C only parts, then people started using them for weird stuff.
55 is enough to feel real hot, 65 C is into burn point, 75 is ouch, 85 is won't do that again.

Probably not a good idea the SD card get hot unless you get industrial versions.
I think most SD's would be 0-70C? I better check mine.

[LdB]

I am going to show my age and say I had stick on heatsink probably circa 90's we used to attach to H bridge darlington driver transistor arrays used on small 1-2 amp stepper motors. Not sure if they sell such a thing these days and I was amazed the amalgam tape stuff it adheres with still worked. Conservative I would guess 20 years old

It was perfect but 10mm x 10mm and nice thin tall veins probably 15mm long by look.

[Ultibo]

I am not sold on that yellow couldn't we go for a calming blue

The color goes with the release, so the current release is Cucumber (which is Orange) and the next one will be....

On a sidenote can I ask have you noticed how hot Ultibo gets the cpu on a Pi3 board

The temperature and the clock speed go almost hand in hand, so when the Pi3 runs at 1.2GHz it gets fairly hot. Now others have commented that Raspbian runs at 1.2GHz and doesn't get so hot but that actually isn't quite true because Linux has a CPU governor that drops the speed when there is no work to do (which is often in most cases).

I'm not aware of any bare metal project that has implemented a CPU governor but since the question comes up regularly we might have to have a go at it sometime.

[LdB]

Nice ... just make it blue .. you are a Pascal man look at the original Borland compiler colour scheme

I need to also thank you I borrowed a couple of cute lines from Ultibo. I had the situation with all the autodetecting I can run Arm6 code flawlessly on the Pi3 had all the peripherals and knowing about all the extra register stuff but switching the processor modes I couldn't do because the Arm6 compiler doesn't have the opcodes. Then I saw your HYP to SRV mode code and you inlined raw .word as opcodes (FPC obviously had same issue) which works a treat and now my Arm6 code can change CPU modes on an Pi3.

One last mystery to work out is the Video pitch is set as 32 for that first motley coloured screen yet it spans the whole screen. It is like it's a really small bitmap that is somehow zoomed up large onto the entire screen and I don't understand how they did it which I find rather annoying. Whatever they have done I can't just use the screen I have to actually issue a set screen resolution command before I can get what I would call normal control over the screen.

Oh I still have the silly USB on the Pi3 it won't power up which is a bit of mystery to me. The mailbox 0x80 power up message doesn't seem to do anything so will probably need to poke around in your code again. I have suspicion that they probably moved it out with the activity LED. You have pretty much everything working from what I can see. Then I am bracing to go after the EGL video, I have lots of code from articles I have done on OpenGL 3.0 and 3.3 so I am hoping I can adapt the shaders etc. Sigh so much coding so little time and I might even get some paying work done in there as well

[dwelch67]

LdB, no offense meant at all, was trying to nip something in the bud, lots of these ARM boards and forums and my chip is hot what do I do...So was basically a knee jerk reaction in general, not personal. Sorry.

Yes there are other parts on the board. Funny story in our parts database thermistors and resistors were in the same category and we had a board that a thermistor was accidentally chosen instead of a resistor. The primary processor was well below rated temp but things were failing once we started pushing it harder, so I recommended they look around the socket and see what other parts are there and their ratings, and eventually this mistake was found, replaced with a resistor, and problem solved. Still dont truly understand how the mistake happened, but was pretty funny as not only was it some other part, but the part was specifically a temperature sensitive part.

Could put the pi in a cardboard box (insulated) and maybe use a hair dryer on low to get the temp up faster and see if the whole board works. If there are other parts that are sensitive.

Interesting possible experiment to see if I can get the part warmer or not. Sorry if this was answered is there a thermal sensor in the part that we know about?

And also, yes I was combining comments to three other sub threads at the same time, talking to three people in one comment.

David

[LdB]

No worries David I meant nothing by it was just an off the cuff comment to Ultibo about something I noticed.

I would appreciate a clarification on something else really basic from anyone. I have been trying to sort out CPU_ID and I have basically been dealing with them in my code by the CPU_ID returned from the chip and that is what I see. This what I have

#define ARM6_CPU_ID 0x410FB767 // CPU id a BCM2835 reports
#define ARM7_CPU_ID 0x410FC073 // CPU id a BCM2836 reports
#define ARM8_CPU_ID 0x410FD034 // CPU id a BCM2837 reports

I know what all the bits mean and basically they are B76, C07, DO3 which nominates the CPU the rest are manufacture,revision etc.

So I have 3 chips BCM2835, BCM286, BCM2837
That is the numbers on the silcon as I look at it and they are referred to by the official site so here is the BCM2836
https://www.raspberrypi.org/documentati ... /README.md

However when I look at the firmware repository, In some discussion and even Ultibo has totally different numbers
BCM2708, BC2709, BCM2710

What the heck are these numbers and they seem to refer to the same thing. I have enormous piles of #IFDEF based code to sort thru on these numbers and I haven't a clue what they are and where they are getting it from. I took a guess that they were Pi1,Pi2 and Pi3 but that doesn't even seem to work on the repositories or there is a fourth CPU I haven't seen.

Ultibo has his in different files and it sort of does what I expected like this
R1 - Machine Type (Raspberry Pi or BCM2708 = 0x0c42) => (BootRpi.pas)
R1 - Machine Type (Raspberry Pi 2 or BCM2709 = 0x0C42) => (BootRpi2.pas)
R1 - Machine Type (Raspberry Pi 3 or BCM2710 = 0x0C42) => (BootRpi3.pas)

But linux repositories don't seem to obey that they go all over the shop. Then if I google those numbers I am getting things about Pi1,Pi2 and Pi3 and often the same number with different Pi's. I am completely lost with these #IFDEF's. The BCM2708 sort of matches what I expect with a BCM2835 but then occassionally not it jumps to a Pi2. The BCM2710 seems to be consistently a Pi3 but then occassionally a Pi zero. I don't run across BCM2709 a lot and when I do it's just confusing it often doesn't refer to a Pi2.

At the most basic I was trying to work out what a Pi Zero CPU ID would return because I can't get my hands on one I have it on order for weeks and this problem cropped up and is this my missing CPU. I was under the impression it was just a cut down ARM7 board.

[LdB]

I made a little progress it would appear sometimes BCM2708 etc is used to refer to the actual hardware and other times to files like overlay driver files which have those strange numbers dt2708, dt2709, dt2710. So it becomes messy because obviously some drivers are being accessed for different boards and I guess they alter the IO base address.

So I think I am safe to assume a Pi1 is BCM2708, Pi2 BCM2709, Pi3 BCM2710 but some of the #IFDEF's look wrong because they are accessing driver files for another model.

[dwelch67]

Those CPU IDs are from the ARM core Im pretty sure and are directly documented in the ARM ARM or ARM TRM for those cores (probably the TRM). The pi-zero is a small pi 1 so it should be the same as the pi1, and looking at one it has the package on package dram, which the others dont, again same as the pi1.

[LdB]

Thanks David I will go with that but note it as untested in next article which hopefully can put in for submission tonight. Otherwise article won't happen until next weekend as I have a heavy workload this week.

[dwelch67]

Not sure if this was a coincidence or you asked on stackoverflow how to do this as well, but either way answering in both places plus I made a simple example (and dug out an old pi1 as well to try it on, duh I guess I have some A+ boards laying around I could have used instead of an old original-ish).

Code: Select all

.globl GETCPUID
GETCPUID:
    mrc p15,0,r0,c0,c0,0
    bx lr

returns

Code: Select all

PI3 0x410FD034
PI2 0x410FC075
PI1/Zero 0x410FB767

https://github.com/dwelch67/raspberrypi ... ards/cpuid

Tried it on an old/original-ish (because I dont have a blue wire on it for jtag it is probably the rev 2 or whatever that they moved the jtag pin over to the P1 header), a pizero, a pi2 and a pi3.

[LdB]

Wasn't me, I didn't even know they discussed Pi's there but I will take it

I know how to read the CPUID from code, I just didn't physically have one.

[dwelch67]

Posting the instruction for completeness. I had a funny feeling you didnt have one of the boards thus couldnt confirm what it returned...I was pretty sure the pizero and pi1 were the same chip, and got lucky and found a pi1 in the first place I looked, wasnt going to go digging for a hour to find one...And my pi2 and pi3 were handy same story. So was able to try those four.

[LdB]

All good it gave me a break from FAT32 coding .. the Endian swapping on the Pi is driving me to tears.

Never really wanted Endian Aware FAT32 code but now I have too. Shouldn't complain easier to read on Arm.

[dwelch67]

I dont remember the details but there are endian swapping features of the instruction set(s) (ARM). There may be a simple load while swapping one, and or you change the endian bit, load, and change it back. Depends on the instruction set though, the armv6 on up are BE-8 so a word sized operation will swap the bytes (if in big endian mode for that instruction).

[Ultibo]

the Endian swapping on the Pi is driving me to tears.

Sorry, totally off topic but curiosity gets the better of me.

Since the Pi is little endian by default and all the FAT data structures are also little endian (no swaps needed) what platform do you normally code for that is big endian? Or are you setting the ARM to big endian mode?

[LdB]

Yes that is what I said it's easier to read on the Arm. However the code is big endian from a PC so it swaps the data at places. So when it picks up a whole record it doesn't automatically swap the data because it might not be using it all, well lets say most times it isn't. So basically I am having to read Intel assembler, rewrite it to arm assembler with whatever changes that entails (often I have odd byte alignment issues) and on top of that pick the Endian swaps. Sometimes I am not even sure I have 16, 32, or 64 bits values because the Intel can use the registers as 8, 16 or 32 bit storage and I was obviously trying to be super efficient in the day and I wish I had commented better back then. I considered playing with the Endian swap on the Arm but I have to convert the code anyhow. I also considered writing it from scratch again but I have large beautiful blocks that are well tried and tested and easy to convert, it's just this messy joining code that needs attention.

There is an irony not lost on me that the PI bootloader itself must have a FAT system to be able to get at it's files and so I will be the second and whatever comes behind me will probably be the third file system to run.

You of all people after writing Ultibo would know what I am up against as essentially as I am writing what is loosely a BIOS. Just like a BIOS I am having to pick the drives, mouse, screen etc up to use for short "setup" purposes only to later on probably be thrown out of memory by whatever comes after me. I thought my assembler days were well behind me and I think will be the last time I do assembler on this scale, I am getting too old for this

Parts of this will be up Sunday, I was hoping for more but I still have a small list of weird things which may or may not get debugged on weekend. I think this is my current list
1.) USB port on Pi3 doesn't power up off Mailbox command like Pi1 & 2
2.) Need to be able to send HID setup block to mice, some seem to start in absolute mode
3.) SD card capabilities register seems to be missing on Pi .. where/why?
4.) SD card 3.3V UHS-I double edge read/write mode works on Pi1 but not Pi2/3 .. why?
5.) Need to sort out a proper malloc function to be able to deal with FAT32 long names and searches.