OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 2:44 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 7:51 am 
Offline

Joined: Tue Dec 04, 2018 7:38 am
Posts: 3
Hi all, I have a generic question. After I enabling mmu on arm (aarch64), supposedly, kernel will be run at the high end of the virtual memory space (starts from 0xffff0000'00000000 in my mmu), but the original start address of the kernel is 0x00080000 which is specified in the kernel's linker script. So some pointers, addresses in kernel binary are still based on the address 0x00080000 which is not mapped in my mmu. In my mmu, code should access 0xffff0000'0008xxxx instead 0x00000000'0008xxxx). How should I resolve this problem?

Thanks!


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 8:08 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
All addresses in your binary should be exactly like they are supposed to be. So if the address needs to be 0xffff0000'0008xxxx, it needs to be set that in the binary. Not 0x0008xxx.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 8:49 am 
Offline

Joined: Tue Dec 04, 2018 7:38 am
Posts: 3
The start address is 0x00080000 is required by the bootloader. The bootloader will load the kernel to 0x00080000 and jump to that address to execute. MMU is enabled in the kernel. If the kernel is addressed at 0xffff0000'00000000 in linker script, it can't be executed after bootloader loading it.


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 9:40 am 
Offline
Member
Member
User avatar

Joined: Sun Oct 22, 2006 7:01 am
Posts: 2646
Location: Devon, UK
Hi,

You have a couple options here. I'm approaching this from an x86_64 background but the principles should be the same.

