<bslsk05>
twitter: <mjg59> The real reason Open Firmware lost is that the intersection of the people who've learned how to do hardware bringup and the people who know Forth is approximately 0, and UEFI recognised that
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<moon-child>
'Worse is Better, but for your system firmware'
<moon-child>
eesh, no need to rub it in
heat has quit [Ping timeout: 260 seconds]
srjek has quit [Ping timeout: 240 seconds]
<geist>
yah word
<geist>
mjg: truth
<moon-child>
that's not the same mjg :P
<geist>
well, okay
<mrvn>
The goal of forth was to have plugin cards work on any hardware.
<geist>
yah and uefi tried to do it with their own bytecode, though i guess that hasn't really caught on
<mrvn>
Trying to get PCI cards to work on Alpha was a pain because you couldn't run the rom.
<mrvn>
I guess nowadays you would have java or javascript or something.
<mrvn>
They should just have a C compiler in the rom and compiler device setup code from source.
<mrvn>
Smallest C compiler is below 1k I think.
<geist>
well, that's what forth or the uefi bytecode is supposed to solve
<geist>
problem is you need to have the will for vendors to do it
<mrvn>
Don't give them a choice. :) Only allow compiling C code.
<mrvn>
or only bytecode.
<Griwes>
actually if sane people were making the decisions today without the baggage of aml and whatnot, you'd make all the bytecodes be webasm or something in that vein
<mrvn>
but I guess then we would still have BIOS as primary boot method.
freakazoid343 has quit [Read error: Connection reset by peer]
<mrvn>
The idea of using C source would be that existing code will likely be C already so you only have to work around some compiler quirks for the simpler bios C compiler.
<mrvn>
Griwes: you think it would be simple to make webasm interact with real hardware and bit banging easily?
<Griwes>
maybe not "simple", but I don't think it'd be terrible either
kkd has quit [Ping timeout: 260 seconds]
<Griwes>
you'd probably have some sort of an interface in a different webasm module, which also makes you able to switch between s
<Griwes>
...between good perf and safe implementations
<Griwes>
on a per-device or per-table basis, probably
<mrvn>
screw good perf. This is boot stuff. Saving 0.1s there is irrelevant.
<Griwes>
right. I'm just saying it should be trivially possible to have a choice
<mrvn>
You probably waste more time on sleeps during bootup than optimization would save.
<Griwes>
also it may matter for runtime bytecode services, if any
<Griwes>
your OS could also plug different implementations of the hal interface into those
<Griwes>
but we all know this will never happen, so... :)
<mrvn>
Is anything but toy project actually using EFI services?
<mrvn>
they are called boot services for a reasonl.
<Griwes>
aren't efivars accessed through runtime services?
<mrvn>
Griwes: EFI defines two types of services: boot services and runtime services.
<Griwes>
yes, and c is a weakly typed language.
<Griwes>
you asked, presumably, about runtime services
<mrvn>
No. I was talking about boot services.
<mrvn>
Do devices provide runtime services?
<Griwes>
oh, i see what you are asking, I lost a bit of context there
<Griwes>
by "runtime bytecode services" I didn't necessarily mean uefi
<mrvn>
You might have a point about optimizing runtiume services if they include any device drivers.
<Griwes>
I mean things like aml bytecode or pieces of device roms
<mrvn>
I think nowadays nothing used device roms at runtime. Probably mainly because the 16bit code won't work in long mode and such.
<Griwes>
but it would be fine if roms have been implemented in webasm ;>
<Griwes>
you'd just load their modules and run them
<mrvn>
Or even more readable forms
<mrvn>
And once booted you can upload firmware blobs to get optimized performance.
<Ali_A>
This might not be an OSdev question but I don't know other places to ask such question
<Ali_A>
under x86 linux (SYSV ABI)
<Ali_A>
I am trying to understand why do I see a lot of this in linker scripts
<Ali_A>
. = 0x1000
<Ali_A>
/some stuff goes here
<Ali_A>
. = 0x8000000 //other stuff goes here
<Ali_A>
I thought the stack size is usually 1MB per process?
<Ali_A>
but according to this picture it seems to be 128 MB
<Ali_A>
and to quote them > The stack resides immediately below the text segment, growing toward lower addresses. This arrangement provides a little over 128 MB for the stack and about 2 GB for text and data.
<GeDaMo>
The stack size is what you make it
<Ali_A>
GeDaMo so there is no convention to make it 1MB or 2 MB or anything? I can make it as big as I want (almost as big as I want, as I know there should be some OS reservation for the process)
<zid>
If you're asing for a review of a specific linker script
<zid>
it helps to post the specific linker script
srjek|home has quit [Ping timeout: 260 seconds]
Likorn has joined #osdev
srjek has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
srjek has joined #osdev
nopenope[m] has quit [Quit: You have been kicked for being idle]
scripted has joined #osdev
<scripted>
Hello people. I'm stuck with this page frame allocator I tried to write using a tutorial. So the issue is that the both variables (end_mmap_addr and curr_mmap_addr) are 0, so I think I've made a mistake while passing the multiboot structure. The line I'm talking about is 20 https://github.com/ScriptedDeveloper/CrazeOS/blob/unstable/src/pageframe/pageframe.c
<bslsk05>
github.com: CrazeOS/pageframe.c at unstable · ScriptedDeveloper/CrazeOS · GitHub
dzwdz has joined #osdev
<dzwdz>
i hope getting back in this channel will peer pressure me into actually working on my OS lol
<scripted>
dzwdz: don't worry, I halted OSdev development for an entire week
<scripted>
*my
<dzwdz>
> week
<dzwdz>
i haven't really worked on mine since november
<scripted>
dzwdz: that's bad, get your lazy ass up or help me
<dzwdz>
i've got a bunch of work done over the weekend
<scripted>
I'd study osdev like 5/7, but school is really stopping me to do so
Likorn has quit [Quit: WeeChat 3.4]
<dzwdz>
school is really stopping me from... everything
<dzwdz>
i'm too exhausted to do anything once i'm home
Likorn has joined #osdev
<scripted>
dzwdz: I know exactly how you feel, it's keeping your energy away from your hobbies
<scripted>
but then you still have to do homework, after you finished with that you either have to go to sleep or do some stupid shit like watching youtube or something since you are so exhausted
ephemer0l has quit [Ping timeout: 240 seconds]
<dzwdz>
so anyways, does anyone know if i can somehow get GRUB to boot my kernel in the vga text mode?
<GeDaMo>
Does adding a vga=3 to the kernel line in grub work?
<gog>
i'm doing it, i'm writing my own EFI headers
<gog>
this sucks
<gog>
and the spec document is riddles with typos
<zid>
my monitor bit flipped again
<gog>
ope
<zid>
decided that pixel 1024 was the first pixel
<gog>
is this your trusty crt?
<zid>
fun effect, left and right sides of the display swapped
<zid>
no, crts don't have firmware :p
<gog>
yes they do
<gog>
what is EDID?
<clever>
gog: i think originally, just an i2d rom
<clever>
i2c rom*
<gog>
hm
<gog>
i guess that's not quite firmware
<GeDaMo>
Does your monitor have a goatee beard? It may be from the mirror universe :|
<gog>
just a ROM image you can slurp from
* gog
slurps ROM
<clever>
and it just tells you what the monitor supports in terms of resolutions
<gog>
ye
<clever>
you can ignore edid, and just feed it whatever you want
<clever>
but i have seen signs of even my old vga crt, having firmware
<clever>
both the OSD for configuring it, and how it behaved from malformed signals
<clever>
if vsync was out of bounds, the power led would blink orange
<clever>
and due to an undefined variable, i wound up configuring the hw for interlaced mode, even field was 1/60th of a second, odd field was 2 seconds, lol
<clever>
the screen would see 2 vsync pulses at 1/60th apart, power led would turn green, then it didnt get another vsync, timed out, and turned off
<clever>
repeat every 2 seconds
<zid>
You can do all that with a cpld or whatever
<zid>
doesn't have to be firmware
<clever>
yeah
<clever>
*looks*
srjek|home has joined #osdev
<clever>
and now android is playing games
<clever>
i just took a photo, it claims i have zero photos on the phone
sonny has joined #osdev
<clever>
zid: it was a CPD-100SX
srjek has quit [Ping timeout: 240 seconds]
<zid>
I have a cpd-200es on my desk
<zid>
that's like twice as good
<clever>
zid: in one of the service manuals i found online, it mentions "microprocessor and sync processing" and an 80c51
freakazoid343 has joined #osdev
<clever>
8k of maskrom, 8051 cpu core, stores the graphics for the OSD, but the bulk of the firmware/config are on an external 8k eeprom
<clever>
and it has an rs232 bus as well
sonny has quit [Ping timeout: 256 seconds]
<zid>
these are fancy trinitrons though
<zid>
I've had crts with wheels to dial things in and not an osd
<clever>
yeah
<clever>
in theory, all you need to do is turn hsync/vsync into a sawtooth waveform, and your done
<clever>
adjusting the rate of change, will stretch the image, and it could auto-adjust some to match up with the next sync
<clever>
adding a dc offset will change the xy position
<clever>
boom, done
<zid>
see: oscilloscope
<zid>
I love a good braindead scope that just does what the input signal says to do
<zid>
the new ones that take 8 minutes to boot and run windows make me said
<zid>
sad*
<clever>
ive got an old tektronix 2232
srjek|home has quit [Ping timeout: 240 seconds]
srjek has joined #osdev
scripted has quit [Quit: WeeChat 3.4.1]
sonny has joined #osdev
C-Man has quit [Ping timeout: 256 seconds]
C-Man has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 272 seconds]
Likorn has quit [Quit: WeeChat 3.4]
knusbaum has joined #osdev
jack_rabbit has quit [Ping timeout: 256 seconds]
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 268 seconds]
ephemer0l has joined #osdev
pretty_dumm_guy has joined #osdev
Ali_A has quit [Quit: Connection closed]
wolfshappen has quit [Read error: Connection reset by peer]
Oli has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<heat>
mrvn, I'm very late to the party but literally all of UEFI uses boot services
<heat>
drivers, apps, all use boot services
<heat>
it's not just a cute thing #osdev toy bootloaders play with
sonny has joined #osdev
<j`ey>
l i n u x uses boot services
<heat>
fax
<heat>
j`ey: i'm going to be a mentor in tianocore this gsoc!
<j`ey>
I've been playing with runtime services to do PSCI
<j`ey>
heat: wew nice!
<j`ey>
from mentee to mentore :D
<j`ey>
*mentor
<heat>
yeah it'll be a fun experience
<heat>
definitely out of my comfort zone, but fun :)
<sortie>
Anyone else into Unix fan fiction?
<heat>
fuck yeah
<heat>
who's nailin' netbsd
<j`ey>
lmao
<heat>
fork their socket
<sortie>
I'm shipping dracobsd & linux
<sortie>
Documenting my OS feels like writing Unix fan fiction
<heat>
steal someone else's man pages
<heat>
ez
<sortie>
You wouldn't steal someone else's design, it's terrible
* heat
looks at his OS
<heat>
>budget linux
<heat>
haha totally wouldn't
wolfshappen has joined #osdev
<heat>
j`ey, how does PSCI play with the runtime services?
sonny has quit [Quit: Client closed]
<j`ey>
heat: problem with m1 is that there's no EL3.. which is normally where PSCI code would reside
<j`ey>
so we're tryning to do PSCI with an EFI runtime service
<heat>
can you still call it with hvc?
<heat>
or however you call it
<j`ey>
nope
<j`ey>
just a normal call
<immibis>
Griwes: then you find a ROM that relies on some obscure webasm extension. WebASM doesn't binary compatibility any more. It only did temporarily, because there was only one version
<immibis>
but now they are adding extensions like multiple memory regions, shared memory, reference types and garbage collection
<heat>
j`ey, do you extend the runtime services table?
<Griwes>
None of those extensions seem "obscure"
<j`ey>
nah, added a new table kind
<immibis>
Griwes: it is obscure to your pre-extension uefi!
<heat>
we should all shut up and use efi bytecode
<Griwes>
It's not like having to do a bios upgrade from time to time to support new hardware is unheard of
<immibis>
not for such a silly reason as "the programmers wanted to use garbage collection"
<immibis>
that is how the web works, not hardware
* Griwes
shrugs
<immibis>
on the web you have to upgrade your browser so javascript programmers can have better syntax
<heat>
ban those extensions
<heat>
easy
<Griwes>
It's "you need bios upgrade to run this hardware" which is not outlandish in my opinion
<Griwes>
The user doesn't care about the details, new hardware, need new blob, it's all the same to non nerds
<heat>
i mean the status quo is that the bytecode is x86 machine code
<heat>
which is fine I guess
<heat>
just interpret that
<heat>
no need for web asm
<Griwes>
"just" interpret that
<Griwes>
That's a load bearing "just"
<heat>
edk2-non-osi has an embedded qemu interpreter that does that
<bslsk05>
github.com: edk2-non-osi/Emulator/X86EmulatorDxe at master · tianocore/edk2-non-osi · GitHub
<Griwes>
But that only works for boot services when firmware is in control, not later, and is also a gigantically stupid hack for something that should be sane
<Griwes>
Also what if the rom uses instructions that your emulator doesn't yet know about?
<Griwes>
You're now in the same situation as with bytecode extensions
<heat>
what if the rom uses instructions that your CPU doesn't yet know about?
<Griwes>
The cpu does, because on x86 it requires a newer cpu
<heat>
why do you care about running rom when firmware isn't in control
<Griwes>
(which is worse than it would've been if it was using bytecode, because then on x86 it would also just need a new blob)
<Griwes>
If the OS is capable of running a portable bytecode from roms, you could probably greatly simplify a number of interactions between the OS and hardware
<heat>
like what?
<Griwes>
Don't know, ask me again once I started dealing with pcie so that I can have a list of grievances ready
<heat>
pcie is simple, hardware isn't
<Griwes>
With pcie *devices* is what I meant
<heat>
right
<heat>
i mean, honestly, I don't see what you should put inside a ROM
<heat>
you obviously can't stick a whole driver in there unless you provide standardised interfaces to/from the driver
<heat>
(which is what happens with UEFI)
freakazoid343 has quit [Ping timeout: 256 seconds]
<catern>
i want to vaguely allude to the concept of running programs on a CPU in your NIC or in a CPU in your storage device, to reduce the latency of touching the data
<catern>
is there a good introduction to this that I can link to?
<catern>
just, anything I could link to, so I don't have to explain it
<immibis>
catern: latency or throughput? Because doing that for throughput is basically every accelerator ever, from TCP offload to GPUs
<catern>
latency
<immibis>
there are NICs with FPGAs on them, or rather, FPGA accelerators with NICs on them
<bslsk05>
www.usenix.org: Willow: A User-Programmable SSD | USENIX
<catern>
but it would be nice to be more explicit and just, y'know, actually explain it
<immibis>
can't say I've ever heard of a situation where the couple of light-nanoseconds between a M.2 SSD and a CPU were a problem.
<catern>
shrug, well if anyone else is familiar with this area and has a good link, perhaps you can read it
<immibis>
maybe just vaguely allude to the word offloading
<catern>
i don't think that's enough since I don't mean the form that you're familiar with :)
<catern>
so just saying offloading is ambiguous/may give the wrong impression
<immibis>
what is a storage device but built-in processing, but a computer?
<immibis>
with* built-in processing
<immibis>
you just built a computer and put it in a SSD form factor and wrote SSD on the label
<catern>
okay, well hopefully someone else is familiar with this since like I said, I don't really want to have to explain this, to you or in the article I'm writing :)
mahmutov has quit [Ping timeout: 260 seconds]
jack_rabbit has quit [Ping timeout: 272 seconds]
knusbaum has joined #osdev
freakazoid12345 has quit [Read error: Connection reset by peer]
<catern>
um, unrelated question: I don't really know anything about DMA, is it ever used to communicate directly between two devices without the involvement of the main CPU?