<rqou> hint: when transferring from a nonencrypted rootfs to an encrypted rootfs it helps to not mix the two copies up :P
<rqou> especially when fstab changes are involved in the middle
<nats`> plop
promach has joined ##openfpga
FiveBroDeepBook has joined ##openfpga
FiveBroDeepBook has left ##openfpga [##openfpga]
<cyrozap> Valgrind is the colest thing ever now that I'm getting the hang of it :D
<azonenberg> cyrozap: Indeed, as is static analysis
<azonenberg> honestly i think there's no excuse for not using every tool at your disposal to automatically catch bugs before they waste anyone's time
<rqou> hmm, in general i have not had a good experience with tools
<cyrozap> I've been using Go a lot at work and C just feels so incredibly archaic by comparison.
<rqou> also, i might finally have secure boot working on my nas
<rqou> efitools is broken as shit
<cyrozap> Go's compiler has spoiled me with its strictness, and it feels weird to have to make sure I'm free-ing memory when I don't need it and when stuff errors out.
<cyrozap> And I really miss `gofmt`...
* cyrozap is revisiting the KitProg OpenOCD driver
<pie_> qu1j0t3, "<cyrozap> I've been using Go a lot at work and C just feels so incredibly archaic by comparison."
<pie_> i just laugh waiting for your reaction
<pie_> pointfree, i might check that pdf out
<pie_> thx for linking
<pie_> (i mean, im only tangentially interested, and because it got linked)
<pie_> and now...long overdue sleep.... o/ live free and hack hard
pie_ has quit [Quit: Leaving]
<pointfree> pie_: After doing analog network coding at the end of my undergrad, I was looking for ways to do low power error correction in the analog domain. I starting looking into analog error-correcting codes, then FPAA's, and then PSoC's.
<pointfree> doh pie_ left.
<azonenberg> pointfree: i would love to eventually support verilog-ams
<azonenberg> for both psoc and greenpak
<azonenberg> even if it's just verilog-a sim models of some of the hard IP
<azonenberg> (being able to infer analog IP from verilog-a seems a bit much)
<pointfree> azonenberg: My interest in the PSoC is primarily because of its analog stuff. I just started with the digital system because it's easier.
<pointfree> Cypress released an analog co-processor somewhat recently.
digshadow-s has quit [Ping timeout: 264 seconds]
<rqou> hint: put your gpu option roms in "db" if you remove microsoft keys for secure boot :P
<rqou> hmm extra efitools bug: it can't hash a binary that is signed for some reason
<rqou> if you manually strip the signature then it works
<rqou> who the f*ck writes this shit?
<rqou> imo this thing needs a complete rewrite
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
digshadow has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 256 seconds]
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
<azonenberg> rqou: lol
<azonenberg> i think EFI is as bad as bios
<rqou> yeah, they're all terrible
<azonenberg> i would really like a more MCU-style approach to motherboard design
<rqou> i should write up a "how to put option rom hash into secure boot" procedure
<rqou> because it's not really documented anywhere
<azonenberg> where the CPU basically tries a couple of boot sources in sequence until one works
<rqou> you can always reverse engineer enough to port coreboot :P
<azonenberg> i would love if you could just write (say) u-boot to a microSD card, slide it into a socket on the mobo
<azonenberg> and have it work
<rqou> iirc felix_ was looking at the haswell MRC blob at one point
<azonenberg> yeah but i mean the whole idea of a bios seems like something rooted in the ages of DOS
<azonenberg> the kernel and bootloader have to redo all that stuff anyway
<azonenberg> Why can't we just skip it?
<rqou> whereas EFI is just "stupid wintel shit?"
<azonenberg> in fact, why can't you just burn a FSBL + vmlinuz to spi flash on the mobo?
<azonenberg> then have that load the rest of the OS from the HDD
<rqou> you can on embedded platforms
<rqou> or with coreboot
<azonenberg> and why can't you with x86?
<azonenberg> I mean i know the current implementation doesnt support it
<rqou> no good reason?
<azonenberg> but inherently, from an architectural perspective
<rqou> like i said, coreboot can do that
<azonenberg> why do we need all this code running before the kernel starts?
<rqou> one great answer is that the intel ME needs to update the cpu microcode :P
<azonenberg> So, have a partition on the spi flash for ucode
<rqou> apparently otherwise the cpu might not even boot through the bios
<azonenberg> that a tiny 100-gate state machine reads
<azonenberg> before doing anything else
<rqou> but ME also needs to set up some stupid DRM shit :P
<rqou> and emulate a TPM :P
<azonenberg> :p
<rqou> and enforce non-overclockability :P
<azonenberg> aaand this is one of the many reasons i hate the x86 ecosystem
* rqou still needs to work on the "liberate tegra boot chain" project
<rqou> the nvidia tegra x1 afaik just needs someone to RE nvtboot
<rqou> (there's also the GPU ucode, of course)
<rqou> but the GPU ucode isn't in the boot chain
<rqou> you can just load it whenever
<rqou> iirc on tegra the GPU isn't even hooked up to the scanout logic
<rqou> you can draw a framebuffer without booting it
<rqou> it's funny how in some ways ARM is actually less wtf than x86
<rqou> although on the other extreme you have qualcomm
<rqou> where the baseband needs to boot first
<rqou> hmm this reminds me; has raspi been liberated yet?
<rqou> too bad i can't work on raspi VPU
<rqou> wow, neat
<rqou> but yeah, i've seen the HDL for VC4, so i'm not going to touch any of this :P
<jn__> rqou: if you liberate tegra, consider using coreboot
<rqou> i'm not actually working on tegra atm
<rqou> it's just sitting on my project shelf
<rqou> i ordered the jetson tx1 right before i graduated so that i would still qualify for the educational discount
<jn__> i have an ever-growing list of projects, too :)
<pointfree> I try to combine my projects wherever it makes sense to do so.
<rqou> anyways, afaik the only part of tegra that really needs liberating is nvtboot
<rqou> the rest of the downstream stuff is mostly stupid bullshit bugfixing
<rqou> e.g. the trustzone firmware is iirc open source
<rqou> and the u-boot is too, just ancient/weird/hacked
<jn__> i think they're using ARM Trusted Firmware in TZ
<rqou> yeah
<rqou> which is source-visible at least
<rqou> afaik nothing is really hidden in the early boot code (unlike intel)
<rqou> it's just not open for whatever dumb reason
<jn__> my experience with ARMTF has se far mostly been "it breaks the build when we upgrade coreboot to GCC 6" :)
<rqou> imho i don't care about that
<rqou> that's Somebody Else's Problem :P
<rqou> ie "there exists at least one configuration that works where all of the source code is visible"
<rqou> fixing it so that everything is up to date is "just a coding exercise" :P
<jn__> sure, i wouldn't care about it, but it's partly my problem, because i'm a coreboot dev
<rqou> as in, no extra reverse engineering is necessary
<rqou> oh really?
<jn__> yes, i did GSoC 2016 with coreboot
<rqou> i've used coreboot a little bit
<jn__> i helped with the RISC-V port
<rqou> is anyone seriously working on MRC/FSP reverse engineering?
<jn__> no :(
<jn__> old stuff, i.e. chipsets from about up to 2010 have native raminit, but that's about it
<rqou> i never understood why raminit is closed source
<jn__> ("native" meaning "it's free software and available as source code in coreboot")
<rqou> looking at the sandy bridge code nothing is particularly special or secret
<rqou> ie "it performs the operations (link training, etc) that you would naturally expect a ddr3 memory controller to have to do"
<rqou> hmm, i wonder if "product differentiation" is hidden in MRC/FSP?
<jn__> one hypothetical business reason is that managing the copyrights well enough to be able to release the code under an open source license would cost too much money, but intel also makes open source graphics drivers, so idk
<rqou> ecc defeature flags?
<rqou> e.g. i experienced that for haswell/broadwell HEDT on X99, not all mobos enable ECC
<jn__> i haven't look at FSP closely enough to know if that's plausible
<rqou> what about bclk overclocking? :P
<jn__> i know that FSP gets a large struct with config flags when it's called
<jn__> FSP is one of the reasons why i'm not very excited about new x86 hardware
<rqou> yeah, intel's been adding a kinda ridiculous number of blobs recently
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
FiveBroDeepBook has joined ##openfpga
FiveBroDeepBook has left ##openfpga [##openfpga]
<rqou> woot tpm-sealed disk encryption key is working
<rqou> why is this so ridiculously hard?
promach has quit [Ping timeout: 255 seconds]
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
m_t has joined ##openfpga
<cyrozap> Reduced the KitProg driver by 50 lines :)
<cyrozap> I realize that's not much for a 900+ line driver, but I also added 16 lines of comments in the same commit, so it actually was a pretty sizeable simplification.
<azonenberg> :)
<azonenberg> negative sized commits are always fun
<azonenberg> i havent got to do them much lately b/c i've been adding so many new features to projects
<rqou> apartment is getting brownouts rather than breaker trips
<rqou> that's always a good sign
<rqou> :P
<azonenberg> Lol
<azonenberg> rqou: in other news
<azonenberg> i think i may have found the bus to use for my future home automation projects
<azonenberg> Optional redundancy, specified to run over copper or fiber
<azonenberg> AC coupled so no worries about shorting power to the data lines
<rqou> i expected the answer to be "ethernet" :P
<azonenberg> Well the thing about ethernet is it's expensive, i'm wondering if something like this might be cheaper
<azonenberg> i'm open to options though
<rqou> it has "MIL" in it
<rqou> how can it be cheaper? :P
<azonenberg> it's just a protocol
<azonenberg> nothing in it requires expensive hardware
<azonenberg> Although it does use highish voltages
<azonenberg> The other option would be 10baseT bitbanged on the MCU/FPGA without a PHY
<azonenberg> The big thing i have to solve, honestly, is power
<azonenberg> I need a way to get low voltage power into the junction box either via AC conversion or a separate power distribution wire
<azonenberg> And do so in a safe, efficient, low-cost way while passing code
<azonenberg> PoE is an option but it'd be tricky to (legally) run PoE into the same junction box as mains
<azonenberg> And you still would have to step 48V down to low voltage which might be tricky to do on the cheap
<rqou> eh, code doesn't strictly matter on your own house unless you try to sell it
<azonenberg> It matters for insurance etc
<azonenberg> If something happens i dont want to be denied a payout b/c of unapproved wiring
<azonenberg> i might even go so far as to try getting UL/ETL/whatever cert on the hardware once i've prototyped it a bit
<azonenberg> i mean i'd use good engineering practices and design it to probably be 10x safer than most of the cheap chinese crap on the market, but if a lab signs off on it i have somebody else vouching that my board wasnt negligently designed
<rqou> so i never really understood what legal framework UL operates under
<rqou> how does UL make their labeling required/more-or-less-required?
<azonenberg> i dont think they have any authority so much as most insurance agencies trust their word on things
<azonenberg> in some cases certain equimpent must be tested by a nationally recognized testing lab, including but not limited to UL
<azonenberg> to be sold
<azonenberg> you dont have to do that for your own use
<azonenberg> My concern is that if there's ever a fire or something
<azonenberg> the insurer will be looking for excuses to not pay up
<azonenberg> I dont want to give them one :p
<azonenberg> The other option would be to build the device as a MITM that sits between the junction box and the plug load
<azonenberg> and not touch the house wiring at all
<azonenberg> this would be a lot harder to communicate b/c i cant easily cable to the box. but no code issues
<azonenberg> I dont want to do wireless, esp not on an ISM band, b/c this would mean EMI means i can't turn my lights on and off
<azonenberg> not good :p
<cr1901_modern> Where does that wiki article say AC coupled?
<nats`> Transmitters and receivers couple to the bus via isolation transformers,
<cr1901_modern> Oh that's obvious in retrospect lol.
<cr1901_modern> But why does AC coupling in and of itself prevent shorting to power?
<rqou> wow, i just gave myself a nice mini heart attach
<rqou> *attack
<rqou> i tried to mount my old nas storage volume
<nats`> it doesn't prevent it but it make no damage
<rqou> and it was telling me that my mount options were bad
<nats`> if you have a 100nF capacitor inline
<rqou> turns out the old filesystem was ext4, and i was telling it to mount as btrfs
<nats`> you can short it to VCC
<rqou> :P
<nats`> it'll simply block DC
digshadow1 has quit [Quit: Leaving.]
<cr1901_modern> I think I was just confused by the wording
<rqou> wow, rsync is just as bad as windows at "file progress"
digshadow has joined ##openfpga
<rqou> hmm according to the twitter many operating systems still fail to enable iommu protection against dma attacks
<rqou> why is this so hard?
Bike has quit [Quit: leaving]
promach has joined ##openfpga
<rqou> hmm, i just transferred 1,277,948,060,333 bytes from one hdd to another hdd
<rqou> i wonder what sata BER statistics look like? azonenberg?
<rqou> the old FS was ext4, so no crcs really possible unfortunately
<rqou> just hoping and praying :P
FiveBroDeepBook has joined ##openfpga
FiveBroDeepBook has left ##openfpga [##openfpga]
<lain> there's checksums at the protocol level
<lain> iirc
<lain> I'm pretty sure you can even monitor SATA BER, but I forget how
<lain> good way to detect a bad cable
<rqou> whee, now i get to do the transfer again!
<rqou> "btrfs balance start -dconvert=raid1 -mconvert=raid1"
<rqou> going to go to sleep now; this is going to take about three hours
<rqou> there are checksums and ecc this time around
<rqou> so no additional corruption will hopefully be introduced
m_t has quit [Quit: Leaving]
<plaes> s
<nats`> t
promach has quit [Ping timeout: 240 seconds]
<nats`> someone already played with MPSSE mode of ftdi ?
<nats`> JTAG handling seems awful
<nats`> either I don't get all the details or something is really wrong
<whitequark> it's awful
<nats`> like the crap about TMS
<nats`> having a different command that take the MSB of the BYTE to drive TDI and TMS after
<nats`> what's that crap oO
<lain> oh, yeah
<lain> it's bad
<lain> have fun :D
<lain> it's honestly easier and cheaper to just plop down some cheapo arm mcu with usb and implement your own jtag-over-usb :P
<lain> and likely more reliable
<felix_> coreboot does't do that much stuff that the os will do later and also only has a small amount of code running in smm
<felix_> you don't need a bootloader; you can even put a small linux in the spi flash and then kexec into some other kernel
<nats`> lain I'm inclined to think so...
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 245 seconds]
Bike has joined ##openfpga
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
mifune has quit [Read error: Connection reset by peer]
mifune has joined ##openfpga
m_t has joined ##openfpga
pie_ has joined ##openfpga
<azonenberg> rqou:dont know
Hootch has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<whitequark> yup
m_t has quit [Quit: Leaving]
<rqou> why does btrfs always have flaky metadata balancing problems?
<qu1j0t3> it's not mature yet? been a while
<lain> still not recommended for prod
<lain> just use zfs
<lain> on bsd*
<qu1j0t3> +1
<lain> zfs on linux is still... also not stable
<lain> :P
<rqou> afaik balancing bugs don'
<rqou> don't actually eat your data
* lain -> sleep
<rqou> they just give you weird failures all the time
<rqou> wtf lain
<lain> it's 1600 and I am /tired/
<rqou> isn't it afternoon for you?
<lain> been up since
<lain> forever
<rqou> lol, just got up over hear
<rqou> *here
<rqou> it's 12:58
<rqou> anyways, i've noticed that "bulk data transferring" with btrfs tends to be a bit flaky and give out of space errors
<rqou> haven't had that come up in normal usage
<rqou> anyways, i have about 2.5 million files here, so churning through the metadata might take a while :P
<pie_> ", Homeland Security Secretary John Kelly said that people visiting the United States may be asked to give up passwords to their social media accounts. "We want to get on their social media, with passwords: What do you do, what do you say?" Kelly told the House Homeland Security Committee. "If they don't want to cooperate then you don't come in.""
<pie_> what the fuck?
<pie_> is this real?
<rqou> making america great, one step at a time :P
Hootch has quit [Quit: Leaving]
mifune has quit [Read error: Connection reset by peer]
mifune has joined ##openfpga
mifune has joined ##openfpga
forrestv has quit [Read error: Connection reset by peer]
<rqou> i figured out why my btrfs balance was taking forever
<rqou> i didn't give it the "soft" option
<rqou> so it was reshuffling everything
<rqou> instead of "only what hasn't been shuffled already"
<rqou> balancing btrfs metadata makes my hard drives sound very sad