Is the Pokitto boot process documented as well?
1 Like
What part of the process are you interested in?
1 Like
I’d like to have an overall review, such as when Pokitto is powered up, what gets executed first? What stages follow (any BIOS like HW tests etc.?). Where does the “press C for loader” screen come from? How does the loader work?
I don’t need any specific information ATM, I’ve been just curious (after reading about your new loader) and couldn’t find the info.
OK, off the top of my head:
- When it’s powered up the ROM reads the flash and checks for a valid checksum. If the checksum is correct, it sets up the vector table, loads the stack pointer and jumps to the entry point (the ResetISR). More info on this is in the technical reference manual.
- The ResetISR is in
PokittoLib/mbed-pokitto/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/TOOLCHAIN_GCC_ARM/TARGET_LPC11U68/startup_LPC11U68.cpp, This initializes the BSS and data sections in RAM. - It then calls SystemInit in system_11u68.cpp, which initializes a bunch of hardware registers. What the specific registers do is also documented in the TRM.
- Constructors for all the global C++ classes are called.
- int main() is called
- Pokitto::Core::begin initializes more registers and the LCD, displays the “Pokitto” logo, “press C for loader”, etc. This is all in PokittoLib/POKITTO_CORE/PokittoCore.cpp.
- If you “press C for loader” the PokittoLib will shutdown part of the CPU to put it into a known safe state and activates the loader in a way similar to the ROM activating the initial app.
Edit: looked up the file names/paths. 
2 Likes
Missed this question in the previous post…
The Loader is a regular application (…ish) that is stored in a specific location in flash. The PokittoLib looks for a struct in a fixed address (0x3FFF4). This struct has information like a magic and a version number, and a pointer to the loader’s vector table. With that, the lib knows if the loader is valid or not, if the version in the SD is newer, and where it has to jump to to start.
Once the loader is activated, it initializes the hardware again. It does not use the PokittoLib, but it does use PFFS and the mbed APIs. When you select a game the loader uses functions built-in to the LPC11U68’s ROM for writing to the flash. You can look at iap.h to see how that works, but it is also documented in the TRM.
3 Likes
@FManga explained it better than I could, and I wrote the loader 
One important note about the “jump” from the main program to the loader program.
One thing that I fought with is the fact that “jumping” from one memory address to another and continuing execution there is not a simple matter of changing the PC (program counter) value.
When you reset, all of the internal registers of the MCU are in an initialized (zero) state. This is not the case when you jump from main application to loader - things like interrupt requests are still enabled and will cause havoc if care is not taken to disable them.
Before the main application jumps to the loader, it effectively disables and shuts down power to peripherals etc. The loader re-initializes the MCU, almost like a reset would. That is why you can see the display flick when the jump occurs.
2 Likes
Thank you, some words I’ve never heard but after reading a bit of that MCU manual and the Pokittolib source I think I get the idea.
I can’t seem to be able to find much about the ROM in the TRM. From what you’ve written it looks like kind of a BIOS? It contains executable code for basic HW handling, and you’re not supposed to be fiddling with this ROM, which is why it’s ROM, okay? I’d then also suppose the code is proprietary? (Just out of curiosity, I can live with small proprietary lowlevel code that’s on the borderline of HW and SW, my laptop still has it too.)
The TRM documents the API exposed by the code in the ROM. There are useful functions there that you can call, but the sourcecode isn’t available. This isn’t a problem: it’s read-only memory after all, so you wouldn’t be able to do anything with the code if you had it.
Unlike a PC’s BIOS, which resides on a flash and can be updated, this code is burnt-in permanently. Its part of the hardware, and this is good because it makes these chips (almost?) impossible to brick.
AFAIK, you can read the ROM just like any other memory, dump it to the SD card then disassemble it… but its a bad idea to do so. The manufacturer could make changes to future revisions of the hardware and anything that depended on undocumented behavior could break.
2 Likes
Yeah, I mean this is okay, I’m pro open HW as well, but I don’t think this is a problem that (unlike with software) is highly alarming at this moment.
For the curious: the FSF draws a line as well – their Respects Your Freedom criteria say this kind of proprietary code is acceptable on secondary embedded processors unless there is a free alternative, which is almost the case here, except the MCU is not secondary, it’s the main processor of the system. It’s close enough to me though 
1 Like
when I try to make a image for pokitto in photoshop I know it is 220x176 what pixel resolution do I use?
Well exactly 220 x 176? Not sure what you want to know. Just make sure to go in image size and set it to that same dimension.
its just some thing the photoshop was doing, I switched back to gimp
2 Likes