boards/cpu: Add GBA boot support to RIOT#19519
Conversation
cpu/arm7tdmi_gba/stdio_fb/stdio_fb.c
Outdated
|
|
||
| static void clearScreen(void) | ||
| { | ||
| memset(GBA_VRAM, 0x00, 240 * 160 * 2); |
There was a problem hiding this comment.
Let's use a define for width and height, we can likely reuse this code for other displays.
Why the * 2? Is this double-buffering or do we have 16 bit/pixel?
(I don't see any flip buffer / commit command - how (often) is the framebuffer sent to the display?)
There was a problem hiding this comment.
I added the define for the screen size, got lost during refactoring oops.
The * 2 is indeed because of 15 bit/pixel yes, 15 - at least in the display-mode selected for stdio_fb. The graphic options/settings/modes are impressive for such a little device. When a proper "gpu driver" is added in the future (not in this PR), this will probably get a rework. I hence just added a comment for now.
There is no dedicated flip, the gpu redraws the current memory in the buffer automatically with ~60FPS. Ideally, you would wait for h-blank and then update the buffer, otherwise you'll get tearing. In this first PR, I just accepted that. :) By the way, the GBA can also do double-buffering if you ask nicely.
| /** | ||
| * @brief Stack size used for the interrupt (ISR) stack | ||
| * @{ | ||
| */ | ||
| #ifndef ISR_STACKSIZE | ||
| #define ISR_STACKSIZE (400) | ||
| #endif | ||
| /** @} */ | ||
|
|
||
| /** | ||
| * @brief Stack size used for the fast interrupt (FIQ) stack | ||
| * @{ | ||
| */ | ||
| #define FIQ_STACKSIZE (64) | ||
| /** @} */ | ||
|
|
||
| /** | ||
| * @brief Stack size used for the supervisor mode (SVC) stack | ||
| * @{ | ||
| */ | ||
| #define SVC_STACKSIZE (400) | ||
| /** @} */ | ||
|
|
||
| /** | ||
| * @brief Stack size used for the user mode/kernel init stack | ||
| * @{ | ||
| */ | ||
| #define USR_STACKSIZE (4096) |
There was a problem hiding this comment.
If you find more things that should rather be in arm7_common (because you copied them verbatim from lpc23xx) better move them there instead of creating a copy.
There was a problem hiding this comment.
I updated the file. I don't think it can be moved to arm7_common as the GBA differs a lot - I yet have to figure out how to translate "technical hardware description" into config file ;-) e.g. I changed most stacks to zero bytes as the GBA won't have these stacks (except the ISR, thats just not implemented yet).
|
you may squash if you want! |
18efd72 to
95daad1
Compare
|
you may squash if you like. I also don't know about this introduce Makfile.default on this PR... might be a bit much (though a good idea). |
|
Ahh you are also getting the rust failure... |
Ahh seems like it is already a thing in RIOT (I learn something new everyday) |
MrKevinWeiss
left a comment
There was a problem hiding this comment.
Not that I understand the internals of the GBA or the assembly but I believe @Teufelchen1 will be responsible for this and what I do know looks good. I tested it previously and saw it running. If murdock passes I think it is fine! ACK!
|
if you rebase I bet it will pass now :) |
|
Rebased + removed periph_pm from the provided features in a fixup. This should work now... x.x |
|
🎉 |

Contribution description
Hi! 🦦
After my draft showcasing threading & gpu acceleration support in #19430, this PR is the first step towards that goal.
Included are the following features:
gba_cartridge. In the GBA-ecosystem, the CPU/SoC/etc. is always the same, however, cartridges might bring their own ROM, RAM, RTC, ... - This firstgba_cartridgeboard doesn't add any features and is hence empty. The always required boot-rom is indirectly added via the cpu support. Here I need your help: If one wanted to add an othergba_cartridge_extra_ram, which features additional RAM (e.g. the Pokemon games do this!), the linker script needs to be adjusted. This script lies in the cpu folder. How could we model that in RIOT?arm7tdmi_gba. I choose this name as the GBA features an ARM7TDMI but with typical Nintendo limitations/changes. The support is very limited and this PR sets the focus on getting RIOT to build and boot. Here I need your help: What is the correct way to blacklist features that are not supported yet? e.g. Threading.This logo is included in this PR. From what I can see in the homebrew-scene, people don't care anymore (and so did the uCLinux people back in the day) and it is unlikely for Nintendo to pursue legal actions. However, we might skip the risk and ask the user to provide a valid header file themselves. Update: I removed the logo, most emulators do not check the logo anyway.stdio_fbrenders text to the LCD screen of the GBA. It brings it's own font. Help: Does RIOT already have it's own font? Could/ Should this driver be generalized and moved to the other stdio drivers?periph_cpu.h, many GBA special purpose register are listed. Help: Is that the correct location for such defines? As for the names, I tried to stick to the common naming convention of the homebrew-scene, mostly influenced by the "devKit pro".Testing procedure
Grab an emulator of your choice. E.g. mgba. Then:
cd RIOT/example/hello-world BOARD=gba_cartridge make mgba bin/gba_cartridge/hello-world.bin