<epony>
from the newspeak mellow soft rainbow gender reveal cyanobacteria pop-culture politically correct when it is in the interest of our_own_secret_world_domination_plans_which_everyone_knows_too_but_we_all_pretend_is_conspiracy
<zid>
jimbzy: he needs to turn it after so he doesn't want hard spots, and he's building material up not just joining bits
<jimbzy>
Yeah, I figured as much. I've seen it used for refacing parts.
<zid>
yea it needs an o-ring to seal nicely afterwards
<zid>
and it's gouged to shit
<zid>
so build back up, flush cut back on lathe
terminalpusher has joined #osdev
blockhead has joined #osdev
terminalpusher has quit [Remote host closed the connection]
<klys>
finally bought the 12 gauge extension cable and 1800w psu for my rig. the 1800w ups has been in my rack since december. next up might be a disk or something. started studying blender a bit today.
Ram-Z has joined #osdev
Brnocrist has quit [Ping timeout: 260 seconds]
Brnocrist has joined #osdev
hmmmm has quit [Ping timeout: 265 seconds]
Brnocrist has quit [Ping timeout: 246 seconds]
Brnocrist has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.7.1]
ThinkT510 has joined #osdev
<zid>
klys: now overload it with SSD power draw by collecting pictures of cats
<klys>
well the attached network is not so super. a few days ago i made a w10pro vm just to get itunes.
<klys>
today I made a debian vm to get blender going
<zid>
you can probably buy hdds preloaded with cats
<zid>
you just need to power them
<klys>
cat power
selve has quit [Remote host closed the connection]
selve has joined #osdev
vexmane has joined #osdev
vexmane has quit [Remote host closed the connection]
Brnocrist has quit [Ping timeout: 260 seconds]
theWeaver is now known as HeadBitch
ghostbuster has quit [Ping timeout: 256 seconds]
ghostbuster has joined #osdev
lucartc has joined #osdev
GeDaMo has joined #osdev
<ddevault>
rpi4 online :D
<ddevault>
but why doesn't my exception vector work
<ddevault>
dereference null pointer in qemu => goes to my fault handler
<ddevault>
same thing on rpi4 => hangs
<ddevault>
actually it doesn't hang, it just werks, then it hangs later in the code I wanted to debug via the fault handler
gog has joined #osdev
<zid>
you should debugger your debugger
<Ermine>
Either qemu or rpi4 is broken
<GeDaMo>
Is it possible the fault handler is not saving / restoring something properly and qemu just gets away with it?
<ddevault>
I don't think so
<ddevault>
in any case my fucking serial port is broken again
<ddevault>
so I have to solve bullshit problems before I can solve real problems
<froggey>
there are no real problems, it's bullshit all the way down
<ddevault>
serial ports are the bane of my fucking existence
<ddevault>
remember back when every PC had one and you didn't need a godawful janky USB adapter plugged into random pins on a fucking SoC
<froggey>
make sure your exception vector is properly aligned. I misread the docs and had mine 1k aligned but it needed to be 4k aligned (or something like that), worked fine in qemu but not real hardware
<ddevault>
thanks for the tip, will check that
<Ermine>
tfw my motherboard has serial port but it is basically unreachable
<ddevault>
well, good news is I got it to halt when I dereference a null pointer
<ddevault>
still exception no worky though
[itchyjunk] has joined #osdev
<Ermine>
Btw is step-by-step execution possible on rpi?
<GeDaMo>
Is that something you could do with JTAG?
<Ermine>
Idk. I mean, I would do that in that situation to compare what qemu does and what rpi does
<zid>
I don't know if I have a serial port without doing any soldering
<ddevault>
hunch is that my EL2 => EL1 code is wrong
<zid>
The nuvoton chip has literally everything on it
<ddevault>
maybe I should try to set up vbar in my EL2 bootloader and see if it works to verify this hunch
<zid>
idk if mine is wired up, it's a similar board but mine is micro
* zid
grabs the manual
<zid>
ya no serial, aafp, spdif, power, reset, go, fan2, usb, usb, sata, panel on the bottom of the board
<Ermine>
Who needs spdif stuff I wonder
<zid>
people who want digital audio?
<zid>
no point doing analogue until the final step
<zid>
if you don't have to
<Ermine>
Aren't jacks about digital audio?
<zid>
'jacks about' ?
<Ermine>
3.5mm ports
<zid>
never ever?
<Ermine>
?
<zid>
3.5mm ring connectors have always been used for analogue
<Ermine>
Ah
<zid>
I've never seen anybody put anything digital over it ever, despite the 60 years or whatever they've had the chance to
<zid>
maybe you could count like, loading programs off tape drives?
<Ermine>
Well, isn't digital audio something niche?
<zid>
not if you do audio
<zid>
if you're just a home gamer you'll just plug your headphones into your mobo
<Ermine>
For home analogue seems to be okay. I can listen to music and play games
<zid>
if you just have your PC as part of a complicated audio setup and you have nice digital gear you'd absolutely use the digital output instead
<zid>
a lot of people do digital audio just by virtue of using USB headsets these days though
<zid>
the headphones themselves have a DAC
<Ermine>
So it would make sense to put spdifs in specialized hardware for audio people, but I have it in rather consumer hardware
<zid>
digital is consumer af
<zid>
spdif is from the 80s
<zid>
It's also basically free to provide
<zid>
given it's digital already to begin with at the source
<zid>
the whole bottom left corner of your mobo could be removed if they didn't offer analogue, all spdif removal gets you is the little black header above your aafp header removed
<zid>
(the three pin with 1 pin missing guy)
SGautam has joined #osdev
Turn_Left has joined #osdev
<ddevault>
hrmph
<zid>
ddevault: Remember to add a serial port output after every line of code that spits out a couple of meg of debug info
<zid>
you'll find it eventually
<ddevault>
serial port works
<ddevault>
back to dealing with the other problems
<ddevault>
though I do have one more bullshit problem, but I can ignore it for now
Left_Turn has quit [Ping timeout: 248 seconds]
<zid>
is it that your lighter sucks shit and it's tearing the skin off your finger
<zid>
that's my problem I am ignoring
<ddevault>
no, my lighter is fine
<ddevault>
though it does enable problematic behaviors
<ddevault>
the other bullshit problem is that edk2 does not autoboot my kernel anymore
<ddevault>
have to go to the shell
<ddevault>
bleh
<ddevault>
anyone ever had issues with vbar not working on rpi?
<ddevault>
no good leads yet
<ddevault>
aligned on 4096
<ddevault>
ooh ooh
<ddevault>
can reproduce in qemu if booting from EL2
<zid>
quick, assert(el == 8)
<ddevault>
good call
<gog>
zid: cricket
<gog>
stop buying the cheap chinese ones
<gog>
or bic
<Ermine>
cheap chinese cheese
<ddevault>
okay I am in EL1
<gog>
but also i am no longer smoking
<ddevault>
in any case that's not surprising since I'm using EL1 page tables and it does not blow up too early
<ddevault>
hm
<ddevault>
that seems interesting
<ddevault>
sp is zero
<ddevault>
so double faults all day when it tries to push the CPU state
<zid>
gog: I bought a fucking clipper
<zid>
but CAPITALISM
<gog>
lmao
<zid>
so it ran out of flint in 4 strokes and out of gas in 8 seconds
<zid>
cus you can't SEE that they've been reducing those by 10% every year since 2008
<gog>
bics never run out of flint
<zid>
so you're like "fuck it, clippers are good, I'll pay"
<gog>
they have like 4cm of flint
<gog>
they always have more than half left when the gas is gone
<zid>
I bought a pack of flints after it ran out
<zid>
"fuck it, clipper can change flints easy, I paid for this privledge"
<gog>
can they refill?
<zid>
and then it ran out of gas after 2 strikes on the new flint
<zid>
so now I need more gas
<gog>
if you can refill them then maybe the cost is worth it
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<ddevault>
translation fault! FAR is bogus though
<ddevault>
wonder what causes this
<ddevault>
hrm
<ddevault>
should solve this logging problem first though
<ddevault>
PC alignment fault? wut
[itchyjunk] has joined #osdev
[_] has joined #osdev
[_] has quit [Client Quit]
<ddevault>
jtag would be nice
<zid>
pootag is cheating, find an LED to flash
<ddevault>
well, I can get output from it
<ddevault>
hmm...
<ddevault>
I wonder if my bss is not zeroed
<Ermine>
Is it supposed to be?
<ddevault>
yes
<zid>
it's one of the very few requirements C expects from its environment
<zid>
that static storage duration stuff is zero'd
<ddevault>
yes that was it
<Ermine>
But this is Hare, not C
<ddevault>
hare has the same bss constraint
<ddevault>
wew now we're cooking
<ddevault>
landed on an assertion with // TODO on it
<ddevault>
that's what I like to see
<geist>
ddevault: i'm sure you've figured it out since then, but in general most of those things (like SPSel) are banked by EL
<ddevault>
yeah
<geist>
so when you drop from EL2 to EL1 a bunch of things (like all the bits in PSTATE) you have to re-configure
<ddevault>
aye
<geist>
or configure the EL1 one from EL2 before you drop
<geist>
cool
<ddevault>
thankfully I did get past this point
<geist>
gneeral rules being that in a higher EL you can access banked copies of registers in lower ELs, but not vice versa
<ddevault>
going to have to revisit this once I'm ready to do scheduling
<ddevault>
for now it's Good Enough(TM)
<geist>
:thumbs up:
<geist>
in general the usual thing to do with SPSel is to use the banked version of SP (i forget the polarity of the register)
<ddevault>
ideally I'd like to be able to replicate what I do on x86_64
<geist>
ie, SP = SP_EL1 when in EL1, etc
<ddevault>
which is set the interrupt stack to the current process's context structure
<geist>
the other mode is pretty weird, but useful in very specific situation
<ddevault>
but I suspect I won't be able to do that, we'll see
<ddevault>
well, maybe I can do that
<geist>
yah that's probably not what you want to do. the banked SP is much more useful and flexible than x86-64, you probably want it
<ddevault>
anyway, problem for future me
<ddevault>
oh I'm going to use the banked registers for sure
<geist>
ie, when in user space you can just leave the kernel stack loaded up, and thus dont need any of that TSS nonsense
<ddevault>
unrelated probem
<ddevault>
problem*
<geist>
for anchors you want to look into TPIDR_EL1
<geist>
just a 'free' register you can put whatever you want into
<ddevault>
aye
<ddevault>
single threaded system for now though
<ddevault>
not in scope for the demo I'm working on
<geist>
yah and really TPIDR only really is necessary when doing SMP, because without it you can just anchor the global state in some global register
<ddevault>
or literally in a global
<geist>
er i mean globla variable yes
<ddevault>
SMP is the main "big feature" left for my kernel
<ddevault>
I mean setting aside things like ports
<ddevault>
other remaining tasks are relatively small
<geist>
yeah you'll want to so SMP relatively soon
<geist>
but definitely get interrupts and context switching working first
<ddevault>
yeah preemptive multitasking is already in for x86_64
<ddevault>
just thinking in terms of aarch64 port atm
* geist
nods
<Ermine>
Maybe it's high time to sum up how this stuff works
<ddevault>
on x86_64 the kernel is mature enough that I would soon call it 1.0 if I were a bit stupider than I seem to be
<Ermine>
What about userspace? Or you aren't in business of providing userland besides the testing one?
<ddevault>
I am in the business of providing a userspace
<ddevault>
but almost all of the work so far has gone into the kernel
<ddevault>
userspace development will really kick off once I finish the IPC codegen tooling
<Ermine>
Ah
<geist>
you'll find that arm64 is about as complex as x86-64 but in different ways
<ddevault>
which is what I was working on before I put everything on hold to do this demo
<geist>
it's more straightforward in terms of having less nonsense crap you have to set up Just Because
<geist>
but then it's also in a lot of ways much more complex and powerful and subtle
<ddevault>
yes, I have found that arm64 is just as much of a nightmare as anything else
<geist>
so also easy to screw up
<ddevault>
my browser can only open the manual if my computer has had its coffee that morning
<geist>
once you grok it it's kinda pleasant to work with, but in the way that driving a high performance car that's finiky and wants to kill you is more fun
<ddevault>
tbh though kernel hacking is a problem like any other
<Ermine>
Now I want to ask heat if he still thinks aarch64 is good, but he isn't here
<geist>
or another metaphor is x86 is more like driving a powerful Harley motorcycle that leaks oil but just sort of powers through it
<ddevault>
work on it iteratively and persistently and eventually it works
<geist>
vs more of a ducati crotch rocket
<geist>
and riscv is like one of those little scooters with a 5hp briggs and stratton motor you have to start with a pull cord
<gog>
yes
<gog>
i want that
<geist>
but requires zero training
<ddevault>
I'm doing riscv64 next
<ddevault>
looking forward to it
<geist>
yeah its refreshingly simple
<gog>
me too
<zid>
can't let those casio watch devs get too confused
<ddevault>
want pizza
<ddevault>
erp, wrong buffer
<ddevault>
still: want pizza
<zid>
oh man a pizza would be unreal rn
<ddevault>
screen, picocom, and minicom are all annoying
<ddevault>
what's the least shitty way to plug my terminal into a serial port
<Ermine>
write your own I guess
<ddevault>
saw that one coming
<Ermine>
If you don't mind GUI apparently PuTTY is ported to linux. Not that this is perfect though...
<ddevault>
hard pass
<Ermine>
as you wish
<ddevault>
it can't be that hard to implement it myself
<ddevault>
open the file, use termios to set baud rate et al, plug into stdin/stdout
<geist>
are yo on linux? i usually do screen
<geist>
though depends on exactly wat you mean terminal i guess
<ddevault>
yeah I'm on linux
<ddevault>
I'm using screen now
<ddevault>
maybe I'll get fed up enough to write my own, we'll see
<geist>
yeah either that or minicom
<Ermine>
Maybe it's worth it to write something refreshingly simple and get some dopamine for working on something harder
<ddevault>
I'll probably end up spending a couple of hours on it and if it ends up being more work than that, set it aside until the demo is done
<ddevault>
have to flesh out termios support for hare first
<geist>
yah it's quite simple to just use ttyios to open the serial port, turn off all cooking, and pass it directly through
<ddevault>
I foresee a minor annoyance in that I'll have to use nonblocking I/O to handle both directions
<Ermine>
I was at sysadmin competition some time ago and I failed to figure out which tty out of /dev/tty* I should use to get to cisco switch through serial line. What a shame.
<ddevault>
I hope you learned your lesson
<ddevault>
which is that there are better things to do than enter sysadmin competitions
<Ermine>
Yeah, but it was fun to me back then
<Ermine>
Also fuck dlink for not soldering serial line pins to their router's PCB
<zid>
I'd like one of those logic analyzer bulldog clip things
<zid>
whole pack of theese in diff sizes'd be cool
SGautam has quit [Quit: Connection closed for inactivity]
<geist>
This is a case where the systems/etc whatever named dev nodes in modern linux distros is great
<geist>
Ie, /dev/serial/by-uuid., etc
<geist>
Great when you have a pile of usb serial ports that can show up in any order
<geist>
For raw disk access i use this almost exclusively so i dont accidentally the wrong drive
<ddevault>
I do dmesg | tail after hotplugging a disk of some kind
unimplemented has quit [Read error: Connection reset by peer]
<Ermine>
uuid stuff annoys me. So windowsy. However, it seems to be useful for identifying partitions
unimplemented has joined #osdev
<gog>
no no microsoft has GLOBALLY unique ID's
<gog>
the non-MS world are UNIVERSALLY unique
<gog>
:)
jafarlihi has joined #osdev
<jafarlihi>
How hard would it be to add SMP support to OpenBSD's vmm and get it to perform as well as KVM? Is there work being done on it?
unimplemented has quit [Read error: Connection reset by peer]
<gog>
openbsd has smp
<jafarlihi>
gog I mean for vmm
<gog>
oh ok i see
<gog>
kernel mode is still single threaded
<gog>
uhhh
<gog>
probably pretty hard
<gog>
there's a lot of moving parts and action at a distance in kernel land
<gog>
and then you run into the problem of big locks where you prevent other threads from being scheduled on any cpu while a kernel thread is in a critical section
<gog>
or small locks where you need to find every spot where concurrent data access is a problem
<gog>
but you also have shorter critical sections
<jafarlihi>
Does kernel have to be multi-threaded before vmm can be made multi-threaded for guest OSes?
<gog>
i don't know enough about that
<gog>
most likely
<jafarlihi>
Is there any book or anything I can read if I want to contribute to vmm?
<gog>
i don't know
<jafarlihi>
OpenBSD would be perfect host OS as daily driver, just do development in Linux VM, but vmm performance sucks
<gog>
why not host on linux?
<jafarlihi>
Security concerns
<gog>
develop on an airgapped system
<jafarlihi>
Not practical
<gog>
is it more practical to develop on openbsd?
<jafarlihi>
I already have host Linux where I don't install shit but develop in VMs where I install shit
<gog>
with its performance constraints
<jafarlihi>
Well, if it was better performer and vmm supported smp then it would be perfect
<gog>
you'll need to weigh the practical considerations against the security considerations
<gog>
if you're that paranoid but performance is a problem then an airgapped linux system is your option
<gog>
it sounds less practical to work on openbsd to improve its vmm
<gog>
and introducing unknown security concerns
<gog>
inadvertently
unimplemented has joined #osdev
unimplemented has quit [Read error: Connection reset by peer]
<ddevault>
then the serial device is defined at reg = <0x7e201000 0x200>;
<ddevault>
I happen to know that the real address is 0xfe201000
<ddevault>
but... uh
<ddevault>
I am assuming by my reading of the device tree spec that I determine if a translation range applies by testing if min-child <= addr < max-child
<ddevault>
in which case I subtract the child address and add the parent address
<qookie>
you're missing the size here? each entry of ranges is <child-base parent-base size>, perhaps you're misparsing it?
<qookie>
for one of the two addresses (idr which) you use the #address-cells value of the parent and for the other one you use the #address-cells of the current node
<ddevault>
addr cells and size cells are both 1, though
<qookie>
both on soc and on parent of soc?
<ddevault>
oh wait the /parents/ addr-cells/size-cells applies
<ddevault>
not the node's
<ddevault>
that makes sense, thanks!
<qookie>
both apply, one for the child-base, one for the parent-base
<qookie>
also as a side note i recommend getting acquainted with Documentation/devicetree/bindings in the linux source tree, since that's where all the device-specific properties are described
<ddevault>
yeah, been there
<ddevault>
not particularly well organized but hey
<qookie>
better than having to look at the driver code that parses the properties :^)
<ddevault>
in theory, yes!
<ddevault>
in practice, the docs suck
<ddevault>
so you'll read the code anyway
<qookie>
although they aren't always grep-able since some files use a regex pattern to describe the "compatible" values
<ddevault>
and it's not like the devices themselves ever have vendor docs, so if you want to know how they work... back to the linux code
<qookie>
yeah that's also true
<qookie>
and quite unfortunate
<ddevault>
agreed.
<ddevault>
well
<ddevault>
at least it's better than ACPI
vexmane has joined #osdev
<ddevault>
most recursion heavy code in my kernel is probably not printf, but the FDT prober
vexmane has quit [Client Quit]
vexmane has joined #osdev
terminalpusher has joined #osdev
<ddevault>
\o/
<ddevault>
rpi4 now gets as far as qemu
<ddevault>
/without/ an SoC-specific build, same kernel binary as qemu
<ddevault>
err, I say that, but now qemu doesn't boot
<ddevault>
broke it somewhere along the way I guess
<qookie>
nice
<qookie>
managarm is in a similar position, except there's separate prekernels for virt and rpi4 (mainly due to the base addresses since i haven't bothered with pic/pie yet)
<qookie>
and on my fork i also have a prekernel for exynos 7870 :^)
<ddevault>
well, qemu is a problem for tomorrow me
<gog>
i have pic working
<gog>
well, it runs, who can say whether all of my relocations are always going to be right
hmmmm has joined #osdev
ramsay90 has joined #osdev
k0valski18891 has quit [Read error: Connection reset by peer]
k0valski18891 has joined #osdev
* vdamewood
relocates a fishy to gog
<vdamewood>
hmm... PIF position-independent fishy
dude12312414 has joined #osdev
* gog
memmove(fishy, gog->mouth, fishy_size);
<gog>
wait no
<gog>
gog->mouth, fishy
<gog>
i never get that right
dude12312414 has quit [Remote host closed the connection]
<mjg>
do these overlap? :O
<mjg>
as the name suggests, move does not actually *move*
heat has joined #osdev
<dh`>
all the standard functions are the same order as assignment (memcpy, memmove, strcpy, etc.)
<heat>
ddevault, do you want me to ruin your day?
<dh`>
the legacy ones are the same as cp(1): bcopy, copyin/out
<ddevault>
uh
<ddevault>
no?
<heat>
the ranges property doesn't have the same format across the device tree
<ddevault>
you're right
<ddevault>
you have ruined my day
<heat>
as in, it's not always address : size
<heat>
an easy example is the pci nodes
<ddevault>
it's not always (addr, addr, size)...?
<qookie>
pci is still child parent size, the child just has an address-size=3
<ddevault>
re-reading the device tree spec and it does not look like this is the case
<ddevault>
unless there is behavior outside of the spec in the wild
<heat>
where it's #address-cells=3 and the actual format is "random pci-specific-data, address, size"
<ddevault>
erph
<ddevault>
I see
<ddevault>
well, it could be worse
<qookie>
the child address is a 64-bit addr + 32 bits of pci goop
<heat>
yes, and that's nuts
<ddevault>
don't need to deal with that right now
<ddevault>
none of my targets are affected by it
<qookie>
rpi4 has pcie
<qookie>
and xhci behind pci
<heat>
my original idea was to go down the device tree and generically decode ranges myself
<ddevault>
ah, so it does
* ddevault
shrugs
<ddevault>
still, don't need a PCI driver for this device right now
<heat>
can't happen because pci will burn and crash
<qookie>
heat: the managarm code does that, but only if the nod that contains ranges is compatible with "simple-bus"
<qookie>
node*
<heat>
and is that the case? what if that isn't the case, bus-specific decode?
<qookie>
er, it decodes them always (it has an extra fields for the upper 32 bits of a 96 bit child addr), but it translates the addresses of children automatically if it's compatible with "simple-bus"
<ddevault>
that seems like a reasonable solution
* heat
nods
<vdamewood>
salt water is also a reasonable solution.
<qookie>
so far it has not fallen apart but i only tested on qemu virt, rpi4 and exynos7870 :^)
xenos1984 has quit [Ping timeout: 246 seconds]
<heat>
<jafarlihi> OpenBSD would be perfect host OS as daily driver
<heat>
mjg, found theo
<mjg>
lemme share an anecdote real kuik
<mjg>
a friend of mine, who happened to be a freebsd developer at some point, was attending a bsd conf
<mjg>
on a bus to the venue some dude approached him and said +/- "i'm an openbsd user, so i wont greet you"
<mjg>
:d
<mjg>
it was NOT theo
<qookie>
lmao
<heat>
hahahahaha
<heat>
openbsd would be the perfect host OS under a hypervisor
<heat>
a single openbsd instance per CPU
<heat>
who says no?
<mjg>
there is someone who did it
<mjg>
except the hypervisor is also openbsd :d
<heat>
ddevault, how are you getting around acpi?
<heat>
do you load your device tree manually?
xenos1984 has joined #osdev
<ddevault>
right now I'm loading it manually
<ddevault>
but there's a flag in edk2 to make it pass a device tree over EFI that I intend to set up at some point
<ddevault>
had it working as a proof of concept with RISC-V via u-boot EFI a while back
<heat>
a flag in the platform config?
<ddevault>
nah, runtime flag
<ddevault>
you can toggle it in the boot manager
<heat>
hm, can you toggle it in boot services?
<ddevault>
not sure, doubt it
<ddevault>
it's controlled by an EFI variable iirc
<ddevault>
so runtime services probably
<qookie>
solution: use the linux boot proto instead of efi /s
<ddevault>
no thanks
<ddevault>
did consider it when I was at my lowest point in trying to prepare an EFI stub though :P
<heat>
why the /s?
<heat>
it's literally the sanest idea
<heat>
EFI is only good for booting windows
<heat>
you're able to discard around 8MB of compressed code and data for the loss of... absolutely nothing
<ddevault>
I just want a standard man
<heat>
the linux boot protocol is the defacto standard
<heat>
which you will need to use for riscv64 because the EFI support for that is still very alpha
<heat>
it's not like this is some kind of x86 linux boot protocol thing where everything is bad and old and horrible with many many fields
<ddevault>
also
<ddevault>
I need to load shit from the filesystem during boot
epony has quit [Quit: QUIT]
<heat>
what shit?
<ddevault>
boot modules, ala multiboot
<ddevault>
at least two files
<heat>
the linux bootloaders can just load your initrd if that's what you need, the address even gets tucked away in the device tree
<ddevault>
>two files
<ddevault>
yes I can cat them together
<ddevault>
no I won't
<heat>
is there a difference between two files and a cpio/tar? :v
<ddevault>
well the first file needs to be an ELF executable
<ddevault>
I could cram the second file into an object and stuff it into the executable
<ddevault>
but I will not
<heat>
you could also just use cpio or tar
<ddevault>
or I could not do that
<ddevault>
I don't want a cpio or tar parser in my kernel
<heat>
ok
<ddevault>
nor do I want my "prepare an initramfs" process to involve a linker
<heat>
but you will need to fwiw
<ddevault>
why?
<heat>
because edk2 riscv support is still very early on and in-progress
<ddevault>
nah
<heat>
yah
<ddevault>
I have played with u-boot UEFI on risc-v and it was sufficient for my needs
<ddevault>
dunno about edk2 but w/e
<ddevault>
I got a working setup
<ddevault>
in any case I can just work on the EFI implementation if need be
<heat>
>work on the EFI implementation
<heat>
ohno!
<ddevault>
I've seen scarier domains
<ddevault>
life is a series of problems, solve one after another and you eventually run out
<ddevault>
or die
<heat>
have you?
<ddevault>
but hey!
<ddevault>
no, but the list keeps shrinking
unimplemented has quit [Read error: Connection reset by peer]
<heat>
i've seen MADT cpu sorting code that called sort() multiple times instead of, erm, calling sort once with a proper compare function
<heat>
that code was also subsequently patched to not sort CPUs, and then to sort cpus with a different criteria
<heat>
why? who knows, the commit message was something like "We must sort CPUs according to X" with no further explanation of the problem
<heat>
i pressed to know why and then the patch stalled and AFAIK never got pushed
<ddevault>
this one time I saw a lepoard
<dh`>
99 problems of code on the wall / 99 problems of code / take one down, pass it around ...
<heat>
maaaaaaaaaaaaaaaa, they're overengineering riscv again
<ddevault>
there's a special place in hell for people who make flowcharts
<heat>
the UEFI standards body?
<ddevault>
in any case yes they are fucking up our boy
<qookie>
[21:28:29] <heat> why the /s?
<qookie>
well the linux boot proto is at least somewhat being replaced with uefi due to the arm systemready specs, although if one believes that soc/sbc manufacturers are going to actually follow them is another thing
<ddevault>
ACPI is coming
<ddevault>
my solution to soc vendors not doing the right thing is to not give a shit about their soc
<heat>
qookie, i know, they're destroying fucking booting
<ddevault>
booting has not been good for like 40 years
<heat>
arm's was simple at least
<ddevault>
arm was a fucking nightmare
<heat>
now it's overengineered as nuts
<heat>
EFI firmware sizes are fucking nuts
<ddevault>
I'd rather have too much than literally nothing
<qookie>
well at least now we (hopefully, fingers crossed) have a consistenet way of configuring booting though
<heat>
they're literally 8MB COMPRESSED
<ddevault>
custom kernel build and a custom bootloader for every SoC!@!
<heat>
COM FUCKING PRESSED
<heat>
the code quality is at best dubious
<qookie>
ddevault: linux boot proto didn't require that
<ddevault>
which kernel? fuck you! here's a fork of linux 2.7 with a bunch of garbage in it
<qookie>
i don't think efi is going to make manufacturers stop maintaining downstream forks instead of upstreaming
<ddevault>
well at least there's a standard and I can mail them nasty letters about all of the ways they don't implement it
<heat>
things you do not need for arm64 and riscv: the EFI PI spec, the EFI spec, ACPI
<ddevault>
instead of just doing my very best to stay as far away from arm as possible
<heat>
in fact, their ACPI isn't even real
<heat>
it's just a shitty platform description bytecode
<ddevault>
whenever some new "hacker" hardware comes out
<heat>
the actual do-magic-stuff bits don't do any! because they're "reduced platforms" in the ACPI sense
<ddevault>
grep for ARM
<ddevault>
close tab
<heat>
i can confidently tell you that nobody needs this shit except windows
<qookie>
acpi is a double edged sword for me, it's nice that you don't need drivers for every chipset imaginable to shutdown, but then the fact you need a whole bytecode interpreter (where the real world follows what windows/acpica implements and not the spec) is a pain as well
<heat>
shutdown is not a hard thing to standardize on
<qookie>
that's true
<heat>
you know how shutdown works in literally all of Intel's chipsets? outb(CHIPSET_PORT (0xcf9 right?), SHUTDOWN_VAL)
<heat>
where both of these values have been stable for the past 20 YEARS at least
<qookie>
although i think acpi has a few more things standardized, or at least thermal stuff
<ddevault>
what we need is to place a bomb in every vendor's factory
<qookie>
as in reading the sensor temps if they're exposeed via aml
<heat>
qookie, yes, and they could've just standardized on some interface
<ddevault>
which triggers automatically when they design something vendor-specific which could have been a standard
<heat>
as would be done in a sane world
<qookie>
that's also true yeah
<qookie>
sadly neither microsoft or vendors are
<heat>
ACPI turned out to be an SMI fest
<heat>
where you call a method and boom, now you're in SMI land doing who knows what
<heat>
this sucks so hard microsoft had to create ANOTHER STANDARD for reducing SMI usage
<heat>
and let me be 100% clear, SMM is also 3000000% nuts
<qookie>
oh yeah i'm not denying that
<heat>
interrupts disabled and serializes the whole system
<heat>
I would love to see how a 128-thread chip enters SMM
terminalpusher has quit [Remote host closed the connection]
<heat>
this kind of shitty ACPI and EFI world is what was made the fuck up to solve the "how do we blackbox our IP" thing
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
terminalpusher has joined #osdev
<heat>
ARM and riscv64 have historically not needed this
<heat>
will they start having shitty IP blackboxes now? or is this all for nothing?
<ddevault>
aaaaand my FOSDEM submission was rejected without explanation
<ddevault>
guess I can stop working on all of the shit I've been doing for the past 6 weeks
<heat>
:((
<qookie>
idea: just bring a projector and set it up in a hallway and start talking
SGautam has quit [Quit: Connection closed for inactivity]
<zid>
In the days of spinning disks it was important to run a defragmenter to reduce latency spikes in the middle of reading files
<zid>
Modern flash memory wear leveling means we now run files through a refragmenter
air has joined #osdev
* vdamewood
frgments
* vdamewood
fragments
MiningMarsh has joined #osdev
dutch has quit [Quit: WeeChat 3.7.1]
<amj>
ddevault: you makes me feel guilty, a year I didn't even sent a email to the people we rejected :(
epony has joined #osdev
<Ermine>
At least you habe now enough experience to tell the tale of bringing up aarch64 system I guess
<geist>
yay seemed like only last year i was the only one trying to get people to do !x86
<geist>
(though really it was about 10 years ago. i think mrvn was the first person still here that was pro-arm)
<geist>
i remember even arguing with someone here about how portability was good, etc. they were of of the opinion that it was all a waste of time, etc
vexmane has quit [Quit: bye bye]
<epony>
portability is paramount
[itchyjunk] has quit [Remote host closed the connection]
<epony>
and then comes standardisation on some layer
[itchyjunk] has joined #osdev
<epony>
that's the power of C, machine independent machine specific programming
<Ermine>
geist: ARM got more traction over the years. I think that introduction ARM machines boosted that process.
<geist>
yep
<epony>
we call that Berkeley RISC
<geist>
but also the availabilty to Regular People of actual interesting ARM machines to run their hobby os on
<ddevault>
amj: I didn't get an email, I just logged into penta and it says rejected
<epony>
and it's been with the commerce and idustrial controllers programming all along
<geist>
10 years ago or so it was more like 'yeah but i dont have one except this smartphone i can't do anything with'
<epony>
the "affordable" RISC has been a long term goal with many, and it's part of the CISC internals too
<geist>
ARM has of course been important for a long time, it was more that it wasn't really in the wheelhouse of the average hobby osdevers
blockhead has left #osdev [#osdev]
<epony>
it's been a falsely sustained artificial high pricing on RISC
<epony>
the fabless model and the restructuring of the semiconductor industry in the 80ies and 90ies results in more freeform processor design competitive entries
<Ermine>
s/introduction ARM/introduction of Apple ARM/
<epony>
RISC is from the early 80ies but the designs are theoretic from the earlier machine specification attempts Knuth et all
<epony>
it's not very "RISC" when it's realised though, so mostly the register-register and shorter width instructions and more non-specific registers are characteristic (and smaller use of instruction opcodes as an intended design)
<geist>
i think of it as a continuum (much like microkernels). you get to pick from a selection of 'risc-like' or 'cisc-like' features and based on what you pick you land somewhere between 1 and 10
<geist>
that sometimes upsets folks that like to put things in clear bins but so it goes. the real world is messy
<epony>
the trouble with the System on Chip designs is their complexity and incompatible realisations between models and implementers which leaves mostly the machine unprogrammed fully except in reference implementation from the designer-programmer studio company
ramsay90 has quit [Quit: Client closed]
unimplemented has quit [Read error: Connection reset by peer]
<Ermine>
ARM boot process needs unification. That would bring closer the day when we can declare x86 obsolete
<geist>
yes but it's faaaaar better than it was before
<epony>
that's where it should be in the programming model.. a selection of feature sets, eventually realised in families of processors that are providing programming interfaces for both models
<geist>
just the introduction of PSCI really helped immensely
<geist>
it's still a few choices but the boot situation on ARM is more like one of 2 or 3 open solutions
<geist>
and a couple closed ones
<geist>
vs 100% everything is propretary and bespoke
<Ermine>
That's way better
air has quit [Ping timeout: 272 seconds]
<epony>
it is not better if the product is very short lived as huge investments are used in the programming so the native and full SoC programming remains unachievable for independent software developers most of the time on fast paced "non-platforms" but "product bundles"
<epony>
it's for the goals and objectives of the embedded appliances and consumer electronics and microcontrollers that these proprietary designs find their realisation, previously in the extremely overpriced RISC workstations that got displaced by much more affordable lower priced and mass produced CISC in personal computers (more universal computing designs)
<epony>
it's a specialisation and efficiency model of microprocessor and microcontroller and application specific and generally programmable integrated circuits that produce these different "implementation" conventions / families
<epony>
it's just become more mass produced for the mobile market and accessible for consumer and software development kits too, not a major replacement or conversion of the computing principles ;-)
spikeheron has joined #osdev
<epony>
the need for high performance and efficient machines of all form factors and classes is still there
<epony>
imrpovement in the design and programming of smaller classes can improve (and should) the larger middle class machines too
<epony>
supercomputers are an interesting class too, if their designs can be brought in size to the middle classes of machines
<epony>
that's the directions thngs are moving in, from large into smaller machines, with miniaturisation and efficiency / optimisation on each iteration / generation
<epony>
it's very interesting that small form factor machines have now advanced capabilities comparable to the middle class and larger higher energetic machinery
<epony>
obviously advances in their designs get propagated to portable and stationary business computing too
air has joined #osdev
<epony>
they are not very different as semiconductor technology, just their organisation and fabrication process is more specialised to the needs of integration and consumer bundling sectors
<epony>
better programming aims to bring the capabilities and functionally modular-composable machine properties from the larger machines into the system-on-chip variants too, for now it's mostly as small appliances, not yet the modular and interchangeable apparatuses to replace the middle class machines but if that improves the applications, it's a net improvement in general (so portability is paramount)
<epony>
the negative results are from non-open and portable backend infrastructure that small computing classes need to support their competitive operation (with the larger machines)
<epony>
on compiler toolkits and programming it is accessible, on self-hosted compilation the machinery is too small / needs specialised development kits or retargetting on a larger machine, for aplications.. most of them rely on the backend server farms which is non-portable and non-open
<epony>
for educational and hobby and research projects they are quite fine, but limited in performance and programming their proprietary and fast changing specifics
<epony>
so they are much more elaborate modern microprocessor-bundling achievements and use the latest processes and most advanced lithography, but in net result are comparable ot the reduced capability of the first portable/personal computers (the 8bit PCs anew)
<epony>
mostly the result of the battery operation and thermal design and still "large feature" sizes for that compact device form factor
<epony>
it's probably a good 20-30 years ahead for that to improve, and it's possible, the feature sizes of semiconductors are going to shrink 10-100 fold more and these machines will improve in both accessiblity / programming and also capability or at least thermal and energetic for a more continuous operation
<epony>
but the middle class and large class machines are not going to stand still too ;-)
<epony>
the fabless model allows more competition, it's a real shame to have only one proprietary technology design reused by all competitors, standards are needed and multiple sources
<epony>
negative reactions to semiconductors adoption in consumer appliances is not realistic, it's very important and happening (already happened in televisions in the 80ies and early 90ies with reuse of specialised and general chip-compuers), same happened with modems and other consumer electronics, and networking appliances are the primary candidates for more and better semiconductors
<epony>
so these designs are really oriented towards microcontrollers and network class machine nodes
<epony>
entry level computing and portable and wearable is their real specialty
<epony>
better programming is an important achievement
<epony>
we're in the epoch of always on networking and collaborative computing due to advancements in communications use of computerised elecrtonics, that is the small computers becoming microcontroller and microprocessors in modems and network infrastructure
<epony>
when these achieve the capabilities of the modern smart-phones, we're all advancing our portability and networking (and energy utilisaion / efficiency of computing)
Turn_Left has joined #osdev
<epony>
when their improved efficiency propagate to the middle class machines we're achieving localised and independent computing as the infrastructure for the roaming appliances
Left_Turn has quit [Ping timeout: 265 seconds]
<epony>
it's entirely feasible and possible even today (and for the last 2 decades since the 64bit epoch, when microntrollers raised their capabilities with minaturisation and more logic gates in them comparable to the middle class machines) that our devices which we perceive as storage and networking and memory units in the computer, are computers on their own with their internal operating systems, much alike the system-on-chip appliances
<epony>
so, we can even begin having software defined networking and storage and.. memory architectures propagating to the middle class machines
<epony>
that's advancements from the large supercomputer brought in the middle class with componentry from the small class machines
<epony>
it's going to be much fun programming and achieving heterogenous systems designs with on processor service oriented applications
<epony>
that's why it's important to get more open, standardised and competitive programming and portability for applications and their organisation
<epony>
programming and networking models success on the middle class bring utility to the small class machines, their designs need to be improved so they are portable and standardised and their utility can be retrofitted in middle class machines as well
<epony>
the important application for efficient and highly integrated systems is in application specific extensions to general programmability machines, so their extensions modules need general programmability too
<bslsk05>
en.wikipedia.org: Reconfigurable computing - Wikipedia
<epony>
the middle class machines need these so they can be the next class of machines on which to service and facilitate the small class machines in local affinity much more evenly distributed (thus achieving reliability) edge and uniform computing
<heat>
Ermine, why do you need a unified boot process?