-1

I am writing my RTOS for armv8 arch and I am using u-boot. Now when my board booting it switchs in EL1. But I can not write/read any values. Is there a way to disable translation table? Or is the problem elsewhere? Thanks advance for answers :)

Lino
  • 7
  • 4
  • Translation tables are disabled by disabling address translations, should sounds right... And translations are controlled by MMU. Disable MMU and there is no need in translation tables. But before you get too excited, remember that disabling MMU also disables translations of instruction addresses. – user3124812 Sep 04 '21 at 22:46
  • I disabled the MMU before switch EL1 but I have this problems. I/O ports are accessible but my binary freeze in EL1. It's working well in EL2. Maybe some bits in MMU registers locks the memory access at 0 address – Lino Sep 05 '21 at 02:57
  • 1
    No, MMU does not have 'lock' bits. And as an advise, describe your question clearly. Like stating that MMU is turned off, caches are cleaned, what sort of values you are reading properly and what are fails, if instructions are executed, and what the hell 'my binary freeze' means. That way you have much better chances to get an answer. – user3124812 Sep 05 '21 at 05:23

1 Answers1

1

I disabled the mmu with sctlr_el1, Anyway I added some asm code and I can read the ram. The code generated by gcc halt the cpu, Here's the .s files

ldr   w0, =__bss_size

it's working

adrp x19, __bss_size ldr w0, [x19, #:lo12:__bss_size]

it is generated by gcc and it is not working

Lino
  • 7
  • 4
  • Those do different things. The `=__bss_size` one sets w0 = a symbol address (or the low 32 bits of it I guess) and may not involve a load at all; the other loads from that address. If the `__bss_size` symbol's "address" isn't really an address, but instead a size, that would obviously be problem. Or if the =symbol one doesn't load at all, then it can work with only code-fetch, no data load/store. Use a disassembler to see. – Peter Cordes Sep 05 '21 at 08:56
  • BTW, this seems like a weird thing to post as an answer to your question, since you don't mention how to get GCC to generate the thing that works. If that's even what you want. If this wasn't intended as an answer, delete it and edit your question. – Peter Cordes Sep 05 '21 at 08:57
  • The bss_size is a variable and it fills during the compilation, in the ld script. My code reads directly from ram at address 0x285000. The gcc code reads another address. Maybe the alignment throw an exception...it's aligned 0x4 instead 0x8. – Lino Sep 05 '21 at 09:35
  • In ARM asm syntax, `ldr w0, =foo` sets w0 to the *address* of `foo`, unlike `ldr w0, foo`. So that code just sets w0 = 0x285000 but doesn't load from there. Look at the disassembly. Also, GCC's load is only 4-bytes wide so it is naturally aligned. – Peter Cordes Sep 05 '21 at 09:41
  • Just I copy & paste :) https://github.com/bztsrc/raspi3-tutorial/blob/master/0F_executionlevel/start.Sw – Lino Sep 05 '21 at 10:43
  • Oh, so you *are* using the symbol "address" as a size value like in that tutorial. So loading from it as an address doesn't work. In C, you'd need to do `size = (size_t)&__bss_size` to get the compiler to emit `ldr w0, =__bss_size` and use the address, not load from it. In C, using a global variable name implicitly dereferences its address, unless it's an array like `extern char __bss_size[];`. I assume you wrote some C that didn't do that, but didn't bother to mention that in the question or answer. – Peter Cordes Sep 05 '21 at 11:23
  • I am just checking the code to find the reason because it is not working in EL1. It is working in EL2, may be the code throw an exception for unaligned address. I am just using objdump with elf for disassembling the code. Anyway thanks for help ;) – Lino Sep 05 '21 at 16:18
  • Solved. Added code for initialization global variables in start routines. – Lino Sep 07 '21 at 14:21