<awygle>
azonenberg: libjtaghal is supposed to build as a .so right? or a .a?
<rqou>
why would you ever build as a .so?
<rqou>
that's "distro people's" job :P
<awygle>
rqou: hush, you :P
soylentyellow has joined ##openfpga
soylentyellow has quit [Max SendQ exceeded]
<mithro>
hey awygle
<awygle>
hey mithro
<mithro>
awygle: I'm currently trying to get the arch-defs repo to have some type of CI and do something when you type "make" in the top level directory
<mithro>
awygle: And getting things ready for tinyfpga's stuff :-P
soylentyellow has joined ##openfpga
<mithro>
be back in ~30 minutes - going to find some coffee
<qu1j0t3>
always a good plan
<awygle>
god i would love some coffee but it's 5pm, i'd be up all night (because i'm old apparently)
<awygle>
maybe i'll make decafe...
pie__ has joined ##openfpga
pie___ has quit [Ping timeout: 260 seconds]
<qu1j0t3>
awygle: well i'm old but it doesn't keep me awake
<qu1j0t3>
awygle: I'm like Obélix in this respect
<awygle>
i have a hard time sleeping just like, in general, so i try to Do The Right Things
* qu1j0t3
nods
<qu1j0t3>
makes perfect sense
<awygle>
nothing in bed but sleep, no coffee after ~3pm, etcetc
<qu1j0t3>
i've tamed that dragon by routine
<qu1j0t3>
yeah
<qu1j0t3>
all good
<awygle>
someday i'll be able to exercise again and that will help lol
<qu1j0t3>
oh, wow, yes that's very effective
<mithro>
I'm back
<mithro>
awygle: btw if the idea of doing doctests for the verilog modules isn't very compelling to you, maybe you want to look at improving sphinx's Verilog support?
* mithro
also acquired some food
<azonenberg>
awygle: i default to building a .so
<azonenberg>
i mean i see no reason you couldnt statically link
<azonenberg>
But i've always built a so
<awygle>
azonenberg: just wondering whether to put STATIC or SHARED in this cmake file
<azonenberg>
Yeah i'd do shared
<rqou>
ugh why
<rqou>
now you need to mess with rpath or ld_library_path or whatever
<azonenberg>
rqou: or just install to /usr/lib
<rqou>
but that requires sudo
<azonenberg>
not much point making a shared library if everyone can't use it
<rqou>
but i don't want to need sudo during development
<rqou>
at least openfpga builds as static
<awygle>
does anybody know how we ended up with the ridiculous way linux installs everything to global directories so it's impossible to e.g. uninstall things/
<awygle>
like, historically speaking?
<mithro>
awygle: Things were small enough that people could just manually remember what files to delete, then people went to package managers
<mithro>
awygle: Plus you didn't actually upgrade very often either
<awygle>
I suppose.
<awygle>
mithro: I think I'd rather do doctests XD I downloaded cocotb
<mithro>
awygle: How is it looking?
<awygle>
"downloaded" is as far as I've gotten. It looks decent from the docs
<awygle>
Finishing this cmake patch for libjtaghal and then I'll do about 50/50 tests and the mpsse stuff for whitequark's project
<azonenberg>
awygle: did you do one for jtagd too?
<azonenberg>
and jtagclient?
<azonenberg>
or just the core library
<azonenberg>
i have to find a good spot for them, i might move it to its own repo or something
<awygle>
azonenberg: no, I was going to ask you about that. Currently just the library because yeah, those are still in antikernel
<azonenberg>
jtaghal is its own repo to allow you to embed it in larger projects as a submodule
<azonenberg>
If you give me some time
<azonenberg>
i can fork them off to their own repo
<rqou>
azonenberg: you and diamondman really need to go and integrate your stuff
<azonenberg>
rqou: i offered several times and he didnt seem interested
<azonenberg>
the offer is open
<rqou>
funny, he said the exact same thing :P
<awygle>
rqou: diamondman?
<awygle>
azonenberg: it seems sensible to have libjtaghal as a submodule of jtagclient and jtagd
<azonenberg>
awygle: so have jtaghal-tools as the main repo
<azonenberg>
with the tools in it, then jtaghal imported as a submodule
<awygle>
(also I had to add log and xptools as submodules to get libjtaghal to build)
<azonenberg>
you can then build either just the lib, or everything
<awygle>
Right
<azonenberg>
Dont do that
<azonenberg>
give me a few mins and i'll do that right now
<azonenberg>
i'll make jtaghal-tools a standalone parent repo
<awygle>
K. I haven't committed anything so no rush
<azonenberg>
Actually i wonder if i'd be better off with three repos
<azonenberg>
one for just the libs
<azonenberg>
one for just the tools
<azonenberg>
and one with everything
<rqou>
why do you also really like separate repos?
<rqou>
i tend to make monorepos instead because the submodule ux is just awful
<awygle>
The tools need to include the headers from the lib don't they? I dislike having repos that can't be built by themselves with only system dependencies
<awygle>
Your call obv
<azonenberg>
awygle: the intention is for the lib and tool repo alone to be included as a submodule in antikernel
<azonenberg>
or as a submodule in the standalone-build project
<awygle>
rqou: Modularity Is Good (TM) (although yes submodules are pretty badly implemented)
<azonenberg>
rqou: i'm trying to make a massive monorepo a la Google
<azonenberg>
But also make individual subcomponents of that massive project be usable standalone
<azonenberg>
f.ex logtools in openfpga
<rqou>
sure, i believe in modularity
<azonenberg>
So i have one submodule for each module that's intended for public consumption
<azonenberg>
but i never build the submodules alone
<rqou>
but i'd still make a monorepo just so i didn't have to use submodules
<azonenberg>
i use splash to build everything in the monorepo
<azonenberg>
honestly if i had time to refactor things the way i really wanted
<awygle>
If you have a submodule in the tree twice I wonder if git deduplicates it...
<azonenberg>
i'd have one monorepo that is completely empty
<azonenberg>
just submodules
<azonenberg>
and maybe a top level build script
<azonenberg>
then it'd pull stuff in
<azonenberg>
ok so, new plan
<azonenberg>
jtaghal repo is the lib alone, with a leaf cmakelists to integrate into a larger project
<azonenberg>
and a leaf build.yml to integrate into a larger project using Splash
<azonenberg>
Just like how logtools etc are set up
<rqou>
ugh cmake
<azonenberg>
rqou: dual-stack makes sense until splash is usable by the general public
<azonenberg>
its the least bad of the bad options
<azonenberg>
i made splash to get away from cmake
<rqou>
how about traditional make?
<azonenberg>
eeeew
<azonenberg>
awfuul syntax
<rqou>
eeew yourself :P
<azonenberg>
awygle: anyway, then jtaghal-tools is a source-only repo for jtagd, jtagclient, etc
<awygle>
cmake is pretty bad too, syntactically
<rqou>
cmake syntax is imho even worse
<azonenberg>
and a leaf cmakelists for that stuff
<awygle>
and tbh i object on principle to build systems that generate other build systems as their output
<azonenberg>
Then jtaghal-tools-cmake will be a skeleton repo that just pulls in the two, plus logtools
<awygle>
but cmake is probably the least bad, yeah
<azonenberg>
and has a root cmakelists
<azonenberg>
awygle: sound good?
<awygle>
azonenberg: sure, knock yourself out :P i'll go build cocotb until you've got it all set up
<azonenberg>
That seems the best way to dualstack cmake+splash
<rqou>
azonenberg: does your jtag stuff have a c api or a c++ api?
<azonenberg>
rqou: C++
<rqou>
ugh
<azonenberg>
it's heavily, heavily OO
<rqou>
ugh ugh
<azonenberg>
with lots of code in base classes (this is why i don't like java interfaces) that's shared by all of the derived stuff
<cr1901_modern>
azonenberg lives, eats, and breathes UML diagrams
<azonenberg>
like "how does i shift to SHIFT-DR"
<azonenberg>
each dongle class doesnt need to reimplement that
<azonenberg>
cr1901_modern: i have never used uml outside of my software engineering class
<cr1901_modern>
azonenberg reads a chapter of GoF before he goes to bed each night
<awygle>
as long as it has good descriptions of the abstract data types and an in-memory serialization format there's nothing wrong with c++ :p
<awygle>
oh holy gods _why_ cocotb. its test output is dark dark blue on black
<rqou>
c++ is a giant minefield of ABI disasters
<rqou>
including its own billion laughs attack that whitequark pointed out
<azonenberg>
awygle: well good luck serializing anything to do with jtag
<azonenberg>
since it depends on hardware state
<awygle>
azonenberg: i meant that C++ should be written so that it can be called by, and call into, other code
<azonenberg>
oh
<rqou>
yeah, unlike xbpar :P
<awygle>
(non-C++ code)
<rqou>
awygle: have you seen xbpar-rs?
<rqou>
it had more code than xbpar itself :P
<awygle>
rqou: only in passing
<azonenberg>
yeah that would be tricky with jtaghal, it was primarily meant to be used by C++ when i made it
<azonenberg>
i'm not sure how to make it more friendly other than writing a C wrapper around opaque handles pointing to objects
<rqou>
i tend to avoid that so to avoid c++ abi disasters
<awygle>
well jtaghal isn't too bad, because it'll be protobufs at the most important interface
<awygle>
and it's small and wellscoped
<azonenberg>
awygle: welll
<azonenberg>
it will be protobufs as the dongle abstraction interface
<azonenberg>
But the programming algorithms live in the core library
<azonenberg>
the intent is that your client app links with jtaghal and speaks over the protobuf api to a remote hardware server
<azonenberg>
But the remote server just knows how to jtag
<azonenberg>
not how to flash a stm32
<azonenberg>
it would be trivial to write your own app in another language that talks raw jtag using jtaghal
<awygle>
eh ok that's not as clean as i was imagining then lol
<azonenberg>
or a jtag server in another language
<azonenberg>
i mean
<azonenberg>
Nothing would stop us from making an "algorithm server"
<azonenberg>
that was protobufs at a higher level of abstraction too
<azonenberg>
i.e. the ProgrammableDevice API
<azonenberg>
rather than the JtagInterface API
<awygle>
right
<azonenberg>
jtaghal is very cleanly layered but the interface between the layers is all C++ ABI
<azonenberg>
the socket api is an alternate JtagInterface
<azonenberg>
So you can either create a DigilentJtagInterface manually and talk to a local cable
<azonenberg>
or talk over TCP with a NetworkedJtagInterface to whatever
<azonenberg>
The layering is clean enough that you should have no problem creating a server for a higher level of the protocol
<azonenberg>
kinda like how openocd does
<azonenberg>
i've just never had the need
<rqou>
i guess since i always have weird usecases i always try and restrict myself to FFI-friendly interfaces
<azonenberg>
my use case is, unit tests in C++ speaking C++ ABI to jtaghal to implement programming algorithms, then over TCP to jtagd to implement hardware
<azonenberg>
in fact i would not be opposed (down the road) into splitting jtaghal into two sub-libraries
<azonenberg>
one for dongle support and one for higher level stuff
<azonenberg>
Since it seems like most apps will use one api or the other, and the high level stuff calls into the dongle lib but not the other way around
<awygle>
the reason things like the language protocol server exist is because we, collectively, never figured out how to do FFI
<rqou>
we have working FFI :P
<rqou>
option 1: use C
<rqou>
option 2: use a network RPC protocol of some kind
<azonenberg>
yeah thats what i do
<azonenberg>
gimme a sec
<awygle>
rqou: "use C and like one of like four other languages"
<awygle>
... redundant like
<awygle>
my california is showing
pie__ has quit [Ping timeout: 276 seconds]
<awygle>
you can only call into C from C++, Rust, probably Swift, and maybe two or three others
<rqou>
um, no?
<awygle>
and i don't even know if you *can* call out of C (i've never tried)
<rqou>
also python, javascript, and many other scripting languages
<awygle>
i'm sure you can actually but sitll
<awygle>
rqou: having done C interop in Python.... there's "technically possible" and then there's "less unpleasant than just doing RPC"
<rqou>
i've successfully done it many times?
<awygle>
i have too but it's shitty
<rqou>
worksforme?
<rqou>
it doesn't lead to very pythonic code, but it exposes the c interface the way it would work in c
<azonenberg>
eh my drawing skills are awful
<azonenberg>
w/e let me actualyl implement this :p
<awygle>
anyway the whole debate is beside the point because "just use C" is not an acceptable state for ffi
unixb0y has quit [Ping timeout: 240 seconds]
<rqou>
how about "just use xmlrpc/json-rpc/etc.?" :P
<azonenberg>
rqou: you mean protobufs?
<rqou>
nobody except you and the big G uses protobufs
<awygle>
rpc is fine but inefficient
<azonenberg>
i have reverse engineered client code that says otherwise :p
<awygle>
to varying degrees depending on how you do it
<rqou>
pokemon go doesn't count :P
<azonenberg>
not that, it was scada
<rqou>
O_o
<awygle>
we did protobufs at planetary but then somehow ended up wrapping it in 3 layers of abstraction above and 3 more below
<rqou>
i thought scada was supposed to use some shitty things like CAN encapsulated in XML encapsulated in Ethernet?
<awygle>
(i did not do software at planetary)
<azonenberg>
rqou: CIP and a few other protocols are supposed to replace that, but some folks use protobufs at various layers of the stack too
unixb0y has joined ##openfpga
<rqou>
wait this actually exists as described?
<rqou>
i thought i was exaggerating?
<azonenberg>
i meant "the mess of protocols that existed before"
<azonenberg>
I have seen things you wouldn't believe, though
<awygle>
C-beams glittering off the Tannhauser Gate
<azonenberg>
awygle: beat me to it
<azonenberg>
lol
<azonenberg>
i was going to reference that speech
<awygle>
because i didn't stop to google it to make sure i had it right (i did not)
<awygle>
cats hate productivity
<azonenberg>
awygle: also right now the commit bot for jtaghal etc logs to #antikernel
<azonenberg>
do you think it makes more sense to go here?
<awygle>
i don't understand the purpose of those bots so... whatever you want is fine with me
<azonenberg>
just to keep people in the channel posted re code changes that might affect them
<awygle>
it is technically an open fpga tool, i guess? although "fpga' is questionable
<azonenberg>
it's very fpga focused right now
<azonenberg>
as opposed to openocd which is almost all MCU focused
<azonenberg>
ok azonenberg/jtaghal-apps is set up
<azonenberg>
working on the next one
<antikernel-bot>
[jtaghal-apps] azonenberg pushed 2 new commits to master: https://git.io/vAHbX
<antikernel-bot>
jtaghal-apps/master d965661 Andrew D. Zonenberg: Added svfdumper from Antikernel repo. Only works for UltraScale right now.
<antikernel-bot>
jtaghal-apps/master 91dbe0f Andrew D. Zonenberg: Initial import of apps from Antikernel repo
<antikernel-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/vA6Y9
<antikernel-bot>
jtaghal/master 5a83172 Andrew D. Zonenberg: Refactored bitstream loading to make better use of exceptions. Continued work on UltraScale jtaghal support.
<rqou>
you removed mode n?
<azonenberg>
yes, it was breaking the commit bots
<azonenberg>
if we start getting spam again i'll bring it back
<azonenberg>
but i think that wave has died down
<azonenberg>
i havent seen it for a while
<antikernel-bot>
[jtaghal-apps] azonenberg pushed 1 new commit to master: https://git.io/vAHNc
<antikernel-bot>
jtaghal-apps/master 3db7b4c Andrew D. Zonenberg: Updated README
<antikernel-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/vAHNC
<antikernel-bot>
jtaghal/master 0a2872e Andrew D. Zonenberg: Updated README
keith-man has quit [Read error: Connection reset by peer]
<qu1j0t3>
azonenberg: lol, i've been complaining about CMake today...
<azonenberg>
qu1j0t3: if you want to help me get Splash to the point of general usability
<azonenberg>
feel free :p
<openfpga-bot>
[jtaghal-cmake] azonenberg pushed 2 new commits to master: https://git.io/vAHN6
<openfpga-bot>
jtaghal-cmake/master afc3a2f Andrew D. Zonenberg: Updated README
<openfpga-bot>
jtaghal-cmake/master 1406229 Andrew D. Zonenberg: Initial import of all submodules
<rqou>
i'll just continue to use raw make and/or the "f*ck it" build system
<awygle>
someday i'm gonna do a "my dream build system" speculative blog post rant
<azonenberg>
rqou: is that gcc -O3 -march=ibmbluegene -mtune=bitcoinminerwow -funroll-loops *
<azonenberg>
?
<azonenberg>
(not going to bother making a full ricer command line there)
<rqou>
one thing i really hate (fortunately azonenberg doesn't seem to do this) is build systems that conflate themselves with "find/download all your deps" systems
<cr1901_modern>
-DCHAR_BIT=9
* azonenberg
slaps cr1901_modern with a half-ton tuna because a trout isn't heavy enough for that
<cr1901_modern>
-Dtrue=false
<awygle>
my blog post will *absolutely* piss rqou off
<awygle>
if it does not i will consider it a failure
<cr1901_modern>
azonenberg: :D
<rqou>
azonenberg: no, it's just "gcc -Wall -ggdb -o <foo> *.c"
<awygle>
Too much salt not enough pepper :-/ okay, cmake time
rohitksingh_work has joined ##openfpga
<whitequark>
awygle: "i object on principle to build systems that generate other build systems as their output" then just use -G Ninja with cmake, ninja isn't a full-blown build system :p
<whitequark>
rqou: you must like cargo then
<rqou>
i like cargo except for how opinionated it is
<rqou>
afaict it's extremely difficult to integrate with anything that isn't managed by cargo
<rqou>
but it works _great_ for normal rust
<awygle>
cargo tries to fetch all your dependencies, right? as long as all your dependencies are rust crates at least
<rqou>
yeah it does
<rqou>
but it amazingly actually works
<rqou>
unlike autocrap
<rqou>
or some people have made giant piles of copypasta for cmake to auto download deps
Bike has quit [Quit: Lost terminal]
<whitequark>
rqou: in theory, integration of cargo with anything else is an explicit goal
<whitequark>
for this y ear or something
<rqou>
in theory
<rqou>
i can never figure out or understand how rust's development process works
<rqou>
i've been waiting over a year for them to fix deriving traits for arrays with more than 32 elements, and among the open issues, closed issues, open RFCs, and closed RFCs i can't even figure out what the latest plan is
<rqou>
i know they fixed Copy/Clone, but I can't figure out from that discussion why that fix doesn't work for e.g. Debug
<awygle>
back when i was paying attention i really wanted a good story for integrating other test frameworks
<JSharp>
no, you're not. different design requirements, different end goals -- different implementation. They also have the "benefit" of having most of the original install base wiped out during the 30s and 40s :/ -- so why not apply past learning.
<whitequark>
the Schuko plug, for example, is designed in a way that has three useful properties:
<whitequark>
1. it's polarized
<JSharp>
ring circuits make sense, if you're short on copper
<JSharp>
larger circuits with more capacity, fewer fuses in the consumer unit, less wasted cable
<whitequark>
2. it has ground on top, so if you plug it into a noncompliant (i.e. non-sunk) socket and then drop something metallic on top it doesn't short out the leads
<JSharp>
at the cost of more expensive plugs
<whitequark>
3. with sunk sockets, at no point when plugging it in or out can your fingers touch energized leads
<whitequark>
none of this is true about nema5
<rqou>
btw, my experience with schuko was much improved once i bought a proper dedicated schuko to nema adapter\
<rqou>
it _sucks_ if you use generic travel europlug to nema adapters
<whitequark>
oh yes, multipurpose adapters are horribly noncompliant and a serious hazard
<whitequark>
that is if they work at all
<JSharp>
indeed... deathadapters :/
<JSharp>
fitnothing plugs
<whitequark>
i've recently bought some magstirrers from rushim and they came with chinese plugs
<rqou>
"universal" sockets are even more fun
<whitequark>
mainland chinese
<whitequark>
so rushim gave out adapters with them
<cr1901_modern>
nema-5 isn't polarized?
<JSharp>
hint: that's not compliant.
<whitequark>
the next time i went to rushim i complained: "the adapters you gave me work like 50% of the time"
<whitequark>
they responded: "the adapters we didn't give you work 0% of the time"
<cr1901_modern>
Well old devices aren't, but anything modern one prong is larger than the other
<rqou>
lol
<awygle>
whitequark: i mean... not incorrect?
<awygle>
that's pretty good tho
<rqou>
btw, i came up with a "fun" solution to the "universal" sockets that you can occasionally encounter on planes or other "international-ish" areas
<rqou>
i just plug in a bs1363 adapter to nema adapter
<rqou>
because the prongs on that are the largest, so it's least likely to be loose in the "universal" socket
<JSharp>
hmm
<cr1901_modern>
whitequark: By polarized you meant "can't insert the plug backwards", right?
<azonenberg>
rqou: you know whats funny?
<whitequark>
yes
<azonenberg>
i do the same thing
<awygle>
azonenberg: well i made this work but i'm only 25% confident i understood what you actually wanted from the various cmakelists
<awygle>
so i'm going to push to branches so you can yell at me tomorrow
<azonenberg>
awygle: commit to master
<azonenberg>
you have push access
<cr1901_modern>
Yea, modern appliances w/ NEMA-5 are polarized then. Of course I have a few old appliances that aren't polarized
<azonenberg>
awygle: My rule with 0.x project is, pushing new broken features to master is fine
<awygle>
azonenberg: lol ok then
<azonenberg>
just dont (knowingly) break an existing feature
<azonenberg>
once you hit a 1.0 release i'm more strict about things working, but i still consider master to be a development platform and not something the average user should run
<rqou>
cr1901_modern: be glad you aren't here in berkeley where one of the local hardware stores still sells lamp socket to nema adapters
<cr1901_modern>
rqou: I remember seeing a video of someone showing off their antiques. One of them was a 120v fan that plugged into an incandescent lightbulb socket
<azonenberg>
rqou: do those not exist anymore?
<rqou>
they still exist
<rqou>
the idea is that berkeley has so much ancient housing that the hardware store still carries them
<azonenberg>
i cant remember having seen one recently, but i also take a dim view to janky wiring
<cr1901_modern>
apparently back then, it was commonplace to have lamps, but not sockets
<cr1901_modern>
So you'd repurpose a lamp for a fan or other appliance
<awygle>
azonenberg: i suppose if you let rqou push the Rust Sandwich i'm probably safe with a few dodgy cmake files
<openfpga-bot>
[jtaghal] awygle pushed 1 new commit to master: https://git.io/vAHjv
<openfpga-bot>
jtaghal/master 4ad3dcf Andrew Wygle: Added CMakeLists.txt and generated enum headers
<openfpga-bot>
[jtaghal-apps] awygle pushed 1 new commit to master: https://git.io/vAHjq
<openfpga-bot>
jtaghal-apps/master adadf16 Andrew Wygle: Added CMakeLists.txt. Fixed svfdumper for its new home.
<openfpga-bot>
[jtaghal-cmake] awygle pushed 1 new commit to master: https://git.io/vAHjO
<openfpga-bot>
jtaghal-cmake/master e6f31db Andrew Wygle: Created CMakeLists.txt. Updated submodules to point to versions containing CMakeLists.txt. Added xptools as a submodule.
pie__ has joined ##openfpga
<sorear>
NEMA 5 (3-prong) is polarized, NEMA 1 (2-prong) is sometimes polarized
<sorear>
NEMA 5 plugs are also much harder to accidenally pull out, NEMA 1s fall out if you look at them wrong
<azonenberg>
yeah i hate 1's
<azonenberg>
do they meet code, anywhere, for any purpose, anymore?
<rqou>
be like whitequark and use iec plugs everywhere?
<azonenberg>
nema 5-15 is my standard receptacle these days, it does the job just fine
<azonenberg>
i might put a feeew 5-20s in but honestly i dont see the point
<azonenberg>
everything i have that needs more than 1800W runs on 240V
user10032 has joined ##openfpga
user10032 has quit [Remote host closed the connection]
stefanct has quit [Ping timeout: 260 seconds]
stefanct has joined ##openfpga
stefanct has quit [Changing host]
stefanct has joined ##openfpga
m_t has joined ##openfpga
<gruetzkopf>
everything i have runs on 240V
<rqou>
don't be me at 34c3?
<gruetzkopf>
what did you make catch fire
<rqou>
don't you remember i blew up that atx psu?
<rqou>
iirc i even offered it to you and you didn't want it :P
<gruetzkopf>
ah
<gruetzkopf>
i have enough dead atx psus
Bicyclidine has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ondrej2 has joined ##openfpga
soylentyellow has quit [Ping timeout: 256 seconds]
<whitequark>
gruetzkopf: 240V or 220V?
<whitequark>
... or 230V?
<whitequark>
all of these are within tolerances of each other but i've been recently shown some equipment that apparently cares enough
<felix_>
rqou: this summer may or may not happen something regarding ath10k; still depends on some factors we haven't fully figured out yet
<whitequark>
niiiice
<felix_>
oh and on reverse engineering projects: the airbus security people also poked the hp ilo4 released this nice tool: https://github.com/airbus-seclab/ilo4_toolbox we didn't get to unpacking the main firmware during the 1,5 weeks wo worked on that last summer; we did identify the compression as lz-like, but didn't get around to implement that ourselves
<felix_>
well, our main goal was to get coreboot running on that machine, but yeah...
<balrog>
felix_: nice :D
<balrog>
still wondering if we'll ever see a free driver for bcm4360.... hah
<felix_>
haven't looked at those and if their firmware is signed or not, but if it's not, then that should be possible. there are full datasheets for some smaller broacom wifi chips that got sold to cypress
<felix_>
i doubt that the small and the big broadcom wifi chipsets are completely different
<whitequark>
maybe they bought the small ones from someone else
<balrog>
aiui it's not signed
<balrog>
there's one app note that references a cyw4360 but there's no datasheet
<felix_>
both small and big ones have an embedded arm microcontroller thogh; might be worth trying bindiff on the firmware images
<felix_>
yeah, the big chips went to avago (which iirc then renamed itself to broadcom)