[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: Changing kernel entry point
I still did not piece that puzzle together completely. However, I am getting
closer. Here is what I got now and I hope someone has an idea for me.
I did setup the MIS at the end of my boot2 routine. I pushed the address of the
MIS into EBX and the magic value 0xBAD2B002 into EAX. I then release control to
the kernel by jumping to its entry point.
I can see some steps being executed. An objdump -D netbsd | less tells me:
netbsd: file format elf64-x86-64
Disassembly of section .text:
ffffffff80100000: 66 c7 05 72 04 00 00 movw $0x1234,0x472(%rip)
# ffffffff8010047b <cpu_switchto+0x7b>
ffffffff80100007: 34 12
ffffffff80100009: 8b 44 24 04 mov 0x4(%rsp),%eax
ffffffff8010000d: a3 18 66 4c 00 8b 44 movabs %eax,0xc24448b004c6618
ffffffff80100014: 24 0c
ffffffff80100016: 85 c0 test %eax,%eax
ffffffff80100018: 74 64 je ffffffff8010007e
It crashes now at the movabs instruction. 0x2c444... is not a canonical memory
address which is true. I am now wondering what causes this? I mean the BSD
bootloader must do something to prevent this? What is this statement for?
Again, thanks for any pointers and help!
[current-users-owner%NetBSD.org@localhost] on behalf of Martin Osterloh
Sent: Tuesday, February 26, 2013 1:39 PM
Subject: Re: Changing kernel entry point
To follow up on this.
I made my bootloader MULTIBOOT compliant. At the end of "my" boot2, I
have C code in which I create the MIS structure, push the magic number
into EAX and the address of the MIS into EBX.
Now I have the following problem. I am not sure what to call from here?
Should I just jump to location 0x100000 and execute from there (while
having EAX and EBX set correctly)?
On 02/21/2013 10:15 AM, Martin Osterloh wrote:
> Anyone an idea on this?
> On 02/19/2013 12:39 PM, Martin Osterloh wrote:
>> [ Please find the previous correspondence below this email I forgot
>> to include the mailing list]
>> Thanks for the document. I've been reading it and I understand more
>> and more how the BSD bootloader works. I am getting closer.
>> One thing you mentioned in your article is that the kernel maps
>> itself at a very hogh location (0xC0100000 and higher).
>> Since the BL cannot address anything like that, the physical location
>> will be 0x100000 (1MiByte) - right after the BIOS. That makes sense
>> to me.
>> However, a readelf -x -t -s -d netbsd shows me the following (just
>> the top)
>> netbsd: file format elf64-x86-64
>> architecture: i386:x86-64, flags 0x00000112:
>> EXEC_P, HAS_SYMS, D_PAGED
>> start address 0xffffffff80100000
>> Program Header:
>> LOAD off 0x0000000000100000 vaddr 0xffffffff80100000 paddr
>> 0xffffffff80100000 align 2**20
>> filesz 0x0000000000265e88 memsz 0x0000000000265e88 flags r-x
>> LOAD off 0x0000000000366000 vaddr 0xffffffff80466000 paddr
>> 0xffffffff80466000 align 2**20
>> filesz 0x0000000000040598 memsz 0x00000000000ade80 flags rw-
>> I am confused as to why the paddr is set to 0xffffffff80100000?
>> Shouldn't that be 0x100000? That is actually what causes trouble for me.
>> I found that KERNBASE, KERNTEXTOFF, etc. are all defined in
>> /usr.src.sys.arch.amd64.compile/CUSTOM/machine/param.h (whereas
>> CUSTOM is the name of my configuration).
>> The next thing that came to my mind is that if I change it here I
>> might be able to change the physical entry point. Unfortunately, I
>> messed up the memory map and locore.S is complaining during the
>> compilation process.
>> So I guess, I am wondering why the paddr attribute in the elf file is
>> not set to 0x100000? And there must be another way to adjust these
>> parameters (KERNBASE, KERNTEXTOFF, etc.)?
>> Again, I truly appreciate your help and advise.
>> On 02/15/2013 12:11 PM, Julio Merino wrote:
>>> On Fri, Feb 15, 2013 at 11:29 AM, Martin Osterloh
>>> <martin.osterloh%dartmouth.edu@localhost> wrote:
>>>> Hi Julio,
>>>> Thanks a lot for your quick response!
>>>> My bootloader is currently very simple (two stages like the BSD
>>>> At the end of boot2 it kicks off my micro-kernel in long mode. I
>>>> think I
>>>> will have to change this since the entry point is 32 bit.
>>>> Could you please point out what/where these data structures are? I am
>>>> browsing the source tree at the moment and am trying to figure out
>>>> at which
>>>> point the elf binary is being loaded. From there on I would back
>>>> trace to
>>>> see what the BL does before loading the binary.
>>> Look for "bootinfo" in the code and in filenames. It has been a long
>>> time since I touched this code, so I don't remember the specific
>>> You might also find this useful:
Main Index |
Thread Index |