mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
paulk-aldrin has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
jernej has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
bonbons has joined #linux-sunxi
al1o has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 260 seconds]
cnxsoft1 is now known as cnxsoft
apritzel has joined #linux-sunxi
staplr has quit [Ping timeout: 244 seconds]
staplr has joined #linux-sunxi
<wens>
juri_: is it in stable?
apritzel has quit [Ping timeout: 244 seconds]
p1u3sch1_ has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
jstein has joined #linux-sunxi
avph has joined #linux-sunxi
jernej has joined #linux-sunxi
<montjoie>
apritzel I am sure that on pine64 PHY need to be powered, each time EMAC timeout in reset, the root cause is PHY
apritzel has joined #linux-sunxi
staplr has quit [Ping timeout: 276 seconds]
apritzel has quit [Ping timeout: 244 seconds]
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
The_Loko has joined #linux-sunxi
arossdotme has quit [Ping timeout: 246 seconds]
jernej has quit [Ping timeout: 260 seconds]
arossdotme has joined #linux-sunxi
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
jernej has joined #linux-sunxi
The_Loko has quit [Ping timeout: 246 seconds]
The_Loko has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
stasiic has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Graf_Ithaka has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 246 seconds]
<Graf_Ithaka>
good afternoon. Starting off with my Pine64, using the arch-build. already updated kernel manually (using kernel.sh from build-pine64-image repository). Only have access via UART. Is kernel 3.10.101-0-pine64-longsleep already hdcp_enable=0 ? On some points in the forum people hint that this might resolve HDMI/DVI issues. Thanks in advance :)
p1u3sch1 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
dlan has quit [Ping timeout: 250 seconds]
<longsleep>
Graf_Ithaka: all my releases are with hdcp disabled
<Graf_Ithaka>
longsleep: thanks for the confirmation, then I'll need another adapter I guess :)
<longsleep>
Graf_Ithaka: default HDMI resolution is 1080p60 - does your screen support that?
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
<Graf_Ithaka>
longsleep: not exactly, it supports 1920x1200 @ 60Hz and many more modes below that
<longsleep>
Graf_Ithaka: well then you have the answer, check the Pine64 forum on how to switch to lower resolution (eg 720p)
<longsleep>
Graf_Ithaka: some people have confirmed that it works for them now with the releases from yesterday
<Graf_Ithaka>
longsleep: tried doing so with your sunxi-disp-tool already but to no avail.
<longsleep>
Graf_Ithaka: well - it should work just fine, try the Xenial image if unsure
<Graf_Ithaka>
longsleep: okay will try that one :) thanks for your help :)
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein1 is now known as iamfrankenstein
p1u3sch1 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
arossdotme has quit [Ping timeout: 276 seconds]
The_Loko has quit [Quit: Leaving]
kruxXx has joined #linux-sunxi
Nacho has quit [Ping timeout: 246 seconds]
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
montjoie: PHY powered> yeah, would make sense, only the schematics is not really helpful here
<apritzel>
montjoie: there is some extra power signal referenced in the PHY section, but it's not clear where it is connected
<apritzel>
and on the PMIC section I don't see a rail that would be reserved for the PHY
<apritzel>
NiteHawk: btw: your Pine64 is on the way, 1GB plus Wifi
<apritzel>
probably the best packaged Pine64 so far ;-)
<apritzel>
wens: yeah, I am afraid I have to go down into the BSP dungeon for this ;-)
<apritzel>
NiteHawk: ah, nice, looks mostly good
<apritzel>
only that I am not a fan of mapping file formats to C structs
<apritzel>
as this relies on the compiler and ABI to match the file format
<NiteHawk>
ah, i see. to me, the uboot_header_t didn't "feel worse" than shuffling around with the word offsets
<Graf_Ithaka>
longsleep: I tried the Xenial image. I can get a pink-ish image for a short time during boot if I flash the uboot with hdmi_cts_compatibility=1 as mentioned somewhere in the Xenial thread. Then image disappears again. Also I might have messed up something with this flash since my wifi is now not working anymore.
<apritzel>
I see this "mapping something to C structs" a lot in sunxi code (in U-Boot, for instance)
<NiteHawk>
apritzel: as i'm not making too much use of those header fields in extract_image(), i could discard/revert that again easily
<apritzel>
this is frowned upon in the kernel - I guess for x86(-64), arm and arm64 the assumptions hold for the time being, that's why it works
<NiteHawk>
well, as long as you can make sure that your structs match the actual (file or memory) layout, it's a somewhat 'natural' way to access the member fields
<apritzel>
yeah, I see that, the point is that "make sure" is not really possible, as the C standard says that the compiler is free to align members in structs
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
<apritzel>
now there is an ABI demanding certain rules to make object files compatible
<apritzel>
so far the rules for arm and x86 match up here, at least for things like uint32_t, uint64_t and char[], which is whats mostly used in these fields
<apritzel>
so I decided deliberately to give this array approach a go here
<apritzel>
and it didn't look too bad
<NiteHawk>
well it's really up to your preferences - i can live with those header_offsets enum just as well
<apritzel>
I see some code in U-boot which matches register offsets to structs, with having the register offsets (as described in the manual) as comments in the declaration
kaspter has joined #linux-sunxi
<apritzel>
which is a bit weird, as the register offset is the reference and it should be reflected in the code, not in the comments
<NiteHawk>
yeah, quite a few places in uboot rely on structs / packing i think. at least from what i've seen when tinkering with the spl header
arossdotme has joined #linux-sunxi
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
jernej has joined #linux-sunxi
<KotCzarny>
lvrp16: where is opi+2e ?
<lvrp16>
KotCzarny: Coming out this week
<KotCzarny>
lvrp16: woo, hoo
staplr has joined #linux-sunxi
<longsleep>
apritzel: Pine64 nic driver is horrible - beware :)
<longsleep>
Graf_Ithaka: and you added the kernel parameter so that it changes to 720p on boot?
<longsleep>
Graf_Ithaka: but anyhow, you can ssh in and just try out various resolutions from commandline
<wens>
longsleep: already looked at it :|
<Graf_Ithaka>
longsleep: I added disp.screen0_output_mode=EDID:1280x720p60 as fallback. at a certain point I get [HDMI WRN] file:drivers/video/sunxi/disp2/hdmi/drv_hdmi.c,line:331: unsupported video mode 65535 when set display mode
<Graf_Ithaka>
longsleep: I am connected via UART and tried playing with the resolutions. No reaction at all, screen stays blank
<longsleep>
Graf_Ithaka: yeah, ignore that line message - its something else sending wrong parameters
<longsleep>
Graf_Ithaka: well, then i guess you need another converter. I think there are some references to working ones in the Pine64 forum
<wens>
seems there's a) void * base + OFFSET_MACRO, and b) &((struct foo *)base->bar)
<wens>
kernel uses (a) more, while u-boot uses a lot of (b)
ricardocrudo has joined #linux-sunxi
<Graf_Ithaka>
longsleep: already guessed so. Well, weekend is over anyway :) Thanks for your help and have a nice evening! :)
<longsleep>
Anyone has measured performance of the various sunxi-ss crypto and hash implementations? I am wondering if i should bother with them ...
staplr has quit [Remote host closed the connection]
Graf_Ithaka has quit [Ping timeout: 240 seconds]
<apritzel>
mripard: sorry for that trouble with that sunxi irq controller patch, who do I have to contact for getting that original ARCH_SUNXI for arm64 patch reverted?
paulk-collins has quit [Quit: Leaving]
jstein has joined #linux-sunxi
hrw has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
<dave0x6d>
So for the Orange Pi (One) that has a H3, any suggestions on what kernel to use?
ssvb has joined #linux-sunxi
tomboy65 has quit [Quit: Uhh ... gotta go.]
tomboy64 has joined #linux-sunxi
jstein has quit [Remote host closed the connection]