<bslsk05>
www.gnu.org: Multiboot Specification version 0.6.96: Header address fields
<bslsk05>
github.com: kexec-tools/kexec-multiboot-x86.c at main · horms/kexec-tools · GitHub
<bslsk05>
git.savannah.gnu.org: startup_raw.S\pc\i386\boot\grub-core - grub.git - GNU GRUB
<klys>
and then I got grub to load from kexec() on an mbr system and not an efi system.
<klys>
by patching at line 107 to not fail but do: mbh->load_end_addr = ( mbh->header_addr + buf_len - mbh_offset ); and mbh->bss_end_addr = ( mbh->header_addr + buf_len - mbh_offset );
<klys>
now I hear grub has something called efiemu, except I don't know much about it yet.
<mrvn>
was there a question in there somewhere?
<klys>
how hard would it be to get the efi reboot working with kexec() ?
<mrvn>
you can't get efi bootservices back once you killed them. so you need so efi emulation there
<klys>
yeah I guess grub has something like that?
<klys>
oh, I need it from the kernel I guess
<mrvn>
I know there is grub-efi to boot multiboot on efis but you kind of need the reverse, boot efi on multiboot.
<klys>
how would grub know where to look for video memory? does it just assume real mode?
<mrvn>
get an FB from the running kernel I gues
<mrvn>
guess
<mrvn>
It sounds a bit like the kernel would have to keep running in the background to provide boot services.
<klys>
what we need here is a lightweight linux kernel capable of emuating efi
archenoth has quit [Read error: Connection reset by peer]
archenoth has joined #osdev
<klys>
if it's a linux kernel, kexec can load it without difficulty. my ovmf+qemu system always boots "in blind mode."
<klys>
so I only get video when in loads the virtio-gpu driver (.ko)
X-Scale` has joined #osdev
Bonstra has quit [Ping timeout: 248 seconds]
gdd1 has quit [Ping timeout: 272 seconds]
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
<coso>
is it normal for the first 4K of an elf executable to be the header + zeros?
<mrvn>
very
<mrvn>
most linker scripts align sections to pages and there is only so much metadata the linker can put in with the elf header.
<coso>
i see
<coso>
my linker script doesnt say anything about that tho but i guess i have to explicitly tell the linker not to do that?
<geist>
yeah there's a whole trick to it. something like . = SIZEOF_HEADERS; at the start
<geist>
basically offsets the start of the text by the size that the ELF file would have used up
<mrvn>
there is a default pagesize too you can set (must on amd64 or you get 2MB)
<coso>
i have a hello world program that would fit comfortably in 4K anyway
<coso>
and hard disk space is so expensive these days!
<geist>
yah that's the trick something like . = 0x100000 + SIZEOF_HEADERS;
<coso>
hmm im gonna check that SIZEOF_HEADERS stuff
<geist>
basically you're starting the .text segment such that if it were to start it aligns such that the ELF headers would fit in the first part of the page and thus doesn't need to pad it out to start on the next page aligned address
<geist>
and yeah as mrvn says you also may need to override the max-page-size
<geist>
depends on the arch and what toolchain your'e using
<mrvn>
SIZEOF_HEADERS should always work, 0 aligns with everything.
<mrvn>
but then .data might have a huge gap before it
<mrvn>
check you linker script that you have no align stuff in there so it just uses the alignment the code + data itself has.
<coso>
thanks guys
<coso>
linker scripts feel like some sort of a
<coso>
witchcraft lol
<mrvn>
they are
<mrvn>
normaly you want to separate the code, rodata, data+bss so you can set different permissions with the MMU. You don't want someone to write over your code for example. Far more important than saving a few byte diskspace.
<mrvn>
So that's what the default targets
Bonstra has joined #osdev
gdd1 has joined #osdev
<coso>
makes sense, 4K is also a small price to pay
<coso>
lol that SIZEOF_HEADERS thing works well. hello world fits in 544 bytes
<coso>
im off to bed, gnight fellas
coso has quit [Quit: Leaving]
kingoffrance has quit [Ping timeout: 265 seconds]
gog has quit [Ping timeout: 240 seconds]
wowaname has quit [Remote host closed the connection]
wowaname has joined #osdev
<geist>
woot!
<zid>
uh oh what did you do now
<klys>
=)
Likorn has joined #osdev
toluene has quit [Read error: Connection reset by peer]
toluene0 has joined #osdev
<geist>
oh just wooting cosos success
<geist>
also i got my 6800 emulator 'fully' working last night
<geist>
int hat it ran the altair 680 rom and was able to load 6800 basic, etc
<bslsk05>
github.com: emu/cpu6809.cpp at wip/6800 · travisg/emu · GitHub
<geist>
the pinnacle of 8 bit cpus
<geist>
i just did the 6800 one by forking the 6809 code and essentially removing what wasn't implemented there
<geist>
since 6809 is *mostly* a superset of 6800, even about half the opcodes are the same, but there are enough subtle differences in how some CC flags are computed you have to still go through everything
<bradd>
neat. I still remember assembler on os9 level II. first multitasking os i've used
<klys>
yeyy 6809
<klys>
speaking of simple this last week I'd been working out a nybble code interpreter.
<klys>
I haven't uploaded it anywhere yet tho
<klys>
about every other nybble is an operation or data "width" indicator.
<geist>
bradd: yah i should dig out an os9 build and try to get it running on my emulator
<geist>
interesting that apparently some company still owns it and i think still maintains it
<geist>
there was some discussino about that on another discord the other day
<bradd>
oh, neat. I didn't really use level I, level II seemed alot better
<sbalmos>
mrvn: oof, yeah I saw a couple fun holes
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<mrvn>
heat: I wasn't benchmarking. I was trying to see why someone elses benchmakring didn't return "0 ms"
<mrvn>
sbalmos: wrong name for init, that's an alloc. No error check in kalloc. No overflow/underflow check.
<heat>
windows 11's iso doesn't support el torito
<heat>
el sadito :(
<gamozo>
el tostitos?
<sbalmos>
el dorito
<heat>
seriously though who tf doesn't use EL TORITO
<sbalmos>
mrvn: yeah, that's some Grade-F head/tail handling there
<heat>
holy shit ntfs-3g is so slow
<heat>
i'll need to do this in windows
heat has quit [Remote host closed the connection]
kingoffrance has joined #osdev
<geist>
EL TORITO
<geist>
i guess it just does UEFI only? and UEFI only iso9660 probably doesn't need any of the EL TORITO embedded image stuff?
<sbalmos>
makes sense. UEFI requires an actual partition table, regardless of the medium
wand has quit [Ping timeout: 268 seconds]
gildasio has joined #osdev
wand has joined #osdev
ethrl has quit [Read error: Connection reset by peer]
ethrl has joined #osdev
heat has joined #osdev
<heat>
geist, it should still support ELLLLLLLLLLLLLLL TORITO
<heat>
pretty sure that's still a thing in UEFI
<heat>
dd if=windows.iso of=/dev/sdb doesn't work
<heat>
I had the use the Official Microsoft(r) Windows(tm) Installation media creation tools
<gamozo>
yeahhh i hate that you can't dd windows isos
<\Test_User>
reason: microsoft doesn't know what an iso is :P
<\Test_User>
"here's an iso, doesn't actually work when used as one though"
<heat>
it sure does
<heat>
for dvds
<\Test_User>
last time I tried it booted fine but refused to install
<heat>
iso are specifically for CDs
<heat>
not usbs
<\Test_User>
though didn't use a cd/dvd
<heat>
it's ok that they don't support el torito, but it's fucking annoying as ballz because everyone does
<sbalmos>
no one else matters
<heat>
even I support el torito
<klange>
We should be calling DVD image files UDFs...
<sbalmos>
given it's a summer day, and the local hometown ice cream chain is UDF (United Dairy Farmers), I want to go for a shake now
<heat>
my milkshake brings all sbalmos to the yard
<mrvn>
Pretty much every linux distribution uses hybrid isos.
psykose has quit [Remote host closed the connection]
psykose has joined #osdev
<heat>
The native page size an Itanium-based operating system will choose for its page tables is likely be
<heat>
larger than the architectural minimum page size of 4 K
<heat>
ha ha ha ha ha ha ha ha
<mrvn>
I need a constexpr friendly string class.
<heat>
aged like milk
<heat>
also is that a typo in the itanium sdm lol
<mrvn>
heat: I find page tables with a different size than pages rather ugly to deal with.
<heat>
itanium doesn't have page tables
<heat>
I dunno why they used page tables there
<mrvn>
I would use struct { size_t text; size_t rodata; size_t heap; size_t stack; } AddressSpace;
<mrvn>
make theI would use struct { size_t text; size_t rodata; size_t heap; size_t stack; } AddressSpace;
<mrvn>
make that struct { const size_t text; const size_t rodata; size_t heap; size_t stack; } AddressSpace;
<heat>
in itanium you may have the VHPT which is a hash table of page mappings
<heat>
but in the worst case you insert it directly into the tlb
<heat>
it meaning a TLB entry, kinda analogous to a PTE
<heat>
you know
<mrvn>
sure. that struct is just the permanent storage to generate TLB entries from.
<heat>
in a way, I should stop reading this
<heat>
in reality, I can't
<heat>
this is too good
<sbalmos>
wonder if they were getting the VHPT idea from POWER, because I'm going back over my OS/400 Internals book and they describe something kinda similar in OS/400 for the single-level store
GalaxyNova has quit [Quit: WeeChat 3.4.1]
<geist>
well, the PT part is still technically a table, it's just a flat one
<geist>
just not a radix tree of tables like you expect with x86
<geist>
and yeah the VHPT is pretty similar to POWER
<geist>
but there's also the other mode which is interesting
<heat>
which mode? VHPT-less?
<geist>
somewhere i read a paper about which one of the two modes linux uses, and i forget which one they settled on
<heat>
I noticed that there's two VHPT structures
<heat>
short and long
<heat>
didn't really try to understand it
<geist>
iirc there's a single hash table style one, and then another one where there is a linear virtual table per process
<geist>
yes, it's the short one, i think
<geist>
the long one has fairly large entries in the VHPT because it acts like a hash table but has to hold the physica and at least enough of the virtual and ASID to match
<geist>
so that ends up being a few words at the minimum
<geist>
the short one i think is only useful in the context of a flat linear non hash based PT
nyah has quit [Ping timeout: 246 seconds]
<geist>
as in the hashing is direct 1:1 and is per process, thus doesn't need to hold extra infos
<heat>
if you can also go VHPTless if you're kool
<geist>
i think the short one relies on you sometimes getting a TLB miss exception
<heat>
both do
<heat>
I think
<geist>
because if you say, for example, declared you have a 36 bit long page table that lives virtually, and is sparsely populated
<geist>
in that case you dont reserve that much physical memory to back it, so the cpu doing a TLB miss may be recursive and fault when trying to resolve the page table itself
<geist>
and as long as you ca guarantee forward progress you are okay
<heat>
isn't that solved with those tlb entries you can fixate
<geist>
*bingo*
<heat>
tbf it's a pretty cool idea
<geist>
so that short entry, per process virtual page table is the really exotic thig i remember. i only kow of VAX that does something like that
<geist>
but that was much more limited because small 32bit machine
<geist>
that being said i dont know what linux does. it could do either mode, but iirc it uses long form
<sbalmos>
I'm wrapping my head around the implications where OS/400 has a single virtual address space, no TLB switching, etc
<heat>
n order to find out the
<heat>
interval time.
<heat>
frequency at run time, one can use a firmware call to obtain the input frequency information to the
<geist>
talks about the two modes and why one is picked over the other
<CompanionCube>
sbalmos: note that OS/400 didn't use POWER *originally*
<CompanionCube>
the switch occured some years in
<sbalmos>
CompanionCube: correct
<geist>
also OS/400 may be more intrinsically built around virtualization
<geist>
so you may just be expected to run multiple single-address-space OSes simultaneously
<sbalmos>
geist: they used a Mach-derived microkernel at one point at the lowest level
<geist>
lowest as in at the root?
<geist>
(depends on what you mean by highest and lowest)
<sbalmos>
geist: actually the more I'm reading about it, there's similarities to using VMOs/VMARs as the lowest level of memory (or file) access
<sbalmos>
correct
<CompanionCube>
also any OS/400 virtualization stuff would be post the switch to POWER in the mid 90s iirc
<geist>
ah
<CompanionCube>
the closer thing to your description would be VM/CMS, i think?
<sbalmos>
possibly
bauen1 has quit [Ping timeout: 255 seconds]
<geist>
possibly yeah
gxt has quit [Ping timeout: 268 seconds]
gxt has joined #osdev
<heat>
i stopped reading the itanium manual and now i'm doing something productive with my time
<heat>
writing arm64 mmu code
<j`ey>
<3
<heat>
not as productive as writing itanium mmu code
<heat>
but... it is what it is
<heat>
how much of a flex is "ported my own operating system to x86_64, riscv64, arm64, itanium"?
<heat>
kinda need that in my CV I guess
<heat>
maybe itanium should be first
<heat>
or "ia64, ia-32e, riscv64, aarch64" for maximum confusion
xenos1984 has quit [Remote host closed the connection]
<CompanionCube>
lol
<heat>
geist, did you try ski yet?
<geist>
i fiddled with it a bit. required a few local patches to comment out some things but it looks like its pretty full featured
<heat>
are you actually going through with an lk port
<geist>
drops you into a curses style window with a live dump of the registers and whatnot
<geist>
and a lot of debug commands
* kingoffrance
throws es20 code at heat...dont forget alpha
<geist>
me? no. but was interesting anyway
<geist>
might futz with a hello world maybe
<heat>
aw
<geist>
usually i start with a start.S style project and write some asm to see how to make things go when i fiddle with a new arch
<geist>
also lets me sort out the necessary compiler switches, etc
<heat>
oh yeah edk2 called(RIP) itanium IPF
<heat>
intel is really good at naming things
<heat>
riscv is *all caps* RISCV
<heat>
almost like our very own EL TORITO
<CompanionCube>
huh, had no idea itanium emulators aren't really a thing
<CompanionCube>
surprising
<geist>
though i like old architectures i tend to get more interested in writing code to run on some that are at least physically still obtainable in a form i'd like to get ahold of
<geist>
itanium just doesn't fit that bill
<geist>
VAX pushes it, but it also is pretty historically significant
<geist>
though i also haven't pushed that code into mainline
<heat>
WHAT
<heat>
I CANT HEAR YOU OVER MY ITANIUM SERVER
<heat>
I haven't gone bonkers enough to buy one though
<CompanionCube>
isn't there a good chance the vax is louder though
<geist>
well, the microvax i have isn't. it's actually a fairly nice box, just big and heavy like they used to make
<geist>
but see you never really could find smallish non beefy itaniums
<geist>
best case you could find a 2U rack or so as we did on ebay.
<heat>
you could like
<heat>
find a dual socket one and try to run an IA32 + itanium cpu
<heat>
if any one of those is out there
<heat>
that would be like the coolest shit ever done in computing ever