* If your loader supports it, you could have an entry point at 0x00080000. I don't know your toolchain but with LD, make use of AT and a .boot section. Then your .code section should be linked at 0xffff0000'0008xxxx and you just make a jump when you have finished executing the lower-half code (and your code running in the higher half can then un-map 0x80000 - I'm not familiar with this MMU, though...).

* Alternatively, link the whole thing to 0xffff0000'0008xxxx - I assume (not knowing your toolchain...) that the loader will still place your code execute from 0x00080000 and as long as you jump to 0xffff0000'0008xxxx (to reload the PC) before you jump or load any other data, you'll be fine.

Cheers,
Adam


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 1:03 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
xybxyb wrote:
The start address is 0x00080000 is required by the bootloader. The bootloader will load the kernel to 0x00080000 and jump to that address to execute. MMU is enabled in the kernel. If the kernel is addressed at 0xffff0000'00000000 in linker script, it can't be executed after bootloader loading it.

Then it's a stupid loader, that asks to be thrown away, since it can't do its task. this is an example clearly showing all those "universal" loaders are useless garbage. Every OS should have its own OS loader that knows what its OS wants. Normal loaders run as firmware clients and using services of the latter do their work.

With this BS loader, not even being able to load things where they need to be loaded, you need to provide your own real loader, that will map your kernel properly. The question is whether that BS loader provides services for reading storage for your real loader to load, "shadow" your kernel into DRAM. What is the loader? What is the machine you work with? Is it a "virtual" crap or real one? Raspberry Pi? :lol:

Of course, you also could do trickery. But it's lame as hell. Given MMU isn't switched yet on, and thus 0x00080000 is a system address, as AJ suggested, you can create a special section/segment with this base and do all the mapping and MMU switching on there and then jumping into the real kernel point. Basically it's a linux way of putting everything into one pile of it. :?

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 4:08 pm 
Offline

Joined: Tue Dec 04, 2018 7:38 am
Posts: 3
Yeah, it is raspberry pi. :D

Thanks you guys. I'll try your's suggestions.


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 4:36 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
xybxyb wrote:
Yeah, it is raspberry pi. :D

Thanks you guys. I'll try your's suggestions.

First thing you need to be sure about, that that bootloader runs in aarch64, because otherwise, it would be hard to use that board as a 64 bit machine. I don't have this, you'd be better off to ask on the RPi forum.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Tue Dec 04, 2018 9:55 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 898
The way you make the Raspberry Pi boot in 64 bits mode is to add the following to your config.txt:

Code:
# Boot in 64-bit mode please
narm_control=0x200


You also need to use the right default name (kernel8.img) for your "kernel". Or you can specify your own name in the config.txt:

Code:
kernel = path/to/kernel/my64bitskernel


As for OP's issue: the RPi will load your elf at a fixed address, there isn't anything you can do about this. What I would recommend is have the RPi load your own bootloader that knows how to load the kernel and map it to high memory. This can be done by placing the real kernel into memory at a specified address. Again in the config.txt:

Code:
# Put my kernel in memory at 0x00100000
ramfsfile=path/to/real/kernel.elf
ramfsaddr=0x00100000


Eventually you'll want to put a real "ram fs" in memory with the kernel inside it. But for now this can get you going.

_________________
https://github.com/kiznit/rainbow-os


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Fri Dec 07, 2018 8:10 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
Hi,

First of all, your address is suspicious at least. I believe it's in the address gap, I don't think Cortex-A allows 48 bits virtual address space size.

Second, I've already implemented higher half loading on RPi3. You can use my boot loader which will load and map your 64 bit kernel at -2M. Example kernel with linker script provided of course. This loader will stop the APs, it will set up a stack, clear the bss, enable simd, switch to 64 bit supervisor mode (EL1) for your kernel.
How to use:
1. Copy bootboot.img as kernel8.img onto the SD card.
2. Create a directory and copy your kernel there as BOOTBOOT/INITRD
3. Enjoy!

Later, when you need to use a real initrd (eventually you will), just create an archive (tar, cpio etc.) with your kernel in it instead. Also create a text file BOOTBOOT/CONFIG with
Code:
kernel=(the name of your kernel executable in the initrd)
(In lack of a configuration file, it will simply load the first AArch64 ELF executable from the initrd.)

Another cool feature, if you don't like to remove and insert the SD card all the time (which is boring and could physically damage your card), you can upload the initrd over serial too. For that, remove BOOTBOOT/INITRD, and run this raspbootcom tool on your PC (thanks to contributors, java version also available).

If you want to go down on the long road and wish to write your own loader, then take a look at the source (MIT licensed), and also check my MMU tutorial on AArch64 which maps the MMIO in higher half.

Cheers,
bzt

ps: no need for config.txt any more. Just name the loader kernel8.img and it will be booted in AArch64 mode.


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Sat Dec 08, 2018 1:30 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
bzt wrote:
Hi,

First of all, your address is suspicious at least. I believe it's in the address gap, I don't think Cortex-A allows 48 bits virtual address space size.

Emmm, you are wrong. His address is correct. Cortex-A53, found in RPi3, is compliant with ARMv8 VMSA, and thus it provides two 48 bit address spaces at maximum, resulting in 512TB of total addressable memory.
The architecturally unused gap you are talking about is between 0x0000_FFFF_FFFF_FFFF and 0xFFFF_0000_0000_0000

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Sun Dec 09, 2018 1:42 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
zaval wrote:
Emmm, you are wrong.
Am I? Read the doc more carefully, DDI0587 (page D5-2401):
Quote:
If {I}PS is programmed to a value larger than the implemented PA size, then the PE behaves as if programmed with the implemented PA size, but software must not rely on this behavior. That is, the output address size is never larger than the implemented PA size.
And what does ID_AA64MMFR0_EL1 tell you about PA size on an RPi3? See?

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Sun Dec 09, 2018 2:07 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
bzt wrote:
zaval wrote:
Emmm, you are wrong.
Am I? Read the doc more carefully, DDI0587 (page D5-2401):
Quote:
If {I}PS is programmed to a value larger than the implemented PA size, then the PE behaves as if programmed with the implemented PA size, but software must not rely on this behavior. That is, the output address size is never larger than the implemented PA size.
And what does ID_AA64MMFR0_EL1 tell you about PA size on an RPi3? See?

Cheers,
bzt

Yes, you are. You have confused "physical" addresses with "virtual" ones. His address is the latter, your quotes are about the former. And this line of you:
Quote:
First of all, your address is suspicious at least. I believe it's in the address gap, I don't think Cortex-A allows 48 bits virtual address space size.

proves this confusion of VAs and PAs. The "gap" exists only in the former. Limitations of the size your quote is talking about are applied to the latter.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Mon Dec 10, 2018 7:17 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
zaval wrote:
Yes, you are. You have confused "physical" addresses with "virtual" ones. His address is the latter, your quotes are about the former.
Is that so? :-) The quote is about the relation between PA and VA on the ARM. I think you are the one who confused x86 and ARM. On ARM the virtual address size (called "output address size" in the quote) is not fixed, it must be configured. Physical address bus width ("input address size" in this context) is not and cannot be software configurable, simply because that's hardwired into the chip. And that quote makes it perfectly clear that you cannot program VA size larger than the actual PA size.

