Intel Bare Metal Programming

[Sal Ammoniac]

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?

[alm]

Why would you would want to get into a discontinued product when 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.

[mikeselectricstuff]

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".

[westfw]

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.

[alm]

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.

[Sal Ammoniac]

Why would you would want to get into a discontinued product when 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.

Two 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

[Sal Ammoniac]

I don't know those boards based on full x86, but those reduced x86 chips such as Quark D or Curie (Quark SE) can be coded bare metal with Intel's IDE, but they prefer you to use their free RTOS (vaguely remembered to be WindRiver based).

I'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.

But even the simplest Galileo (Quark X) has on chip PCI(e) peripherals and a lot of other system buses. I wouldn't touch it without an OS. There is paid (or maybe even free) Intel RTOS (WindRiver?) for those need instant boot time, and for most people, there is the free Yocto Linux. I really don't see a need for bare metal programming.

Again, the whole point here is writing my own RTOS, so I have no interest in WindRiver VxWorks or Linux.

Visual Studio is just an IDE, it can be used with any compiler. It comes with Windows SDK, which has Microsoft compilers (VS6 and earlier comes with paid IDE, then starting from .NET, MS started to provide compilers for free, and they only charge for the IDE).

Can Visual Studio interface with a J-TAG debugger over USB and remotely debug code?

[Sal Ammoniac]

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.

I 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.

[rstofer]

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.

[alm]

That is possible, but reverse engineering reg_72 = 0x48414d4d455201 is a lot more painful than reading a datasheet that defines the registers.

[rstofer]

That is possible, but reverse engineering reg_72 = 0x48414d4d455201 is a lot more painful than reading a datasheet that defines the registers.

That 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.

[julian1]

Beware of hardware bugs in the implementation, which lead to incompatibility with standard x86. Also no microcode updates,

https://news.ycombinator.com/item?id=14851034

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575

[hamster_nz]

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 RAM

Good times

There 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.






 
 

[rstofer]

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.

[agehall]

Can you image what DOS would do on a bare bones multi-GHz CPU?

Isn't that pretty much Linux these days? (Without all the horrible GUI ofc)

[rstofer]

Can you image what DOS would do on a bare bones multi-GHz CPU?

Isn't that pretty much Linux these days? (Without all the horrible GUI ofc)

Not 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.

[alm]

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.

Embedded 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.

[rstofer]

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

[Bruce Abbott]

Writing a DOS program with USB and wireless networking would take months.

Months? 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!).

[Bruce Abbott]

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...

No comparison to a modern OS!

MS-DOS does have 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....

[hamster_nz]

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!

[donotdespisethesnake]

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?

I don't know much about bare metal on Intel since 80286, but it sounds like you are looking for https://software.intel.com/en-us/intel-system-debugger, and for Galileo https://software.intel.com/en-us/articles/using-intel-system-debugger-with-openocd

I 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.

[westfw]

Virtual memory is a disgusting hack that slows the system down 100 times or more

Um.  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...)

[janoc]

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....

Tell that to IBM who has introduced it on their System/360. I am sure they were trying to run those bloated apps too

I 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?