<apritzel>
Peetz0r: I don't think that crust supports any Wake-on-(W)LAN yet, at least I don't see anything in the code
<apritzel>
Peetz0r: I dimly remember that smaeul once mentioned some experiments around WOL, but this was for wired Ethernet only, IIRC
<Peetz0r>
apritzel: thanks :)
<Peetz0r>
Any idea how much work it is to get support for it? I have tried figureing out how crust works but I don't understand much of it
<apritzel>
Peetz0r: regarding debug: if you want to play around with crust, it's probably easier to do on a devboard like the Pine64, where you have plenty of serial ports to attach to
<apritzel>
Peetz0r: I think on the A64 we are seriously limited by SRAM memory, which makes any larger feature like Wake-on-WLAN very tricky to implement
<apritzel>
(not to speak of the technical difficulties to get this to work in the first place)
<Peetz0r>
Isn't most of the work already being done by the wifi chipset?
<Peetz0r>
it is already smart enough to keep its connection open at a low data rate
<apritzel>
yes, but you would need to set it up, and set it into some mode where it listens for the magic packet
<apritzel>
I think Linux turns the Wifi off before going to sleep?
<Peetz0r>
Nope, at least not when you do `sudo iw phy0 wowlan enable any` first
vagrantc has quit [Quit: leaving]
<Peetz0r>
the status page of my accesspoint also shows it as connected many minutes after going to sleep
<Peetz0r>
so, to me (not an expert) it looks like the wifi chipset and driver are already doing the right thing
<Peetz0r>
so I think just watching for the signal on the WL-WAKE-AP pin and waking op the a64 should be everything that needs to happen?
tuxd3v_ has joined #linux-sunxi
tuxd3v has quit [Read error: Connection reset by peer]
<apritzel>
Peetz0r: well, if Linux sets that up already, you have a chance, but I don't know the details, you would need to wait for smaeul
<Peetz0r>
I'm patient :)
<apritzel>
probably some dummy driver to keep the clocks and regulators for the WiFi chip up, then enable the EINT IRQ for the GPIO
<apritzel>
Peetz0r: maybe you can take inspiration from the CIR (infrared) driver
juri_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
andy25225 has quit [Ping timeout: 240 seconds]
andy25225 has joined #linux-sunxi
kaspter has joined #linux-sunxi
kaspter has quit [Excess Flood]
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
chewitt has joined #linux-sunxi
smaeul has joined #linux-sunxi
andy25225 has quit [Ping timeout: 240 seconds]
andy25225 has joined #linux-sunxi
<smaeul>
Peetz0r: sorry, I've been offline due to a weather-related network outage. for debugging crust, enable CONFIG_DEBUG_LOG under Debugging options
<smaeul>
crust does not need any changes for WoWLAN. all of the necessary code will be in the Linux driver. as long as the GPIO IRQ is (kept) enabled during the suspend process, crust will use it as a wakeup trigger
<Peetz0r>
Sounds relatively easy
<smaeul>
Peetz0r: if you're starting with the PinePhone config, you'll need to enable CONFIG_SERIAL as well -- it's disabled by default for additional power saving
<Peetz0r>
And the serial lines are together with the main serial lines on the headphone jack?
<smaeul>
yes, crust "shares" UART0 by default
<Peetz0r>
check
<Peetz0r>
Will poke at it later, maybe tomorrow.
<Peetz0r>
Firt I'm gonna finish my very crude call recorder :p
shailangsa has quit []
jstein has quit [Quit: quit]
victhor has quit [Ping timeout: 260 seconds]
putti_ has joined #linux-sunxi
Putti has quit [Remote host closed the connection]
[TheBug] has quit [Ping timeout: 240 seconds]
[TheBug] has joined #linux-sunxi
jelly has quit [Ping timeout: 240 seconds]
jelly-home has joined #linux-sunxi
jelly-home has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #linux-sunxi
sunshavi has quit [Remote host closed the connection]
pCactus_ has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
<libv>
can we start adding notices to anything DW at probe time?
iyzsong has quit [Read error: Connection reset by peer]
<Peetz0r>
Hmm, so I enabled CONFIG_SERIAL and CONFIG_DEBUG_LOG for the pinephone, but "Firmware overflows allocated memory area" and "Firmware overflows into SCPI shared memory"
<Peetz0r>
so I guess we're flying blind here :p
iyzsong has joined #linux-sunxi
IgorPec_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
Net147 has quit [Quit: Quit]
<Peetz0r>
So, how do I install my self-baked crust? I assume I need to dd build/pinephone/u-boot-sunxi-with-spl.bin onto either /dev/mmcblk2boot0 or /dev/mmcblk2boot2?
pCactus has quit [Ping timeout: 272 seconds]
Net147 has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 240 seconds]
<Peetz0r>
Ah. I found the right section in the readme :)
tuxd3v_ has quit [Quit: Leaving]
<Peetz0r>
So I built with CONFIG_SERIAL=y but CONFIG_DEBUG_LOG disabled. SPL and Crust and then U-boot load (I see "SCP/INF: Crust v0.3.10119" on the serial) but after 'DRAM: 3GB" it hangs.
<Peetz0r>
waaaait, why does it say 4096 MB? It is hanging because it's trying to intialize dram I don't have?
_whitelogger has joined #linux-sunxi
bauen1 has quit [Quit: leaving]
lurchi_ is now known as lurchi__
prefixcactus has quit [Remote host closed the connection]
bauen1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi
apritzel has joined #linux-sunxi
lurchi__ is now known as lurchi_
prefixcactus has joined #linux-sunxi
<prefixcactus>
apritzel: my attempt to boot from emmc faced an unexpected problem: the emmc is not visible from neither SPL nor U-Boot proper (when it's loaded from the SD card)
<Peetz0r>
Maybe we're having the same problem?
<Peetz0r>
Detecting the emmc is the first thing that should happen after the point where it hangs.
<apritzel>
Peetz0r: are you using mainline U-Boot? For the PinePhone 3GB there is one patch missing upstream
<libv>
CotKzarny: i think pebcak might also be acceptable ;p
<Peetz0r>
So, what can I do with CONFIG_SERIAL enabled but CONFIG_DEBUG_LOG disabled?
<Peetz0r>
or, how do I enable CONFIG_DEBUG_LOG in spite of "Firmware overflows allocated memory area" and "Firmware overflows into SCPI shared memory"?
<Peetz0r>
Also, where do I define which gpio pins cause a wake-up?
<KotCzarny>
libv: ofc, but spelling might be different in that case
pCactus_ has joined #linux-sunxi
lurchi_ is now known as lurchi__
pCactus has quit [Ping timeout: 264 seconds]
<Peetz0r>
Oh huh there's a crust freenode in the readme and I've read right past that at least multiple times
random_yanek has joined #linux-sunxi
pCactus_ has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
<apritzel>
Peetz0r: as smaeul mentioned, that should be setup by Linux
<Peetz0r>
That should be in the device tree, right?
<Peetz0r>
so, I couldn't build with CONFIG_DEBUG_LOG, but I can build with CONFIG_DEBUG_INFO
<wens>
smaeul: do you by chance live in the Pacific Northwest? # power outage
<Peetz0r>
but, that doesn't seem to do anything
<apritzel>
Peetz0r: I don't know the details of this, but yeah: the DT is the place to put the GPIO pin for the wake up pin
<Peetz0r>
Yeah, but it was already there before I started digging
<apritzel>
wens: wasn't that all over the place? Our colleagues in Texas were affected as well
<Peetz0r>
I also noticed uboot shits their own DT. Does that matter?
<Peetz0r>
ships*
<wens>
I read about Texas this morning, though "frozen gas lines" seemed confusing to me
<apritzel>
Peetz0r: I think most distros use their own DTs: 57: Retrieving file: /dtb-5.11-sunxi64/allwinner/sun50i-a64-pinephone-1.2.dtb
victhor has joined #linux-sunxi
bauen1 has quit [Remote host closed the connection]
elros1 has quit [Read error: Connection reset by peer]
jelly-home is now known as jelly
uis has joined #linux-sunxi
<uis>
apritzel: Any news?
<apritzel>
uis: did you see the link to the debug patch I just posted 20 minutes ago?
dlan has quit [Remote host closed the connection]
pCactus_ has joined #linux-sunxi
<apritzel>
uis: I tested my two monitors here: they only list their native resolutions in the EDID response, so there is not much to choose from ;-)
<uis>
Found
<apritzel>
uis: but if your 4K display lists more than one, we can have a simple patch, to only accept modes with pixel clocks less than 165 MHz
<apritzel>
since this seems to be a generic limitation, the A20 manual lists that number as a limit explicitly
matthias_bgg has quit [Ping timeout: 260 seconds]
pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
<apritzel>
(but I don't know much about EDID, so can't tell if any display is expected to list alternative modes in this response, or if we should issue some kind of additional EDID request)
dlan has joined #linux-sunxi
pCactus_ has quit [Ping timeout: 264 seconds]
JohnDoe_71Rus has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
<uis>
What loglevel use? Or how to enable printing?
<apritzel>
uis: bummer! so it lists an alternative, but it's still to high
<libv>
uis: please use pastebin for multiline pastes
<uis>
K
<apritzel>
I wonder if we can fabricate some FullHD fallback mode? should we do that?
<libv>
1024x768@60 would be even safer
<libv>
165 is the original limit of dvi
<libv>
165MHz even
<libv>
so yes, it is pretty generic, only never versions of hdmi explicitely allow higher bitrates
<libv>
even though that 165MHz is a dotclock, and the actual bitrate is some GHz number, but that value is not x8, as it uses some simple compression and some error correction
<apritzel>
libv: I see that HDMI 1.2 still caries this limit, but apparently 1.3 supports a higher dotclock already. And the SoC manuals list support for HDMI 1.3 and 1.4
<libv>
apritzel: then the question becomes, what parts of the 1.3 specification?
<libv>
as i doubt that allwinner has done all of the verification
<apritzel>
libv: sure, they just want the stickers! HDMI 1.3!!!!
<libv>
as mentioned before, i ran into a lot of fun with dotclocks for the fosdem project
<apritzel>
the A20 manual explicitly says: "Comply with the HDMI v1.3 with HDCP\nSupport up to 165M pixel per second" (sic)
<libv>
so i would not be surprised that this could be a dotclock issue
<libv>
ah, good, settled :)
<apritzel>
I could provide the EDID entry from my good ol' Eizo Flexscan 15" LCD, which has a 1024x768 resolution, to be used as a fallback
<libv>
uis: are you able to get to a linux prompt and can you install the read-edid package?
<libv>
apritzel: this is a VESA defined mode that does not match modes generated by gtf/cvt
<libv>
so it's a seperate definition, and i think it should exist in the u-boot source tree somewhere already
<libv>
and 1024x768 is more than good enough of a fallback for a uboot prompt
<libv>
when i introduced native display to coreboot, i went for the 720x480 VGA textmode, as that was the lowest common denominator
<libv>
while still useful
<libv>
uis: can you get to a linux prompt at all?
<uis>
Yes
<libv>
uis: if so, can you install the read-edid package?
sunshavi has quit [Ping timeout: 240 seconds]
<uis>
K
<libv>
hrm, trying to verify this on the fosdem test machine...
<libv>
uis: modprobe i2c-dev
<libv>
uis: then run: get-edid | parse-edid
<libv>
i implemented the automatic handling of edid provided information in Xorg, so that people no longer had to edid their xorg/xfree86.conf all the time
<uis>
About fallback modes. Get them by dividind resolution by power of two.
<libv>
uis: the vesa standard mode 1024x768 is pretty universal by now
<libv>
it was just about possible with vga hw
<libv>
and unless you are into proper retrocomputing, you will not have hw that does not support it
<libv>
that is, unless you are running an lcd directly
<uis>
I know, but 16:9 is more common for hdmi.
<libv>
again, useful, and common enough
<uis>
*for hdmi monitors
<libv>
A10/A20 does vga as well
<libv>
vga, the physical connection, not the hw register compatibility
<libv>
uis: there's some form of lcd that displays your pixels
<libv>
between the hdmi cable and the lcd there's a hdmi decoder that converts the signal, and often does some processing as well
<libv>
such as scaling
matthias_bgg has quit [Ping timeout: 260 seconds]
<apritzel>
I agree, the U-Boot video console is just to see *something* on the screen
<apritzel>
"pretty" is not in the list of requirements
<apritzel>
I will have a look at that tonight, and then fake a mismatch to test it
xes_ has joined #linux-sunxi
xes has quit [Ping timeout: 240 seconds]
<mripard>
apritzel: well, pretty could be useful for simplefb
<apritzel>
mripard: true, but at the moment we have 0 * 0 @ 0 Hz, so it's an improvement already
<apritzel>
mripard: and apparently uis has native sun4i_drm output, at *some* resolution
<apritzel>
mripard: not sure how Linux handles this, can you tell?
matthias_bgg has joined #linux-sunxi
<mripard>
apritzel: I'm guessing the driver will filter all the EDIDs, and since there's none DRM will add the VESA ones
<apritzel>
mripard: many thanks, I think we will just go for that.
<apritzel>
we could do better, since we know that the monitor can do higher resolutions, so we could also consider a FullHD fallback first
<libv>
this requires 3 fixes to satisfy 99.9% of all use cases, first the 165MHz limitation, then a 1024x768 fallback when no modes survive, and an option to provide a modeline at buildtime
<apritzel>
libv: I think U-Boot already provides the standard VESA modes, in drivers/video/videomodes.c
<libv>
yeah, i suspected as much
<apritzel>
we could record the highest resolution provided by the monitor while going over the EDID modes (and filtering those which are too high)
<libv>
but now that i am done babysitting my 4y old, i get to go shopping
<apritzel>
and if that is at least FullHD, use FullHD, otherwise XGA
<libv>
apritzel: too much logic for what should be a fallback
<libv>
and then someone in future will have to go unify it without breaking it
<apritzel>
well, yes, sounds like a generic problem, maybe there is already something in the code elsewhere
<libv>
i doubt it
<libv>
uboot only recently and only partially grew device model
<libv>
there's no distributed validation as i introduced in 2005
<libv>
there's no structured display drivers aka modesetting
<libv>
so just go for a limit, a fallback, and give users to ability to hardcode a resolution
<apritzel>
libv: hardcode> there is already CONFIG_SYS_DEFAULT_VIDEO_MODE, but no user, and it's not Kconfig, but legacy
<apritzel>
so I guess another patch for that ...
<apritzel>
mripard: it looks like sun4i_dram handles both "DE1" and DE2, how different are they, actually?
<apritzel>
mripard: before I clean up sunxi_display.c in U-Boot, we might just merge it into sunxi_de2.c there then
<apritzel>
s/sun4i_dram/sun4i_drm/
<mripard>
apritzel: it depends on what you're talking about :)
<mripard>
there's several devices involved
<mripard>
mostly the "planes" device that does the DMA and blending, the TCON that generates the timings, and (if relevant) the HDMI or DSI controller
<mripard>
the DSI controller has never really changed
<mripard>
the HDMI controller got changed at some point for a designware (with the H3 iirc?)
<mripard>
the TCON slowly evolved but has always remained fairly similar
<mripard>
and the "planes" device is actually DE1 vs DE2
<mripard>
and it's completely different
<mripard>
and that changed with the A83t if I remember well
<mripard>
so yeah, strictly speaking the DE1 vs DE2 is only for the part that does the DMA and blending
<mripard>
but it's really a mix and match now depending on what SoC you want to support
eduardas has joined #linux-sunxi
<apritzel>
mripard: OK, thanks, I need to check the actual U-Boot code then, I guess
cmeerw has joined #linux-sunxi
<jernej>
mripard: apritzel: DW-HDMI first appeared in A80 (paired with DE1), all newer (A83T onwards) pairs DW-HDMI with DE2 or newer
<jernej>
aprizel: as mripard said, merging DE1 with DE2 makes no sense, they are almost nothing alike
<mripard>
jernej: ah that was the A80 not the H3, thanks :)
<jernej>
whereas DE2, DE3 and now DE3.3 remain pretty similar and can be handled with same code
<mripard>
DE3.3 is what is used on the H616?
<jernej>
yes
<jernej>
it's pretty interesting, though
<jernej>
it has common pool of planes - H616 has 3 VI and 3 UI planes
<mripard>
nice
<jernej>
and they can be assigned to any output
<mripard>
I just wished they weren't changing the design with every SoC :)
<jernej>
I have early working version for it, but VI plane scaling and YUV formats don't work yet
<apritzel>
jernej, mripard: I saw in the manual that G2D is back, is that of any help (for Linux)? We never supported it in mainline, did we?
juri_ has quit [Ping timeout: 246 seconds]
<jernej>
it's enough for desktop, but not for advanced DRM users like Kodi
<jernej>
apritzel: it's not supported currently
<jernej>
I'm sure someone would find it useful but he/she would need to write driver first
juri_ has joined #linux-sunxi
<mripard>
apritzel: the issue with G2D is not only how to write a driver, but how to make the userspace use ti
<apritzel>
mripard: yeah, I was wondering about that, also we didn't seem to miss it too much so far
<apritzel>
but manager would surely create a ticket out of that feature ;-)
<jernej>
mripard: DE2 is actually used on many SoCs
<jernej>
apritzel: regarding EDID - it contains detailed timings for few modes, others are described just with a number
<mripard>
jernej: yeah, I guess, but then you never have the same number of channels, VI and UI planes
<mripard>
and you have those nice additions like the TCON TOP
<mripard>
apritzel: issue 42: Make X behave ? :)
<mripard>
I'm sure a lot of managers have that one
<jernej>
apritzel: so you have to have big array of timings hardcoded
<jernej>
mripard: that's true, but at this point I consider this only minor inconvinience - only compatible with settings needs to be added
<mripard>
yeah, you did a great job to support it
<jernej>
oh, plenty of things to do
<jernej>
but thanks :)
<mripard>
my point was more that it was some significant work to support it like we did, without a lot of benefits
<mripard>
(well, obviously, having the DE2 working is some benefits)
<mripard>
but if they would have used the A83t design for every SoC every thing would have been working just fine too
<jernej>
mripard: with DE3.3 they introduced optional register DMA - so you set memory location which is then copied to respective registers automatically
<jernej>
it seems that if that unit is included, it must be used
<jernej>
but I'm not 100% sure, since H616 doesn't have it
ldevulder has quit [Remote host closed the connection]
<mripard>
it's going to be interesting to support :)
prefixcactus has quit [Ping timeout: 272 seconds]
pCactus_ has joined #linux-sunxi
<mripard>
it's not very far off what vc4 is doing though
pCactus has quit [Ping timeout: 264 seconds]
pCactus has joined #linux-sunxi
<jernej>
making this work would also help solve current DE2 issue where register read might return wrong value
<jernej>
I think none of those registers were meant to be read anyway
pCactus_ has quit [Read error: Connection reset by peer]
pCactus_ has joined #linux-sunxi
pCactus has quit [Ping timeout: 256 seconds]
vagrantc has joined #linux-sunxi
<mripard>
the commit bit polling didn't help?
<jernej>
I really don't want to add delays, IMO it's better to just set all (changed) registers before signalling dbuff
lurchi__ is now known as lurchi_
wens has quit [Ping timeout: 256 seconds]
wens has joined #linux-sunxi
sunshavi has joined #linux-sunxi
lurchi_ is now known as lurchi__
<linkmauve>
Hi, I just upgraded from 5.8.9 to 5.11.0 and while it worked fine on my Olimex Lime A20, my Lime2 are now both failing to get an IP.
<linkmauve>
There is a “0 is an invalid IRQ number” error in dmesg, but that seems unrelated to the issue at hand since it’s there also on the Lime.
<apritzel>
linkmauve: what is your phy-mode property in the GMAC devicetree node? if it's still "rgmii", you will probably need to change this to rgmii-id or rgmii-txid
lurchi__ is now known as lurchi_
<linkmauve>
apritzel, looking at the dtbs shipped by ALARM it seems to be rgmii still.
<linkmauve>
Is that something not upstream in Linux?
<apritzel>
almost every GBit Ethernet board broke, and only those where users sent patches got fixed
<linkmauve>
Oh, I see. :(
<linkmauve>
I’ll try to fix that for 5.11.1, hopefully not too many people will upgrade in the meantime.
<linkmauve>
apritzel, what is the difference between rgmii-id and rgmii-txid? Should I prefer one over the other? There is also a line saying pinctrl-0 = <&gmac_rgmii_pins>;, should I change that too?
<DuClare>
Don't touch pins
<linkmauve>
Ack.
<DuClare>
rgmii-id implies internal delay for both rx and tx
<DuClare>
rgmii-txid is just for tx
<DuClare>
So what you need depends on the board
<linkmauve>
I tried rgmii-id, it does give me an IP again!
<linkmauve>
I’ll test rgmii-txid now.
<linkmauve>
txid also works, so I assume txid should be preferred?
<linkmauve>
If so I’ll send a patch to the ML.
<DuClare>
No it really depends on the board..
<DuClare>
Can you run iperf?
<DuClare>
Or something
<DuClare>
To test network performance and stability
<linkmauve>
Any specific mode for iperf?
<DuClare>
Dunno.. you just need to see your bandwidth and packet loss
<DuClare>
It might be useful to run it in both directions, simultaneously
<DuClare>
(But I'd test separately first, in each directoin)
mmarc__ has quit [Remote host closed the connection]
pCactus_ has quit [Remote host closed the connection]
pCactus has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 260 seconds]
<DuClare>
What a mess :)
asdf28 has quit [Ping timeout: 246 seconds]
<DuClare>
Sorry I can't help you much more.. if I wanted to do the right thing, I'd check whether the board traces are matched (probably they are), and then check what delays are supposed to be configured on the phy
<DuClare>
(It may have some delays enabled by default, it is also possible that a driver disables or enables delays)
<DuClare>
And if that doesn't give a true answer.. well, I'd probably try to figure out whether that packet loss is due to congestion or corruption
<DuClare>
Congestion + high bandwidth would mean you're not being limited by the rgmii link
<DuClare>
On the other hand, if packets are dropped due to corruption, that is bad
<DuClare>
It's not the end of the world if you pick the "wrong" choice as long as it works
<linkmauve>
I’ll play safe and submit rgmii-id to mainline and 5.11.1 backport, explaining the choice in the commit message, but it’d indeed be good to figure out the underlying reason. :)
<linkmauve>
Is there anything I could do to help?
<DuClare>
Well if there's an adjustable delay, as the wiki page suggested there might be..
<DuClare>
You iterate through all the possible values, with both -id and -txid and see if there's a sweet spot :)
<DuClare>
Alternatively figure out what is the setup for your phy
<DuClare>
(Check datasheet & driver, look out for internal rgmii ingress/egress or tx/rx delays)
<DuClare>
The whole goal is very simple: rgmii clock signals need to be skewed by around 1.5-2ns
<DuClare>
That can happen at the mac, on the board itself (clock trace physically longer than data traces), or at the phy
<DuClare>
And it can happen in separate locations for both directions, e.g. one at mac and one at phy
<DuClare>
I'm going to assume most boards these days have matched trace lengths, so then it's either mac or phy
<DuClare>
If it's in the phy, you should see it in the datasheet (or possibly driver if it's configurable and the driver doesn't just rely on defaults)
<DuClare>
I guess it's plausible that some phys also have config pins, in which case you'd have to see whether the board pulls it high or low
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
<DuClare>
Even then, depending on what range of adjustability the mac supports, it may be better to calibrate it there.. so it's just a lot of trial and error to find the sweet spot
<DuClare>
For rockchip boards people have used scripts that load a DT overlay on the fly and reset the driver
<DuClare>
And run it through all the possible values for both tx and rx to find the sweet spot