Btw, have you ever tried to implement paging on RPi3?

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Mon Dec 10, 2018 8:30 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
bzt wrote:
zaval wrote:
Yes, you are. You have confused "physical" addresses with "virtual" ones. His address is the latter, your quotes are about the former.
Is that so? :-) The quote is about the relation between PA and VA on the ARM. ... On ARM the virtual address size (called "output address size" in the quote) is not fixed, it must be configured. Physical address bus width ("input address size" in this context) is not and cannot be software configurable, simply because that's hardwired into the chip. And that quote makes it perfectly clear that you cannot program VA size larger than the actual PA size.

Btw, have you ever tried to implement paging on RPi3?

Cheers,
bzt

dude, seriously, RTFM. Output address is PA. Always. It's from the MMU pesrpective - input is VA, output is (I)PA. And the quote you showed doesn't touch VA at all:
Quote:
If {I}PS is programmed to a value larger than the implemented PA size, then the PE behaves as if programmed with the implemented PA size, but software must not rely on this behavior. That is, the output address size is never larger than the implemented PA size.

PS field is "Physical address size". Or "intermediate physical address size" if HV is involved. "Output address" is physical address. It has nothing to do with VA space paramteres. Basically, it's about correct relation between writable TCR.(I)PS and hardwired ID_AA64MMFR0_EL1.PARange. Both of them describe physical addresses spaces only (as their names suggest).
Quote:
For each enabled stage of address translation, TCR.{I}PS must be programmed to maximum output address size for
that stage of translation, using the encodings as shown in Table D4-5.

"Each stage" here doesn't mean multi-level Page Tables, it means that it's either 1 stage VA->PA translation (a normal scenario) or 2 stage VA->IPA->PA (braindead HV scenario). For page tables it's termed "levels", and here - "stages". In both cases of this organization, (I)PS means "physical" address space size, "output address" means "physical" address.

VA space could be up to 512TB even if your system space is limited to only 4GB, with MMIO incl. as with the current Rockchip chips for example. It's up to the OS designer how much of "virtual memory" to support. The way you misunderstood, a so called "higher half" of VA spaces, is not possible at all on systems with the system space size less than or equal to 4GB, - thus on almost all SoCs found in modern SBCs. But it's not true! You just keep confusing things.
And of course, the kernel is loaded into the VA space, and the topic starter said that in the first line of his original post.
Quote:
Hi all, I have a generic question. After I enabling mmu on arm (aarch64), supposedly, kernel will be run at the high end of the virtual memory space (starts from 0xffff0000'00000000 in my mmu)...


You really confused things. Instead of arguing, try to clear it up by reading.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: After enabling mmu on arm (aarch64)
PostPosted: Mon Dec 10, 2018 11:17 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
zaval wrote:
You really confused things. Instead of arguing, try to clear it up by reading.

You should consider your own advice. Start with that 512G address space you keep repeating. JFYI, the architectural limit of ARMv8 is 52 bits as a starter. Second, write PoC and try that out. I'm afraid I cannot help you more. Some people are just beyond hope.

Good bye,
bzt

EDIT: 512G was obviously a typo, I wanted to write 512T.


Last edited by bzt on Wed Dec 12, 2018 6:50 am, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: 8infy, Bing [Bot], Google [Bot], SemrushBot [Bot] and 63 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group