Intel Bare Metal Programming - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2017, 10:26:56 pm
content: Do any of the Intel "maker" boards like the Galileo, Edison, or Joule support bare metal programming in the sense that ARM Cortex-M boards do using an IDE to compile C code and download it to the board using J-TAG to debug and run?Does Visual Studio support this?

author: alm
author_rank: Super Contributor
timestamp: August 03, 2017, 10:36:24 pm
content: Why would you would want to get into adiscontinued productwhen starting fresh? I believe the Beaglebone Black should have sufficient documentation to initialize it from bare metal. I am sure there are others. Not sure how long the startup code would be and how practical it would be, though. Definitely a lot more complicated than Cortex M.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 03, 2017, 11:23:03 pm
content: The issue with this sort of thing is often not so much getting the processor to run code, but to make use of the high-end peripherals that are there.There may be a few issues like initialising an MMU and/or DRAM controller, and setting up clocks etc, and if a processor is designed for a big OS, these things may not be so well documented "because everyone just uses our BSP".

author: westfw
author_rank: Super Contributor
timestamp: August 04, 2017, 02:40:27 am
content: A standard PC-like motherboard can be programmed in bare-metal fashion, and the BIOS present will do a bunch of convenient initialization for you (and probably surprise you by continuing to service interrupts for stuff like "legacy BIOS emulation for USB devices") Just write your code like it was running on a nice bare-metal x86 with a lot of linear memory space, and use something like Grub to load and start it... Anything that can run linux should be in a similar category.

author: alm
author_rank: Super Contributor
timestamp: August 04, 2017, 08:49:36 am
content: The latter is not necessarily true. Embedded systems like SBCs do not usually have a BIOS. Linux support might have been developed by people with special access to documentation that is not publicly available, e.g. Raspberry Pi.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2017, 03:05:09 pm
content: Quote from: alm on August 03, 2017, 10:36:24 pmTwo reasons. Because I already have some of these boards, and because I want to write code for the x86 architecture, not ARM. That's why I don't want to use a board like a Beaglebone Black or a Raspberry Pi

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2017, 03:09:57 pm
content: Quote from: blueskull on August 03, 2017, 10:35:48 pmI'm developing an RTOS, so using an existing one is pointless. This is a hobby project, so the fact that there are existing RTOSs that run on this hardware is irrelevant.QuoteAgain, the whole point here is writing my own RTOS, so I have no interest in WindRiver VxWorks or Linux.QuoteCan Visual Studio interface with a J-TAG debugger over USB and remotely debug code?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 04, 2017, 03:15:51 pm
content: Quote from: westfw on August 04, 2017, 02:40:27 amI think this is the way I'll go. I probably have an old PC out in the shed that I can use when I get to the point of running something on actual hardware. Before that, I can use QEMU on Windows to emulate the hardware and make it easier to do initial testing.

author: rstofer
author_rank: Super Contributor
timestamp: August 04, 2017, 10:07:54 pm
content: If Linux runs on the platform, somebody coded it at the bare metal level. So, find the appropriate code and use it as a model. Much of it will be Linux specific but at the bottom level, it is hardware specific.

author: alm
author_rank: Super Contributor
timestamp: August 04, 2017, 11:06:01 pm
content: That is possible, but reverse engineering reg_72 = 0x48414d4d455201 is a lot more painful than reading a datasheet that defines the registers.

author: rstofer
author_rank: Super Contributor
timestamp: August 04, 2017, 11:23:51 pm
content: Quote from: alm on August 04, 2017, 11:06:01 pmThat is absolutely true! If is bad enough if you see something like that in a file dump but the programmer should have used a bunch of #defines so that the source made some kind of sense.In any event, working at the bare iron level will necessarily entail many hours decoding the user manual and/or datasheet. Many hours... And then the errata and then the forums and it still won't work until enough tears have been emitted.

author: julian1
author_rank: Frequent Contributor
timestamp: August 05, 2017, 12:20:08 am
content: Beware of hardware bugs in the implementation, which lead to incompatibility with standard x86. Also no microcode updates,https://news.ycombinator.com/item?id=14851034https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575

author: hamster_nz
author_rank: Super Contributor
timestamp: August 05, 2017, 09:01:30 am
content: Ah the memories it brings back.In the old 386 days I wrote my own DOS extender in assembler, to allow me to write a MOD file player using 32-bit code rather than the old 8086 segmented real mode. It was something like this....- Build the Local and global descriptor tables that mapped virtual memory addresses to physical memory- set up a whole lot of hardware interrupt mapping, which can then call the BIOS ISRs in real mode.- tell the keyboard controller to enable the AND gate on A20- set up a new reset vector by mapping out the old one- get the keyboard controller to reset the CPU, to make it jump to the 'new' reset vector- then had to use 'bounce buffers' for DMA, as the soundcard could only DMA from the first MB of RAMGood timesThere are now so many kludges on top of kludges on top of workarounds that it really would not be fun to do Intel bare metal any more, unless you want to rediscover a whole lot of knowledge that should remain forgotten... HDD addressing limits is one that comes to mind.x86 has gone from a 16-bit CPU at most a MB of RAM, with a couple of 360kB floppies, to hyperthreaded multicores 64-bit CPUs, 100s of GB of RAM, and TBs of disk, with multiple nested virtualization layers. That deep under the hood it is pretty krufty, if you know what I mean.

author: rstofer
author_rank: Super Contributor
timestamp: August 05, 2017, 04:38:38 pm
content: And yet DOS can be blistering fast even on a 100 MHz 486. Turbo Pascal runs very well and its executable output also blazes.Different processor but I rather enjoy CP/M on a 50 MHz Z80. It smokes...Can you image what DOS would do on a bare bones multi-GHz CPU?The machines get faster and the programs get bigger. The CP/M Macro Assembler was about 35k bytes IIRC.

