ChanServ changed the topic of #linux-cros-arm to:
tobhe has joined #linux-cros-arm
hexdump01 has joined #linux-cros-arm
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe_ has quit [Ping timeout: 480 seconds]
hexdump01 has quit []
hexdump0815 has joined #linux-cros-arm
<hexdump0815> i was able to get one of the new lenovo cb plus 14 devices, compiled a chromeos kernel with some more generic kernel options to put it into a debian rootfs and it boots
<hexdump0815> chromeos kernel sources are v6.6
<hexdump0815> the device is very nice and well built and the performance of it is in a completely different league than everything before
<hexdump0815> 7z b output of a fresh run is:
<hexdump0815> Avr: 49382 752 6886 51740 | 568365 705 7016 49482
<hexdump0815> Tot: 729 6951 50611
<hexdump0815> it will throttle a bit under constant load, as its a fanless device, but it looks like only by about 10% to around 90% (just quick testing)
<hexdump0815> kvm is supported it seems
<hexdump0815> only downside: those devices are way more expensive than the other arm chromebooks - so it might be worth waiting until the prices drop a bit
<hexdump0815> also not sure if i'll keep it because of it ...
<hexdump0815> i plan to build some bootable debian image for it for other people who get their hands onto one and want to play around with it
<hexdump0815> performance seems to be close or at least not far from qcom x1 plus devices i would say - not that bad :)
<dcz[m]> thanks for testing!
<dcz[m]> I hope there's a tall-screen convertible coming up
<dcz[m]> what does the mainlining of those devices look like? are they getting mainlined in the end?
<ellyq> hexdump0815: damn, that's fast
<ellyq> if i get my hands on one, i'm gonna speedrun u-boot
<ellyq> dcz[m]: collabora is slowly upstreaming MTK SoCs
<dcz[m]> how slowly?
<ellyq> like... 3/4 years
<ellyq> I could do it faster, if I had spare time
<dcz[m]> I wonder what will be available by the time I finish the last grant :P
<ellyq> yeah, about that... any idea if we'd get paid for the current work in the end?
<dcz[m]> not sure, I haven't checked for updates
<ellyq> I'm working on clock drivers currently, MT8186 boots but doesn't detect USB/MMC, MT8195 deadlocks while detecting eMMC
<dcz[m]> if you want, I can send them an email and ask
<ellyq> i'd appreciate that :D
<dcz[m]> kk
<ellyq> because with that, i could justify spending 750EUR on that MT8196
<dcz[m]> I think there's still some kickoff meeting remaining we haven't scheduled yet
<ellyq> (right now i'm in middle of moving, and fighting vonovia... hopefully i won't have to drag them to court...)
<ellyq> also, hexdump0815: could you open the case and check if UFS module is on M.2?
<ellyq> Google started putting UFS on M.2 in 2022, so it would be nice if we could swap UFS with NVME in those machines
* dcz[m] thought UFS was supposed to be soldered on
<dcz[m]> and that it was not PCI-E
<ellyq> it's not
<ellyq> they configure GPIOs differently based on "provisioning" of the SKU
<dcz[m]> that's runtime configurable betwen UFS and PCI-E?
<ellyq> yup
<dcz[m]> neat
<dcz[m]> why would that be the same between ARM and Intel? don't the SoCs have completely different capabilities
<ellyq> standarization