Bare Metal Assembly


31 posts   Page 2 of 2   1, 2
by rurwin » Sat Jun 09, 2012 4:51 pm
They were made in the UK, so they are copyrighted. On the other hand they are at least implicitly licensed for redistribution. I have not seen any indication that Broadcom or the foundation are limiting distribution.

That devicetree structure looks useful. Bare metal code could use that to find where the various devices live, even if you did not make as much use of it as a general purpose OS like Linux would.
User avatar
Forum Moderator
Forum Moderator
Posts: 2932
Joined: Mon Jan 09, 2012 3:16 pm
by DexOS » Sat Jun 09, 2012 5:46 pm
Thats good news, so my tut safe :) .
Please do not get me wrong, in some ways Broadcom is being too helpful.
But it can get very frustrating coding something that took a week of hardwork, to find that they have just added it anyway.
Also those of us who want bare metal, what bare metal, its getting like coding on top of another OS, that your not in full control of.
Note: All us assemble coders are Control Freaks ;)
Batteries not included, Some assembly required.
User avatar
Posts: 863
Joined: Wed May 16, 2012 6:32 pm
by tufty » Sat Jun 09, 2012 6:27 pm
I'm largely in agreement with Dex here. Coding to a moving target is extremely hard, and I would add that the current changes seem to be being added *solely* to help with the way Linux does things. Not to mention that it pulls the carpet out from everything we've been told thus far (i.e. "the kernel binary is a flat image that is loaded starting at address 0x0").

As Dex says, all assembler coders are control freaks. And we tend to get a bit miffed at losing 32K of memory, even if we have 224M to play with. I do, anyway.

Personally, I would like to see a line dawn in the sand - for the way the Pi boots to be something we can consider as fixed, static, immovable. Even if it's not the way we all want it to be. At least that way we can be sure that some future blob version isn't suddenly gonna make our kernels fail to boot. And that way it can be documented.

For example, I personally would like to be back at the "load at 0x0". The option of atags or a device tree starting at 0x100 through 0x4000 can be useful (for non-linux, more atags than the device tree, I think). I fail to see any benefit in forcing the kernel to load at 0x8000, except for the marginal benefit of not carrying 32K of zeros around in the linux kernel. The approach of "you might be loading at 0x0, you might be loading at 0x8000" is confusing and likely to cause problems down the line for everyone apart from Linux. Like I said. From my viewpoint, it's a PITA.

That may be because I'm feeling a bit grumpy. My best friend is in hospital with a metastasis of his lung cancer, it's affecting his brain, and it's looking increasingly unlikely he will be getting out without a pine suit.

Simon
Posts: 1368
Joined: Sun Sep 11, 2011 2:32 pm
by nick.mccloud » Sat Jun 09, 2012 7:31 pm
Sorry to hear about your friend Simon. Life can be a bi*tch.

I'm keen to learn bare metal (I do it on PIC because I'm a masochist), mostly I code high level but I don't have the skills to go through the learning curve you guys are.

I think this topic is very important but it also has to be recognised that the main driver for the Pi is Linux.

Why not start a thread in this section to engage with Dom and others on these issues. There is also nothing stopping you from posting your brief comments on GitHub on the impact proposed changes to firmware will have on bare metal programming.

I get the impression from lurking that some sort of switcher-roo option in the firmware would help so you can boot the Pi in Linux, code, compile and then reboot but due to a cunningly set flag, boot one time from a different kernel, see what happens (or not) and then reboot back in to Linux. Maybe helping with a format for that would be useful?
User avatar
Posts: 795
Joined: Sat Feb 04, 2012 4:18 pm
by DexOS » Sun Jun 10, 2012 3:00 pm
I to, am sorry to hear about your friend, as nick.mccloud said, life can be a bi*tch.
Batteries not included, Some assembly required.
User avatar
Posts: 863
Joined: Wed May 16, 2012 6:32 pm
by tufty » Sun Jun 10, 2012 3:30 pm
Cheers guys.

Anyway, I raised an issue on the firmware, I think that something better could certainly be arranged. Comments and / or suggestions would be welcome, I'm sure.

https://github.com/raspberrypi/firmware/issues/36

Simon
Posts: 1368
Joined: Sun Sep 11, 2011 2:32 pm