<Izem>
Who is supposed to be responsible for designing the boot process? Is it the chip/architecture designer? I want to get a bigger picture behind this process.
<heat>
what's the boot process?
isaacwoods has quit [Quit: WeeChat 3.2]
<heat>
generally the "boot process" is a sequence of smaller processes that are designed independently
<Izem>
not boot process but boot loader?
<Izem>
Not sure of the terminology
<Izem>
but whatever happens before the os takes over
<clever>
Izem: uefi, gpt, or one of the many custom arm things?
<clever>
s/gpt/legacy/
<Izem>
yeah
<clever>
for legacy, the only thing really defined, is that the 512 byte MBR is loaded to a certain addr, and executed
<clever>
and the bios provides certain utils via soft irq's
<heat>
well the firmware's part is "designed" by the board manufacturer (although it's generally a part of a standard in x86 PC)
<clever>
everything else is up to the bootloader author
<Izem>
yes, that sounds like bios which came in the micro computer days right?
<heat>
then you have the bootloader, which is not standardised at all(and part of a larger project, like GRUB and syslinux and microsoft's bootloader)
<clever>
heat: thats kinda half just copying the firmware behaviour, so your board is compatible with existing software
<Izem>
interesting
<heat>
clever: except in UEFI lots of things are shared, no copying, just reuse
<clever>
heat: yeah, that was designed in a time of more open things
<heat>
I'd totally agree with the statement in the BIOS' case, of course
<clever>
there was a whole legal puzzle of doing a clean-room copy of the original IBM bios
<Izem>
that kinds indicates why arm has so many things? if the folk that make the boards are making the firmware
<clever>
Izem: yeah, on arm, there wasnt really a standard bios (but uefi is trying to take over), so every developer did it differently
<clever>
nobody to copy, so they all ran off in different directions
<Izem>
clever: is this what uefi had to do to avoid legal trouble, or earlier bios authors? sorry I did not get that bit
<Izem>
ah I see
<heat>
ealier bios authors
<Izem>
ok, that makes sense
<clever>
for early bios, they wanted to copy the functionality, so existing os/software could be installed
<Izem>
that reminds me, I did see something about uefi and rpi, so it seems uefi is crossing over from the desktop realm
<clever>
but with arm, the developer controlled the entire stack, and the end-user isnt going to pick another os
<Izem>
yeah
<clever>
so they didnt need to be compatible with eachother
<heat>
EFI was developed by intel and then they open sourced a bunch of code (called TianoCore), which is mostly shared between vendors AFAIK
<heat>
it's designed in a way that allows you to develop each part of the firmware independently
<clever>
so now there is a legally valid route to copy it, and have everybody work the same way
<Izem>
cool
<clever>
uefi also works on arm, as Izem mentioned
<clever>
but the rpi uefi is a bit of an ugly hack, given how rpi boots
<Izem>
iirc you can boot from address 0 on arm, but anyways what's the hack?
<clever>
on most arm boards, the boot rom is mapped to the reset address
<clever>
the rom loads an SPL from some fixed offset on flash media
<clever>
the SPL brings ram online, and loads the secondary program (hence, SPL == secondary program loader)
<clever>
uboot can be built as a combined SPL+uboot blob, filling both roles at once
<clever>
and then uboot loads linux
<clever>
Izem: all make sense?
<heat>
does ARM also have CAR?
<Izem>
yeah, it also seems like uboot was for arm stuff from the start? I've always heard of it but I did not look into it
<clever>
heat: some chips probably have that
<clever>
Izem: for x86, the reset vector points to some flash memory, so it can skip the rom and loading SPL, but that flash memory is slower to access, so the bios will copy itself to ram (after ram init), which is often refered to as the shadow something something...
<clever>
(older x86)
<clever>
but then on the rpi, its completely different, and yet the same!
<heat>
shadow BIOS mapping?
<clever>
heat: probably
<clever>
on bootup, the VPU (not the ARM) runs a rom at the reset vector
<clever>
that rom loads+executes bootcode.bin via cache-as-ram
<clever>
bootcode.bin brings ram online, and loads+executes start.elf
<clever>
start.elf then puts an "arm stub" at arm physical 0 (the reset vector), followed by a copy of linux, and then enables the arm core(s)
<clever>
you can optionally replace the armstub+linux, with uboot, or uefi
<clever>
but the whole VPU chain still has to happen first
<Izem>
ah cool
<Izem>
why did rpi use efi instead of armstub+linux?
<clever>
Boot0004 says to find a GPT partition with PARTUUID="27c99b08-455d-4dfe-a44f-6150cbc09ef8", mount that, and then execute \EFI\BOOT\BOOTX64.EFI
<bslsk05>
www.reddit.com: Warning to all Faceit (and possibly ESEA) players! Playing in KVM VM with GPU passthrough might get you banned! : linux_gaming
<clever>
but a hacking VM could expose the real hw, and use an IOMMU to partition off a tiny bit of its own ram
<heat>
^^two popular csgo anticheats
<clever>
that sounds like qemu with gpu passthru, which will advertise itself all over the place
<clever>
there will be qemu devices all over the lspci tree
<heat>
they used tweaks to hide KVM and it worked until it didn't
<clever>
you dont even have to try, to detect it
<clever>
yeah, at that point, it just turns into an endless game of cat&mouse
<clever>
each side finding new detection strats, and then patching them out
<heat>
the only qemu device in a default qemu-system-x86_64 is the VGA controller
<clever>
it should also advertise itself in the acpi
<clever>
and maybe cpuid?
<clever>
and the whole bios build
<clever>
also, would qemu even show a northbridge + southbridge in pci?
<clever>
a pc without a northbridge is a giant red flag
<clever>
a malware type VM, would just expose all of the pci devices directly, so such hints would just vanish
<heat>
clever, vm exits can leak
<heat>
that's a *huge* issue
<clever>
maybe people (like me) over-estimating the power of the vm hw, is what led to such fears, and off buttons
tacco has quit []
iorem has joined #osdev
Izem has quit [Quit: rcirc on GNU Emacs 27.2]
CryptoDavid has quit [Quit: Connection closed for inactivity]
zoey has quit [Ping timeout: 240 seconds]
sts-q has quit [Ping timeout: 268 seconds]
srjek has quit [Ping timeout: 256 seconds]
zaquest has quit [Quit: Leaving]
zaquest has joined #osdev
Matt|home has quit [Ping timeout: 255 seconds]
Matt|home has joined #osdev
dude12312414 has joined #osdev
nyah has quit [Ping timeout: 255 seconds]
dude12312414 has quit [Ping timeout: 244 seconds]
thinkpol has quit [Remote host closed the connection]
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
andydude has joined #osdev
catern has quit [Ping timeout: 240 seconds]
andydude has quit [Quit: andydude]
Mikaku has joined #osdev
Izem has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Izem has left #osdev [rcirc on GNU Emacs 27.2]
MarchHare has quit [Quit: Leaving]
<moon-child>
I added syntax highlighting to my text editor, and now it's dog slow
<moon-child>
there's no caching, so it re-highlights everything on every keypress, but vim can still re-highlight a page of text an order of magnitude faster
<mjg>
and vim is already slow
elastic_dog has quit [Ping timeout: 255 seconds]
<moon-child>
I find vim is pretty snappy for everything except raku
<moon-child>
(and very long lines, though that's unrelated to syntax highlighting)
elastic_dog has joined #osdev
<kingoffrance>
speak of the devil "and now it's dog slow"
<dzwdz>
do syscalls usually use the same paging directory as the calling process?
<klange>
That... is a more complicated question than you may realize.
<klange>
So traditionally, yes, for a long time that was common - why pay the penalty of having to switch directories on entry into the kernel? After all, that's what all those virtual memory permission bit things are for, right, keeping the kernel separated from userspace?
<klange>
But then some stuff happened now the norm in 'real' OSes is to only keep the bare minimum of kernel mappings in place - a 'trampoline' of pages necessary to respond to various entry points (interrupts or whatever) and then switch to the real directory when you get to the kernel.
<dzwdz>
that's due to spectre, right?
<klange>
one of those things, yeah
<dzwdz>
and what happens when the kernel wants to read user memory? does it parse the page dirs on its own?
<klange>
For a long while even before the great switching, most kernels had APIs for "copy from user" / "copy to user" which may have been doing bounds checks or whatever, and then now they can map things somewhere to perform the copies in and out.
<dzwdz>
where do they map them? in their own page directory?
<j`ey>
yes
<dzwdz>
is it even worth it performance-wise? if i'm iterating over the page tables anyways, i could just copy a page at a time
<klange>
You still need to map _that_ page somewhere.
<dzwdz>
what if the kernel uses an identity mapping spanning the whole physical address space?
<klange>
that's somewhere
ElectronApps has quit [Remote host closed the connection]
dennis95 has joined #osdev
ElectronApps has joined #osdev
transistor has quit [Ping timeout: 252 seconds]
transistor has joined #osdev
zoey has joined #osdev
pony has quit [Quit: WeeChat 2.8]
pony has joined #osdev
mcfrdy has joined #osdev
GeDaMo has joined #osdev
Belxjander has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
<klange>
moon-child: my editor's older C highlighter was really fast and could effectively highlight its own 10k line source every keystroke if it really wanted to ;)
<klange>
And then I embedded my Python knock-off and ported all the syntax highlighting to that, and now it takes a second or two to do that much, so having a smarter highlighter is important.
<moon-child>
yea, this is highlighter in scheme, and it has to restart for every token
<moon-child>
if i did it in c and oneshot probably it would be that fast
<moon-child>
but that it's _this_ slow indicates something else somewhere is fundamentally wrong
<klange>
Even after the language port, I've got the same general system going, and I've got all sorts of little tricks to reduce rehighlighting... and then I threw in even more tricks with highlighting 'in the background' with some dirty fake coroutine things.
englishm has quit [Ping timeout: 252 seconds]
<moon-child>
oooh, actually that gives me an idea
<moon-child>
can use call/cc to handle ambiguous parses
<moon-child>
restart the continuation until it gives a valid parse
<moon-child>
I'm sure this is a horrible idea in practice, _but_
<klange>
If you peel back the covers, all editors are little more than a bunch of horrible ideas.
<moon-child>
lol
pony has quit [Quit: WeeChat 2.8]
pony has joined #osdev
dormito has joined #osdev
CryptoDavid has joined #osdev
nyah has joined #osdev
kwilczynski has quit [Quit: Connection closed for inactivity]
wille has joined #osdev
<sortie>
Today in me going mad in osdev: I have one perl source directory that builds correctly and another one that doesn't.
<sortie>
(Natively on my OS, well it builds, but the installed perl is defective)
<sortie>
The difference is partly my own patches being slightly updated, and also that the old dir isn't distclean. (Oh god perl is terrible at cleaning its source directory)
pony has left #osdev [#osdev]
ElectronApps has quit [Read error: Connection reset by peer]
<sortie>
Been going mad trying to bisect this difference, turns out it's also due to the installed stuff in /lib/perl5, so one test could taint the next
ElectronApps has joined #osdev
<sortie>
The new source dir has all the files in the upstream perl and perl-cross releases, so it's not that anything is missing
<sortie>
My best bet is that when I cross-compiled perl on Linux and made that old directory, it populated it with some files that got picked up when I used the source directory on my OS, and when I built a proper distclean, it deleted those files. But due to some bug in my OS, they don't get properly recreated when doing a native build, and the perl isn't fully featured
pony has joined #osdev
<sortie>
Hmm also happens when I cross-compile
isaacwoods has joined #osdev
ahalaney has joined #osdev
Ameisen_ has quit [Quit: Quitting]
Ameisen has joined #osdev
klysm has quit [Ping timeout: 265 seconds]
clever has quit [Ping timeout: 265 seconds]
klysm has joined #osdev
wille3 has joined #osdev
dennisschagt_ has joined #osdev
wolfshappen_ has joined #osdev
NieDzejkob_ has joined #osdev
Terlisimo1 has joined #osdev
Terlisimo has quit [Ping timeout: 255 seconds]
froggey has quit [Ping timeout: 255 seconds]
koolazer has quit [Ping timeout: 255 seconds]
kanzure has quit [Ping timeout: 255 seconds]
wille has quit [Ping timeout: 255 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
thinkpol has quit [Ping timeout: 255 seconds]
Mikaku has quit [Ping timeout: 255 seconds]
NieDzejkob has quit [Ping timeout: 255 seconds]
dennisschagt has quit [Ping timeout: 255 seconds]
wolfshappen has quit [Ping timeout: 255 seconds]
kingoffrance has quit [Ping timeout: 255 seconds]
nur has quit [Ping timeout: 255 seconds]
wille3 is now known as wille
koolazer has joined #osdev
Bonstra has quit [Quit: Pouf c'est tout !]
kanzure has joined #osdev
froggey has joined #osdev
elastic_dog has joined #osdev
Mikaku has joined #osdev
Bonstra has joined #osdev
kingoffrance has joined #osdev
clever has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
heat has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 272 seconds]
heat_ is now known as heat
nur has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
z_is_stimky_ has quit [Read error: Connection reset by peer]
z_is_stimky has joined #osdev
gog has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<gog>
mew
<dzwdz>
mewtwo
<heat>
mewthree
SGautam has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
gareppa has joined #osdev
Izem has joined #osdev
Izem has quit [Remote host closed the connection]
vai has quit [Ping timeout: 258 seconds]
* Bitweasil
makes... whatever sound a mustalid trying to mew is.
<bslsk05>
'Baby Ferret Noises' by Earthling1984 (00:00:25)
<Bitweasil>
Fair. :D
<Bitweasil>
I've never had baby ferrets, all mine are older rescues, usually 8+ months old.
<dzwdz>
are baby ferrets supposed to act like this? it kinda looks scared
<Bitweasil>
Oh, that's not a baby, that's just a young ferret. And that's perfectly normal.
<Bitweasil>
They're... very bouncy. Lots of Tigger in them.
<gog>
yeah mustelids do this "dance" when they're hunting
mctpyt has quit [Ping timeout: 258 seconds]
<gog>
this one is playing :p
<Bitweasil>
They hold that energy to about 2-3 years old, then start gradually slowing down.
<Bitweasil>
Indeed. That's just a ferret having fun.
<dzwdz>
also, how many ferrets do you have?
<dzwdz>
that sounds pretty fun
<Bitweasil>
... probably one that was in a cage, if they've got more space to run around endlessly, they're a bit calmer when they come out.
<Bitweasil>
The hyper "spring uncoiling" behavior is usually if they've been left in a cage for a while (even a larger cage). They need a bit more space.
<Bitweasil>
Currently, 3, generally between 2 and 5.
<Bitweasil>
They've got... oh, 50+ sq ft of walled in area in a room they can play in, with a ton of tubes, couple cages to sleep in if they want, etc.
<Bitweasil>
And we let them run around the house as well at times.
<dzwdz>
> between 2 and 5
<dzwdz>
do you run a rescue or something?
<Bitweasil>
It's not popular right now in the heat, but I've got a little travel cage that has a 10' tube feeding into it, so there's a nice run into it, and they really like it in the winter - I cover it with blankets and they just fur pile in there.
<Bitweasil>
... no?
<Bitweasil>
That's a sane personal ferret count.
<Bitweasil>
I mean, all mine are rescues, but I don't run a rescue, nor do I try to rehome them. They come here and stay. :)
mctpyt has joined #osdev
<Bitweasil>
3-4 is ideal.
<heat>
my weakness is people talking about summer and thermal issues :(
<dzwdz>
they come to you on their own? wow
<Bitweasil>
...
<Bitweasil>
Are you being deliberately obtuse?
<dzwdz>
no
<dzwdz>
i just didn't know that ferrets do that
<Bitweasil>
We go out and find ferrets that people are looking to rehome when we're low.
<Bitweasil>
They're... about like a cat, socially.
<dzwdz>
ah ok
gareppa has quit [Quit: Leaving]
<kingoffrance>
so, 4 against elastic_dog
<GeDaMo>
The Internet is run by ferrets, they carry the packets down the tubes :|
<gog>
ferrets, hamsters, rabbits, and moles
<heat>
fiber optic is a lie
gog has quit [Quit: bye]
gog has joined #osdev
<Bitweasil>
Sounds about right.
tacco has joined #osdev
freakazoid333 has joined #osdev
aleamb has joined #osdev
<Bitweasil>
ARM timers support "event streams" - that sends events that trip the WFE (Wait For Event) instruction and such.
<Bitweasil>
What *are* "events" in ARM? :/
<clever>
Bitweasil: wfe (wait for event) and sev (send event)
<clever>
my understanding, is that events are just a global broadcast, to wake up every core in wfe
<clever>
so you can skip having to deal with the external interrupt controller?
<Bitweasil>
*nods* I'm unclear as to if they're delivered as exceptions, or what, exactly.
<Bitweasil>
No, I get to deal with that too. :p
<Bitweasil>
Or if I need new "event" plumbing.
<clever>
i think they ONLY un-pause wfe, and nothing else
<Bitweasil>
But timers can send them too.
<clever>
also, its semi sticky, if you receive an event, then wfe, the wfe will clear the flag, and continue
<Bitweasil>
The generic timer can send event streams that unblock WFE.
<clever>
so you could wfe for a timer to tick over, and then not deal with exceptions
freakazoid333 has quit [Read error: Connection reset by peer]
<Bitweasil>
Yeah, I think timer events are "a different thing."
<Bitweasil>
"The following events are WFE wake-up events: ... an event sent by the timer event stream."
<clever>
i think its for lower latency gpio things?
<clever>
set a timer, wfe, then poke a gpio, for example
<clever>
rather then enabling interrupts, waiting for the exception, confirming what irq it was, then poking gpio
<Bitweasil>
Right, I don't care what it's used for, I care how it's implemented. :)
dennis95 has quit [Quit: Leaving]
iorem has quit [Quit: Connection closed]
terrorjack has quit [Read error: Connection reset by peer]
immibis has joined #osdev
terrorjack has joined #osdev
nvmd has quit [Quit: Later, nerds.]
johnjay has quit [Ping timeout: 268 seconds]
freakazoid333 has joined #osdev
GeDaMo has quit [Quit: Leaving.]
freakazoid333 has quit [Read error: Connection reset by peer]
mhall has quit [Quit: Connection closed for inactivity]
<sortie>
https://xkcd.com/349/ ← Me, fixing my perl port, deep in the rabbit hole, and now make(1) itself is stuck using 100% time solving the halting problem
<bslsk05>
'Hal fixing a light bulb' by Gordon Myers (00:00:42)
<sortie>
sortie and mjg at at Tanagra
dormito has quit [Ping timeout: 240 seconds]
terrorjack has quit [Read error: Connection reset by peer]
CryptoDavid has quit [Quit: Connection closed for inactivity]
terrorjack has joined #osdev
<immibis>
I found out the other day that all you have to do to solve the halting problem is to define H(paradoxical program)=false and spend 2 years writing an academic paper to convince yourself this is correct
<moon-child>
what is a paradoxical program?
dormito has joined #osdev
<clever>
moon-child: this statement is a lie
<moon-child>
that is not a program
<sortie>
Well.. make only locks up when building -jN
<moon-child>
clever: in particular, a sound type system will reject formulations such as that
<immibis>
int main() {print(program_halts_with_argument(f, f));}
<immibis>
it's the halting problem equivalent of "this sentence is false" and has no correct answer
<moon-child>
immibis: that's not a solution to the halting problem, that's a proof by contradiction that the halting problem cannot be solved
<immibis>
moon-child: correct. but if you define program_halts_with_argument(f,f)==false and then spend 2 years writing an academic paper to convince yourself that's a solution, it can be a solution too!
<immibis>
despite the fact that with this definition, f(f) clearly does halt.
<moon-child>
there's a guy on usenet who keeps claiming to have solved the halting problem
<moon-child>
I don't think he even had to write an academic paper!
<sortie>
Well my problem went away as mysteriously as it appeared
<sortie>
Normally that terrifies me but a dirty perl tree seems to have so many fucked up aspects that I'll just say it was in a bad state somehow and pray
<zid>
moon-child: I already solved the halting problem, pfft
<zid>
The solution is to not give a shit about any classes of problems where it applies
<bslsk05>
softwareengineering.stackexchange.com: algorithms - Does H correctly decide that P (source-code provided) never halts? - Software Engineering Stack Exchange
<bslsk05>
www.researchgate.net: (PDF) Halting problem undecidability and infinitely nested simulation
<moon-child>
zid: sounds like dhall
<immibis>
basically: H is an x86 simulator, when the simulator encounters a call to H(f,f) it doesn't call H but rather just calls f(f) directly. Therefore f(f) is infinitely recursive in the simulator and never halts.
<immibis>
obvious problem: this is not how H(f,f) actually behaves
<immibis>
obvious solution: just delude yourself until you don't understand why that's a problem
V has quit [Remote host closed the connection]
V has joined #osdev
<zid>
immibis: skyhooks!
dutch has quit [Quit: WeeChat 3.2]
dutch has joined #osdev
heat has quit [Read error: Connection reset by peer]
wgrant has quit [Ping timeout: 268 seconds]
terrorjack has quit [Read error: Connection reset by peer]