| - S0rin (QUIT: Ping timeout: 268 seconds) (~S0rin@user/s0rin) | 00:31 | |
| + S0rin (~S0rin@user/s0rin) | 00:32 | |
| - mtm (QUIT: Ping timeout: 252 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 01:04 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 01:04 | |
| flowy | minute: praise the wasd | 01:20 |
|---|---|---|
| - Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149-210-16-8.mobile.nym.cosmote.net) | 01:46 | |
| + Ar|stote|is (~linx@149-210-16-8.mobile.nym.cosmote.net) | 01:46 | |
| - ajr (QUIT: Ping timeout: 272 seconds) (~ajr@user/ajr) | 02:18 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:40) | 02:21 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 03:09 | |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 03:31 | |
| - jackhill (QUIT: Ping timeout: 264 seconds) (~jackhill@kalessin.dragonsnail.net) | 03:37 | |
| - nsc (QUIT: Ping timeout: 256 seconds) (~nicolas@134-49-142-46.pool.kielnet.net) | 03:40 | |
| + nsc (~nicolas@8-49-142-46.pool.kielnet.net) | 03:41 | |
| * nsc -> Guest2700 | 03:42 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:40) | 06:12 | |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:05 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:05 | |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 07:15 | |
| * wielaard -> mjw | 10:03 | |
| - XYZ (QUIT: Ping timeout: 260 seconds) (~XYZ@89-24-50-119.nat.epc.tmcz.cz) | 10:03 | |
| + MajorBiscuit (~MajorBisc@145.94.179.130) | 10:51 | |
| - MajorBiscuit (QUIT: Ping timeout: 256 seconds) (~MajorBisc@145.94.179.130) | 11:36 | |
| minute | there are new imx8mq errata | 11:49 |
| minute | https://www.nxp.com/docs/en/errata/IMX8MDQLQ_2N14W.pdf | 11:49 |
| minute | ERR051273 could be the cause of random lockups on resume | 11:49 |
| + XYZ (~XYZ@89-24-50-119.nat.epc.tmcz.cz) | 11:50 | |
| - XYZ (QUIT: Read error: Connection reset by peer) (~XYZ@89-24-50-119.nat.epc.tmcz.cz) | 11:57 | |
| + XYZ (~XYZ@89-24-50-119.nat.epc.tmcz.cz) | 11:58 | |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 12:44 | |
| - mtm (QUIT: Ping timeout: 265 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 13:04 | |
| + MajorBiscuit (~MajorBisc@145.94.179.130) | 13:45 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 15:09 | |
| - mtm (QUIT: Read error: Connection reset by peer) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:13 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:16 | |
| - MajorBiscuit (QUIT: Quit: WeeChat 3.6) (~MajorBisc@145.94.179.130) | 16:50 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 17:54 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 18:12 | |
| sigrid | seems like the trackball "falls off" on its own sometimes, for unknown to me reason. that's the newest one | 18:13 |
| sigrid | just idling for a long time was enough once | 18:13 |
| cinap_lenrek | sigrid: i had issues with the cable | 18:14 |
| cinap_lenrek | sigrid: i crimped my own cable and that fixed the issue | 18:14 |
| sigrid | I'd imagine a cable wouldn't be moving on its own inside the laptop :) | 18:15 |
| cinap_lenrek | like the jack was kind of loose | 18:15 |
| cinap_lenrek | if you widdgled the cable it would disconnect from usb | 18:15 |
| sigrid | I see | 18:15 |
| sigrid | also interesting: if I boot off a usb flash drive, then reboot, u-boot does not detect the flash drive | 18:16 |
| sigrid | I have to reset the reform | 18:16 |
| cinap_lenrek | thats odd | 18:17 |
| cinap_lenrek | was we do reset the usb hub | 18:17 |
| sigrid | yeah | 18:17 |
| cinap_lenrek | well | 18:17 |
| cinap_lenrek | the internal hub | 18:17 |
| cinap_lenrek | but yeah | 18:17 |
| cinap_lenrek | wiggle the connector sigrid on the trackball | 18:18 |
| cinap_lenrek | i never had issues with the keyboard tho | 18:18 |
| cinap_lenrek | only the trackball connector | 18:18 |
| sigrid | I'll try that next time I have that issue | 18:18 |
| cinap_lenrek | i think maybe the jst connector is like slightly the wrong size? | 18:18 |
| sigrid | re the usb flash: if I do "usb stop; usb start" (a rescan) it appears | 18:20 |
| sigrid | perhaps some timings are wrong :/ | 18:20 |
| cinap_lenrek | yeah | 18:20 |
| vagrantc | does the trackball need to be available in u-boot? | 18:21 |
| cinap_lenrek | no | 18:21 |
| cinap_lenrek | its only usbkdb.c | 18:21 |
| sigrid | hmmm. are external ports on the same hub? does that question even make sense | 18:22 |
| cinap_lenrek | theres some usb info command | 18:23 |
| cinap_lenrek | printing the tree | 18:23 |
| cinap_lenrek | or use usbtree in 9front | 18:23 |
| cinap_lenrek | i dont remember it | 18:23 |
| sigrid | yeah, it's a different hub | 18:24 |
| cinap_lenrek | for xhci, the port reset should be handled by the xhci controller | 18:37 |
| cinap_lenrek | (usb3) | 18:37 |
| cinap_lenrek | otherwise, you need to see the port status change to present and then issue a port reset | 18:37 |
| cinap_lenrek | all with some timing delays from the spec | 18:37 |
| cinap_lenrek | and after reset it should go to enabled state | 18:37 |
| - mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 18:38 | |
| + mjw (~mjw_@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 18:39 | |
| minute | sigrid: so, there is a root port/hub with 2 ports in imx8mq. one of these goes directly to the outside. the other goes to an internal TUSB8041 hub and is split into 4 ports, 2 of them outside, two inside. | 18:46 |
| minute | also kind of visible here: https://mntre.com/reform2-handbook/system.html | 18:47 |
| + ajr (~ajr@user/ajr) | 18:47 | |
| + bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 18:51 | |
| minute | weird line in lpddr4_init.c of reform-boundary-uboot: | 19:01 |
| minute | #ifdef DFI_BUG_WR | 19:01 |
| minute | reg32_write(DDRC_DFIPHYMSTR(0), 0x00000001); | 19:01 |
| minute | #endif | 19:01 |
| minute | so looks like this erratum doesn't apply to us anyway :| | 19:05 |
| cinap_lenrek | minute: what errata is this? the write basically clears the whole register except the ddr3 bit | 19:08 |
| cinap_lenrek | sorry | 19:10 |
| cinap_lenrek | wrong device | 19:10 |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 19:21 | |
| cinap_lenrek | doesnt appear to be documented register | 19:31 |
| cinap_lenrek | yeah | 19:32 |
| minute | cinap_lenrek: ERR051273 | 19:32 |
| minute | cinap_lenrek: newly released, https://www.nxp.com/docs/en/errata/IMX8MDQLQ_2N14W.pdf | 19:32 |
| cinap_lenrek | the document ends at +0x1C0 DM/DBI Control Register, and continues at +0x200 | 19:32 |
| minute | huh. | 19:32 |
| + bkeys1 (~Thunderbi@157.201.98.1) | 19:36 | |
| eery[m] | Can the rescue image be updated by just copying over the image from the build artifacts? | 20:36 |
| josch | eery[m]: that will remove whatever was on the sd-card before but after that, yes, then you will have an sd-card with an updated rescue image | 20:40 |
| eery[m] | What about emmc? Just making sure there isn't an extra step I'm missing before I have to take everything apart again haha | 20:43 |
| josch | eery[m]: there is a script to update your emmc with the latest rescue image | 20:48 |
| josch | reform-flash-rescue | 20:48 |
| minute | i just merged https://source.mnt.re/reform/reform-boundary-uboot/-/merge_requests/12 | 20:52 |
| minute | and now i will test it :D | 20:52 |
| minute | josch: u-boot nowadays doesn't need different builds for emmc or sd card, or? | 20:54 |
| eery[m] | Yeah, I've been following the source, just paranoid about soft-bricking my reform | 20:54 |
| eery[m] | Running fedora on nvme so I don't have the tools on root | 20:54 |
| eery[m] | Should probably look into packaging them in a copr repo or something | 20:54 |
| josch | minute: yes, the u-boot binary on both can be the same | 20:57 |
| minute | josch: thanks! | 20:59 |
| josch | minute: thanks for merging -- if it cannot read emmc, try this patch by sigrid on top of master: https://mister-muffin.de/p/LOou.diff | 21:01 |
| josch | i've been running that u-boot with this patch on top since last week | 21:02 |
| sigrid | don't need that one anymore, josch | 21:02 |
| josch | oh what changed? | 21:02 |
| sigrid | https://source.mnt.re/reform/reform-boundary-uboot/-/merge_requests/12/diffs?commit_id=278763f01b90e2d81508544d68755e3284030fff | 21:03 |
| sigrid | this fixes it | 21:03 |
| josch | uuuh sweet! | 21:04 |
| minute | it worked immediately! | 21:06 |
| minute | the new flash.bin that is, on emmc. | 21:06 |
| minute | this is pretty great | 21:07 |
| cinap_lenrek | yep, figured it out since last weekend | 21:07 |
| minute | bluerise: how do we get openbsd going? now there's a framebuffer! | 21:07 |
| cinap_lenrek | studying the boot sequence on the imx8mq | 21:10 |
| cinap_lenrek | its all pretty silly | 21:10 |
| cinap_lenrek | so actually the uboot spl is the first code | 21:10 |
| cinap_lenrek | and then for some reason that launches ATF and THAT launches the 2nd stage uboot? | 21:11 |
| cinap_lenrek | what *IS* atf actually doing? its not initializing the ddr | 21:12 |
| cinap_lenrek | its hust tere for PSCI handler? | 21:12 |
| minute | yeah, it doesn't do much. i guess it also handles a little bit of wakeup from sleep | 21:14 |
| minute | if you also put the ddr to sleep, it can recalibrate it, but i'm not sure if that actually works | 21:14 |
| sigrid | minute: openbsd probably just needs simple-framebuffer to be set in the dtb | 21:14 |
| minute | sigrid: cool, i wonder if the other imx8m drivers are upstreamed though | 21:15 |
| cinap_lenrek | this whole EL3 stuff makes me nervous | 21:16 |
| minute | cinap_lenrek: what's that | 21:16 |
| cinap_lenrek | it is exactly the same SMM shit that intel gets critisized for | 21:16 |
| minute | ah, at-f running in some privileged zone? | 21:17 |
| cinap_lenrek | yeah | 21:17 |
| minute | tf-a | 21:17 |
| minute | a-tf | 21:17 |
| minute | you know | 21:17 |
| cinap_lenrek | apparently they also stopped maintaining it | 21:17 |
| minute | cinap_lenrek: well, at least it is open source and also much smaller than minix | 21:17 |
| cinap_lenrek | the readme on the atf website sais they dropped imx8mq support because the ocram is too small | 21:17 |
| - ajr (QUIT: Ping timeout: 265 seconds) (~ajr@user/ajr) | 21:17 | |
| minute | cinap_lenrek: also, much less features | 21:17 |
| minute | and it's turned off if computer is off | 21:17 |
| minute | cinap_lenrek: haha, sounds good actually | 21:18 |
| minute | IMHO atf is pretty useless and shouldn't exist | 21:18 |
| minute | i'm sure it was only made for DRM purposes | 21:18 |
| cinap_lenrek | i think it was for power management | 21:18 |
| minute | so you can run netflix video decryption in secure world | 21:19 |
| cinap_lenrek | like to handle the chip specific details of turning off cores and handle the memory coherency for this stuff | 21:19 |
| minute | well, i think the OS should do that stuff | 21:19 |
| cinap_lenrek | but then it is all pretty scary | 21:19 |
| cinap_lenrek | given that atf doesnt have no knowledge of the full platform really | 21:19 |
| cinap_lenrek | at leeast in our case | 21:19 |
| cinap_lenrek | so its kind of a inversion | 21:19 |
| minute | yeah | 21:19 |
| minute | https://github.com/freebsd/freebsd-src/tree/main/sys/arm64/freescale/imx | 21:21 |
| minute | funny, it looks like freebsd just imports all the linux dtses https://github.com/freebsd/freebsd-src/blob/b97ee269eae3cbaf35c18f51a459aea581c2a7dc/sys/contrib/device-tree/src/arm64/freescale/imx8mq-mnt-reform2.dts | 21:24 |
| cinap_lenrek | minute → cinap_lenrek: well, at least it is open source and also much smaller than minix | 21:31 |
| cinap_lenrek | that is just for the management engine imho | 21:31 |
| cinap_lenrek | i mean, if all these hidden cores would actually DO something usefull for you | 21:32 |
| cinap_lenrek | but no | 21:32 |
| cinap_lenrek | you still have todo everything yourself | 21:32 |
| minute | oh, it is booting opensbd | 21:33 |
| minute | openbsd | 21:33 |
| cinap_lenrek | hahaha | 21:33 |
| cinap_lenrek | naice | 21:33 |
| minute | the keyboard flashes once | 21:33 |
| minute | i think it really just needs simple-framebuffer added to the dtb like sigrid said | 21:33 |
| minute | what i did was: write miniroot72.img to an sd card from here: https://ftp.uni-hannover.de/openbsd/snapshots/arm64/ | 21:34 |
| cinap_lenrek | we put the framebuffer address in the gd->fb_base | 21:34 |
| minute | then i did: load mmc 0:1 ${fdt_addr_r} dtb | 21:34 |
| cinap_lenrek | i saw for some image targets that it uses this information to pass it on | 21:34 |
| minute | (loaded reform dtb from emmc) | 21:34 |
| minute | then: load mmc 0:1 ${kernel_addr_r} efi/boot/bootaa64.efi | 21:34 |
| minute | and: bootefi ${kernel_addr_r} ${fdt_addr_r} | 21:34 |
| - Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149-210-16-8.mobile.nym.cosmote.net) | 21:35 | |
| + Ar|stote|is (~linx@149-210-16-8.mobile.nym.cosmote.net) | 21:37 | |
| minute | screenshots: https://mastodon.social/@mntmn/109712128428780443 | 21:39 |
| cinap_lenrek | wow | 21:41 |
| cinap_lenrek | nice | 21:41 |
| cinap_lenrek | but the kernel doesnt print, no? :( | 21:41 |
| - mjw (QUIT: Killed (NickServ (GHOST command used by markw!~wielaard@gnu.wildebeest.org))) (~mjw_@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 21:42 | |
| + wielaard (~mjw_@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 21:43 | |
| minute | cinap_lenrek: i think it maybe prints to serial | 21:43 |
| cinap_lenrek | its strange tho | 21:43 |
| minute | cinap_lenrek: also i didn't do any framebuffer passing yet | 21:43 |
| cinap_lenrek | wouldnt uefi be able to pass the framebuffer? | 21:43 |
| minute | hmm, good question! | 21:44 |
| cinap_lenrek | i mean uefi itself knows it | 21:44 |
| minute | maybe it doesn't touch the dtb | 21:44 |
| cinap_lenrek | otherwise it wouldnt print the load message | 21:44 |
| minute | well, i guess it prints via some kind of stdout mechanism? | 21:44 |
| cinap_lenrek | yeah, but uefi has a protocol | 21:44 |
| minute | also it prints the addresses of the usdhc controllers, so it knows something about the hardware :D | 21:44 |
| cinap_lenrek | usually, you efi loader will get it from there and then pass it to the kernel in whatever convention the kernel needs | 21:45 |
| minute | yeah, unfortunately i know almost nothing about uefi | 21:45 |
| sigrid | you can try adding that simple framebuffer to the dtb like linux uses | 21:45 |
| sigrid | maybe that is enough | 21:45 |
| bluerise | cinap_lenrek: no reason to criticise ATF, it's open source, there are no secrets, isn't that nice? | 21:45 |
| minute | sigrid: yeah, i'm just a bit too tired now | 21:45 |
| bluerise | the biggest secret is t he ddr firmware | 21:45 |
| bluerise | and hdmi | 21:45 |
| minute | btw, imx8mp doesn't have no more hdmi firmware | 21:45 |
| minute | (afaik) | 21:45 |
| bluerise | minute: try entering "set tty fb0" when it says boot> | 21:46 |
| bluerise | it might default to the serial line | 21:46 |
| minute | bluerise: ah, i wasn't aware that i can type something there | 21:46 |
| bluerise | so, "set tty fb0", then "boot" | 21:46 |
| bluerise | that's the bootloader :) | 21:46 |
| minute | gonna try it | 21:47 |
| bluerise | if that doesn't work, it's possible u-boot doesn't create the simple-framebuffer node | 21:47 |
| - bkeys1 (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@157.201.98.1) | 21:47 | |
| cinap_lenrek | bluerise: i'm a master in complaining, indeed :) | 21:47 |
| bluerise | and if boundary devices had a recent u-boot, all that manual load mmc stuff wouldn't be necessary thanks to distroboot | 21:47 |
| minute | bluerise: distroboot is possible i think, i just wanted to do it manually | 21:48 |
| minute | because i'm loading the dtb from another disk | 21:48 |
| cinap_lenrek | bluerise: i just wish it wouldnt need to be resident | 21:48 |
| cinap_lenrek | bluerise: that opens quite some attack surface :( | 21:48 |
| sigrid | rpi uboot seems to call lcd_dt_simplefb_add_node | 21:49 |
| cinap_lenrek | we had this guy (aiju) that made his own board based on a zynq | 21:49 |
| bluerise | I believe there are quite some more attack surfaces than that | 21:49 |
| cinap_lenrek | and there was no firmware at all | 21:49 |
| cinap_lenrek | it could all be brought up from scratch, right from the first instruction | 21:49 |
| minute | oh, it actually works automatically | 21:49 |
| minute | BSD bootloader is loaded automatically if the sd card is in the slot | 21:49 |
| bluerise | that's nice | 21:50 |
| minute | and yeah, i can type commands in the boot> prompt | 21:50 |
| minute | > switching console to fb0 | 21:50 |
| cinap_lenrek | i wish arm would have kept it this way | 21:50 |
| cinap_lenrek | but yeah. maybe i'm wrong | 21:50 |
| bluerise | i wish there was no risc-v | 21:50 |
| bluerise | they are re-doing all the same mistakes | 21:51 |
| bluerise | and it's not really open either | 21:51 |
| minute | sigrid: neat | 21:51 |
| bluerise | Damn, I'm now becoming the old-grump-internet-guy :) | 21:51 |
| minute | ok unfortunately it hangs after booting and i guess initializing usb | 21:51 |
| cinap_lenrek | bluerise: it depends on WHO's doing the same mistakes :) | 21:51 |
| minute | (after the booting sd0a:/bsd... line) | 21:51 |
| bluerise | hmhmhm | 21:51 |
| cinap_lenrek | bluerise: i think it is not surprising. it is the same peoble that do these arm socs before | 21:51 |
| bluerise | nah, one issue is that the instruction set is design by committee | 21:52 |
| minute | probably have to do serial debugging to see what's going on, eh | 21:52 |
| bluerise | compressed instructions, gets you back all those x86 gadgets | 21:52 |
| bluerise | minute: the lcd diff is already in your repo, right? | 21:52 |
| cinap_lenrek | it doesnt mean there could not be board with eigther good and well defined interfaces and clear responsibilities of which component does what bring up | 21:52 |
| minute | bluerise: it's merged yep | 21:52 |
| cinap_lenrek | that could as well also exist for arm | 21:52 |
| minute | bluerise: you just need to run build.sh in https://source.mnt.re/reform/reform-boundary-uboot | 21:53 |
| minute | bluerise: or use http://dump.mntmn.com/flash.bin | 21:53 |
| minute | dd if=flash.bin of=/dev/sda bs=1024 seek=33 | 21:53 |
| minute | ;) | 21:53 |
| minute | boot>'s ls even works, nice | 21:54 |
| cinap_lenrek | bluerise → nah, one issue is that the instruction set is design by committee | 21:55 |
| cinap_lenrek | it is like that probably everywhere | 21:55 |
| cinap_lenrek | even on arm | 21:55 |
| minute | cinap_lenrek: btw can i see the framebuffer address in u-boot somehow? i mean in the console | 21:55 |
| cinap_lenrek | for sure, that gic interrupt controller must have come out of 5 man years of comittee meetings given how overengineered it is | 21:56 |
| cinap_lenrek | minute: yes | 21:56 |
| cinap_lenrek | minute: bdinfo | 21:56 |
| bluerise | minute: which target is it? | 21:56 |
| cinap_lenrek | it should have a fb_base field | 21:57 |
| bluerise | nitrogen8m_som/ that one? | 21:57 |
| sigrid | cp mntreform-config .config | 21:57 |
| cinap_lenrek | it should be near the top of 4GB | 21:57 |
| bluerise | sigrid: :) | 21:57 |
| minute | bluerise: ah yeah, what sigrid said. sorry! | 21:57 |
| cinap_lenrek | if someone cares, i'm sure we could also make it fixed | 21:57 |
| cinap_lenrek | theres some memory reservation magic in common | 21:58 |
| sigrid | it seems like lcd_dt_simplefb_add_node is enough | 21:58 |
| sigrid | and it does not need to be a fixed address | 21:58 |
| minute | cinap_lenrek: ah yeah, FB base | 21:58 |
| cinap_lenrek | sigrid: fixed would have to advantage to keep it like RIGHT at the end of the first bank 2-4GB | 21:58 |
| minute | 0xfe540000 | 21:58 |
| cinap_lenrek | so you dont have like 2gb-fb fbend...4gb | 21:59 |
| cinap_lenrek | it just kind of sucks having the fb like in the middle of your dram map :D | 21:59 |
| minute | haha | 21:59 |
| sigrid | well... | 22:00 |
| sigrid | it's a... uh... BUFFER | 22:00 |
| minute | you can paint using mw.l 0xfe540000 0xffffffff 100 | 22:00 |
| sigrid | sorry this is a very stupid joke :( | 22:00 |
| minute | sigrid: lol | 22:00 |
| cinap_lenrek | minute: make some pascal triangles using uboot memory commands! | 22:01 |
| minute | mmmm | 22:01 |
| minute | i'm tempted to port interim | 22:01 |
| minute | it is kind of crappy though | 22:01 |
| cinap_lenrek | in the meanwhile, we can port doom to the M4 and have it run eternally in the background | 22:01 |
| minute | oh yeah! the M4 | 22:02 |
| minute | the forgotten 5th core | 22:02 |
| minute | on the imx8mp, it's a M7 IIRC | 22:02 |
| minute | at 800mhz or something? | 22:02 |
| cinap_lenrek | see? they have all these cores | 22:03 |
| cinap_lenrek | but none is like used to do some gritty init work | 22:03 |
| cinap_lenrek | i dont get it | 22:03 |
| minute | there's also a DSP | 22:03 |
| sigrid | on mp? | 22:03 |
| sigrid | :( | 22:03 |
| minute | yeah, > Cadence HIFI4 DSP | 22:04 |
| bluerise | sigrid: I tend to agree that it might be enough. one has to take care though that this buffer is carved out of the memory map, otherwise the OS might make use of it | 22:04 |
| minute | > This core runs either a custom firmware or the open source SOF firmware | 22:04 |
| cinap_lenrek | bluerise: its not a problem | 22:05 |
| bluerise | sigrid: problem is that the lcd_ stuff is not used on imx8, so I'm getting lots of undefined reference stuff | 22:05 |
| bluerise | need to solve that differently. | 22:05 |
| cinap_lenrek | even if you use it, you just get to SEE the contents of your memory! | 22:05 |
| cinap_lenrek | the lcdif just reads from it | 22:05 |
| sigrid | # CONFIG_LCD is not set | 22:05 |
| sigrid | # CONFIG_VIDEO_SIMPLE is not set | 22:05 |
| sigrid | perhaps this ^ | 22:05 |
| minute | bluerise: it's not building? | 22:06 |
| bluerise | cinap_lenrek: yes yes, and then my X11 writes into memory that's also used for user processes, eehhh | 22:06 |
| minute | bluerise: did you make clean? maybe you have an older build there? | 22:06 |
| minute | bluerise: (i had to do make clean initially i think) | 22:06 |
| cinap_lenrek | bluerise: well, at this point the os should be aware of the framebuffer address | 22:06 |
| cinap_lenrek | oh, wait | 22:06 |
| cinap_lenrek | you'r right | 22:06 |
| cinap_lenrek | they might expect the fb and memory map not be overlapping :D | 22:06 |
| minute | there's reserved-memory {} in dtb also | 22:08 |
| cinap_lenrek | i swear, we have tons of defensive code in the x86 port for this | 22:09 |
| cinap_lenrek | we only half trust the memory map | 22:09 |
| cinap_lenrek | if a pci device uses that range -> gets excluded from dram map | 22:10 |
| minute | i'm chatting with a Risc OS dev so we will be getting Risc OS | 22:10 |
| cinap_lenrek | just in case | 22:10 |
| minute | there was a almost-done port that just missed display setup | 22:10 |
| cinap_lenrek | pc bios/uefi is so broken | 22:10 |
| cinap_lenrek | minute: excellent! | 22:11 |
| cinap_lenrek | ok, lemme see this dtb magic | 22:13 |
| cinap_lenrek | ret = uclass_first_device_err(UCLASS_VIDEO, &dev); | 22:15 |
| cinap_lenrek | okay | 22:15 |
| cinap_lenrek | i think this means i have to make our lcdif.c register the video uclass thing | 22:15 |
| cinap_lenrek | let me look into this | 22:15 |
| cinap_lenrek | or alternatively that lcd interface | 22:16 |
| cinap_lenrek | hmmm | 22:16 |
| cinap_lenrek | xsize = lcd_get_pixel_width(); | 22:16 |
| cinap_lenrek | ysize = lcd_get_pixel_height(); | 22:16 |
| cinap_lenrek | bpix = LCD_BPP; | 22:16 |
| cinap_lenrek | fb_base = gd->fb_base; | 22:16 |
| minute | lgtm? | 22:16 |
| cinap_lenrek | okay, so lcd_get_pixel_width() comes from common/lcd.c | 22:17 |
| cinap_lenrek | okay | 22:18 |
| cinap_lenrek | and for this, we need to fill and export struct vidinfo panel_info; | 22:18 |
| cinap_lenrek | which is actually quite code to what i parse from edid | 22:19 |
| bluerise | I'm gonna try this http://ix.io/4lCb | 22:20 |
| cinap_lenrek | ah, wait | 22:20 |
| cinap_lenrek | its even easier | 22:20 |
| bluerise | no memory carving though, but that should give some output at least | 22:20 |
| cinap_lenrek | that only applies for CONFIG_DM_VIDEO | 22:20 |
| cinap_lenrek | if we dont have that, the struct is trivial | 22:20 |
| cinap_lenrek | typedef struct vidinfo { | 22:21 |
| cinap_lenrek | ushort vl_col;/* Number of columns (i.e. 160) */ | 22:21 |
| cinap_lenrek | ushort vl_row;/* Number of rows (i.e. 100) */ | 22:21 |
| cinap_lenrek | ushort vl_rot;/* Rotation of Display (0, 1, 2, 3) */ | 22:21 |
| cinap_lenrek | u_char vl_bpix;/* Bits per pixel, 0 = 1 */ | 22:21 |
| cinap_lenrek | ushort *cmap;/* Pointer to the colormap */ | 22:21 |
| cinap_lenrek | void *priv;/* Pointer to driver-specific data */ | 22:21 |
| cinap_lenrek | } vidinfo_t; | 22:21 |
| sigrid | who would have though getting pixels out is this much work, eh? | 22:23 |
| sigrid | *thought | 22:23 |
| cinap_lenrek | uboot is insane | 22:23 |
| cinap_lenrek | they have like 5 different driver apis for everything | 22:23 |
| cinap_lenrek | and EVERY single driver does some #ifdef maze and supports some kind of subset | 22:23 |
| bluerise | it's getting better | 22:24 |
| bluerise | it's just that the boundary fork is way too old | 22:24 |
| bluerise | VERSION = 2018 | 22:24 |
| bluerise | PATCHLEVEL = 07 | 22:24 |
| minute | bluerise: what's the concrete problem? do you need to change something on u-boot? | 22:24 |
| cinap_lenrek | its only getting better if the number of uboot forks in the universe decrease over time | 22:24 |
| minute | ah, sorry, misread the log | 22:25 |
| minute | bluerise: nevermind! | 22:25 |
| bluerise | minute: that I had to get up from the couch to retrieve the reform2 | 22:25 |
| bluerise | but I managed that | 22:25 |
| minute | bluerise: haha yes that is indeed a problem | 22:25 |
| minute | oh great :D | 22:25 |
| cinap_lenrek | bluerise: haha :D | 22:25 |
| minute | does it still work? :D | 22:25 |
| cinap_lenrek | okay, i need another beer | 22:25 |
| sigrid | "any challenges this sprint?" "getting off the couch" | 22:26 |
| minute | i'll drive home and will be online there | 22:26 |
| bluerise | my wine glass is empty | 22:26 |
| minute | i'm roughly 2.5 years sober or something!! | 22:26 |
| bluerise | congrats :) | 22:26 |
| minute | thx! | 22:26 |
| cinap_lenrek | pffffff | 22:27 |
| cinap_lenrek | i just accept the self descrutive nature of working with ... embedded software :D | 22:27 |
| sigrid | at my first job all my embedded dev colleagues were heavy vodka drinkers | 22:28 |
| sigrid | maybe that was not a coincidence | 22:28 |
| cinap_lenrek | lets face it | 22:29 |
| bluerise | how can I share pictures with this chat... hm... | 22:29 |
| cinap_lenrek | anyone externally that sees what the fuck we'r wasting our lifes with... will immediately understand that this must be some kind of self destructive fetish or something | 22:29 |
| sigrid | bluerise: via mastodon | 22:29 |
| minute | bluerise: or https://mister-muffin.de/paste | 22:30 |
| klardotsh_ | minute: aayyeee congrats! love that it's been long enough now that it's just "roughly ... or something" amount of time and not a number of days :) | 22:30 |
| minute | klardotsh_: haha yeah i kinda stopped counting | 22:30 |
| sigrid | holy shit it does work | 22:31 |
| sigrid | a bit... wrong but works :D | 22:31 |
| bluerise | I'm seeing double, and it's not the wine | 22:31 |
| sigrid | does it gets stuck at sdhc? | 22:31 |
| minute | what are you looking at | 22:32 |
| minute | i didn't get the link! | 22:32 |
| bluerise | minute: check mastodon | 22:32 |
| minute | ah | 22:32 |
| bluerise | minute: can you send me the current .dtb that linux uses? | 22:32 |
| minute | omg | 22:32 |
| sigrid | cinap_lenrek: https://nein.ftrv.se/fileserver/0185ZZATRBAS3GYQTRS2XAASX9/attachment/original/01E28VQP9P0N5P54TYPEAMBCGT.jpg | 22:32 |
| minute | that looks like a pitch problem | 22:32 |
| bluerise | might have supplied the wrong mode | 22:33 |
| minute | bluerise: looks like 16 bit | 22:33 |
| minute | bluerise: or 960 pixels | 22:33 |
| bluerise | x8b8g8r8 might not be it | 22:34 |
| minute | bluerise: but also, your lines are half the length they should be (in bytes) | 22:34 |
| minute | bluerise: so each odd line is in the right half of the screen | 22:34 |
| minute | bluerise: and that's also why the screen is not filled | 22:35 |
| bluerise | + return fdt_setup_simplefb_node(blob, off, gd->fb_base, imx_lcdif.winSizeX, | 22:36 |
| bluerise | + imx_lcdif.winSizeY, imx_lcdif.winSizeX * (1 << imx_lcdif.gdfBytesPP) / 8, | 22:36 |
| bluerise | + "x8b8g8r8"); | 22:36 |
| bluerise | int fdt_setup_simplefb_node(void *fdt, int node, u64 base_address, u32 width, | 22:36 |
| bluerise | u32 height, u32 stride, const char *format) | 22:36 |
| bluerise | * @stride: bytes per line | 22:36 |
| bluerise | line -> width * bytes per pixel? | 22:36 |
| sigrid | stride = (imx_lcdif.winSizeX * imx_lcdif.gdfBytesPP) | 22:36 |
| sigrid | no? | 22:37 |
| bluerise | yep | 22:37 |
| sigrid | so it's 3840 instead of 7680 rn | 22:38 |
| sigrid | right in the middle :) | 22:38 |
| bluerise | also it might be x8r8g8b8 | 22:38 |
| minute | bluerise: this is a dtb from october, shouldn't have changed since then http://dump.mntmn.com/imx8mq-mnt-reform2.dtb | 22:38 |
| cinap_lenrek | ok | 22:39 |
| cinap_lenrek | compiling | 22:39 |
| bluerise | sigrid: did you see the second reply I just sent? | 22:40 |
| sigrid | yep | 22:41 |
| sigrid | all good now :) | 22:41 |
| bluerise | minute: with the dtb it nearly comes up, but it hangs somewhere, maybe different pcie settings | 22:42 |
| bluerise | let me check what linux has right now | 22:42 |
| bluerise | linux,pci-domain = <0x00000001>; | 22:43 |
| bluerise | finally that shit was upstreamed | 22:43 |
| bluerise | but the ext osc maybe not | 22:44 |
| bluerise | will disable pcie for no | 22:44 |
| bluerise | w | 22:44 |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 22:45 | |
| bluerise | yep, boots up with mainline linux dts (minus pcie) | 22:47 |
| bluerise | now I can go back to my mainline-u-boot fork and add the lcdif stuff :P | 22:47 |
| sigrid | nice | 22:47 |
| bluerise | because I had NVMe support in there as well and then I could just boot whatever is on the NVMe right now... | 22:48 |
| sigrid | 2018 version also has nvme support though, right? | 22:48 |
| minute | bluerise: fantastic! maybe just disable pcie0 / the first one? | 22:48 |
| sigrid | just not the pcie stuff I guess | 22:48 |
| bluerise | My OpenBSD installation is on PCIe right now :P | 22:49 |
| minute | bluerise: the hang happens if pcie0 doesn't get a refclk. but it's only used for wifi card (mpcie) | 22:49 |
| bluerise | and using the ramdisk is boring | 22:49 |
| minute | nvme is on the second pcie | 22:49 |
| minute | and uses motherboard refclk | 22:49 |
| bluerise | ext_osc that is? | 22:49 |
| minute | yeah | 22:50 |
| minute | ext_osc is not a mainline thing | 22:50 |
| bluerise | I wonder if they finally managed to encode that in linux as well | 22:50 |
| bluerise | ugh, sitll not? | 22:50 |
| minute | yeah they did i think | 22:50 |
| minute | but differently | 22:50 |
| minute | ext_osc is something from vendor kernel that i ported | 22:50 |
| qbit | bluerise: woo! | 22:52 |
| bluerise | qbit: hah, you're here :D | 22:53 |
| qbit | :D | 22:53 |
| sigrid | cinap_lenrek: cable wiggling did not help with trackball issue | 23:01 |
| sigrid | it looks like a firmware bug to me, tbh | 23:01 |
| sigrid | rst on the trackball made it come back | 23:02 |
| cinap_lenrek | almost done | 23:11 |
| cinap_lenrek | CONFIG_LCD also allows you to fix the FB address | 23:11 |
| minute | sigrid: sensor cable? | 23:17 |
| - XYZ (QUIT: Read error: Connection reset by peer) (~XYZ@89-24-50-119.nat.epc.tmcz.cz) | 23:26 | |
| cinap_lenrek | here we go | 23:34 |
| minute | bluerise: ok so do i just need to add your few lines to add fdt_setup_simplefb etc? | 23:34 |
| - robin (QUIT: Remote host closed the connection) (~robin@user/terpri) | 23:34 | |
| minute | bluerise: or do you have a patch? | 23:34 |
| bluerise | http://ix.io/4lCn | 23:36 |
| bluerise | running with this diff, but maybe it doesn't carve out the memory | 23:36 |
| sigrid | minute: it happens when i am not touching anything at all | 23:36 |
| cinap_lenrek | http://okturing.com/src/14852/body | 23:37 |
| minute | bluerise: thx! btw can i share your pic? | 23:38 |
| minute | cinap_lenrek: thx | 23:38 |
| cinap_lenrek | also puts the framebuffer at -8MB & 4G-1 | 23:39 |
| cinap_lenrek | it is a bit hacky tho | 23:39 |
| cinap_lenrek | i think CONFIG_LCD was ment to have a static resolution | 23:40 |
| cinap_lenrek | maybe going the CONFIG_DM_VIDEO is a better approach | 23:40 |
| bluerise | minute: usually I make better pics for that, but, ok :p | 23:40 |
| cinap_lenrek | bluerise: checking | 23:41 |
| minute | bluerise: thanks! | 23:42 |
| cinap_lenrek | what i dont like is that this stuff has a direct dependency on the graphics driver | 23:43 |
| cinap_lenrek | thats kind of insane | 23:43 |
| cinap_lenrek | like why the fuck does the graphics driver needs to care about desitributing the info | 23:44 |
| cinap_lenrek | it ALREADY does that | 23:44 |
| cinap_lenrek | returning that graphics_device structure pointer | 23:44 |
| cinap_lenrek | like wtf where they *THINKING* | 23:44 |
| cinap_lenrek | dont they teach proper software engineering anymore at university? | 23:45 |
| cinap_lenrek | and separation of concerns | 23:45 |
| cinap_lenrek | you need ONE interface | 23:45 |
| minute | ACTION chuckles | 23:45 |
| cinap_lenrek | telling the next payload where the fb is is clearly something INDEPENDENT of the graphics driver | 23:45 |
| cinap_lenrek | bluerise: man | 23:47 |
| minute | rebuilding uboot on my reform incl your patch | 23:47 |
| cinap_lenrek | bluerise: maybe we can hack this into the caller of video_hw_init() | 23:47 |
| cinap_lenrek | like the console code? | 23:47 |
| cinap_lenrek | at that point, it gets the graphcis_device struct and you can prepare the devicetree blob | 23:48 |
| cinap_lenrek | minute: nah, i'm not yet convinced | 23:48 |
| cinap_lenrek | maybe just duplicating the devicetree code as bluerise did is better | 23:49 |
| cinap_lenrek | i just dont like it being conflated with the graphics driver :( | 23:49 |
| cinap_lenrek | we try to find the solution that requires the LEAST amount of dependencies to some crappy legacy interface | 23:50 |
| cinap_lenrek | this is what my patch is doing and i dont like it | 23:50 |
| minute | cinap_lenrek: using your patch i don't get display no more in uboot | 23:52 |
| minute | luckily linux still boots :D | 23:52 |
| cinap_lenrek | you need the config | 23:53 |
| minute | i used it | 23:53 |
| cinap_lenrek | hmmm | 23:53 |
| minute | or whatcha mean | 23:53 |
| cinap_lenrek | dunno | 23:53 |
| cinap_lenrek | works for me :( | 23:53 |
| minute | :( | 23:53 |
| minute | i will revert and see if it works at all | 23:53 |
| cinap_lenrek | it assumes we have at least 2GB of ram | 23:53 |
| minute | i have 4 | 23:53 |
| cinap_lenrek | yeah | 23:53 |
| cinap_lenrek | same here | 23:53 |
| cinap_lenrek | dont worry, i already dont like it anyway | 23:54 |
| minute | haha ok | 23:54 |
| cinap_lenrek | CONFIG_LCD can fuck itself | 23:55 |
| minute | i'm silly | 23:55 |
| minute | i flashed the wrong flash.bin | 23:55 |
| cinap_lenrek | also we probably should not use legacy stuff | 23:55 |
| cinap_lenrek | as blueraise said, he'r making our lifes worse | 23:55 |
| cinap_lenrek | the goal is to upstream this and use stock uboot | 23:55 |
| minute | sure, i just wanted to see openbsd booting 2 nite | 23:56 |
| cinap_lenrek | okay | 23:56 |
| minute | so i can sleep happily | 23:56 |
| cinap_lenrek | lets DO IT | 23:56 |
| minute | lol | 23:56 |
| minute | i am reapplying your patch | 23:56 |
| minute | it was just operator error on my part | 23:57 |
| cinap_lenrek | do you have serial? | 23:57 |
| cinap_lenrek | did openbsd print something? | 23:57 |
| cinap_lenrek | i mean, bluerise's patch probably does the same | 23:57 |
| cinap_lenrek | but not depending on the CONFIG_LCD stuff | 23:57 |
| cinap_lenrek | have you tired this? | 23:58 |
| minute | my display is back on | 23:59 |
| cinap_lenrek | \o/ | 23:59 |
| minute | in uboot. but openbsd puts garbage on screen (totally wrong pitch?) | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
