<zhaofeng>
The Makefile calls it the `PRIVATE_MKIMAGE_TOOL`. I see u-boot's mkimage has functionality to generate MTK boot images with special boot headers, but not sure whether those are the same thing
<samueldr>
zhaofeng: I believe none of the binaries will be required
<samueldr>
with my two mediatek devices I was able to just use other binaries
<samueldr>
but yes
<samueldr>
it's bad, and probably not compliant with the GPL
<samueldr>
turns out the trick with dtc_overlay helped postmarketOS users too!
<zhaofeng>
It failed trying to execute the binary, which is enabled by `CONFIG_MTK_DTBO_FEATURE`
<samueldr>
oh
<samueldr>
try that trick!
<samueldr>
haven't had a mediatek device with dtbo shenanigans yet
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
<zhaofeng>
I don't think that's actually necesary, since the kernel in the boot.img dump looks like a normal zImage with appended dtb
<samueldr>
probably not required
<samueldr>
BUT
<samueldr>
there's still the dtbo partition that exists
<samueldr>
and that will cause issues if it's like qualcomm devices
<samueldr>
those dtbo will get overlaid on the kernel dtb
<samueldr>
which is fine if it's from a compatible revision
<samueldr>
but if your kernel "upgrades" to an incompatible one, it might not work anymore
<samueldr>
with qualcomm kernels there is an option to "APPEND" the dtbo during the kernel build time
<samueldr>
might not be qualcomm specific
<samueldr>
CONFIG_BUILD_ARM64_DT_OVERLAY is it IIRC
<samueldr>
it *may* be appropriate to `fastboot erase dtbo` when using that
<samueldr>
something I don't know for sure
monk has left #nixos-aarch64 ["Error from remote client"]
<zhaofeng>
Cool, let me give that a try.
<zhaofeng>
So that's why erasing the dtbo partition was necessary on my OnePlus 6, hmm
<samueldr>
possibly!
<samueldr>
it's something I don't yet grok
<samueldr>
I know the vague outline of the issues
monk has joined #nixos-aarch64
<samueldr>
but I haven't taken the time to investigate and test
<samueldr>
I would have to take a device with dtbo partition, install an old android release, including its dtbo partition, then try a newer android kernel
<samueldr>
*and* the reverse situation
<samueldr>
and that wouldn't prove anything except if I have a bad result
<samueldr>
the theory here is that you could have a common boot image with basic dtb for a bunch of devices
<samueldr>
with the per-device bits in the dtbo partition
<samueldr>
artturin: missing its /proc/tty/driver/serial
justanotheruser has quit [Ping timeout: 260 seconds]
<zhaofeng>
samueldr: For the other mediatek devices, do you need to enable some special configs to get framebuffer console?
<samueldr>
assume OEM vendor kernel trees can't enable the framebuffer console
<samueldr>
because maybe you won't be able to
<zhaofeng>
The kernel _seems_ to boot, but I can't see anything on screen (FRAMEBUFFER_CONSOLE is enabled). I can't easily take the device apart to get a serial line :/
<samueldr>
zhaofeng: if it "hangs" it's a sign the kernel is running
<artturin>
manjaro serial added
<samueldr>
you can look in /sys/fs/pstore in e.g. TWRP to find the previous kernel boot dmesg
<samueldr>
which is not as good as a serial interface, but what I use on all my devices without serial access
<samueldr>
zhaofeng: a trick is to force the init to quit
<zhaofeng>
And it will enable the ethernet gadget mode?
<samueldr>
not by itself, but will allow use of gadget mode
<samueldr>
you can use adb
<samueldr>
(which I personally like)
<samueldr>
or yes, rndis
<zhaofeng>
Oh, there's adbd in stage1?
<samueldr>
yes!
<samueldr>
I think I'm the only non-android distro (except ubports maybe) to have adb working
<samueldr>
in theory it should work on the pinephone once usb gadget mode works
<samueldr>
since it worked on other fun devices!
<samueldr>
so yeah, to know which mode to enable, check in your kernel config for CONFIG_USB_G_ANDROID
<samueldr>
if it's CONFIG_USB_G_ANDROID=y, then android_usb
<samueldr>
otherwise gadgetfs
<samueldr>
obviously, any usb gadget is only useful if things boot enough for the initrd to work!
<zhaofeng>
Let me try in a bit (getting distracted). I can theoretically root the Android ROM, but it will be pretty awkward to use as it's Android Things :/
<zhaofeng>
(it's the Lenovo Smart Clock)
<samueldr>
I figured from the branch name
<samueldr>
looks like a "fun" project to hack on
<samueldr>
(especially given the lack of feedback early on)
<zhaofeng>
It would be pretty cool to get NixOS there, and maybe I can slap Mycroft on there to actually use it as a smart clock with a voice assistant
<samueldr>
effectively
<zhaofeng>
The lack of visual indicator is indeed pretty annoying, though
<samueldr>
any LEDs on the device?
<zhaofeng>
Nope :/
<samueldr>
aww
<samueldr>
those are also useful, on devices with LEDs you can force the kernel to enable them earlier than initrd
<samueldr>
so you can get a feeling of whether it is even booting the kernel or not
<samueldr>
quirks.fb-refresher.enable is not required anymore for the splash thing to work
<samueldr>
if the concept is still required
<zhaofeng>
Yeah, I wasn't sure what that was for, and then I checked the package
<zhaofeng>
I call it "google-mt8167s" as I believe all the Android Things platforms are generic (the base ROM images are supplied by Google), but I may be wrong
<samueldr>
it could be the issue here, depending on how the dtbo stuff is going
misuzu has quit [Remote host closed the connection]
misuzu has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
<superherointj>
In my RockPro64, If I use U-boot latest (from hydra), I get: "Flattened Device Tree blbo at 01f00000/nBooting using the fdt blob at 0x1f00000"
<superherointj>
*blob
<superherointj>
I'd like to understand this better. Am I using an invalid u-boot version? Should U-boot and NixOS be at sync? How do I know which u-boot version I should use?
<cepheus>
From what I can tell, they're separate boards that are meant to be pin-compatible with the CM3, by the looks?
<cepheus>
as in the CM3 option they offer is just an unmodified CM3 and the other boards are ones they've designed to be drop in replacements using the same interface the CM3 does
<cepheus>
there even appear to be RPI direct competitor SBCs using that SoC, so it seems like a fairly reasonable guess
<Ke>
though I think amlogic and nxp had something similar
<Ke>
maybe nxp uses vivante though
<cepheus>
NXP doesn't appear to licence Mali at all, amlogic licences some mali GPUs but apparently not the t860 (if you believe wikipedia)
<cepheus>
mediatek makes two SoCs with the t860 but both are 4+4
<Ke>
rk3399 is very popular now for a reason
<samueldr>
superherointj: fresh u-boot or existing u-boot install from a previous image?
<samueldr>
oh, latest u-boot from nixos
<samueldr>
so I guess fresh u-boot
<samueldr>
I don't have a rockpro, so it's not really possible for me to say
<samueldr>
artturin: it's plausible that there could be a race. If there is, it is extremely unfortunate and the drivers should be fixed
<samueldr>
but, we probably want to start making the pine64-flavoured kernel modular to make a common build for the pinetab
<samueldr>
since there's no modem in the pinetab, it would end up circumventing the issue
<samueldr>
veleiro/cepheus: there are different clockworkpi boards, and they all use different CPUs, IIRC there is as you said the RK3399 one for A-06XX
<samueldr>
and I believe the A04* were most likely sunxi
<samueldr>
but the lack of actual details for things "shipping in 2021" is concerning
<cepheus>
To be fair, I wouldn't want to commit to shipping anything electronic in 2021 either :p
<samueldr>
being vague in the actual specs of the boards is the kind of things vendors selling phones with extremely inexpensive or fake specs do
<samueldr>
"eight core CPU!"
<samueldr>
* the cheapest we could find
pavan has quit [Ping timeout: 264 seconds]
<samueldr>
when you're buying a still unpopular SBC or embedded device, it's a bad idea to go for one you cannot know the actual specs
<samueldr>
since you'll be unable to do research beforehand to make sure things will work
<cepheus>
yeah
<cepheus>
it's not a PC where you can just slap any old silicon in there and pretty much call it a day after all
<samueldr>
but it should be!
<cepheus>
ofc
<samueldr>
but OEMs generally stop after putting whatever silliness the SoC vendor gave them as a "BSP"
* samueldr
sighs
<samueldr>
the SoC vendor is *also* part of the issue obviously
rajivr has quit [Quit: Connection closed for inactivity]
<cepheus>
you can't even realistically call any two SoCs userspace compatible unless they use the same GPU given the extremely variable feature support and quality of drivers
<cepheus>
(if you care about the GPU, anyway)
<samueldr>
hm?
<samueldr>
I don't follow
<cepheus>
was just kind of getting at GPUs and their implementations on SoC frequently have enough quirks or other issues that it can be difficult to assure that intensive 3d applications would work correctly without the actual hardware to hand in a way which is less true of the ISA side of things
<cepheus>
just waffling a bit really
evils has joined #nixos-aarch64
justanotheruser has quit [Quit: WeeChat 2.9]
zupo has joined #nixos-aarch64
konubinix has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
justanotheruser has quit [Quit: WeeChat 2.9]
justanotheruser has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
Thra11 has joined #nixos-aarch64
patagonicus9 has joined #nixos-aarch64
cole-h_ has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [*.net *.split]
cole-h has quit [*.net *.split]
patagonicus has quit [*.net *.split]
patagonicus9 is now known as patagonicus
Thra11 has quit [Quit: WeeChat 3.1]
zupo_ has quit [Ping timeout: 265 seconds]
<samueldr>
since I've been seeing these terms a lot with mobile nixos adjacent searches