<apritzel>
macromorgan: acmeplus: tokyovigilante: can you try to isolate when this "Failed to set core voltage! Can't set CPU frequency" shows exactly?
<apritzel>
and also which of the statements that set power_failed causes it? Is it axp_init(), calling pmic_bus_init()?
<apritzel>
also, what is the story with the SD boot? Does the SPL load, but anything further (TF-A, U-Boot) does not work?
<acmeplus>
Stays at the same Trying to boot from MMC1
<acmeplus>
In my tests the Failed to set core voltage! happens after a reset, if I power the board off completely it dissapears in the next boot. However I've not tested when it's triggered again but I suspect it's after a reboot without completely powering it off
<apritzel>
that actually makes sense (PMIC is still in RSB mode, SPL tries I2C), though I thought we fixed that, in Linux
ftg has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
<acmeplus>
I'm using tokyovigilante uboot and your axp717-WIP branch
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
<tokyovigilante>
macromorgan: apritzel's u-boot driver has an extra version check that was causing that bogus return value from axp_init(). Just return ret; after the pmic_bus_read() call. Some of the other AXPs have revisons or subtypes to check, not the 717 apparently. From memory I still get the "Failed to set core voltage!" error if I don't do a full cold shutdown of the AXP (ie pull the USB power with no
<tokyovigilante>
battery in). Annoying and will need fixing but that's how I've been getting it through and booted up at 1Ghz
<tokyovigilante>
It may be that early return is papering over another issue but the power delivery to the board seems ok, only other issue thus far is flaky bluetooth but I think that's downstream
<tokyovigilante>
apritzel: did you have an inkling of what DT fixes I would need for the gpu node?
<acmeplus>
tokyovigilante: I thought you had the gpu running earlier today, maybe you were talking about something else
<tokyovigilante>
No, apritzel has I think
<tokyovigilante>
Needs a DT node and either that register manually disabled or with apritzel's proper kernel driver fix
<acmeplus>
Ok, I only got it to recognize panfrost and load the module automatically, but I couldn't enable hdmi
<tokyovigilante>
oh yup
<tokyovigilante>
then I think jernej has HDMI support for the D1 potentially, which hopefully will be H616-adjacent
<tokyovigilante>
I don't even have a mini-HDMI adaptor yet (in the post from Amazon) so will get on it, but we can get the GPU up and poke it from the command-line at least
<tokyovigilante>
IMO none of that is really as impactful as the power LED ;)
<acmeplus>
I saw that today :) I spent some time trying to get hdmi with the DT but I'm sure it's not that easy. Same for audio
<acmeplus>
Did you get the rtl8821 wireless to work?
<tokyovigilante>
yup, that needs the driver enabled in the kernel though, with my DT
<tokyovigilante>
rtl8821-cs variant specifically, and you will need the firmware in your linux image. Fedora had it but they also use xz compression for firmware so had to enable that too
<tokyovigilante>
the bluetooth also works but weirdly flaky, likely a power delivery issue, it physically interfaces over a serial connection even though the chip itself (and the wifi) runs over SDIO
<acmeplus>
I had issues with the 4.9.170 and bluetooth consistency with batocera. It connects but tends to drops connections
<tokyovigilante>
it connects ok on my 6.8rc build, just seems to have trouble changing power states and spams the log with various power and out-of-order packet messages
vagrantc has joined #linux-sunxi
acmeplus has quit [Remote host closed the connection]
macromorgan has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
montjoie_ has quit [Remote host closed the connection]
chewitt has joined #linux-sunxi
montjoie has joined #linux-sunxi
pg12_ has joined #linux-sunxi
pg12 has quit [Ping timeout: 480 seconds]
pg12_ is now known as pg12
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
warpme has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #linux-sunxi
enick_416 has quit []
warpme has quit []
Syter has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
macromorgan has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<tokyovigilante>
I'm trying to be clever and start the RG35XX+ device tree work in the kernel, but am thinking I will need a base RG35XX, then one for the plus, and another for the H (the H adds thumbsticks and an extra USB port) but should I also be creating one for the H700? I'm relying on the H616 generic DTSI currently, so I'm guessing not
<tokyovigilante>
Also, acmeplus or macromorgan, are you able to post a vendor DT from the -H?
warpme has quit []
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: h700.dtsi: no, you don't need that, just use the h616.dtsi. The differences are so minor, and actually the H616 has the very same die, so has those extra peripherals as well, they are just not connected
<apritzel>
BT: is driven via UART, it just happens to share the same package with the WiFi chip, and probably some of the clocks and power supply. But programming wise WiFi goes via SDIO and BT via UART
<apritzel>
-H vs -Plus DT: if one is a subset of the former, it's probably fine to go with one main DT, and include that from the other one. Compare pine64 and pine64-plus
<apritzel>
video in general: please keep in mind that most Arm SoCs (including AW) use separate components for what goes as a "graphics card" on the PC side
<apritzel>
so you have the display engine, which regularly scans out a region of the DRAM
<apritzel>
this then connects to some module that translates this pixel data into some device specific interface
<apritzel>
one is HDMI, another is parallel (RGB) LCD, MIPI DSI is yet another (not present on the H700, but on the T507, I think)
<apritzel>
jernej had display engine patches in his github branch for a long while, and various downstream users like Armbian use them already
<apritzel>
this has also HDMI support (which is the only display interface supported by the H616)
<apritzel>
and if I understood jernej correctly, RGB LCD is not a big deal in our case
<apritzel>
the DE patches are not ready for upstream yet, there are some issues left to be fixed properly, but jernej would know more
<tokyovigilante>
Sounds good re the DT, The -Plus is a subset of the -H, just missing the extra USB and sticks, so that should work, ta.
<apritzel>
oh, and the 3D renderer (Mali GPU) is yet another component in this game: it renders directly into a memory region, ideally the framebuffer, so is somewhat independent from the rest
<tokyovigilante>
Thanks, I vaguely understood the component split, so in theory I just need the LCD and DE work from jernej to get 2D/framebuffer output? But the GPU should more or less also be supported on the kernel/mesa side, with some work potentially to understand what buffers are where
<apritzel>
I can post the DT snippet for Mali, to be used with the existing panfrost driver, and my GPU PPU patch
<tokyovigilante>
that would be awesome, if I can cobble together something that works we can more less finish the DT, get that upstream, then work on the remaining components. I can also think thermal, cpufreq, and sound codec
<apritzel>
tokyovigilante: the GPU should already work, courtesy of the panfrost driver being somewhat generic, and we provide the platform bits (clocks, power domain)
<apritzel>
thermal should be merged in the next day (the merge window opened on Sunday), cpufreq builds on top of that, with patches being ready, though I am thinking about improving them still
<tokyovigilante>
I have absolutely walked in at the right time
<apritzel>
I wouldn't post that in the merge window anyway, so you have to live another two weeks with 1GHz ;-)
<tokyovigilante>
LIKE AN ANIMAL ;)
<apritzel>
yeah, the H616 is seeing some activity at the moment
<apritzel>
regarding the DT: you should prepare some DT patches, but without any graphics related nodes, since the bindings are not fixed yet
Schimsalabim has quit [Read error: No route to host]
<apritzel>
oh, regarding BT: in my DT I had some 32K clock fanout properties commented, in the Wifi powerseq node. Try to uncomment them, I saw the vendor DT using that pin
<apritzel>
I don't know yet if this clock is used for BT or WiFi, but I guess the former, since WiFi somewhat works?
<apritzel>
it's odd that it works at all without the clock, so maybe it's not needed, but worth a try
<tokyovigilante>
Oh yup, will give that a roll. Wifi seems stable but was not blown away by the speed for 802.11ac (~2MB/s)
Schimsalabim has joined #linux-sunxi
<apritzel>
oh, also: the power key will not work, as the AXP interrupt is connected to the NMI pad, which we don't support yet: the H616 does not connect that pin
<apritzel>
this probably also affects some of the other AXP devices, like the charging and USB parts
<apritzel>
as usual there is little documentation about the NMI controller, but chances are it's close to the H6 version, and there are hopefully traces in some BSP code
<apritzel>
tokyovigilante: you mentioned the power LED, but in your DT you only include the LED header, but no actual DT nodes? Or did I miss that somehow?
junari has quit [Ping timeout: 480 seconds]
<tokyovigilante>
I just lifted it from the vendor DT, and it seems to be automagically working
<tokyovigilante>
and the charge led works regardless, and even when the device is off, so I assume that's directly wired to the PMIC
<tokyovigilante>
Should I post links directly to current patches on the wiki?
hlauer has joined #linux-sunxi
hlauer_ has joined #linux-sunxi
<tokyovigilante>
And should the gpu reference DCDC1 or 2? the other DTs say VCC-SYS rather than VCC-CPU, so I'm guessing DCDC2?
<tokyovigilante>
Oh whoops, re led no I missed I hadn't actually committed the node.
<tokyovigilante>
Just trying to add the 32k clock, and I assume I should add it to the h616 dts first?
<apritzel>
the bits should be in the .dtsi already (due to the Transpeed box), you just need to specify the pinmux, so that the internally generated 32KHz clock is output to pin PG10
<apritzel>
and Mali is most likely connected to DCDC2. DCDC1 is the CPU rail, it's typically exclusive, since that's what cpufreq changes
dsimic is now known as Guest2523
dsimic has joined #linux-sunxi
Guest2523 has quit [Ping timeout: 480 seconds]
<apritzel>
tokyovigilante: if you want to post links to patches, use a branch, ideally with a somewhat stable name. Your U-Boot branch would be fine
bauen1 has quit [Ping timeout: 480 seconds]
tolthoff has joined #linux-sunxi
tolthoff has quit [Remote host closed the connection]
<libv>
does anyone know why the sinovoip banana pi m2 zero is not in u-boot?
<libv>
also, why is the dts subdirectory called allwinner and not sunxi?
Daanct12 has quit [Quit: WeeChat 4.2.1]
<apritzel>
because that's the name of the company and for the property vendor prefix?
<libv>
ok, seems out of sync with everything else
<apritzel>
how so? sunxi is more a platform name, and those things are strictly by vendor name
<apritzel>
same story with meson and Amlogic
<libv>
yes, i understand that, it just is not what i and i guess a lot of others are used to look for
<Jookia>
it threw me a bit considering they use to be prefied with sunxi names but i'm happier with the way it is now than before
<apritzel>
libv: boards get supported in mainline if *someone* in possession of the board cares enough to send a DT to Linux and then a defconfig patch to U-Boot
<libv>
apritzel: this i know as well, i just wonder if something else happened
<libv>
there seems to be patches around
<apritzel>
nothing happened, that's why there is no progress ;-)
<libv>
ok
<apritzel>
I sent DT patches for the BananaPi M4 Berry, but since no one tested them, they are stuck
<Jookia>
apritzel: you can't just get them merged?
<apritzel>
Jookia: I don't want to. I wrote the DT patches because someone in here asked me and it was easy enough to do, with the schematic available, and the SoC and PMIC already supported
<Jookia>
oh, so you don't have the device?
<Jookia>
that makes sense, i was confused a bit
<apritzel>
exactly, and without the DT being tested on real hardware, this shouldn't go anywhere
<Jookia>
yeah, definitely
acmeplus has joined #linux-sunxi
<libv>
if they get mentioned in the wiki, and listed as untested, someone might test them
<libv>
when you open a user page, you should see "Email this user" under "tools" in the left menu table
<acmeplus>
tokyovigilante: did you get the rg35xx H DT? I'll post it later if you don't have it. As I mentioned before it's completely compatible with the plus, where the analogues are just ignored
<libv>
meh, the mw parsers adds either newlines or new paragraphs almost willynilly
<libv>
found it, but why is this always so difficult.
macromorgan has joined #linux-sunxi
acmeplus has quit [Remote host closed the connection]
<apritzel>
tokyovigilante: thanks btw for the response and the test on the mailing list!
junari has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<macromorgan>
apritzel: It fails at the axp_init() in the sunxi_board_init() function under board/sunxi/board.c
<apritzel>
macromorgan: so are you using the original code, as in my WIP branch? As tokyovigilante mentioned, this is overzealous with checking the chip ID, so would fail all the time
<macromorgan>
your WIP branch
<apritzel>
can you actually dump the chip ID read in there?
<macromorgan>
let me check Tokyo's branch
<macromorgan>
let me try that too
<apritzel>
I took the values and mask from some BSP code, but apparently those were not correct
<macromorgan>
problem is I don't know if it ever does that... SPL_PMIC_AXP needs to be enabled to get to that point
<macromorgan>
which needs driver model, which causes me to run out of room in the sram
<apritzel>
no no no, please no DM in the SPL
<apritzel>
that's not needed, and cause much more pain than you want to endure, I guess
<macromorgan>
right... and uclass_get_device_by_driver needs it right?
<macromorgan>
maybe, let me look more
<apritzel>
I think you took a wrong turn somewhere ... not blaming you, that code is confusing
<apritzel>
we are talking about drivers/power/axp717.c:axp_init(), which calls pmic_bus_init(), which is basically a NOP in our case
<apritzel>
so we just end up calling i2c_read() right away, and all the parameters are hardcoded in the .config
vagrantc has joined #linux-sunxi
<apritzel>
it's borderline whether the whole idea of sharing code between the SPL and U-Boot proper really still makes sense here, at least without SPL_DM
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
it's effectively two different code paths, somewhat funneled through the same interface
<macromorgan>
okay
<macromorgan>
the i2c_read is what's giving the funky return value, so I figured we should have been calling that code. Let me back it all out and try to troubleshoot the i2c call again
<macromorgan>
presume that's the i2c_read() that's actually returning that value based on what's enabled and whatnot
<apritzel>
oh, have you changed the I2C address?
<macromorgan>
no
<apritzel>
I think this was also wrong in my branch, but tokyovigilante fixed that
<macromorgan>
okay
<macromorgan>
let me check his branch again
<apritzel>
it's the old question of whether the address is with or without the R/W bit
<apritzel>
should be #define AXP717_I2C_ADDR 0x34
<macromorgan>
looks like he's got it at 34 right
<apritzel>
I will push fixes to my branch to avoid confusion in the future. Sorry about that
<macromorgan>
okay, now it's reading a chip ID of 255... let me double check the mask
<macromorgan>
yeah, chip ID shows 0xff
<apritzel>
0xff sounds more like not working I2C bus?
<apritzel>
do you have CONFIG_R_I2C_ENABLE, CONFIG_SYS_I2C_SLAVE=0x7f and CONFIG_SYS_I2C_SPEED=400000 in your defconfig?
wasutton- has joined #linux-sunxi
wasutton| has joined #linux-sunxi
<macromorgan>
let me triple check
<macromorgan>
yes I do
<apritzel>
try to read other registers, like 0x5, that should be 0xff
<apritzel>
should *not* be 0xff
wasutton3 has quit [Ping timeout: 480 seconds]
wasutton3 has joined #linux-sunxi
wasutton^ has joined #linux-sunxi
<macromorgan>
okay will do
<macromorgan>
okay... PMIC_ID is still 0xff, register 0x05 is 0x70
wasutton- has quit [Ping timeout: 480 seconds]
<macromorgan>
so I guess it's reading something...
wasutton| has quit [Ping timeout: 480 seconds]
wasutton3 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
junari has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
macromorgan: ok, thanks, I guess I will remove the ID check then completely
hlauer_ has quit [Remote host closed the connection]
hlauer has quit [Remote host closed the connection]
<macromorgan>
still freezing before it loads A-TF, but I need to check more (if it's dying while initing the SD card or what it's doing)
<apritzel>
after all the register isn't documented, though I think many AXPs had an ID register at this address
warpme has quit []
<apritzel>
so out of desperation: we had an issue with some mis-compiled/buggy DRAM init code a while ago, on the H616, which only showed with either FEL or MMC booting (don't remember which it was)
<apritzel>
it didn't show with GCC 10, but with everything later
<apritzel>
I think the problem vanished, though I don't think we ever found the real root cause
<apritzel>
so if you can grab some GCC 10 cross compiler, for instance some binaries from kernel.org or bootlin, you could give this a go
<macromorgan>
I'll try next
acmeplus has joined #linux-sunxi
<apritzel>
thanks! So do I get this correctly that no one has successfully ran U-Boot from an SD card on the RG35XX so far?
<acmeplus>
not here, tried also to use older GCC 9 and no changes
acmeplus has quit [Quit: Page closed]
<apritzel>
thats ... unfortunate
<macromorgan>
nothing different with GCC 10 for me
<apritzel>
too bad, but many thanks for trying
acmeplus has joined #linux-sunxi
<macromorgan>
load_image is where it's dying, going to keep digging
ungeskriptet is now known as Guest2550
ungeskriptet has joined #linux-sunxi
<macromorgan>
in spl_load_image() the loader->load_image() is where it stops executing, I'll continue to dig
<macromorgan>
the sizeof (*mmc) is only 432, wonder why calloc is crapping out
<tokyovigilante>
Have updated the wiki with what's working (for me at least...) and what's not
<tokyovigilante>
sounds promising macromorgan, did you get past the axp_init issue? I disabled the board check more or less entirely in my version of the driver (functionally otherwise more or less the same as apritzel's) and a heap of debug logs show the subsequent DCDC2/3 setting over I2C working
<macromorgan>
yes, AXP init working fine for me now
<tokyovigilante>
awesome. and you're trying to fix SD boot now?
<macromorgan>
yes, correct
<tokyovigilante>
good luck! Dropping the kids at school and will look in later in the morning
<macromorgan>
yeah, for now it's dying at that calloc() in mmc_create()
acmeplus has joined #linux-sunxi
<macromorgan>
all I can think of is maybe the malloc address is wrong or something?
apritzel has joined #linux-sunxi
acmeplus has quit [Remote host closed the connection]
<apritzel>
macromorgan: interesting, many thanks for digging into this, and it makes somewhat sense, as the MMC code is the first one to need serious memory (for the buffers)
<apritzel>
but again this points to DRAM issues, which we thought we have solved?
<apritzel>
so that would mean that the DRAM code works when doing FEL booting, but does not when loading via MMC
<apritzel>
well, it's something less obvious, since it passes the internal checks and reports the proper DRAM size
<apritzel>
what you can do is try to hack something in, after the DRAM init, and do some DRAM testing:
<apritzel>
read some words, write some words, read back, etc
<apritzel>
DRAM starts at 0x40000000, and should be entirely at your disposal at this point
<apritzel>
just keep in mind that the MMU is still off, so no unaligned accesses
bauen1 has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
<macromorgan>
I wonder why on earth it would work fine if you did it via FEL though
<macromorgan>
(not that I've tried FEL)
apritzel has quit [Ping timeout: 480 seconds]
Syter has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<tokyovigilante>
apritzel: bluetooth function significantly improved by adding the 32x clock node in the h616 dtsi and uncommenting the references in the board DTS. Still getting
<tokyovigilante>
[ 129.865651] rtw_8821cs mmc1:0001:1: firmware failed to leave lps state
<tokyovigilante>
every few seconds, but functionally seems much improved
<tokyovigilante>
hmm, perhaps not
<tokyovigilante>
connected a bluetooth keyboard and just spewing [ 297.748019] rtw_8821cs mmc1:0001:1: failed to send h2c command
<tokyovigilante>
and wifi then stops working until I power the bluetooth back off
<tokyovigilante>
I see as well as the 32mhz clock, there is also a pin for a 40Mhz crystal? will that just be on the board somewhere and I can ignore it?
<tokyovigilante>
I did find the -CE version the other night, but then have lost that tab, will see if I can dig it back out
vagrantc has quit [Remote host closed the connection]
<apritzel>
macromorgan: I see your tested-by tag on the 8821CS driver, and it is used in other Anbernic consoles, can you help out with a datasheet, or have a contact (Martin maybe?) to provide one?
vagrantc has joined #linux-sunxi
<apritzel>
tokyovigilante: that dump is good info, but probably material for an email to the Realtek Wifi developers? Where you could also ask for a datasheet, or information about platform requirements?
<tokyovigilante>
sure, just their mailing list?
<apritzel>
git show b2a777d68434 provides some pointers, also: $ scripts/get_maintainer.pl -f drivers/net/wireless/realtek/rtw88/rtw8821cs.c
<apritzel>
please CC: linux-sunxi@lists.linux.dev
<tokyovigilante>
ta
<tokyovigilante>
fiddling with the GPU DTS bits as well, got as far as [ OK ] Stopped 11.554966] panfrost 1800000.gpu: clock rate = 432000000
<apritzel>
the system locking up is a sign of this power domain bit being wrong
<macromorgan>
I sadly don't have one. I just tested that the driver worked for me and I was able to connect/use it
<tokyovigilante>
just waiting for my kernel tree to unshallow...
<tokyovigilante>
and am severely undercaffeinated
<apritzel>
tokyovigilante: do you have my GPU PPU patch? Inside the Mali node you then need "power-domains = <&r_ccu 0>;"
acmeplus has joined #linux-sunxi
<tokyovigilante>
oops no. I've taken the larger H616 gpu block from the orangepi with all the IRQs etc, and then just a smaller block in the board dts with the power rail
<acmeplus>
I get the panfrost to load correctly, but at the end: platform 1800000.gpu: deferred probe pending: panfrost: _opp_set_regulators: no regulator (mali) found
<tokyovigilante>
nice acmeplus, we should compare DTs also
<apritzel>
tokyovigilante: well, don't worry, that's new, and I don't think posted this particular line somewhere
<apritzel>
mali-supply = <®_dcdc2>;
<tokyovigilante>
man, hard links are underrated
<acmeplus>
note to self, I need to get a proper micro sdcard reader....
<acmeplus>
apritzel: thank, that was with a manualy patched dts, so the handle was wrong and not pointing to dcdc2. I'll try again later
<tokyovigilante>
ok, still struggling, but progress
<tokyovigilante>
[ 11.291720] panfrost 1800000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found
<tokyovigilante>
[ 11.301578] panfrost 1800000.gpu: supply mali not found, using dummy regulator
<tokyovigilante>
should I have a &mali block in addition to &gpu?
<apritzel>
no, just gpu
<tokyovigilante>
ok, and will I need defintely either jernej's register hack or your patchset? I have built them but not copied it to the device yet
<acmeplus>
tokyovigilante: did you apply the kernel patch that apritzel posted the other day?
<tokyovigilante>
that is what I think I'm missing
<tokyovigilante>
just need to rebuild
<apritzel>
tokyovigilante: you need my patch to add a power domain device to the r_ccu device, otherwise you will keep seeing those messages above
<tokyovigilante>
ta, just rebuilding the kernel now.
<apritzel>
acmeplus: any idea how the analogue sticks on the -H are connected? was there a vendor DT already?
<acmeplus>
Let me find the DT and post it, I believe they were just defined in the DT
<tokyovigilante>
hmm, still no joy with the power domain patch
<tokyovigilante>
oh sorry, pebkac, extra quotes not required
<acmeplus>
macromorgan: I can confirm it gets stuck on the calloc call in mmc_create
<acmeplus>
Is there a way we can compare the values with the ones used in the stock/bsp? I believe when I compiled it the uboot was booting correctly (but display not initialized because its missing the vendor patches)
<tokyovigilante>
that part where you realise that not only did your power-domains line was quoted, but your whole gpu block was commented out...
acmeplus has quit [Remote host closed the connection]
<apritzel>
acmeplus: you can dump the DRAM controller register values in U-Boot, but there are a lot of them, and it's not easy to deduce how to get to the same result (same values are dynamic)
<tokyovigilante>
outstanding
<tokyovigilante>
gpu_sched 40960 1 panfrost
<apritzel>
\o/
<tokyovigilante>
still getting messages about regulators
<tokyovigilante>
[ 21.002491] platform 1800000.gpu: deferred probe pending: panfrost: _opp_set_regulators: no regulator (mali) found
<tokyovigilante>
but booted up fine
<tokyovigilante>
will install mesa and see what the glxinfo goss is
<apritzel>
don't you need a running X server for that?
<apritzel>
tokyovigilante: can you check /sys/kernel/debug/devices_deferred? Maybe that message is just the temporary one, because mali probed before the AXP?
<apritzel>
(in which case we should send a patch to demote that message)
<tokyovigilante>
1800000.gpu panfrost: _opp_set_regulators: no regulator (mali) found
<tokyovigilante>
also seems to have broken wifi
<apritzel>
ok, maybe not, this file should be empty after boot
<apritzel>
are you sure the AXP driver is happy?
<tokyovigilante>
hmm, maybe not. Missing quite a few from cat /sys/kernel/debug/regulator/regulator_summary
<tokyovigilante>
only have vcc-5v, vcc-3v3, and vcc-1v8, then a bunch of dummy ones
<tokyovigilante>
swear it had all the LDO regulators there previously
<tokyovigilante>
or rather, when booting from the vendor BSP
<tokyovigilante>
[ 11.167764] OF: /soc/gpu@1800000: could not get #power-domain-cells for /soc/clock@7010000
<tokyovigilante>
in the log
<apritzel>
ah, right, you need: #power-domain-cells = <1>; in the r_ccu node in h616.dtsi
<apritzel>
but the missing AXP regulators are worrying, any hints on what happened with the AXP driver in dmesg?
<tokyovigilante>
cool, also even bigger pebkac involving not building the AXP driver in that branch, was putting my DTS changes in there
vagrantc has quit [Quit: leaving]
<tokyovigilante>
sorry, hard to find good help
Asara has quit [Quit: Lost terminal]
Asara has joined #linux-sunxi
<apritzel>
that would indeed explain it ;-)
<tokyovigilante>
[drm] Initialized panfrost 1.2.0 20180908 for 1800000.gpu on minor 0
<tokyovigilante>
NICE
<Jookia>
hype
<tokyovigilante>
Have a GPU and wifi at the same time even
<Jookia>
you're making awesome progress
<tokyovigilante>
I can take absolutely no credit, all your advice
<tokyovigilante>
[ryan@fedora ~]$ vulkaninfo
<tokyovigilante>
'DISPLAY' environment variable not set... skipping surface info
<tokyovigilante>
ERROR: [../src/panfrost/vulkan/panvk_device.c:381] Code 0 : WARNING: panvk is not a conformant vulkan implementation, pass PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1 if you know what you're doing. (VK_ERROR_INCOMPATIBLE_DRIVER)
<tokyovigilante>
successfully crashed after that
<tokyovigilante>
still, was quite optimistic
<Jookia>
yeah most likely needs a display server or something
<tokyovigilante>
yup
<tokyovigilante>
well, my HDMI adaptor is still in Amazon's bowels somewhere, so the LCD it is...
<apritzel>
I guess X forwarding over that flaky WiFi is not an option?
<tokyovigilante>
Could give it a go I suppose...
<apritzel>
maybe even some dummy X server would do?