Idea: Bootrom that maintains control, serves as tiny "OS" layer

#1

Originally here: Self Bootloading Mod-Chip

Making this it’s own topic to live in though for those interested in the idea or applications of.

Has anyone discussed the idea of simply having the boot loader never release the interrupt table? I’m pretty sure you can do this with ONLY a modified boot loader - and zero support from applications themselves - they wouldn’t even be aware of the boot loader running silently in the background.

But the idea:

Basically the boot loader simply “proxies” all the interrupts to the sketch - instead of transferring the vector table to address 0 (as it typically done). Whatever interrupt Arduino already uses for timekeeping seems like the perfect “systick” interrupt. The bootloader could simply run its own internal code before jumping to the sketch’s own time keeping interrupt.

So essentially every 1ms or so the boot loader code would still be actually running… so any “hardware” functionality you wanted to build in could be be built on top of that. Such as checking for reboot keystrokes, etc… or even sleep/wake at the device level… and this code would live in the boot loader, not the application.

So one idea could be to keep the 4kb boot loader size but expand the functionality with something like this and a bit more “hardware” support… for things like volume, flashlight, boot logo, etc…

Yippy, so you can do it in theory. The boot loader is responsibility for moving the interrupts TO the boot loader (when it starts) and then as it fires up the application it moves the interrupts back into application space. So we’d simply NOT do that last step… and instead proxy them. So then regardless of how the application was compiled or with what libraries it could still have “hardware level” features like flashlight, boot logo, reboot keystrokes, etc… it would be purely a feature of the boot loader.

If an application REALLY REALLY wanted to disable the hardware functionality, they just could relocate interrupts purely to user space themselves, but I don’t know why most people would do that?

This approach would work fine regardless of boot loader size… ie you could do it with a 3kb boot loader too, just with 4kb you’d have more room for hardware functionality I’d think.

Of course it’s all a bit theoretical UNLESS/UNTIL we build new hardware - since it would require a custom boot loader - and AFAIK there isn’t a super easy way to refresh the Arduboy’s bootloader now. So it might be something that only worked on say generation 2 devices.

But when you do that the advantage is: it all “just works”. You have 200 old Arduboy games that know NOTHING about a pause button or sleep/wake… or the “reboot key sequence”… and yet they all would magically support these new features - without needing to be recompiled.

2 Likes
Self Bootloading Mod-Chip
#2

I assume we already had that with Arduboy2?
Volume control on splash screen… flashlight during powerup …
I mean, the regular Arduboy library also had flashlight control. Arduboy2 just did it slightly better.

As we had done here. After splash screen, sketch loads, blah blah …

Depends on how many function you want to put in, but 4KB should be sufficient.

When you would leave out the … (what do you call the 2 x 3) pins and also put a USB coder on the shelf

What if they don’t really need to support these new features?

That would be a bit like the Arduboy game loader (can’t remember the name) thing.

I think what he was saying is that we put in a bit of code in our bootloader sector that just takes all the hardware input. The sketch will “read” the input through the “handles” given from the bootloader, or if they wanted to, access the hardware directly.

I think we can have a bootloader that “moderates” all controls and the sketch will NOT access the hardware directly.

That would be like DWM (desktop window manager). When you press a key on the keyboard (press a key on the Arduboy) the active window will receive a WM_KEYDOWN message (the sketch will receive a message telling them a key is pressed). Then the sketch can do whatever it does and returns output (to bootloader?) to be drawn on screen (or to be drawn on screen directly).
“New Hardware” like the Arduboy Crank will, say, generate a string of KEYDOWN messages. This can make the implementation of joysticks easier. The bootloader would handle it rather than the sketch.

Sounds like a … idea.
But it would also mean a major code rewrite, and the hassle with “switching to new codebase” would be somewhat difficult?
But existing work would work well. They will just need to be recompiled.

The existing .hex file is written to tell the microcontroller to poll direct input. Try to run bootloader against its will … I don’t think it’s going to work.

#3

No, I’m not talking like a BIOS. That’s a neat idea though. The sketch would still be running natively against the REAL hardware… the only thing we’d be coopting is the interrupts (and boot, but the boot loader already coopts boot, so that’s nothing new)… which allows us to run a little code periodically…

Hardware this simple doesn’t really need a HAL (hardware abstraction layer).

That allows us to support a reboot/switch ROM sequence at the hardware level. Such that it always works regardless of which library your compile against or which features of said library you decide you have room for or not. Right now often people compile out the logo or flashlight because they “ran out of space”. You shouldn’t be able to compile out the “switch roms” feature… no matter how cool your game was. Putting it in the reserved boot rom areas solves that problem.

Now since there is no such things as protected memory or anything the sketch could always MANUALLY move the interrupt table, thereby reclaiming REAL interrupts… but I can’t think of a reason a sketch would need to do that. It would only break things like switching ROMS, with no upside - there is no space to reclaim - since that space is locked away inside the boot loader.

The existing .hex file is written to tell the microcontroller to poll direct input. Try to run bootloader against its will … I don’t think it’s going to work.

What I’m suggesting would “just work” with all existing sketches. They would have no idea the interrupts were stolen. Well, we might need a few bytes of RAM (which we’d steal from the top of the stack)… but that would work with all sketches except those that literally were SOOOO memory tight the they were already optimized down to the exact amount of RAM the stack uses - which is pretty poor design since the compiler could optimized a function differently and frack you in the future without warning.

#4

That’s all software, not hardware. You can easily flash the Arduboy such that NONE of that works… no logo, no flashlight, no volume control… if all that was in the boot loader it would just work even if your Arduboy was flashed with nothing but 0s.

[I know technically it’s all software, but the boot loader is a lot “hardware” level since it can’t be modified and is always present.]

1 Like
#5

If they wanted to, they always can … just like how we “throw away” the code for rawADC, but I still use it in my games to check battery voltage.

Doesn’t sound to be the safest way of doing things, but again, might “just work” well.

I had hit the RAM limit (AND the ROM limit) when developing my Asteroids game. But I am able to substitute manual fixed point rather than floating point, so RAM was down to about 60%.
But in some games you simply can’t reduce the amount when it’s jam-packed with int8_ts already.
They can try to ‘reuse’ them, but there are times when you can’t – and there probably has been more cases than ever.

#6

It’s not necessarily unsafe at all. It’s actually a pretty common little trick going way back to DOS and TSR (terminate and stay resident) programs (or further?). I’m not familiar with it being used here but don’t see why it couldn’t be used to great effect.

we might need a few bytes of RAM

Key word being might. Just to detect keystrokes you don’t really need any RAM… and in any case there are always a few bytes you can steal from the top of the stack that are never used by anything in any case.

1 Like