author: agehall
author_rank: Frequent Contributor
timestamp: August 05, 2017, 04:47:32 pm
content: Quote from: rstofer on August 05, 2017, 04:38:38 pmIsn't that pretty much Linux these days? (Without all the horrible GUI ofc)

author: rstofer
author_rank: Super Contributor
timestamp: August 05, 2017, 07:17:23 pm
content: Quote from: agehall on August 05, 2017, 04:47:32 pmNot with multiple layers of the Linux kernel in the middle. The thing about DOS, derived from CP/M, is that it gets right at the hardware in very few layers. For CP/M, the BIOS layer talks to hardware (in very few instructions), the BDOS layer interfaces between the user and the BIOS, providing a file system plus the ability to send/receive strings to/from the devices provided by BIOS. That's it!Think about how much stuff the Linux kernel needs to boot! I can boot CP/M, run a program and head out on a coffee break before Linux boots.Now, pretty much everything the Linux does is required by the expectations of the users. CP/M did it the other way around: Here's what you get, knock yourself out! Then again, 64k was a big machine with CP/M.

author: alm
author_rank: Super Contributor
timestamp: August 05, 2017, 07:33:14 pm
content: Quote from: rstofer on August 05, 2017, 07:17:23 pmEmbedded systems, and desktops/laptops with Coreboot, can boot in a few second from power-up. How much faster does CP/M boot? Including BIOS? By your description, it should be under 100 ms from power up. Now add the time it takes to load networking.Close to the hardware sounds fun, until you figure out how complicated that hardware has gotten. Writing a DOS program with USB and wireless networking would take months. Sure, you can offer them as standard libraries, but at that point you might as well add them to the OS, and you would be complaining about the OS getting bloated.

author: rstofer
author_rank: Super Contributor
timestamp: August 05, 2017, 08:10:46 pm
content: In the case of CP/M, specifically, boot usually starts when the processor resets and maps a ROM into the low address space. The ROM reads a few sectors from the HDD, stuffs them in high memory and, voila', the machine is up and running (after it maps RAM back where it belongs in low memory. Timing is totally dependent on the HDD and for a Compact Flash, it's pretty darn fast.I would say, without a shred of proof, that my 50 MHz Z80 boots in about 1/2 second. The longest delay is probably writing the sign-on message to the screen. Serial IO, even at 115,200 baud is pretty slow. And, yes, I just tried it.But, CP/M doesn't have USB, it doesn't have networking, it doesn't have virtual memory. It doesn't have anything at all compared to a modern system. But it boots in a real big hurry! You can also cause it to load and execute a particular program at startup so the existence of CP/M is not even mentioned.No comparison to a modern OS!Here's a link to an older post that has a photo of my Zilog Z80 board on the right and my daughtercard with a pair of USB serial ports and a Compact Flash device on the left.https://www.eevblog.com/forum/vintage-computing/for-a-vintage-computer-project-which-processor-is-easier-to-use/msg1253075/#msg1253075

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: August 05, 2017, 08:31:33 pm
content: Quote from: alm on August 05, 2017, 07:33:14 pmMonths? The way I code it probably would, and that is totally unacceptable. If it would take longer than 20 minutes we won't do it (actual quote from manufacturer, when asked to fix a serious software bug which was upsetting all our customers!).

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: August 05, 2017, 08:47:48 pm
content: Quote from: rstofer on August 05, 2017, 08:10:46 pmMS-DOSdoeshave USB and networking, and boots in milliseconds from ROM.Virtual memory is a disgusting hack that slows the system down 100 times or more - why would we want that? Oh yeah, to run those bloated apps....

author: hamster_nz
author_rank: Super Contributor
timestamp: August 05, 2017, 08:56:37 pm
content: Linux is booted as soon as 'init' is run, the rest is messy userland stuff.If you build a kernel including only the drivers you need, and use something like BusyBox, with a static IP you can have a working command prompt a couple of seconds after the boot loader is called.But that BIOS sure can take a while!

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: August 05, 2017, 09:04:58 pm
content: Quote from: Sal Ammoniac on August 03, 2017, 10:26:56 pmI don't know much about bare metal on Intel since 80286, but it sounds like you are looking forhttps://software.intel.com/en-us/intel-system-debugger, and for Galileohttps://software.intel.com/en-us/articles/using-intel-system-debugger-with-openocdI guess the first thing to do if writing an RTOS like this, is to create a monitor/boot code like uboot/gdb server, which allows you to load RAM, program Flash, execute code, set breakpoints and get trace output over a serial port (or better USB) and other debug type stuff.

author: westfw
author_rank: Super Contributor
timestamp: August 06, 2017, 03:20:40 am
content: QuoteUm. No.The most notable Consumer of Many Cycles on a modern desktop is almost certainly that big, beautiful, bitmap graphics display that you have connected, and all the compressed content that you're throwing up on it. Stick to text, using whatever character mode display modes your graphics card happens to support (for the bios?), and nearly anything will run "really fast." Not that you'll need it to, any more...(People who haven't written code for an old-style bitmap graphics card (CGA, original VGA, "Hercules", no "acceleration", no special "CPU engine") have no idea just how compute intensive graphics is...)

author: janoc
author_rank: Super Contributor
timestamp: August 06, 2017, 09:18:09 am
content: Quote from: Bruce Abbott on August 05, 2017, 08:47:48 pmTell that to IBM who has introduced it on their System/360. I am sure they were trying to run those bloated apps tooI suggest that you try to understand the problems that VM solves first before you call something a "disgusting hack". But if all you ever wanted is to run a single program on the CPU, then you really don't need virtual memory. Good that all computers are just PCs running spreadsheets, right?