rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 246 seconds]
specing_ is now known as specing
vagrantc has quit [Ping timeout: 240 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
qschulz has quit [Remote host closed the connection]
qschulz has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstein has quit [Ping timeout: 240 seconds]
jstefanop has quit [Ping timeout: 252 seconds]
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
ganbold has quit [Ping timeout: 260 seconds]
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
jstefanop has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
victhor has quit [Ping timeout: 240 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
buzzmarshall has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: Ping timeout: 999,999,999 years]
vagrantc has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
\\Mr_C\\ has joined #linux-sunxi
jstein has joined #linux-sunxi
reinforce has joined #linux-sunxi
<mripard> smaeul: yeah, I don't really know what's up with the clk maintainers, I'm struggling to get patches reviewed too
<mripard> I still think this is the best solution, so just keep pinging them?
gsz has joined #linux-sunxi
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
fourkbomb has quit [*.net *.split]
camus has joined #linux-sunxi
jbrown has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
matthias_bgg has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
fourkbomb has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
apritzel has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
<mru> are you being clock-blocked?
victhor has joined #linux-sunxi
<warpme_> guys: i'm trying to get 5.12 mainline boot on TanixTX6s (h616). Distro i'm using works ok with OrangePIZero2 so ATF should be ok. I started with uboot (current sunxi custodians repo) + patch like this: https://pastebin.com/8uXaMnwT This gives me uart output like this: https://pastebin.com/aTxAa9f6 It looks like uboot looking on mmc0 while this tvbox seems to have sd card as mmc1. maybe somebody has some ideas
<warpme_> here?
<apritzel> warpme_: SD card as mmc1? are you sure? How do you boot?
<buZz> maybe its got internal mmc aswell?
<apritzel> warpme_: and you will have only limited fun with 5.12, I'd suggest https://github.com/apritzel/linux/commits/h616-v6-WIP
<apritzel> buZz: sure it has (eMMC on MMC2, probably), but this boots the Android
<buZz> doesnt fex/dtb decide which mmc is which device? could just swap it
<apritzel> buZz: please don't mention fex ever again ;-)
<apritzel> last time I checked U-Boot had the hardcoded assumption of mmc0 being the SD card (in the SPL code, for instance)
<apritzel> yes, normally this is covered by the DT, and is no problem for fully compliant software, like the kernel or U-Boot proper
<buZz> ah
<buZz> apritzel: :D :D
<apritzel> warpme_: do they put the WiFi on mmc0 instead?
<apritzel> warpme_: I guess you are booting via FEL then?
<apritzel> warpme_: also to preempt libv: please add a Wiki page for that, especially if the TX6s is a special snowflake with its SD card
<apritzel> warpme_: and do you have a 1GB DRAM version? Or is the DRAM special and we detect only half of it?
indy has quit [Ping timeout: 260 seconds]
<warpme_> apritzel: i suspect sd card is on mmc1 as to get uboot spl i need to set CONFIG_MMC1_CD_PIN="PF6" in defconfig. with CONFIG_MMC0_CD_PIN="PF6" there is no spl at all. with CONFIG_MMC1_CD_PIN="PF6" uboot tells me https://pastebin.com/aTxAa9f6 re: RAM - boc has 2G ram so it looks uboot detects wrongly only 1G.. re: your branch for h616 - i already using code from it to get nicelly working OPIzero2
<warpme_> boc->box
<warpme_> re tanixTX6s and wifi on mmc0 question: here is android boot log: https://pastebin.com/dzLyYW0U
uis has quit [Quit: ZNC 1.7.5 - https://znc.in]
uis has joined #linux-sunxi
andy25225 has joined #linux-sunxi
<warpme_> re how i'm booting: it is uboot (sunxi custodians) build with ATF included and then flashed to SD card. FAT partitiojn on SD card also has boot.scr for loading DTB & kernel. boot.scr is like this: https://github.com/warpme/minimyth2/blob/master/script/bootloaders/board-h616.orangepi_lite2/files/h616-boot.txt (not small logic here is for: allowing to auto-recognize boots with or without initramfs; also allows to
<warpme_> customize with precedence for user-supplied DTB if hw requires it)
<apritzel> warpme_: so if you boot from SD card, then SD card is on MMC0
<apritzel> maybe the CD pin is not PF6?
sunilmohan has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
<apritzel> so with MMC0_CD_PIN is looks at PF6, and sees "no card"? But MMC1_CD_PIN would get ignored, and the missing MMC0_CD_PIN let's U-Boot assume non-removable?
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
<warpme_> apritzel: well. idk as i don't have any schematics. i was guessing it is on mmc1 as simple change in CONFIG_MMC1_CD_PIN from MMC0 to MMC1 allows uboot move forward.... but for sure it is just guessing -(
specing_ is now known as specing
jbrown has joined #linux-sunxi
indy has joined #linux-sunxi
fl__0 has joined #linux-sunxi
fl_0 has quit [Ping timeout: 276 seconds]
<warpme_> apritzel: i don't checked uboot code - but if your statement "MMC1_CD_PIN would get ignored" comes from uboot code - then indeed hypothesis that sd card is on mmc0 + setting CD pin to mmc1 in reality ignores CD pin on mmc0 -> causes uboot assumes sd card is non-removable mmc0 start to make sense. Maybe simple test with: defconfig CONFIG_MMC0_CD_PIN entry removed will help us to move forward?
choozy has joined #linux-sunxi
<warpme_> apritzel: indeed. commenting MMC0_CD_PIN gives the same result like using MMC1_CD_PIN so sd card seems to be on mmc0 + this box as CD uses different than PF6 pin.
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
jstefanop has joined #linux-sunxi
<apritzel> warpme_: great! You can just use CONFIG_MMC0_CD_PIN="" in your defconfig then
<apritzel> warpme_: and does the box have 3 USB ports? The pictures I found online suggest so
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
Net147 has quit [Ping timeout: 268 seconds]
cnxsoft has quit [Quit: cnxsoft]
<warpme_> apritzel: yes. it has 3 ports: 1x blue (3.0 i think) + 2x white (2.0 i suppose)
<apritzel> there is no USB 3.0 controller in the H616
<apritzel> but selling it as USB 3.0 doesn't seem to be uncommon ;-)
<warpme_> ah ok - so it looks like box producer had just such component (or this another famous Chinese marketing spin :-) )
<apritzel> (probaby because the H6 had it, and people just copy&pasted everything from their previous TV box models)
<warpme_> :-)
<apritzel> for instance the Tanix TX6 (without the "s")
elros1 has joined #linux-sunxi
<warpme_> h616 is really nice mediaplayer soc imho
<apritzel> I don't know about that, but it seems to be cheap
<warpme_> exactly. OrangePIzero2 is 17Eur board with periph. exactly enough for mediaplayer. so for price-functionality it is killler
<warpme_> so sad it hasn't yet foss traction it deserves....
Net147 has joined #linux-sunxi
gaston1980 has quit [Ping timeout: 240 seconds]
<warpme_> apritzel: infact your+jernej code runs really nice on h616. HDMI, USB, Eth working well. To get multimedia player on OPIzero2 missing are: GPU/Audio/VideoDEC.
<warpme_> CEC as well :-)
<warpme_> i mean CEC works nicelly as well
<apritzel> well, that doesn't look too bad, does it? we got our hands on boards only end of last year, so that's pretty fast, I'd say
reinforce has quit [Quit: Leaving.]
Net147 has quit [Ping timeout: 268 seconds]
<warpme_> yeah. it look really good!
<jernej> warpme_: VI planes still don't work with my WIP patches, so you would need GPU rendering
<warpme_> gpu is g31 - well supported by panfrost. probably some entries in DT and it will pop-up. I don't know about DE3.3 - as iirc jernej mentined no yuv support (iirc).
<jernej> warpme_: regarding sd card issue - you could try adding "broken-cd;" to mmc0 node just to see if it helps
<apritzel> jernej: broken-cd is ignored by U-Boot proper ;-)
<jernej> ah, ok
<apritzel> but just not specifying a CD GPIO should fix that
<jernej> I have tx6s android dt, let me check what it says regarding cd pin
<warpme_> jernej: saying "need GPU rendering" - do you mean DMABUF in EGL mode?
<jernej> I don't have specific method in mind, whatever works with GPU
<jernej> apritzel, warpme_: it seems CD pin on TX6s is PI10
<warpme_> h6 t720 in DMABUF in EGL mode works really well for me. comparing cpu load on gs1: DRM planes is 5-10% load while EGL is 15-25%. not bad - giving that EGL mode gives me deinterlacing by GPU.
yann has quit [Ping timeout: 252 seconds]
Net147 has joined #linux-sunxi
<warpme_> jernej: qll. let me try with PI10
<warpme_> jernej: in DT i have: cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; how this should be changed?
<jernej> <&pio 8 10 ...
<warpme_> PI10 - is it papa leon 10?
<warpme_> it seems Papa India 10
<libv> lima. the now too overweight glider pilot in me remembers that L is lima.
<warpme_> :-)
<libv> for completeness sake, original name was remali, but arm complained about possible trademark violations
<karlp> hrm, I thought I remembered leon in one of the older regional ones, but no, there was "liverpool" and "love" and "luis" and "lewis" though...
<libv> and one of the other codethink employees suggested lima
<libv> i do not remember who though
<jernej> apritzel: speaking of CD pin, T95 also seems to use PI10 pin for it
gaston1980 has joined #linux-sunxi
<jernej> so X96 and T95 are thus not totally compatible
<apritzel> and I thought we were past non-standard CD pins ...
<apritzel> because PF6 cries "use me for CD!!!" all over the place
<jernej> well, it's just a pin, nobody said it must be one or another
<apritzel> sure, bu just because you *can* doesn't mean you must deviate
<apritzel> that's not really well understood in the ARM world, though
<jernej> and that's why DT was born :)
fl__0 has quit [Ping timeout: 245 seconds]
<jernej> well, used
<warpme_> apritzel: totally agree. it should be rule of thumb: deviate only if you must!
<apritzel> jernej: we have: "default "PF6" if MACH_SUN8I_A83T || MACH_SUNXI_H3_H5 || MACH_SUN50I" in U-Boot
fl_0 has joined #linux-sunxi
<warpme_> hmm - with PI10 in def config + &pio 8 10 in DT i'm getting:
<warpme_> it is the same error like with CONFIG_MMC0_CD_PIN="PF6" in defconfig...
<warpme_> patch for tx6s applied on custodians uboot: https://pastebin.com/qfLWWpKC
<apritzel> warpme_: do you get to the U-Boot prompt (in any config)?
<apritzel> then you could try "gpio input pi10"
<warpme_> it looks like yes but i have (currently) inly tx soldered
<warpme_> for sure i can add rx
<apritzel> repeating that with a card inserted and not should give you a hint whether this is the right GPIO
<jernej> apritzel: slightly unrelated: I think this line has a bug: https://elixir.bootlin.com/u-boot/latest/source/drivers/gpio/sunxi_gpio.c#L107
<jernej> apritzel: shouldn't it be: group = *name - (*name >= 'a' ? 'a' : 'A'); ?
<apritzel> looks like on the first glance, yes
<warpme_> apritzel: if i remove sd card - then box boots with android
<jernej> and sunxi_name_to_gpio_bank() too
<apritzel> warpme_: I mean boot with your SD card, then type this command on the U-Boot prompt, then remove the SD card and repeat the command
<warpme_> ah ok i see. indeed this is logical :-)
<apritzel> warpme_: and there are slightly hackish ways to scan whole banks of GPIOs at once
<warpme_> let me try this. i need to run now. i'll be back at around 9PM
cmeerw has joined #linux-sunxi
<jernej> warpme_: you do realize, that not all people here are in same timezone as you? :)
<warpme_> yes :-)
vagrantc has joined #linux-sunxi
<warpme_> last q before my playings with gpio querings: what namespace i need to use? (PF0..PF?; PI0..PI? or?)
<apritzel> the code that jernej linked to tells you ;-)
sunshavi has quit [Ping timeout: 240 seconds]
matthias_bgg has quit [Quit: Leaving]
Mangy_Dog has quit [Remote host closed the connection]
prefixcactus has quit [Ping timeout: 240 seconds]
Mangy_Dog has joined #linux-sunxi
ganbold has quit [Read error: Connection reset by peer]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
<tuxd3v> On nanopi neo Air, its impossible to boot correctly
<tuxd3v> because on boot up
<tuxd3v> sometimes your card is mmcblk1, sometimes in mmcblk2
<tuxd3v> /etc/fstab has fixed values
<tuxd3v> can I force uboot mmc0, to become mmcblk1 or mmcblk2, but fixed between reboots?
<plaes> tuxd3v: you could use partition names or uuid's in fstab
<KotCzarny> partition names requires use of ramdisk
<KotCzarny> ls -l /dev/disk/ anyway for options
<Jin^eLD> can't part-names be specified on kernel command line and be passed by u-boot via bootargs?
<Jin^eLD> a u-boot script could surely handle that
<tuxd3v> I don't believe uboot can handle the name the kernel atributes to its disks..
<tuxd3v> maybe via device-tree.. but I don't know how to do that..
<Jin^eLD> tuxd3v: no, no, u-boot knows your device, i.e. the one you will be booting from
<Jin^eLD> and then no matter which one it figured out, you give a fixed name like, "rootfs" for your user space
jstefano_ has joined #linux-sunxi
jstefanop has quit [Ping timeout: 246 seconds]
<Jin^eLD> basically my thought was, you set tha bootargs via u-boot to root=/dev/mmcblkXpY:part-name=rootfs
<tuxd3v> yes uboot knows, and its pass the partuuid to kernel args, and then lated sometimes the kernel decide that disk 1, is now disk 2 or vice versa..
<Jin^eLD> and you construct the /dev/mmcblk stuff by a u-boot script since you have to know where you are booting from, and fstab just uses the part-name
<Jin^eLD> since the part name remains fixed regardless of what device you picked for booting
<tuxd3v> I wanted to fix the devices
<tuxd3v> like uboot mmc0 is mmcblk1
<tuxd3v> fixed names, that could be possible via device t5ree
<tuxd3v> tree*
<tuxd3v> ofcourse I can use PARTUUID in /etc/fstab
<Jin^eLD> I was told it should be possible via device trees indeed, but that's where my knowledge ends :P
<tuxd3v> plaes, mentioned a workaround
<tuxd3v> but I liked to have a solution :)
<tuxd3v> plaes, many thanks for remembering me of that :)
<DuClare> I don't know if anyone ever committed a patch similar to this https://lore.kernel.org/patchwork/patch/674379/
<DuClare> But that kinda does what you want
<DuClare> If you want to name mmcblks via dt
<DuClare> Knowing linux it probably got never committed so have fun rebasing the patch on every kernel :P
<tuxd3v> DuClare, many thanks,that seems to be the solution
<tuxd3v> What I don't understand is why nobody commits that to mainline
<tuxd3v> it should be there for a decade already
<DuClare> It's an ideology thing
<DuClare> As is common with linux, the people who call the shots want you to do the complex thing
<DuClare> i.e. use initramfs and fumble around in userspace to figure out what is sd card slot number 2
<plaes> device tree is ABI :(
<DuClare> You're not supposed to use DT to describe which slot is number two because dt is supposed to be used for describing hardware and ...
<DuClare> You get the point
<DuClare> Can't do the simple thing
<DuClare> (There are some technical arguments to be made but imo they don't hold up that well)
jstefanop has joined #linux-sunxi
elros1 has quit [Remote host closed the connection]
<apritzel> mmc aliases have been merged recently
<apritzel> there is even a proposed patch to put them into the .dtsi files
<DuClare> Really? If so, I'm very happy and positively surprised
jstefano_ has quit [Ping timeout: 240 seconds]
<apritzel> seems like Rockchip got aliases into all their board .dts files
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
Esmil has left #linux-sunxi [#linux-sunxi]
camus has joined #linux-sunxi
sunshavi has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
megi has quit [Quit: WeeChat 3.1]
megi has joined #linux-sunxi
uis has quit [Quit: ZNC 1.7.5 - https://znc.in]
uis has joined #linux-sunxi
diego71 has quit [Ping timeout: 252 seconds]
akaWolf has quit [Ping timeout: 240 seconds]
cmeerw has quit [Ping timeout: 245 seconds]
gsz has quit [Ping timeout: 252 seconds]
akaWolf has joined #linux-sunxi
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
hlauer has quit [Ping timeout: 240 seconds]
buzzmarshall has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-sunxi
apritzel has quit [Ping timeout: 268 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi