ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
Schimsalabim has joined #linux-sunxi
acmeplus has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
sunshavi_ has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
<tokyovigilante> Managed to get SD card boot working on the RG35XX+, but only at an 8k offset, not 128k
<tokyovigilante> reboot comes along for free, which is neat.
<tokyovigilante> what's the easiest way to get my kernel load commands into a script? does chucking them into a boot.scr on partition 0 still work?
<gnarface> it should, but extlinux is easier if it's working
<tokyovigilante> Oh right, needs compiling. Awesome, got all the way from SD boot to linux login without interacting over serial
<tokyovigilante> ok cool, will try that next
<tokyovigilante> thanks
<gnarface> np
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
wingrime1 has quit []
wingrime-ww has joined #linux-sunxi
montjoie has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<apritzel> tokyovigilante: so what was it now, exactly? the new DRAM parameters?
<apritzel> tokyovigilante: ultimately, you should not need to create a boot script, that's the distro's job
<apritzel> Fedora probably uses grub, and that should work with U-Boot. We don't support persistent UEFI variables, though, but there is a one-time workaround
<apritzel> (to copy Fedora's grub.efi to efi/boot/bootaa64.efi)
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante> No I have always thought DRAM was ok since I got it working initially, was the SPL stack and BSS offsets
<tokyovigilante> Right, I did see a grub boot screen at one stage letting it start up, I blew the entire EFI partition away however. Can certainly migrate to that going forward though, but that might require figuring out why I can't boot from the 128k offset
<tokyovigilante> Have been trying to integrate jernej's HDMI drivers into my 6.8 kernel, think acmeplus has had more luck so far
ftg has joined #linux-sunxi
montjoie has joined #linux-sunxi
dsimic is now known as Guest2921
dsimic has joined #linux-sunxi
Guest2921 has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<acmeplus> apritzel: macromorgan found out the issue with uboot, it was CONFIG_SPL_STACK_R_ADDR=0x50000, removing that so it defaults to the 0x4fe00000 value solved the sdcard boot
<acmeplus> tokyovigilante: I have it flashed at 8k and is working without issues
<acmeplus> about kernel commands, you can use boot/boot.scr (you will need mkimage to convert boot.cmd) or use extlinux/extlinux.conf
<acmeplus> If you want full rootfs for testing you can use any of the armbian, ubuntu or debian from the orangepi-zero3 or if you want batocera you can use the orangepi-zero2 but you will need to unsquash and mksquashfs the rootfs (batocera) to add your kernel modules.
<acmeplus> However I lost panfrost during the process so it's only framebuffer for now. I need to go back to 6.8 and apply those and other DT changes to see if I can get hdmi+gpu
apritzel has joined #linux-sunxi
<apritzel> acmeplus: oh, CONFIG_SPL_STACK_R_ADDR, that's apparently a misunderstanding, changing that to SRAM (0x50000) was just an experiment to see if it's really DRAM that's the issue
<apritzel> so it works with the old DRAM parameters, and not messing with any of the load addresses
<acmeplus> Yeah, that's what tokoyvigilante thought once he saw the change
<apritzel> really those new devices bringup is mostly SoC dependent (which means it's already solved for the H616/H700), plus some DRAM (LPDDR4 already supported, so just chip and board specific parameters), and the PMIC (WIP)
<apritzel> regarding rootfs: really *any* arm64 rootfs would work, the more mainstream distro, the better
<acmeplus> yup
<apritzel> there is really no need to go with a vendor provided rootfs (OrangePi), just go with the original, say Debian or Ubuntu
<acmeplus> I've just merged the hdmi patches into your 6.8 axp717 branch. HDMI is working, but I lost drm
<acmeplus> panfrost: probe of 1800000.gpu failed with error -110
<acmeplus> most likely a messed up the DT changes
<apritzel> acmeplus: do you have that "GPU PPU" patch?
<acmeplus> the domain-cell changes?
<apritzel> well, that line in the r_ccu node, but you also need the corresponding kernel patch
<acmeplus> oh... that's true, I started from scratch with your clean branch
<acmeplus> I'm missing that patch
<acmeplus> that one, correct?
<apritzel> yes
<acmeplus> thanks
<acmeplus> Well, one step forward, one step back :)
<acmeplus> [ 12.936498] panfrost 1800000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0
<acmeplus> but kmscube immediately froze it
<acmeplus> Time to be with the kids, but will try later
<acmeplus> Just for reference I started with your axp717 branch, applied jernejsk hdmi patch, and your gpu patch. Then the DT is complicated because is hybrid of h616 hdmi connectors and gpu that I did manually
<jernej> acmeplus: I think OPP is important for GPU, default voltage and frequency might not be compatible
acmeplus has quit [Ping timeout: 480 seconds]
afiftyp has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
f__ has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
f_ is now known as Guest2925
f__ is now known as f_
Guest2925 has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
<wingrime-ww> so H700 is kinda variant of h618/h616 ?
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel> wingrime-ww: it's a package variant: it's the same die, but exposes more pins, like the LCD RGB interface
<wingrime-ww> apritzel: does aw use fuses or just don't expose pins ?
<apritzel> it's really just not exposed pins: you can program those peripherals, even set up the pins, they just don't go anywhere
bauen1 has joined #linux-sunxi
<apritzel> and it might be visible in the SID bits, but we don't know yet and also don't care
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<apritzel> jernej: smaeul: wens: any input on that H616 "GPU PPU" driver in general? Is a power domain driver a good idea? Is putting it into the R-CCU driver the right thing?
<jernej> sorry, I forgot about it
<jernej> apritzel: I thought that that region is protected by TF-A at boot, that's why I made U-Boot hack
<jernej> but if that works from Linux, even better
<jernej> now the only question remains, if we want to make separate driver or not
<jernej> apritzel: it wouldn't be first time that memory region as mentioned in manual is split in two and driven by different drivers
<jernej> like watchdog and timer
<apritzel> I think smaeul confirmed some times ago that it's not secure (e.g. accessible from non-secure even on a secure boot board)
acmeplus has quit [Ping timeout: 480 seconds]
<smaeul> I remember confirming something, but not the details :-)
<smaeul> the "right" way to split a device into multiple drivers is the auxiliary device bus, not multiple DT nodes
<gamiee> Oh hi smaeul
<jernej> smaeul: apritzel: I guess this was conversation: https://oftc.irclog.whitequark.org/linux-sunxi/2023-06-07#32211468
acmeplus has joined #linux-sunxi
<jernej> ah, yes, this is actual confirmation :)
<smaeul> apritzel: thanks! gamiee: hi!
<apritzel> smaeul: I am not sure this aux device bus is really necessary? I mean we can easily register into multiple subsystems from one driver and DT node
<apritzel> like it's done with clocks and reset, from the CCU driver
<jernej> smaeul: if you're cool with that patch, please review it and I'll merge it after -rc1
<apritzel> and the various interrupt controllers
<smaeul> it's only necessary if you want to split into multiple independent drivers, which I'm not suggesting is necessary
<apritzel> smaeul: do you have any PRCM documentation?
<smaeul> e.g. the problem with how we have CCU and RTC linked with a function call is that you can't have them both built as modules
<smaeul> I don't think we should call it "ppu" since that refers to a specific IP block
<apritzel> poking around with U-Boot in that MMIO area suggests there is a at least one other bit to toggle
<smaeul> apritzel: I only have the bits and pieces that exist in the various user manuals, nothing H616 specific
<apritzel> and one register with multiple writeable bit, one of which stops execution
<apritzel> ah, I see, thanks
<smaeul> that's probably what you're looking for -- GPU_PWROFF_GATING_REG isn't actually new
<apritzel> ah, indeed, thanks
<smaeul> and it has the same semantics as VDD_SYS_PWROFF_GATING_REG, which has been around since A31/sun6i :-)
<smaeul> so it's definitely not related to the PPU
<apritzel> and I can confirm that I saw +0x0260 and +0x0250 doing something
<apritzel> well, it's a power gating bit/register, I think that comes pretty close to a power domain (which is more of a Linux concept, isn't it?)
<smaeul> yes, those will definitely hang your system unless your are on CPUS running off IOSC ;-)
<smaeul> yes, it's a power domain, but not related to the PPU, so the modeling is fine; I only take issue with the naming
acmeplus has quit [Ping timeout: 480 seconds]
<apritzel> was it the D1 introducing the PPU? I saw it in the A523 too
<smaeul> it's not clear the order in which the D1 was designed/released relative to some of the sun8i ones
<smaeul> so maybe D1, maybe TV303 or something else
<apritzel> but your D1 PPU driver was the first time I heard of such a thing in the AW context
<smaeul> we certainly haven't been upstreaming SoCs in chronological order
<apritzel> yeah, those details don't matter, AW products are confusing anyway, and surely more driven by marketing
<apritzel> but I figured that sorting the SoC IDs gives an order that somewhat makes sense
<smaeul> yeah, close enough
<apritzel> sunxi-fel --list-socs | sort -n
<jernej> smaeul: do you know what DRAM_PAD_HOLD does? I've seen PAD bits in HDMI PHY registers too, but I have no idea what they do
<smaeul> they isolate the external pads from the digital logic, so they keep their high/low state while the logic is in reset
<jernej> makes sense, thanks!
<smaeul> for DRAM pad hold specifically, it ensures the command lines are set to the right state to keep the DRAM chip in self-refresh
<apritzel> jernej: smaeul: thanks for the input, I would send a proper (non-RFC) patch, including the DT bindings, after -rc1
<smaeul> it's probably good to split the power domain part to a separate file, since it applies to H6 as well
<apritzel> but that r-ccu driver file is already shared with the H6
acmeplus has joined #linux-sunxi
<apritzel> and I can confirm that the bit does the same thing on the H6, it's just the opposite reset default
<smaeul> oh, right. well, it'll probably be shared with A50, A133, etc.
<apritzel> so separate file, but just exporting a function, to be able to add this to the other R-CCU drivers more easily?
<smaeul> oh, and the bit exists on A64, H3, etc. as well at a different offset: https://github.com/crust-firmware/crust/blob/master/platform/a64/include/platform/prcm.h
<smaeul> good thing I documented this all because I've completely forgotten about it
<smaeul> I don't know how much we care or how much power it saves to gate the GPU when not in use
<apritzel> can we introduce this now to existing DTs without breaking compatibility anyway?
<jernej> I think yes, since updated DT should be compatible with kernel in which it was introduced, and newer
acmeplus has quit [Ping timeout: 480 seconds]
<apritzel> I guess my "USB charging doctor" cannot tell the difference in power consumption, but maybe the AXP803 battery registers can (on some Pine64)?
<apritzel> jernej: but we also want to cover older kernels, to allow updating U-Boot and still run stable kernels
chewitt has quit [Quit: Zzz..]
<apritzel> I understand that "older DTs with newer kernel" is a core requirement, but I was hoping we would now be like "real computers", and support the other way around as well
<jernej> sure, but now and then some features can't be implemented in such manner
<apritzel> understood, but I guess such a somewhat optional "power savings" register justifies breaking this
<apritzel> argh, *does not justify*
<jernej> but as discussed, nobody is sure if this gpu power domain thing is beneficial enough
<smaeul> unfortunately platform_probe() -> dev_pm_domain_attach() -> genpd_dev_pm_attach() -> __genpd_dev_pm_attach() -> -EPROBE_DEFER
<smaeul> it's probably reasonable to add it to the driver/binding, just not hook it up in the DT
<smaeul> or else ignore it for <H6
<apritzel> smaeul: agreed
<apritzel> is there a problem with the above sequence? I think I saw it EPROBE_DEFER, but it sorted itself out
<jernej> will Linux disable power domain if driver is not loaded? like it's done for clocks?
<apritzel> smaeul: or do you mean the Mali driver?
<apritzel> indeed if there is no power domain driver, Mali will not probe, that's why I say we only add it to H616 and future SoCs
<smaeul> apritzel: it doesn't depend on the peripheral driver (Mali), since everything's done at the generic platform device layer (like assigned-clocks)
<smaeul> yeah that's what I was referring to, for the old kernel there will be no power domain provider, so you will get permanent -EPROBE_DEFER
<smaeul> jernej: no, I don't see any code to do that
acmeplus has joined #linux-sunxi
<apritzel> smaeul: you mean because power-domains is parsed and handled by generic code, like pinctrl?
<smaeul> yes
junari has quit [Ping timeout: 480 seconds]
<apritzel> speaking of DT compatibility: there is a 1.8V/3.3V switch regulator in the pinctrl device of H616 and later, that would enable UHS-I cards, for a potential 400% performance uplist when accessing SD cards
<apritzel> I have some sketches to add a regulator to the pinctrl driver, to be there for the A523 from day one
<apritzel> but adding this to the H616 would break compatibility with older kernels, so I was wondering if we would introduce it to the driver, but don't change the H616 DTs?
<apritzel> and potentially allow people to use DT overlays to enable it anyway, if they care and use new enough kernels?
acmeplus has quit [Ping timeout: 480 seconds]
<jernej> what is your design? if there are extra properties, old driver can just ignore them, right?
<apritzel> the pinctrl driver would register a regulator, and vqmmc-supply would point to the pinctrl node
<apritzel> which means older kernels wouldn't find the regulator there, and I guess the MMC driver wouldn't probe
<jernej> hmm... why emmc doesn't need to go through pinctrl driver?
<apritzel> emmc doesn't need to *switch* the voltage, it has either a fixed 3.3V or 1.8V
<apritzel> it is my understanding that this is fine for eMMC, but not for SD cards
<apritzel> they need to start negotiation at 3.3V I/O voltage, and can then switch to 1.8V if both sides agree
<jernej> there is sunxi_mmc_volt_switch(), so in theory you could?
<jernej> maybe that's why 3.3 V speeds don't work with eMMCs?
<apritzel> well, yes, it's all wired up in the MMC framework I guess, but so far we only had fixed regulators for vqmmc
acmeplus has joined #linux-sunxi
<jernej> do we have any full schematic for H616 or newer SoC with switchable SD card voltage?
<apritzel> if someone would have a external GPIO driven regulator and a level shifter for PortF pins, it would already work
<apritzel> jernej: I did some experiments on the OPi Zero2 back then
<apritzel> the H616 allows to switch the whole PortF between VCC-IO and VCC-PLL
<apritzel> so 3.3V and 1.8V, effectively
<apritzel> most boards seem to have pullups to 3.3V, I don't know if this spoils it
<jernej> yeah, I wouldn't use 1.8 V on such boards
<apritzel> please note that I couldn't get it to work in U-Boot on the OPi Zero2, but this could well be because of me doing something stupid
<apritzel> I saw both side agreeing to the voltage switch, but then they fell back to 3.3V
<apritzel> maybe the SD card was confused because it still saw the 3.3V from the pull up?
<apritzel> maybe worth to try a UHS-I card on a BSP kernel, I think I saw them implementing it
<apritzel> UHS-I goes up to 104MB/s compared to the 25MB/s maximum we have today, so that should be easily measurable, even without looking at dmesg or sysfs
acmeplus has quit [Ping timeout: 480 seconds]
afiftyp has quit []
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.0, revision: 5.2.0+git-7558-9b8fa92ef, build type: debug, sources date: 20160102, built on: 2024-02-17 21:13:17 UTC 5.2.0+git-7558-]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
acmeplus has quit []
apritzel has joined #linux-sunxi