Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
vagrantc has joined #linux-sunxi
TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-sunxi
pitelpan has quit [Quit: I am going to fishing!!!]
leio has quit [Ping timeout: 250 seconds]
leio has joined #linux-sunxi
<lennyraposo> so everyone
<lennyraposo> new Debian images with kodi are coming along nicely
<lennyraposo> and h264 265 hardware decoding
<lennyraposo> ;)
<lennyraposo> can watch stuff in windowed mode
<lennyraposo> ;)
<lennyraposo> oops
<lennyraposo> wrong window
<lennyraposo> thought I was elsewhere
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.
<lennyraposo> 6. User layer driver implementation can reference at http://cgit.freedesktop.org/xorg/driver/...eo-armsoc/
egbert has joined #linux-sunxi
egbert_ has quit [Ping timeout: 250 seconds]
nixdork has joined #linux-sunxi
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
kaspter has joined #linux-sunxi
azend|vps has joined #linux-sunxi
azend|vps has quit [Remote host closed the connection]
azend|vps has joined #linux-sunxi
azend|vps has quit [Remote host closed the connection]
azend|vps has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
stasiic has quit [Ping timeout: 276 seconds]
cnxsoft has joined #linux-sunxi
lerc has quit [Ping timeout: 250 seconds]
lerc has joined #linux-sunxi
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
adj__ has quit [Quit: Leaving]
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 250 seconds]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 252 seconds]
<wens> hmm
<wens> if only they put out code that is nice to read and properly licensed
Net147 has quit [Ping timeout: 244 seconds]
Net147 has joined #linux-sunxi
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-sunxi
<lennyraposo> correction
<lennyraposo> I just got a message for the url on the Mali
<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.
<lennyraposo> 6. User layer driver implementation can reference at https://cgit.freedesktop.org/xorg/driver/xf86-video-armsoc/
<lennyraposo> read it all
<lennyraposo> from Allwinner to Pine engineers
reev has quit [Quit: Leaving]
reev has joined #linux-sunxi
<lennyraposo> they want to tie it into that?
<lennyraposo> this was translated from Chinese from tllim at pine
<wens> hmm, so the disp2 driver for h3/a83t was not kms/drm?
<lennyraposo> dunno
<wens> i'm not really familiar with how mali hooks into drm and xf86 video drivers in userspace though
<wens> at some elc talk this year someone mentioned that mali drivers are now available for download directly from arm
<wens> though there's no source code, due to the fact that arm bought mali from some other company, so there's restrictions on what they can do
<lennyraposo> they have the mali 450 64 bit drivers
<lennyraposo> but not the 400
<lennyraposo> grr
<lennyraposo> wish they went with 450
<lennyraposo> atleast we could get something going
<wens> don't expect SoCs to change that quick, the upgrade cycle time is mucher longer than software :)
<lennyraposo> oh I now
<plaes> c.h.i.p. already has some kind of mali support
<plaes> when looking at their tree
<wens> plaes: i'm rewatching mripard's talk on chip's drm/kms support
* plaes needs to rework the fe/de/tcon dts patches
IgorPec has joined #linux-sunxi
<plaes> yeah, Mali has origins from Norwegian mythology ;)
JohnDoe_71Rus has joined #linux-sunxi
<wens> mripard explains drm/kms gpu integration
<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
<ssvb> NiteHawk: so that https://github.com/skristiansson/ar100-info does not fail after the DRAM initialization is done by the U-Boot SPL
<NiteHawk> i see. i'll move forward with them, and rebase the "A64-support" branch accordingly then in a while
jernej has quit [Quit: Konversation terminated!]
<NiteHawk> btw: just commented on your SCTLR remark: https://github.com/linux-sunxi/sunxi-tools/commit/4a1dbf6f596eea94ecc2ad78ac74ba2eb8206d88#commitcomment-17388816 . Are you aware of more SoCs (other than A80) that might be affected?
jernej has joined #linux-sunxi
apritzel has joined #linux-sunxi
<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?
<stasiic> PMID906 is also similar in appearence http://linux-sunxi.org/File:Polaroid_PMID906_mainboard.jpeg
apritzel has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
<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
<NiteHawk> do you think http://paste.fedoraproject.org/363658/62943714/ make sense so far?
<NiteHawk> oh heck, he left...
Amit_t_ has joined #linux-sunxi
jernej has joined #linux-sunxi
apritzel has joined #linux-sunxi
<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]
juri__ has quit [Ping timeout: 276 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
<NiteHawk> i don't get what you're doing with the "nominal" checksum: https://github.com/apritzel/pine64/blob/master/tools/boot0img.c#L155-L156 - isn't that value rather meaningless? in most cases that would be (2 * checksum + CHECKSUM_SEED), assuming a 'matching' old_checksum
<NiteHawk> apritzel: ^
<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
<Amit_t_> ok but if you look at completed output few address are aligned http://paste.ubuntu.com/16281240/
<Amit_t_> like 7bf4b640 and 7bf4b680
* apritzel looks at the code ...
IgorPec has joined #linux-sunxi
<apritzel> Amit_t: I don't think your alignment hints work that way
<Amit_t_> apritzel: Like how ?
<apritzel> first you must not have a semicolon before the __aligned attribute
<Amit_t_> apritzel: oh sorry, I corrected it already
avph has quit [Ping timeout: 260 seconds]
<apritzel> second I think the compiler cannot make sure that a member within a struct is properly aligned
<apritzel> normally you allocate buffers that need to be aligned separately
<Amit_t_> apritzel: ok, You want me to have, __aligned attribute against struct emac_dma_desc rx_chain[CONFIG_TX_DESCR_NUM] ?
<Amit_t_> to make sure that structure members are aligned properly ?
<apritzel> I think you shouldn't have the actual buffers within the struct
<apritzel> just pointers to them
<apritzel> if they need to be aligned, you must allocate them this way
<Amit_t_> ok
<apritzel> but I think they don't need to be aligned
<apritzel> at least the hardware probably doesn't care
<apritzel> just the cache flush instructions do
<Amit_t_> Also, its just problem with recv buffers
avph has joined #linux-sunxi
<apritzel> that's all random, I am afraid
<apritzel> some may happen to be aligned and it works
<apritzel> solution should be easy: just round down the start address of the cache flush instruction
<apritzel> and round up the end
<Amit_t_> If a cache line size is greater than that of dma desc structure size , would it be problem with recv buffers
<Amit_t_> ok , you meant to say I should not use invalidate instruction at all and should use flush_dcache_range only ?
<apritzel> no, I meant you have to align the addresses that you pass to your cache maintenance instruction
avph has quit [Ping timeout: 260 seconds]
<Amit_t_> ok ;)
avph has joined #linux-sunxi
juri_ has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
willmore has quit [Ping timeout: 252 seconds]
juri_ has quit [Ping timeout: 244 seconds]
willmore has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
juri_ has joined #linux-sunxi
avph has joined #linux-sunxi
hrw has quit [Ping timeout: 260 seconds]
avph has quit [Ping timeout: 260 seconds]
hrw has joined #linux-sunxi
avph has joined #linux-sunxi
willmore has quit [Ping timeout: 246 seconds]
jernej has quit [Ping timeout: 240 seconds]
avph has quit [Ping timeout: 260 seconds]
willmore has joined #linux-sunxi
willmore has quit [Ping timeout: 250 seconds]
willmore has joined #linux-sunxi
jstein has joined #linux-sunxi
TheLinuxBug has quit [*.net *.split]
TheLinuxBug has joined #linux-sunxi
Amit_t_ has quit [Ping timeout: 250 seconds]
Nyuutwo has quit [Ping timeout: 250 seconds]
Nyuutwo has joined #linux-sunxi
arossdotme has joined #linux-sunxi
arossdotme-planb has joined #linux-sunxi
banana-pi-m2-usr has joined #linux-sunxi
akaizen has quit []
akaizen has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
banana-pi-m2-usr has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
JohnDoe9 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<juri_> got 4.5 working, and got iscsi working on 4.5.
apritzel has quit [Ping timeout: 244 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
zuikis has joined #linux-sunxi
tsuggs has quit [Ping timeout: 276 seconds]
Netlynx has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
VargaD has quit [Ping timeout: 244 seconds]
VargaD has joined #linux-sunxi
<juri_> um. is there someone who knows stmmac well around?
<juri_> i'm getting a lot of very crunchy oopses.. and they all appear to be happening around skb code, called from stmmac.
<NiteHawk> juri_: what platform (soc) are you on? i think stmmac had some issues in 4.5 - see http://linux-sunxi.org/Linux_mainlining_effort#Merged_into_4.5
<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 :/
bonbons has joined #linux-sunxi
<juri_> I'm going over my patch very carefully.
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
ricardocrudo has quit [Ping timeout: 260 seconds]
jernej has quit [Ping timeout: 276 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
iamfrankenstein has quit [Quit: iamfrankenstein]
bonbons has quit [Quit: Leaving]
iamfrankenstein has joined #linux-sunxi
nove has quit [Quit: nove]
paulk-aldrin has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
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]