ftg has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
<acmeplus>
apritzel: quick update, sunxi-fel from my mac seems to be working and producing bl31 traces... Just tested on the H, but then I tried again from the mac on the plus and traces are now coming. So something's off with my ubuntu box and the usb cable......
<tokyovigilante>
acmeplus: looks good, think it's failing because of the missing DRM/graphics
<tokyovigilante>
you might be better with a plain Debian/Fedora/Ubuntu server rootfs image
<acmeplus>
Yeah, I'm not very concerned about that, I have adapted it now and I have a regular prompt. Just tested the GPIO_keys and are working, good job there too.
<tokyovigilante>
I wonder if it might be a USB power issue or something else related to USB on your ubuntu system, I think after the fel u-boot stage the USB connection is reset, as it's taken over by whatever OS (u-boot, TF-A, or linux proper) is running at that point. Maybe not though, as at that point the device has everything it needs and you should still get a boot output over serial
<tokyovigilante>
oh nice
<tokyovigilante>
well I would say next priorities are 1. fleshing out the device tree, 2, either enabling (or displaying if internal) battery charging support, 3. display timing controller and RGB output support, then 4. enablement for the GPU and sound. That would get us all the way to working untethered hardware, and the various replacement OS teams can build on top. Video acceleration (for H264 and 265 at
<tokyovigilante>
least) would be amazing, but probably a bit of work to bring over from earlier iterations.
<acmeplus>
Yeah, those are good priorities. MMC boot is also failing, so something to look at so we can build a full bootable sdcard
<tokyovigilante>
Annoying, I haven't actually tried dumping a working image on a card since I discovered the wonders of FEL-boot
<tokyovigilante>
I wonder how important crust is? Doesn't look like H616 is implemented there yet
<tokyovigilante>
I also wonder how much of a hack this is?>
<acmeplus>
Did you compare with the orangepi zero2w/3?
<tokyovigilante>
just reading through the armbian forums about it
<tokyovigilante>
Oh yeah, LEDs on the list. I should really update the sunxi wiki
flyback has left #linux-sunxi [#linux-sunxi]
vagrantc has quit [Quit: leaving]
junari has joined #linux-sunxi
junari has quit []
junari has joined #linux-sunxi
<junari>
tokyovigilante: crust is nott needed because sun50iw9s doesn't have a co-processor
<junari>
gpu enable hack only changes one register, it's not critical. There is no infrastructure for this in the kernel yet. But apritzel sent patches for that
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
norton has joined #linux-sunxi
chewitt has joined #linux-sunxi
norton has quit [Ping timeout: 480 seconds]
junari_ has joined #linux-sunxi
junari has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
junari has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
junari_ has quit [Remote host closed the connection]
hentai has quit [Read error: No route to host]
hentai has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
<tokyovigilante>
oh great, thanks
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
warpme 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
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
mripard has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<karlp>
fel boot is fantastic.
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<tokyovigilante>
Ah nice, got the power LED working, looks like the battery charger LED is driven directly from the PMIC, so doesn't need adding to the DT
<tokyovigilante>
there are plenty of updates to go on the page!
<Jookia>
no scanout
<Jookia>
hehe
<apritzel>
and if I got jernej correctly, the video encoder/decoders are not complicated, I think they are already working in various community H616 trees
<tokyovigilante>
I mean, who needs to see it? sudo dnf install crysis
<apritzel>
yeah, scanout is just for people without imagination!
<apritzel>
(well the video encoders *are* complicated, but not that much different from the previous generations, so not too much of a blocker)
<apritzel>
tokyovigilante: have a good one
<junari>
ffmpeg-v4l2-request should be installed for VPU support
<karlp>
lol, corpo hell opendns decided that git.sr.ht isn't a "good" domain,btu the git.sr.ht hsts policy still holds, so it fails to even show me the opendns "lol, no page for you!" because that relies on their absurd MitM SSL cert :)
<libv>
apritzel: so lack of imagination is why people dismissed me for years when i was one of the only people left driving display driver development in the mid 2000s
<libv>
thanks for clearing that up for me
<libv>
for years i was certain that people didn't care because 3d engines were sexier
<libv>
but all it was was a lack of imagination
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
warpme has quit []
<Jookia>
anything that can't be used to play video games is basically boring when it comes to software dev
<Jookia>
that's my theory of how resources get allocated
warpme has joined #linux-sunxi
<apritzel>
does anyone know why our cpufreq DT nodes (for H6 and beyond) do not use the opp-supported-hw property?
bauen1 has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest2434
dsimic has joined #linux-sunxi
Guest2434 has quit [Ping timeout: 480 seconds]
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
warpme has quit []
KREYREN_oftc has quit [Remote host closed the connection]
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
<junari>
tokyovigilante: I can try to build a manjaro image with hdmi support if the provided dts has the correct nodes
<jernej>
apritzel: If you manage to make it work with that property, I'm all for it
<jernej>
I, for one, I'm glad for fixed display pipeline. At least on AW it's often more powerful for some usecases, like video playback.
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<jernej>
apritzel: do you know how that property is supposed to work?
<apritzel>
so the idea is that this is a mask, of speedbins that support this particular OPP
<apritzel>
so if you have 5 speedbin, 0x1f would mean supported in all of them, while 0x03 would mean only supported in two
<apritzel>
this applies to a particular OPP, in whole
<apritzel>
so for supporting this frequency, but at a different voltage, you would describe two OPPs, with disjunct masks
<apritzel>
I am still trying to figure out if this makes a real difference, or if those opp-microvolt-speed<X> properties are just a more compact way of describing things, in our case
<apritzel>
for the H616 it seems this opp-microvolt-speed<X> approach isn't enough anyway, since some OPPs are not mentioned for some speedbins, which the generic code doesn't like, IIRC
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<jernej>
I can't find the code where this is mask is checked in hw. How kernel gets hw ID? Via TF-A?
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
that's exactly the problem, that is not specified in the binding, so you still need a platform specific driver that sets this mask, via dev_pm_opp_set_config()
<apritzel>
so at the end it might not matter, whether we use dev_pm_opp_set_config() or dev_pm_opp_set_prop_name(), as we do now. It sounds nicer to use the mask, and seems to be more widely used, but I am not sure
<apritzel>
I guess I give it a try and we can look at actual code
apritzel has quit [Ping timeout: 480 seconds]
<Jookia>
*sprinkling DAI properties all over my DT* please work please work please work
diego71 has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
diego71 has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<Jookia>
i got 2x 8-channel tdm 100khz 32-bit audio capture working
bauen1 has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
vagrantc has joined #linux-sunxi
<apritzel>
on what SoC again?
<Jookia>
T113
<Jookia>
Looks like it can do 200khz, it's just IO bound
<Jookia>
I have a loong patch series to make all this possible that I'm going to have to sort out this week
apritzel has quit [Ping timeout: 480 seconds]
<Jookia>
i'm doing this all as work for someone who is making a device starring the t113, but from what i gather having a very low power chip be able to handle so many audio channels and multiplex them in different ways is pretty cool
<Jookia>
having accurate variable clocking is also very useful as it avoids having to implement a filter in software which the t113 might not be capable of
<Jookia>
i believe the h616 can do all this too
<Jookia>
and the d1
warpme has joined #linux-sunxi
<libv>
what audio chip is that?
<libv>
the ti pcm3168 is a pretty powerful chip it seems
<macromorgan>
getting error of "Failed to set core voltage! Can't set CPU frequency" and finding it happens because pmic_bus_init() returns 21504024 for some reason
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<Jookia>
libv: cs5638 for 8 channel tdm, i'm going to try mainlining my driver for it
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
<macromorgan>
is there a datasheet yet for the H700? I'm wondering if my issue is that we need DM enabled in SPL for U-Boot... but the default size for SPL is so small I can't seem to get away with that...
ftg has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
macromorgan: this frequency setting is a known issue, because of the AXP being driven via RSB in Linux and TF-A and I2C in the SPL
<apritzel>
I think people had success with cutting off the TF-A part short
<macromorgan>
I'm trying to boot from SDMMC (not messing with FEL at the moment) and it doesn't look like it ever gets to read the SDMMC. I think we need to get the regulators running before we can even get to that part.
<macromorgan>
basically I never even get to the point to read the A-TF binary, it just dies
<apritzel>
but if this is about booting from SD card, that's unrelated
<apritzel>
there cannot be any AXP related issue with SD booting, because it's the BROM doing that part, and this does not know about any PMICs
<apritzel>
so the reset I/O voltage for PortF must be 3.3V, and the SD card must be powered when the system comes up
<macromorgan>
okay, I will dig in more then
<macromorgan>
do you think we should try to set up the regs in A-TF like they do for the axp803 and axp805?
<apritzel>
no, we should skip the whole PMIC setup in TF-A altogether
<apritzel>
TF-A runs after the SPL, so it doesn't help anyway
<macromorgan>
okay... do you think we should have an ifdef to tell us to skip regulator setup in there for the h616, or should we make h700 a new target (not sure if it's different enough to warrant that)?
<apritzel>
eventually my plan is to remove or at least disable the regulator code in TF-A, but we need U-Boot catching up first
<apritzel>
there is already such a config option in TF-A
<macromorgan>
right, but it's not plumbed correctly for the 616
<apritzel>
SUNXI_SETUP_REGULATORS=0
<macromorgan>
correct
<apritzel>
it just skips the regulator setup
<apritzel>
but still initialises the PMIC
<apritzel>
because we need this anyway for power off
<macromorgan>
okay, so we don't need to skip initalization?
<macromorgan>
I can try to wire it up then in there (I think we need a hardware address don't we)?
<macromorgan>
but for now that feels like a tomorrow morning problem :-)
<apritzel>
in TF-A?
<apritzel>
You can try to skip the whole TF-A PMIC code, by hacking this: if you put "return 0;" just before the rsb_init() call in TF-A's plat/allwinner/sun50i_h616/sunxi_power.c
<macromorgan>
yes, but I'd rather init it correctly if we need it
<apritzel>
this won't work easily anyway
<macromorgan>
nothing ever does it seems
<apritzel>
because there is no AXP717 support in TF-A
<apritzel>
anyway I don't think that's the problem
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]