| josch | vagrantc: the bl31.bin is found if i set BINMAN_INDIRS=/path/to/bl31.bin for "make all" | 00:04 |
|---|---|---|
| vagrantc | oh ... then we should be able to specify that the same way BL31 is specified for other platforms | 00:06 |
| vagrantc | that simplifies things a good deal :) | 00:06 |
| vagrantc | or maybe use BINMAN_INDIRS for all of them? | 00:06 |
| josch | i just don't understand why the BL31 variable doesn't work... | 00:06 |
| vagrantc | it's pretty much a wild west problem ... u-boot had so many highly divergent ways of doing things and even though it has been improving over the last decade or so, there is a lot of difference for difference sake ... | 00:11 |
| josch | vagrantc: another way to do it (maybe): could u-boot in main compile a (dfsg-free) imx flash.bin that misses (or has zeroed out) the ddr4 memory training blob (this flash.bin would of course be non-functional) but then the non-free part would grab the non-functionl but free flash.bin, combine it with the non-free ddr4 training blob and create a package that cain be uploaded to non-free? | 00:24 |
| josch | vagrantc: just grepping my flash.bin it seems that those blobs could be transplanted at a later stage | 00:26 |
| josch | vagrantc: so since the non-free blobs essentially never change, we know they have a fixed size. src:u-boot in main could produce placeholders of exactly the correct size with some magic signature at the beginning and put these into the (dfsg-free) flash.bin | 00:30 |
| josch | vagrantc: then src:u-boot-non-free would pick up these artifacts, search for the magic signatures and just replace the placeholder bytes with the non-free blobs | 00:31 |
| vagrantc | josch: does it build at all without them? ... or you replace it with dummy zeroed out versions? might be tricky to keep all the sizes matching exactly | 00:31 |
| josch | vagrantc: i'd inject zeroed out dummies, yes | 00:31 |
| josch | this might work because the sizes are fixed | 00:32 |
| josch | and even if the sizes change, it would just break a package in non-free | 00:32 |
| vagrantc | it wouldn't be the first non-working without other processing binary shipped in u-boot packages in Debian (e.g. u-boot-mvebu, u-boot-amlogic) | 00:32 |
| josch | uh interesting | 00:32 |
| vagrantc | so ... there's precedent ... although i think those have a process to convert them correctly out of the box | 00:33 |
| vagrantc | sort of | 00:33 |
| josch | shipping non-functional flash.bin might be a bit easier than shipping the whole u-boot source and trying to keep build-depends etc in sync between free and non-free u-boot | 00:34 |
| vagrantc | josch: fwiw, pushed the debian packaging up to 2023.07-rc1 ... shouldn't be hard to pull in the mnt/reform patch from mainline ... and maybe apply the other patches as well | 00:35 |
| vagrantc | josch: yeah, i can see the appeal ... big question gets down to how hard it will be to inject them, of course ... it may produce a checksummed image | 00:36 |
| vagrantc | i haven't poked at that layer in a long time :/ | 00:37 |
| josch | vagrantc: true -- i'll try to come up with a PoC to see how hard it is | 00:37 |
| vagrantc | josch: cool! | 00:37 |
| josch | saw your push to salsa -- thanks! | 00:37 |
| vagrantc | josch: if you can come up with a process to even do it manually ... we could ship it in debian experimental ... because ... it sounds good and experimental :) | 00:38 |
| josch | lets see :) | 00:39 |
| josch | first i'm gonna try out https://github.com/bluerise/u-boot/tree/mnt on my reform :) | 00:39 |
| vagrantc | might be able to do the same for librem5 | 00:39 |
| vagrantc | sure :) | 00:39 |
| vagrantc | hah. i still haven't put in my upgraded trackball ... | 00:41 |
| bluerise | josch: but that's old :D | 00:44 |
| vagrantc | simply weeks out of date | 00:44 |
| vagrantc | ACTION loves it when rebases go smoothly | 00:45 |
| josch | bluerise: are there newer commits? i thought i just rebase the top commits onto upstream git master | 00:45 |
| bluerise | Yeah | 00:45 |
| bluerise | I mean | 00:45 |
| bluerise | no | 00:45 |
| bluerise | wait | 00:45 |
| bluerise | + 0495e5ea3e...8bc893b989 mnt -> mnt (forced update) | 00:46 |
| bluerise | https://github.com/bluerise/u-boot/commits/mnt | 00:46 |
| bluerise | this should be fine (but untested by myself) | 00:46 |
| josch | nice | 00:47 |
| josch | bed for me now | 00:47 |
| josch | it's 00:47 AM over here :) | 00:47 |
| josch | good night! | 00:47 |
| bluerise | same here | 00:48 |
| vagrantc | ACTION waves | 00:52 |
| - chomwitt (QUIT: Remote host closed the connection) (~chomwitt@ppp-94-67-201-180.home.otenet.gr) | 01:11 | |
| vagrantc | u-boot 2023.07-rc1 + the patch from u-boot git adding mnt/reform2 works (at least as well as it used to for me) | 01:17 |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 01:26 | |
| - mtm- (QUIT: Ping timeout: 248 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:03 | |
| - ajr (QUIT: ) (~ajr@user/ajr) | 02:14 | |
| - qbit_m (PART: !!unknown attribute: msg!!) (~qbittapen@2001:470:69fc:105::194) | 02:43 | |
| - mjw (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 02:47 | |
| - nsc (QUIT: Ping timeout: 268 seconds) (~nicolas@130-48-142-46.pool.kielnet.net) | 03:26 | |
| + nsc (~nicolas@115-97-142-46.pool.kielnet.net) | 03:28 | |
| + mtm- (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:09 | |
| - gnou_liber (QUIT: Ping timeout: 268 seconds) (~gnou_libe@223.pool85-50-3.static.orange.es) | 04:12 | |
| + gnou_liber (~gnou_libe@223.pool85-50-3.static.orange.es) | 04:13 | |
| - q66 (QUIT: Ping timeout: 265 seconds) (~q66@q66.moe) | 06:57 | |
| + q66 (~q66@q66.moe) | 07:03 | |
| - gnou_liber (QUIT: Ping timeout: 268 seconds) (~gnou_libe@223.pool85-50-3.static.orange.es) | 08:12 | |
| + gnou_liber (~gnou_libe@72.pool85-52-202.static.orange.es) | 08:13 | |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 09:36 | |
| - austriancoder_ (QUIT: ) (sid152545@id-152545.hampstead.irccloud.com) | 09:58 | |
| + austriancoder (sid152545@id-152545.hampstead.irccloud.com) | 09:59 | |
| + MajorBiscuit (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 10:31 | |
| - MajorBiscuit (QUIT: Client Quit) (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 10:33 | |
| + MajorBiscuit (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 10:33 | |
| - MajorBiscuit (QUIT: Ping timeout: 256 seconds) (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 11:00 | |
| + MajorBiscuit (~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a) | 11:01 | |
| - MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a) | 11:08 | |
| + MajorBiscuit (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 11:21 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:43 | |
| - mjw (QUIT: Ping timeout: 256 seconds) (~mjw@gnu.wildebeest.org) | 12:10 | |
| * mark_ -> mjw | 12:19 | |
| - mtm- (QUIT: Ping timeout: 276 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:04 | |
| - gnou_liber (QUIT: Read error: Connection reset by peer) (~gnou_libe@72.pool85-52-202.static.orange.es) | 14:28 | |
| + gnou_liber (~gnou_libe@223.pool85-50-3.static.orange.es) | 14:28 | |
| + mark_ (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:35 | |
| - mark_ (QUIT: Remote host closed the connection) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:35 | |
| - mjw (QUIT: Quit: Leaving) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:35 | |
| + mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:36 | |
| * mjw -> dichen | 14:39 | |
| - dichen (QUIT: Quit: Leaving) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:41 | |
| + mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:43 | |
| * mjw -> dichen | 14:44 | |
| - dichen (QUIT: Client Quit) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:45 | |
| + mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:46 | |
| - mjw (QUIT: Remote host closed the connection) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:47 | |
| + mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:48 | |
| * mjw -> dichen | 14:48 | |
| - dichen (QUIT: Client Quit) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:51 | |
| minute | very interesting board https://olimex.wordpress.com/2023/05/05/our-most-complex-oshw-board-the-imx8quadmax-tukhla-project-first-prototypes-are-assembled-and-they-boot/ | 14:51 |
| + mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 14:51 | |
| + sbates (~sbates@user/sbates) | 15:41 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 15:42 | |
| - MajorBiscuit (QUIT: Quit: WeeChat 3.6) (~MajorBisc@2001:1c00:2408:a400:7f99:b6d8:c8b8:dc05) | 15:42 | |
| + mtm- (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:10 | |
| - mark_ (QUIT: Ping timeout: 256 seconds) (~mjw@gnu.wildebeest.org) | 16:34 | |
| josch | minute: are you thinking about cooperating? | 16:59 |
| minute | josch: well i would definitely like to give the board a spin | 17:00 |
| minute | afaik it needs a security blob though (seco) | 17:00 |
| minute | afaik it's meant to run two OSes in parallel and has two GPUs and stuff (the big i.mx8) | 17:01 |
| sigrid | looks like it can use both(?) gpus as one though? | 17:13 |
| Boostisbetter | that sounds like an amazing board. Would be very cool to see if it could be a part of the Reform lineup. | 17:38 |
| - sbates (QUIT: Quit: Leaving) (~sbates@user/sbates) | 17:52 | |
| + ajr (~ajr@user/ajr) | 17:54 | |
| Boostisbetter | I'm really looking forward to the Pocket Reform and the 8gb RAM it will have. | 17:57 |
| Boostisbetter | I am seeing, of course, that it isn't necessary to have more than 4gb, thanks to the Reform, but I think having more RAM to use instead of swap is a good thing. | 17:57 |
| sigrid | I am yet to use more than 1Gb ram on anything but filesystem cache | 17:59 |
| josch | i have been fine with 4 GB for nearly a year now | 18:02 |
| + nottheoilrig (~nottheoil@198-48-158-226.cpe.pppoe.ca) | 18:15 | |
| Boostisbetter | minute: does the Reform work if the batteries are removed but the DC is plugged in? | 18:17 |
| Boostisbetter | My system is usually sitting at 3.2 GB RAM in use and 2.4GB swap | 18:18 |
| mjw | it does | 18:18 |
| Boostisbetter | mjw: awesome | 18:18 |
| Boostisbetter | josch: in your case where your system is on all the time, do you think it would make sense to remove your batteries and keep them from power cycling? | 18:19 |
| Boostisbetter | or are the batteries so affordable that you don't really care, and the convience of being able to go on battery whenever you want the primary draw? | 18:19 |
| mjw | ACTION has to admit he has to run it that way because the batteries drained beyond recovery :{ | 18:20 |
| mjw | I need to order some new ones, they aren't that expensive indeed, but not always in stock | 18:20 |
| Boostisbetter | if you can try to get the 2000 mAH batteries from Eremit. | 18:21 |
| + ajr_ (~ajr@user/ajr) | 18:31 | |
| - ajr (QUIT: Ping timeout: 240 seconds) (~ajr@user/ajr) | 18:35 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 19:07 | |
| josch | Boostisbetter: but if i would remove the batteries, then my reform would be stuck to my couch -- how am i supposed to move it to other places where i want to use it without having to shutdown and boot it up again every time i'm moving it? | 19:10 |
| josch | vagrantc, bluerise: i have a proof-of-concept that replaces u-boot flash.bin built with empty dummy binaries of the ddr4 training blobs with the real blobs, creating a bit-by-bit identical flash.bin compared to compiling with the real blobs in the first place | 19:20 |
| josch | bluerise, vagrantc: the problem is signed_hdmi_imx8m.bin | 19:21 |
| josch | somehow that file is not contained varbatim inside flash.bin but gets processed somehow | 19:21 |
| josch | does somebody know how that processing looks like and/or where in the u-boot codebase it is done so that i can replicate it? | 19:22 |
| + mark_ (~mjw@gnu.wildebeest.org) | 19:29 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mjw@gnu.wildebeest.org))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 19:31 | |
| * mark_ -> mjw | 19:31 | |
| + mark_ (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 19:31 | |
| josch | vagrantc: alternatively, since i'd call hdmi support optional, the patching method already is producing a working u-boot binary | 19:39 |
| vagrantc | josch: nice progress! | 19:47 |
| josch | it'd be really nice to do the same thing for the cadence hdmi blob though :) | 19:47 |
| vagrantc | josch: bigger question is does it boot when you re-add the binaries? | 19:48 |
| josch | vagrantc: i didn't try because the result is bit-by-bit identical to u-boot built with the non-dummy versions (if one sets SOURCE_DATE_EPOCH) | 19:49 |
| vagrantc | ah, yes. reproducible builds for the win! | 19:49 |
| josch | it's the best! :D | 19:49 |
| josch | 99% of my reproducible builds modivation just comes from it making software development so much easier | 19:50 |
| vagrantc | :) | 19:50 |
| josch | so i see signed_hdmi_imx8m.bin referenced in arch/arm/dts/imx8mq-u-boot.dtsi -- which part parses the dtsi and thus munges the arch/arm/dts/imx8mq-u-boot.dtsi? | 19:51 |
| josch | *munges the signed_hdmi_imx8m.bin | 19:51 |
| vagrantc | josch: as to what mangles the signed_hdmi bianries ... wild guess would be tools/imx8mimage.c | 19:51 |
| josch | vagrantc: that looks very promising, thank you! | 19:52 |
| josch | /* The signed HDMI FW has 0x400 IVT offset, need remove it */ | 19:53 |
| josch | aha! | 19:53 |
| vagrantc | i will be curious if it works by leaving the HDMI blanked out or not | 19:56 |
| vagrantc | i suspect it is building a FIT image ... which i am pretty sure has checksums | 19:56 |
| josch | vagrantc: is there any advantage of not putting the hdmi blob in there as well? | 19:57 |
| josch | s/as well// | 19:57 |
| Boostisbetter | minute: I ordered the keycap replacements, and was wondering if they might have already shipped? I know you all are busy. | 20:21 |
| josch | vagrantc: okay i now can produce replacement blobs with which i can build u-boot and then later replace those dummy blobs with the real non-free blobs creating a bit-by-bit identical flash.bin | 20:54 |
| josch | the dummies are produces with a small shell script, the replacement with a short python script | 20:54 |
| josch | the dummies are all zero except a short header including the filename, size and sha1sum | 20:55 |
| josch | vagrantc: any thoughts? | 20:55 |
| josch | the cadence hdmi magic was indeed just to strip off the 0x400 bytes of IVT header | 20:55 |
| minute | Boostisbetter: currently on vacation (this week). when something ships, you get a ups tracking email. | 20:57 |
| - ajr_ (QUIT: ) (~ajr@user/ajr) | 21:04 | |
| vagrantc | josch: that sounds great ... could include it in a u-boot-imx package and update the relevent README.Debian or whatnot | 21:11 |
| vagrantc | josch: and include the python script in examples? or maybe make it executable somewhere? dunno. | 21:12 |
| vagrantc | josch: as to leaving out the signed_hdmi bits ... i guess no, not really much reason, given it requires the ddr training blobs | 21:23 |
| josch | vagrantc: src:u-boot has to ship the dummy blobs. But src:u-boot cannot contain the script creating the dummies because that script requires non-free material, making src:u-boot belong into contrib. I'd put both the script creating the dummy blobs and the script doing the patching in a src:u-boot-imx package and upload that to contrib. The src:u-boot-imx package can then depend on the non-free | 21:23 |
| josch | firmware-imx package. | 21:24 |
| josch | vagrantc: this would of course mean that src:u-boot would ship blobs "without source" but i'd argue that those blobs are trivial enough to be written by hand | 21:24 |
| josch | (i mean it's just all zeroes except for a filename, a size and a hash) | 21:24 |
| josch | (you'd also not require the source for a textfile containing that information) | 21:25 |
| vagrantc | josch: i guess i have a more liberal reading that a script that could be used to embed arbitrary blobs is not in and of itself non-free ... even though technically the only known working blobs are currently non-free | 21:25 |
| josch | vagrantc: i tried the same argument for a game engine for which there are currently only non-free graphics even though it's theoretically possible to draw free alternatives. Still ftp-master deemed that engine to be for contrib. | 21:26 |
| josch | vagrantc: i'll not stop you from uploading (and i won't be the one filing any bugs complaining) | 21:27 |
| vagrantc | josch: the script that generates the zero'd blobs ... does it actually require the blobs for the sizing? | 21:28 |
| vagrantc | or other headers? | 21:28 |
| josch | vagrantc: the script creating the zeroed blobs requires the blobs to get the size and hash of them | 21:28 |
| vagrantc | e.g. could it just be included in the src:u-boot package | 21:28 |
| vagrantc | got it. | 21:28 |
| vagrantc | hrm. | 21:28 |
| josch | alternatively, i could also throw that script away and just hand you the blobs | 21:28 |
| josch | since the non-free blobs won't change, the zeroed blobs won't either | 21:29 |
| vagrantc | this is definitely getting into really weird grey areas :/ | 21:29 |
| josch | yuuuup | 21:29 |
| josch | should i talk to #ftp-master? | 21:29 |
| vagrantc | it would probably be harder ... but almost wonder if you couldn't regenerate the hash too ... | 21:30 |
| josch | what do you mean by "regenerate the hashes"? | 21:31 |
| vagrantc | alternately, maybe we could ship the components that flash.bin is constructed out of ... | 21:31 |
| vagrantc | josch: ship with hashes for the zero'd out blobs, and then replace both the blobs and the hashes | 21:32 |
| vagrantc | we used to do that sort of thing for sunxi and rockchip systems ... just ship components that had to be manually assembled | 21:32 |
| josch | vagrantc: you mean instead of containing the blobs, src:u-boot would contain a table with sizes and hashes and create the blobs from that? | 21:33 |
| vagrantc | josch: build it with some dummy firmware, doesn't even match the size, and then re-build the flash.bin from all the various parts | 21:34 |
| vagrantc | or no firmware at all ... flash.bin is constructed out of some u-boot-imx.bin + ddr blob + hdmi blob ... so just ship the u-boot-imx.bin part? | 21:35 |
| vagrantc | kind of obnoxious | 21:35 |
| vagrantc | why do vendors have to think they have some magic special sauce that needs to be kept private ... when in reality there's probably nothing particularly special about it | 21:36 |
| vagrantc | just an arbitrarily different way of doing something ... | 21:36 |
| + v4rke_ (~v4rke@88.135.20.160) | 21:37 | |
| vagrantc | josch: i guess this makes me more thinking of the src:u-boot producing a u-boot-src package, and then a u-boot-non-free-firmware package that builds things for non-free-firmware out of that | 21:38 |
| vagrantc | or inclines me to think that approach would be worth doing | 21:38 |
| vagrantc | can still use the zero'd out blobs until the firmware package becomes available ... | 21:38 |
| vagrantc | a size and a hash are not source code ... per se. | 21:39 |
| vagrantc | and once the imx-firmware package becomes available, can just use that to build the complete images. | 21:40 |
| vagrantc | this also opens the door to various other flexible options in the grey area space... | 21:41 |
| josch | vagrantc: i still think duplicating the u-boot building process in a second source package would be more complex but if you're doing it i'm not going to complain :) | 21:41 |
| - v4rke_ (QUIT: Ping timeout: 256 seconds) (~v4rke@88.135.20.160) | 21:42 | |
| vagrantc | josch: more complex, yes, but also more clear in a way ... | 21:42 |
| josch | those who do the work get to decide | 21:42 |
| josch | you just tell me whether i should send you patches for the approach that i tried just now or not :) | 21:43 |
| vagrantc | so, presuming the licensing on these blobs is at least ok for non-free-firmware ... this would make it possible to have a works-out-of-the-box debian-installer (and maybe live image) for the mnt/reform2 officially supported on debian | 21:44 |
| vagrantc | so, that is pretty exciting | 21:44 |
| vagrantc | josch: i'd like to at least take a look at what you've done, definitely! | 21:44 |
| JC[m] | that is definitely exciting - I know how excited I was when the Olimex TERES-I worked with vanilla d-i | 21:45 |
| josch | vagrantc: then let me just quickly share my PoC shell and python script before investing the time to polish them (and probably combine them into a single python script) | 21:45 |
| josch | vagrantc: https://paste.debian.net/hidden/f5b7b78c/ | 21:46 |
| josch | vagrantc: https://paste.debian.net/hidden/66292194/ | 21:46 |
| vagrantc | ah, you're also using the ATF from the blobs | 21:47 |
| vagrantc | i forget if i am using that or the arm-trusted-firmware from the package in debian | 21:48 |
| vagrantc | that might explain the different issues | 21:48 |
| josch | vagrantc: ah you mean that the bugs you see result from the different ATF you are using compared to me? | 21:48 |
| josch | i shall try out the version from arm-trusted-firmware next, then | 21:49 |
| vagrantc | josch: that's a theory | 21:50 |
| vagrantc | e.g. wifi and display/drm/sway issues | 21:50 |
| vagrantc | yeah, i'm definitely using arm-trusted-firmware from Debian | 21:53 |
| vagrantc | oh, i should try the switch to BINMAN_INDIRS | 21:55 |
| vagrantc | the other difference is i haven't been quite confident of reflashing my SD card so i interrupt u-boot in order to swap in the SD card with /boot on it when testing the newer version | 21:57 |
| josch | i only have u-boot on my sd-card and nothing else (/boot is on emmc) | 21:58 |
| vagrantc | i tend to avoid using things that are hard-to-remove and fix ... but that does seem compelling | 21:58 |
| josch | vagrantc: that's why i want to move my /boot to nvme! :D | 21:59 |
| vagrantc | indeed | 21:59 |
| vagrantc | ACTION tries with bl31-iMX8MQ.bin instead | 22:08 |
| vagrantc | changing out ATF didn't appear to change my issues with mainline u-boot. hrm. | 22:19 |
| vagrantc | oh ... i wonder | 22:20 |
| bluerise | hm? | 22:23 |
| bluerise | what's going on? | 22:23 |
| bluerise | I usually use NXP's newest firmware-imx drop | 22:24 |
| bluerise | oh and... hm... bl31... | 22:24 |
| bluerise | NXP's branch/fork, because I think ATF's upstream branch might not work anymore really | 22:24 |
| vagrantc | hah. | 22:25 |
| vagrantc | my issues were due to the fact that the old vendor u-boot only booted boot.scr, but the new u-boot supported extlinux.conf ... and extlinux.conf did not pass all the same boot commandline arguments | 22:26 |
| vagrantc | that's a relief to have figured out at least | 22:27 |
| bluerise | hah | 22:28 |
| bluerise | nice | 22:28 |
| josch | vagrantc: a relief indeed! you are not generating your extlinux.conf using u-boot-menu? | 22:30 |
| vagrantc | josch: i am using u-boot-menu ... but maybe i don't have some hooks installed? | 22:31 |
| josch | vagrantc: i placed all the hooks that make it work into the reform-tools package | 22:31 |
| josch | vagrantc: https://source.mnt.re/reform/reform-tools/-/tree/main/u-boot-menu | 22:31 |
| vagrantc | josch: ah, don't have that installed | 22:32 |
| vagrantc | the image i'm running off of was a very stripped down v3 image that has been upgraded a bit over time | 22:32 |
| Boostisbetter | minute: awesome! Have a great vacation! | 23:01 |
| vagrantc | hrm. so every once in a while, i hit the circle button and it just freezes :/ | 23:21 |
| chartreuse | Alright digikey parts arrived today, gotta work up the courage and replace the mosfet now | 23:26 |
| minute | chartreuse: good luck! | 23:36 |
| chartreuse | Only main concern is getting it off without a hotplate, but I do plan on preheating the backside evenly with the hot air first | 23:37 |
| chartreuse | And then when soldering it down making it flat , but that should be alright | 23:37 |
| chartreuse | Already got the motherboard out and all the removable parts out so should be fine | 23:37 |
| chartreuse | I did also RTV down my audio capacitors since I was worried the heat might cause the superglue they were supported by to fail | 23:38 |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 23:56 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!