Daanct12 has quit [Read error: Connection reset by peer]
cch has joined #linux-sunxi
<macromorgan>
yes, I'll try that
<macromorgan>
apparently Anbernic just launched a 6th H700 based device, so I get to figure out all over again how to add it to U-Boot for runtime detection...
<Jookia>
if i can't find this bug by the end of the month i'm just going to recommend disabling the sunxi kernel video code and using simple-framebuffer :(
<Jookia>
i guess i could use the sunxi kernel
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
hramrach has quit [Ping timeout: 480 seconds]
hramrach has joined #linux-sunxi
flyback has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
warpme has quit []
flyback 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
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 quit []
warpme has joined #linux-sunxi
warpme has quit []
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
<kjn260>
I would love if anyone has any idea why I cannot reach getty on a R40 board bring-up. Or how I might diagnose:
<apritzel>
kjn260: your root device seems wrong, try root=/dev/mmcblk1p1
<apritzel>
the kernel's mmc block device enumeration is not deterministic (and that's not a bug)
<apritzel>
you either specify the root device by something more robust than the mmc block device number (uuid or label, using an initrd), or ...
<apritzel>
you drop loading the DTB from your extlinux.conf, and just use $fdtcontroladdr, which points to U-Boot's DTB copy
<apritzel>
that one forces an order to the MMC devices, more as a side effect.
<apritzel>
but using a single DTB, already provided by the firmware, is the smarter way of doing things anyway, so it's a win-win ;-)
<karlp>
yes, it's a feature ;)
<karlp>
if it's not deterministic, and that it's a feature not a bug, perhaps you should suggest the recommended alternatives rather than just "try blk1 instead of blk0" ?
* karlp
grumbles a bit.
<kjn260>
you drop loading the DTB from your extlinux.conf, and just use $fdtcontroladdr, which points to U-Boot's DTB copy
<kjn260>
this seems like the most robust method
<kjn260>
let me try some things
<apritzel>
karlp: well, I did, didn't I? root=label=, root-uuid= (the official Linux solutions), or the somewhat cheeky workaround to use U-Boot's DTB. *try* ... was just for a quick check to confirm that's the problem
<apritzel>
(as it could be a missing clock or disabled regulator as well)
<apritzel>
kjn260: also, any particular reason you use Jookia's branch? Do you need one of those LCD panels supported in there for your board?
dliviu has quit []
dliviu has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
Daaanct12 has quit [Quit: WeeChat 4.3.2]
<kjn260>
he has a bunch of fixes relating to the use of USB OTG with uboot (so I can flash EMMC using the UMS command)
<kjn260>
however, it would appear that didn't fix my problem
<maggio_>
followed the instructions in u-boot/boar/sunxi/README.sunxi64
<maggio_>
and ran 'make PLAT=sun50i_a64 bl31'
<maggio_>
but I get a "make: Nothing to be done for 'bl31'" error
<maggio_>
seems to be that thing with make where the target, in this case bl31, coincides with a file or directory name
<maggio_>
apritzel: suggestions for any workarounds
dsimic is now known as Guest10963
dsimic has joined #linux-sunxi
<maggio_>
?
Guest10963 has quit [Ping timeout: 480 seconds]
ndufresne has joined #linux-sunxi
<apritzel>
maggio_: mmh, that's odd, works for me here. Have you done a "make clean" before? Please note that you need to do "make PLAT=sun50i_a64 clean", otherwise you will clean the default "fvp" platform only.
<Jookia>
apritzel: i'm possibly going to take a patch from kjn260 in to my branch that may not get sent upstream to fix usb on their board, so my fork may end up being an actual fork
<apritzel>
maggio_: another workaround is to either drop the make target at all or use "all"
<Jookia>
i also need to add some patches for my specific board that have no way of working in u-boot :(
<Jookia>
probably the same with the kernle
<Jookia>
kernel*
<apritzel>
Jookia: "may not get sent upstream to fix usb" > why is that?
<Jookia>
apritzel: because the author may not figure out how to do it
<apritzel>
sending a patch, you mean?
<Jookia>
yeah
<apritzel>
you can send it, keep him as the author, just add your Signed-off-by:
<apritzel>
or make it your patch, even
<Jookia>
it's a fix for an existing patch set on the u-boot mailing list that is broken and old and requires a dt change in the kernel probably
<apritzel>
oh, is that the phy link thing?
<Jookia>
yes
<Jookia>
i don't have the hardware to test it, so i'm not sending the patch upstream
<apritzel>
I added the phy link to the DT a few years back, because it fixed host support on port 0. The kernel has indeed issues when running this in OTG mode, but the DT as of now is most surely correct
<Jookia>
yeah, i'm not able to debate this patch
<Jookia>
just carry it for a little bit as someone is using my fork and wants it
Schimsalabim has quit [Ping timeout: 480 seconds]
<Jookia>
so you might end up seeing people using the t113 using my fork in the wild like that
Schimsalabim has joined #linux-sunxi
<apritzel>
that ... sounds like not a good reason, honestly. Something "works for me" does not mean it's the right solution. At least it should have a discussion on the list
<Jookia>
not sure what to say
<Jookia>
i'm going to have to add some #ifdef bodges to my tree too :\
<Jookia>
same for linux i think
<apritzel>
now I am not sure what to say ... ;-)
karlp has left #linux-sunxi [$job has moved in other directions, time for less distractions...]
<Jookia>
AFAIK u-boot and linux don't have an infrastructure for specifying the RGB bit depth in the device tree
<Jookia>
so i have to hardcod eit
<apritzel>
> "AFAIK": have you asked this question on the list?
<Jookia>
no, the list generally gets no replies
<apritzel>
even when adding the right people?
maggio_ has quit [Remote host closed the connection]
<Jookia>
i don't know who the right people are
<Jookia>
and searching the list is basically impossible so i don't want to bother people about obvious already asked questions
<apritzel>
scripts/get_maintainers.pl
<Jookia>
i have sent messages to lkml cc'ing actual maintainers reporting bugs and gotten no response
<Jookia>
right now the solution is to use a board-specific patch which is probably going to turn in to an ifdef for my sanity
<apritzel>
well, sorry to say, but #ifdef'ing the kernel is as wrong as it can be, so I would strongly encourage you to post this question on the list
<Jookia>
the lcd issue i'm having is on the list somewhere and i can't find it because searching gives so much nonsense
<apritzel>
with lore? have you tried "quotation marks" around the words that appear together?
<Jookia>
i dont know what words appear together
warpme has joined #linux-sunxi
<apritzel>
well, if even a Google search doesn't turn up something, then it's absolutely fine to post a question on the list
<Jookia>
:\
<Jookia>
the dilema is basically i don't have the energy to mainline AND ship code
<Jookia>
so i'm going to pick shipping code for now
<apritzel>
bummer
warpme has quit []
<Jookia>
if/when the process gets easier i'll be able to dedicate more time to it i think
<Jookia>
maybe if they start using github or something nice
<apritzel>
I don't think that's the problem, tbh
<apritzel>
Your work areas seem to be somewhat niche, to some degree (specific panels on wimpy Allwinner SoCs, for instance). There are simply not that many people out there involved in OpenSource projects that have knowledge on these
maggio_ has joined #linux-sunxi
<Jookia>
the LCD bug affects all LCDs independent of panels on the D1/T113 and possibly R40
<Jookia>
and possibly things like HDMI
<Jookia>
the DE is effectively unusable atm
<Jookia>
i guess it is niche but like, i dunno
maggio_ has quit [Remote host closed the connection]
<apritzel>
there should be LCD users on D1's out there that have seen the issue?
<Jookia>
yes, there are
<Jookia>
multiple
<Jookia>
i know of 3 cases not including myself
maggio_ has joined #linux-sunxi
<maggio_>
apritzel: 'make PLAT=sun50i_a64' only builds libfdt.a and libc.a. Same with 'make PLAT=sun50i_a64 all'
<maggio_>
no bl31.bin
<apritzel>
Jookia: is that a regression? Have you reported it on the list?
<Jookia>
apritzel: it's been reported on the list. i can't find it. i don't know if its a regression, most likely it's always been broken
<Jookia>
the bug is over a year old
<Jookia>
initializing the DE+LCD in u-boot and having the kernel use that is an acceptable workaround for my project
<macromorgan>
orange pi zero 2 is using RSB not i2c as best I can tell, at least per the device tree
<macromorgan>
but the defconfig shows it's using i2c... weird
<apritzel>
macromorgan: the AXP305 used on the OPi Zero2 can do both, I believe all RSB PMICs also speak I2C
<apritzel>
we already have I2C code in the SPL, so we are using this for the initial PMIC setup there
<macromorgan>
right... I'm wondering if it's the devicetree specific stuff in A-TF causing the issue? except that can't be because the first i2c failure is before A-TF loads
<macromorgan>
given I'm not getting acks, I wonder if the issue is that the parent clocks might not be set up right?
<apritzel>
macromorgan: does that appear on cold boots, so basically just the SPL code running, right after reset
<macromorgan>
cold or warm... plus in U-Boot proper
<apritzel>
are you using the right I2C address? the datasheets often state them differently (shifted by 1)
<buZz>
i2c-scanner tools are useful ;)
<apritzel>
to make this clear: using just I2C works perfectly fine on the OPi Zero3, and IIUC it worked already with the AXP717 a while back, for tokyovigilante IIRC
<apritzel>
he needed to adjust the address, though, but that should be corrected in this tree already (and in the patches I pushed to sunxi/master)
<apritzel>
maggio_: does manually removing the build directory help? rm -Rf build/sun50i_a64
<maggio_>
apritzel: nope
maggio_ has quit [Remote host closed the connection]
macromorgan has joined #linux-sunxi
<macromorgan>
sorry, putting a new hard drive in my server (which is also my IRC bouncer)
aggi has joined #linux-sunxi
aggi_ has quit [Remote host closed the connection]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<Jookia>
i've read the datasheets and sunxi kernel code and i think i have a plausible explanation for what's happening
<Jookia>
it looks like assining two tcons to the same DE is broken, at least on this chip. the sunxi code mitigates this by swapping the tcons before setting one and starting with DE1 set to TV1
<Jookia>
i've sent a patch off to get tested, should hear back in around 9 hours
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<kjn260>
apritzel: sorry, had to go afk. the paste shows the whole log.
<tokyovigilante>
macromorgan: when you're back, is there anything I can do for USB host support?
<apritzel>
kjn260: so it seems like the eMMC is not happy: [ 1.653586] sunxi-mmc 1c11000.mmc: data error, sending stop command
<tokyovigilante>
Jookia: nice! will give it a roll. Still haven't managed to get display out on my board, but will keep working on it
<macromorgan>
the USB charger driver needs to be hooked up to the USB port (easy), but the driver itself needs to interact somehow correctly to turn on the boost regulator
<tokyovigilante>
ok, thanks
<tokyovigilante>
will have a spelunk into it if I get a chance
<apritzel>
kjn260: maybe the eMMC chip on this board doesn't like the DDR50 mode, I think we have seen this before
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
kjn260: maybe play around with: max-frequency = <xxx>; in the mmc2 DT node, to see if you can force a different speed mode
<apritzel>
Jookia: ah, the old sunxi ML, that explains something ...
<Jookia>
you've been CC'd to that thread i think
<Jookia>
i don't have permissions to post in it :\
<Jookia>
it would be nice to get them to test my latest patch narrowing down the tcon issue
<apritzel>
I even replied originally, but it diverted pretty quickly out of my comfort zone ...
<Jookia>
ugh i can't even get their emails to send a new one on the new list to
<apritzel>
the old sunxi list is not read by many mainline people, so you would need mripard and wens plus dri-devel for knowledgeable mainline audience
<apritzel>
Jookia: whose emails do you need? I can bounce some mails to you ...
<Jookia>
apritzel: can you DM me the addresses of you, Jakob L, K James, then i'll do a kernel mail including them and dri-devel and sunxi
<apritzel>
was just about to do that ;-)
<Jookia>
thank you! i'll get on this later after i get feedback from a tester