| mntmn | old reform unit (my personal) with kernel 5.1, sway, waybar, rofi, firefox. pretty snappy https://twitter.com/mntmn/status/1118248031558696961?s=21 | 01:14 |
|---|---|---|
| + darth-cheney (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 02:44 | |
| - darth-cheney (QUIT: Ping timeout: 246 seconds) (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 09:20 | |
| + darth-cheney (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 11:16 | |
| - darth-cheney (QUIT: Ping timeout: 250 seconds) (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 11:20 | |
| Jookia | mntmn: changing chipsets all of a sudden seems a bit risky | 11:56 |
| mntmn | jookia no risc no fun | 12:02 |
| Jookia | ok you got me | 12:02 |
| Jookia | isn't firmware still an issue | 12:02 |
| mntmn | for imx8m “only” ddr training and hdmi | 12:03 |
| mntmn | and hantro but that’s very optional | 12:03 |
| mntmn | hdmi is also not strictly required if you want to avoid it. leaves ddr training. we have to take a look at what that means. is it just a bunch of pokes or is it something turing complete? | 12:09 |
| mntmn | also we could potentially RE that part | 12:09 |
| Jookia | you'd probably have to scope it | 12:14 |
| mntmn | have you looked into the DDR stuff by any chance? | 12:14 |
| Jookia | nope | 12:16 |
| Jookia | it's proprietary so it must be impossible to do ;) | 12:17 |
| mntmn | https://community.nxp.com/docs/DOC-340179 | 12:19 |
| mntmn | imx6 has a ddr “blob” too, a bunch of pokes for setting the ram timing | 12:19 |
| mntmn | but nobody seems to have a problem with that :) it’s in u-boot | 12:19 |
| Jookia | oh really? | 12:19 |
| mntmn | sure, without it the system goes pretty crazy and spills garbage | 12:20 |
| Jookia | which file is it? just curious | 12:20 |
| mntmn | afaik you have to account for the properties of the ddr traces for every board or mem chip | 12:21 |
| Jookia | at this point it doesn't really bother me since it's code that runs one time and isn't going to do any weird security stuff | 12:22 |
| mntmn | https://github.com/mntmn/u-boot/blob/mntreform/board/mnt/reform/mntreform.cfg | 12:22 |
| mntmn | jookia exactly, that’s my opinion too | 12:22 |
| mntmn | the blob discussion needs to be much more differentiated | 12:23 |
| Jookia | there's also a lot more blobs such as the hardware itself and anything burned in to ROM | 12:23 |
| rvense | but theoretically the blob could do anything, right? | 12:23 |
| Jookia | the imx6's boot rom has a security vuln that effectively means anyone with physical access can bypass secure boot | 12:24 |
| rvense | same as the boot rom | 12:24 |
| Jookia | which is both proprietary and unfixable | 12:24 |
| rvense | Jookia: it does? | 12:24 |
| Jookia | yeah, it's an errata | 12:24 |
| Jookia | it's fixed on newer chips | 12:24 |
| rvense | huh, interesting | 12:24 |
| Jookia | it could theoretically do anything | 12:25 |
| mntmn | rvense, the question is, is the blob code or data | 12:25 |
| mntmn | and if code, for what kind of mcu/cpu/ip block and what can that do | 12:25 |
| mntmn | vs what hard code/data is in the ip anyway that you never see | 12:25 |
| rvense | very true | 12:26 |
| rvense | ftr i think you're completely right about nuance, both concerning blobs and other things | 12:27 |
| Jookia | it's strange to be OK with proprietary chips but not proprietary code that brings up the chips | 12:27 |
| mntmn | the safest bet would be something like xilinx zynq and then use only open IP for the graphics and IO, defined in the fpga part. | 12:27 |
| mntmn | jookia yes it’s irrational | 12:27 |
| Jookia | bunnie did a talk about all this a few years ago and suggested things like clearly defined interfaces with security fences | 12:28 |
| mntmn | cool | 12:28 |
| Jookia | if you didn't see it i can link | 12:28 |
| mntmn | please do | 12:28 |
| mntmn | example: if you hook up your black box baseband to your soc via pcie and let it dma anything then that’s not so smart | 12:29 |
| Jookia | it's from the 2017 and talks about risc-v, a bit about the novena, and expectations from the open source community versus the actual problems in hardware https://www.youtube.com/watch?v=zXwy65d_tu8 | 12:29 |
| Jookia | 25 minutes in is a good wakeup call :P | 12:30 |
| mntmn | thanks, gotta watch! | 12:32 |
| mntmn | i will do a bit more explaining but my current plan is to deliver a system that is as open and auditable as possible but at the same time also has enough performance for daily tasks | 12:34 |
| mntmn | 100% open is not possible today but it can be dramatically more open than a laptop from a big manufacturer | 12:35 |
| Jookia | yep | 12:35 |
| mntmn | and then iterate over the next years towards more and more openness, hopefully gain enough momentum to make it more attractive for chip suppliers etc / to be able to source risc-v chips or hybrid solutions with fpga | 12:37 |
| mntmn | while already all the mechanicals and input devices, custom pcbs are and will be open | 12:37 |
| mntmn | https://www.devever.net/~hl/ortega | 12:45 |
| rvense | i love the modular approach from so many perspectives. all those perfectly good displays, casings and keyboards that get thrown away because a transistor or two inside has failed or is deemed to old, it breaks my heart | 13:15 |
| + darth-cheney (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 13:16 | |
| - darth-cheney (QUIT: Ping timeout: 244 seconds) (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 13:20 | |
| mntmn | very true rvense | 13:24 |
| mntmn | i'm taking a closer look at the imx8 firmware files now | 13:24 |
| mntmn | hdmi firmware is for IP by cadence. it's one file, around 100kb. seemingly uncompressed, it has some strings like > SHA224..SHA256.. > $Revision: 12022 | 13:31 |
| mntmn | at the end it has a signature by NXP > 0x194C4 Certificate in DER format (x509 v3), header length: 4, sequence length: 680 | 13:31 |
| mntmn | it has a bunch of tables / gradient / LUT data and some stuff that looks like code, but binwalk -A doesn't find the architecture | 13:32 |
| mntmn | this diagram shows an "uCPU" in the cadence HD TX IP https://ip.cadence.com/uploads/images/DIP-v2-Images/HD-Display-TX-Controller.png | 13:38 |
| mntmn | this firmware blob is very similar and contains blocks of identical data https://github.com/woodsts/linux-firmware/blob/master/cadence/mhdp8546.bin | 13:45 |
| mntmn | referenced here https://patchwork.kernel.org/patch/10570461/ | 13:45 |
| mntmn | sorry, i mean referenced here in a driver https://patchwork.kernel.org/patch/10613795/ | 13:46 |
| mntmn | according to an etnaviv developer, the uCPU is most likely xtensa. | 14:03 |
| + darth-cheney (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 14:06 | |
| mntmn | AFAIK the DSP is also xtensa. this ISA is also popular in the form of the ESP wifi MCU chips | 14:06 |
| adjtm | mntmn, I really love Reform, it's the most exciting laptop since Novena, and it even improves some weakness of Novena! | 14:10 |
| mntmn | thanks adjtm | 14:10 |
| adjtm | but I disagree with you about changing SOC | 14:10 |
| mntmn | well, it's always possible to do a version with imx6 if you need that | 14:10 |
| adjtm | I don't use Novena as much as I'd like, but it is not because of lack of processing power, but because novena form factor is not very handy as a portable device | 14:11 |
| mntmn | like, we could backport some improvements to the existing board | 14:11 |
| adjtm | reform solves that problem | 14:11 |
| adjtm | also, xillinx tools are horrible, so I have played more with lattice fpgas than with the one included with novena | 14:12 |
| adjtm | another weakness of novena is the complexity, specially the power board that it's complex, with a lot of expensive components etc. | 14:13 |
| adjtm | reform is much more simple | 14:13 |
| mntmn | interesting, this PDF features "i.MX 10" https://community.nxp.com/servlet/JiveServlet/downloadBody/341872-102-2-287319/AMF-AUT-T3361.pdf | 15:00 |
| mntmn | and i.MX8DX | 15:00 |
| mntmn | Jookia, check page 20 of that pdf | 15:04 |
| mntmn | it shows the difference of DDR init between 8QM and 8MQ | 15:04 |
| mntmn | so, i.mx8m ddr init is done by SCU firmware. but i.mx8qm ddr init is just pokes! | 15:05 |
| Jookia | ooh, fun | 15:05 |
| mntmn | that's actually nice | 15:05 |
| mntmn | sorry, it's not SCU firmware on i.mx8m, it is > Performed by the PHY MCU (firmware loaded into MCU IRAM/DRAM) | 15:06 |
| mntmn | so on i.mx8qm everything is done by the SCU (which afaik is an ARM as well?) and on i.mx8m the DDR PHY (not the DDR controller!) has mystery meat MCU where those iram and dram files go | 15:07 |
| Jookia | yeah i believe the librem is loading the firmware to the DDR PHY | 15:08 |
| mntmn | both chips have the same DDR controller but not the same DDR PHY (8m has a newer with integrated MCU, 8qm has an older version that does not have such MCU) | 15:08 |
| mntmn | so in this regard for me the 8qm is better, one less mystery MCU there | 15:09 |
| Jookia | Purism are still loading the firmware from MMC -> CPU -> M4 CPU -> DDR PHY | 15:09 |
| Jookia | for some reason | 15:09 |
| mntmn | yes | 15:09 |
| Jookia | s/MMC/SPI/ in future | 15:10 |
| mntmn | they think this way they can get around some RYF rules | 15:10 |
| mntmn | which is silly | 15:10 |
| Jookia | It's not even running on the CPU :\ | 15:10 |
| mntmn | yes | 15:10 |
| mntmn | it's running on a mystery MCU in the PHY | 15:10 |
| mntmn | so it's complete nonsense to make some weird workaround there | 15:10 |
| mntmn | i wonder what kind of MCU that is. so far i couldn't get anything useful out of the binaries. | 15:11 |
| mntmn | aha "embedded calibration processor" https://www.synopsys.com/dw/images/ds/DDR43-phy-blockdiagram.jpg | 15:14 |
| mntmn | ok the ISA is ARC | 15:16 |
| mntmn | i have the datasheet, it says > The PUB also includes an embedded ARC® calibration processor to execute hardware-assisted, firmware-based training algorithms | 15:17 |
| Jookia | sweet | 15:18 |
| mntmn | that processor's job is to switch between different configuration states of the DDR reacting to temperature changes for example | 15:20 |
| mntmn | > – Each trained state can have unique frequency, I/O equalization and I/O drive and ODT impedance settings | 15:20 |
| mntmn | > – Frequency changes are initiated by the DFI interface without software involvement | 15:20 |
| mntmn | > – Each trained state is maintained across voltage and temperature variation | 15:20 |
| Jookia | sounds complicated | 15:35 |
| mntmn | can’t be super complicated, the firmware is quite little | 15:39 |
| mntmn | i’m trying to find an ARC disassembler | 15:39 |
| mntmn | ah https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases?after=arc-2017.03-eng002 | 15:41 |
| + B[] (~Thunderbi@122-61-190-38-fibre.sparkbb.co.nz) | 15:42 | |
| Jookia | beware reverse engineering tainting | 15:46 |
| Jookia | apparently to get ryf certification the blob can't touch the CPU, so they do it from SPI -> coprocessor -> DDR PHY | 16:17 |
| adjtm | Jookia, so for ryf certification the application processor can't read the blog but you can add an auxiliary processor to read it? | 16:19 |
| Jookia | apparently there's an exception that you can say the M4 CPU is a single-purpose CPU just for loading blobs | 16:20 |
| Jookia | and thus it's ok | 16:20 |
| mntmn | yeah i find that pretty silly because that doesn't make any difference for the user, except makes the init more complicated | 16:21 |
| Jookia | well, it means the user loses a CPU ;) | 16:22 |
| mntmn | arc disassembly yields no success. but this could be an RE project for later. i don't think it will have super much value though. i don't think the ddr phy interface is a security risk here | 16:22 |
| mntmn | Jookia: hehe | 16:22 |
| mntmn | true | 16:22 |
| mntmn | because the PHY firmware can't have access to the actual data on the DDR's data pins | 16:24 |
| mntmn | but anyway, this makes 8qm more attractive for me (no phy mcu). more realistic to use 8qm in a blob-free manner | 16:25 |
| Jookia | But doesn't that mean the 8qm will actually run a blob on the CPU | 16:27 |
| adjtm | where is the limit? can I add a PowerVR based SOC as a second processor running proprietary software (read it by itself from a flash), connect it to the main processor through ethernet, using glx to render and ask for ryf certification? | 16:28 |
| adjtm | that second processor would be single-propose, as the application processor only use it to render... | 16:28 |
| - darth-cheney (QUIT: Ping timeout: 246 seconds) (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 16:29 | |
| Jookia | i think the stance is ryf only applies to the CPU | 16:30 |
| Jookia | general purpose CPU | 16:31 |
| adjtm | so my propose could be approved? | 16:32 |
| adjtm | as soon as I do not document how to reflash the image for that second processor | 16:33 |
| Jookia | I think it's a case by case basis | 16:33 |
| Jookia | Like the standards that apply to the librem are different to the ones that applied to the Novena | 16:33 |
| Jookia | and EOMA68(?) | 16:34 |
| Jookia | I believe bunnie referenced in the video I linked that rms effectively wanted a custom version of the imx6 with hardware removed just because it could accept nonfree blobs | 16:36 |
| mntmn | Jookia, the ddr init code for the 8qm is pretty short and commented at least, sec | 16:40 |
| mntmn | https://github.com/Freescale/imx-mkimage/blob/master/iMX8QM/imx8qm_dcd_1.6GHz.cfg#L35 | 16:41 |
| Jookia | ah | 16:41 |
| mntmn | and it's only running once (at boot) | 16:42 |
| mntmn | radare2 / cutter can disassemble the imx8m DDR firmware when architecture set to "arc" | 16:46 |
| mntmn | it can also disassemble the hdmi firmware with architecture "xtensa" | 16:52 |
| Jookia | interesting | 17:23 |
| mntmn | i dumped my findings in a twitter thread, will do a real writeup at a later point https://twitter.com/mntmn/status/1118530994871705600?s=20 | 17:30 |
| + darth-cheney (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 18:25 | |
| - darth-cheney (QUIT: Ping timeout: 268 seconds) (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 18:30 | |
| + darth-cheney (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 20:25 | |
| - darth-cheney (QUIT: Ping timeout: 250 seconds) (~darth-che@pool-173-52-211-226.nycmny.fios.verizon.net) | 20:31 | |
| - B[] (QUIT: Ping timeout: 250 seconds) (~Thunderbi@122-61-190-38-fibre.sparkbb.co.nz) | 20:47 | |
| * andrej235 -> andrej_test | 21:25 | |
| * andrej_test -> andrej235 | 21:26 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
