smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
smaeul has quit [Quit: Down for maintenance...]
smaeul has joined #linux-sunxi
Asara_ has joined #linux-sunxi
Asara has quit [Ping timeout: 480 seconds]
pnill has joined #linux-sunxi
pnill has quit [Remote host closed the connection]
pnill has joined #linux-sunxi
Asara_ has quit [Ping timeout: 480 seconds]
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 480 seconds]
Asara has joined #linux-sunxi
apritzel has joined #linux-sunxi
Asara has quit [Quit: leaving]
Asara has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cmeerw has quit [Ping timeout: 480 seconds]
chewitt has joined #linux-sunxi
chewitt has quit []
chewitt has joined #linux-sunxi
tnovotny has joined #linux-sunxi
maz has joined #linux-sunxi
Xalius has joined #linux-sunxi
apritzel has joined #linux-sunxi
buZz has quit [Quit: Reconnecting]
buZz has joined #linux-sunxi
chewitt_ has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
rtp has joined #linux-sunxi
zumbi has joined #linux-sunxi
<warpme_>
guys: i'm hacking h616 tanix-tx6s with adding gpu & cedrus. it looks like cedrus is loading and reporting ok supported decode formats but g31 gpu is not loading and says:
<warpme_>
i have decompiled android DT for this box. maybe somebody has clue where issue might be?
<warpme_>
i don't know: is this because my mistake in DT or rather there are still missing code in kernel to get g31 running on h616 ?
<libv>
cedrus has nothing to do with the mali
<libv>
cedrus is the media encoding decoding engine that allwinner developed "in house"
<plaes>
also, h616 has panfrost?
<libv>
(probably by taking gpl and public domain code, and pouring hot paths into hw)
<libv>
oh, sorry, Lgpl code
<warpme_>
libv: re cedrus vs. mail. of course :-). i was trying only to say that to get tx6s as basic madia player i got loading hw.video decoder (cedrus) but fail with gl hw (g31 bifrost)
<libv>
warpme_: ok
<warpme_>
mail> mali
<warpme_>
current h616 support seems start to look really encouraging (thx. jernej & apritzel excellent work). Box has working: usb, eth, hdmi, cec, ir, vdec. missings: gl and audio
<apritzel>
plaes: the H616 has a Mali-G31, which is the smallest Bifrost GPU - and that should be supported by Panfrost (if that was your question)
<apritzel>
it looks like the RK3326 aka PX30 uses G31 as well, and reportedly panfrost works quite nicely there
<apritzel>
warpme_: what does your DT node look like?
<warpme_>
apritzel: yes. g31 is well supported. i have it running very well on amlogic sm1. so for sure it will work well on h616 i think. currently mesa panfrost loads on my h616 but complains about mem region (see my msg from 11:44AM)
<apritzel>
warpme_: I saw that message, but what is your DT node? The error suggests there is an issue with the reg property?
<apritzel>
warpme_: or it may be a CMA problem? Or a 4GB issue? Do you have a box with 4GB and Linux also sees all of it?
choozy has quit [Remote host closed the connection]
<warpme_>
ough
<apritzel>
warpme_: do you have a mali-supply in the DT node?
<warpme_>
i have following:
<warpme_>
&gpu {
<warpme_>
mali-supply = <®_dcdcc>;
<warpme_>
};
<warpme_>
status = "okay";
<apritzel>
hanging at this point could also be missing or wrong resets or clocks
<warpme_>
mayby dcdcc voltage is too low?
<warpme_>
resets or clocks i was trying to sync with adroid DT + 5.12 dt-bindings
<warpme_>
sorry: i sync interrupts to android DT. reset & clocks are synced with dt-bindings
<warpme_>
but maybe i done this wrongly - so 2nd pair of eyes will be really helpful...
<warpme_>
changing dcdcc to 1.08v not helps
<warpme_>
i'm not sure: isn't that jernej mentioned sometime ago that h616 needs some magic to get gpu powered (or clocked). i don't remember as it was months ago....
<warpme_>
apritzel: i'm too weak in uboot internals to address "mw.l 0x07010254 0". what will be your advice?
<apritzel>
libv: wiki? the DT bits should be in a patch sent to the list ...
<apritzel>
warpme_: I don't know yet. We could add it somewhere in the SPL (I think there are similar hacks already)
<apritzel>
or model it as a power domain in Linux, but I don't know how accessible it is from non-secure
<apritzel>
it seems like I can't flip it on the H6 from non-secure, but it works on the H616
<libv>
until the fix is in, and even then it will take months for everyone to be on the same u-boot versions
Mangy_Dog has left #linux-sunxi [#linux-sunxi]
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Remote host closed the connection]
Mangy_Dog has joined #linux-sunxi
<Mangy_Dog>
testing
<Mangy_Dog>
there we go working
<libv>
:)
<ssvb>
apritzel: It's best to have both patch sent to the list and also documented in the wiki for anyone who may be interested in being able to easily reproduce the results. Mentioning any other dependent/required patches, versions of the kernel & u-boot, their configuration options and anything else that may be important. Such trivial things may easily save a lot of time for those who want to quickly get up to speed.
<gediz0x539>
apritzel: SD card CD problem was stemming from the hardware. thanks for your help.
<gediz0x539>
now "mmc: mmc-uclass: Use dev_seq() to read aliases> node's index" bit me :)
<gediz0x539>
i'm using "Bring back SD card as MMC device 0" patch
<gediz0x539>
btw, isn't this dev_seq alias change a breaking one?
<gediz0x539>
is there a mechanism to alert maintainers about something like this?
<apritzel>
gediz0x539: it's a general problem, similar to the kernel: there was never the promise of stable numbering, it just happened to be
<apritzel>
and we had this mmc1=&mmc2 hack in place to make it work
gnarface has joined #linux-sunxi
<apritzel>
also the doc always explicitly mentioned that gaps wouldn't be filled, this was just not in effect, for some reason
<apritzel>
gediz0x539: the mechanism is called "merge window" and "testing" ;-)
<karlp>
so, what's the "expected" soon to be outcome? will sd always be mmc0, and emmc be... whatever numebr it ends up as, depending on whether there's an sdio card on mmc1 or whatnot?
<gediz0x539>
apritzel: I see
<karlp>
will emmc always have a stable number? it's not going to change depending on the presence of an sd card right?
<gediz0x539>
so the same thing is in place for U-Boot?
<gediz0x539>
oh sorry it's different.
<apritzel>
gediz0x539: yes, a version of this patch was merged in Linux, so you can force stable numbering via DT aliases
<apritzel>
and Rockchip got those aliases in the mainline DT, but mripard is not really happy with that for sunxi
<apritzel>
karlp: ideally you don't make any assumptions about numbering
<apritzel>
karlp: I posted a patch for the fastboot command to make it more robust, and do what we really mean: use the eMMC if available, of the SD card otherwise
<libv>
to whoever is here but still lurking on #linux-sunxi freenode, please leave the channel on freenode
<apritzel>
ideally we can do away with using those fixed numbers, and use something like $emmc_dev or $sd_dev, or something like $boot_dev (contains the device we booted from)
<apritzel>
in the short run I am going to merge the mmc0=&mmc0 patch, to restore the old behaviour
<apritzel>
karlp: gediz0x539: happy to hear opinions about it. U-Boot seems to be used in many different ways ...
<gediz0x539>
apritzel: i have no idea about how Rockchip works. but if it just works™, what's the drawback to use it also for sunxi?
<gediz0x539>
i actually think twice before commenting about something because while not being able to contribute anything, complaining is not a cool behaviour imho.
<apritzel>
gediz0x539: but hearing opinions from users is very important
<apritzel>
gediz0x539: just to be sure: the Rockchip patch is for the kernel, where it's a slightly different situation
<apritzel>
as mripard rightfully argues, one should not rely on /dev/sda being your first hard disk
<apritzel>
and there is no real reason this shouldn't apply to /dev/mmcblk as well
Danct12 has quit [Read error: Connection reset by peer]
<gediz0x539>
oh i see now. they're not that relevant as i thought.
<karlp>
apritzel: I'm just concerned about the suggestions of using UUID stuff when I want to make boot script that works on multiple devices,
<karlp>
I want to flash the same image to all of them, and make sure it boots ok regardless of whether the user has put in an sd card for extra storage or not.
<karlp>
I haven't failed on any of this yet, just concerned as I know it's in my future:)
<apritzel>
karlp: I hear you
<apritzel>
karlp: are you talking about U-Boot?
<apritzel>
karlp: so you mean you flash U-Boot to eMMC, and want to only load env and boot.scr (or whatever) from eMMC?
<apritzel>
karlp: and not be thrown off by a user inserting some SD card with a boot.scr on it?
<apritzel>
this should be covered by using something like $boot_dev, which would be set at runtime to the device number that we booted from
<karlp>
apritzel: correct.
<karlp>
I know that sd card is always higher priorty, andd that's ok, if they stick something speciall formatted in,
<karlp>
but for "normal" cases, with the sd card just being a fat/ext/whatever "bulk disk" I want to be happy that both uboot boot env and linux will not have things jump around.
<apritzel>
so that's a problem already: the SPL does it right: it looks at SRAMA1[0x28] and loads U-Boot proper from the same device
<apritzel>
but U-Boot proper fixes the boot device number at compile time, to be eMMC when you enable eMMC (CONFIG_MMC_SUNXI_SLOT_EXTRA)
<plaes>
btw, when using UUIDs (the standard ones for root / boot), things fail spectacularily when using these on both sdcard and emmc :P
<apritzel>
plaes: I wouldn't say "fail spectacularily", it's just that only one of them is used
Danct12 has joined #linux-sunxi
<apritzel>
karlp: gediz0x539: happy to hear about your use cases, so we can work out something that works for everyone and is sustainable
<jelly>
libv, there's a good number of people on libera, maybe it would be a good idea to register the channel there just to put a link to OFTC in the topic?
<apritzel>
I think $mmc_bootdev covers already many cases, it just should be used better
<gediz0x539>
apritzel: thank you for your time. please let me know if there's something I can do, or test something. i'd be more than happy to help.
<libv>
jelly: i could, when i take turl and mnemoc in tow, and by filling in the form on the libera site
<libv>
or the form that should be poured into email
<libv>
but i hoped to avoid that
<libv>
jelly: you can play your own part though, by no longer being there ;)
prefixcactus has joined #linux-sunxi
<karlp>
apritzel: I mean, I don't really think I'm doing anything special, I just want a basic, "manufacturing can flash the same image to emmc on all devices, users can still optionally use an sdcard without surprises" and these back and forth threads seem like this is not something that happens by default, and something that has to be done carefully...
<apritzel>
karlp: did this work for you with 2021.04? And does this still work with the "Bring back SD card" patch?
<karlp>
I'm actualyl not there yet, like I said, this is in my (rapidly approaching) future,
<karlp>
but the threads and the back and forth are giving me concern that this is "something I have ot worry about" instead of "things will all be ok" :)
<apritzel>
my goal is to have *one* image, that can be flashed to SD card, eMMC boot partition, eMMC data partition and SPI flash, and does the right thing(TM)
<karlp>
currently I hav emore pressing concerns, like ethernet only coming up as 10Meg :)
<apritzel>
karlp: on which board/SoC?
<karlp>
h3, but custom board, so... probbbbably just insufficient care on routing,
<karlp>
possssibly also just an assembly problem.
<karlp>
it's only 100M, so yolo should have been pretty much fine
<apritzel>
karlp: does it work at 100MBit in Linux?
<karlp>
no, 10M in linux
<karlp>
have had a faiyl unscientific plug fest with a gig switch, and a 100M switch, and straight to my laptop, but no clear easy answer yet. it's ok, will hopefully muddle along on it.
<jernej>
warpme_: so, does g31 work or not for you?
_whitelogger has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<apritzel>
jernej: so your H616 HDMI github patches are marked as WIP, are there any showstoppers in there or nasty parts to be solved?
<jernej>
apritzel: yes, there are
<jernej>
4k@60 doesn't work
<jernej>
YUV scaling doesn't work
<jernej>
and DE 3.3 is slightly more generic than DE 3.0 (H6), like planes can be assigned to any output
<jernej>
this part (to select which plane is where) is hackish (hardcoded in one place)
<apritzel>
jernej: I see, many thanks for the summary
<jernej>
4k@60 issue is probably somewhere in clock driver, quick check showed wrong clock, but it might be something else too
<jernej>
*wrong clock rate
tnovotny has quit []
choozy has joined #linux-sunxi
pentabarf has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 480 seconds]
lvrp16 has joined #linux-sunxi
jkm has joined #linux-sunxi
jkm has quit []
jkm has joined #linux-sunxi
<pnill>
apritzel: found it interesting to see you guys moved to OFTC instead of libera lol.
<jernej>
why not? plenty linux dev related channels moved here
<pnill>
Idk, I'd never heard of OFTC before this.
<pnill>
and "Libera" seemed to basically be Freenode in spirit.
<pnill>
Tbh, prior to jumping into linux-sunxi for the first time... I'd long assumed IRC was kind of just dead and mostly idlers as I hadn't been on it since 2008.
<Asara>
i feel like most of the linux specific communities are on oftc
<libv>
and whatever choice was made, would've been wrong for some people
vagrantc has joined #linux-sunxi
pentabarf has quit [Ping timeout: 480 seconds]
choozy has quit [Ping timeout: 480 seconds]
megi has quit [Quit: WeeChat 3.1]
megi has joined #linux-sunxi
arnd has joined #linux-sunxi
choozy has joined #linux-sunxi
ats has quit [Ping timeout: 480 seconds]
hanetzer has joined #linux-sunxi
ats has joined #linux-sunxi
cmeerw has quit [Read error: Connection reset by peer]
cmeerw has joined #linux-sunxi
<libv>
hrm, still lots of people on freenode who are here already
<libv>
come on, it's +m, there's no point
<vagrantc>
i get the impression people basically need to hang out there to prevent it from being coopted by freenode's new management
<libv>
wrt #linux-sunxi?
<anarsoul>
libv: probably they just set up bouncer some time ago and forgot about it
<libv>
yeah, but that's not the people who are in here already
<libv>
i'm not magically going to revive the freenode channel when everyones left
<libv>
and then sit there on my own all gleeful on having the channel to myself
<libv>
i
<vagrantc>
i hear you ... it's a bizarre situation