<wens>
looks like behavior of lamobo r1 switch will change in 5.3, due to commit 75dad2520fc3 ("net: dsa: b53: Disable all ports on setup")
<wens>
be warned if you are running a setup like mine, where you just bring up eth0
<suprothunderbolt>
I've now made some progres...
<suprothunderbolt>
i'm getting EGL_BAD_ALLOC
<suprothunderbolt>
with mali
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 245 seconds]
<MoeIcenowy>
jernej: the EPHY problem seems complex
<MoeIcenowy>
you need to activate it via AC200 I2C
NeuroScr has quit [Quit: NeuroScr]
<MoeIcenowy>
but then the EPHY is just probed and controlled via MDIO
<wens>
jernej: the PHY is not detected or not registered with the driver you want?
dddddd has quit [Remote host closed the connection]
<jernej>
wens: it's not detected
<wens>
mdio muxing maybe? the mfd bits seem to be ok
<suprothunderbolt>
anyone got mainline mali working? I feel like I'm getting close, If i don't call fbset -match it segfaults
<suprothunderbolt>
of I do it now gets eglCreateWindowSurface failed: 0x3003
<suprothunderbolt>
if I do it now gets eglCreateWindowSurface failed: 0x3003
JohnDoe_71Rus has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 246 seconds]
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 250 seconds]
<KotCzarny>
maybe it doesnt like your panel's resolution
tl_lim has quit [Ping timeout: 276 seconds]
tl_lim has joined #linux-sunxi
reinforce has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
<suprothunderbolt>
i think that might be it, it's 720p
<KotCzarny>
looks standard one
<KotCzarny>
i was thinking about some weird res panels, as in 2048x1536 or 800x480
<KotCzarny>
but doesnt hurt to check other resolutions, simple and maybe error will change
<superprower>
Hello! Some time ago it was said that sun6i-rtc driver doesn't have alarm/wakeup support because there is "no suspend support yet, so there's no code to deal with the wakeup and resume either". Can anyone tell me more about this? Where can I read which components in general exactly need suspend support implemented in them and how? A64 documentation clearly says that RTC supports wakeup function, and there are many different
<superprower>
chips, so what _exactly_ could be lacking? Thanks.
<KotCzarny>
basically whole suspend isnt implemented? so there's nothing to wake
<KotCzarny>
but who knows, maybe it can wake from power off?
<KotCzarny>
have you tried setting alarm and doing software poweroff?
<superprower>
I'm unfortunately not so much familiar with kernel as to know what is "whole suspend". That's kinda why I asked, so I could learn a bit more about what "whole" is composed of. I mean, Pine64 is planning to release A64-based PinePhone next month iirc, how would it work without suspend?
<KotCzarny>
:)
<KotCzarny>
my thinkpad x40 works 24/7
<superprower>
Alarm Timer initialization functions doesn't succeed because sun6i-rtc device doesn't set some fields and thus device_may_wakeup fails. I doubt that I could set an alarm (CLOCK_XXX_ALARM clockid's don't work because of that).
<KotCzarny>
you may try playing directly with registers
<KotCzarny>
just to check if it works
<wens>
KotCzarny: it can't wake from power off if the SoC isn't being supplied power *wink*
<KotCzarny>
wens, well, i was hoping rtc steals some power via separate pin, even if soc is 'off' ;)
<KotCzarny>
otherwise, it will be a sucky rtc design
<KotCzarny>
i suspect it relies on rtc battery connected
<wens>
it does, but again, it has no way to trigger anything else
<superprower>
Shouldn't be an issue, I can see a small clock battery on my device
<KotCzarny>
wens, no connection to axp?
<wens>
nope
<KotCzarny>
bummer
<wens>
the only connections are the i2c bus and the irq pin
<KotCzarny>
sucky design then
<wens>
the irq pin can be reversed to trigger the axp to come on
<wens>
but then you'd need something to do that, which the rtc by itself can't
<KotCzarny>
at that point you might as well use arisc
<wens>
which is why you need the openrisc core
<wens>
yeah
<KotCzarny>
and ignore rtc altogether
<KotCzarny>
but then again, if soc isnt supplied power, arisc is off too, right?
xes__ is now known as xes
<superprower>
ARISC sounds interesting, but I don't see any mentions of on the A64 wiki page or in user manual
<KotCzarny>
superprower: check linux-sunxi's wiki
<superprower>
That's where I'm looking
<KotCzarny>
smaeul started writing firmware
<superprower>
Oh, I see it on ar100 page itself
<superprower>
It's so proprietary it isn't even in user manual, huh?
<wens>
KotCzarny: arisc has a separate power rail
<wens>
KotCzarny: if you are putting the system into suspend, you wouldn't turn off everything
<wens>
KotCzarny: you'd likely keep arisc and dram on
TheSeven has quit [Ping timeout: 252 seconds]
TheSeven has joined #linux-sunxi
<superprower>
What is AXP, by the way?
return0e has joined #linux-sunxi
<wens>
the PMIC
<superprower>
By the way, there is some "crust-firmware". Isn't this enough to use suspend?
<wens>
none of the in-kernel drivers support suspend/resume
<KotCzarny>
wens, yeah, i've been playing with arisc and implemented fake power off with soc turn on on events
return0e has quit [Ping timeout: 244 seconds]
cnxsoft has quit [Quit: cnxsoft]
<KotCzarny>
superprower: arisc isnt proprietiary, most r_* registers relate to it, and it can have different names in manual
<KotCzarny>
allwinner's legacy blob is proprietiary, but most functionality has been reversed already
<KotCzarny>
but that's only one side, as wens have said, linux drivers dont have support/resume functionality
s_frit has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
return0e has joined #linux-sunxi
selfbg has joined #linux-sunxi
warpme_ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
SopaXorzTaker has joined #linux-sunxi
yann has quit [Ping timeout: 272 seconds]
warpme_ has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
AneoX has joined #linux-sunxi
tl_lim has quit [Read error: Connection reset by peer]
selfbg has quit [Quit: selfbg]
yann has joined #linux-sunxi
tnovotny has joined #linux-sunxi
SopaXorzTaker has quit [Remote host closed the connection]
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
warpme_ has joined #linux-sunxi
airwind has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
random_yanek has quit [Ping timeout: 268 seconds]
random_yanek has joined #linux-sunxi
warpme_ has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
megi has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 248 seconds]
SopaXorzTaker has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-sunxi
longsleep_ has joined #linux-sunxi
aliosa27 has quit [*.net *.split]
longsleep has quit [*.net *.split]
jerbob92 has quit [*.net *.split]
arnd has quit [*.net *.split]
steev has quit [*.net *.split]
jeandet has quit [*.net *.split]
aib has quit [*.net *.split]
smaeul has quit [*.net *.split]
lennard has quit [*.net *.split]
Turl has quit [*.net *.split]
random_yanek has quit [Quit: random_yanek]
Turl has joined #linux-sunxi
aliosa27 has joined #linux-sunxi
smaeul has joined #linux-sunxi
arnd has joined #linux-sunxi
aib has joined #linux-sunxi
jeandet has joined #linux-sunxi
lennard has joined #linux-sunxi
jerbob92 has joined #linux-sunxi
steev has joined #linux-sunxi
steev has quit [Ping timeout: 246 seconds]
steev has joined #linux-sunxi
yann has quit [Remote host closed the connection]
dddddd has joined #linux-sunxi
random_yanek has joined #linux-sunxi
bisbarn has joined #linux-sunxi
<bisbarn>
Hey, I'm currently trying to get an olinuxino-a20lime2-emmc up an running, building a simple openembedded image. Its basically a distroless core-image-minimal. However, I'm struggling to get Ethernet working properly. I can only get it to work when setting it up as 10baseT/Half. I tried appending CONF_RTL8211X_PHY_FORCE_MASTER=y to u-boot without luck. I'm also trying the olimex branch of the olimex u-boot fork, which also does not work. I would be
<bisbarn>
really grateful for any kind of suggestion ;)
<cristian_c>
I'd like to know how long usually between a new mainline kernel rs released and its availibility by sunxi
<cristian_c>
Any ideas?
<libv>
explain what you see as "availability by sunxi"
<fALSO>
i saw something in the news about MALI and kernel 5.2
<cristian_c>
I don't know how it's shared between distros
<cristian_c>
i.e. armbian
<fALSO>
was mripard "module" imported into the kernel ?
<cristian_c>
I've just looked at armbian-config
<libv>
cristian_c: only very little from armbian comes back to sunxi
<cristian_c>
and I've found the last next kernel is 5.1 next (not stsble branch)
<libv>
cristian_c: if you wish to know when armbian moves to a new kernel version, go ask the armbian people, they like to be on their own island
<cristian_c>
I wonder ifnthrre is a ne mainline kernel suitable for allwinnr
<cristian_c>
*platform
jernej has joined #linux-sunxi
<cristian_c>
*if there is
<cristian_c>
*a new
<libv>
linux-sunxi was always meant to be distribution neutral, giving people the ability to run an actual linux on a sunxi device, as opposed to android exclusively as that was the world we were in before linux-sunxi was founded
<libv>
some people started selling boards, and duplicated stuff (wiki/community) there, some people started making highly specific debian distributions, duplicating stuff there
<cristian_c>
I understsnd, so every distro compiles mainline sunxi kernel
<libv>
so go ask the armbian guys what they will do next
<libv>
cristian_c: our wiki very clearly guides you to a device page for your specific device
<libv>
it should list what dtb to use
<libv>
and _should_ point you towards how to build and run a kernel
<cristian_c>
(I use mainline kernel for allwinner, btw, currently I use 5.1)
<lsjet>
I just want to say thanks. I have only recently discovered linux-sunxi and it is amazing the amount of work that has been done.
jstefanop has quit []
msevo has quit [Quit: Leaving]
<libv>
heh, armbian is dated 20131224, and was sunxi specific
<libv>
this channel was founded 20120911
<libv>
and the server was set up around the same time
<DonkeyHotei>
and before this channel, much of the discussion was in #arm-netbook
gnarface has quit [Quit: Leaving]
<libv>
yup, that's where it originated indeed
jstefanop has joined #linux-sunxi
<libv>
with tom cubie putting mele a1000s on ebay while working at allwinner
<libv>
before doing a... crowdsupply? to get a few 1000 boards built
<libv>
and then there were two tablet makers who adhered to the gpl
<libv>
whereas almost literally no-one else was even remotely close to adhering to the gpl for their cheap android devices
<libv>
not even most allwinner based vendors
<libv>
but allwinner had such lax control, that two vendors did do the right thing
<karlp>
which two were they?
<libv>
i would have to look it up, it's somewhere in our wiki
<DuClare>
Should the exact same spl binary work whether it's on sdcard or spi?
<MoeIcenowy>
yes
<MoeIcenowy>
SPL can detect where it's booted
<MoeIcenowy>
because BROM will set an flag in SPL header
<MoeIcenowy>
(at least on all ARMv7/8 Allwinner SoCs
<DuClare>
Hmh :(
<mru>
I've never seen a soc where the boot location had to be hard-coded into spl
bisbarn has quit [Ping timeout: 245 seconds]
<DuClare>
Dang, I think brom finds the header and tries to boot
bisbarn has joined #linux-sunxi
<DuClare>
And that's as far as it gets. Now I need to figure out what to short so I can boot sdcard again..
cnxsoft has quit [Quit: cnxsoft]
<DuClare>
*sigh*
jstefanop has quit []
<lsjet>
Just curious: Looking at the linux mainlining chart it shows HDMI Audio as "No" everywhere meaning no one is working on it, right? Is there a big roadblock there, or is it lack of people?
<Mangy_Dog>
just showing the lcd is working... at least on the ada board
<Mangy_Dog>
my ociliscope still not turned up in the post
<hellsenberg>
nice
<Mangy_Dog>
expected tomorrow or thursday
<Mangy_Dog>
ive noticed a couple of differences
<libv>
so you are forcing an edid through the commandline
<Mangy_Dog>
the ada board uses a phyiscailly larger inductor
<libv>
but uboot just uses the edid inside the adafruit module
<Mangy_Dog>
also one of the diodes it uses are also a lot larger than the one im using
<Mangy_Dog>
dont know if its the zenner or schot
<mru>
physical size doesn't necessarily mean much
<hellsenberg>
I don't think resolution issues have to do with diodes and inductors (those are usually for backlight voltage)
<libv>
Mangy_Dog: first step, concentrate on why the display goes out of sync when the kernel is loaded, is there an inconsistency between the edid in the adafruit module and the edid loaded through the commandline?
<Mangy_Dog>
hell my issue is the backlight not the res
<Mangy_Dog>
thats another herdle i need to sort
<jernej>
lsjet: for which SoC? for H3 and newer patches exist and they are getting slowly mainlined
<libv>
you can then reliably boot linux on the adafruit, and start measuring some things out
<Mangy_Dog>
^^^ hell
<libv>
small steps, and change single things only
<Mangy_Dog>
i tell you what though, im indoors and its overcast, but even at 25ma that text was bright
<Mangy_Dog>
but from what i read the board runs at a higher voltage at 25ma?
<libv>
Mangy_Dog: for instance measure the backlight signal with $multimeter, and see if you get a similar reading with your own board
<libv>
my ultracheapo multimeter was showing consistent % voltages while poking at vsync/DE depending on the frequencies of those signals
<hellsenberg>
Mangy_Dog: uneducated guess would say regulation is flaky, or overcurrent is being tripped somewhere on that backlight circuit
<libv>
but fix the kernel hdmi output on the adafruit module first
<libv>
that is a _very_ small searchspace
<libv>
and then move on to the next
<Mangy_Dog>
the thing is libv there are some small changes, such as ive got mine set to dish out 40ma... but also different inductor value, mine matches the datasheets 10uh where the ada board is 15... another guy i know suggested i should be using 25+
<libv>
Mangy_Dog: first, the kernel edid thing, then, start measuring
<Mangy_Dog>
libv i have no idea how to do that right now...
<Mangy_Dog>
so any tips? :D
<libv>
know that your adafruit is reliably displaying with the kernel, before you move on
<Mangy_Dog>
nods
<libv>
did you provide an EDID blob in the commandline?
<Mangy_Dog>
btw my main os is the armbian packed with orangeretropie
<Mangy_Dog>
no
<Mangy_Dog>
my guess is its defaulting to 720p
<libv>
Mangy_Dog: ok, one step back, what happens with a normal hdmi based display on your setup?
<libv>
is there similar behaviour there?
<lsjet>
jernej, Specifically I was curious about the H5. The page seemed to indicate it was an across the board issue so I wasn't more specific.
<Mangy_Dog>
well ive only plugged it into my 1440p monitor it runs at a fixed res i think its 720 but not 100%, in armbian the display res only lists 1 res and cant be changed..
<libv>
a good trivial help for display stuff is to check the info in the display menu and note the resolution and timings, usually you get horizontal and vertical frequencies
<Mangy_Dog>
wheres this menu?
<Mangy_Dog>
that level of stuff isnt in the gui armbian
<libv>
on whatever monitor you use
<libv>
they usually come with a menu system of sorts
<Mangy_Dog>
oh right
<libv>
dig deep enough, and you should get some basic mode timing
<Mangy_Dog>
yeah that said 720
<libv>
and...
<Mangy_Dog>
but thats all it would show
<libv>
did it not mention frequencies?
<Mangy_Dog>
nope
<libv>
get another monitor ;p
<Mangy_Dog>
cant afford one
<Mangy_Dog>
its an old dell 30inch
<libv>
anything dvi based perhaps?
<Mangy_Dog>
its not totally dead yet :p
<Mangy_Dog>
has dvi and hdmi and display port
<Mangy_Dog>
ive tried dvi and hdmi
<libv>
ok
<Mangy_Dog>
the mini lcd however should be happy at 60hz
<libv>
i have had a fun experience with dell when displayport first came out
<libv>
pos.
<Mangy_Dog>
i mean its at the specs to and other projects i did with embedded hardware runs them at 60z
<Mangy_Dog>
yeah display port on dell is funky
<libv>
ok, so start the board on the actual monitor, and halt uboot, and see what the monitor claims to see then
<Mangy_Dog>
im not a big linux user soo i have to ask, is uboot that little startup text i can see on my mini screen before it stoped displaying anything?
<libv>
we were doing radeonhd, and we had early ati hw with the first displayport support
<libv>
rv670/rv635 if memory serves
<Mangy_Dog>
fun
<libv>
and dell had made a lot of noise about being first with a displayport based monitor
<libv>
so we organized budget, and got the novell corporate system to order the monitor at dell
<libv>
delays, delays, delays, for 3 months
<libv>
then bridgman, who was supposed to be in control of documentation, but who played a double game and protected atombios and the ati software ways at all cost, told us:
<libv>
"oh, that dell monitor you guys have on order"
<libv>
"guess who asked us for our validation setup"
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<libv>
i have one dell monitor here, a diamondtron i use until mode switching kills it, to be able to visually see the stability of the dotclock and the timing
<libv>
i spend 40eur on that back in 2006, and that's going to be the only dell product i ever own
<DuClare>
Soo the eGON header for spl must be preceded by 4 bytes, right?
<Mangy_Dog>
libv in uboot on my monitor its running full res 1920 1200 60hz
<libv>
so uboot is probably listening to the edid and taking the preferred mode
<Mangy_Dog>
nods
<Mangy_Dog>
i assumed as much
<libv>
well, go figure out why kms is doing something different
<Mangy_Dog>
now how do i make the rest of teh system listen :D
<libv>
there's a command line argument called...
<libv>
drm.debug=
<libv>
drm.debug=0x1e is what i have lying around in my boot.cmds
<Mangy_Dog>
what does that do?
<Mangy_Dog>
and where do i put it? in terminal once im booted into armbian?
<libv>
read up on uboot, and figure out what boot.cmd is and does
<libv>
our wiki should have plenty of useful info for you
<DuClare>
So eGON.BT0 is preceded by jump address.. for some reason, the first 4-5 bytes do not survive when I write them to spi flash :(
<Mangy_Dog>
but we already asitained that uboot is displaying correctly
<libv>
Mangy_Dog: uboot is what loads the kernel
<libv>
it is also what tells the kernel what command line arguments to use
<libv>
Mangy_Dog: you really should have worked through a manual build if you plan to develop daughterboards
<libv>
that would've showed you the steps involved for uboot and for the kernel
<Mangy_Dog>
i had assumed stuff liek setting display resolusions have been figured out already
<libv>
which is very necessary experience/knowledge for any debugging
<libv>
Mangy_Dog: you mean, like, magically?
<Mangy_Dog>
no like working, like most things
<Mangy_Dog>
this is pretty basic stuff a os should cover on its own
<libv>
ignoring all the complexity and variability that you just introduced?
<Mangy_Dog>
being able to set a resolusion
<Mangy_Dog>
not at all ive not introduced anything complex to the mix, its a dvi/hdmi signal out...
<Mangy_Dog>
its being decoded
<Mangy_Dog>
it has a edid giving infro of what res to default too
<libv>
you did, and it tripped up
<libv>
now you get to debug it
<libv>
if that is too much for you, then don't bother
<libv>
with any of it
<Mangy_Dog>
what ive developed is a daughter board
<Mangy_Dog>
not a linux os
<libv>
well, that pretty much ends any conversation here
<Mangy_Dog>
i have assumed that things like setting a display resolusion had been sorted on the OS level for the last 30 years
<Mangy_Dog>
or have i been wrong?
warpme_ has quit [Quit: warpme_]
<libv>
if you're not willing to debug this, and not willing to read the limited info needed to change kernel arguments, then you have nowhere to go from here, and you might was well just turn back
<[TheBug]>
Mangy_Dog: to be honest, libv is being very kind to you with his time, what he is trying to convey is if you want to continue to have help you need to do your part by RTFM and learning how these things work. We can't do the debug for you and you need to have knowledge of uboot to understand how to troubleshoot it.
<Mangy_Dog>
no i am willing
<Mangy_Dog>
but not even telling me where to start is hardly going to help is it
warpme_ has joined #linux-sunxi
<libv>
Mangy_Dog: you are telling that to the guy who enabled most of the automatic display configuration you have enjoyed for the past 1.5 decade
<Mangy_Dog>
rtfm great.... WHAT MANUAL?
<[TheBug]>
Mangy_Dog: he did, uboot is discussed in detail in the wiki
<libv>
Mangy_Dog: /topic says "did you try looking at our wiki?"
<Mangy_Dog>
which one? what page of the liturally billions of various documents should i read?
<libv>
the one about u-boot?
<[TheBug]>
Mangy_Dog: just gonna warn you before responses in here change -- if you want help in here you need to be willing to do the leg work your self instead of expecting us to just give you a step by step -- you will need to search the wiki and read as well as possibly search google some on any topics your not sure about to try and learn. Once you understand uboot (which is the Bios on AARM
<[TheBug]>
devices) it is much easier to debug things that rely on it
<Mangy_Dog>
thats great but i didnt even come here about this specific issue.. I came here for somthing else... so barking at me saying im doing it all wrong, then tell me to rtfm, without even indicating at all what i should be reading... About a thing im not even developing and had assuming had already been developed...
<[TheBug]>
and now you can handle it your self... warning ignored..
<Mangy_Dog>
Ok so reading the LCD page and not the uboot page, there is a fex file I can set the display settings in... BUt theres no indication as to where this file even is located
<DuClare>
This is so bizarre :<
diego_r has quit [Ping timeout: 258 seconds]
<DuClare>
Ohhhh
<DuClare>
Bytes on my spi flashes are gravitating towards 0 as I write blocks from /dev/random
<DuClare>
I need some special tool to erase mtd?
warpme_ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<gnarface>
maybe a different driver from regular sd
<mru>
DuClare: yes, you need the mtd-utils package
<jernej>
montjoie: MoeIcenowy: In this line, "ret" should be used instead of "1", right?
<jernej>
otherwise comment above doesn't make sense
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 245 seconds]
ganbold has quit [Remote host closed the connection]
warpme_ has quit [Quit: warpme_]
matthias_bgg has quit [Read error: Connection reset by peer]
ganbold has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
warpme_ has joined #linux-sunxi
<MoeIcenowy>
jernej: seems so
matthias_bgg has quit [Ping timeout: 268 seconds]
warpme_ has quit [Quit: warpme_]
<Mangy_Dog>
And thebug, I had assumed uboot was "bios" but i didnt want to call it that as im sure some one here would have taken an issue to that as well
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
megi has quit [Ping timeout: 246 seconds]
Putti has quit [Remote host closed the connection]
<willmore>
DuClare, in case you haven't figured it out yet, flash memory is a 1 when erased and 0 when programmed. If you program it and don't erase it, and then program it again, you'll get the AND of the two values you wrote.
<DuClare>
Yes, I figured that out :)
<DuClare>
I foolishly assumed that writing on flash with dd would imply an erase cycle so you actually end up with the data you wanted
<willmore>
That's a good point, libv. DuClare flash generally requires specific erase commands as it's written in blocks and you don't and some random byte write to blow away a whole block.
<willmore>
With EEPROM SPI memory, the erase is at the byte level, so you get the erase as part of the write in that case.
<willmore>
If you're used to one, the other can be confusing.
<willmore>
Oh, and clever filesystems have taken advantage of that property of flash for a while--you can overwrite existing metadata or append to it to reflect changes.
Putti has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
<Mangy_Dog>
oh one thing i havnt checked yet is the clock solder jumper
<Mangy_Dog>
that might be it
Putti has quit [Remote host closed the connection]
<Mangy_Dog>
na that wasnt it
<Mangy_Dog>
umm
<Mangy_Dog>
curious
<Mangy_Dog>
the distortion is only there when its runnign bright, when it goes dim for screen saver i guess... the image is clear
Putti has joined #linux-sunxi
<jernej>
MoeIcenowy: AC200 EPHY works now! That bypass bit in PWM block made all the difference.
<jernej>
Now I have to clean it up...
<Mangy_Dog>
ok i think i know what i need to do
ijc has quit [*.net *.split]
ijc has joined #linux-sunxi
<Mangy_Dog>
need to create my own 800480 fex? i think the issue is timing... As the uboot is reading the EDID and setting itself correctly by that. So the chip is certainly capable of outputting the correct res and clk
<Mangy_Dog>
i think its just a sync or clk timing issue in the config
<Mangy_Dog>
oh and it only works in dvi mode
<Mangy_Dog>
-d
<mru>
the distortion is probably caused by timing being slightly off for the panel
<Mangy_Dog>
yeah
<Mangy_Dog>
thats my thought
<mru>
the datasheet you pointed to the other day doesn't provide timings though
<mru>
that's a bit rubbish of them
<Mangy_Dog>
i can get the timing from the example adafruit edid
<Mangy_Dog>
as that had it in that i think
<Mangy_Dog>
however I can contact my, contract :D
<Mangy_Dog>
contact
<Mangy_Dog>
who can give me the more indepth datasheet for my exsact model
<Mangy_Dog>
i had one... but lost it D:
<Mangy_Dog>
though
<Mangy_Dog>
ILI6122
<Mangy_Dog>
might be in that datasheet
<Mangy_Dog>
thats the driver for the panel
<Mangy_Dog>
Anyway i got to get back to food... so need to run for now
<mru>
that's just the controller
<mru>
and good luck finding any ilitech datasheets
BenG83 has quit [Remote host closed the connection]
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
warpme_ has quit [Client Quit]
lsjet has quit [Quit: Leaving]
diego_r has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
Putti has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<Mangy_Dog>
well theres also something wrong with my hdmi connection on my board as well :/ So getting this workign on the adaboard though with this bit of distortion... Thought to try and see if my board displays anything... Even though ive not fixed the flashing problem yet
<Mangy_Dog>
well no... i had a orange pink filled screen with some random lines show up
<Mangy_Dog>
its safe to say that the hdmi line in is wrong some way or another
<Mangy_Dog>
ive not got perfectly matched length difs, as i had to hand draw them in kicad but given the such short run (about an inch) i really didnt think it would cause that much of any issue... certainly not a sync issue with such a low bandwidth connection
diego_r has quit [Ping timeout: 272 seconds]
lurchi__ is now known as lurchi_
<m4t>
has anyone else experienced issues with usb audio + cpu frequency scaling on 4.19 mainline w/H5?
<m4t>
didn't see the issues with built in codec, but the system would stall/become unresponsive when trying to use a usb2 audio devices
<Mangy_Dog>
cant say i have, but just curious why use usb audio instead of built in audio?
<m4t>
issues went away when i set it to a fixed frequency
<m4t>
sound quality
<m4t>
ability to drive headphones properly
<Mangy_Dog>
the internal one that bad?
<Mangy_Dog>
in my project i have an external amp
<Mangy_Dog>
shame i cant get the display working :p
<Mangy_Dog>
everything else works so far :p
<m4t>
it's not going to have anywhere near the spec of a decent discrete dac/amp
<m4t>
tis why they make them. because onboard sound sucks a lot of the time.
<Mangy_Dog>
well i guess thats true if youre doing audiophile stuff
<m4t>
they cant source enough current to drive a lot of headphones either
<m4t>
earbuds maybe, but not high end headphones
<Mangy_Dog>
well like i said, my project uses an external amp
<m4t>
anyways, system shouldn't freeze when using usb audio ;)
<Mangy_Dog>
usb drawing too much power?
<m4t>
nope
<[TheBug]>
Mangy_Dog: are you using an H3 based device?
<Mangy_Dog>
me yes
<m4t>
the cpu is stalling, load avg goes to like 4-5 and the system takes hundreds of ms to respond to pings
<m4t>
basically locks up
<[TheBug]>
Go download H3Droid, once installed first time around and you get into H3resc, set your uboot to the video testing uboot and boot the device
<m4t>
rcu/workqueue stall messages in dmesg
<[TheBug]>
make sure you have TTL connected
<Mangy_Dog>
you sure its not browning out because usb draws too much power to run the internal amp on your sound card?
<[TheBug]>
it will output correct video information for your display
<Mangy_Dog>
ttl as in serial debug?
<[TheBug]>
yes
<Mangy_Dog>
or ssh console?
<Mangy_Dog>
well ive been setting the display res in that
<Mangy_Dog>
h3disp -w 800x480 -d
<[TheBug]>
again this something different it is a diagnostic tool put together for H3Droid
<[TheBug]>
but it is made to give display information
<m4t>
Mangy_Dog: no it's not browning out. it works fine with cpufreq set at a fixed frequency
<[TheBug]>
you could use it in your case to possibly find out all the display output types
<[TheBug]>
and H3 devices are sensitive to power drain with poor power supply on USB, so if you have less than a 5V3A supply and put something with a lot of power need in USB, you will likely be underpowering
<m4t>
the dac/amp only uses a few 10s of mA, i've run it with a power meter inline
<Mangy_Dog>
i would need to know what commands to put in to print out the stuff:?
<m4t>
its some bug with usb clocks or something
<m4t>
usb clock vs cpu clock or something
<[TheBug]>
Mangy_Dog: what is your actual end goal with the device?
<Mangy_Dog>
portable handheld retro game console
<[TheBug]>
hrmm
<[TheBug]>
what H3 board?
<Mangy_Dog>
orange pi zero plus 2
<Mangy_Dog>
just warn you im in apex... might be slow to reply
<[TheBug]>
So why don't you go get H3Droid then and run it and use the Android emulators, I have mine setup that way plays psp, gba, dreamcast most games no issue
<[TheBug]>
and you have a lot more help available for video resolutions etc
<[TheBug]>
oh
<[TheBug]>
hmm
<[TheBug]>
low memory board
<[TheBug]>
so may not do as well
<[TheBug]>
you may be able to run it but...
<[TheBug]>
I assume thats a 512mb or 256Mb memory board?
<[TheBug]>
512
<[TheBug]>
you might be able to pull it off but you will be tight on memory
<[TheBug]>
also provides ability to dual boot Armbian and take advantage of the H3resc video resolution settings menu instead of having to update uboot info your self
<[TheBug]>
Mangy_Dog: Android has overhead
<Mangy_Dog>
not android
<Mangy_Dog>
armbian
<[TheBug]>
you may be able to do it should you not enable Goole Play service updates
<[TheBug]>
I understand I am tyelling you everything you want to do will likely be 300% easier in H3Droid
<[TheBug]>
even using it to dual boot as it gives a gui interface for setting a bunch of stuff
<Mangy_Dog>
this is armbian...
<Mangy_Dog>
not android
<[TheBug]>
omg are you thick
<[TheBug]>
I can't do this anymore
<Mangy_Dog>
<[TheBug]> Mangy_Dog: Android has overhead
<[TheBug]>
you spent all day on what your doing all I am telling you is H3droid will work better and likely not present t he weird issues your having per se
<Mangy_Dog>
does it have a retropi build for it?
<[TheBug]>
might be worth burning on a card and testing
<[TheBug]>
I just... can't... it hurts.,..
<Mangy_Dog>
why bother trying to help if youre just going to be insulting
<[TheBug]>
well your not even following the conversation, so your right, it really isn't worth bothering.. I mean I don't know what more to do for you, it seems like I could tell you the answer and you would just say something random back about why it can't work or unrelated -- I mean seriously if your having display issues and thats what you have been fighting all day, don't you think trying
<[TheBug]>
something different would be worth a few minute -- go read the actual website and understand what it is and consider testing as I described -- maybe you will be able to get by the issue your seeing.
<[TheBug]>
you're*
<[TheBug]>
The nice thing about H3Droid is is dumbs down making a lot of the changes you have been trying and provides a interface to make those changes instead of you having to manually update the fex and boot.cmd
<[TheBug]>
so even if you don't us android, using it to install Armbian with might work out for you
<[TheBug]>
anyhow, shift over, back later...
<Mangy_Dog>
right so h3droid is an android build.... which on its own then is pretty usless to me
<Mangy_Dog>
as what im using isnt android based software
<Mangy_Dog>
which is why i said im not using android
<[TheBug]>
and again, I know you didn't read the webpage or you wouldn't have said what you just said, so I am indeed done trying to help for now, good luck to you!
msimpson has joined #linux-sunxi
<Mangy_Dog>
i did read the page, and it clearly said in its faq its an adroid build
<Mangy_Dog>
its had all teh chinese faff stripped down and clean up
msimpson has quit [Remote host closed the connection]
suprothunderbolt has joined #linux-sunxi
<Mangy_Dog>
H3Droid is an Android built for Allwinner H3 and H2+ based devices!