A few short changes to the write-up

This commit is contained in:
Adam Greenwood-Byrne 2021-02-21 21:47:59 +00:00
parent 65560deb5a
commit e409b722b9
2 changed files with 9 additions and 8 deletions

View file

@ -5,7 +5,9 @@ Using multiple CPU cores
------------------------ ------------------------
Instead of a background DMA transfer, I suggested that we might use a second CPU core to play the audio whilst our main core continues on. I also said it would be hard on the Raspberry Pi 4... and it is. Instead of a background DMA transfer, I suggested that we might use a second CPU core to play the audio whilst our main core continues on. I also said it would be hard on the Raspberry Pi 4... and it is.
This code isn't great yet, but it's enough to prove the concept in principle. Importantly, you'll need to modify your _config.txt_ file on your SD card to include the following lines: I wrote this code as I referenced [Sergey Matyukevich's work](https://github.com/s-matyukevich/raspberry-pi-os/tree/master/src/lesson02), for which I am very grateful. It did need some modification to ensure the secondary cores are woken up when the time is right. This code isn't particularly "safe" yet, but it's good enough to prove the concept in principle.
Importantly, you'll need to modify your _config.txt_ file on your SD card to include the following lines:
```c ```c
kernel_old=1 kernel_old=1
@ -13,11 +15,11 @@ disable_commandline_tags=1
arm_64bit=1 arm_64bit=1
``` ```
For now, the points of interest in the code are: For now, I'll signpost the following points of interest in the code:
* The new _boot.S_ and related _boot.h_ loader * The new _boot.S_ loader and related _boot.h_ header
* The new _multicore.c_ and _multicore.h_ files * The new _multicore.c_ library and related _multicore.h_ header
* A slimmed down _io.h_ and _kernel.c_ (DMA sound removed), with a new approach to `main()` * A slimmed down _io.h_ and _kernel.c_ (DMA sound removed), with a new multicore approach to `main()`
* A revised _link.ld_ * A revised _link.ld_ adding provisions for the secondary core's stack and the 0x00000 entry point (a result of setting `kernel_old=1`
I will write more soon! I will write more soon to attempt to explain what's going on here.

View file

@ -7,4 +7,3 @@ unsigned long load32(unsigned long address);
void start_core1(void (*func)(void)); void start_core1(void (*func)(void));
void start_core2(void (*func)(void)); void start_core2(void (*func)(void));
void start_core3(void (*func)(void)); void start_core3(void (*func)(void));
unsigned int get_core_number(void);