ChanServ changed the topic of #linux-cros-arm to:
<jenneron[m]> results of bisect: https://dpaste.com/8NTBHP4YN
<jenneron[m]> pmaports merge request switching to 6.6 LTS: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4840
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-cros-arm
KREYREN_oftc has quit [Remote host closed the connection]
hexdump01 has joined #linux-cros-arm
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump01 has quit []
hexdump0815 has joined #linux-cros-arm
<hexdump0815> jenneron[m]: oh sorry, i forgot aboutnyan - for me this kernel was working: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/6.6.9-stb-cbt%2B - maybe give that one a try to see if it works for you, maybe it makes bisecting easier
<hexdump0815> oh - too late, you already bisected it - strange that that version works for me
KREYREN_oftc has joined #linux-cros-arm
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-cros-arm
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-cros-arm
KREYREN_oftc has quit [Remote host closed the connection]
<jenneron[m]> hexdump0815: yeah weird. maybe it is different for blaze and big
<jenneron[m]> btw we finally have GPU working on snow https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61093
dcz_ has joined #linux-cros-arm
<dcz_> hey, I started a Matrix channel for the topic of freeing ARM Chromebooks: #freebook:chatwave.org
<dcz_> IRC is cool, but in low traffic channels following discussions becomes hard
<dcz_> and I have questions
<jenneron[m]> dcz_: you can join from matrix
<jenneron[m]> if that room is supposed to be the same as this one, but on matrix, it doesn't make sense
<jenneron[m]> you can join with this link https://matrix.to/#/#_oftc_#linux-cros-arm:matrix.org
<dcz_> I'm actually not sure what this room isexactly :P
<jenneron[m]> dcz_: it is for development, testing and kinda for cross distro cooperation
<jenneron[m]> *for arm chrome os devices
<dcz_> well so I've put a target on Mediatek chromebooks
<dcz_> the CPU is freeable, but how blobby are the typical peripherals?
<dcz_> can anyone point me to the devicetree?
<jenneron[m]> what do you mean by freeing though? do you want to implement open source firmware for components like wifi?
<jenneron[m]> dcz_: which device?
<dcz_> the bloblesst one is the most interesting
<dcz_> ...blobleast?
<dcz_> I mean choosing the device where there's least blobs and replacing peripherals if possible
<jenneron[m]> there are blobs for wifi/bt on all of these devices
<dcz_> are any socketed?
<jenneron[m]> probably no
<dcz_> dang
<jenneron[m]> dcz_: go with this one https://wiki.postmarketos.org/wiki/ASUS_Chromebook_C201_(google-veyron-speedy), replace bootloader with u-boot or build coreboot + depthcharge, install pmOS without nonfree firmware, connect USB wifi/bt
<dcz_> so I'm taking the Librem 5 as a baseline, where newer models had WiFi firmware
<dcz_> there's also displayport firmware in there, so that's where I'd look next
<dcz_> thanks for the link
<jenneron[m]> i'm not sure what do you mean
<jenneron[m]> you can't do without blobs completely
<dcz_> the displayport controller might need firmware
<jenneron[m]> unless you use USB WiFi/BT
<jenneron[m]> also stuff like bootrom is proprietary
<dcz_> that's not rewriteable, though
<jenneron[m]> i guess you can go with tegra if you don't need gpu and usb 3.0, i think you can dump bootrom, of course you can't replace it but you can probably analyze it
dcz[m]1 has joined #linux-cros-arm
<dcz_> where does bootrom sit exactly? does it have a resident part after boot?
<jenneron[m]> in SoC
<dcz_> it's executed before TrustZone, right?
<ellyq> dcz_: STEELIX (MT8186) has socketed WiFi module, but it's still SDIO :D
<dcz_> it's hard to find those... been there with the L5
<dcz_> it's a risc-v binary
<dcz_> anyway I'm not seeing any blobs apart from this one and wifi in Kukui-like chromebooks, which is promising
<ellyq> power management, scp, wifi/bt
<dcz_> what's scp?
<dcz_> https://github.com/ARM-software/SCP-firmware - okay, looks freeable
<weirdtreething[m]> scp in chromebooks is based on chrome ec
<weirdtreething[m]> it's sorta open source but the public source code is missing stuff like image processing algorithms
<weirdtreething[m]> <dcz_> "oh wait https://anduin.linuxfrom..." <- you can build your own sof firmware
<dcz_> awesome
<dcz_> what is the image processing for? csi cameras?
<weirdtreething[m]> yeah
<dcz_> hmmm given that it's risc-v, it sounds implementable/reversable
<dcz_> https://wiki.postmarketos.org/wiki/Google_Kukui_Chromebook_(google-kukui) does ayone know what the problem with audio is here?
<weirdtreething[m]> jack detection is a kernel issue
<weirdtreething[m]> I haven't looked into it much
<dcz_> okay, that's just firmware loaded by the OS, but there might still be some loaded by the boot loader, right?
<weirdtreething[m]> yes but you can dump the coreboot firmware and look at all the blobs in it
<dcz_> like the RAM training, although I've seen some sources for MT8183 in coreboot
<weirdtreething[m]> you can also build your own firmware to remove any non-essential blobs
<dcz_> yeah when I looked at it I haven't seen any basically
<dcz_> which indicates that DP isn't going to be a problem, either
<weirdtreething[m]> DP is a problem only because of kernel drivers being broken
<dcz_> well, that validates my idea: Chromebooks can be as free as the Librem 5, which is quite useful
<weirdtreething[m]> yeah chromebooks can be very free
<weirdtreething[m]> like jenneron said, veyron_speedy without wifi has zero blobs
<weirdtreething[m]> I looked in my stock firmware dump on krane and the only blob in there is for dram training
<dcz_> I found open source code in coreboot for what I though was MT8183 RAM training, could that blob be freed too?
<weirdtreething[m]> afaik that one has no public code
<weirdtreething[m]> where did you find it?
* dcz_ digs into old dusty browser tabs
<weirdtreething[m]> dcz_: thats just input data for the dram blob
<dcz_> the second link is something else
<weirdtreething[m]> dram.elf still being in the blobs repo makes me think that what you found isn't the same thing exactly
<dcz_> comparing the changelog might be helpful, not that I'm going to do it today
<dcz_> I wonder what the differences are between models
<dcz_> thankfully there are 2 copies of the source, the other one in mt8195, but that's another thing I'm not doing today
<weirdtreething[m]> those release notes are for mt8183, but the code you linked was for mt8195
<weirdtreething[m]> there is nothing for mt8183 in what you linked
<dcz_> right, but if you look at changelogs, both mention the name "dramc", which is also the name of the sources I linked, making it likely that they are both talking about the same base code
<weirdtreething[m]> It's probably just the code for interfacing with the blob
<dcz_> the blob executing in ... the RAM controller?
<dcz_> I kind of assumed link training was done by the CPU
<weirdtreething[m]> yes it is on the cpu
<dcz_> hmmmm
<dcz_> 307kB, that's a lot of reverse engineering
<dcz_> changelog has lines about "mtk-dramk/mt8195" so that checks out
<dcz_> This is the DRAM initialization code from the reference implementation released by Mediatek for MT8192. The DRAM calibration code can be taken as a standalone library, used by different boot loaders for initializing DRAM
<dcz_> so it *is* the real deal, just outdated real deal
<weirdtreething[m]> still doesnt help with mt8183
<dcz_> I think this code is going to be shared, but even if it isn't, it makes existing options palatable
dcz_ has quit [Ping timeout: 480 seconds]