<Ermine>
Watching a video about 486 computer now. Apparently motherboards of that time were equipped with bios batteries which start leaking over time and eroding the boards
<nikolar>
that's pretty common, yeah
<nikolar>
i mean motherboards are still equipped with batteries
<Ermine>
nowadays they're equipped with cr2032 batteries, which don't seem to leak
<nikolar>
they do, definitely
<nikolar>
probably less often though
<mjg>
fixing the battery problem is the most common 486 video
<nikolar>
indeed
<mjg>
apart from running doom or duke nukem 3d
<mjg>
:d
<nikolar>
you first have to fix the battery problem though
<Ermine>
this drives extinction of boards which can run 486, which is sadge
<mjg>
sure, but you dn't necessari yahve to make a video about it
<heat_>
hmm does linox still support 486 or is it pentium only
<nikolar>
true
<Ermine>
it does
<mjg>
hm
<mjg>
how much ram do you need to boot though
<mjg>
may be borderline impossible to use
<Ermine>
and I've said I want to play with one
<nikolar>
there are a few videos of modern linux running on 486s
<heat_>
how much ram did a 486 computer usually have?
<Ermine>
in that gentoo on 486 vid kernel was complaining about stack running out of stack space
<heat_>
yeah you should be able to totes boot with 8M I think
<heat_>
you just need to tone everything down
<mjg>
i would be geuninely surprised if a stock distro kernel got to a point where it can even try to exec init
<heat_>
oh distros dont really support i386 anymore
<mjg>
not even ddddebian?
<Ermine>
You can even have systemd on those
<heat_>
maybe alpine does? but debian definitely dropped it
<Ermine>
i386 was dropped somewhere in 3.x
<mjg>
8S
<mjg>
mofo you continue talking like that and i'm gonna try things out in a vm
<heat_>
or is dropping it, at least
<Ermine>
in kernel 3.x
<heat_>
Ermine, i meant i386 as in the sub-arch
<heat_>
"Insofar as they still do, we anticipate that the kernel, d-i and images teams will cease to support i386 in the near future" i guess the debian near future is somewhere around 2050
<Ermine>
I'm not sure I understand what that means
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<Ermine>
I guess that means "i486 and pentium and pentium pro", pentium 2 has sse
<zid>
i686 is life
<zid>
only viable architecture
<zid>
but by i686 I mean the ones without movcc only
gcoakes has quit [Ping timeout: 244 seconds]
<zid>
I can't remember the link, but very recently a bunch of people had to argue about what instructions even counted as i686
<zid>
because some via chips or whatever were missing some a p4 had
<heat_>
i386 can be used as an umbrella term for anything 32-bit x86
<heat_>
if that's what you're asking.
<heat_>
other terms include i686, x86, x86_32, x86-32, "intel architecture", ia32
<geist>
fwiw pentium 2 does not have SSE. pentium 3 added SSE
<geist>
was the only real initial difference
<heat_>
geist!
<geist>
hola
<Ermine>
wait, there was a vid where guy launched alpine on pentium
<zid>
I'm busy watchin everybody fall over trying to enter the olympic stadium
<zid>
because of some poorly gaffered electrical runs
<Ermine>
alpine 3.16 to be precise
<Ermine>
but idr any deprecations since then, so 3.20 may work on it as well
<geist>
watching guy fix bendix computer
<heat_>
hey geist youre a computer history guy
<heat_>
i heard you like computers innit
<Ermine>
Anyway, 486 machines get super expensive nowadays...
<heat_>
is there a good reason why linux kinda tries/tried to be compatible with other unices on their arch? e.g sparc has sunos errno numbers, i386 tried to be syscall-ish-compatible with svr4
<heat_>
was there a general expectation that unices would be binary compatible between each other?
<geist>
maybe initially
<zid>
why not
<geist>
a simpler time too, much less syscalls then there are now
vdamewood has joined #osdev
<Ermine>
As per sysv abi spec, no?
<zid>
there's a fair chance certain things WILL just run, as long as you make a trivial effort to copy paste
<zid>
rather than randomize
<heat_>
no
<heat_>
i think the i386 sysv abi does specify the number of SYS_exit and that's about it
<Ermine>
also take a look at man 2 personality
<rbox>
well if given the choice between coming up with nubmers all on yoru own, or copying something else
<rbox>
what would you pick?
<heat_>
they *went out of their way* to customize all of this shit for various architectures
<geist>
in earlier netbsds and whatnot the kernel comfig has piles of COMPAT_* options you can set, including with other unicex
<heat_>
the saner choice would be a stable errno/signal-number/syscall-number (etc) numbering
<heat_>
for all archs
<zid>
how
<rbox>
why does it matter
<geist>
and i think it wasn't defining separate tables as much as adding if/elses for particular compat things
<rbox>
it has to be compiled for each arch anyway
<geist>
so my guess is back in the day that was fairly common
<zid>
what do you do about gaps, arches where the numbers need to be offset for some reason, etc
<zid>
arches without the 64bit reads and seeks etc
<heat_>
it's far less confusing, easier to maintain, and easier to use
<rbox>
whats confusing
<rbox>
thats why defines exist
<zid>
it's equally as confusing but different
<rbox>
so you dont care about the nubmers
<geist>
large gaps would be annoying due to the wastage in your table, but so it goes
<heat_>
all the separate errno files/syscall tables/signal.h files
<geist>
assuming it's still close enough to have a single table
<rbox>
OH NO! a separate file for each arch
<zid>
those are going to have differences anyway
<zid>
x86 and amd64 aren't even the same
<zid>
and you want itaniumn to be the same?
<heat_>
have you looked at linux source or are you just spitballing at this point?
<heat_>
slightly different constants for everyone, with slightly different syscall ABIs (and god oh god when they randomly switch parameter ordering per arch) has caused many many hours of pain
<geist>
for early zircon we put FF00FF in the top of the syscall # to make it explicitly clear that it wouldn't run linux binaries and vice versa
<heat_>
haha
* Ermine
files bug report against zircon about not running his linux binary
<geist>
really more of the opposite since post build you have a ton of ELF files in your file system, and if you try to run it it'll instantly blow up on linx with bad syscall
<geist>
Ermine: we have starnix now for that. it might run it
<Ermine>
what's onyx syscall abi btw
<heat_>
wdym
<Ermine>
will look later
<geist>
probably just curious how your marshalling args, etc
<nikolar>
Ermine: what kind of question is that, it's obviously the linux abi
<heat_>
yes
<nikolar>
with probably different syscall numbers
<nikolar>
did you forget that he's copying linux :P
<geist>
do you allow more than 6 args on x86-64?
<heat_>
no
<heat_>
the linux ABI tends to be aight, at least on the architectures i've worked with. there's no reason not to use it
<geist>
yah only issue we had was 6 vs 8 args
<geist>
though i think since then we dont really have any syscalls that take that many
<geist>
maybe just one
<geist>
also iirc i thinl inux does/doesn't have some sort of 'skip the next instruction on exit' stuff
<heat_>
wdym?
<geist>
i think we added that on at least one of the arches, where the instruction immediatley after the SVC/SYSCALL is a debug instruction
<geist>
and then the kernel itself actually pushes the return address forward one
<geist>
one of those spectre/meltdown sploit things
<heat_>
lol
<geist>
but then that's only doable because of the VDSO thing in zircon, where the only place for a sycall to happen *must* come from a particular offset in the VDSO
<heat_>
i remember that in riscv you need to nudge epc manually on a syscall
<geist>
yah i forget why, aside from it Just Being That Way
<heat_>
linux ofc afaik supports all sorts of regs nudging through ptrace
<geist>
REG NUDGING
<geist>
new olympic sport
min0911 has joined #osdev
<heat_>
will-it-scale new olympic sport wake up mjg
<heat_>
scalability olympics
<mjg>
winner: SOLARIS
<mjg>
further editions postponed indefinitely until the other systems can get their shit together
<mjg>
kthx
<mjg>
i'm afkin
<Ermine>
kthx = kernel thx
<mjg>
solaris wins everything, most i-cache misses per syscall, most cacheline bounces with 2 threads doing the same thing etc.
<mjg>
fucking work of art
<Ermine>
girls kiss only olympic champions
hwpplayer1 has quit [Quit: Tomorrow is another day]
<min0911>
I want to make a abstract machine (maybe it is like vm) to run real mode code, so that I can call bios functions in Protect Mode without VM8086 mode.That's my design: emulate a cpu that can run real mode code, but when it executes in/out or tries reading/writing memory, do this on real cpu.I don't know whether it is a good idea or not.Just need
<min0911>
some suggestions or comments, thanks
Turn_Left has joined #osdev
<nikolar>
i think what you're describing is called user mode emulation
<CompanionCube>
probably not 'user-mode' if you're doing it for bios functions, though?
Left_Turn has quit [Ping timeout: 248 seconds]
<zid>
yea I kept meaning to write an x86 -> x86_64 recompiler
<zid>
for use to run the vesa bios
<nikolar>
CompanionCube: it's kind of the same idea, no?
<zid>
so that I could modeset on real hw, because the only video drivers I have are for imaginary vbox/bochs/etc devices
<nikolar>
lol
<CompanionCube>
'what if libx86emu, but JIT?'
<zid>
it isn't really a jit
<zid>
but it could be
<zid>
it's mostly fair to make the assumption that CFA is enough for a firmware blob
<zid>
the problem with static analysis is the edge cases, not the general ones
min0911 has quit [Quit: Client closed]
<zid>
(i.e the things that trip static analysis up are things like jumps to the middle of instructions and other nonsense, which you'd hope nvidia's blob doesn'tdo)
<nortti>
how'd you handle dynamically computed jump targets, from e.g. function pointers?
<zid>
another hard one, but if it needs it, it's not that hard to add
<zid>
with some 'I am cheating a little' heuristics
<zid>
i.e pretend it isn't hard and just hard code an edge case that supports exactly what the blob does
<zid>
or you just give up and do a callout to a function that does a block lookup
<nikolar>
can you really just emulate the vesa rom in x64, like is it that simple to modeset
<zid>
how do you think vesa does it?
<zid>
magjick?
<nikolar>
well it's not running in long mode presumably
<zid>
The blob is provided by nvidia, to make the card work in systems that use the VESA api, and makes the card.. work
<zid>
it'd be a bugged card if it didn't work
<zid>
it might be entirely emulated, like the PIC is on a PC or whatever, in terms of how it works, though
<zid>
Where it just listens for an ioport write to 0x3D4 with the exact value 0xC2 then runs a complicated load of C++ on a risc-v on the actual card instead
<zid>
but who cares
<zid>
Or it might know enough about pascal or turing to actually do it itself, never looked
<nikolar>
btw weren't there plans with x86s to remove io ports
<zid>
you currently only need them to.. disable the PIC :D
<zid>
assuming you don't mind using HPETs or RDTSC or whatever instead of the PIT
<zid>
I think you'd also maybe run into trouble with.. the COM port on the superio?
<nikolar>
i don't even know if they are connected to anyhting other than the emulated pic
<nikolar>
maybe serial
<zid>
it's hosted onto a diff bus now nikolar called up
<CompanionCube>
you can cat /proc/ioports
<zid>
LPC
<zid>
(and now espi I guess)
<zid>
it just posts a read/write to THAT bus, and that bus has all the low level hw on it
<zid>
rather than there being a 'real' ISA/io bus hanging around
<CompanionCube>
mine has pci stuff, smbus, some acpi stuff, the other usual tihngs
<zid>
LPC bus I think is serial, so it's just a wire pair going to the ME, superio, etc
<zid>
rather than a huge ISA thing
<zid>
and it has the old io bus running on top
<zid>
the i/o for the PIC probably never leaves the cpu at all
<nikolar>
yeah very likely
<zid>
but the rest does, and does sorta matter for things like thermal sensors, com ports, ps/2 emulation, blah blah
<zid>
it's just now on a better electrical bus to make mobos less hell
<nikolar>
i wonder what they'll do to make serial work in x86s
<nikolar>
presumably just some well known mmio
<CompanionCube>
do they even care about non-usb serial for x86s?
<nikolar>
well some motherboards to have serial ports
<nikolar>
so i assume someone cares
<CompanionCube>
yes but is it likely for *x86s*
<nikolar>
why not
<nikolar>
they exist now, they don't need to
<zid>
LPC isn't going away
<zid>
(even if it will be espi instead)
<zid>
you could just have an mmio pci-e superio though I guess
<nikolar>
yeah that's kind of what i thought
<heat_>
geist, oh i've just remembered there's that vzeroupper peculiarity on your x86_64 syscall abi compared to linux
<heat_>
which kind of pledges just not to ever touch the fpu state
<zid>
but, pci-e 5.0 or whatever is super super expensive
<zid>
like, the things for splitting lanes etc are $300 a chip
<zid>
so you'd much rather use the $1 lpc part presumably
<zid>
You could put it behind the southbridge on its own 1x, but intel's only been shipping 20 lanes lately
<nikolar>
yeah sounds wasteful
hanemile is now known as Guest3559
Guest3559 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
hanemile_ has joined #osdev
<geist>
heat_: ah yeah
<geist>
basically the C abi wipes it out, so why have the syscall layer not do the same?
<heat_>
don't you need an extra clobber on your syscalls?
<heat_>
i guess it's less of a problem because of your vdso
<geist>
exactly
goliath has quit [Quit: SIGSEGV]
<heat_>
do you know if its any measurably faster?
<heat_>
the vzeroupper that is
<geist>
not particularly, i think
<geist>
hypothetically it makes saves run a bit faster if context switching inside syscall
<heat_>
oh right, compressed state and all that
<heat_>
i haven't looked at avx codegen enough, maybe the compiler does the vzeroupper on its own?
<geist>
i think it does it in the callee and only if it's about to use the vector unit
hanemile_ is now known as hanemile
<Ermine>
bb has one more shell, hush
<heat_>
what for?
karenw has joined #osdev
<heat_>
is it a mega minimal version
<heat_>
or a mini bloated version
<Ermine>
mega minimal
<heat_>
hahahahahahahahahahahahahaha
<Ermine>
no command line editing apparently
<heat_>
ew
<heat_>
you know, i've had dash in onyx for the longest time. relatively recently i added some hooks in the system to change the shell to bash if its present. night and day difference
<heat_>
line editing, tab completion. insane
<Ermine>
unsurprisingly
<heat_>
and i didn't even have bash-completion set up!
<Ermine>
that's why installing bash is the first thing I do on new linux installations
<Ermine>
(and bash-completion is the second thing)
<heat_>
i can cope without bash-completion cuz tabbing to find files/progs is the 99.9% ofw hat i tab for
<Ermine>
i use tab for git stuff and for pass
cow321 has quit [Ping timeout: 245 seconds]
cow321 has joined #osdev
GreaseMonkey has joined #osdev
hwpplayer1 has joined #osdev
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
netbsduser has quit [Ping timeout: 252 seconds]
Turn_Left has quit [Read error: Connection reset by peer]
<kof673>
> Aug 16, 2020 · Modern Linux kernels require a mid-life 486 chip because modern kernels require support for atomic compare-and-swap (CMPXCHG)
<dostoyevsky2>
kof673: I'd just run one kernel on each cpu and never want to synchronize any state across them, so much simpler
<kof673>
also, that's a basilisk surely :D > Sea of Eden - EarthBound Wiki - Fandom earthbound.fandom.com › wiki › Sea_of_Eden The only enemies here are three Krakens
<kof673>
i don't know details but llvm: > march=i386 should not generate bswap/cmpxchg/xadd instructions
<kof673>
so i think bsds also are similar, re: what are the minimum instructions needed
<kof673>
(was/is an llvm bug, generating when not supposed to)
memset_ has quit [Ping timeout: 260 seconds]
<dostoyevsky2>
kof673: Just run the kernel through movfuscator
<heat_>
LLVM does not support 386 or even 486
<heat_>
IIRC pentium was the earliest. basically no cpuid? get fucked
<dostoyevsky>
I think pentium only had one cpu/core, no? So you could make the cmpxchng just a nop
<kof673>
yeah, these are like 2016/2019/2020 posts...not sure llvm ever expected "march=i386" to work as the complaints expect
<kof673>
just you will need a compiler that does not do that, in any case :D
<heat_>
dostoyevsky, no, cmpxchg is still an important op
<heat_>
you can have one core all you like, it still matters when e.g you're protecting against preemption or irqs or what have you. basically cmpxchgs without the lock prefix
<kof673>
The Linux Kernel May Finally Phase Out Intel i486 CPU Support - Phoronix > We got rid of i386 support back in 2012. Maybe it's time to get rid of i486 support in 2022?
<kof673>
i don't know about 486, google says yes though, there was smp for old x86....likely very expensive "enterprise" "server-class" hardware, but they did exist :D
<kof673>
i would guess they would have scsi for drives too
<kof673>
not "consumer" "home" gear...for servers
<dostoyevsky2>
hmmm.. just looked it up: pentium had 4.4ghz, and an esp32 has 240mhz
<dostoyevsky2>
hmm... my amd ryzen has 3.3ghz... but I guess it has more cores than the pentium...
gcoakes has joined #osdev
<dostoyevsky2>
Oh, seems like the pentium line of processors only ended in 2023... and the first ones only had like 60mhz
<zid>
I've heardno word they're killing the branding
<zid>
ah, yea, 2023, they decided to go with 'core' instead, rip
<dostoyevsky2>
=> @TheRasteri | Add an ISA slot to Modern Motherboards! [00:14:11] | 2023
<zid>
that seems fun, I assume there's just a breakout from LPC for it?
<kof673>
there were some usb 2 isa things too...kind of pricey...and i assume needs software rewritten for it i.e. much easier if you have source for whatever application :D
<kof673>
i don't know if the company that made them even makes them anymore