#shkwve: an incomplete kernel/maybe bootloader/UEFI thing/maybe something else if i get bored again
1 messages Ā· Page 3 of 1
and it decodes shit
even though im a bootloader and so it would be totally fine for me to use the boot protocol 
i should use arbitrary self types more
yeah exactly
so usb isnt as hard as people say?
well I guess HID is probs the easiest
define "not as hard as people say"
it took me quite a while, and my usb stack is horrible
"stack"
and i think theres a race in there
idk I feel like when I hear xhci people make it out to be like impossible
and it also took me a while
yeah no its not that bad
its not like a gpu driver or anything
if u just make a hardcoded stack without layers of abstraction or it being asynchrounous its just structs on top of structs and stuff
so not that hard
mine is mostly async
theres like one place where im missing async and thats it
nice
its my slowest driver
in terms of time
lol
i think so at least?
and its still not finished, i need to restructure some logic around to support echi/ochi/uhci and shit
and i want to support dual-role dwc3
also i think im missing an intel quirk that fusl has
yeah thats kinda not that easy because xhci abstracts a lot of stuff away
like address allocation
etc
nah the big one is that i need to move driver assignment out of xhci
address alloc is also a thing
but thats gonna be new code and not code i already have written
im also missing route string shit for superspeed hubs
and hub logic in general
and also it wont work on any real hw because i dont allocate scratch buffers
oh yeah hub stuff is like the most complex part
and real hw is usually hubs on top of hubs even for native ports
especially like PCs
i think my m1 has the two usb3 ports directly attached?
because lsusb shows nothing
or the rpi4 usb2 ports :^)
I know managarm still doesnt work with my pc because it has stuff behind hubs
also e.g. my laptops touchscreen is behind a fake hub i think
i see i see
maybe i should try debugging hubs again during the christmas break
im still kinda thinking about attaching a logic analyzer to the usb hub to see what happens when it responds with an usb transaction error
you have a logic analyzer?
damn
a shitty 8 channel 24MHz one, which should be borderline barely enough for usb fs
i could also use my pi pico as one ig
fair
actually, there are projects implementing fake usb hubs with rpi pico pio
i could also try that to see what happens there
okay time to design my Seat/IODev abstraction
so i guess there are different kinds of devices
theres serial
both CDC and hw serial
and then theres like GUI serial
which would i guess be handled by a GUISerial iodev?
or it could be a "proper" gui menu or something?
hmm
based
so do I
I also have working hub code in FUBS
nice
I will write hub code for FUSL soon too
figured
lmao
you're only half right, for now
which part can you disagree with š
yes
its definitely a shitlang
i dont think that makes it a shitlang
also its closed
which is like, a key feature of a shitlang
dw it's gonna have a proper, source first license later
so not even oss :^)
no, the entire idea is to do better than oss
i mean shkwve doesnt have a license at all atm
ok time to copy paste dual mit apache2
have fun getting your shit stolen by big corp
my code is too bad for that lol
:^)
also id be happy if a big corp stole my code
it would mean its actually good!
ok i got bored of looking up how to dual apache mit my code
ill just do whatever limine does
actually i think ill change my mind again
its mit now
uh
what license is FUSL
none yet, we'll see
you should just make it 0bsd
or dual mit+apache
(the last one gives a patent grant which is important for some big corpos)
this is the main candidate rn
but I may do something spicy
its public domain but its actually legally sound
L public domain
L cuck license!!!!
gnu will rule the world!!!
(this is sarcasm)
(I prefer permissive licenses anyway)
yeah lol
funnily enough the only people i've seen complain about ""cuck licenses" are not developers
like luke smith
lol
also has anyone spotted how the battery aml works on my laptop
it has two batteries, I assume there is a way to switch which one it drains
currently it's doing the dumb and is draining the internal battery first, and the swappable one last
which honesly is like room temperature iq levels
I assume there is a way to tell it which one to use from AML or whatever
oh lol it does indeed
it's controlled by a field in the embedded controller
via AML or something else?
I couldn't find anything in the firmware settings
ooo
i see aml reading it but idk how its changed, probably via the windows WMI driver which talks to AML
hmmmm
charge_behavior i guess?
ā” root@thonk ī° ~ ī° cat /sys/class/power_supply/BAT1/charge_behaviour
[auto] inhibit-charge force-discharge
ā” root@thonk ī° ~ ī° cat /sys/class/power_supply/BAT0/charge_behaviour
[auto] inhibit-charge force-discharge
I probably should switch it to force-discharge on the one I want to use then?
These are your WMI-customizable options, perhaps one of these controls it?
I can't find anything in /sys/class/power_supply related to this
yeah i dont know tbh
okay hmm lets think some more about my device abstraction
and how to make it less shit
okay i did some more horrible interrupt stuff
lets figure out how to make xhci generate interrupts
okay wow that wasnt even that bad
yeah is ez
totally didnt have to add printfs all over qemu to debug it :^)
yeah no same
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index ad40232eb6..65a074b238 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -31,7 +31,7 @@
#include "hcd-xhci.h"
-//#define DEBUG_XHCI
+#define DEBUG_XHCI
//#define DEBUG_DATA
#ifdef DEBUG_XHCI
@@ -591,16 +591,20 @@ static void xhci_intr_raise(XHCIState *xhci, int v)
xhci->usbsts |= USBSTS_EINT;
if (pending) {
+ DPRINTF("xhci_intr_raise: pending\n");
return;
}
if (!(xhci->intr[v].iman & IMAN_IE)) {
+ DPRINTF("xhci_intr_raise: IMAN_IE\n");
return;
}
if (!(xhci->usbcmd & USBCMD_INTE)) {
+ DPRINTF("xhci_intr_raise: USBCMD_INTE\n");
return;
}
if (xhci->intr_raise) {
+ DPRINTF("xhci_intr_raise: raising interrupt!\n");
if (xhci->intr_raise(xhci, v, true)) {
xhci->intr[v].iman &= ~IMAN_IP;
}
I would never do that
oh i had a lot more printfs
can you not -d trace:*xhci*
?
of course you can but there are no printfs for what I wanted to know
okay i kinda glued up support for my new seat subsystem
i think i'll rework how my device discovery works to work similarly to Keyronex's DeviceKit
okay, time to do that
it's a bit annoying in rust because no interfaces + no inheritance
but it sounds like a better architecture
hmm i still dont know how to design my driver abstraction
so i like the fact that DeviceKit uses inheritance
which is neat
but doesnt work in rust sadly
which really sucks
traits dont really solve everything
i see i see
you aren't using rust though
i like the inheritance approaches
but they dont work in rust
so many things dont work in rust, actually
its kinda funny
wait are you using rust?
no
the nub thing is neat
and plists
a PCI driver identifies its provider as "PciDevice"
and sets a vendor id/device id
and now it's automagically discovered on bus iteration
and instantiated
I guess in rust you'd use dynamic traits
or something
in rust youd do idk some crazy shit probably
hmm, thats a neat idea
might do that
right now i just manually probe
it's literally how IO/Kit works
like i apply every probe function
to every new device
which is ugly and a bit expensive
there are more pressing issues with my design though
what you do is instantiate a PciDevice "nub" for every pci device on the bus
then call probe
for each device
what's a nub?
that's what apple does
it's what sits between an actual device and a bus of some kind
iirc
but yeah i think caller-controlled probing is a better approach
it doesnt do anything but probe for drivers
Essential information for programming in the OS X kernel. Includes a high-level overview.
"Each nub provides a bridge between two drivers (and, by extension, between two families). It is most common that a driver publishes one nub for each individual device or service it controls. "
yeah if a driver is loaded at runtime you can just go through unmatched nubs
I cant really think of other uses on the top of my head
ngl
the lack of inheritance in rust is super limiting
i pretty much need some sort of inheritance system
hmm
hmmmm
I think I could think of a way to do it with dynamic traits
but I'm not sure it'd be feasible
dont think you can
i dont want to switch to c++
id rather write some cursed macros or a compiler plugin or something
yeah but like
you can do it with #[repr(C)]
you can do both
no thats like the worst of both worlds
actually i dont even need repr(C)
i think i just need some container_of memes
"Umm actually sweaty inheritance is a BAD thing" - him
okay i'm doing hid part two now
for a meme project im adhd'ing myself to but its also an excuse to fix the hid logic
and by "fix" i mean "rewrite"
okay im so fucking confused rn
i'm trying to parse the hid descriptor for my m1's trackpad
their adherence to the spec is best described as "not" afaict
unless its linux
i THINK this is a real hid device? maybe???
it has a bus type of BUS_SPI
and it has a vendor/product id that is the same as the apple usb thing
okay i give up apple sucks
lol
okay, new plan
im back to redesiging my device shit
the NEW system is designed in a way that is legally distinct from Keyronex' DeviceKit
and thus is completely original and do not fact check that
except its more different
basically: there's still a tree of devices, except its not really a tree and its more of a digraph
a device can also have a special "parent" node and if you take all the parents together you get a tree
the NEW problem i'm facing is the exciting problem that because (like in keyronex) my devices don't have names
uh
my devices dont have names
actually maybe keyronex has names
but i dont
and i need to assign them somehow
ugh
UUID? 
i guess i dont really need names anyway
it does, implicitly the class name so i don't guarantee distinctive names
so it doesn't have names
i have a device type too
new keyronex branch (not online) has multiple axes and names per axis, and the idea there will be that names will be unique
i see
#[shkwve_derive::device(name = "slice", traits = [Block])]
struct Partition {
#[edge]
parent: DeviceRc<dyn Block>,
#[prop(uint)]
start: u64,
#[prop(uint)]
len: u64,
}
impl Block for Partition {
fn size(self: &Device<Self>) -> u64 {
self.len
}
fn read(self: &Device<Self>, offs: u64, buf: &mut [u8]) -> Result<()> {
self.parent.read(offs + self.start, buf)
}
}
```okay now i have a custom rust macro for making this kind of workflow work
i can also guess the #[edge] and #[prop(uint)] annotations automatically now
proc macro is so fun
also super cursed
but fun too
#[shkwve_derive::device(name = "ramdisk", traits = [Block], extra_props = { size: u64 = size })]
struct Ramdisk {
data: OwnedBuffer,
}
impl Block for Ramdisk {
fn size(self: &Device<Self>) -> u64 {
self.data.len() as u64
}
fn read(self: &Device<Self>, offs: u64, buf: &mut [u8]) -> Result<()> {
self.data.get(offs as usize..offs as usize + buf.len(), buf);
Ok(())
}
}
``` okay now i got extra_props working
and it does stuff to get &Device<Self> to work on the size callback too
so my only slightly scuffed proc macro seems to be working now
ayo i like this interface
yeah thats one of us then
/j

Any particular goldfish device?
okay now i populate the devicetree into my device model meme
also i will not say how long it took me to make those unicode box drawing characters to lay out the right way
now i also show the compatible here
Now also deref phandles and pretty print what they reference
thats the phandle of the node
also it doesnt really make sense with what the tree is intended to do
ykwim
my dt pretty printer in the console does do this already btw
the console is commented out tho until i reimplement a bunch of other shit
yeah this tree dumper is even more overengineered than the keyronex one
yeah im a fan myself
also this is meant to be a debugging facility as well kinda
in terms of random shit that is a total waste of time, i wrote a mac multitouch parser
so now i can get the raw finger data
okay so anyway lets go back to figuring out how to make the bus meme work
okay now i have this mildly cursed query DSL: ```rs
for f in query!(>(type: "fdt-node" name: "cpus")>(type: "fdt-node" name: "core0")) {
// whatever logic
}
which you can use to find nodes
and its a whole bunch of proc macro memes to eventually produce an NFA
so the codegen ends up being only a little scuffed as fuck
actually the codegen seems surprisingly good
nfa?
nondeterministic finite automaton
its math stuff
the important point is that it works
especially now that i fixed a bunch of small bugs and added even more things (i can now do query!(... as type) and it will only give you answers that are of that node type which is handy sometimes)
and it also has theoretical support for really complex queries
like regex-type queries
now i have a plic node
the thing after the ~ is the node's stable name
okay now lets figure out why qemu reports a weird uart clock
sql!
lol
i love dsls
what does clock-frequency do on an ns16550
what does this value mean
i used to think its the clock
and then the baud rate is clock / divisor
but that does not match qemu logic
okay now i have an interrupt which is a child of the interrupt controller
with an id
and a target which is set to the uart
this is the pitust⢠advancedā¢ā¢ architecture®®© for interrupts®® (or PAAIā¢) (patent not pending)
not to be confused with AAI which stands for Advanced Autonomous Industries
i still need to do interrupt registration
and handling
okay
now i have registration at least
time for handling or something i guess
okay now im not getting interrupts anymore fuck
ah it was just my stupid code
now it totally works
your thing sounds overengineered
huh i think i found a qemu bug
maybe
or maybe not idk
somehow im getting random spurious serial interrupts if i write to uart in my read interrupt handling logic
okay anyway
my totally normal and certainly not overengineered input queueing system is done
this new device system is way better tbh
lets do another driver
fwcfg time
okay my new totally not scuffed i swear fwcfg driver is a thing
so, the remaining drivers are:
- disk stuff
- ramfb
pci- usb hell
lets do ramfb
NVME works!
it was just a tiny bit of tweaking to make the old driver work, really
the really annoying one is gonna be xhci
both because im planning to redesign some things a bit, part N+1
but also because it will be when i have to finally implement hotplug
okay now the size of the NVM namespace is no longer a string
and now i have partitions going
okay now i have a syscon driver
so far the new device subsystem is miles better than the old one
okay i think it might be time for virtio
okay cool
what do you think of it?
weird
i think that's a good way to describe it
what 9p protocol version are you using?
very simplistic
9P2000.L
original 9p would have had you bewildered, 9p2000.U an improvement but still overloads everything
heh
9p2000.L finally dissociates the operations into ones that resemble a conventional vfs
it is the opposite of NFS in many ways
i have looked at NFS recently for a ctf chall (and i did not enjoy that experience, and will not be doing nfs again most likely)
okay back to xhci
okay now i have a new cleaner impl of usb hid
im somewhat tempted to rip off linux evdev
okay time for the "fun" that is pci irqs
I have a question do you develop a kernel or a super bootloader with usb support
no
that requires qemu doesnt it
or basically qemu
i.e. no way lmfao
no
it just requirse a normal cpu emulator then?
pci option roms are x86 code
and im not on x86 so i guess id need to emulate it
a few firmwares do it, you need only basic x86 emulation
and im not that crazy
hmm
still probably not
waiting for the emulator in your bootloader to run real mode applications
how much cpu emulation do you actually need?
anyway for now ill focus on pci bullshit
Slimline Open Firware - an implementation of IEEE1275 Open Firmware for some POWER ISA systems - aik/SLOF
this open firmware implementation uses a package called "x86emu" for it
and its a shitload of code
okay maybe its not that bad
but still no
or at least not anytime soon
first i need to figure out how pcie interrupt-map is actually encoded
because the spec and bindings are incredibly unclear
the definition from the open firmware spec seems reasonable
no guarantees linux didn't shit it up
great, it was written by sun and friends, maybe it will actually make sense
lets figure out how to make pci irqs work
okay time to figure out why my interrupts arent interrupting
okay good news
i now have these pci-irq devices
bad news
they do not work correctly
holy shit
interrupt driven xhci actually works???
finally reached driver parity with old shkwve
cool :^)
maybe i should have a single pci-irq device
instead of a couple
meh
its fine
and that would require me to deal with handling multiple interrupt controllers a bit more and thats annoying
also i need to do the remaining virtio devices
net, serial, scsi, gpu
net and serial require async virtio too
anyway
i could definitely do an arm port right now
my asm is almost fully constrained to arch/rv64
and the abi for that is a couple functions
plus i'd need a gic driver i guess
it would be totally doable though
but i cant be fucked so
no
lets instead work on making input work
I also couldn't get my IRQ routing code from x86 to work on RISC-V, but I haven't bothered figuring out why it didn't work so idk
i'd think x86 irq routing is totally different?
oh you fixed it
because acpi and not whatever the fuck FDT is
no? you just use lapic instead of plic
yeye it was totally working
yeah that part true
tbh its all the same
except more different
i think pci irqs are totally different actually
you also have acpi with ovmf
then it's the same
besides a different (slighlty dumb) controller
but supposedly it's still a GSI which you route to somewhere
any time i plug in a new keyboard weird things start happening ! shkwve_bin/src/driver/xhci.rs:435 xhci: unexpected transfer event trb with no transfer started, code Success ! shkwve_bin/src/driver/xhci.rs:435 xhci: unexpected transfer event trb with no transfer started, code Success ! shkwve_bin/src/driver/xhci.rs:435 xhci: unexpected transfer event trb with no transfer started, code Success
like my ns16550 interrupts worked, and pci didn't
but only sometimes
this is super worrying ngl
and if that happens then i dont ever get any keyboard input
the xhci fsm probably breaks because my code is ultra fragile
qemu is also fragile 
so i get this
nah its definitely me
okay lets enable debug logs
1st step of debugging: blame the compiler
those might be useful
that is not a BAD strategy
especially since i had compiler-induced failures in the past
okay so the original device was assigned slot 0
the second device gets assigned slot 1
which is why it works i think
the third device reuses slot 0
fun!
well this is worrying
okay so i think the issue is memory corruption -> stack exhaustion
yeah so it is trying to free shkwve::driver::usb_hid::USBHID
okay
i was freeing the wrong thing
still getting transfer errors though
the transfers themselves are normal and expected
i think the issue is that the ring contains a bunch of stale transfers
yeahh
so now that i have this working
and NOW i have feature parity
time to reenable console
also i want to do fbterm
actually fbterm might be first
because cool
i kinda want to switch from the log crate to my own meme
its pretty easy to do
and i could make it only compile in the log entries that i opt into at compile time or something idk
when are you adding userspace? 
neverrrr
(lol)
okay, drawing text, attempt 1
okay
shkwve fbterm is basically better than flanterm now
hmm i think something went wrong still
but i dont know if its qemu
or my code
lets build qemu with qtk
yeah i think it was the issue
with gtk it looks fine
lets build qemu AGAIN because i managed to remove it
yeah
with a patch to force SDL_WINDOW_ALLOW_HIGHDPI it looks fine
feature parity with what?
old shkwve
nah it looks cool
it looks ass because dpi scaling on linux is fucked
before i threw out the entire device subsystem
and did it again
and qemu isnt helping the situation
it should look like a normal font except ??? linux moment
the font
how are you printing it
rendered by imagemagick
i have a bitmap
i know the bitmap looks fine because i checked
also the asahi people render it correctly
and it does look fine for them
bruh i thought you were doing ttf rendering or something
i was sweating
lmfao
i could port rusttype
or something
idk
theres a lot of rust font rasterizers for some reason
im sure at least one of them supports nostd

try it
its already 900k
eh i dont really want to, because why
and all of them suck
there's really no point
ah i see
that's 3 Limines
is it
rust gui in general sucks
roughly
you mean compressed limines?
no
wtf
gaddamn
actually it's more than that
and its only light optimizations
yeah
damn
though
i have drivers
which arent small
i mean
all i have is drivers, lol
and 12kloc of code
im not counting debug symbols
680k release
yeah so im a lot bigger
i wonder why
other than rust
it's 250k after strip
tbh its probably rust
it's probably rust
yeah
plus my liberal use of code generation isnt helping
you know what is also not helping
the fact that i might have accidentally added a bunch of crap to the binary
like uh
idk actually
ah no i didnt
i was worried for a sec i added all of keyronex to my size
i have a thing which puts a bunch of files inside of the bootloader
and im measuring the size of the final binary
its also not rust
its the fact that i ship unwind tables
its only 290k of code and data
still fatter than Limine
true
that is all on rust
like yeah im not gonna beat limine on size ever
not the goal either tbh
how did you take that screenshot btw
oh wait there is a "screendump" option in qemu im blind
here is mine so far
grim -g (slurp -d) | wl-copy
ah lol
something like that
i just used qemu monitor screendump
didnt know that was a thing
because that reliably produces correct pixels
anyway
works
now is a good time to fix my io crap
i have fbterm working now
so wait, how are you printing, now?
still sbi console
i have a graphical terminal now implemented
but i dont use it yet
thats blocked on whatever i come up with to manage devices
Do it
i have a mildly cursed idea
what if i made a scuffed powershell clone for my console thing
oh yeah also i have the graphical terminal thing doing output now
XHCI/USB HID input too
no cursor because idk
okay now i have a cursor
and i have half broken incremental repaint, so i only redraw the cells that changed
okay needs more work
oh its my cursor movement stuff
ugh
oh also i think my arrow key handling is fucked
oh i think its my shit ass key repeat "logic"
wonderful, tree still crashes it
oh right
its a utf8 moment
ughhh
literally everything else works in ascii not utf8
now the graphical subsystem has the required special characters to draw these as well
okay i redid all the commands except lbp support (which i need to fix up for the new device model still)
and fs stuff
and time
and also now i have an idea for a new device model
so i might rewrite it all again now
but this time without as much cursed
hmm what if ECS
(probably a bad idea but)
also im not sure anymore about my idea where nodes dont have a label
nah ill do an arm port instead
so arm port step 1
lets make the riscv port handle relocation
i'll need it for any efi ports i may want to do in the future anyway so might as well
okay so, relocations on riscv "progress"
also i think theres still some memory corruption
yeah
works
for some reason, qemu seems to load my kernel in 32 bit mode???
wtf
ah i was missing -cpu cortex-a72
im getting an undefined insn again, pc=0x40081c90
its probably FP
arm64 shkwve!
im polling the gic right now so its not really super great
and i need to unmask only the required interrupts instead of all of them
okay next steps
uh
implement vbar
and wfi
cool
i now unmask only the important stuff
next step vbar
irq delivery works
big w
this was mostly pretty easy because my shit was mostly portable
okay same thing as before but with interrupts this time
okay i think ill do fs now maybe

oh exciting
programming the pl011 correctly requires me to engage in clk and pll torture
igpu flashbacks
lmao
nah its cool
this is only one clock
and i can hardcode fixed-clock for now
i love clock and pll torture
wait wtf lmao
it's called being lazy
theres just a firmware call to set the clock to whatever you want???
okay now i need to grab a dtb dump
i haven't looked at the properā¢ļø way to do it, but the fw interface works well enough to just get uart up and running
and the cprman points to firmware = &/soc/raspberrypi,bcm2835-firmware
i also don't know how i want to deal with clocks and resets in managarm
but yeah ill need to do clk and pll torture at some point
the fw interface is the proper way to do it
the linux driver doesn't talk to the firmware?
you sure?
Elixir Cross Referencer - source code of Linux v6.12.6: drivers/clk/bcm/clk-bcm2835.c
C-f firmware only yields some comments
aah
only 4 in fact
also no hits for mbox/mailbox
well it'd be needed for other platforms
i can 100% assure you that the shkwve clk and pll torture subsystem will use a firmware call
other platforms with a broadcom soc?
i'm not too worried about clocks on the pi4, but e.g. i do have a wip port to exynos7870 somewhere
damn
i should try targetting one of my phones
or the m1
probably the m1 tbh
since you have a nice uart over a special dongle
on the galaxy j7 that i was testing on you can get an uart over the usb port too
yes but you need a different special dongle from the one i have
by using an otg dongle that has a special pulldown resistor with a specific resistance
it turns D+/D- into RX/TX
same as on my pixel 3a and 5
the pixel 5 even has a bug that lets you get code exec in uefi so...
but so far i've done without that and instead just reenabled enough of the display controller to get a working framebuffer after the bootloader jumps to the kernel 
(i think)
lmfao
just abuse ramoops :^)
or set a uefi variable
thats a trustzone call i believe
so firmware does it for you
no uefi here
or at least it is on my phone
ah unfun
anyway
back to getting inspired by the managarm pl011 driver
samsung has a proprietary bootloader that's loaded by the bootrom and that just jumps to linux
(and handles download mode etc)
ah right samsung moment
afaicu it's a single flat binary on one of the partitions
(+ another partition for crypto code and another for config stuff and a tar archive with all the images like the samsung logo etc
)
abl, abl_payload, hyp, imagefv, tz, uefisecapp, xbl, xbl_config, cdt
on samsung phones with exynos socs (at least the older ones) it's sboot, cm, and param
abl has an elf and a uefi firmware volume
abl_payload is JUST an efi firmware volume
hyp is an elf
imagefv is an elf with a uefi firmware volume
tz is an elf
uefisecapp is an elf
xbl is an elf and an uefi firmware volume
xbl_config is a flat binary
cdt is some magic header + dtb
(no it does not contain any devices, cdt is just some provisioning data. obviously.)
pl011 driver works too
interrupt-driven btw
its only a 2 kloc diff
now the real question is
does it run on riscv still
the answer is no
okay i fixed THOSE bugs now it works
okay
so do i implement more boot protocols
or do i implement x86
or do i implement more boot protocols for me to be loaded by
later today ill try running on m1 (this is not gonna be fun)
oh also or do i fix SMP
or do i clean up the riscv arch code
i think ill fix my fs layer
hmm or maybe ill unfuckup my device model
by adding an explicit path system back
and a multi-axis system
(again)
okay the primary uart is the s5l at 0x235200000
#define UTXH 0x020
#define UTRSTAT 0x010
#define UTRSTAT_TXBE 2
while (!(read32(uart_base + UTRSTAT) & UTRSTAT_TXBE))
;
write32(uart_base + UTXH, c);
cool
okay i only did env setup
I'm getting tempted to buy an m1 Mac Mini
lmao
i have a 3 day weekend coming up because therres a storm or some shit
for initial bringup i will probably use m1n1 hv
so i just need to write(0x235200020, output) to get logs
i really need to implement the even newer device subsystem though
then when that works (and i can take the mandatory pictures for bragging rights) i'll try getting it working on pure real hw
i still defo need to mess around with EL2 stuff
since right now i just assume el1
also im missing arm paging
and i need any boot protocol
so i can claim the true bragging rights
ugh i think i have to rework my device model but i dont know how to make the new one
hmm actually it might be fine
or maybe not idk
so the problem is that my device model doesnt really have a great way of naming different nodes
and it sprays assumptions about DTs everywhere
with no easy way to avoid it
hmm maybe i could actually steal a page from managarm's book and have a flat list not a tree
pros:
- i do not need a tree
- easier probably
cons:
- not a tree
- i cant have as many colors
- lots of things really are trees, like the acpi/aml tree
ok ill just add names to my devices and call it a day
ah wait thta doesnt map to my interface
fuck
ugh
just program it incorrectly lol
you're doing -Zbuild-std or whatever right?
wait this is freestanding, you're likely already doing it
yes ofc i am
for a target named checks notes l0eklpdnp4av9vig5bupeab1fidtpnj3d1hoh91p04rfi
so i think its definitely -Zbuild-std
i think you can get away with not doing it for some freestanding targets because they're tier 1 or whatever
i think l0eklp... is definitely not tier 1
ok that's good at least it's not the entirety of std
yeah ofc
the unwind tables can probably be optimized further too tbh
they arent particularly optimal at the moment
last time i checked the target list x86_64-unknown-none was tier 1 so there is prebuilt std for them? so you could probably not do build-std and that would likely cause the binary size to be huge
yes but i dont want to use it
also there is no difference between build-std and them building the std for me
I use custom json target specifications for all my targets which i strongly recommend if already not doing that
cool
{
"abi": "softfloat",
"arch": "aarch64",
"code-model": "small",
"cpu": "cortex-a57",
"crt-objects-fallback": "false",
"data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32",
"eh-frame-header": true,
"emit-debug-gdb-scripts": true,
"features": "+v8a,+strict-align,-neon,-fp-armv8",
"linker": "rust-lld",
"linker-flavor": "gnu-lld",
"llvm-abiname": "softfloat",
"llvm-target": "aarch64-elf",
"max-atomic-width": 64,
"panic-strategy": "abort",
"supported-sanitizers": [],
"target-pointer-width": "64",
"position-independent-executables": true,
"dynamic-linking": true
}```
something like this
(this is the arm one the riscv one is similar enough though)
it's kinda required for non-x86 because there is no default target for most of those freestanding ones iirc?
but some people in the rust #os-dev channel don't use a json target specification for x86
cringe
yep
ill definitely be using one
what is shkwve supposed to be
a bootloader i guess?
and am i supposed to pronounce it shockwave
they are derived from some properties
target:
arch: aarch64
cpu: cortex-a57
code-model: small
data-layout: e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32
abi: softfloat
features: +v8a,+strict-align,-neon,-fp-armv8
``` so its actually only this
did you know you can pass linker args and linker scripts there
in the target json?
yep
no i did not
but why
i just generate a cargo config matching the current selected configuration
which contains a -Clink-args i need
and also a bunch of other flags like -Zinstrument-mcount if required
and -Crelocation-model=pie
and -Zdirect-access-external-data=yes
i mostly used it for linker scripts I didn't even touch that many linker args
what I did before using limine for risc-v was create a linker script and target for each board (e.g. i had riscv64-qemu.json and stuff)
and I wasn't using SBI or anything it was booting from M-mode so it depended on the reset address of the SoC
i have something like that except 10x more cursed
and with more yaml
omg show me
configs are here https://git.sr.ht/~pitust/shkwve/tree/trunk/item/config
the schema is here https://git.sr.ht/~pitust/shkwve/tree/trunk/item/build-src/config.go
the parser is here https://git.sr.ht/~pitust/shkwve/tree/trunk/item/build-src/data-ast.go
most if not all of the processing is here https://git.sr.ht/~pitust/shkwve/tree/trunk/item/build-src/main.go
ok yes that's cursed
yes but cool
yep cool that you got it working the way you wanted
and its layered
tbh hardcoding where the memory starts and ends in a linker script is more cursed
this is an actually good solution
linker scripts?
i generate those
at compile time
I wrote them for every board manually :3
lol
i used to hardcode a base in these configs before i switched to self-relocating executables
which dont need that
its like 10 lines of asm
and a custom relocation table format
which is shit and horrible
none
it used to do limine
and i want to fix limine
then a rewrite happened?
and probably add linux boot
yeah i changed how all device stuff works
# BSP code
adr x10, __blob_base
adr x11, __rel_start
adr x12, __rel_size
ldr x11, [x11]
ldr x12, [x12]
add x12, x12, x11
_loop_begin:
cmp x11, x12
beq _loop_end
ldr w13, [x11, x10]
ldr x14, [x13, x10]
add x14, x14, x10
str x14, [x13, x10]
add x11, x11, 4
b _loop_begin
_loop_end:
its pretty easy
__rel_start and __rel_size are patched by the build tooling
to contain a list of u32s that need relocating
shkwve is like what I would want from my bootloader if I were to roll one myself
lol
which shell thingy?
you mean the console.rs stuff?
ah yeah that
heres the help command
and it works both over serial and usb+framebuffer
very cool
oof

