<apritzel>
well, good luck, see you in a year then ...
<apritzel>
I'd say you focus on the problem at hand: "Do I need this driver?" Otherwise you will be busy for a long time ...
<ity>
I need things to be busy with :D
<ity>
I am helping Krey with getting things to work rn
<apritzel>
and devfreq is just the main practical feature of this driver, but it's still a driver for that MBUS device, hence the name
<ity>
OOH, hmm, why is it in devfreq in the tree then? Is MBUS not a bus? I am quite confused hah
<apritzel>
I understand your goal, but in the interest of your sanity, you should focus on what's really important. Some devices can be insanely complicated, and you won't understand a thing without deep diving into manuals and code for weeks or months
<apritzel>
devfreq is the main subsystem this driver implements, hence in lives in that directory
KREYREN_ has quit []
<apritzel>
the driver is called "sun8i-a33-mbus", because that is the device this driver supports
KREYREN_oftc has joined #linux-sunxi
<apritzel>
mbus is the name used in the manual, and sun8i-a33 is the first device from the Allwinner family that it supports
<KREYREN_oftc>
her sanity's long gone, she's capable of reverse-engineering the universe
<ity>
Hmm, what does MBUS stand for? I skimmed the manual but it seems I am blind haha
<apritzel>
fair enough, but I am afraid she needs to do that, by reading the code, for instance
<ity>
Yea, I have the code up in a separate workspace
<apritzel>
which takes time, and threatens you sanity, because you will understand nothing at first
<KREYREN_oftc>
she can do the code, but doesn't have a good understanding of the hardware itself
<ity>
Yea ^
<apritzel>
nobody has, welcome to Allwinner
<KREYREN_oftc>
xDDD
<ity>
I need to mostly learn the terms so I have an easier time reading the code
<ity>
AHAHHAHAAHHAHA
<KREYREN_oftc>
actually i will be making ~10 boards with A64 soon(TM) as i plan on giving one to fraolt and the other to nikky and my bf
<KREYREN_oftc>
bcs teres-1.5 lets goooo
<apritzel>
A64 in 2024, mmh, that sounds very sad
<KREYREN_oftc>
apritzel, give me plans for better one and i shall move the ground
<ity>
What's the diff between the A64 and the H64? Is it just extra MPEG decoding stuff? Krey was suggesting using the H64 but I can't find much info about it
<KREYREN_oftc>
but actually i want to upgrade teres so adding faster emmc and the reworked IO board to have a stable platform for riscv64 and SOM development
<KREYREN_oftc>
bcs teres-2 is projected to be SOM
ity has quit [Quit: WeeChat 4.2.1]
<apritzel>
ity: Allwinner often sells chips that are only slight variations or even relabels. We honestly couldn't find a real difference between the H64 and A64, and we know of only one device using the H64 anyway
ity has joined #linux-sunxi
<apritzel>
I doubt you can still buy it, tbh
<apritzel>
this extra video decoding was one thing that stood up when comparing the AW marketing material, we haven't checked whether that's actually true
<apritzel>
or whether it's just some kind of qualification trick, where they just don't officially support some modes on the A64
<apritzel>
so I'd say swapping for the H64 is a complete waste of time ;-)
<apritzel>
KREYREN_oftc: if you want to make something cool, with AW hardware, pick the "newest" SoC, the A523 or better A527 (w/ HDMI), or their sibling T527
<KREYREN_oftc>
apritzel, will they actually provide it to me though?
<apritzel>
you won't know until you ask, I am afraid
<apritzel>
that SoC has eight A55 cores, going up to 1.8GHz, has PCIe or USB3.0, supports up to 4GB of DRAM, has a much better GPU and video capabilities and so on
<apritzel>
that's still pretty sad in 2024, but at least much more modern and useful than the A64
<ity>
Hmm, I like the A64 so far since it has a decent amount of support. I consider PCIe as a minus, but USB would be really nice. I prioritize not needing blobs for anything, not sure what status does the more modern GPU have
<apritzel>
the new Malis are supported by the in-kernel Panfrost driver, which is better maintained than the Lima driver for the Mali-400 series, I hear
<apritzel>
KREYREN_oftc: cloudflare? I read sales@forlinx.com there
<KREYREN_oftc>
apritzel, ye says email protected for me
<ity>
Ah, Panfrost is better maintained than Lima? Does it need blobs or nah
<apritzel>
not that I know of
<apritzel>
Lima is just covering old GPUs, the active development is happening on Panfrost
<ity>
Ooooh
<ity>
Btw, what does scripts/dts/dtx_diff do? I wanna thoroughly test it before I try my luck at my first patch in the kernel. It *seems* to behave the same from quick tests of the paths I modified... But I should probably fuzz it or something...
vagrantc has quit [Quit: leaving]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
Jookia has quit [Remote host closed the connection]
<KREYREN_oftc>
apritzel, what's the mainline status of that A527 thing?
<KREYREN_oftc>
ain't sure if wiki is up to date
<apritzel>
non-existent / very early, but I am on it
<KREYREN_oftc>
oke
<KREYREN_oftc>
apritzel, do you know how good is the battery life on it in comparison to A64 and max battery capacity?
<apritzel>
I have no clue, but you could compare the data sheets (not user manuals) of the two, maybe they mention something
<apritzel>
everyone: I have added a Wiki page with a list of AXP PMICs, feel free to add and/or correct ...
<ity>
apritzel: I am a bit confused, so there are parts that are signed, but it's open source? So you can read what it does, and not change it? Or are all the main chips without any signature checking in any component, but you can burn in signature checking if you modify the SoC? I am a bit confused when it comes to hardware stuff, sorry :/ I will also need to read up on TF-A,
<ity>
thankfully there seems to be some docs around
<KREYREN_oftc>
ity, afaik some things in the chip are unchangable bcs of the chip design itself not having any interface to change it e.g. the FEL mode, though you can inspect it and see what exactly it's doing
<jernej>
ity: I believe (but I have no proof) MBUS stands for memory bus. It's used for DMA purposes. MBUS controller is configured alongside DRAM in U-Boot. Mostly QoS, priority and bandwith of each channel.
ftg has quit [Read error: Connection reset by peer]
<tokyovigilante>
apritzel: thanks for checking in, re the H700 the only things I have changed are the DRAM timings as posted for the T507 a few days ago, changing the I2C address to 0x34, and disabling the ID check for the AXP717. It looks like you're right about never reaching the TF-A firmware
<tokyovigilante>
if it is still a DRAM issue, is that likely to be power-related or something else?
<jernej>
you can measure power rail to see if it's at proper voltage level
<tokyovigilante>
do you mean with a multimeter? or software/
<tokyovigilante>
?
<tokyovigilante>
also, tried the DRAM init patch you linked yesterday, and seems to work well (ie detects and uses correct DRAM phy_init values and reports correct amount of RAM)
<jernej>
multimeter
<jernej>
oh, great, thanks
<tokyovigilante>
I do have one, but where on the board physically? at the DRAM chip?
warpme has joined #linux-sunxi
<jernej>
whereever you have easiest access, most likely directly on axp chip
<jernej>
but you have to be extra careful not to make short, otherwise you can burn out something
<tokyovigilante>
Ok thanks. Will give it a go if I get desperate, but that might be a bit drastic for me.
warpme has quit []
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<junari>
tokyovigilante: There will definitely be an inductor next to the DCDC converter
<apritzel>
ity: so out of the box Allwinner SoCs contain the BootROM, which is like 32-64KB of ARM code. You can read this via any method (FEL, U-Boot, /dev/mem), it's not protected in any way
<apritzel>
technically there is no easy way around this (on modern SoCs), and it simplifies a lot of other things
<apritzel>
this BROM code then looks on several boot media (SD card, eMMC, SPI flash) for the first user code, to load into SRAM and execute
<apritzel>
to be accepted by the BROM, your code needs to have an 8-byte "eGON" magic, and a super simple checksum, and it needs to be on the right place on the SD card (or eMMC or SPI flash)
<apritzel>
that's all, then the BROM loads your code and executes it, and you rule the chip from then on
<apritzel>
now Allwinner has a feature called "Secure Boot", where you burn an efuse (irreversible!), then it additionally requires this first boot code to be signed
<apritzel>
but this is optional, most devices do not use that, though you yourself can burn this fuse (some people including me have done this)
<apritzel>
on devices shipped with the fuse burnt, we never found an actual ROTPK hash to be burned into the efuses, so actually the BROM accepts *any* signature
<apritzel>
so to boot those devices, you create a random key, sign your boot code with this, and are good to go
<apritzel>
the management core is a somewhat optional device, mostly used for suspend/resume or advanced power saving, as it keeps running even when you turned off the main Arm cores
<apritzel>
again you can upload any code you like into some SRAM and this mgmt core will execute it. We have a fully Open Source implementation of such firmware: https://github.com/crust-firmware/crust
<apritzel>
ity: KREYREN: hope that clear it up. So from a paranoid Open Source fanatic point of view this is almost heaven ;-)
<apritzel>
tokyovigilante: as junari said, probing one of the conductors or capacitors nearby is much easier
<apritzel>
I'd correlate schematics from other devices, showing the typical connection of the coils and capacitors, with the pinout of the AXP717 from the datasheet. Maybe you can follow traces
<apritzel>
tokyovigilante: or you try to upgrade the voltage a little bit, like 1160 mV: we had reports in the past of some parts needing a bit more juice
<apritzel>
thought the boot0 log seems to suggest that 1.1V are fine
<apritzel>
tokyovigilante: any chance you can take some pictures of the device and upload them? The website doesn't show any pictures from the side or the top, showing the connectors there (HDMI? USB-C?)
<apritzel>
also a picture of the whole PCB typically proves to be very helpful, to check what chips there are exactly (DRAM, WiFi, PMIC)
<apritzel>
thx!
dsimic is now known as Guest948
dsimic has joined #linux-sunxi
Guest948 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
<gamiee>
apritzel: hi, is it possible to debug bootrom through JTAG if it is in secure mode?
<apritzel>
gamiee: I have no clue, I never tried JTAG
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
gamiee: any particular reason? It's not too much code, so can follow it manually, looking at the disassembly. Just need some time and patience. Or use ghidra
<gamiee>
just was thinking about if it would be possible at all to do. But yeah, it is not hard to figure it out with Ghidra
apritzel has quit [Ping timeout: 480 seconds]
freemangordon has quit [Remote host closed the connection]
f_ is now known as funderscore
funderscore is now known as f_
machinehum has joined #linux-sunxi
<KREYREN_oftc>
apritzel, cool thanks!
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
freemangordon has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari has quit [Quit: Leaving]
warpme has joined #linux-sunxi
<apritzel>
does anybody know if "general compute" works with Panfrost? Like in Vulkan compute shaders? Or is Mali only usable with a graphics stack?
warpme has quit []
<ity>
apritzel: Oh, thank you! That does clear up most of my questions, yea! I am a big fan now ngl
<ity>
apritzel: works in what way? If the driver is VK compliant it has to have *some* sort of GPGPU support, no?
<apritzel>
that is one question: is the mainline Panfrost Mesa driver fully Vulkan compliant yet? And is that GPGPU support usable in any way?
<MoeIcenowy>
apritzel: well I think Midgard support is dropped in PanVK
<MoeIcenowy>
Bifrost may work
<apritzel>
I am asking whether it makes sense to enable Mali on the H616 in mainline now, before we have a graphics stack ready
<ity>
Enable?
<apritzel>
as in: send patches to enable the DT nodes
<ity>
Ooh
<apritzel>
I see that Panfrost probes, but am wondering if that is any useful, without a framebuffer and such
<ity>
Does the Mali in the thing have both gpgpu and graphics cores?
<apritzel>
I was under the impression that this is not a distinction made in hardware?
<ity>
PanVK seems to support V6 & V7 only (mesa tree, src/panfrost/vulkan/panvk_device.c panvk_queue_init)
<ity>
Afaik in modern hardware, the submission queues are separate for compute & graphics, but I might be wrong
<ity>
I *think*, at least as far as the kernel driver is concerned, they are separate
<ity>
(For Intel & AMD at least)
<apritzel>
the H616 has Mali G31, which is Bifrost (v7)?
<jernej>
actually dvfs, since voltage adjustments are also in play here
<ity>
Ah, any resource I could read up on it from?
<jernej>
operating points are just device tree construct for giving all frequency voltage combos, between driver can switch
<jernej>
so device tree bingdings?
<jernej>
but usually it holds just values taken from BSP source
<jernej>
in AW case
<ity>
Ooh
wingrime-ww has quit [Read error: Connection reset by peer]
wingrime-ww has joined #linux-sunxi
<ity>
What's the driver that handles that?
<ity>
It reads from the DT and does magic to set the voltage/frequency based on that to the GPU?
<jernej>
it's part of panfrost
<jernej>
but of course it uses functions from devfreq (I think) framework
<ity>
Ah, so it needs a devfreq driver?
<jernej>
I'm not sure if we have same definition of word driver
<jernej>
panfrost is single driver handling GPU jobs and also frequency switching
<jernej>
but it uses functionality of different subsystems (frameworks)
<ity>
Ah, when I say driver in this case, I mean a kernel module that implements some functionality for a set of device(s)
<ity>
(I am trying to orient myself in the Linux sunxi infra)
<jernej>
module for me is just driver, which can be loaded later from userspace (.ko file)
<ity>
Ya fair
apritzel has joined #linux-sunxi
<apritzel>
ity: the driver for a device (say Panfrost for the Mali GPU device) is in control of its clocks, so it's that driver that needs to provide access to those clocks to the devfreq framework
ftg has joined #linux-sunxi
<apritzel>
in case of mbus, we don't need a driver for the actual functionality, as this is set up once by U-Boot, and we don't need to adjust the priorities later. Hence the driver lives in drivers/devfreq
<apritzel>
but for Mali, we of course do need the functionality, so Panfrost registers itself with the devfreq subsystem, and that asks the driver (via a callback) to change to a certain frequency
<jernej>
apritzel: speaking of mbus adjustments - H6 and later uses MBUS driver to adjust Cedrus bandwith or priority (I forgot which) for high bitrate HEVC video decoding
<jernej>
I think only for HEVC 4k@60 AFBC compressed
<jernej>
which is actually max that H6 is capable
<apritzel>
jernej: you mean the BSP code does that? and that we should have something similar, or we cannot decode HEVC 4K60?
<jernej>
yes, BSP code has
<jernej>
I don't know currently how much impact this adjustment has, since I always have equal subjective feel on decoding smoothness
<Jookia>
the frames sound warmer
<jernej>
thing is that AFBC actually produces bigger frames, but it's my understanding that decoding and memory transfers are faster because of it
<jernej>
anyway, it's on my todo to figure everything out
f_ is now known as funderscore
warpme has quit []
funderscore is now known as f_
hentai has joined #linux-sunxi
<ity>
apritzel: I am a bit confused, I don't follow the explanation of why mbus lies in devfreq/, but it's sort of starting to make sense. Lemme look at the struct real quick
<jernej>
ity: It's about what is the main purpose of the driver. Currently it only provides devfreq so it's there.
<ity>
Oooooh, and the two don't interact at all then? mbus & panfrost? That makes sense!
<ity>
I feel like I am blind, but I can't seem to find the Vulkan driver for the G57? I could only find the NIR->ISA compiler at src/panfrost/compiler, and panvk seems to only support v6 & v7? There is probably smth really obvious I am missing...
<jernej>
ity: ask at #panfrost?
<ity>
Ah, there is a channel? Oki
<jernej>
and yes, mbus and panfrost driver don't interact with each other
<ity>
Oooh, thx for the explanation!
warpme has joined #linux-sunxi
warpme has quit []
<apritzel>
ity: sorry, that was probably confusing on my side: mbus and panfrost are two unrelated examples of devfreq users
<apritzel>
mbus has "nothing else to do", so just sets up devfreq, and thus lives in drivers/devfreq. If you want to understand devfreq, it's the easier code to look at
<apritzel>
panfrost's main job is of course driving the Mali GPU, but on top of that it lends its main clock to devfreq, to allow it being clocked down, when power saving is required
<ity>
OOOH, thx, that makes sense! So, it only configures the MBUS, which is used for DMA, and also manages the DRAM clock?
hentai has quit [Ping timeout: 480 seconds]
<apritzel>
yes, there is little documentation about that, but to my understanding "MBUS" is part of the whole DRAM controller, and controls access of various DMA users to DRAM
<apritzel>
and the Linux driver doesn't really configure the MBUS, this is done statically in U-Boot
<jernej>
not sure if this can explain boot troubles on other than H616 variants
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<apritzel>
jernej: RMR is used at SPL, since we have both SPL and proper running in AArch64. The same code is in U-Boot proper as well, but we have that 64-bit "switch" opcode before, so it's skipped
<apritzel>
this is so that you *can* enter U-Boot proper in AArch32 as well, if need be, for instance if you somehow boot with boot0, but this isn't really used in practice
<apritzel>
jernej: what's the additional condition? I think it's the code we use in TF-A ((ver_reg & 0xff) != 2), though in U-Boot we use == 0
<apritzel>
so far we have seen 0 and 2, so this wasn't a problem. Do you see actual issues with that?
<jernej>
exactly that 2
<jernej>
I mean, there is no comparison with 2
<jernej>
but I guess that's not an issue currently
<apritzel>
it should be a matter of inserting "cmp r0, #2", I guess?
<jernej>
so, if this would ever be the issue, SPL would crash immediatelly, right?
<apritzel>
I guess so. You can invert the ldrne to ldreq on a working board, or read 0x3000024 (via FEL, for instance), to check this