<rqou>
fpgacraft(1) is gonna need a drama shield :P
<rqou>
fpgacraft2 will be vanilla
<lain>
:)
<lain>
I haven't run a modded server in a while, still running a vanilla (with forge for ircbridge) 1.10 on freebsd though
<rqou>
fpgacraft1 will be 1.7.10
<rqou>
:(
<rqou>
i'm going to run it with my personal magitech modpack
<rqou>
which _was_ dw20-inspired at one point
<rqou>
but then dw20 went the MOARPOWAH route
<rqou>
so now it's a ftb-retro-inspired-but-not-as-ancient pack :P
<rqou>
also you weren't here earlier to try to pop a shell on my laptop :P
digshadow has joined ##openfpga
<lain>
hehe
<rqou>
i was testing my custom irc bridge on freenode
<rqou>
(i needed an excuse to try asyncio)
<lain>
you could run hermitpack, it's 1.10 modded
<lain>
I've been enjoying etho's hermitpack series
<lain>
(if you wanted to go newer than 1.7)
<rqou>
>no buildcraft
<rqou>
:P
<lain>
ah
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
<rqou>
uh oh
<rqou>
that wasn't supposed to happen
fpgacraft2 has joined ##openfpga
<rqou>
hmm weird
<lain>
I wonder if my friend's potatore mod still works
<rqou>
also, 1.10 won't have the definitely-not-designed-for-borderline-aspie-nerds mod railcraft :P :P
<lain>
adds an ore that drops potatoes
<lain>
ahaha
<lain>
railcraft yeah, that one...
<lain>
rqou: do you have a no-bees rule yet? :x
* rqou
is not a railfan, rqou is not a railfan
<rqou>
i never played for long enough to have bees
<rqou>
they take forever to bootstrap
<lain>
I never got into bees
<cr1901_modern>
Is rqou a foamer :3?
<rqou>
also the bee system really conflates haploid/diploid in a weird way
<lain>
iunno what those words mean, and I'm ok with that
<rqou>
one vs two sets of chromosomes
<lain>
there was some mod we had in a custom pack, I forget what, but it let you like crawl around (you could crawl through 1x1 tunnels) and jump up and grab ledges and stuff
<rqou>
i'm actually considering banning quarries
<rqou>
lain: i had that at one point
<lain>
unfortunately it was really buggy when used with hat mod and some other stuff
<rqou>
it was called "smart moving"
<lain>
yeah!
<lain>
that's the one
<rqou>
afaik it's not updated and was also quite buggy
<lain>
yeah :<
<rqou>
iirc i was having problems with ic2
<lain>
it had some great stuff but it just didn't work right half the time
<lain>
would be neat if it worked
<lain>
rqou: are you adding mystcraft?
<rqou>
one of my friends who was using one of my much older packs found a neat trick
<rqou>
smart moving iirc didn't use forge
<rqou>
only modloadermp
<lain>
oh
<rqou>
and it activated on vanilla servers
<rqou>
:P
<lain>
lel
<rqou>
not all the movements were allowed of course
<rqou>
but the "climb two blocks" one does
<rqou>
also, no mystcraft
<lain>
awwweee
<rqou>
i don't want the server to oom every ten minutes :P
<lain>
lol
<lain>
what about pocket dimensions
<rqou>
i don't want extra dimensions in general
<lain>
ok :<
<rqou>
the world is already infinite you know :P
<lain>
mmmyeah, on several of my servers we had no-quarry rules for overworld, but you were allowed to make a quarry dimension
<lain>
another amusing one is ender quarry, it has a basically lag-free mode which replaces blocks with dirt (though you can add modifiers to replace with air or something else I think)
<lain>
if you're concerned about lag, ender quarry is a good choice to still allow quarries
<rqou>
in general i want to ban "too magical" blocks and egregious sploits
<lain>
ah :)
<rqou>
e.g. iirc i have to turn mfr biofuel off
<rqou>
because it oredict matches forestry biofuel
<rqou>
but it's much cheaper to make
<lain>
will you have ME storage?
<rqou>
i really don't like ae
<rqou>
it feels like a "look, i just took an algorithms/data structures class" mod
<rqou>
i can't believe how long it took the ecosystem/ideas to develop to the point where someone would even try the ice nuclear reactor
<rqou>
i assume you know what i'm referring to?
<lain>
nope
<rqou>
do you remember the old ic2 nuclear reactor?
<lain>
we used big reactors mostly iirc, and before that on Voltz we used uhh... fusion power
<lain>
nope
<rqou>
in the old ic2 nuclear reactor, you could alter the reactor temperature by placing in "single use coolants"
<rqou>
e.g. a bucket of water or an ice block
<rqou>
this is great until someone realized that if you managed to feed ice into the reactor fast enough, you could fill all but ~9 slots of it with uranium
<rqou>
and fill the rest with ice
<rqou>
and the reactor would produce a ludicrous amount of EU
<rqou>
originally, there wasn't really a way to make ice blocks like that
<lain>
hah
<rqou>
but then rp2 made it so that block breakers could collect snow from snow golems
<rqou>
so if you fed a bank of ic2 compressors with an array of snow golems, you could make enough ice
<rqou>
in the meantime, equivalent exchange was being worked on/refactored again
<rqou>
and ice gained an EMC value
<rqou>
...of 1
<lain>
ehehe
<lain>
equivalent exchange is so OP
<rqou>
so people would take a single EMC collector thingy and make it generate ice blocks to continually feed the ic2 reactor
<lain>
for one of our worlds I actually used wolfram mathematica to compute the best big reactors turbine configuration :x
<lain>
with fusion power in Voltz, if you mess up, it explodes and irradiates everything nearby
<lain>
which is really nasty to clean up, and you lose a LOT of valuable resources
<rqou>
hmm i hope binnie's mods 1.7.10 still works
<lain>
that felt like an acceptable balance, because it meant: a/ you had to work to maintain the thing, and b/ you usually had to transport power and materials over great distances, because you don't want that thing anywhere near your base :P
<rqou>
it hasn't been updated in a while
<lain>
rqou: how about thaumcraft?
<rqou>
yes, i quite like the idea of thaumcraft
<lain>
thaumcraft is fun
<rqou>
great, it doesn't work
<rqou>
there's a meta-mod to fix it
<rqou>
:P
<rqou>
that's how ecosystems are supposed to work
<lain>
haha
<lain>
yo dawg, I herd u liek mods
<rqou>
also, thank god java got rid of permgen
<rqou>
otherwise modded minecraft regularly exceeded the default permgen allocation
<lain>
rqou: whatever mod provides slime boots and slime sling, those items are hilarious (though a bit OP)
<rqou>
modded minecraft has a ludicrous number of classes
<rqou>
according to my roommate: "yeah, normal enterprisey java projects usually _start_ with a huge number of classes, but they don't usually get more"
<lain>
haha
<rqou>
unlike modded minecraft where minecraft and each individual mod has about as many classes as a mid-enterprisey java project :P
<rqou>
btw minecraft (vanilla) runs fine on tegra x1 (aarch64)
<rqou>
even hits 30fps
<rqou>
and this isn't the pocket edition bullshit either
<lain>
nice
<rqou>
you have to screw around with a "very java" build system to try and build aarch64 natives for lwjgl though
<rqou>
i hate java build systems
<rqou>
correction, i hate all build systems
<rqou>
but java ones are particularly bad
<lain>
lol on my laptop I was playing vanilla on the 3k internal display, at 3k, wondering why it's only like 15fps ... turns out it was using the integrated intel graphics, not the quadro >_<
<lain>
switched it to quadro and it was like vroom
<rqou>
also, lwjgl's build system iirc thinks it's really clever and understands multilib
<rqou>
only for x86_64/i386
<rqou>
aarch64/armhf doesn't work
<rqou>
great, my chat gets spammed with a "codechickencore.update" every time i log in
<rqou>
it's bugged twice
<rqou>
a) this is already the latest version for 1.7.10
<rqou>
b) the message isn't localized properly
<rqou>
actually remembering to copy files into mods/ helps :P
<lain>
:D
<lain>
oh oh
<lain>
will you have that one mod where you can mail other players? :P
<lain>
it also has a trading system iirc, where you can offer items in exchange for other items, which is handy
<rqou>
i'm trying to remember what mod that is
<rqou>
iirc it was an incidental feature of a bigger mod
<rqou>
i think that's actually part of forestry
<lain>
hmm yeah
<lain>
looks like it
<rqou>
also, apparently forge fluids now know now to replace other fluids
<lain>
whenever this resilver finishes, the array will no longer be degraded.
<lain>
great success
<rqou>
i should upgrade my "nas" at some point
<rqou>
getting ecc ram on it would be nice
<rqou>
the current NAS is a celeron j1900+wd red
<rqou>
very advanced hw :P
<rqou>
apparently all of the atom microarchitectures suck
<lain>
hehe
<lain>
this is an old desktop turned fileserver... core i7 920 with 6GB ram running freenas
<lain>
it works well!
<rqou>
my upgrade will probably be one of the skylake celerons with ecc ram
<rqou>
that someone at 33c3 mentioned existed
<rqou>
also broadwell-ep power efficiency is amazing
Ardeshir has joined ##openfpga
<lain>
yeah I'd like to move to ecc
<lain>
aside from the mobo I'm currently designing, I don't intend to build any more systems without ecc
<lain>
with the possible exception of a gaming rig, since I don't think you can get unlocked multiplier xeons? I dunno
<lain>
although
<lain>
OCing probably also isn't necessary if I go with a modern xeon anyway :P
<rqou>
iirc there's no unlocked multiplier xeon
<rqou>
but OC + ECC doesn't make sense anyways
<lain>
apparently there were some in the past
<rqou>
i don't play too many AAA titles that require ALL THE GHZ anyways
<rqou>
for most other purposes more cores is more useful
<lain>
there's only one game I play for which it matters
<rqou>
minecraft? :P
<lain>
lol
<lain>
ghost in the shell: first assault
<rqou>
but can it run crysis? :P
<lain>
it will get around 150fps on my core i7-2600, but that's a lie because it framedrops and stutters a ton
<lain>
their engine is awful
<lain>
but it's purely cpu bound, my gtx970 has no issues with it, it's all cpu
Ardeshir_ has joined ##openfpga
<lain>
bumping up bclk on my board improved it dramatically, but it became unstable so I had to drop it back down :P
<rqou>
btw the other day when i made a "can it run crysis" joke to my roommate...
<rqou>
he pointed out that crysis came out 9 years ago
Ardeshir_ has quit [Remote host closed the connection]
<lain>
I refuse to believe this
<lain>
:P
Ardeshir has quit [Ping timeout: 240 seconds]
<lain>
but yeah, at max turbo my cpu is just not quite fast enough for this game
<rqou>
i don't understand why so many games are so poorly programmed
<lain>
it's playable but sometimes it gets really annoyingly bad and I have to just ragequit
<rqou>
don't they have, like, real development teams
<lain>
like it'll consistently stutter during critical aim
<lain>
and then I die
<lain>
a bunch
<lain>
and yeah I dunno
<lain>
the netcode for this game is also a joke, which is unfortunate because the game itself is really fun
<lain>
they've been improving it
<rqou>
how about the minecraft netcode? :P
<lain>
the game is from nexon in south korea, which I hadn't heard of until this... the running joke is that everyone in korea has fiber so the devs don't even understand what ping means :P
<rqou>
heh, nexon
<rqou>
i used to play maplestory in a previous life
<rqou>
hence why you might have heard me mention gameguard
<lain>
there was a bug where if your ping was between like 40-150ms, you were basically god mode
<rqou>
my favorite maplestory cheat was the "client side EAX hack"
<lain>
so naturally euro players all join US servers and vice-versa
<lain>
and just start murdering everyone
<rqou>
(which was finally fixed years ago after a few years of it existing)
<lain>
because at that ping, your hitbox would lag behind or sometimes travel in front of your character on screen
<lain>
and it was impossible to predict which one it was at a given moment
<rqou>
that sounds like a nexon game :P
<lain>
and also you could shoot through corners / walls and cheat death
<rqou>
anyways, the maplestory "client side EAX hack" was:
<rqou>
you would apply a patch at a particular location in the code and set EAX to a constant
<lain>
basically the effect was: if someone with terrible lag shot you, their hit counted before any of your hits on them counted, so even IF you killed them, that wouldn't count, because the server would replay it as them killing you first :P
<rqou>
in this context, EAX is the x-coordinate of a mob
<rqou>
so on your screen, all the mobs on the map would be in a single column constantly
<rqou>
then you just spam AoE attacks on it
<rqou>
and then your client tells the server "I hit this mob"
<rqou>
and the server says "OK"
<rqou>
:P
<lain>
rofl
<rqou>
everybody else sees mobs just getting magically attacked
<lain>
client-side hit detection is cancer
<rqou>
for bonus points, there was a "server side eax hack" at various times
<rqou>
that actually had nothing to do with eax
<rqou>
but it essentially looked the same as the client side eax hack except for all players
<lain>
hahaha
<rqou>
i don't know how it worked, but essentially the client could convince the server that mobs had moved
<rqou>
how is that even possible?
<lain>
early on in the gits game, there was a bug in the code... like ok, you know how... when a player experiences packet loss, the client or server has to predict their movement (because standing still is boring?)
<lain>
so their initial code just assumed constant velocity in the same direction as the last movement update
<lain>
except
<lain>
it...
<lain>
they somehow managed to calculate it wrong, so instead of the same velocity they were previously moving at, it was always faster than that by some constant amount
<lain>
so if someone was experiencing wicked packet loss, or using a lag switch........
<lain>
they would appear to be one place
<rqou>
wtf
<lain>
but in reality, they would be somewhere else
<lain>
if they're running STRAIGHT at you, it's fine of course, but if they're zig-zagging like they should, they become unhittable :P
<lain>
they did patch that early on though, but god it was annoying
<rqou>
another hilarious maplestory hack:
<rqou>
at some point nexon finally decided to clean up the most egrigious hacks
<rqou>
like "god mode"
<lain>
once you knew, you could sometimes notice when someone was lagged because they'd be traveling in some direction, then warp back a bit, etc... and you'd know to aim slightly *behind* them to hit them
<rqou>
which was promptly substituted for "miss mode"
<rqou>
:P
<lain>
hahaha
<rqou>
which was iirc also fixed
<rqou>
and then replaced with "damage of 1 mode"
<rqou>
it's almost like the maplestory devs didn't think at all about "what if the client is lying"
<rqou>
actually wait
<rqou>
they did
<rqou>
the client has a "text segment crc" command
<rqou>
so the prerequisite code patch before you can apply any other patch
<rqou>
is to take a dump of the text segment with no patches applied
<rqou>
then find the crc function
<rqou>
and patch it to read from the dump you just saved :P
<lain>
rofl
<lain>
that's kind of like the lmtools thing I looked at a while back, some software I use requires a dongle, I kept forgetting it, so I wanted to bypass the dongle check... they delegate all the lmtools interaction to a single dll, which isn't signed, so I found the signature verification function for the license file entries...
<lain>
I figured I'd replace the signing key with one of my own, and just re-sign it as a MAC-locked license file and leave it at that
<lain>
but IDA choked on the (obviously algorithmically generated) pile of small functions used to deobfuscate the pubkey from the binary
<rqou>
ah, so it's at least one of the "new" ECC license keys? :P
<lain>
yeah
<rqou>
"new" = more than 5 years at this point
<lain>
that code pulled out all the stops lol, it was self-modifying, it had thousands of tiny functions so IDA refused to even try to graph it, etc
<rqou>
not one of the bullshit NIH symmetric key ones :P
<lain>
so I'm like well let's see
<lain>
there's ONE signature verification function
<lain>
so rather than changing the key, I'll just mov eax, 1; retn
<lain>
yeah that works.
<lain>
of course that meant patching all N different versions of the dll because this software is split up into like 20 different actual programs, each of which has its own copy of the dll
<rqou>
i can't find it anymore, but at one point i found a streamlined tutorial for pulling symmetric keys from flexlm
<lain>
but none were signed and all were similar enough that once the first one was done, it only took maybe an hour to do the rest
<lain>
haha
<rqou>
it involved finding a particular pattern that was iirc a prng of some kind
<rqou>
and patching it to return 0
<rqou>
and then finding a different function that mangles the internal keys
<rqou>
but when the prng returns 0 no mangling happens
<rqou>
so then you look on the stack or whatever and the keys are there
<rqou>
plug them into a flexlm sdk leak and recompile lmcrypt
<rqou>
done
<rqou>
:P
<lain>
nice
<lain>
yeah I did manage to extract the pubkey from memory
<lain>
but obviously I wasn't going to find a matching privkey in this lifetime
<rqou>
right, because EC
<rqou>
not like gameguard's old rsa512 key :P
<lain>
and without knowing the deobfuscation sequence, it was a lot easier to just patch out the function altogether
<lain>
lol yeah
<rqou>
they now have an rsa2048 key
<lain>
I saw support for some rsa512 keys in the lib
<lain>
but they weren't used
<rqou>
afaik it's because when I did a google search for the modulus i found some chinese forum posts talking about it
<lain>
lol
<rqou>
i assumed some gold farmer or whatever also factored the key
<lain>
I would love to see what horrors lie in gits netcode
<lain>
but I don't have time to wrestle with themida
<lain>
aka BlackCipher.aes
<rqou>
for some reason xor crypto is really popular in vidya
<rqou>
oh god themida still exists?
<lain>
the entire game and assets are encrypted
<lain>
it's decrypted in ram and only runs as admin
<rqou>
i somehow got the impression all pe packers disappeared when "cloud" happened
<lain>
well, it's more evil than that
<lain>
it uses... what's it called... malbolge or something
<rqou>
themida no longer uses a kernel driver though, right?
<lain>
don't think it uses kernel driver, no
<rqou>
it used to outright patch the IDT and used that as part of the unpack sequence
<lain>
malbolge is a vm using opcodes designed to be almost impossible for humans to understand, and the opcodes are randomized for each build
<lain>
the entire decryption routine is obfuscated and written in malbolge bytecode
<lain>
it's madness
<lain>
I mean it's totally crackable it's just going to take a lot more time than I care to invest
<rqou>
that's quite different from old themida i read about
<lain>
ah
<lain>
yeah this was pretty good
<rqou>
why do pe packers still exist?
<lain>
nevertheless, cheats exist for the game, so clearly someone is familiar with it
<lain>
the game also detects if it's virtualized and refuses to run
<lain>
though it doesn't seem to mind amazon ec2 or hyper-v
<lain>
it ragequits under vmware
<lain>
iirc vmware has a way to debug apps in the guest, from the host, so that's probably why
<lain>
that would be a great way to dump the game
<rqou>
um, so can hyper-v or kvm
<lain>
hrm
<rqou>
not easily though
<lain>
I thought hyper-v's stuff was undoc'd and internal to MS?
<lain>
I know it /exists/ but...
<rqou>
it's probably some stupid thing poking the vmware extensions
<rqou>
and can't detect vt-x
<lain>
right
<lain>
it's just doing some dumb heuristics I'm sure
<rqou>
because ideally other than timing you can't detect a perfect vt-x hypervisor
<lain>
but now that things are paravirtualized you can probably detect by looking at pci devices and such
<lain>
also just in general, pci device names and whatnot
<rqou>
iirc (on new enough intel) even rdtsc traps
<lain>
"VMWARE DISK CONTROLLER" or whatever
<rqou>
red hat virtio scsi? :P
<lain>
haha
<rqou>
but a vt-x h4x0ring debugger can use vt-d to pass through all host devices
<rqou>
the only visible difference might be some ram carveouts
<lain>
hmm
<lain>
I should look into dumping it from a vm
<lain>
I don't care to modify the code, I just want to see it :P
<rqou>
one project (very far in the future) that i wanted to build was a fpga on a dimm
<rqou>
intercepting all the memory
<rqou>
i'm sure that will lead to really insane hacks
<rqou>
you can basically bypass any software protection at that point
<rqou>
afaik you can even get me code exec by doing this
<lain>
yeah
<lain>
I've wanted to do that also
<lain>
on this intel mobo I'm designing, I'll have jtag and trace on the cpu
<lain>
I'm wondering if that's helpful for this sort of thing
<rqou>
it's pointless, but doing such a ram intercept on the vita would be neat
<rqou>
the psvita has either PoP ram or even ram in the same package as the soc
<rqou>
but it's a separate die obviously so you can actually still tap it if you're very 1337
<lain>
:3
<lain>
this intel mobo is going to be fun, I need to get it done :D
<rqou>
i want somebody to reverse engineer some more fsp blobs
<lain>
after this one, I'd like to make one for a proper powerhouse of a laptop, and then a xeon server rig
<lain>
gradually increasing difficulty
<lain>
that's a long way out though
<lain>
even if this hardware mostly works on the first spin, firmware dev is going to take a while :P
<rqou>
not just "dump coreboot+fsp on it?"
<lain>
I'm planning to build some customization on top of tianocore
talsit has joined ##openfpga
<rqou>
ugh why
<lain>
why not?
<rqou>
i never understood what the point of uefi was
<rqou>
it doesn't seem to actually solve any problems
<lain>
oh I completely disagree :P
<lain>
having dealt with hundreds of bioses over the years, bios needs to die a death
<rqou>
why can't the firmware just get the heck out of the way so that the os can do its job?
<rqou>
e.g. coreboot+grub2
<rqou>
why does my firmware need a whole OS+platform?
<lain>
I don't understand the complaint: uefi on a modern system is only executing for milliseconds
<rqou>
doesn't it have runtime services?
<rqou>
also, why all the complexity just to execute for milliseconds?
<lain>
uefi *can* be a lot more, but...
<lain>
most manufacturers fuck up their impl.
<lain>
and that's why it seems awful :P
<lain>
uefi itself is very good imo
<rqou>
uefi seems great for causing fun issues like "my boot is waiting for my network card to do *something*"
<rqou>
and then hanging for 30 seconds
<lain>
this is also why I'm doing my own though, I'm tired of noncompliant uefi's, shitty firmware, shitty mobos, etc
<rqou>
(yes this happened)
<rqou>
this was "fixed" by updating my option rom
<lain>
lol
<lain>
wow
<rqou>
idk why this even exists in the first place
<rqou>
the workaround option is "enable the CSP"
<rqou>
:P
<rqou>
apparently when the CSP is enabled the option rom does something different
<lain>
if you really dig in, most bios/uefi implementations are checked to see if they boot the latest windows installation disc
<lain>
if they do, they ship it
<lain>
that's sorta the bulk of the testing :P
<lain>
linux has a crapton of hacks to pretend to be windows as a result
<lain>
places where the bios/uefi does standards-violating things, but hey, it boots windows so who cares
<lain>
:|
<rqou>
why does uefi need all of its complexity and NIH though?
<rqou>
why can't i e.g. use coreboot+linux as the firmware
<rqou>
and to boot windows or another linux just use kexec
<lain>
it's not *that* complex compared to a reasonably featureful bios
<rqou>
why does my bios have features?
<lain>
well you'd like to be able to change bios options
<lain>
so that's some UI
<rqou>
other than the boot order i don't think i've ever changed any other options more than once ever
<rqou>
and that's only because the defaults were dumb
<rqou>
like "HPET disabled"
<lain>
sure, but you may have changed them at least once, and how would you do that otherwise?
<lain>
btw there's a way to change uefi variables without the uefi providing a UI, bios doesn't have this same concept afaik
<rqou>
just don't? allow the OS to turn the HPET on?
<lain>
ehhhh
<rqou>
i suppose only linux really knows how to do that
<rqou>
because of too many broken bioses
<lain>
the problem is these options you find in the bios require platform-specific knowledge, and possibly platform-specific code
<lain>
this is handled by ACPI for example
<lain>
the bulk of the complexity is in fact ACPI stuff, afaik
<lain>
this applies equally to bios and uefi
<rqou>
all i know about what acpi does is that it makes some developers sad and causes laptops to have bugs :P
<lain>
and also most of your bugs probably come from shitty ACPI code
<lain>
lol
<lain>
yeah I've learned a lot about it
<rqou>
and you fuck around with it to make hackintoshes
<lain>
sooo you know how embedded devices usually use something like uhh.. what's it called, device tree shit
<lain>
to tell the *nix OS what's available, so it knows which drivers to load
<lain>
peripherals and whatnot
<rqou>
idk because last time i looked at kernel stuff DT only existed on PPC
<rqou>
ARM was full of "board file" crap
<lain>
yeah so linux and freebsd these days use FDT, flattened device tree
<lain>
or they use boards that provide uefi firmware
<rqou>
there was a "mach id" in a register (r2?) way back in the day
<lain>
with fdt, you've got a tree of devices and info on how the OS should map drivers to each
<rqou>
i don't really see the advantage though
<lain>
acpi is like the bios/uefi device tree, but it also provides services -- for example, maybe your platform provides an ambient light sensor or a pile of thermal sensors...
<rqou>
old way: write a .c file with all the random shit about hardware
<rqou>
new way: write a .dts file with all the random shit about hardware
<lain>
acpi tells the OS those exist, and how to talk to them, and may even provide functions for accessing them which contain platform-specific code
<lain>
so it provides a stable api surface that any OS can code against
<lain>
that's the purpose
<lain>
I can run windows, freebsd, openbsd, linux, wtfever
<rqou>
why can't you just put the code in the OS instead?
<lain>
because then I have to write it N times
<lain>
for supporting N different OSes
<rqou>
old way: you have to RE the hardware for each OS
<rqou>
new way: you have to RE the acpi bugs for each OS
<lain>
well
<lain>
that's not an ACPI problem
<lain>
that's a vendor problem
<lain>
ACPI is fine, vendors are dumb
<rqou>
i suppose i can agree with that
<lain>
anyway I'm of the strong opinion that a clean API like that is important for firmware, but I do think most vendors do it so wrong that it's hard to see the benefits :P
<rqou>
so does acpi actually provide a mechanism to "magically" run code under to OS?
<rqou>
or is acpi code all OS-driven?
<lain>
acpi can provide function calls which contain vendor code, that the OS can call into
<rqou>
but they're all AML or whatever, not native code?
<lain>
hmm I think so, I'm not sure on the specifics actually
<lain>
what would be nice is to replace the Intel ME stuff with an open alternative, but... long way away...
<rqou>
so e.g. if i'm running on <your favorite crappy cheapo laptop with a broken as hell ACPI+EC> i can write a driver that just says "screw what ACPI says, i'll just poke the hardware directly"
<lain>
hm
<rqou>
that should be possible, right?
<lain>
I would think so, as long as you have the information necessary to do that
<rqou>
i bet there are some shitty laptops that have an i2c als or whatever that's wrapped by some shitty acpi
<lain>
lol
<lain>
yes
<rqou>
talking to the pch i2c might be simpler in the end
<rqou>
so question: all those hackintosh dsdt hacks
<rqou>
do they really work?
<rqou>
some of them seem to e.g. try and change interrupt routing
<rqou>
can you actually do that? or is it just tricking the os?
<lain>
now we're beyond my knowledge :3
<rqou>
tangential question: why does hd audio suck so much?
<lain>
I'm sure once I'm bloody, beaten, and bruised and on the other side of firmware bringup on the board, I'll be able to answer a lot more questions
<rqou>
hd audio also has a giant pile of hacks and quirks
<rqou>
e.g. linux always turns on the spdif light on my mac and i don't know how to turn it off
<rqou>
it occasionally does turn off though
<rqou>
so somewhere between the random gpio pin and pnmixer the information got lost
<rqou>
somehow
<rqou>
<troll>just route it into the linux led framework</troll>
<lain>
I was going to include an HDA codec in my board, but I opted to use the built-in "LPE"
<lain>
Low-Power Engine
<lain>
which is some DSP that spits out i2s, then I'm running that to a da7219
<rqou>
this exists?
<lain>
it's built in to the soc I'm using
<rqou>
this? "Audio device: Intel Corporation Haswell-ULT HD Audio Controller"
<lain>
(Apollo Lake, specifically Penium N4200, which uses an Atom core)
<lain>
iunno
<lain>
it's just called LPE in the docs, the DSP runs some proprietary blob which I'd like to reverse
<lain>
it can do things like mp3 encode/decode and dma, so you can playback while the cpu is sleepy
<lain>
which is nice for portable devices
<rqou>
i have another thing for you to reverse (more):
<lain>
well, I have access to the datasheet, so...
<lain>
:P
<rqou>
oh really
<rqou>
leak? :P
<lain>
I have an NDA
<lain>
sorry nope :P
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<lain>
I've convinced them to let me release all my designs fully open source, firmware, drivers, schematics, pcb layout, etc
<rqou>
alright, how about some hints for a (very) future RE project?
<lain>
haha
<rqou>
the physical layer signalling
<rqou>
is it the same as pcie/usb3?
<lain>
I haven't looked at thunderbolt
<lain>
but I would guess it's very similar
<lain>
IP reuse seems obvious
<rqou>
because if it's similar then i can just do TB->FPGA
<lain>
are there linux drivers available?
<lain>
intel is usually good about publishing linux drivers for stuff
<rqou>
also, i have to check the signaling levels, but a trolly thing to do would be TB->SFP+
<lain>
haha
<rqou>
now i really have optical thunderbolt :P
<rqou>
also, no drivers because apple or something
<rqou>
the existing driver is from RE
<lain>
ah
<rqou>
afaik chaining doesn't work
<rqou>
anyways, i've been told that sfp+ devices in general accept whatever bullshit ac-coupled signals you feed it (within the passband)
<rqou>
so e.g. sata can be fed into a sfp+
<lain>
handy
<rqou>
i've also been told that some 8g infiniband sfps overclock to 10g ethernet speeds
<rqou>
apparently the "normal" way to do thunderbolt is to have smm and/or acpi hide everything
<rqou>
and then make it just "magically" show up as pcie hotplug
<rqou>
this seems to be a pretty ugly approach
<lain>
I wish thunderbolt was different
<lain>
there's so many things I could build to take advantage of that kind of bandwidth
<rqou>
it is different(TM)
<rqou>
that's why you can use it to mount dma and option rom attacks :P
<lain>
I mean sure I could make them pcie cards, but that doesn't help me when I'm in a car or somewhere with a laptop
<lain>
lol yeah
<lain>
provided the iommu isn't properly configured
<lain>
but nobody thinks of these things :<
<rqou>
also, i like to trollingly call firewire "thunderbolt 0" :P
<rqou>
it even has the same footguns
<rqou>
:P :P
<rqou>
also, dma attacks were actually used to dump the iphone bootrom recently
<rqou>
apparently the iphone doesn't have an iommu or something
<lain>
ah yes
<rqou>
but it has a nvme flash
<lain>
I remember seeing that
<lain>
heh here's a fun fact
<lain>
so you know usb isn't a switched fabric
<lain>
it's a bus
<rqou>
at least usb2 is
<rqou>
idk about 3
<lain>
right
<lain>
idk about 3 either
<rqou>
3 is weird
<lain>
iphones have usb2 on the dock port
<lain>
when I re'd the flir one, I hooked a usb analyzer between the iphone and the flir one to capture packets, then wrote software to talk to the flir one from a pc
<lain>
well
<lain>
in those packet captures I also noticed network packets going out the dock port
<lain>
I think they were destined for the internal wifi or cell modem
<lain>
but since usb is bus....
<lain>
they were just flying out the dock port
<rqou>
wow
<lain>
of course you can't see the replies going upstream to the soc
<rqou>
but you can't inject anything, right?
<lain>
but you can see everything the soc is sending out
<lain>
you could likely inject
<lain>
but I didn't try
<lain>
it's something I'd like to explore more in the future, but usb2 will probably become irrelevant before I get around to it :P
<rqou>
do you know if it's possible to bring up a usb3 connection without the usb2 pins?
<rqou>
i know the spec doesn't allow that
<rqou>
but the usb spec says a lot of things
<lain>
the spec allows that for built-in devices, but not for anything exposed to the user
<rqou>
very little of which seems to be followed
<lain>
I don't know if *drivers* typically support it
<rqou>
oh really?
<lain>
yes
<rqou>
that's neat
<lain>
they explicitly allow it for things like expansion cards or internal flex connections or on-board stuff
<lain>
but it's not allowed for anything that has an actual usb port :P
<rqou>
note to self: actually read specs sometimes :P
<lain>
hehe
<rqou>
i remember reading (from the official spec) a fun requirement that otg devices may only have one otg port
<rqou>
i wonder what type of footgun that is intended to prevent?
<rqou>
plugging a pda into itself?
<lain>
hahahaha
<lain>
oh gods ok
<lain>
dude
<lain>
so usb3 type-c, right, it goes both ways (giggity)
<lain>
the connections are duped top and bottom and then an analog mux is used to flip which side the usb3 signals go to
<lain>
this also means you have twice as many high speed connections as you need, which is how you can do displayport alternate function for example, where you have several displayport data lanes, and then the aux line goes out over the low-speed lines in the type-c connector
<lain>
anyway
<lain>
type-c is neat shit, but there's a really really really stupid thing in the spec
<lain>
so you know type-c has the same connector regardless of what it is. alternate functions like type-c to displayport or hdmi or etc are identified electronically over CC (control channel), a low-speed thing that lets a cable identify wtf it is, or lets the devices negotiate wtf they are before they bring up any high speed lanes
<lain>
so they can mux them to the appropriate shit first
<lain>
WELL
<lain>
let's suppose you have a usb type-c dual-role port (DRP), so it can be host or device
<lain>
and you connect that to another DRP
<lain>
which one is the host?
<rqou>
old way was to use HNP
<rqou>
with involved some weird hacks involving injecting current into vbus
<lain>
haha
<lain>
soooo
<rqou>
iirc this moved to a less-dumb CC signalling?
<lain>
this is so dumb
<lain>
the way it works is a given device will, every N milliseconds or whatever, I forget, switch between behaving like a host and a device
<lain>
and the spec actualy says
<lain>
get this
<lain>
the spec actually says
<lain>
you are encouraged to use something like an RC oscillator for this
<lain>
which will drift
<lain>
not a crystal
<lain>
because otherwise
<rqou>
wut
<rqou>
that's stupid
<lain>
you might get into a situation where the two clocks are close enough to synchronized
<rqou>
i would rather inject current into vbus :P
<lain>
that they never settle into a condition where one is host and one is device
<lain>
SO STUPID
<lain>
I mean ffs
<lain>
ethernet mdi-x solved this
<lain>
auto mdix solved this years ago
<rqou>
just run sgmii over an alt function :P
<lain>
haha
<lain>
you *can* run eth over alt mode lol
<lain>
straight-up ethernet signalling over usb type-c port
<lain>
but yeah
<lain>
so dumb.
<rqou>
wait, i thought the impedance wasn't the same
<lain>
HOWEVER
<lain>
you are allowed to provide a software/firmware mechanism to force the device into a given mode
<lain>
so at least there's that :P
<lain>
impedance is close enough
<rqou>
does type-c define a mechanism to back-compat with the old HNP/SRP?
<lain>
what's SRP?
<lain>
I never really looked at the old otg stuff
<rqou>
session request protocol
* lain
doesn't know
<rqou>
does *anybody* implement oldschool otg properly?
<lain>
probably not
<rqou>
except possibly TI?
<rqou>
on their calculators? :P
<lain>
for usb2 compat, it's likely going to be a function of the cable's electronic identifier
<rqou>
can the identifier somehow signify "usb type c to usb micro ab otg" or is that not allowed?
<lain>
speaking of misc-shit-over-type-c, my mobo has sata over type-c :P
<lain>
I dunno, I'd have to check
<rqou>
because doing that makes you need to support oldschool hnp/srp
<lain>
it can support uhhhhh
<rqou>
btw ti calculators really do support hnp
<lain>
what's that signalling... VBUS signalling
<rqou>
goddammit
<lain>
where power adapters did signalling over vbus
<rqou>
that is the oldschool crap
<rqou>
or wait
<lain>
but now that's moved to CC
<rqou>
that's not the same oldschool crap i was thinking of :P
<lain>
ah
<lain>
yeah I'm talking about like, I forget what, BPSK or some silly thing over VBUS
<rqou>
apparently there are multiple different "oldschool crap" :P
<rqou>
i've never heard of that one
<lain>
to comm between a power adapter and a device, for negotiating higher voltage or current
<lain>
tablets use this often
<rqou>
i know there's the "short D+/D-" one
<rqou>
and the "put an apple-proprietary voltage on D+/D-" one
<lain>
usb type-c moves this to CC, but for a legacy cable it can still work over vbus if both ends support it
<rqou>
i assume this means that you're free to support oldschool hnp/srp as well then
<rqou>
so all two users can rejoice!
<lain>
this is how eg. usb type-c supports 100W
<lain>
you can request up to 5A at 20V
<lain>
:D
<lain>
assuming the cable advertises support for this, which it shuold only do if the wiring is capable of carrying 5A
<rqou>
i remember the "old" PD spec was just "short D+/D- for 500mA"
<lain>
yeah
<lain>
then it evolved to support BFSK signalling over VBUS
<lain>
and now it supports CC
<rqou>
not that those usb light bulbs or whatever ever checked that :P
<rqou>
the modern usb testing matrix must be insanely huge
<lain>
in both BFSK over Vbus and CC cases, the comms are done by exchanging packets, it's a pretty interesting system
<rqou>
but fortunately this means that i can plug my modern usb3 hub into my old ppc mac and it still works
<lain>
and in fact that packet system is what CC uses all the time
<rqou>
(yes, i actually tried)
<lain>
you can have vendor-defined CC packets too
<rqou>
(even the asix ethernet driver worked)
<lain>
haha
<rqou>
this was running debian ppc, not os9/osx
<rqou>
os9/osx don't have asix drivers for some reason :P
<lain>
HMM
<lain>
:P
<rqou>
especially os9 :P
<rqou>
hmm apparently asix was founded in 1995
<rqou>
so os9 doesn't actually predate them existing
<rqou>
os9 is actually a neat os
<rqou>
held together by an amazing amount of duct tape
<rqou>
(also, it was using devicetree before it was cool :P )
<lain>
haha
<lain>
I hate devicetree tbh
<rqou>
i just don't see how it solves any problems
<lain>
devicetree?
<rqou>
yeah
<lain>
you don't know what devices a modern soc has without something like devicetree or a firmware to tell you (via acpi or etc)
<rqou>
you still have to write the drivers for everything
<lain>
you can enumerate buses like pcie, but you don't know where registers for memory-mapped devices live
<rqou>
you just turned a crap .c file into a slightly-less-crap .dts file
<lain>
or what is where
<lain>
and you can't enumerate that
<lain>
you *have* to have some kind of specification
<rqou>
but the old crap .c file did specify things
<lain>
a C file would be specific to a certain OS or build or API, a devicetree is, in theory, standardized (but I have yet to see any standardization in practice)
<lain>
sooo I can't really disagree
<lain>
it's crap :P
<lain>
well ok
<lain>
in most cases the bootloader (u-boot, usually) is the thing holding the device tree
<lain>
and it loads it into mem and passes a pointer to the OS
<lain>
kernel
<rqou>
it is?
<lain>
on some of the embedded systems I've worked with yeah, at least for freebsd
<rqou>
ime the device tree was always just another file that sat right next to the kernel
<lain>
I haven't done linux embedded so I don't know if theirs is the same
<rqou>
so u-boot would load some script file thing from a fat partition
<rqou>
that also has a kernel, devicetree, and initrd
<rqou>
so i don't see how you gained much by moving the "information about devices" from the kernel file to the devicetree file
<rqou>
they're both files in the exact same place
<lain>
hm
<lain>
because you can run the same kernel without having to compile it for a specific device?
<rqou>
i thought you could already do that using the "mach id"
<lain>
ah, I dunno
<lain>
never heard of that
<rqou>
The boot loader should detect the machine type its running on by some
<rqou>
method. Whether this is a hard coded value or some algorithm that
<rqou>
looks at the connected hardware is beyond the scope of this document.
<rqou>
The boot loader must ultimately be able to provide a MACH_TYPE_xxx
<rqou>
value to the kernel. (see linux/arch/arm/tools/mach-types). This
<rqou>
should be passed to the kernel in register r1.
<lain>
ok, so basically the kernel has the device tree in some C files I guess, for each mach id, and just loads the appropriate tree
<lain>
although
<lain>
step 4b says to load the dtb
<lain>
ah, optional, okay
<rqou>
the old way afaik was a .c "board file" that contained random ad-hoc shit to initialize a board
<rqou>
the new way is to just skip all that and pass a dtb
<lain>
hmmm my guess then is the linux kernel doesn't want the responsibility of holding not only device drivers, but also platform-level specifics for every board in existence
<rqou>
but you still do in the form of dts source files
<lain>
but those aren't mainline I thought?
<lain>
those are just distributed by the vendors afaik?
<lain>
also this means adding a new board doesn't necessarily require rebuilding the kernel
<lain>
(assuming drivers for all the peripherals exist or can be loadable modules)
<rqou>
but a new board very likely includes a new soc and or random i2c thing
<rqou>
which needs a new driver
<lain>
I suppose, yeah
<rqou>
also, every vendor needs to add at least one shitty blob :P
<lain>
haha
<lain>
it's like an unwritten rule
<lain>
and don't forget vendor blobs must include at least one ring 0 privesc vuln, preferably exploitable from userland
<lain>
doubly so if the vendor is unwilling to patch said vuln
<rqou>
preferably exploitable by writing to a 0666 file in /sys
<rqou>
*cough* *cough* allwinner
<lain>
hehehe
<rqou>
although that wasn't a blob
<rqou>
waiting for a vendor (other than qcom) to have an el3/tz vuln
<rqou>
:P
<lain>
hehe
<lain>
so here's a question
<lain>
saw something recently where journalists are calling for camera manufacturers to add encryption support, to "protect them" when they're photographing in, for example, oppressive regimes or whatever
<lain>
I cannot for the life of me figure out why encryption would help
<lain>
I imagine the scenario is: people stop journalist, people take camera, destroy memory card, escort journalist out :P
<lain>
maybe I've got it wrong
<lain>
even if there was a scenario where they would check the camera for any "unapproved" images and let the journalist leave as long as all the images are "acceptable," that still seems like a matter of hiding data rather than encrypting it. if there's images that come up with "oh you need to enter a passcode to view this," they're not going to walk away with that memory card I don't think :P
<rqou>
you can have something like truecrypt hidden volumes
<lain>
sure but I feel like that's a lot more than just "encryption"
<lain>
that's about the only thing I could see being useful though, for sure. if you both encrypted *and* hid the data
<lain>
but if a manufacturer advertised such a feature, everyone would then know about it, and if I were an oppressive border control person, I would just copy their images off, format the card, and then copy them back lol
<lain>
bye bye hidden data
<lain>
I dunno, it just seems like it's of little use. maybe I'm giving too much credit to these oppressive regimes or whatever the journalists are trying to combat
<cyrozap>
rqou: One benefit of devicetree is that you can have overlays, so you can tell the kernel about other devices connected to the SoC without having to even modify the board's dtb. The RasPi uses this for things like this: https://www.hifiberry.com/
<cyrozap>
Also, before devicetree, vendors would just add random junk to the kernel, making every board's kernel a special snowflake. I mean, many still do this, but now the vendors that aren't completely terrible can do things the right way, making it easier to swap out kernels/distros. Of course, that wasn't enough for some companies (RedHat), and now UEFI on ARM is a thing :P
<lain>
uefi :3
<lain>
rqou: so when can I join the modded minecraft server? :D
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
amclain has quit [Quit: Leaving]
massi has joined ##openfpga
<eduardo_>
Lain: I talked with two guys at 33c3. They try to do a SDcard with invisible an encrypted File storage directly on the SD card. (with an FPGA). So you dont need to adapt the Firemware of the camera.
clifford has joined ##openfpga
<eduardo_>
Lets see what will come out of this.
<cyrozap>
Regarding journalists asking for auto-encrypting cameras, I can't help but think of this: https://www.xkcd.com/538/
<jhol>
I don't understand the question? how would there more than one eye diagram per pair?
<cr1901_modern>
there are two wires per pair
<jhol>
right... but that's an eye digram of a differential signal
<jhol>
the voltage axis is the difference between the two conductors
<felix_>
rqou: i started looking at the mrc.bin blob of some haswell chromebox, but hit a bug in ida, reported it and iirc there's still no fix yet :( usually they are very responsive with fixing bugs in ida...
<rqou>
wait, mrc.bin is x86 code
<rqou>
and you still hit a bug?
<rqou>
also, iirc someone already did this?
<rqou>
nvm that was for sandybridge
<cr1901_modern>
jhol: Oh... oops
<jhol>
:)
<rqou>
also, felix_ have you tested the ath10k card yet?
<cr1901_modern>
Aren't the inputs to a PHY the raw differential pair?
<cr1901_modern>
Idk of an oscilloscope with 8 different channels, tbh
<rqou>
there's only 4 differential pairs
<jhol>
depends how the PHY works, but normally it's a parallel bus that feeds a phy
<jhol>
the PHY is basically a big serdes
<rqou>
i thought the modern way to feed a phy is sgmii (serial, not parallel)?
<jhol>
true true
<cr1901_modern>
rqou: But you have 8 signals, and you need to get the difference of them to get 4 signals
<cr1901_modern>
that would mean you still need 8 probes?
<rqou>
use a differential probe?
<jhol>
cr1901_modern: yeah - you need a differential probe
<cr1901_modern>
Oh, didn't know those were a thing... I wish I were kidding
jhol has quit [*.net *.split]
<felix_>
lain: sure, uefi is much better than the old legacy bios stuff, but it's layers on layers of indirection (and smells very much like microsoft) and the hardware-dependent code isn't pretty either. oh and it has ways too much "features" that aren't necessary, but increase the chance of explotable bugs...
<felix_>
rqou: yep, mrc.bin is x86 code; basically the memory and chipset initialization peim modules with some thin wrapper around
<felix_>
rqou: no, didn't have the time to test the card yet :(
<felix_>
imho the devicetree stuff isn't that bad; most other stuff is at least much worse ;P
<felix_>
but not sure if the dtd format is really specified...
<felix_>
*dtb
* felix_
strongly prefers devicetree over acpi
<cr1901_modern>
I don't think anybody likes ACPI?
<rqou>
lain?
<cr1901_modern>
... ... ...
<felix_>
rqou: the bug in ida basically is that the elements of arrays in structs aren't handled properly
<rqou>
ah, somewhere in hex-rays
<rqou>
?
<felix_>
yeah, the bug is in ida
<rqou>
oh right, the disassembler can annotate structs
<rqou>
i rarely use that
<felix_>
it's really useful for non-trivial data types
<rqou>
most of my experience with ida was for warezing :P
<felix_>
you basically feed it a header file and then you can annotate stuff
<rqou>
not "real, professional" RE :P
<felix_>
yeah, for patching a "mov rax, rbx" into a "mov al, 0" you don't need that feature ;P
<jn__>
even radare could do that :P
<cr1901_modern>
radare is unbelievably unintuitive and/or buggy
<cr1901_modern>
I would rather roll my own solution than use it
* felix_
doesn't get along with the ui of radare (even though he wrote some assember support for lm32 for radare)
<felix_>
will probably port that to ida
<cr1901_modern>
Did someone in #m-labs ask you to port it?
<felix_>
but the person i was working with on that project doesn't have ida and doesn't want to use proprietary software if it can be avoided
<cr1901_modern>
Well, I actually like lm32 (it's like MIPS, but open and less questionable design decisions), but idk many people using it
<cr1901_modern>
s/MIPS/early MIPS/
<felix_>
it doesn't have branch delay slots, so it's better than mips ;P
<cr1901_modern>
Yes, and the multiplier isn't some hidden state that needs to be invalidated on interrupt
<felix_>
lm32 has a quite low code density, but it's a simple design. and the instruction set encoding is also really simple; not something crazy like in some architectures with better code density
<cr1901_modern>
I don't have a good explanation for it, but reading lm32 code is somewhat pleasant DESPITE it's awful code density. Maybe b/c I've been around it more.
<felix_>
yeah, the assember code ist quite easy to read
<qu1j0t3>
haha, i treid to get radare working the other day
<qu1j0t3>
failed
<cr1901_modern>
felix_: My main gripe w/ lm32 is: No MMU by default, and no atomics
<cr1901_modern>
Also I don't find the Verilog impl exceptionally pleasant to read
<felix_>
haven't read the verilog implementation tbh. i don't care about mmu, since i don't need one for the applications i used the lm32 for. the lack of atomics is also something i don't like, but a lot of small embeded microprocessors lack them
<felix_>
i someone pays me for that, i'd totally write a lm32 implementation in migen
<cr1901_modern>
felix_: Well, there is a user opcode, but I wouldn't anticipate anyone adding binutils support for a user opcode anytime soon
<rqou>
um, ".word 0xabcdef00" works :P
<cr1901_modern>
1. Yes, that would work.
<cr1901_modern>
2. YUCK
<rqou>
iirc j2 was doing that for a while for their cas.l
<cr1901_modern>
Ahhh I think you did mention this before...
specing has quit [Ping timeout: 248 seconds]
specing has joined ##openfpga
digshadow has quit [Quit: Leaving.]
fpgacraft1 has quit [Read error: Connection reset by peer]
fpgacraft1_ has joined ##openfpga
fpgacraft1_ is now known as fpgacraft1
<lain>
well, I wouldn't say that I like acpi
<lain>
I would be fine with device tree alone, provided there's a standard
<lain>
all I want is a stable api surface or file format for conveying the platform info to the OS
<lain>
I wonder if freebsd devicetree is the same as linux
<lain>
is there some standard for it? I know freebsd has some good docs on the subject, last time I looked linux devs just said "read the relevant source files for 'documentation'"
<mtp>
freebsd device tree is at least documented in the manpages
<mtp>
there's also `devd`, which is much less of a heinous trash inferno than the equivalent linux turd
<lain>
well that is certainly a collection of text files.
<lain>
an attempt was made
<lain>
better than nothing though!
digshadow has quit [Quit: Leaving.]
<mtp>
have they been updated since 2.6.20-ac-gd1ef0ad?
<mtp>
;p
<felix_>
acpi has a spec, but the microsoft asl compiler produces output that doesn't fully conform to the spec...
<felix_>
(at least maybe 3 years ago when i had to patch some stuff generated by it)
<mtp>
felix_, i dumped and roundtripped a laptop's ACPI table through iasl and it also didn't conform
<mtp>
unpopular opinion: i miss Open Firmware
<nats`>
ohh god I feel like I'm back in 2008
<nats`>
with my samsung Q45 laptop and his fucking bloated acpi
<nats`>
:D
<felix_>
oh and what i also really dislike is that some mainboard vendor firmwares do ways too much stuff in smm. that makes those boards basically unuseable for realtime stuff. sure today you can use some fpga for hard realtime stuff, but there's still enough stuff doing bitbanging over a parallel port
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
magulo has quit [Ping timeout: 255 seconds]
magulo has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 260 seconds]
digshadow has quit [Read error: Connection reset by peer]