klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
<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
gog has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<heat> you could write into vdso .text :D
<heat> vdso_entry: mov $0x90, syscallret; syscall; syscallret: mov $0xCC, syscallret; ret
<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> the first read fails, secod one succeeds
<geist> this is maybe why most folks dont see it. it's guessing that anything within first 4K is really a null pointer
<geist> i was seeing it explicitly because the firmware on the 68k board leaves a data structure at 0x400 that i was reading some bits out of
<geist> so *thatS* probably wy the linux kernel still builds with this (presumably)
<geist> it's more so than just dereffing a raw pointer
<mrvn> Yeah, it's a odd little thing that everything below 0x400 is kernel mode only.
<mrvn> writable
<geist> well nothing a #pragma can't solve
<mrvn> would be nicer if one could attach that to the pointer itself.
<mrvn> why isn't clang using #-1[r1] to load r0?
gog has quit [Ping timeout: 248 seconds]
<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
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
<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?
<bslsk05> ​bootstrappable.org: Bootstrappable builds
srjek has joined #osdev
<mrvn> linux works fine to run gcc
<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.
<oriansj> and we do have a path from hex to Linux+GCC+Guile https://github.com/fosslinux/live-bootstrap without only the kernel being the problem
<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
<mrvn> have you looked at lk?
darkstardevx has joined #osdev
<oriansj> mrvn: did you mean this: https://github.com/littlekernel/lk ?
<bslsk05> ​littlekernel/lk - LK embedded kernel (521 forks/2589 stargazers/NOASSERTION)
<mrvn> yes
<oriansj> honestly never heard of it before but I am looking at it now. Can it run tcc or gcc?
<mrvn> ask geist
<clever> oriansj: i believe out of the box, it lacks a userland and modules, but there is a proof of concept userland
<oriansj> clever: I don't need any userland at all
<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
<oriansj> which is why I am here now
<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 )
* kingoffrance .oO( looking at bdf fonts, i found this gem: https://www.tomsarazac.com/tom/Fun/nethack.html )
<bslsk05> ​www.tomsarazac.com: Big X11 Nethack Font
Likorn has quit [Quit: WeeChat 3.4.1]
<FatAlbert> lol what is that site
CYKS has joined #osdev
<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
<kazinsal> bradd: I managed to add one of these to my cart and it didn't tell me it was a preorder: https://www.canakit.com/raspberry-pi-400.html
<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
<bslsk05> ​defuse.ca: Defuse Security's Encrypted Pastebin
* kingoffrance runs away
kspalaiologos has joined #osdev
<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
puck has quit [Excess Flood]
puck has joined #osdev
<klange> kingoffrance: for qemu, the E9 device will return a readback value (which is 0xe9 by default), but I think it could be patched to use `qemu_chr_fe_read_all` on the same thing it writes to instead... https://gitlab.com/qemu-project/qemu/-/blob/master/hw/char/debugcon.c#L78
<bslsk05> ​gitlab.com: hw/char/debugcon.c · master · QEMU / QEMU · GitLab
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
<bslsk05> ​defuse.ca: Defuse Security's Encrypted Pastebin
<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> ​gist.github.com: bake.c · GitHub
<klange> Output (with added DejaVu/Bitstream license text): https://github.com/klange/toaruos/blob/master/apps/terminal-font.h
<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 ;)
<kingoffrance> BDF actually looks plaintext-ish too...
<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
<bslsk05> ​dakko.us: ~/osdev/kernel/core/vga_font.c.html
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<zid> yea that's cute
<zid> unifont uses a macro instead
<zid> 256 macros, infact
nyah has joined #osdev
gog has quit [Ping timeout: 260 seconds]
the_lanetly_052_ has joined #osdev
sonny has joined #osdev
Brnocrist has quit [Ping timeout: 246 seconds]
Ali_A has joined #osdev
wand_ has quit [Remote host closed the connection]
wand has joined #osdev
milesrout has quit [Remote host closed the connection]
patwid has quit [Remote host closed the connection]
sm2n has quit [Remote host closed the connection]
tom5760 has quit [Remote host closed the connection]
exec64 has quit [Remote host closed the connection]
jleightcap has quit [Remote host closed the connection]
gjnoonan has quit [Remote host closed the connection]
arcadewise has quit [Remote host closed the connection]
ddevault has quit [Remote host closed the connection]
arcadewise has joined #osdev
tom5760 has joined #osdev
ddevault has joined #osdev
exec64 has joined #osdev
milesrout has joined #osdev
sm2n has joined #osdev
gjnoonan has joined #osdev
jleightcap has joined #osdev
patwid has joined #osdev
srjek has joined #osdev
FatAlbert has quit [Ping timeout: 246 seconds]
wand has quit [Remote host closed the connection]
gildasio has quit [Remote host closed the connection]
wand has joined #osdev
gildasio has joined #osdev
FatAlbert has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
Ali_A has quit [Quit: Connection closed]
dude12312414 has joined #osdev
Likorn has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
dennis95 has quit [Quit: Leaving]
mahmutov has joined #osdev
srjek has joined #osdev
sonny has quit [Quit: Client closed]
gog has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
elastic_dog has quit [Ping timeout: 248 seconds]
sonny has joined #osdev
elastic_dog has joined #osdev
heat has joined #osdev
terminalpusher has joined #osdev
terminalpusher has quit [Remote host closed the connection]
Brnocrist has joined #osdev
Mutabah has quit [Ping timeout: 248 seconds]
Mutabah has joined #osdev
<bslsk05> ​www.theregister.com: OpenVMS 9.2 hits production status for x86-64 • The Register
<gog> o:
Mutabah has quit [Ping timeout: 276 seconds]
Mutabah has joined #osdev
<dminuoso> geist: Speaking of "pulling out and running as server", the framework laptop mainboard is a prime candidate for that!
<dminuoso> That thing is a marvellous piece of engineering.
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
wand has quit [Ping timeout: 240 seconds]
FatAlbert has left #osdev [WeeChat 3.5]
heat has quit [Remote host closed the connection]
heat has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
bxh7 has quit [Quit: ZNC 1.8.2 - https://znc.in]
wand has joined #osdev
psykose has quit [Remote host closed the connection]
psykose has joined #osdev
<geist> yah never actually looked at one of those
<geist> CompanionCube: oh neat
<geist> i wonder if can get a hobbyist/etc license for that
<geist> looks like at least for that release it's company only, need to have an existing relationship, etc
hodbogi_ has joined #osdev
hodbogi_ is now known as FatalNIX
dennisschagt has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
dennisschagt has joined #osdev
<heat> openvms doesn't sound too open does it
srjek has joined #osdev
<geist> it was named open back in an earlier era of what open means
<geist> i think in the 80s that meant 'can interoperate with other things'
<geist> or something like that
bauen1 has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
netbsduser` has joined #osdev
netbsduser has quit [Ping timeout: 240 seconds]
<jimbzy> Yay. I was finally assigned a call sign.
<zid> "GenericCallsign7"
<jimbzy> Just "1"
<geist> you are number 1 to us
<mrvn> mrvn to 1, mrvn to 1, comcheck, over
<heat> that does not sound cool
<heat> you should've asked for something like alpha bravo delta
<heat> way cooler
<jimbzy> Whiskey Tango Foxtrot
<mrvn> are there even still 3 letter callsigns left?
<jimbzy> I've seen 4 char, but never any 3 char ones.
<heat> find the 3 letter callsign you want, find out who has it, murder them, profit
<jimbzy> I'm too lazy to murder anyone...
sonny has quit [Remote host closed the connection]
<mjg> Charlie Romeo Alfa Papa
<jimbzy> I also received my EEPROM reader and logic analyzer. Unfortunately, I don't have time to mess with any of that stuff at the moment.
<jimbzy> Soon...
<mjg> (tm)
nyah has quit [Ping timeout: 240 seconds]
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
Burgundy has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist> oh one of the little white uh T668 or whatnot?
<geist> i should find mine, have it somewhere
<geist> haven't tried recent software with it
<jimbzy> Yeah, TL866 Plus