ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
chrisl has joined #aarch64-laptops
<steev>
i'm in there
<steev>
oh no, i'm in debian-bananas
chrisl has quit [Ping timeout: 480 seconds]
<noisycoil[m]>
Sorry, of course that's debian-bananas and you're right
Caterpillar has quit [Quit: Konversation terminated!]
hipboi has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
whiskey9 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
AladdinSane7 has joined #aarch64-laptops
hipboi has quit [Quit: hipboi]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hipboi has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
clee_ is now known as clee
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
martiert_ has joined #aarch64-laptops
martiert has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hipboi has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
alfredo has joined #aarch64-laptops
<steev>
noisycoil[m]: are you guys working on the muvm stuff?
gkelly has quit [Remote host closed the connection]
gkelly has joined #aarch64-laptops
krzk has quit [Quit: leaving]
krzk has joined #aarch64-laptops
<noisycoil[m]>
steev: There's been no discussion on doing so
<travmurav[m]>
steev: first time? /s
<travmurav[m]>
robclark: (acpi) i wonder if it's even useful for the logo thing
<travmurav[m]>
Where plymouth reads the acpi table containing the device logo and shows it on boot
<travmurav[m]>
I don't think it would break with us using dt but I didn't check if the sysfs thing was still there when acpi interpreter bails out
<travmurav[m]>
Btw, Jens Glathe: is there any obvious quirks you've noticed with the omnibook hw?
<travmurav[m]>
There was one sold here for (barely) reasonable price
chrisl has joined #aarch64-laptops
krzk has quit [Quit: leaving]
krzk has joined #aarch64-laptops
<JensGlathe[m]>
My model has a reflective (brilliant) screen
<JensGlathe[m]>
The keyboard layout is something to get used to
<JensGlathe[m]>
otherwise just great
<travmurav[m]>
Yeah I think the one sold here is also touch+glossy
<travmurav[m]>
JensGlathe[m]: Nice
<JensGlathe[m]>
glossy, that's the word
<steev>
travmurav[m]: it has to be on qualcomm's side, i checked csl and ofac and i have a fairly unique name so no idea what the hell they're checking
<JensGlathe[m]>
touch works, too
<travmurav[m]>
I was loosely considering buying that thing since this is the chassis I seem to like the most out of the whole x lineup
<JensGlathe[m]>
oh and it has that odd ITE 8997(?) EC that is also on the slim7 and on the dev kit
<travmurav[m]>
steev: yeah, but I think for basic account they didn't mind approving Mr John Smith @10minutemail last time I tried xD
<steev>
heh
<JensGlathe[m]>
dev kit has test software for ec though, so might be interesting
<travmurav[m]>
Jens Glathe: well the mcu sku doesn't matter as much as the firmware I guess
<travmurav[m]>
But I guess if they all used qcoms bsp for it...
<JensGlathe[m]>
looks like it. The USB ports are all working nicely, also type-a
<JensGlathe[m]>
which is something
<travmurav[m]>
I guess the xlcamera is mipi like all other things?
<travmurav[m]>
As in its not a usb Webcam I guess? :D
<JensGlathe[m]>
Booting up windows to check
<travmurav[m]>
Well id guess linux would see it in lsusb if it was
<JensGlathe[m]>
Its some Windows Hello capable thing with unbelievable amounts of drivers
<travmurav[m]>
Oh fun
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Its not in lsusb, there is nothing
<travmurav[m]>
Yeah I guess mipi, no "luck" having a free camera xD
<travmurav[m]>
(Don't get me wrong, swisp work is amazing but it's sad that we're unlikely to ever get hwisp on qcom)
<macc24>
<JensGlathe[m]> "oh and it has that odd ITE 8997(..." <- it8987 iirc
<JensGlathe[m]>
Spectra 695 5MP camera, also IR capable
<steev>
- Fixed an issue where the Lid might not wake the system from Hibernate.
chrisl has joined #aarch64-laptops
martiert_work has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
jglathe_volterra has joined #aarch64-laptops
<Jasper[m]>
@dgilmore can confirm webcam works ootb on f41, thanks!
<Jasper[m]>
Camera led's not on though
hipboi has quit [Quit: hipboi]
<bryanodonoghue>
robclark we do declare CMA heaps in dts
<bryanodonoghue>
we need to because the libcamera policy is to provide physically contiguous output buffers
<bryanodonoghue>
since some hw encoders - like Hantro on i.MX8 require phys contig
<bryanodonoghue>
udmabuf still requires the CMA heap in DTS AFAIK
<KieranBingham[m]>
No, udmabuf doesn't use CMA
<KieranBingham[m]>
And it isn't physically contiguous...
<KieranBingham[m]>
libcamera doesn't require contiguous memory, (that's why we can accept/use udmabuf) but "somewhere, something" is going to need to know about the memory requirements of the whole pipeline. So a buffer allocated with udmabuf isn't going to work as a buffer to share to the encoders indeed.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
travmurav[m]: hmm, I assumed logo details were coming from uefi.. if it is acpi, that is kinda sad. From a standards PoV you shouldn't have both dtb and acpi tables (IIRC the original DtbLoader removed the acpi tables)
<robclark>
bryanodonoghue: but x1e dts shouldn't be declaring things related to _other_ hw
<robclark>
sad.. maybe DtbLoader could patch it into the dtb
<travmurav[m]>
yeah that would probably not be too hard if we agree on something
<travmurav[m]>
but also fwiw my impl doesn't nuke acpi as of now, as linux kills acpi interpreter as soon as it sees most minimal smell of "sane" dt and also because detecting that "we're booting linux" is quite annoying it appears
<travmurav[m]>
so I think at least for now we can also keep some "status quo" and let i.e. plymouth do whatever it already knows for bgrt
<robclark>
I guess send a patch to list to document some bindings that mirror the bgrt table (or at least the needed parts) and see what folks have to say?
<travmurav[m]>
but seems like bgrt is just (type, bmp addr, x-coord, y-coord)
<robclark>
sounds simple enough
<travmurav[m]>
but then again we'd need to define the original region to be reserved until it's picked up for example
<robclark>
I guess we'd have to do that regardless, even if the acpi table was still accessible
<travmurav[m]>
well yes but I think in case of acpi, kernel is supposed to already know how to handle those "acpi reclaim" regions
<travmurav[m]>
I guess I'm not sure what happens with "acpi reclaim" memory that is unused by anything
<travmurav[m]>
as in, spec says dt memory should also be "acpi reclaim" so I guess dt code would find it, and then explicitly un-reserve
<travmurav[m]>
but then we don't have acpi interpreter to find and reclaim the acpi memory? not sure
chrisl has joined #aarch64-laptops
<travmurav[m]>
and tbh, bgrt is probably one of our least concerns today xD
<robclark>
fair, I was mostly just proposing that you (or someone) send bindings proposal just to get discussion started
<robclark>
also.. the whole having both dt and acpi tables just sounds like an accident waiting to happen
<robclark>
it would be unfortunate if userspace came to depend on that
<travmurav[m]>
yeah that's true
<travmurav[m]>
but I think almost everyone who has acpi=y would have both for current qcom stuff
<travmurav[m]>
and efistub today knows to use dt in that case it seems
<robclark>
sure, not worried about having CONFIG_ACPI=y, just worried about having both tables installed
<bryanodonoghue>
I thought it was that we still required a CMA heap to back the udmabuf
<bryanodonoghue>
actually I've only setup the CMA heap version on qcom so far
<bryanodonoghue>
the reason for udmabuf was permissions not - avoidance of physically contig buffers
<bryanodonoghue>
You couldn't guarantee anything larger than a page as phys contig from a regular allocator...
<macc24>
why hugepages aren't used for it instead of cma?
<bryanodonoghue>
some camera frames can be v large larger than a page
<bryanodonoghue>
also different arches have different page sizes
<robclark>
travmurav[m]: yeah, I just don't know how much we want the existing kernel acpi vs dtb stuff to become implicit abi
<robclark>
macc24: what does fwupd need to see from acpi? Ie what would break if the acpi table was removed?
<macc24>
robclark: firmware updates
<macc24>
you've seen it
<robclark>
hmm, sad
<robclark>
bryanodonoghue: but my understanding is that softisp (or anything else on qc) doesn't actually require phys contig
chrisl has joined #aarch64-laptops
<bamse>
robclark: i'm always running with both dt and acpi tables installed (i.e. i don't run dtbloader which drops the acpi tables)
<travmurav[m]>
macc24: I thought fwupd relies on smbios only? clearly acpi is disabled in runtime :D
<bamse>
robclark: and i think for a dual boot scenario, that's the only way we can do it until we move to acpi
<robclark>
yeah, moving to acpi would solve some things..
<macc24>
travmurav[m]: i don't know, i disable acpi in kconfig and it doesn't work
<travmurav[m]>
weird
<robclark>
IIRC the original dtbloader did some dance to only remove acpi tables if booting linux, so dual boot would work.. but I'd have to go back and look at how that worked
<macc24>
bamse: huh, i dualboot windows and linux with dtbloader always being ran
<robclark>
but yeah, having both acpi and dt works fine for now, it just seems like we rely on accidental behavior a bit too much
<robclark>
(but if fwupd needs acpi tables, then maybe we are already a bit painted into a corner)
<travmurav[m]>
robclark: yeah I think original dtbloader registered ebs hook and checked loaded fdt crc32, nuking acpi if something acknowledged fdt by touching it
<travmurav[m]>
somehow I don't recall why exactly I didn't like that...
<robclark>
ahh, right
<travmurav[m]>
maybe because I wasn't sure if it would be changed in-place...
<bamse>
ohh, didn't know that hook was gone
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
but yes, back when I looked at it, I for some reason decided it's safer to keep acpi as is and only install a new dt table, which is now what "new" dtbloader does
<travmurav[m]>
ugh yeah looking at efistub again, I think it copies original fdt into a brand new allocation and then updates the new one, so I think I decided this would mean the config table would remain intact
<travmurav[m]>
I think I then looked for any config table efistub itself leaves behind, iirc the initramfs was the most promising one but I think I ended up deciding that nothing was reliable enough to know "we're booting linux"
<travmurav[m]>
and then can remember that i.e. sd-boot/etc could still decide to overwrite the dtb with it's own new one, perhaps calling dt_fixup_protocol while at it, or not calling....
<travmurav[m]>
so I guess more I think of it, more weird edge cases there appear in the absence of explicit "we\re booting linux" acknowledgement thingie
<travmurav[m]>
(and all of this completely ignores that linux is not the only ""alternative os"" one might want to run lol)
<travmurav[m]>
soo... oh well xD
<bamse>
travmurav[m]: i'm in favor of just having both tables, but requiring that the OS just consumes one...which i'm told it the reason why the specification says you must only have one installed
<travmurav[m]>
yeah, I think for the foreseeable future windows will always pick acpi and linux seems to clearly define it intends to always pick dt first
<travmurav[m]>
that's why I ended up not doing any "nuke acpi" thing for now
<bamse>
you would still end up in this situation if you don't have dtbloader and you tell grub/systemd-boot to load the fdt
<bryanodonoghue>
my understanding was libcamera requires it on the output as part of the s/w contract
<robclark>
so, I'm less familiar with the libcamera part.. but I think the dtb should be "software agnostic"
<robclark>
and if libcamera requires that, we should fix libcamera
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
bryanodonoghue: seems such attributes would be a property of the thing consuming libcamera frames...
<bamse>
bryanodonoghue: and in the past cases where we couldn't rely on iommu here, we had additional requirements on specific regions where these buffers had to be allocated; so it wouldn't have been sufficient with just one cma heap
<KieranBingham[m]>
libcamera does not require contiguous buffers. It requires dmabuf
<KieranBingham[m]>
some libcamera consumers are likely to require contiguous buffers ...
hipboi has quit [Quit: hipboi]
<KieranBingham[m]>
Found the thread ...
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has joined #aarch64-laptops
<bryanodonoghue>
right so we're happy to say on i.MX8 it must be CMA but on basically everything else it can be regular paged memory
<bryanodonoghue>
that's grand
<bamse>
bryanodonoghue: but is it sufficient that it's just CMA, or are there "dma-mask" requirement to that?
chrisl has joined #aarch64-laptops
<bryanodonoghue>
bamse it would be up to the driver/arch to know how to set the mask on the cma buf
<bryanodonoghue>
hantro on i.MX6/7/8 is our reference case
<bryanodonoghue>
it can only do phys contig memory
<bryanodonoghue>
so any buffers we populate in libcamera or dma-buf more generally must come from a phys contig pool
<bryanodonoghue>
I don't know if there are special rules on where the phys buf can live w/r/t those buffers
<bryanodonoghue>
but its surely up to the driver/soc arch to validate and enforce
<bryanodonoghue>
in our case on qcom I'm not aware of any specific masking requirements
<bryanodonoghue>
then again I'm agreeing with rob - I don't think the cma buf is necessary for us at all
<bryanodonoghue>
just testing before I respond on-list
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
bryanodonoghue: but what i mean is that it's not only up to the camera hardware...you might have requirements from the consumer as well... or am i misunderstanding how these buffers are used?
<bamse>
bryanodonoghue: last time i poked at camera on a qcom platform, you had to consider the use case; because venus, display, secure buffers had different requirements when it came to placement in physical memory
<bryanodonoghue>
venus afaik can take dma-buf as input
<bryanodonoghue>
secure buffers OTOH I think we may be looking at carveout heaps
<bryanodonoghue>
actually so what I will do is try feeding a camera dma-buf into venus
<bryanodonoghue>
one from CMA heap
<bryanodonoghue>
one from UDMABuf heap
<bryanodonoghue>
for the secure buffer case in theory all we have to do is have a carveout heap
<bryanodonoghue>
add to libcamera
<bryanodonoghue>
and then feed the buffer to whatever is consuming it
<bryanodonoghue>
a secure TEE enclave somewhere
<bryanodonoghue>
that's what we'd want
<bryanodonoghue>
CAMSS dmaing into the buffer raising an IRQ and user-space throwing the dma-buf handle to a TEE application
<bryanodonoghue>
without APSS having any means - any paged handle to - that buffer
<bryanodonoghue>
final thing
<bryanodonoghue>
we can't debayer or run softisp on a carevout heap
<bryanodonoghue>
because the CPU can't touch the buffer
<robclark>
bamse, idk about secure buffers (but I don't think they should be different).. venus/display/gpu all have iommu's and operate in terms of virtual address.. for display, the virtual address is only 32b (might also be the case for venus), but the physical address could be anything
<robclark>
secure buffers shouldn't really need to be carveout.. the "secure" part is managed by 2nd stage smmu translation (there are two layers of pgtables, one controlled by hyp)
<robclark>
(maybe you could also do secure w/ XBU carveout thing, but that is at least not how it is done on android)
<robclark>
downside is we need more than just TEE to do secure buffers
davidinux has quit [Quit: WeeChat 4.3.1]
alfredo has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
lak has left #aarch64-laptops [#aarch64-laptops]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
cyrinux has quit []
cyrinux has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
<wizzard>
Is my assumption correct the I need to install Windows Insider preview for arm and then reinstall Ubuntu in order to be able to extract the firmware?
<wizzard>
I don't know why but while installing Ubuntu concept, today my windows drive was wiped (I selected install and activated LVM and LUKS from the advanced menu). Restoring from the recovery drive also does not work for me.
<wizzard>
Also has anyone setup Ubuntu concept with luks?
<wizzard>
I tried 3 times but the kernel always crashes when loading the device tree.
<wizzard>
Nice. I gues I can just use the qcom-firmware-extract with those files :)
<wizzard>
Ah, the Makefile should do the job :)
<wizzard>
Very nice
<JensGlathe[m]>
those reinstalls get to you eventually
jglathe_volterra has quit [Remote host closed the connection]
alfredo has joined #aarch64-laptops
todi has joined #aarch64-laptops
<JensGlathe[m]>
configured a mac mini m4 for fun, 3500$ - no way
<erebion[m]>
Exactly. When websites say "statting at 699 euros" I briefly think "seems okay", then I always realise it's only 16 GB of RAM and 256 GB of SSD and NOTHING can be upgraded. No way I'll buy that.
alfredo has quit [Remote host closed the connection]
<steev>
Jasper[m]: the camera led is wired up to kernel panic (at least on sc8280xp)
<Jasper[m]>
<steev> "Jasper: the camera led is..." <- Knew that, just didn't know it was either or
<steev>
afaik, we don't have an led trigger for camera
<robclark>
hmm, unfortunate hw design when the camera led is sw controlled.. AFAIU for Chromebooks they try and tie the camera LED to sensor power so it always goes on when sensor is powered
<steev>
agreed
davidinux has quit [Ping timeout: 480 seconds]
<alexlanzano>
Anyone have any luck with USB-C DisplayPort on the Slim 7x? I tried doing a hail mary by pulling the changes from crd patch and putting in the slim 7x dts with no luck.
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
davidinux has joined #aarch64-laptops
agl has joined #aarch64-laptops
davidinux has quit [Ping timeout: 480 seconds]
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<robclark>
I had it briefly working (although not stable, and only 2 out of 3 usb-c ports) with a branch from abelvesa, but not since rebasing on a newer kernel