<heat>
and erm, thinking about it again, that doesn't really matter
<heat>
clac is supposed to protect against accidental writes
<geist>
exactly
<heat>
i really should look at doing that xD
<geist>
64bit syscall entry you dont have to clac because you can put it in the mask bits of the STAR register
<geist>
so that it comes automatically cleared
<geist>
but i dont think you get that with 32bit syscall
<geist>
and sysenter, dunno.
sonny has joined #osdev
sonny has quit [Ping timeout: 252 seconds]
<geist>
anyway the itanium mechanism is whacky: you can mark a page (or any number of them) as syscall trampoline pages. i forget what the name is
<geist>
but basically it's a bit on the page
<geist>
and then if the cpu is in user mode and inside the page and it runs the 'epc' instruction, it just switches to ring0 and continues running
<geist>
so basically you build your vdso out of that to then just direct branch up to the kernel
<geist>
so it seems impossible to do that securely but i think the trick is the fact that ia64 has the bundled instructions (up to 3 instructions in a bundle) and you can't partially run a bundle, or branch into the middle of them
<geist>
so you carefully arrange for it to be that if you branch to any spot before or after the bundle with the epc in it it is detected that it happened
<geist>
otherwise the instruction is basically zero cost transition from ring 3 to ring0
<heat>
how does it detect that?
<geist>
detect what?
<heat>
that you branched before or after the epc
<geist>
cpu doesn't, software does
<geist>
now maybe that linux url you linked before will make more sense
<geist>
because it's talking about the kernel side of it, and i thik there's some implicit structure to it
<geist>
(it still doesn't, but that's the fun brain teaser about it)
<geist>
it may also be set up such that it's not really important that every possible branch point be validated and rejected, but more that it'll just crash the program if you dont
<heat>
“alloc” instruction
<heat>
oh jeez oh man
<heat>
ia64 assembly D:
<geist>
for exampe if you branched after the epc instruction you'd just get a branch up to the kernel, well that'll fail because it didn't make it into ring 0
<geist>
or if you skipped over the part where it lodas the syscall # into the right register, doesnt matter, you'l get out out of bound syscall, etc
<geist>
it's only important that you cant defeat the mechanism and somehow get a sploit
<heat>
yup
<heat>
this vdso problem is brain teasing the shit out of me
<heat>
i was thinking that "mandatory vdso" could make it a security boundary, but I guess that's not really possible in current architectures
<heat>
but then everyone can write to vdso text, so that doesn't work as well lol
<heat>
and serialization would be an issue
<heat>
and cache flushing too
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
<mrvn>
AmigaOS has something similar to the EPC thing. When you enter supervisor mode it checks if the return address is the library function that should do super visor switches and if not it's a violation.
ngc0202 has quit []
<mrvn>
heat: what would stop anyone from jumpting to vdso_entry+7?
<heat>
what's +7 here?
<mrvn>
syscall
<heat>
it would go int3 and die
<mrvn>
What do you get when you cross an elephant with a rino? Hell-if-I-know.
heat has quit [Read error: Connection reset by peer]
<Mutabah>
I guess such a check is just defence-in-depth
<Mutabah>
sure a mailcious program could jump to the `syscall` instruction, but it'd be one more step in a chain
<geist>
interesting: the gcc 12.x zero length array thing
<geist>
looks ike it only applies to pointers < 4K (0x1000)
<geist>
dunno, my experience is compilers are generally not really good at constant folding like that
<geist>
or sharing of nearby constants at least
<mrvn>
I've seen this with UART code too. Even if you make a pointer to the UART base and then access p[0], p[4], p[20] it till compute the absolute addresses of each and load each from memory into a register.
<mrvn>
s/till/will/
<geist>
i think i've pointed it out every time this comes up but i've seen a compiler (TI piccolo DSP) that actually as a post link optional constant folding pass
<geist>
basically looks at the binary and then tries to restructure the code to combine stuff like this
<mrvn>
I would be happy if gcc stopped unfolding constants
<geist>
and definitely fold constant pools together
<geist>
but then try to modify existing code to base off less common constants. pretty neat idea
<geist>
might not really be adding or removing instructions though, but on a little arch like Piccolo it might use load + PC to get constants a lot, and combining those post link would be fairly easy
<mrvn>
On ARM *0xfff should also do 0x1000-1 on its own. There is no need to create the exact constant, only something close enough to access with an offset.
<clever>
something ive kind of wanted (having seen it in a lot of asm i look at), is if i have a whole whack of 32bit constants (peripheral reg addrs) being cast into pointers and de-referenced
<clever>
for the compiler to find a common base, store that in a reg, and then do reg+immediate addressing
<mrvn>
or just leave the common base I typed in
<geist>
mrvn: i do forget what the range of offsets are for ldrs, they might be units of 4, and/or not negative
<geist>
but the idea still stands
<clever>
some of my newer code is doing constant + constant + constant to create those reg addr's
<clever>
and instead of pre-adding them at compile time, it could shove one into a reg, and add at runtime
<mrvn>
they usualy are in multiples of the data type. No point providing unaligned access
<mrvn>
clever: except the compiler sees the pointer is a literal and then optimizes the variable away
<clever>
yeah, it needs to detect when a dozen literals are within range of a reg+immediate load, and are all being used for load/store
<mrvn>
that and when a constant is used multiple times and keep it as a base
<bslsk05>
github.com: lk-overlay/hvs.h at master · librerpi/lk-overlay · GitHub
<clever>
an example of adding 3 constants
<clever>
if i was writing the asm directly, i might use SCALER_BASE in a reg, and then reg+imm offsets
<geist>
that being said theres probably some particular optimization paths on particular cores of particular arches where it's better to start from scratch on very pointer
<clever>
but because of the lack of clean tools for computing those offsets, i do this instead:
<geist>
i can see, for example, x86 chewing up movabs + mov
<geist>
like that's probably flattened into a single uop
<bslsk05>
github.com: lk-overlay/start.S at master · librerpi/lk-overlay · GitHub
<geist>
and not doing a offset addition can probably save one uop or whatnot
<clever>
where i just have a bit flat list of reg+value's and i load each pair, and store
<geist>
or use more execution ports
floss-jas has joined #osdev
<clever>
yeah, speed is also a question
<clever>
which is faster, a giant table of immediates that you need to ldr, or a reg+offset
<geist>
ARM cores i thik all have basically 'free' offset additions, but writeback usually adds a cycle or so of latency
<clever>
writeback?
<geist>
so if you have a long list of dependent loads, like pushing/popping off a stack it's generally recommended to decrement/increment and then do load/stores relative to that
<geist>
`ldr x0, [x1], #4!` kinda stuff
<clever>
ah, yeah, if your changing sp a lot
<geist>
basically post or preincrement with write back to the base register
<clever>
then it needs to know the new sp
<mrvn>
I believe the imm in "ldr x0, [x1], #4" is free.
<geist>
most high end cores have a completely special path for SP though, but in general for other regs may not
<clever>
most asm i see, just does an add/sub to sp, then sp-relative load/store
<geist>
mrvn: i think it might add another cycle of latency for the writeback, but then compared to a single add afterwards it's still better
<mrvn>
same with (%eax, %edx * 4, #16) on x86
<geist>
*unless* you have another ldr right after it, in which case you're adding a bubble
<mrvn>
might be
<mrvn>
but is loading a constant from memory faster?
<geist>
that's what i mean, they say if you have a long series of load/stores that fiddle with the same base register, usually better to modify the base register before or after
<geist>
and then use the 'free' offset addition that comes with the load/store unit
<geist>
i'm thinkig mostly stuff like pushing/popping from the stack or some data structure manipulation
<geist>
reading 4 things out of the array and then bumping the pointer by 4
<mrvn>
stack is different though as it's nearly always in cache
<geist>
wel more so than that, the SP has special machinery behind it potentially to keep it very close to earlier stages in the pipeline
<geist>
arm64 codifies that by making SP be outside the regular register file
<geist>
it can basically sit off by tself and get known earlier in the pipeline, and only needs to be flushed back to the register file on some sort of instruction that needs the value
<mrvn>
stack access might even just work out of the write buffer, so even closer than L1 cache
<geist>
yah
<geist>
i forget precisely how ARM64 encodes the SP. dunno if it has its own opcodes (you can only do some ops against SP) and/or if it's encoded as x31 (zero register) when a base register to LDR/STR
<vdamewood>
I think it only had load and store with the regular file
<mrvn>
using x31 in LDR/STR seems kind of unwanted so I would assume that gets overloaded to something else.
<vdamewood>
Oh, wait. it would make sense for it to also support add and sub operations
<geist>
you can use it as a base and whatnot in arm64 at least, and even load into it, but it must be encoded differently
<geist>
yah you can do add/sub with oit, but most of the bit operations aren't supported
<geist>
mrvn: yeah. how it's encoded as a target register i dunno, becuase you absolutely can load/store xzr
<vdamewood>
Whcih makes sense, you rarely want to bitshift your stack pointer.
<mrvn>
vdamewood: linux used to have the struct TASK at the top of the stack so you would do: (SP + 0x7FFF) & ~0x7FFFF to access it.
<mrvn>
or SP >> N << N
<mrvn>
when stack goes upwards
<geist>
okay. just verified. you can use SP in the base register slot of any load/store, and it seems to use x31 encoding for that
<geist>
but you cannot load/store into/out of SP. thought you coudl, but no
oriansj has joined #osdev
<geist>
so that makes sense. if you want to save SP to the stack you need to move it into another register, which is usually what happens anyway. save x30 (the base register) and then load SP -> x30
<mrvn>
-fomit-stack-pointer
<geist>
and looks like the ALU ops that work against SP are a special opcode that explicitly is for 'extended registers'
<geist>
and only has a few opcodes like add/subtract
<geist>
and in that case it's the same thing: x31 is SP. presumabky you can't do things with xzr in those instructions
<geist>
like maybe add sp, sp, xzr is illegal
<mrvn>
makes sense, most ops with 0 with ned NOPs. "0 - reg" usualy has it's own opcode
<oriansj>
hello, I have a strange question but in the interest of creating the next major piece in https://bootstrappable.org/ I need to write a POSIX kernel in assembly (or find an already existing one) capable of running TCC (or GCC) and I was wondering if anyone had or knew of a kernel they would be willing to let me leverage for that work?
<oriansj>
mrvn: a bit hard to hand convert to assembly though
<mrvn>
I don't know, gcc does that fine. :)
<oriansj>
mrvn: I know, we bootstrapped GCC from hex
<oriansj>
but to address the Ken Thompson Trusting trust attack, it requires us to create a trusted bootstrap and as of yet we haven't bootstrapped GCC on bare metal yet
<oriansj>
we have bootstrapped a much simpler C compiler on bare metal but it likely is not going to be powerful enough to get us to GCC without considerable more effort.
<bslsk05>
fosslinux/live-bootstrap - Use of a Linux initramfs to fully automate the bootstrapping process (11 forks/151 stargazers)
<Mutabah>
Depending on your hardware target, a posix-ish kernel (enough to run tcc) wouldn't be too complex - you'd probably want something purpose built though.
<Mutabah>
That said, I think most bootstrapping projects go via an intermediate language - e.g. forth
<mrvn>
Maybe just build a barebone gcc?
<mrvn>
gcc doesn't need a lot of syscall
<Griwes>
I mean supposedly you have a C compiler in assembly already, so you could write a simple kernel in C, which would be an improvement over needing to do it in assembly
<oriansj>
Griwes: yes we wrote a C compiler in assembly that does run on bare metal and one that was written in assembly to run on a POSIX kernel using only open/close/read/write/brk
<Griwes>
also I hope you aren't targeting x86, because both microcode and smm can work around any bootstrapping mitigations to the thing Thompson described :P
<Mutabah>
^
knusbaum has joined #osdev
<Mutabah>
I'd probably target a RV64 board, with some form of basic onboard flash storage
<clever>
Griwes: i assume it would have rules about picking a cpu or firmware that is also trustable, but building that...
<oriansj>
Griwes: actually we are doing ports for EVERY architecture. and have written these compilers in assembly for AArch64, armv7l, RISC-V (both 32 and 64bit), Knight, x86 and AMD64 architectures
<Mutabah>
RV64, simple NAND flash, a basic keyboard
<clever>
oriansj: would you be interested in adding another, that currently even lacks linux support?
<Griwes>
right, but what I'm saying is that x86 is particularly untrustworthy if you're caring about this
<oriansj>
clever: I am happy in adding *EVERY* possible CPU architecture as potential roots for bootstrapping
<clever>
oriansj: i'm thinking about the VPU core on the rpi, that runs before the arm, and is basically a threat vector if you where to try and bootstrap using an rpi
<geist>
what do you mean roots for bootstrapping?
<clever>
oriansj: but if you instead bootstrap from the VPU, it cant be a threat
<Mutabah>
I think Griwes' point is that if you're going to the level of writing a kernel for bootstrapping, you also want to be aware of the issues of your hardware
<Mutabah>
x86 would be fine... with much older x86 chips that don't have microcode.
<geist>
i'm missing the point here, what is going on?
<oriansj>
geist: as in all of the architectures bootstrap to a universal cross-platform build toolset which enable any architecture to audit the results of all other architectures creating a mesh of audits
<clever>
oriansj: i think the main features to be aware of on the VPU, is that the opcode size is variable (but always a multiple of 16bits), there is no mmu, but there is a form of MPU, and it can do cache-as-ram, and has a working secure mode similar to arm
<geist>
ah okay
<oriansj>
the key goal is I need to find a kernel to serve the purpose of providing a bootstrap Kernel for bootstrapping the entire world
<bslsk05>
littlekernel/lkuser - framework for a simple user space for lk (10 forks/18 stargazers)
<clever>
if you bake tcc into the kernel, as just another function, it could run tcc
<clever>
gcc feels a bit too big for that though
<geist>
someoe is off doing a fork of that trying to get it to work too
<oriansj>
clever: I only need the kernel to support 31 unique syscalls
<geist>
need to build up a bunch of filesystem syscalls in the lkuser thing but could be probably hacked to get a posixy looking simple user space fairly simply
<klange>
31 sounds like a lot
xenos1984 has quit [Read error: Connection reset by peer]
<oriansj>
open/close/read/write/lseek/chmod/mkdir/mknod/umask/access/chdir/unlink/getcwd brk/exec/waitpid and uname (17 core) are those that are needed to run the steps up to a cross-platform C compiler
<klange>
mknod and uname? really?
<geist>
yah i was curious about those too
<geist>
maybe that's some sort of script to set up /dev first too
<oriansj>
klange: as it currently exists right now, yes
<oriansj>
inital file system only is expected to have 357bytes worth of binary and a pile of source code
<clever>
dang!
<oriansj>
so we build our init, shell, linker, assembler, C compiler, untar, ungz, sha256sum, mkdir, chmod and several other tools before we start unpacking .tar.gz files and having to make folders like /bin and /dev and more
<clever>
sounds a lot like the nix bootstrap tools
<oriansj>
we have a program get_machine which allows us to do host operating system directed builds
<oriansj>
clever: it is the root of guix's bootstrap build
<clever>
ah
<oriansj>
we want to go deeper down the stack and remove the Kernel from the TCB
<clever>
nix is a lot fatter, a tar containing a pre-built gcc and support binaries
<oriansj>
but I need a kernel I *CAN* bootstrap from what we have running on bare metal
<oriansj>
yeah, we bootstrap a full Linux distro from 357bytes
<oriansj>
hence why I am searching for a kernel to bootstrap (either by converting to the M2-Planet C subset) or by hand compiling it into assembly
<oriansj>
The only requirements we have is the ability to write to a storage media (ata disk/floppy disk/paper tape or something), Virtual memory, able to handle single tasking and supporting the 31 syscalls required to run TCC (no user interaction required)
<clever>
but how can you be sure the kernel has been put together correctly, without trusting other kernels?
xenos1984 has joined #osdev
<oriansj>
clever: good question
<oriansj>
fortunately sha256sum can run on a 6502 on bare metal and monster6502 solves the lithography trust problem for us as well
<clever>
and what about bios level exploits?
<oriansj>
clever: well the developer for those bios level exploits is able to subvert *ALL* hardware architectures and *ALL* cross-platform builds including for CPU architectures that haven't been invented yet
<clever>
in the case of something like the rpi, there is a ~18kb mask rom in the cpu, and some OTP to configure what it can boot from
<clever>
and that loads up to 128kb of bootcode.bin from a configured source, into cache-as-ram
<clever>
and then executes it
<clever>
assuming you can trust the maskrom, would that be a possible bootstrap source?
<oriansj>
clever: I assume all hardware is compromised but I know if we have enough hardware architectures providing roots of trust to the common perfect reproducible cross-platform builds chain; any subversion would have to work on *ALL* cpu architecture ever invented and ever to be invented *FOREVER* to avoid detection. And do so without any updates *FOREVER*
<clever>
as far as i know, the maskrom is a true rom, and there is no mechanism available to patch it on startup
<clever>
so if you audit the board for any unexpected flash media, you can be sure that the only code it can possibly run, is your own code
<clever>
an attacker would have to replace the silicon in the cpu to violate those assumptions
<oriansj>
clever: we can even throw custom hardware at the problem; like punched paper tape readers and manually inspected punched paper tape
srjek has quit [Ping timeout: 250 seconds]
<oriansj>
CPUs made out of individual transistors
<oriansj>
core memory and other exotics
<clever>
yep
<clever>
ive seen a computer made out of relays
<clever>
it sounds amazing
<oriansj>
but that will the problem *AFTER* we sort out the kernel problem
<bslsk05>
'Harry Porter's Relay Computer' by hhp3 (00:02:01)
<oriansj>
I seek a kernel to provide just enough for us to bootstrap the world; as I assume there are much better kernel programmers here
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
<oriansj>
so any other kernel recommendations that I should look into as potential bootstrap kernels?
<klange>
I think if you can manage to write all those other utilities, you can write your own kernel, and then you can trust it more because you've done a thorough source audit by writing it in the first place...
zaquest has quit [Remote host closed the connection]
<Mutabah>
^
<Mutabah>
I've not kept up with the discussion, but a few notes
<Mutabah>
1. if you want an assembly-only kernel, then you'll be VERY tied to the architecture
<oriansj>
klange: well yes, doing all of that work took 5 years of effort; and if need be, I'd do the same to solve the kernel problem. But just in case someone else here is interested in that problem space and worked in that direction, I'd prefer to help them reach that shared goal
<Mutabah>
(there is no porting, there is only re-writing)
<Mutabah>
2. If you don't want to write your own, then maybe look at MenuetOS?
<oriansj>
Mutabah: well a kernel in a restrict C subset is also an option but yes you are absolutely right about assembly-only programs being very tied to the architecture
smeso has quit [Quit: smeso]
<Mutabah>
Most pre-existing kernels will not be built with the restrictions you have in mind, so you're going to have to write your own
<Mutabah>
does sound like an interesting project though
smeso has joined #osdev
<oriansj>
Mutabah: darn, I was aiming at boring and too simple to be of interest to anyone
<Mutabah>
well, the idea of taking a simple SOC with no pre-existing firmware, and writing a basic firmware that allows data entry, and building up a bootstrapped system on a NAND chip
<Mutabah>
although, you could probably trust a SD card to provide the data you requested?
<Mutabah>
(you'd want some sort of signature on your data, just in case the card does mangling :D)
<oriansj>
Mutabah: we can do sha256sum on bare hardware
<oriansj>
also we can do custom hardware (like paper tape reader/writer made out of individual transistors)
<oriansj>
and I do expect to have to write the same kernel for several architectures if I do it in assembly (possibly doing speed runs after the first to keep it interesting)
<oriansj>
and I'd be doing it first in C to figure out the logic required before doing the conversion.
Likorn has joined #osdev
<klange>
> MenuetOS
<klange>
I would say look at Kolibri; Menuet is not viably licensed for such a project.
<klange>
But then Kolibri is still only 32-bit (forked from Menuet), the non-FOSS Menuet is 64-bit.
<moon-child>
I mean
<moon-child>
if it's not opensource, there's a limited extent to which you can ... look at it
<moon-child>
even if written in assembly
<klange>
It's inherently source-available, you're just not allowed to do anything with that source.
Vercas has quit [Quit: buh bye]
<klange>
(I don't know off hand if they actually release the original source files, eg. with comments, and don't care to check.)
Vercas has joined #osdev
<moon-child>
yeah, if you disassemble you lose comments, formatting, symbol names, macros...
troseman_ has quit [Ping timeout: 276 seconds]
FatAlbert has joined #osdev
<FatAlbert>
fjklaj
<moon-child>
agreed
<FatAlbert>
i changed battries to the keyboard
<FatAlbert>
i was talking to my mom and im not sure that the two are the actually new ( at least one is because the keyboard is working now )
* kingoffrance
.oO( whoever posted a link other day for x86 switching to vga mode 0x13/256 colors/320x200...apparently bochs and qemu, when pxe booting, switching to that mode, then outputting text, they seem to reroute/draw the text to the graphics lol )
<kazinsal>
ah, the good ol' days of the internet. where you usually had to know someone at a friendly dial-up provider or be in academia to host a web page, usenet reigned supreme for discussion, and 320x200 porn loaded line by painstaking line
jjuran has quit [Ping timeout: 260 seconds]
<geist>
yah i love how its like bam page loaded
<geist>
also wow MenuetOS. back in 2001 when i wrote an article for Dr Dobbs on Newos, menuetos was the other article in the magazine
<Mutabah>
It popped up on HN recently I think (or might have been /r/programming)
<Mutabah>
quite the blast from the past
<kazinsal>
if it popped up on HN I guarantee half the comments are going to be people debating whether or not it should be rewritten in rust
<geist>
heh
<bradd>
narrowed it down to a rpi 3 a+ or a rpi 4 b. I will be using this just to test my arm code. would the 3a+ be enough to do this? (and will code on the 3a+ be compatible with the 4b?). (the 3a+ is much cheaper so i'd like to go that route if compatibility wont be an issue)
<kazinsal>
just get a 4.
<bradd>
ok. I've found 2 sellers on ebay for used p4's at around $100 cad. guess I'll grab one of those
<kazinsal>
unless you're extremely terribly strapped for cash, the 4 is going to give you better instruction throughput, much more memory, full gigabit ethernet, etc
<kazinsal>
also it's a cortex-a72 versus an a53 (iirc)
jjuran has joined #osdev
<bradd>
alright, I'll put the order in then. thanks kazinsal
<kazinsal>
I'm not the local arm wizard but I am canadian so that counts for something when it comes to sourcing parts
<kazinsal>
notably I think canakit is *still* out of stock and will be until at least late summer
<bradd>
yeah. all i found was 2 used ones on ebay.ca
<kazinsal>
you might be able to get a Pi 400 new
<geist>
kazinsal: you did good
<kazinsal>
iirc it's basically a pi 4B with a higher clock rate inside a keyboard
<geist>
right
<geist>
if you can happen to find one cheaper, go for it
<bslsk05>
www.canakit.com: Raspberry Pi 400 and Accessories
<kazinsal>
$70 CAD without accessories
<kazinsal>
$94.90 CAD with a 32 GB microSD and a 3.5A power supply with on/off switch
<bradd>
oh nice. thanks. looking at it now
<kazinsal>
iirc the keyboard on them isn't bad either. nothing fancy but not totally cheap crap
<bradd>
that would still be good for arm osdev testing right?
<kazinsal>
yep. grab one of the micro HDMI cables that they sell and you can hook it up to any HDMI display
<bradd>
sounds good. ty again
<kazinsal>
it's architecturally the same as a Pi 4 B as far as I know
<kazinsal>
just a bit faster because it can clock higher with the larger surface area for thermal dissipation
<Mutabah>
and a bunch of fancy accessories
<bradd>
excellent
<kazinsal>
honestly having a hard time not just clicking "checkout" myself
<kazinsal>
but I just bought a new leather jacket so I should probably cool it with the frivolous spending for a bit :)
<Mutabah>
I got very tempted by one last time I was doing parts shopping... tempted again
<Mutabah>
But I'm not sure I'd actually use it... not for long enough to really justify it...
<kazinsal>
yeah, today's been a day of "ooh, <thing> is in stock... no, wait, I shouldn't" for me
<Mutabah>
then again... if it's beefy enough to youtube...
<vdamewood>
I'm half tempted to try using CMake to generate the build system for my OS.
<Mutabah>
(My laptop has a thermal management bug, known to hardlock under stress)
<vdamewood>
Well, at this point, s/OS/boot code/
<kazinsal>
I very nearly bought a 5900X and then remembered that the 7000 series is likely to be out in the late summer
<kazinsal>
and then very nearly bought a Line 6 Helix HX effects processor...
<kazinsal>
I think when Ryzen 7xxx is out I'll probably buy two -- one to replace my 8700K, one to replace my 2x E5-2620 server
<kazinsal>
or maybe a used 5900X for the server
<kazinsal>
then the 2620s will go to the great e-recycler in the sky and the 8700K will turn into an osdev test box
zaquest has joined #osdev
<vdamewood>
Is it any easier/harder to develop a GUI on AMD vs nVidia GPUs?
<geist>
huh! you know, i never thought to try this but if i simply pll out the video card on this ryzen machein i'm using as my server
<geist>
it just boots and runs fine
<geist>
soooo i dont really need a vid card in it anyway
<geist>
i hadn't even thought to try, i assumed it'd just beep at me and not post
<Mutabah>
vdamewood: Well, GUI tends to be separate to the video driver...
<Mutabah>
but I'd guess that AMD would be slight easier to write a naive driver for, since they provide some level of docs last I checked
<Mutabah>
(although, the noveau driver is aparently pretty good on the docs department)
<Mutabah>
You can get pretty far along just blitting to a bootloader-provided framebuffer
<vdamewood>
Mutabah: I probably should have specified graphics driver.
les has quit [Quit: Adios]
les has joined #osdev
bauen1 has quit [Ping timeout: 276 seconds]
wand_ has joined #osdev
wand has quit [Ping timeout: 240 seconds]
SGautam has joined #osdev
<kazinsal>
geist: oh neat, what ryzen model?
<kingoffrance>
https://defuse.ca/b/Nhfe8U5P8Wk9N6DTDE2StZ pw: x silly bochs patch to make "in" from port 0xE9 read from a fifo if an env var is set. now to try qemu :) i actually have serial port code, but haven't tested yet lol
<kingoffrance>
hmm, actually i should close that fd or make it static :/
<FatAlbert>
you guys still didn't explained to me what is serial port and what is used for and i hang out with you for queit a bit of time
<FatAlbert>
i know what it is only in the context of hardware
<FatAlbert>
not in the context of software
<FatAlbert>
kingoffrance: let's start with you .. what is `serial port code` ?
<Mutabah>
... Directly calling someone out is kinda rude
<Mutabah>
And your initial statement can also be read as rude, as if we should have explained what a serial port is.
<Mutabah>
Have you tried searching the internet yourself?
<kingoffrance>
when i mentioned above idea few days ago, it was pointed out serial port is easy enough. i dont know albert, only seen them recently.
<kingoffrance>
thats too old of a nick not to know what a serial port is :)
kspalaiologos has quit [Quit: Leaving]
iomonad has left #osdev [[1] 28823 segmentation fault (core dumped) weechat]
<klange>
In the general context of computing, I can understand being unaware of serial ports in 2022 since they haven't been included on motherboards in well over a decade, much less actually used by anything, but being even remotely close to OSdev and not knowing what a serial port is... is shocking to me.
<kazinsal>
on top of that, if it's been days and you haven't been able to google what something is this is the wrong field for you
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has joined #osdev
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
vdamewood has quit [Ping timeout: 250 seconds]
vdamewood has joined #osdev
LostFrog has quit [Remote host closed the connection]
PapaFrog has joined #osdev
GeDaMo has joined #osdev
bauen1 has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
Burgundy has joined #osdev
dennis95 has joined #osdev
gog has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
<gog>
µ
<zid>
pls don't call me out like that in public
<gog>
sorry
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
<kingoffrance>
i found an ancient 1994 nawk script to convert a bdf font to a bunch of xbms http://www.ittc.ku.edu/images/AIcons/support/scripts/ unfortunately, it screws up terminus at least :/ luckily, fontforge has scripting https://defuse.ca/b/H8mKjMMDUyT34XAu6wksA4 pw: x i think i have a million things to do before "graphics" but xbm is literally just C code: #define width #define height <array of bytes> lol
<bslsk05>
www.ittc.ku.edu: Index of /images/AIcons/support/scripts
<kingoffrance>
i wonder if you could pre-render ttf or something that way lol
<FatAlbert>
gog i can't here ya
<gog>
i said 'µ'
<klange>
kingoffrance: I have a thing to bake TTF fonts into a C-friendly bitmap format. I used it to produce a version of Deja Vu Sans Mono for kernel debug output.
<klange>
It's also a fallback option for my GUI terminal; it's notably faster than my truetype implementation, so it's good for getting better terminal performance especially in software emulation
<bslsk05>
github.com: toaruos/terminal-font.h at master · klange/toaruos · GitHub
<klange>
I would port it to use my own truetype rasterizer, but I don't currently have a monochrome output mode, and I don't have hinting support, so it would look bad, so it uses freetype ;)
<klange>
For real fun, I used to use binary literals for this stuff, and with a bit of syntax highlighting tweaking... http://dakko.us/~k/vga_font.c.html