<larsc>
but it will only declare the symbol only if it is referenced
<larsc>
one only to many
<ysionneau>
hum ok that's what I'm reading
<ysionneau>
too bad I need to add something to the linker script
<ysionneau>
it does not seem very clean
<ysionneau>
the code should be self sufficient :(
<ysionneau>
moreover my symbol I am referencing is in the same .S file
<larsc>
hm
<larsc>
but the position is still only known on link time
<ysionneau>
oh, right
<larsc>
but why do you need the real addr again?
<ysionneau>
indeed
<ysionneau>
because I'm calling a function with MMU off
<ysionneau>
it's in the TLB miss handler
<larsc>
But the same function can be called with MMU on as well?
<ysionneau>
humm I don't think I will need to call it from "MMU on" context
<larsc>
or well, the symbol can be access with MMU on?
<ysionneau>
In fact I don't even need to put hi(symbol_name) + A -B, I can put the physical address directly, I know it
<ysionneau>
it wo't change
<ysionneau>
but it's more clean that way
<larsc>
you could create a special section for stuff that's running with the mmu off
<ysionneau>
the thing is, I'm not loading the ELF file in qemu
<ysionneau>
I'm doing objcopy -Obinary
<ysionneau>
and I'm loading it as a BIOS file
<ysionneau>
I modified Qemu to load the BIOS file at 0x4000 0000 instead of 0x86****
<ysionneau>
that's not something to commit in any way, but it allows me to test my kernel stuff easily
<ysionneau>
more easily than loading a bios and then transfering the kernel
<ysionneau>
qemu loads the kernel in memory at the right place for me :)
<ysionneau>
maybe mwalle would have a better idea to do this kind of thing in a clean way
<ysionneau>
ping mwalle :)
<larsc>
and the kernel creates a mapping in the MMU at 0xc0000000?
<ysionneau>
I plan on doing the boot in 2 phases
<larsc>
usually the kernel runs at a static mapping, so you do not get these kinds of problems
<ysionneau>
one that automatically resolves misses by updating the TLB with virt->virt-0xc000+0x4000 mapping
<ysionneau>
and then when the pmap (virtual memory subsystem) has initialized the kernel page table page
<ysionneau>
I switched to the real tlb miss handler
<ysionneau>
which does the real normal job of checking if the virtual address is really mapped to something and updates the TLB accordingly
<ysionneau>
16:52 < larsc> usually the kernel runs at a static mapping, so you do not get these kinds of problems < that's the case here, the kernel will always be physically at 0x4000*** and virtually at 0xc000
<ysionneau>
if I understand what you mean by "static mapping"
<larsc>
but you can't run it at 0x40000000 when the mmu is on?
<ysionneau>
oh
<ysionneau>
humm
<ysionneau>
if I want to do something like 3G/1G
<larsc>
I think there is a design flaw somewhere when you need to switch between multiple address spaces
<ysionneau>
I need to map all the kernel stuff at >= 0xc000 0000
<larsc>
I see
<ysionneau>
because kernel is also mapping in process context
<ysionneau>
even if process cannot access it
<ysionneau>
is also mapped*
<larsc>
and it is not possible to retain the 0xc0000000 mapping when the mmu is "off"?
<ysionneau>
I mean, the virtual memory context of any user space process contains the kernel mappings (at >= 0xc000 0000), because then there is no context switch
<ysionneau>
when going into syscalls etc
<ysionneau>
you can use the memory mapping of the process to access kernel stuff (and run kernel code)
<ysionneau>
16:57 < larsc> and it is not possible to retain the 0xc0000000 mapping when the mmu is "off"? < when MMU is off addresses are not translated, and 0xc000 is not in SDRAM
<ysionneau>
for code most of the time it's OK
<ysionneau>
since most of the code is like PIC
<ysionneau>
except for big jumps
<ysionneau>
but for load and stores ...
<larsc>
yea, no pic stores and loads
<ysionneau>
all of this is kind of hackish ...
<ysionneau>
but the more I read kernel code the more I think all low level MD parts are kind of hackish anyway
<larsc>
only in the bsd land ;)
<ysionneau>
OpenRISC is doing this kind of trick for instance (the 2 phases boot) for their linux port
<ysionneau>
ahah no
<ysionneau>
bsd code is very clean
<ysionneau>
OpenRISC rewrites the code of the TLB miss handler
<ysionneau>
which is just a jump
<ysionneau>
to make the jump go to the second miss handler
<ysionneau>
that can sound hackish as well
<ysionneau>
but ... who cares, as long as it works
<ysionneau>
and it helps a lot to have a dummy miss handler during the bootstrap
<ysionneau>
for LM32 I could use two memory zones for the handlers by playing with EBA...
<ysionneau>
but I think it's even more hackish
<ysionneau>
and it wastes even more memory
antgreen has joined #milkymist
kyak has quit []
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
kilae has joined #milkymist
<mwalle>
ysionneau: why dont you use the -kernel parameter?
<ysionneau>
mwalle: because I need to link my kernel to its virtual address
<ysionneau>
not its physical address
<ysionneau>
then in the ELF, all addresses are like 0xc000****
<ysionneau>
maybe I missed something, but I think qemu cannot load the generated ELF, since it thinks RAM is 0x40000000->0x480000
<ysionneau>
tell me if I'm telling bullshit :)
<mwalle>
ysionneau: mh, how does the linux kernel do it?
<larsc>
does not use the mmu
mumptai has joined #milkymist
<mwalle>
larsc: on other architectures
<mwalle>
mhh and isnt there a load address for each elf segment?
<larsc>
doesn't need to switch
<mwalle>
larsc: iirc, on arm the mmu is turned off (if turned on) by the bootloader and the memory base is 0x0
<larsc>
turned off if turned on?
<mwalle>
larsc: if the bootloaded uses the mmu it is turned off before starting the operating system
<mwalle>
if it is not used it remains disabled
<larsc>
ah
<mwalle>
ysionneau: "$(CROSS)readelf -l netbsd_kernel" should print the virtaddr and physaddr of the elf file
<mwalle>
and arm does not have fancy features like mips where some segements are remapped to 0x0 like kseg2, does it?