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>
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>
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?
<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
<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>
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-]