<Clockface>
is there any reason to prefer PE or ELF over the other?
<Clockface>
personally, i lean towards PE since uefi endorsed it, so it seems to be the "official" format of the pc world
<Clockface>
but are there any better reasons to focus on one before i do anything?
<clever>
Clockface: but i primarily work on linux, so everything is already elf based, and the rpi bootloader expects elf files
<clever>
one thing, is that you can use the wrong readelf on a given .elf (for each arch) and it can still get most of the useful data out of it
<clever>
but if you want to decode a PE header, you need the cross-compile toolchain
<heat>
Clockface, ELF is superior
<heat>
it's simpler
<heat>
also its the standard in the UNIX-like world
<heat>
leaning towards something because UEFI endorsed it is, putting it mildly, wrong :)
<clever>
heat: if you where to prodocue a uefi binary, would you use a pe cross-compiler, or just translate the elf to pe?
<heat>
uefi picked PE because microsoft helped out with its creation (and there were literal nt kernel engineers on it)
<heat>
clever, objcopy from elf to PE
<clever>
and i assume objcopy can translate the relocation data?
<heat>
yes
<Clockface>
oh yeah, thats a random idea i had for a tool
<Clockface>
pre-relocate all the DLL files
<Clockface>
so when they are loaded its speedy
<clever>
one guide i think i saw on the osdev wiki, said to objcopy from an elf.so to pe.efi
<Clockface>
*rebase
<heat>
Clockface, that's called prelinking and already done
<clever>
Clockface: windows already does that, there is a cache of the data in system32 or some such place
<Clockface>
oh nice
<clever>
linux also has similar called prelink, but i think it causes some bugs
<clever>
cygwin also skips the problem, by tracking the base addr for every library, and putting each at a new addr, so they never conflict
<clever>
but that only works in certain situations
CaCode has quit [Ping timeout: 268 seconds]
sikkiladho has quit [Quit: Connection closed for inactivity]
<heat>
prelinking is done pretty extensively in UEFI firmware AFAIK
<clever>
it helps that every single binary in the firmware is packaged into a single blob and written to a "rom"
<heat>
also something I want to mention is that PE is super confusing and large and complex and its hard to load it
<heat>
clever, no
<clever>
so you know they will never be changed
<heat>
that's not true
<clever>
almost never changed
<clever>
so you can optimize for the default case
<heat>
you can't entirely prelink everything
<heat>
they only prelink some parts of PEI I think
<clever>
but you can at least pick a unique base addr for every .efi in the firmware
<heat>
which (should be) relatively small
<clever>
so they never have to be relocated, is what i meant
<clever>
got relocation and linking mixed up
<clever>
ah, but doesnt efi never actually do dynamic linking? its all manual via lookup functions?
<heat>
yup
<heat>
no dynamic linking
<clever>
so prelinking isnt really something you can do
<heat>
gog was going to work on it but sike that's the wrong numba
<clever>
only pre relocation, to a non-conflicting addr
<heat>
also I want to casually mention that EDK2's PE loader is bad, super hairy, and full of security holes
<clever>
the thing i had heard about cygwin, is that windows lacked fork() at the time, and for cygwin to emulate it, you had to just spawn a new process with the same libraries, then copy all of the heap/.data over
<clever>
and if a dll randomly decides to relocate differently in the 2nd proc, all hell breaks loose :P
<heat>
windows always had fork
<clever>
so cygwin just prevented all relocation, by ensuring everything is linked to a non-conflicting addr
<Clockface>
does security even matter that much on PC's, i always thought that if you run dinosecuritylogape.exe all is lost by default
<clever>
yeah, there are holes in that story i heard
<bslsk05>
mhaeuser/gsoc-2021-edk2-pe-loader - Submission material for the Google Summer of Code 2021 project "Integration of a PE/COFF Loader designed with formal methods" at TianoCore. (0 forks/1 stargazers)
<heat>
he built a whole formally verified loader because EDK2's is bad but no one got it merged because <strikethrough>they don't care about security</strikethrough> its hard or something
<clever>
lol
<heat>
at least they're getting rid of SMM
<heat>
yay?
<heat>
well, sorry, not getting rid but minimizing it
<clever>
heat: that also reminds me about runtime services, how do they typically work?
<clever>
is the complete code for the runtime services and accessing stuff like efi vars in SPI within the mapped chunk of memory?
<clever>
or does it RPC out to something like SMM?
<clever>
does it vary based on the mobo vendor?
<heat>
you can't actually get rid of SMM because authenticated variables rely on it, and secure boot relies on authenticated variables
<heat>
probably varies
<clever>
ah, and then you rely on only SMM being able to touch the SPI flash?
<heat>
yes
<clever>
and the SMM code lets some vars thru, and blocks others
<CompanionCube>
well it's not like sidechip-free x86 exists any longer, cheat and use that :p
<clever>
so the mapped chunk of runtime services, isnt directly manipulating the filesystem in SPI
<heat>
yes
<clever>
but is instead talkign to the SMM, which allows some actions
<heat>
it's a privilege barrier
<heat>
just like a syscall really
<clever>
but then on arm, might you implement that in EL3?
<heat>
I guess, that's probably how they do it
<heat>
well, not EL3 but the secure monitor
<clever>
and you would need a way to gate an spi controller to only secure mode
<clever>
where did i put that img...
<heat>
anything that isn't variables related is just regular ring0 runtime services code tho
<heat>
(theoretically) (hopefully)
<clever>
yeah, things like reset, what else does runtime services do?
<heat>
GetTime, SetTime
<clever>
ah yeah, talking to the rtc
<heat>
Capsule updates
<clever>
thats more in the security realm?
<heat>
there's also a monotonic count thing
CaCode has joined #osdev
<heat>
Capsule updates are just an update format for firmware
smach has quit [Read error: Connection reset by peer]
<zid>
well, my emerge --sync finished, that was good multitasking
<heat>
I challenge you to find something there that you can't understand
<heat>
my C++ is super simple
<zid>
I mean, like I said, I can guess
<clever>
heat: from reading the code you linked, it looks like the char device should always register, if the runtime services are available, but i dont see such a char device on my laptop...
<clever>
oh, but i do see a capsule-loader.ko.xz !
<zid>
C++ is an unknown number of unknowns, I don't know what I don't know
<zid>
for all I know = could be the "launch a flare" operator
<heat>
that's possible thanks to operator overloading
<heat>
however, thats kinda stupid ngl
<sbalmos>
just remember () is the pothole operator
<clever>
sbalmos: and the discord mobile client doesnt render () symetrically
<sbalmos>
clever: it's doing its job then, sowing discord and dissent amongst the harmony of IRC!
<junon>
dumb question: does ARM have the equivalent of the x86 halt instruction? Or to to a final 'halt', should a simple endless loop be used? I'm not trying to get into ARM specifics right now, just need to test something and this is all I need to know lol
<heat>
wfi
<Mutabah>
`wfi` or `wfe` (I forget the difference, I think it depends on the architecture type)
<junon>
Thanks :)
<Mutabah>
In all cases, you should wrap such an instruction in an infinite loop
<Mutabah>
as they will be interrupted by interrupts
<junon>
Yep, figured as much. Thanks! :)
<clever>
junon: wfi, wait for interrupt, wfe wait for event, sev send event
<clever>
sev will wake every core that is blocked in wfe
<clever>
but you may be woken up by an unrelated event, check your atomics again and wfe if the msg wasnt for you
<clever>
wfe/sev are usually used to implement a mutex, so you can block until another core has released the lock
<clever>
i assume irq's can still be services during wfe?
chartreuse has joined #osdev
<heat>
does arm have NMIs?
<clever>
heat: kinda, IRQ and FIQ have seperate mask registers in the core
<clever>
so you can block normal IRQ but leave FIQ enabled
<clever>
but FIQ is also somewhat deprecated in aarch64
<clever>
on arm32, the vector table is an array of opcodes, so servicing an exception (irq or otherwise) is just setting the PC
<clever>
and due to how densely packed they are, they must all be jump opcodes
<heat>
except on arm64
<clever>
yeah, arm64 fixed that by spacing them out more
<heat>
where's you get too many bytes to be packed and too little to write a handler on
<clever>
but FIQ is the last slot in the arm32 vector table
<clever>
so it doesnt have to be a jmp
<clever>
and there is nothing after it to enforce a size limit
<clever>
FIQ also banks a large number of registers, so you dont have to save/restore in your irq handler
<clever>
both of those factors, is what makes it the "fast irq"
opal has quit [Ping timeout: 268 seconds]
<clever>
the VPU vector table, is instead an array of PC's
<clever>
so instead of doing PC = table+4 your doing PC = table[4]
<clever>
heat: how does x86 vector table compare? not sure ive looked it up before
<heat>
it's just a table of addresses + a bunch of other stuff
<heat>
mostly segmentation related
<clever>
ah, similar to the VPU then
<clever>
what about irq routing?
<clever>
on arm, every irq (except fiq) goes to a single irq exception handler
<heat>
IRQs go to vectors
<clever>
and software must then figure out why it was interrupted, and run the right handler
<clever>
on VPU, there are 64 slots in the vector table, one for every irq, so the hw jumps directly to the correct handler
<heat>
on the apic (io apic IIRC) you specify the vector for each IRQ line
<clever>
but with the PIC and such an expansive tree in both x86 and gic, getting a dedicated slot for every irq#, would be tricky?
<clever>
ah
<heat>
you can easily get a dedicated slot for each irq
<heat>
you've got around 255 - 32
<clever>
and its less the cpu knowing which slot in the table, and more that the (A)PIC tells the cpu what addr to jump to?
<clever>
oh, no, not what i said
<heat>
the APIC tells the CPU which interrupt vector it wants
<heat>
the CPU does the lookup, etc
<clever>
more that you have X vectors on the cpu, and you program the (A)PIC to send IRQ# Y to vector X?
<heat>
yes
<clever>
and then the cpu does PC=table[X]
<heat>
the 8259 PIC is way simpler, it's just a register wth a base vector
<heat>
and then the vector it triggers is vector_base + irqn
<heat>
of course you can totally set it up like that in the IO APIC, I do that for instance
<clever>
so x86 and vpu are similar, but x86 has an extra layer that translates irq's from a wider array to a smaller array
FreeFull has quit []
<heat>
how do MSIs work in arm?
<heat>
you don't really have interrupt vectors
<zid>
I assume same as anywhere else, there's an address you can listen for ints on
<clever>
the GIC can support MSI's, i believe that will have an MMIO slave exposed to the bus, that any peripheral can DMA write into
<zid>
and maybe the hw can even decode the request for you if you're lucky and route it
<clever>
and you can configure the GIC to trigger a virtual irq when a certain msg is written, i assume
<heat>
MSIs are built assuming you have a lot of vectors
<clever>
then when the gic raises the single irq line, you ask the gic "whats up?"
<heat>
and thus its beneficial to get multiple vectors for your fancy NVMe or NIC
<clever>
heat: yeah, when i check `cat /proc/interrupts` on x86, i can see my nvme has one vector for every core, routed to a single core each
<clever>
all are labeled as PCI-MCI
<clever>
i assume the first number is the raw cpu vector#, from that 255 - 32 range you mentioned
<clever>
so these 8 MSI's are mapped into cpu vector 43-50
<clever>
and irq routing means each irq only wakes one core
<heat>
yes
<clever>
heat: this leads into another question though, could you configure MSI-A to trigger vector 43 on core0, and then MSI-B to trigger vector 43 on core1??
<heat>
sure
<heat>
but you lose a good part of the advantage there
<clever>
that would eliminate a lot of the waste here, where it blew 8 vectors, when it could have done 1
<heat>
for instance in NVMe when you're creating an IO queue you specify the MSI vector you want, so when you get an MSI you already know which subset of IO queues may have caused it
<clever>
the way the irq routing is done on my system, it feels like its L1 cache related
<heat>
why?
<clever>
where if core0 does a request, it requests the completion irq to go back to core0
<heat>
well, yes
xenos1984 has quit [Read error: Connection reset by peer]
<clever>
so when core0 gets the reply from the nvme, and returns to whatever asked for the data, that app is L1 hot
<heat>
that's not entirely L1 cache related
<clever>
and every core can talk to the nvme independantly
<clever>
and depending on the filesystem, they dont even have to co-operate
<heat>
its just niceties for high performance storage
<heat>
NVMe does that, but for instance you'll only have a single GPU MSI
<clever>
and yeah, each core has its own list of outstanding IO requests
<clever>
and you dont have to deal with mutexes, because that list is core-private
<clever>
so you can just rip thru it
<clever>
yeah, my amdgpu driver is only showing a single PCI-MSI, routed to core0
<heat>
the ideal case for high performance NVMe is core -> nvme_controller.io_queues[core] -> request -> **irq** -> msi to core -> handler looks at nvme_controller.io_queues[core] -> complete io
<clever>
yep
<heat>
you can't assume it though
<heat>
so you'll always need mutexes, etc
<clever>
vectors 51-76 are all assigned to xhci_hcd, but only 2 of those vectors have even fired
<heat>
the ideal case for high perf networking is similar to nvme
<clever>
the only pattern i can see, is 3 sets of 8
gog` has joined #osdev
<clever>
there is a sudden jump in the PCI-MSI#, which makes it clearly sort into sets of 8
<heat>
I think NICs hash the packet's header to route it to a CPU? something like that
<clever>
my desktop NIC only has a single PCI_MSI
<heat>
yes, these are fancier NICs
<clever>
the genet on the bcm2711 has 2 RX IRQ's, and can be configured to sort based on something
<heat>
do the e1000s have something like this? I think so?
<heat>
ofc this is super micro-optimization
gog has quit [Ping timeout: 256 seconds]
<clever>
oh god, my router is sharing irq's on the nic's
<heat>
there's a lot of shit you can squeeze for more PPS or IOPS
<clever>
and there isnt a single MSI on that router
<clever>
that reminds me, the genet on the 2711, fires an irq for every single packet
<heat>
jens axboe like 5x'd the IOPS on linux's storage stack on some months
<clever>
and with small packet sizes, that becomes a performance problem
<clever>
other NIC's can be configured to throttle irq's and fire less
<clever>
basically, only fire an irq if it has been over $x ms since the last irq
<clever>
so the first packet gives an instant irq
<clever>
a constant barage of packets gives one every $x ms
<clever>
and the final packet alerts you up to $x ms late
<bslsk05>
'This server lives underwater!' by Linus Tech Tips (00:09:11)
<heat>
maybe not? hence the need for a dma controller
<heat>
8257
<clever>
yeah, then maybe ISA can never MSI
<geist>
ISA can not MSI. but i'd think those nics could MSI
<geist>
though the manual for it would definitey tell you
xenos1984 has joined #osdev
<geist>
a little surprised you dont have any MSI going on on that board
<clever>
geist: and above was a question about MSI on GIC, i assume that the GIC exposes an AXI slave port, and you then allocate an MSI within the GIC, assign it to a virtual vector#, and then tell the peripheral to write to the GIC's AXI slave port, with the assigned message?
<clever>
model name : Intel(R) Xeon(TM) CPU 3.20GHz
<clever>
the gist is a dual-socket xeon system
<heat>
geist, maybe the chipset is blacklisted
<clever>
one cpu per socket!
gildasio has quit [Remote host closed the connection]
srjek has quit [Ping timeout: 255 seconds]
<heat>
intel should use utf8 on their cpuid
<heat>
Intel® Xeon™
gildasio has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
heat has quit [Ping timeout: 256 seconds]
joe9 has joined #osdev
heat has joined #osdev
heat has quit [Ping timeout: 256 seconds]
Ameisen has quit [Quit: Quitting]
Ameisen has joined #osdev
joe9 has quit [Remote host closed the connection]
<geist>
clever: works completely differently on GICv2 vs GICv3
<geist>
with v2 you simply tell the device what register on the GICv2 to write the IRQ number to
<geist>
gic v3 has a much more complicated intermediate table that does an indirection for you
<geist>
might be a fun project to finally figure out
<geist>
maybe i'l do that tonight
kof123 has joined #osdev
<clever>
geist: so GICv2, lets you just fire any irq you want, and its up to the drivers/device to play by the rules, and only trigger the irq assigned to the device?
<clever>
this now brings up another question, how does MSI work when virtual guests come into play?
<geist>
yep
<clever>
could an MSI to a GICv2, fire the wrong irq on purpose?
<geist>
if you're emulating the device you emulate the whoe MSI mechanism
<clever>
just to anoy an neighboring guest
<clever>
what if i'm doing passthru?
<clever>
where a real device is exposed to the guest
<geist>
then you need hardware that virtualizes all of that
<clever>
and assuming the iommu can restrict dma properly
<geist>
iommus usually have a whole virtual irq mechanism
<clever>
ah
<clever>
so the iommu may also have its own msi mechanism?
<geist>
this is where you get into 'it's complicated as hell, you'll have to pick a platform and read up on how to do it'
<geist>
yes
<clever>
that would solve the problem
<geist>
that's my understanding at least from intel and amd docs. the GICv3+ stuff probably has something ike that too
<clever>
the guest MSI's go to the iommu, which can then relay the irq with a configured remapping
<geist>
basically
<geist>
how that works is pretty specific but it's my basic understanding that it's something like that
<clever>
and a virtual device, would be emulated in software on the host, so it can obey the rules more strictly
<geist>
and then in that sort of environment it only makes sense if you also have hardware assisted interrupt controller virtualization (APIC-v, AVIC, GICv4, etc) and then there's a whole mechanism to trigger virtual irqs within hardware to virtual cpus without needing to exit out of the guest
<clever>
yeah, and thats what a virtual device would tie into
<clever>
so a virtual NIC would raise a virtual irq in the gic, and then transition to the guest
<clever>
while a passthru'd NIC would raise an irq in the iommu, and the iommu is then configured to map it to say an MSI in GICv2, so the iommu acts like a firewall for both dma and MSI
<geist>
i sort of understand that a bit but i have to go right now so can't tak about it anymore
<geist>
anyway, encourage you ro read about it
<clever>
sure
<clever>
and the above does all make sense
<clever>
double-checking the datasheets, the bcm2711 has a GIC-400, which is none of the above!
<mats1>
unfortunately, pukes all your samples to ???, like virustotal
<CompanionCube>
meh?
* clever
throws the vl805 flashing program at it
<clever>
its a static arm32 ELF, that does ioctl()'s into pci config space, to re-flash an SPI chip
<clever>
angr failed, empty result
<clever>
ghidra and hex-rays timed out, but i have had success with ghidra locally on that binary in the past
<clever>
binary ninja gave source
xenos1984 has quit [Read error: Connection reset by peer]
<clever>
CompanionCube: it is neat, but without the ability to interactively rename things, the code is rather unusable, really need to run those tools locally
carbonfiber has quit [Quit: Connection closed for inactivity]
the_lanetly_052_ has joined #osdev
opal has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
smach has quit []
smach has joined #osdev
sprock has quit [Quit: brb]
sprock has joined #osdev
socksonme has joined #osdev
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Vercas6 has joined #osdev
smach has quit []
smach has joined #osdev
smach has quit [Remote host closed the connection]
outfox has joined #osdev
smach has joined #osdev
sav_ has joined #osdev
ia64developer has joined #osdev
sav_ has quit [Read error: Connection reset by peer]
smach has quit [Ping timeout: 248 seconds]
sortiecat has joined #osdev
sortie has quit [Ping timeout: 244 seconds]
sortiecat is now known as sortie
smach has joined #osdev
GeDaMo has joined #osdev
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
socksonme has quit [Remote host closed the connection]
smach has quit [Read error: Connection reset by peer]
smach has joined #osdev
gxt has quit [Ping timeout: 268 seconds]
gxt has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
gog has joined #osdev
knusbaum has quit [Ping timeout: 268 seconds]
MiningMarsh has quit [Ping timeout: 268 seconds]
MiningMarsh has joined #osdev
gog has quit [Ping timeout: 252 seconds]
w41 has joined #osdev
<ckie>
i'm getting the OS writing urge again but the motivations for it are too weak compared to the effort
<mjg>
:))
<ckie>
ideas for something inbetween? i want to have a machine where i can keep all the code in my head
<mjg>
ALL code?
<mjg>
i was going to suggest doing a small project for a niche OS
<ckie>
yeah, it doesn't have to do much, i just want something where i know *everything*
<mjg>
alternatively if you want to cure yourself real quick try to set up crossbuild env in rust
<ckie>
or at least small and i can discover anything in a few keystrkes
joe9 has joined #osdev
<zid>
just do silly things to the framebuffer
<mjg>
how about you do a hello world kernel in an arch you never tried
<mjg>
vax, sparc, you name it
<ckie>
i have a pi sitting around
<mjg>
arm is mainstream now
<mjg>
well for years :-P
<ckie>
well yeah but i don't have those other machines here and writing for a emu feels dumb
<mjg>
ebay!
<ckie>
..weekend project
<ckie>
..space
<mjg>
well you do you man
<ckie>
i do have a bunch of xtensa devboards
<mjg>
[or woman]
<ckie>
mm I am not looking forward to bringing another monitor here for that
<ckie>
but.. it could be fun
<ckie>
esp32's are very limited
<ckie>
(relative)
<zid>
ethernet driver and just make a text adventure :P
<ckie>
ooh! yes!
<mjg>
ooh nice
<ckie>
yesyes!
<mrvn>
Do you want to play a game
<mrvn>
1) thermo nuclear war
<ckie>
^C
<mjg>
a kernel being a self-hosting telnet client
* mjg
likes
<ckie>
now I just have to pick which machine..
<zid>
That was the plan for my kernel originally
<zid>
but I ended up playing games with the framebuffer
<mrvn>
port the Star Wars film to your telnet server
<zid>
I was just going to make a web repl for its internals instead of /proc and /sys
<zid>
it was just going to draw treeviews for it all in html and serve it
<ckie>
it'd be cool if i bitbanged ethernet on the xtensa
<ckie>
how fast do I have to go?
<zid>
115200 baud
<ckie>
that sounds like serial?
<mjg>
man
<mjg>
get 2 cards
<mjg>
and use both at the smae time to send one stream
<zid>
ethernet is just fancy serial
<mjg>
a'la bonding
<mjg>
and do that at the 115200 rate in total
<zid>
serial + wiggles to sync the clock
<ckie>
i want to have osmething i can just plug in a random rj45 eventually
carbonfiber has joined #osdev
<ckie>
how are ie³ still gatekeeping 802.3i-1990?
<ckie>
(there's a paywall, like, bleh)
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<ckie>
okay, the paywall is no more
gog` has quit [Ping timeout: 252 seconds]
smach has quit [Remote host closed the connection]
smach has joined #osdev
wgrant has quit [Quit: WeeChat 2.8]
wgrant has joined #osdev
<ckie>
oh, ethernet *is* over serial
<ckie>
just a different connector!
gog has joined #osdev
philcox has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
smach has quit [Remote host closed the connection]
smach has joined #osdev
philcox has left #osdev [#osdev]
smach has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
smach has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
gxt has joined #osdev
sav_ has joined #osdev
\Test_User has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
PapaFrog has quit [Remote host closed the connection]
PapaFrog has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
chartreuse has quit [Ping timeout: 256 seconds]
[itchyjunk] has joined #osdev
scoobydoo has quit [Ping timeout: 248 seconds]
scoobydoo has joined #osdev
srjek has joined #osdev
nyah has joined #osdev
heat has joined #osdev
foudfou has quit [Ping timeout: 268 seconds]
foudfou has joined #osdev
heat has quit [Read error: Connection reset by peer]
dude12312414 has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
sav_ has quit [Remote host closed the connection]
smach has quit [Ping timeout: 268 seconds]
bliminse has quit [Quit: leaving]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
smach has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
smach has quit [Remote host closed the connection]
dude12312414 has quit [Remote host closed the connection]
bliminse has joined #osdev
dude12312414 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
elastic_dog has quit [Ping timeout: 268 seconds]
elastic_dog has joined #osdev
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
SGautam has joined #osdev
\Test_User has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<ckie>
few hours down the rabbit hole later: having only 24 clock cycles to bitbang 10base-t is proving challenging
<ckie>
10mhz is fast
k8yun has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
Vercas6 has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
foudfou has joined #osdev
Vercas6 has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
k0valski18894 has quit [Ping timeout: 268 seconds]
the_lanetly_052_ has quit [Ping timeout: 248 seconds]
smach has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
sav_ has joined #osdev
smach has quit [Client Quit]
sav_ has quit [Client Quit]
<geist>
hmm, yeah
<geist>
i wonder if you got one of those old ethernet transceivers and bit banged that if that'd help
<geist>
ie, the AUI 10baseT boxes
<geist>
probaby would at least give you 8 bits at a time
<bslsk05>
en.wikipedia.org: Attachment Unit Interface - Wikipedia
<geist>
looks like it is stil basicaly a serial link, or at least maybe 2 bits at a time? (Data link A, Data link B)
FreeFull has joined #osdev
smach has joined #osdev
smach has quit [Read error: Connection reset by peer]
mimmy has joined #osdev
<Bitweasil>
Oh, *man* that brings back memories.
<Bitweasil>
I had an AAUI adapter for an old Powerbook 520.
<Bitweasil>
What about using an Arduino or something as an ethernet-to-sane-serial-bitrate adapter?
<Bitweasil>
They exist, you'll be slow, but... put serial up at a couple MBaud, and it would handle things, I Think.
dude12312414 has quit [Remote host closed the connection]
<geist>
Bitweasil: yeah i had to get one recently because the microvax needed it for 10baseT
srjek has quit [Ping timeout: 244 seconds]
dude12312414 has joined #osdev
<Bitweasil>
Nice!
<Bitweasil>
I think I'm taking a slight break from my ARM gutless wonders. :/
<Bitweasil>
Qubes doesn't run on ARM yet.
<Bitweasil>
And I don't have the time to work on it at the moment.
<geist>
yah
<Bitweasil>
Though I'm not convinced it's going to be that difficult.
<Bitweasil>
Xen runs on various ARM boards.
<Bitweasil>
And a lot of Qubes is either C or Python... so once you're up there, if you've got all the Xen channels, stuff should (handwave goes here?) just sort of work.
<Bitweasil>
But it's an awful lot more work than I can crack fill with, and it's not something I can casually work with in my spare time.
<Bitweasil>
Also, it presupposes the RK3588 support exists, which... seems to be slow going. :/
<Bitweasil>
Qubes on 4GB is a weak dev target, 8GB is perhaps lightly usable, but you need more for daily driving it.
<Bitweasil>
I'm also not sure how Xen deals with big.LITTLE these days.
<geist>
yeah i got my rk3588 board, fidded with it for about an hour, and haven't touched it since
<geist>
i need to bring up LK on it, but it had a kinda complicated bootloader situation that i didn't feel ike figuring out right then
<geist>
and about then i decided i have too many open, half-completed projbects there that i need to finish up first
<Bitweasil>
Which one do you have?
<Bitweasil>
I've got a QuartzPro64 that should be here soon, and a couple Rock5 preorders that... I kind of regret, tbh.
<Bitweasil>
I've got a grand tied up in boards that aren't shipping.
<Bitweasil>
I should take a few months off work and just hack on this stuff... or something.
<Bitweasil>
Not like my team still exists in a useful form. :/ We're shedding people at an alarming rate.
<geist>
dont be the ast one left holding all the keys
<geist>
uh i got the... i aready forget the name, it was a litte rockchip board with like 4 2.5g ethernets on it
<bslsk05>
www.cnx-software.com: NanoPi R5S Rockchip RK3568 mini router launched for $59 and up - CNX Software
<Bitweasil>
lol, HDMI on the router. I love it!
<geist>
anyway yeah it'd probably be a nice little router. has some linux distro on it that works fine. the quad a55 is nothing to write home about but it does have proper pci based ethernet and whatnot
<Bitweasil>
As long as you're not running crazy firewall rules, should be totally fine.
<Bitweasil>
I just buy Mikrotik, though.
smach has joined #osdev
joe9 has quit [Quit: leaving]
<geist>
yeah, i usually just get some intel x86 machine in a firewall case
<geist>
the last one i have been using for like 8 years is a pfsense firewall. can't find a good reason to replace it until it dies
<geist>
though to be fair it wasn't a super cheap one, but still it's perfectly adequate for my tasks. one of those cases where unless you start shoving through 10x the data a firewall that worked 10 years ago probably will work just as well now. the hw requirements for data throughput doesn't go up much over time
<geist>
it'd be stuff like starting to run a VPN wher eyou used to not, etc
<Bitweasil>
Yup.
<Bitweasil>
I just don't end up with a ton of firewall rules that require advanced processing.
<geist>
my only itch now is my cable modem gives me 1.2gbit/sec now, and i have a 1gb eth port on the firewall
<geist>
i know i really wont miss the .2 but it just irks me that it's right there
<mjg>
:)
<mjg>
root the modem and run a torrent client in there
<mjg>
#notlegaladvice
<PapaFrog>
Port binding?
GeDaMo has quit [Quit: A program is just a bunch of functions in a trenchcoat.]
joe9 has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
sikkiladho has joined #osdev
<sikkiladho>
Remember someone wrote a love letter for klange a few days ago?
<sikkiladho>
well, I got one for clever, j'ey and giest for answering all my questions without any pay. :P
<sikkiladho>
thank you so much everyone, I got a job at AWS. Being the first from my uni to get a job at FAANG soon after graduating.
<j`ey>
sikkiladho: congrats
smach has quit [Remote host closed the connection]
smach has joined #osdev
smach has quit [Client Quit]
smach has joined #osdev
* PapaFrog
puts the tip jar on the counter.
* ThinkT510
notices someone tipping the tip jar over while tipping
* gog
steals the jar and runs away
* sbalmos
tops the tip jar with a top-off tip, to ensure it's in tip-top shape
<zid>
Ya'll suck
<gog>
:I
<ckie>
Bitweasil, geist: i'm using an esp32 which has a 240mhz clock and i think i've got it to send *something* (the interface stays up) but something on my host is rejecting my packets
<Bitweasil>
tcpdump and see what's coming in?
<geist>
probably malformed packet? some things off the top of my head: too short packet, i think they need something like 64 bytes minimum
<geist>
not enough preamble?
<geist>
and crc might be off?
<ckie>
i stole most of the packet from a real captured one
<Bitweasil>
... "most of" ?
<Bitweasil>
Did you recalculate the CRC after you changed it?
<geist>
ah then you'll be missing things like preamble which is usually stripped by the time you capture it
<ckie>
most of hence preamble
ThinkT510 has quit [Quit: WeeChat 3.6]
<ckie>
everything after the ipv4 magic is unmodified
<Bitweasil>
Does tcpdump show anything coming in?
<Bitweasil>
Even if malformed?
<geist>
i forget precisely what that looks like on 10baseT, so might have to consult the official spec for that
<ckie>
nope, just my machine trying to eat stuff
<ckie>
(arp, mdns, blah)
<geist>
this is where it'd be nice if possible to have a direct connection to a dedicated port
<geist>
so you can factor out all that other stuff
<geist>
doublesuperplus if you're trying to read it over 802.11 or something
<ckie>
yeah it's connected to one of my desktop's NICs
<geist>
oh perfect
<geist>
is it the only thing on that port?
<ckie>
mhm
<ckie>
but the whole "its 10mhz" thing makes it rather unenjoyable to debug without a scope
<geist>
might also check some counters on linux (ethtool, etc) to see if it rejected the packets
<geist>
might show a counter like malformed packet
<ckie>
nothing interesting, though ethtool disagrees with the kernel about speed,duplex
<ckie>
r8169 0000:25:00.0 enp37s0: Link is Up - 10Mbps/Half - flow control off
<ckie>
Speed: 1000Mb/s\nDuplex: Full
<sbalmos>
I blame ckie's malformed packets for dropping my SSH connection just now
<ckie>
i mean, net.ipv4.ip_forward = 1 on my machine
<ckie>
(:
genpaku has quit [Remote host closed the connection]
genpaku has joined #osdev
k8yun_ has joined #osdev
<ckie>
i bet this would be so obvious if I had a oscilloscope
ThinkT510 has joined #osdev
k8yun has quit [Ping timeout: 248 seconds]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
gog has quit [Ping timeout: 248 seconds]
<ckie>
i guess I could wire it back to itself instead of the ethernet and slow the clock and send that over serial
<ckie>
got buried in the logs!
<ckie>
E (37) I2S: i2s_calculate_adc_dac_clock(1017): sample rate is too large
<geist>
oooh eep
<ckie>
maybe i'll have to fallback to my self-modifying code stuff then
<ckie>
(the esp32 has 2 main cores and I could make the other one generate instructions to set the GPIOs for a few cycles and noop until it's time again)
<ckie>
i spent a few hours figuring out how to set the GPIOs fast enough for that then I thought of using i2s
<ckie>
but.. maybe I can overclock the i2s interface!
<geist>
is this the newer esp32s with riscv or the xtera ones?
<acidx>
esp32-c3 are the risc-v ones
<geist>
yah i have a few, need to fidde with more
<ckie>
xtensa (perhaps unfortunately)
<geist>
i think they're fine, just a bit off the beaten path
<ckie>
you have to get the ISA reference from a person who breached their probably-NDA
<acidx>
yeah, xtensa is alright. kinda sucks in the tooling/compiler side of things, though, but that's because of how xtensa works.
<acidx>
ckie: it's not much better even if you have a contract with cadence :P
Vercas63 has joined #osdev
<ckie>
i have heard bad things
<ckie>
(but not very specific ones)
<ckie>
it'd be nice if there was an actual toggle bit instruction like x86
<acidx>
it's... hard to work with them
Vercas6 has quit [Remote host closed the connection]
Vercas63 is now known as Vercas6
<ckie>
currently resisting the temptation to throw esp-idf and freertos
<ckie>
[out, oops, early enter]
<ckie>
it'd be cool if it let me control the various clocks it's playing with manually
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
gog has joined #osdev
<ckie>
okay, I guess tomorrow or next time I work on this I'll be writing an assembler
dude12312414 has quit [Remote host closed the connection]
k8yun_ has quit [Quit: Leaving]
bauen1 has joined #osdev
smach has quit [Remote host closed the connection]
vdamewood has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
gxt has quit [Ping timeout: 268 seconds]
gxt has joined #osdev
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
FreeFull has quit []
smach has joined #osdev
eryjus has joined #osdev
zid` has joined #osdev
zid has quit [Ping timeout: 252 seconds]
_eryjus has joined #osdev
<_eryjus>
nick eryjus
nyah has quit [Ping timeout: 252 seconds]
eryjus has quit [Ping timeout: 252 seconds]
_eryjus has quit [Quit: _eryjus]
<zid`>
libera pls
scoobydoo has quit [Read error: Connection timed out]
zid` has quit [Ping timeout: 256 seconds]
scoobydoo has joined #osdev
ripmalware has joined #osdev
matt__ has joined #osdev
frkzoid has quit [Ping timeout: 244 seconds]
matt__ is now known as freakazoid333
spikeheron has quit [Quit: WeeChat 3.0]
zid has joined #osdev
zid has quit [Read error: Connection reset by peer]