<jenneron[m]>
deathmist: I see, I couldn't get it to work on mt8173 too, if this patch does not regress things it still may worth including it
hexdump0815 has joined #linux-cros-arm
hexdump01 has quit [Ping timeout: 480 seconds]
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #linux-cros-arm
aceridus has joined #linux-cros-arm
<aceridus>
hexdump0815: I have been down an ArchLinux rabbit hole with the Hisense C11. I haven't wanted to give up yet because it provides motivation for me to understand ArchLinux better. I am still rebuilding kernels from source to figure out what is wrong. Something broke between the 5.11.2-1 and 5.16.7-1 kernels. I tried rebuilding the 5.16.7-1 kernel using the .config from 5.11.2-1, still broken so likely not a config change.
<aceridus>
hexdump0815: I have successfully built and booted a 5.12.1-1, so I will keep going with my effectively manual bisect of building and trying to boot the kernels, we'll see what happens.
<aceridus>
hexdump0815: I jumped in here to say I successfully booted your Bullseye image on the C11 first try. It is running a 5.19.1 kernel so we can infer that 5.19 kernels should work just fine. When I boot the image though / is mounted read-only and can't be remounted read-write. Is that intended behavior for the image? I can't see anywhere why btrfs refuses to mount rw, but I presume it is because the partition hasn't been expanded and only has ~50
<aceridus>
Obviously, I need to expand the partition and filesystem in order to do anything useful with the system. I am just curious if there should be a clear indication somewhere (e.g. dmesg) that the reason why / is mounted read-only is because btrfs isn't happy with the low space? I don't see any indications anywhere of the reason for the read-only mount mode. Any idea where to see more info on this point?
<jenneron[m]>
aceridus: we have 5.18.5 kernel in pmOS for veyron devices
<jenneron[m]>
i didn't notice much regressions in mainline, but there are generic regressions for camera on armv7
<hexdump0815>
aceridus: myveyron image should just work and mount root properly rw as well - i think i even reinstalled my veyron-jaq recently from it
<hexdump0815>
there should still be some space left, especially on armv7l devices as the binaries take less space vs. aarch64, but running /scripts/extend-rootfs.sh is recommended as one of the first things to do
<hexdump0815>
could it be that there maybe was a problem with the sd card? btrfs is checksumming its files and might get ro if it detects checksum errors on read
<hexdump0815>
aceridus: regarding your kernel problem - i guess its maybe more a kernel config problem than a missing patch
<aceridus>
Maybe, but wouldn't btrfs generate syslog messages if it sees checksum mismatches? It is a brand new SD card, so I don't think the SD is the issue.
<aceridus>
The root filesystem is coming up ro, no indication why on dmesg or anywhere else that I know to look
<hexdump0815>
really strange - could you maybe try to rewrite the sd card (or another) and try if you can reproduce the problem again?
<aceridus>
I came to realize it when I attempted to setup a user account and adjust passwords
<hexdump0815>
i guess you used the latest veyron image - right? ubuntu or debian?
<aceridus>
Let me do an md5sum check of the image vs SD card contents
<aceridus>
I burned chromebook_veyron-armv7l-bullseye.img.gz
<hexdump0815>
hm - this is what i installed my jaq from a few weeks ago
<hexdump0815>
i think patches for veyron are only required to improve some details, but it should work with pure mainline even too i would say
<aceridus>
Regarding the kernel config point, I only have issues with newer kernels on my ArchLinux image. As mentioned above, I took the working .config from 5.11.2-1 and pulled it forward to 5.16.7-1 using 'make olddefconfig' and 5.16.7-1 still didn't boot, so I am all but certain the issue is not changed config flags
<hexdump0815>
make olddefconfig does not always work i think - this is the way i was moving forward too in the past, but there were situations where additional changes were required
<hexdump0815>
this is why i tried to switch to defconfig plus everything required on top to create the config now
<aceridus>
Good point
<hexdump0815>
this way its also easier to see what a certain system requires as extra options - otherwise its sometimes quite hard to find the few magic options in a working config
<aceridus>
Is there a canonical way to identify the config option requirements or is it just a matter of following the devel lists and understanding the various platforms/devices and what hardware they have and in turn which config flags are needed to enable that hardware?
<aceridus>
I am going to compare the config you linked above to the ArchLinux one for linux-armv7 and see if anything stands out. Although, I am not sure I understand the device hardware well enough to recognize that a flag is missing and relevant...
<hexdump0815>
i think someone mentioned that you can build it from the dts, the referenced drivers and the options they need, but i'm not sure if that really works - for me it was often a lot of trial and error and diffing working/non working config files :)
<aceridus>
Yea, that has been my experience so far to with the various SBCs I have used at work. A rather obtuse pain point of Linux on ARM that I would like to see progress on in general. I am fine with it because I am fine with tinkering and lots of trial and error, but I understand why it sends lots of folks running
<hexdump0815>
for config compare this is what worked best for me: "grep -v # .config | sort > some-file-a", then the same for the other, then diff the files and look at "grep ^-" and "grep ^+" - that usually gives a good hint as sometimes there are thousands of lines of differences :)
<aceridus>
Is there a reason to not use scripts/diffconfig under the kernel source?
<hexdump0815>
i think most stuff properly supported on mainline has the relevant options in defconfig sooner or later, but especially in the arm world there are so many devices where one or two people working on them and they never try to upstream stuff, so the options stay missing
<hexdump0815>
i think i'm a good example for that as well - i plan to try to bring some of the patches and options i found required to upstream, but in the end there is never enough time for that and from what i read upstreaming is not really fun always :)
<hexdump0815>
aceridus: never used that - maybe it works well too
<hexdump0815>
at least i started to always put everything i have found and discovered to my repos so that the information is available online instead of only having it somewhere on my disk - this is one reason for my imagebuilder repo and my kernel build/info trees
<aceridus>
I can't believe I didn't know about diffconfig sooner, it really makes the process of comparing config files much easier because it will handle sorting to make sure you don't miss difference that a cruder grep & diff approach might miss
<hexdump0815>
when i was starting with my snow chromebook years ago it was a pain to get anything working, because there was so much outdated, untested or wrong info around ... everyone seemed to try to get some chromebook working for a week and gave up after some time
<hexdump0815>
interesting - will have a look at that then too
<aceridus>
Yea, I am not surprised. I kind of did that with the Galaxy Book Go, but still intend to get back to it. I just don't know where to go next with figuring out GPIOs to enable the trackpad. It is a catch 22 because the hardware I need to make work is the undiscoverable stuff that has to be defined by the hardware oem and I don't have that info other than the dsdt which is a real head scratcher for me still.
<jenneron[m]>
yeah a 100k lines file for reference is annoying
<jenneron[m]>
i ported linux for galaxy book s this way
<aceridus>
I guess it will be a trial and error process, but I really dislike doing trial and error methods unless I have someway of seeing if anything (anything at all) had changes. Unfortunately, with vdd gpios I don't really know if there is a way to "see if anything changed"
<aceridus>
So, for me, often times the starting point is to try to understand the space well enough that I can start seeing the necessary information sources to easily identify whether or not my trial and error attempts are actually causing any change
<jenneron[m]>
it won't be that much trial and error process unless you want to work like me on asus-tf701t when i booted kernel for tests 500+ times and mostly broke power button...
<aceridus>
lol
<hexdump0815>
aceridus: i also plan to look at the galaxy book go more after xmas (no time beforehand) - my plan is to try to see how far i get starting form the kernel tree which travmurav had working on his aspire 1 which is sc7180 woa as well
<jenneron[m]>
as i've already said, you should repeat that gpio sequence in hid-over-i2c driver
<hexdump0815>
maybe this helps to get some of the other things like wifi, gpu etc. forward
<jenneron[m]>
you can also copy hid-over-i2c driver to write a new driver for galaxy book go touchpad, but it's kinda hack
<hexdump0815>
jenneron[m]: all noted for when i have the time for it - all your hints were and are very welcome
<hexdump0815>
jenneron[m]: did you get the touchpad working on your galaxy book s? i remember that there was a problem with it as well there or maybe i mix it up with some other hardware where that was the case?
<aceridus>
hexdump0815: So the SD card image is fine for Bullseye, but it definitely comes up with RO /. https://dpaste.com/FWUESCZSZ
<hexdump0815>
aceridus: ok - thanks for retesting - i'll recheck maybe on the weekend
<aceridus>
jenneron[m]: I recall you saying that multiple times. I guess I don't really know what that means? How do I repeat the sequence in the driver? Which sequence? Are you suggesting it because it is faster than tweaking DT?
<jenneron[m]>
<hexdump0815> "jenneron: did you get the..." <- yes, i did
<hexdump0815>
aceridus: i think he ment me - in the dsl file there are two gpios brought up in a sequence for the touchapd
<jenneron[m]>
aceridus: there is nothing to tweak in dt for touchpad
<jenneron[m]>
yes, there are 2 gpios triggered
<jenneron[m]>
there is hid-over-i2c driver, you can repeat these actions
<jenneron[m]>
in the driver
<jenneron[m]>
check how other drivers communicate with gpios
<aceridus>
The hid-over-i2c driver should be figuring out how to do this sequence from DT if the DT is correct, right?
<aceridus>
Maybe someone else can help me understand how to decipher the GPIO sequence from the dsdt and then I can piece together how to do that using gpio APIs in the driver?
<jenneron[m]>
aceridus: no, you should modify hid-over-i2c driver to do that
<aceridus>
jenneron[m]: I feel like I am missing something here that should be obvious. I though the hid-over-i2c driver already supports enabling power to the touchpad as long as the vdd-supply and vddl-supply bindings are correct? I see the code for getting those bindings here: https://github.com/amcduffee/linux/blob/galaxy-book-go/drivers/hid/i2c-hid/i2c-hid-of.c. So, I guess I am still wondering why doing the sequence in the driver makes more sense?
<jenneron[m]>
it will just trigger 0 or 1 or 2 regulators which you specify in dts
<jenneron[m]>
it will not do anything to gpios
<jenneron[m]>
while your dsdt does
<aceridus>
I thought the gpio was what controls the regulator? Am I understanding that incorrectly?
<hexdump0815>
btw. is the dsdt for sure the same for all devices of one type? on one side it might be as i seems to contain info for different setups in one dsdt but maybe there are different device revisions with different dsdt?
<hexdump0815>
i'm mentioning this as i so far only looked at the galaxy book go dsl files from that github - maybe its time to extract the one from my hardware
<hexdump0815>
aceridus: did you extract your own dsdt or did you do everything just based on the one from github?
<jenneron[m]>
pmOS initramfs uses parted which breaks things on cgpt unfortunately
<hexdump0815>
jenneron[m]: this is what i came up with after playing around with it for a while - not sure if there are better way, but so far it at least worked on a ll systems i used it for
<jenneron[m]>
well, it looks a bit ugly..
<jenneron[m]>
i don't really want that to be in initfs script in pmOS, but if there are no other options..
<aceridus>
hexdump0815: I have only been working off the github one, haven't extracted my own yet
<jenneron[m]>
hexdump0815: have you tried to find a way to do that with parted?
<jenneron[m]>
i may take a look at it, but if you've already tried it's most likely not worth my time
<hexdump0815>
jenneron[m]: for sure it might be possible to rewrite it to be a bit less ugly ... what problems do you see with parted in pmos?
<hexdump0815>
jenneron[m]: i think the partprobe is required at some point for the kernel to reread the changed partition table - maybe that is missing?
<hexdump0815>
jenneron[m]: i never tried parted, but i remember that i had to try a few things until i ended up at this hack to finally work
<hexdump0815>
jenneron[m]: i think this cgpt stuff is not really compatible with everything else - i remember there were situations where playing around with the partition tables with some tools resulted in the chromebook no longer booting as the cgpt stuff was messed up
<hexdump0815>
the reason why my hack might work is that it just modifies some parts of an existing gpt table and is not trying to write or update it as a while maybe
<hexdump0815>
while=whole ... this way the cgpt specific areas are not touched
<hexdump0815>
i guess the proper fix then would be to teach parted to be nice to cgpt info?
<hexdump0815>
aceridus: maybe we should first extract our own dsdt and compare it to the one from github - maybe our hardware is simply a different revision?
<aceridus>
hexdump0815: Makes sense, can that be done from Linux?
<jenneron[m]>
well, maybe that's not that hacky hack
<aceridus>
Also, I haven't studied cgpt in particular, but I know from fairly in-depth work on mbr/gpt images (work projects) that GPT stores checksums for the table as well as the headers, so any changes to a GPT table requires re-calculating the checksums. If that is done with a non-cgpt aware tool I presume it would regenerate a non-cgpt header and table and hose everything cgpt related in the process...
<hexdump0815>
aceridus: i think there were some instructions on the aarch64 github, but i think it was only possible from windows
<aceridus>
I guess the more important question, is there a good resource for helping to understand how to interpret the dumped dsdt?
<jenneron[m]>
aceridus: there is microsoft documentation
<hexdump0815>
aceridus: maybe we should move further discussion about the galaxy book go back to the aarch64-laptop irc as its not chromebook related? (i have no problem with it here, but also do not want to spam the channel with off topic topics)
<hexdump0815>
i think the hackintosh community did a lot with the dsdt, so maybe there is some info about it as well?
<aceridus>
hexdump0815: Agreed, I'll go figure out how to dump the dsdt and we can compare results in #aarch64-laptops
<hexdump0815>
aceridus: sounds like a good plan - will do the same on my end as soon as i find some time
<jenneron[m]>
hexdump0815: `parted -f -s /dev/sdd resizepart 3 100%` + `resize2fs -f /dev/sdd3` just works
<jenneron[m]>
that makes things a lot simpler, i can fix an issue which has been around for 9 months
<hexdump0815>
jenneron[m]: cool - if that works, then i can change my script at some point to do it this way as well
<jenneron[m]>
i will do some testing and send a MR if it works
<jenneron[m]>
(MR to pmaports)
<aceridus>
I just successfully built and booted 5.14.1-1 on the C11
<hexdump0815>
aceridus: congratulations - but still a bit to go towards a recent kernel :)
<aceridus>
hexdump0815: Slow and steady wins the race! I am building 5.15.1 as we speak, the final bisect patchlevel between 5.11.1 and 5.16.7, which was the jump that broke it when I used pre-built packages.
<jenneron[m]>
aceridus: can't you just build a version which works for me and hexdump?
<jenneron[m]>
e.g. i use 5.18.5 (although it's outdated already)
<aceridus>
jenneron[m]: Sure can, but I am attempting to track down the issue as it pertains to the linux-armv7 package that is built for archlinuxarm.org
<jenneron[m]>
i see
<bonfire_>
ok, after using ChromeOS on my specific device- the battery is much closer to range it should be in
<aceridus>
A learning process for me to better understand how Arch does everything compared to Debian. Hopefully it ends in a bug/PR to the package to get it working again for veyron-jerry (Hisense C11)
<jenneron[m]>
it just uses kernel on cgpt without initramfs
<jenneron[m]>
unfortunately this setup doesn't assume using FDE
<jenneron[m]>
but it at least has automatic kernel upgrades
<aceridus>
Yes, that unfortunately break things currently. I have added linux-armv7* to IgnorePkg until I figure out why so I don't accidentally break the system with a pacman -Syu
<jenneron[m]>
well it's also broken on exynos devices
<jenneron[m]>
because they have 8M limit for kernel partition
<jenneron[m]>
arch kernel doesn't fit there
<aceridus>
I read a suggestion that it might be related to the kernel size, but after building a size optimized 5.16.x kernel that ended up smaller than the 5.11.x kernel it still didn't boot, just a black screen. I don't think that matters as much on the C11 though because there is a 16M Kernel partition