pxlnpx wrote:the dwarf info unfortunately gets "corrupted"
I'm sorry, I can't give you cut out instructions here. The best advice I can give you is to try different configurations until the addresses in dwarf info became correct. Having debug info in the elf only and not in the img shouldn't be a problem, so including debug section into text segment is just optional.
pxlnpx wrote:In the process of studying the arm processor by following bzt's tutorials an interesting question emerged: can raspberrypi be deployed in a big-endian mode?
Yes, and you have already done that
It worth mentioning that if you implement virtual memory, you must set big-endian enable bits in the paging tables too.
There are still few open questions:
- could start.S be reduced in the sense of fewer assembler instructions?
Probably. My goal was to create easily distinguishable blocks for education, and not optimalization. Although _start is quite small, and only executed once during boot, so optimization doesn't worth it imho.
pxlnpx wrote:[*] what is the purpose of "msr sp_el1, x1", or why do we need "mov sp, x1"?
Probably. The first one sets the stack for exception handlers (while running in EL2), the second one sets the current sp (running in EL1). There's a good chance you never start your kernel at EL1, therefore the eret is always executed, and sp is always loaded from sp_el1.
pxlnpx wrote:[*] is it correct that cores 1, 2, 3 stay in EL2?
Yes. Simplicity was my goal. For a full-blown implementation, take a look at my bootloader's boot.S
. It sets up all cores (EL1, virtual mappings, etc.), loads an ELF from an initrd, maps it in higher half (-2M) and starts executing it on all cores. Except for the stack, all cores are intialized equally.
pxlnpx wrote:[*] how power-consuming is "1: b 1b"?
Very much. It's generating 100% CPU usage.
Use "1: wfe; b 1b" instead. The Wait For Event instruction puts the cpu core in a low energy consuption mode until it receives an interrupt (or some other similar event).
pxlnpx wrote:[*] the mailbox-interface is certainly not thread-safe? (Just for the case we later invent main0(), ..., main3() for cores 0, ..., 3 to enter, and just want to access mailbox from any of them.)
No, you should implement an exclusive access mechanism for it. Simpliest is a spinlock, so that only one CPU can write the mailbox MMIO address at any given time. By the way, the same stands for all MMIO addresses. It's not healthy either if more CPUs are trying to write the same UART registers concurrently for example.
Sorry for this big post.
Don't you worry