al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kaspter has quit [Ping timeout: 260 seconds]
pitelpan has joined #linux-sunxi
<lennyraposo>
hey ssvb
<lennyraposo>
got something for ya
<lennyraposo>
hope this is meaningful
<lennyraposo>
Translate:
<lennyraposo>
1. UMP will not be support on A64 (ARM only support 32 but UMP and not 64 bit), this means cannot using UMP method to drive USER driver layer which is common implementation method in pass.
<lennyraposo>
2. Need to use dma_buffer method to implement USER layer and DRM driver.
<lennyraposo>
3. The KMS portion on the DRM driver related to display (DE, TCON, HDMI hardware related) needs Allwinner engineerign team to implement. The GEM portion coding can achieve by dma_buffer method, whcih is easy to accomplish.
<lennyraposo>
4. Allwinner will provide a interim solution, KMS portion using display driver and DE, TCON, and HDMI can become part of BSP parameter for KMS implementation.
<lennyraposo>
5. Allwinner will also privide DRM driver, same as using DE, TCON related BSP for KMS implementation. They are working on now and expected should be able to link up with Ubuntu upper layer driver on end of May.
<nixdork>
Are they finally opening up all the source for the Malis?
<wens>
probably not
<wens>
lennyraposo: that's a soc-specific drm/kms based driver for X11
<wens>
not much to do with mali
<wens>
mali is a 3d engine, not a display pipeline
<lennyraposo>
1. UMP will not be support on A64 (ARM only support 32 but UMP and not 64 bit), this means cannot using UMP method to drive USER driver layer which is common implementation method in pass.
<lennyraposo>
2. Need to use dma_buffer method to implement USER layer and DRM driver.
<lennyraposo>
3. The KMS portion on the DRM driver related to display (DE, TCON, HDMI hardware related) needs Allwinner engineerign team to implement. The GEM portion coding can achieve by dma_buffer method, whcih is easy to accomplish.
<lennyraposo>
4. Allwinner will provide a interim solution, KMS portion using display driver and DE, TCON, and HDMI can become part of BSP parameter for KMS implementation.
<lennyraposo>
5. Allwinner will also privide DRM driver, same as using DE, TCON related BSP for KMS implementation. They are working on now and expected should be able to link up with Ubuntu upper layer driver on end of May.
<wens>
background discussion about mali-400 driver situation is barely audible :(
arossdotme has quit [Ping timeout: 260 seconds]
<wens>
lennyraposo: hmm, the 450 driver is aarch64 :(
<lennyraposo>
I know
<lennyraposo>
hey wens
<lennyraposo>
quick question
<lennyraposo>
libvdpau
<wens>
yeah?
<wens>
disclaimer: i haven't used it
<lennyraposo>
ok
<lennyraposo>
in the wiki it says to copy the files over to /usr/lib/vdpau
<lennyraposo>
why the need if it installs elsewhere?
<lennyraposo>
just wondering
<wens>
"Depending on the distro in use, it's most likely they will need to be put in /usr/lib/vdpau."
<wens>
so it's a possibility, not a certainty
<wens>
i think a lot of distros now have arch specific paths for /usr/lib
<lennyraposo>
yeppers
<lennyraposo>
vdpauinfo shows me nvidia with an erro but not sunxi
<lennyraposo>
hmm
<lennyraposo>
evertyhing compiled and installed without error
staplr has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
Amit_t_ has joined #linux-sunxi
<Amit_t_>
where I can get lichee_linux_310.tar.gz ?
Amit_t_ has quit [Quit: Page closed]
JohnDoe9 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 276 seconds]
zumbi has quit [Ping timeout: 276 seconds]
Guest61622 has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
kaspter has joined #linux-sunxi
scream has joined #linux-sunxi
zuikis has joined #linux-sunxi
apritzel has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
paulk-aldrin has quit [Excess Flood]
paulk-aldrin has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<ssvb>
lennyraposo: thanks for the information
<ssvb>
lennyraposo: a really new thing is that Allwinner started implementing the DRM/KMS driver themselves
jernej has joined #linux-sunxi
<ssvb>
lennyraposo: this is great, but of course it could mean anything depending on how their plans (a quick and dirty private hack specifically for you or a contribution to the mainline kernel)
nabblet has joined #linux-sunxi
<lennyraposo>
glad and hope it helps mate
IgorPec has quit [Ping timeout: 265 seconds]
<lennyraposo>
hey ssvb
<lennyraposo>
so they are nixing the UMP
<lennyraposo>
in favour of hopefully somethign a bit mor emodern
<lennyraposo>
maybe we will get a sort of fglrx approach
<lennyraposo>
but it still will be egl n'est pas?
prasannatsm has joined #linux-sunxi
Netlynx has joined #linux-sunxi
paulk-aldrin has quit [Ping timeout: 246 seconds]
paulk-aldrin has joined #linux-sunxi
<ssvb>
lennyraposo: yes, dropping UMP is totally expected and is not anything new
<NiteHawk>
ARM itself did that for their recent utgard drivers, or?
<ssvb>
UMP was invented as a necessary solution at the time when DMA-BUF did not exist yet
<ssvb>
this is somewhat similar to the FEX and the device tree story
<ssvb>
and because DMA-BUF is a standard thing in the mainline kernel now, ARM has eventually changed their code to use DMA-BUF instead of UMP
<ssvb>
but both of these things are providing the same functionality, which is needed for the Mali drivers: memory buffers sharing between processes
<NiteHawk>
ssvb: looking at https://github.com/linux-sunxi/sunxi-tools/commits/A64-support it's really only the very last patch that is A64-specific, or? the rest deals with A10/13/20, A31 and H3. do you consider those "mature" / ready for merging already?
<ssvb>
NiteHawk: yes, the other patches just rearrange the SRAM address space usage and unbreak OpenRISC at least on A31 and H3
<mripard>
wens: the discussion we had about the "new" mali blob license was only for the mali-t blobs unfortunately
apritzel has quit [Ping timeout: 244 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft1 is now known as cnxsoft
reev has quit [Ping timeout: 252 seconds]
reev has joined #linux-sunxi
paulk-aldrin has quit [Ping timeout: 244 seconds]
paulk-aldrin has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<longsleep>
nice - it boots Linux version 3.10.101-0-pine64-longsleep (longsleep@mose2) (gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2) ) #38 SMP PREEMPT Sat May 7 11:20:15 CEST 2016
<wens>
mripard: :(
<wens>
got psci cpu off (fiq) working entirely in C
<wens>
and then my board locked up due to some userspace updates :/
Amit_t_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
stasiic has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
al1o has joined #linux-sunxi
Amit_t_ has quit [Ping timeout: 250 seconds]
nabblet has quit [Quit: leaving]
apritzel has joined #linux-sunxi
Netlynx has quit [Ping timeout: 246 seconds]
nove has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
reev has quit [Ping timeout: 244 seconds]
<nove>
if still "all right reserved", whatever will be done will be of no use
<nove>
and maybe, allwinner engineers time could be better spent by working with us(linux-sunxi) in mainlining
<nove>
lennyraposo: ^
jernej has quit [Ping timeout: 260 seconds]
Shirasaka-Hazumi has quit [Ping timeout: 240 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
reev has joined #linux-sunxi
Nacho has quit [Ping timeout: 252 seconds]
Nacho has joined #linux-sunxi
jernej has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Read error: No route to host]
cnxsoft has quit [Quit: cnxsoft]
jernej has joined #linux-sunxi
jernej_ has quit [Ping timeout: 260 seconds]
Amit_t_ has joined #linux-sunxi
<stasiic>
This is odd.. I am trying to locate the UART on a denver tac. I see on the PCB there is a mark saying VCC, RX, TX and GND in a square, but there are no connectors no where near that mark. Any ideas? Maybe the connectors are on the back of the PCB?
reev has quit [Read error: Connection reset by peer]
<TheLinuxBug>
stasiic: not all board provide connector pins, you likely need to soldier your own onto the board to make use of the UART, either that or soldier the UART directly to the board, but that seems a bit inconvient.
<stasiic>
TheLinuxBug: Yeah I was thinking that there should at least be some pads near the mark where I could solder all the stuff on, but there aren't even any pads
<TheLinuxBug>
hmm what board is this?
<stasiic>
TheLinuxBug: I couldn't find it in the wiki but it is A13 and is very similar to this one http://linux-sunxi.org/Inet_86vs#Pictures . The UART mark is in a different place though
<stasiic>
I have looked through all the A13 tablet pictures in the wiki, the Inet 86vs is the most similar in appearence
<stasiic>
maybe I should create a wiki page and upload some pictures?
<apritzel>
wens: lennyraposo: the reason the Mali450 (and not Mali400) blobs are available in 64-bit is probably due to the HiKey board
<apritzel>
I can try to check if the respective Mali400 bits could be released as well
<stasiic>
oh well.. I'll just wait for the multimeter to arrive and find out that way
<wens>
are there official (ARM or Linaro) boards with Mali 400?
Amit_t_ has quit [Ping timeout: 250 seconds]
<apritzel>
wens: not from 96boards, AFAIK (either Adreno or MP450)
<wens>
that explains it
<apritzel>
but it may just have been because nobody has asked for MP400 blobs
<apritzel>
which I could naively try next week ...
<mripard>
apritzel: I've been using the driver with a mali 400 without any particular issue, beside it directly accessing userspace buffer
<wens>
the kernel side driver is open source isn't it, which means we could patch it?
<apritzel>
mripard: you mean a mali450 blob on a Mali400 hardware?
<apritzel>
wens: AFAIK there should be some OpenSource graphics effort around the HiKey, I guess we could piggy back on this
Netlynx has quit [Ping timeout: 276 seconds]
<wens>
interesting!
<apritzel>
I am afraid that still does cover the actual Mali blobs, but at least the rest of the stack
dlan has joined #linux-sunxi
fredy has quit [Excess Flood]
<mripard>
wens: if you want to check every memory access done by that driver, go ahead ;)
<mripard>
apritzel: but yeah, I'm guessing the blob would work as well
<mripard>
there's only one way to find out
fredy has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
kaspter has quit [Ping timeout: 260 seconds]
<KotCzarny>
hrm, no opi+2e in sight
<NiteHawk>
apritzel: got a minute?
<NiteHawk>
i'm currently having a closer look at your boot0img. what i would like to add is some extra functionality (-x, --extract) to create the "magic" boot0.bin, bl31.bin and scp.bin from an existing image
<NiteHawk>
your extract_fw_blobs.sh pulls out a firmware.img, and as i understand it, those blobs are contained within that at known offsets and with fixed sizes
<Amit_t_>
Can anyone provide me "mdio list" output from cubietrack board ?
<apritzel>
NiteHawk: /me is back
<NiteHawk>
\o/
<Amit_t_>
from u-boot prompt?
<apritzel>
NiteHawk: as, reminds me to update my Booting.md description
<apritzel>
actually those addresses are not hardcoded
<apritzel>
they sit at offset 0x500 in the header
<NiteHawk>
ah, okay
<apritzel>
so yes: having -x to extract stuff is fine for me
<wens>
Amit_t_: you should get a phy at address 0 and 1
<wens>
0 is like a broadcast address for MDIO
<NiteHawk>
apritzel: but it still holds that the u-boot / firmware.img checksum currently covers the entire shebang?
<NiteHawk>
apritzel: i think it's somewhat useful to provide a way to easily get the .bin files, otherwise user will come back whining that boot0img is missing the required files :P
<Amit_t_>
wens: Thanks, on pine64 u-boot I do see http://paste.ubuntu.com/16280043/ but should not I see realtalk Phy instead of generic phy ?
<apritzel>
NiteHawk: checksum is for everything from offset 0 till whats stored offset 0x14 (HEADER_LENGTH)
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<apritzel>
haven't tried if that actually has to cover scp and ATF
<apritzel>
it does in the Android image, so I copied this
<wens>
Amit_t_: depends on if you compiled the realtek phy driver & whether that driver actually supports and matched the phy
<wens>
u-boot realtek phy driver seems to only have entries for phys that have quirks
<wens>
you should check though
<NiteHawk>
apritzel: yes, i was working with those assumptions based on the pine64_linux-20160121.img you provide in your repo. i guess that's an "original" one?
<Amit_t_>
wens: sorry but what do you mean PHY that have quirks ?
<apritzel>
For this one I copied the firmware bits from the first Android image - so kind of "original" one
<wens>
Amit_t_: yes
<NiteHawk>
okay, those were some very useful hints - that's something i can continue working with/on for now. thx
<wens>
but that was my impression, not sure if it's fact
<apritzel>
NiteHawk: do you want to hack the -x functionality into?
<ssvb>
NiteHawk: did you get a Pine64 board?
<NiteHawk>
apritzel: yes, that's the plan. from a "sunxi-tools" point of view, we won't be shipping images or firmware blobs with boot0img - so i'd say it's sort of a requirement to carry your tool over...
<Amit_t_>
wens:I see realtalk driver is not compiled with u-boot source I have for pine64 . Actully on cubietrack we have I think realtak PHY, so I just wanted to what it shows on mdio list
<NiteHawk>
ssvb: no
<ssvb>
NiteHawk: I see, too bad
<wens>
mine is still stuck in shenzhen, for 2 weeks now :/
<NiteHawk>
at least not yet - and i get the impression that people don't like the pine64 quality too much - maybe it's saner to wait for something from Olimex? or get a Xunlong H3
* NiteHawk
waits for frustrated peeps to toss their pine64 into ebay X)
Shirasaka-Hazumi has quit [Quit: ZNC 1.6.2+deb2+b1 - http://znc.in]
<apritzel>
the nominal checksum is naively checksumming everything in that area
<apritzel>
NiteHawk: btw: I can send you a Pine64 if you don't want to wait any longer
<NiteHawk>
ah okay, my bad. i hadn't thought on the meaning of old_checksum here, it's just the value at offset +12 (which is left out from the checksum calculation)
<apritzel>
NiteHawk: exactly
<apritzel>
frankly I am not sure either it's useful, but it didn't cost me anything to just print it :-P
<apritzel>
it that's too confusing we can just remove it
prasannatsm has quit [Ping timeout: 252 seconds]
<NiteHawk>
no, it's okay - i noticed the value isn't really used anywhere, i was just puzzled with its meaning
<NiteHawk>
apritzel: that's very generous - i'm just not sure i would want one. probably /me ends up getting sucked knee-deep into A64 development ;)
Amit_t_ has quit [Ping timeout: 250 seconds]
<apritzel>
NiteHawk: that was my idea ;-)
Amit_t_ has joined #linux-sunxi
<Amit_t_>
apritzel: Hi, trying to run H3 emac code with cache on I do get ping working but I see this ..http://paste.ubuntu.com/16281008/
<apritzel>
Amit_t: the buffers should be aligned then
<apritzel>
or you just pass aligned addresses, so that the range is aligned
<Amit_t_>
apritzel: Its actually received buffers but how come ping has passed ?
<apritzel>
Amit_t: if you memory looks like A....bbbbAbbb....A
<Amit_t_>
apritzel: Also, few starting received buffers are aligned
<apritzel>
where As are cache aligned and b is your buffer
<apritzel>
then you have to pass the range between the first and the third "A" instead of the buffer address
<NiteHawk>
you might want to try an earlier version (4.5-rc7), or a recent 4.6
<juri_>
i'm running the patches from that link.
<juri_>
on a pcduino3 nano lite.
<juri_>
i'm also running iscsitarget with ~250 lines of patch, to make it work on 4.5. I'm double and tripple checking my work now.
<NiteHawk>
might be a bit hard to tell if the issues you are experiencing are originating from iscsi or kernel-side. you could try an alternative implementation like http://scst.sourceforge.net/
<NiteHawk>
hmm... digging their repo it seems they're still at 4.4 :/
staplr has quit [Read error: Connection reset by peer]
staplr has joined #linux-sunxi
zerotri has quit [Ping timeout: 250 seconds]
staplr has quit [Remote host closed the connection]
zerotri has joined #linux-sunxi
avph has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
kaspter has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
mosterta has joined #linux-sunxi
Nyuutwo has quit [Quit: No Ping reply in 180 seconds.]
avph has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
juri_ has quit [Ping timeout: 246 seconds]
avph has joined #linux-sunxi
juri_ has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
<lennyraposo>
longsleep
<lennyraposo>
everyhting works well with the display tool
<lennyraposo>
just an fyi ;)
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<longsleep>
lennyraposo: ok good
<lennyraposo>
tried on a few tvs
<lennyraposo>
1080ps
<lennyraposo>
1 RCA 2 LGs
<lennyraposo>
720ps
<lennyraposo>
1 RCA 1 Emerson
<apritzel>
longsleep: do you build ATF as part of your image creation? From my github repository?
<longsleep>
apritzel: yes, but have not updated it since a while
<lennyraposo>
and then 2 AOC monitors
<apritzel>
longsleep: me neither ;-)
<apritzel>
but I plan to push some patches today
<apritzel>
the final HEAD will probably not run BSP kernels anymore
<longsleep>
apritzel: ok - it would be nice if there would be a tag or something i could add to the docs
<apritzel>
so I will have either a branch or at least a tag that denotes the last commit that should still work
<apritzel>
;-)
<longsleep>
perfect
<longsleep>
thanks!
<apritzel>
but: I cannot (or don't want to?) test it
<apritzel>
So I will ping you when the branch is public
<apritzel>
if you could test it then?
<longsleep>
heh, well let me check what commit i currently have, so just tag that one :)
<longsleep>
sure
<longsleep>
i am non fc1e255c846bc0a0c72c8e6f822e64e24704e136
<apritzel>
you should surely take the fixes that I will push
<longsleep>
Mon Feb 15 02:03:45 2016 +0000 - very old :)
<longsleep>
apritzel: sure, i am happy to test then - just ping me
<apritzel>
removes errata workarounds for A57 and Juno and so on
<longsleep>
i am offline for tthe night soon, but tomorrow
<apritzel>
sure, not sure I will manage to push before bedtime anyway ;-)
<apritzel>
just realised that the next U-Boot release should be on Monday already, and at the moment the shiny new Pine64 board support doesn't compile
<longsleep>
i really want to use a newer u-boot :/
<longsleep>
and a non crap Kernel too
<longsleep>
just need hyp and 1000M nic
<apritzel>
longsleep: well, feel free to debug it ;-)
<apritzel>
my firmware image and a64-wip build with defconfig should give you everything
<longsleep>
yeah - i hope i will come to do that soon - somebody keeps me from it all the time - BSP stuff you know .. :/
<apritzel>
there is even an eth0, but it complains due to failing SOFT_RST when i try to bring it up
jstein has quit [Remote host closed the connection]