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
TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-sunxi
<ssvb> agraf: is it expected that http://csgraf.de/agraf/pine64 returns error 404?
<lennyraposo> gotta clear out those old debian images tonight
lerc has quit [Remote host closed the connection]
lerc has joined #linux-sunxi
medvid has quit [Ping timeout: 264 seconds]
medvid has joined #linux-sunxi
tipo has joined #linux-sunxi
Tusker has joined #linux-sunxi
<Tusker> heya guys, am looking at porting in BCMDHD support into the 4.6 kernel, and was wondering if anyone had a commit set already for it ?
<lennyraposo> meson
<lennyraposo> isn't that amlogic?
<Tusker> doesn't really matter, right? a BCMDHD is a BCMDHD ?
<lennyraposo> oh for broadcom net support?
<Tusker> yeah
egbert_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
tsuggs has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<wens> Tusker: mainline uses the brcmfmac driver
<wens> you should try to get that to support your chip
ninolein has quit [Ping timeout: 250 seconds]
<Tusker> OK, so don't mess with BCMDHD ?
ninolein has joined #linux-sunxi
<wens> brcm80211 (brcmfmac / brcmsmac) is supported by broadcom's people
<Tusker> OK
<Tusker> btw, I don't see the ethernet PHY coming up, even though I have REALTEK built into the kernel...
<Tusker> what about the ethernet ?
<wens> on what chip/board?
<Tusker> banana pi m3
<wens> work in progress
<wens> so is wifi for that matter
<Tusker> it has a rtl8211e, which seems in mainline kernel already, no ?
<wens> that is only the phy, not the controller (which isn't supported
jernej has quit [Ping timeout: 246 seconds]
jernej has joined #linux-sunxi
<Tusker> ah ok, what controller is in it ?
<wens> some unknown hardware named "EMAC"
<wens> the driver is WiP, as listed on the wiki
andoma_ has quit [Read error: Connection reset by peer]
andoma has joined #linux-sunxi
hpeter has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 265 seconds]
p1u3sch1 has joined #linux-sunxi
<lennyraposo> controller vs phy are 2 different things
<lennyraposo> system on chip is no joke ;)
orly_owl has quit [Ping timeout: 250 seconds]
reev has joined #linux-sunxi
orly_owl has joined #linux-sunxi
<Tusker> lennyraposo: yeah, I'm learning that
<lennyraposo> I'm still learning myself
Tusker has quit [Ping timeout: 260 seconds]
<hpeter> hello, someone had success built https://github.com/montjoie/linux.git branch:sun8i-emac-wip
<hpeter> it'll error on make dtbs
<hpeter> Error: arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts:170.1-6 Label or path ephy not found
Gerwin_J has joined #linux-sunxi
hpeter has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
hpeter has joined #linux-sunxi
arossdotme has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
dgilmore has quit [Ping timeout: 250 seconds]
arossdotme has joined #linux-sunxi
<wens> stumped on psci c version :/
<wens> my psci_arch_init disassembled looks almost exactly like the assembly version
<wens> differences are only how addresses are calculated, and which scratch registers are used
<wens> r2, r3, r4 in my version vs r4, r5, r6 in the orignal
<KotCzarny> wouldnt it be simple to fix then?
<montjoie> hpeter: I will check if I forgot a patch
<hpeter> montjoie: thanks for your help :D
<wens> KotCzarny: afaik you can't tell the compiler which registers to use for intermediate values
<KotCzarny> hrm
<KotCzarny> optimizations ahoy?
<wens> and i don't know if there are any constrainst on which registers can be used in the call path for psci
<wens> and there's no stack available for that particular call
JohnDoe_71Rus has joined #linux-sunxi
<KotCzarny> time for inline assembly?
Tusker has joined #linux-sunxi
jernej has quit [Ping timeout: 244 seconds]
lemonzest has quit [Quit: Leaving]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<wens> KotCzarny: the whole point is to move away from assembly unless needed :)
dgilmore has joined #linux-sunxi
leio has quit [Ping timeout: 252 seconds]
reinforce has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
<wens> maz: any ideas?
avph has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
tipo has quit [Ping timeout: 276 seconds]
tipo has joined #linux-sunxi
fl_0 has joined #linux-sunxi
leio has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
Tusker has quit [Quit: Time wasted on IRC: 1 hour 8 minutes 17 seconds]
massi_ has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<agraf> ssvb: I don't think so - try https://csgraf.de/agraf/pine64/ for now
IgorPec has joined #linux-sunxi
premoboss has joined #linux-sunxi
orly_owl has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
apritzel has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
<maz> wens: where is the code?
apritzel has quit [Ping timeout: 244 seconds]
codekipper has joined #linux-sunxi
<codekipper> hpeter: I think this patch is missing https://patchwork.ozlabs.org/patch/605915/
bamvor__ has joined #linux-sunxi
bamvor has quit [Ping timeout: 244 seconds]
bamvor__ is now known as bamvor
<jelle> oh nice
<jelle> didn't see this patch in linux-sunxi
<jelle> oh missed it ;-)
<hpeter> codekipper: thanks , I'll try it later
<codekipper> I hit the same problem yesterday...I'll apply it later
apritzel has joined #linux-sunxi
<montjoie> hpeter: I forgot a patch on my github, I will update it soon
<hpeter> montjoie: thanks :D
<montjoie> hpeter: solved
caog has joined #linux-sunxi
oliv3r has quit [Remote host closed the connection]
<maz> wens: if that's called from assembly, you need to declare this as asmlinkage.
<maz> also, touching LR and SP from C code is a big no-no.
reinforce has quit [Quit: Leaving.]
codekipper has quit [Ping timeout: 250 seconds]
<maz> and doing a bx from C?
<wens> maz: i should probably just leave psci_arch_init in assembly
<wens> rewriting it in C is an ugly naked function
<maz> wens: well, there is a number of things you can do in C, but you need to put the CPU in a state where it *can* execute normal C code. not hack with ASM directives inside a C function, because the compiler completely looses track of where things are.
<ssvb> agraf: thanks for fixing this webserver
<wens> asmlinkage doesn't seem to mean anything on arm
<agraf> you're welcome :)
<maz> wens: it did at some point.
<wens> maz: yeah, but psci_arch_init's job is to put the CPU in a proper state (setting up the stack and stuff)
<wens> so i guess i'll leave it in assembly
<maz> wens: exactly.
pmattern has joined #linux-sunxi
<apritzel> ssvb: btw: I managed to port your A64 SPL enablement on top of upstream U-Boot, so I can boot this via SPL
<apritzel> ssvb: this is still 32-bit for the time being, but at least we can have the same code base for boot0 and SPL
reinforce has joined #linux-sunxi
<NiteHawk> apritzel: Hi! Thanks for your feedback on "./sunxi-fel ver", could you give "./sunxi-fel -v sid" a try too?
al1o has joined #linux-sunxi
* apritzel is looking for a free USB port ...
* NiteHawk finds USB ports tend not to come for free :D
vickycq has quit [Ping timeout: 244 seconds]
<KotCzarny> nitehawk, unless you are good at scavenging usb hubs
<apritzel> NiteHawk: no idea if that makes sense, but it gives me:
<apritzel> SID key (e-fuses) at 0x01C14200
<apritzel> 92c000ba 24104620 51900808 14160acb
vickycq has joined #linux-sunxi
* apritzel is replugging the mouse :-D
<NiteHawk> apritzel: thx! we'll have to cross-check that with other A64 users, but at least it doesn't crash the FEL, so the SID address seems to be okay
<NiteHawk> AW seems to have changed the e-fuses content to no longer show the SoC ID - see e.g. tkaiser's H3 results in https://github.com/linux-sunxi/sunxi-tools/issues/37
<hpeter> montjoie: hi, I had tried your sun8i-emac-wip with Orange PI PC (Allwinner H3) with enable CONFIG_SUN8I_EMAC=yy
<hpeter> it'll will meet http://pastebin.com/Kaw7VvHd 1c30000.ethernet: Cannot get TX clock err=-517
<hpeter> after enable CONFIG_CONFIG_SUN8I_H3_EPHY, I can found my eth0
<hpeter> but the right net orange led is disappear, it's seems no phy connection
<ssvb> NiteHawk: oh, the SID value is space separated? hmm, I was almost sure that I have seen ':' as a delimiter in your old patch
<hpeter> how should I do to help to debug?
<NiteHawk> ssvb: if using a "a ? b : c" expression, maybe that misled you? been trying to mimic U-Boot's "md.l" output here...
<NiteHawk> s/if/I'm/
<NiteHawk> of course we're free to choose whatever output format we like
<ssvb> NiteHawk: you are right :-) I was a little bit puzzled about where have I seen ':' before
<ssvb> using '-' or ':' as separators between nibbles is better because the SID value looks like a single identifier then
<ssvb> and is easier to handle in the FEL server code
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<NiteHawk> ssvb: yes, this output might be mistaken for a list otherwise
avph has quit [Ping timeout: 260 seconds]
<NiteHawk> ssvb: if we thing of grepping / partial string matches with a future "--sid <pattern>" option for device selection, would it make sense to do away with the spaces and have a single "word"? tends to make it less readable though
<NiteHawk> *think
<ssvb> the --sid option is imho also better without extra spaces
<ssvb> partial string matches? how is it useful for SID?
avph has joined #linux-sunxi
<NiteHawk> ssvb: dunno, might save you typing ;) just tossing around ideas here. you're right if you consider that "slightly dangerous" (read: error-prone)
tipo has quit [Quit: Leaving]
<montjoie> hpeter: yes you need both EMAC and EPHY
<montjoie> hpeter: could you paste your bootlog ?
al1o has joined #linux-sunxi
<NiteHawk> ssvb: what would be your vote then? "1651664f-80485686-53504848-0702dde9", "1651664f:80485686:53504848:0702dde9" or "1651664f80485686535048480702dde9"
<NiteHawk> i'm leaning towards the colons (:)
al1o has quit [Client Quit]
al1o has joined #linux-sunxi
<hpeter> montjoie: here is bootlog http://pastebin.com/Dr9J0sRp
<hpeter> montjoie: i found a dirty result http://pastebin.com/1G6LxQYg
<hpeter> it's seems we should wait more time for reset complete on Orange PI PC (H3)
<hpeter> after this workaround, i can use the eth0 with your branch
<hpeter> but seems not stable, I'll try it again
<montjoie> thanks hpeter for the timeout, I had a todo to change it to a better function. Just done it with upper delay
<ssvb> NiteHawk: '-' and ':' are both fine for me, the big glued number looks less readable
<hpeter> montjoie: thanks, I'll try how many time should this need to wait
<NiteHawk> ssvb: i'll be changing that to ':' then. if we think of command line usage, '-' tends to be associated with options
<ssvb> NiteHawk: you are right, that's a good point
prasannatsm has joined #linux-sunxi
<hpeter> montjoie: It's horrible, I had tried with 5 times with http://pastebin.com/5gB2sPQV
<hpeter> montjoie: i need retry 14,5,35,14,37 times to wait reset complete
<montjoie> strange
<prasannatsm> git send-email to linux-sunxi@googlegroups.com does not show up in linux-sunxi page. I have tried twice in the past 4 days. Is it a known issue?
<NiteHawk> prasannatsm: worksforme(TM)
afaerber has joined #linux-sunxi
<prasannatsm> wondering how to send my patch
The_Loko has joined #linux-sunxi
<NiteHawk> did you check with "git send-email --dry-run" that everything looks sane? has your (provider's) mail server replied with an "OK" message after sending?
<NiteHawk> ssvb: know anything about the boot_head_sun3i.elf target in the sunxi-tools Makefile? the dependencies listed don't exist - i assume it's supposed to be treated the same as the sun4i and sun5i ones (only with a different MACHID)?
<prasannatsm> yes it did. I have cc'ed myself and got the email myself.
<NiteHawk> prasannatsm: iirc, you mentioned before that a (regular?) email from you didn't go through to the ML?
<prasannatsm> I was asking about the patch email not a regular one.
hpeter has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
ricardocrudo has joined #linux-sunxi
afaerber has quit [Ping timeout: 250 seconds]
<NiteHawk> prasannatsm: i was thinking along the lines of: there might be a general filter / block preventing *any* of your messages?
afaerber has joined #linux-sunxi
<prasannatsm> nope. I tried with the same patch twice.
<topi`> hi. As far as I understood, all the BPi etc. boards use 3.3 volts on the GPIO lines. Then, if I bring in input which is between 0..12 V, how can I make sure the GPIO pins of A20 aren't being fried? Maybe some resistors?
<topi`> if there is some kind of adapter block in Aliexpress, please let me know how it is called :)
<KotCzarny> max232?
<topi`> what about octocouplers? Should they work?
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Amit_T> Is it right branch for pine64 FEL , origin/A64-support ?
<NiteHawk> Amit_T: yes. it's currently not merged into master yet
<Amit_T> NiteHawk: Thanks
<NiteHawk> ask longsleep ;) i currently have no A64 hardware, i'm just involved in maintaining sunxi-tools
<Amit_T> ok, No issues :)
<apritzel> Amit_T: I doubt that this crappy U-Boot tree will work with FEL
<Amit_T> apritzel: ok but then which tree I should look into tree ?
<apritzel> Amit_T: for the time being this one should work: https://github.com/ssvb/u-boot-sunxi/tree/20160126-wip-a64-experimental
<apritzel> yesterday night I ported this over to upstream U-Boot, but haven't pushed the patches yet
<Amit_T> apritzel: Ok Thanks, I would start looking into it.
pitelpan has joined #linux-sunxi
al1o has joined #linux-sunxi
<apritzel> Amit_T: roughly you would do: checkout ssvb's branch, make pine64_plus_defconfig && make (with a 32-bit ARM cross-compiler), sunxi-fel uboot u-boot-sunxi-with-spl.bin
<apritzel> I will document this in more detail later
<Amit_T> ok I need to checkout wip-a64-experimental branch, right ?
<NiteHawk> the branch name is "20160126-wip-a64-experimental"
<apritzel> which is what the link above says ;-)
<Amit_T> Ok got it, Thanks.
azend|vps has quit [Remote host closed the connection]
<Amit_T> apritzel: ok , I need to place "libdram" file in u-boot's root directory before doing "make "
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec2 has quit [Read error: Connection timed out]
IgorPec has joined #linux-sunxi
aballier has quit [Quit: leaving]
aballier has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
reinforce has quit [Quit: Leaving.]
<apritzel> ssvb: Pine64 boot over SPI> nice!
prasannatsm has quit [Quit: Quit]
<apritzel> ssvb: you mentioned issues with SPI on the Pine64 yesterday: were there any real problems or hacks required?
al1o has joined #linux-sunxi
al1o has quit [Client Quit]
merbanan has quit [Ping timeout: 260 seconds]
caog has quit [Quit: Ex-Chat]
<TheLinuxBug> lennyraposo: whats the link to you pine64 image again?
caog has joined #linux-sunxi
<TheLinuxBug> er maybe I was thinking longsleep, anyhow looking for a reasonablly working pie64 image
<TheLinuxBug> any good options out there
leio has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
<tkaiser> TheLinuxBug: Using BSP kernel this is the image of choice: http://forum.pine64.org/showthread.php?tid=376
JohnDoe_71Rus has joined #linux-sunxi
merbanan has joined #linux-sunxi
<TheLinuxBug> tkaiser: thanks
<tkaiser> TheLinuxBug: Longsleep said he provides a new kernel over the weekend so remember to run the update scripts to benefit from latest fixes
leio has joined #linux-sunxi
<tkaiser> longsleep: Are you around?
merbanan has quit [Ping timeout: 252 seconds]
<apritzel> tkaiser: smells like Brückentag ;-)
<tkaiser> apritzel: Longsleep 'promised' to drive into office today to test 4K displays ;)
<apritzel> tkaiser: so maybe he's got a sunburn from the awesome picture quality ;-)
<tkaiser> apritzel: Yeah, or already on his way back to beergarden where the real development happens. BTW: Just remembered my first time travelling to spain and experiencing an 'Acueducto'. Two BrŸckentage in one week and no one went to work.
stasiic has joined #linux-sunxi
<ssvb> NiteHawk: I don't know anything about boot_head_sun3i.elf, git blame would probably point to somebody who knows more
<ssvb> apritzel: I just moved back to Pine64 from Orange Pi PC after cleaning up the code a bit and the SPI boot worked
<NiteHawk> ssvb: yeah, i've checked that - and it looks like that rule was b0rken right from hno's inital commit - so i've simply adjusted it to the sun4i and sun5i templates
<apritzel> ssvb: thanks!
benjamin_ has joined #linux-sunxi
<stasiic> hello! I have a Denver Tac android table, which I believe uses Allwinner A10, and I want to be able to tinker with it. Is this the right place for getting help and exchanging ideas? :)
IgorPec has quit [Ping timeout: 265 seconds]
stasiic has quit [Quit: leaving]
stasiic has joined #linux-sunxi
reev has quit [Ping timeout: 265 seconds]
<stasiic> woops... accidentally dropped out for a second :(
premoboss has quit [Quit: Sto andando via]
nove has joined #linux-sunxi
<ssvb> apritzel: not sure what exactly fixed it, I initially suspected that the internal clock speed of the SPI hardware block may be somehow responsible, but now trying to set high divisors does not really break it
<NiteHawk> ssvb: that SPI emulator of yours seems pretty neat :D
<ssvb> apritzel: so it was a cargo cult / snake oil all along, and in the SPI slave mode the SPI is clocked by the other end
benjamin_ has quit [Ping timeout: 246 seconds]
<ssvb> apritzel: must have been some other bug in the code, or maybe a problem with jumper wires connection
diego_ has quit [Quit: Konversation terminated!]
diego_r has joined #linux-sunxi
diego_r has quit [Client Quit]
diego_r has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<ssvb> maybe we can add a simple SPI driver to the sunxi-fel tool, I'll try to hack something like this :-)
benjamin_ has joined #linux-sunxi
<ssvb> as a bonus, it is also possible to connect the reset pin and control it too
diego_r has quit [Client Quit]
diego_r has joined #linux-sunxi
benjamin_ has quit [Ping timeout: 244 seconds]
<apritzel> ssvb: does U-Boot support (sunxi) SPI flash?
<ssvb> apritzel: not yet, but this should be relatively simple to implement
* apritzel wonders if we could put at least the EFI variables and/or the U-Boot environment on this
<apritzel> as the boot priority spoils this have-firmware-on-SPI-flash dream :-(
<apritzel> we could only put some check-for-SPI-flash code into the SD-card SPL
<ssvb> still we can just use GPT partitioned SD cards without any bootloader on them and have such SD cards recognized by the firmware
<NiteHawk> shouldn't it be possible to work around the SDcard priority by simply having no valid boot0 boot signature (at 8k)?
<ssvb> NiteHawk: exactly
<ssvb> apritzel: there is no security in such setup, because any bad guy can create a bootable SD card with GNU/Linux or Allwinner's Android and easily take over the hardware
p1u3sch1 has quit [Ping timeout: 252 seconds]
<apritzel> security? dev boards? Allwinner? -ENOPARSE ;-)
<apritzel> security in the sense of preventing someone from booting their own stuff on a dev-board style device is frankly my least concern
<ssvb> from this point of view, the current boot priority is just fine
oliv3r has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
<apritzel> I was thinking about using the SPI flash as some kind of "on-board" BIOS thing, which at least brings up the board to some usable state
<apritzel> can the boot priority be influenced by pins? So other _board vendors_ could fix this?
<ssvb> some other Allwinner SoCs had extra pins to control boot priority, but A64 is not one of them
FlorianH has quit [Ping timeout: 250 seconds]
<apritzel> too bad
<ssvb> the firmware in the SPI flash can boot any kind of "industry standards" compliant system that you want from the SD card, as long as it is not a legacy-bootable SD card with the SPL/boot0 at 8K
<apritzel> that sounds reasonable
<apritzel> after all it's still a dev board style device
<ssvb> and a bootable SD card with the SPL/boot0 at 8K can be used for unbricking the device
<agraf> so what does the separate spi buy you then?
<agraf> you can use a generic image, yes
<agraf> but as a user, what's the benefit? :)
<agraf> or is this about automated testing?
<apritzel> to have a board agnostic image?
<ssvb> agraf: well, aren't you now questioning the whole purpose of the EFI? ;-)
<agraf> so the problem is https://xkcd.com/927/
<apritzel> and not requiring the firmware to be on the only reasonable mass storage device
<agraf> we can't demand users to buy a spi flash expansion card ;)
<agraf> so if a distro wants to have users, they need to provide a specialized image either way
<agraf> at which point the separate spi flash doesn't really buy you too much anymore, since you don't reduce the amount of work for people - there will still be specialized images
<ssvb> or the users can just buy a new revision of the dev board with SPI flash already included
<agraf> oh, sure, that case works great
<agraf> so if the pine65 has a 4MB SPI flash, we're all set
<agraf> or 2MB
<agraf> or whatever, doesn't have to be big
<apritzel> I guess 4Mbit would suffice
<agraf> then we could even make it SBBR compliant I guess
<apritzel> who sets up the kickstarter for this? ;-)
<agraf> but for the pine64, there's no big incentive to use a separate spi flash for booting :)
<apritzel> Olimex, are you listening?
<apritzel> agraf: but it's just cool
<agraf> oh, of course
<agraf> ssvb: so how fast can you drive the spi slave emulation?
<agraf> ssvb: one project on my big pile of todos is an mmc emulation layer
<agraf> ssvb: to fully model an SD card in software
<agraf> ssvb: for automated testing of SD images for various boards
<ssvb> agraf: it's not a real emulation, I'm just constructing the output based on the expected input but not handling real requests
<agraf> ssvb: so far I was thinking bbb and PRUs, but if the native spi slave hardware is fast enough to get me reasonable bandwidth, i guess single spi is good enough for now
<ssvb> and can detect unexpected input and complain after the fact
<agraf> ssvb: sure, but that's a software problem ;)
<agraf> ssvb: but how fast is the interconnect between the cpu and your spi controller? can that handle 50mbit/s?
<agraf> or was it 25?
<agraf> i think it's only 50Mhz
<ssvb> GPIO bit-banging can only handle a couple of MHz at most
<agraf> also for this I'd need a multi-core system, to have one dedicated core for the SD emulation
<ssvb> and for SPI flash emulation we are receiving the read command and the address, and then need to adjust the output very fast
<agraf> for SPI flash, yes, for SD emulation not IIRC
<agraf> you can always return "sorry, I'm busy"
<agraf> so you need to reply fast, but you don't need the data fast
<ssvb> the lowest 8-bit part of the address can be assumed to be always 0 in the SPI Flash emulation implementation and ignored, this gives us 1 byte gap
vagrantc has joined #linux-sunxi
premoboss has joined #linux-sunxi
<ssvb> but this gap is still insufficient, the TX buffer still underflows and we fail to do proper communication in time
<apritzel> agraf: btw: I was wondering if we could use the OpenRISC as some kind of PRU for the Pine64
<agraf> apritzel: well the really cool part about the PRU is that it only needs 1 clock cycle for GPIO access
<agraf> apritzel: I don't think the OpenRISC can get anywhere near that?
<ssvb> the "READ DATA BYTES at HIGHER SPEED" command has 1 byte padding before reading the response, and this is a bit easier to emulate
<apritzel> agraf: not sure about the access latency, but at least it's a separate entity which could run a real RTOS
<ssvb> agraf: we can surely try to measure the GPIO speed on OpenRISC
<agraf> apritzel: you could easily cut off one of the arm cores for that too if you wanted
<apritzel> agraf: but people paid for four of them
<agraf> apritzel: yeah, and they need 1 ;)
tomboy65 has joined #linux-sunxi
<agraf> apritzel: just get jailhouse working on the pine64 and you have your average realtime workloads covered
<agraf> ssvb: would be great if you could :)
* apritzel turns around to Jean-Philippe ;-)
<apritzel> agraf: do you know about the state of AArch64 support in Jailhouse?
<agraf> apritzel: I know that huawei was working on it
<agraf> apritzel: the biggest problem with the a64 is the lack of an iommu
<agraf> apritzel: or at least i haven't seen any :)
tomboy64 has quit [Ping timeout: 244 seconds]
<agraf> apritzel: so you don't get full isolation
<agraf> either way, bbl
<apritzel> just asked JPB: it's looking good, Huawei is on the right track, so aarch64 support should be merged sooner or later
<apritzel> I wonder if someone is making a _real_ case for the Pine64: with a reset and power button, RTC battery holder, power LED, wireless antenna and SPI flash
* vagrantc apparently made the mistake of ordering pine64 with cases
p1u3sch1 has quit [Ping timeout: 260 seconds]
<apritzel> vagrantc: in terms of: delivery is delayed?
<vagrantc> apritzel: i *think* so ... though it's honestly hard to know for sure
* vagrantc hasn't really been able to parse some of these emails about delays
p1u3sch1 has joined #linux-sunxi
hrw has quit [Read error: Connection reset by peer]
hrw has joined #linux-sunxi
<vagrantc> oh nice, pine64 in mainline u-boot.
zuikis has joined #linux-sunxi
jernej has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
jelle has quit [Ping timeout: 264 seconds]
LostSoul has quit [Ping timeout: 250 seconds]
LostSoul has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
Amit_t_ has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
diego_r has quit [Quit: Konversation terminated!]
staplr has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
premoboss has quit [Quit: Sto andando via]
<longsleep> tkaiser: any particular reason why mikhail stopped at 3.10.75?
<longsleep> tkaiser: did he got stuck or felt that .75 is fresh enough?
avph has joined #linux-sunxi
fl_0 has quit [Ping timeout: 250 seconds]
<longsleep> tkaiser: i can also remove the custom name from the repository if people do not like it - i just added it there so i do not forget it when building :)
fl_0 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
caog has quit [Ping timeout: 246 seconds]
pmattern has quit [Quit: Genug für heute.]
robogoat has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 244 seconds]
Amit_t_ has quit [Quit: Page closed]
azend|vps has joined #linux-sunxi
Netlynx has joined #linux-sunxi
dlan has quit [Ping timeout: 276 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
matthias_bgg has quit [Ping timeout: 260 seconds]
<lennyraposo> hey longsleep
<longsleep> si si
<lennyraposo> I remember
<lennyraposo> why debian didn't get fbturbo
<lennyraposo> one dependency that needs upgrading
<lennyraposo> libvdpau is less than 1.1
<lennyraposo> ;)
vagrantc has quit [Quit: leaving]
<lennyraposo> but the image will be released with all the trimmings this time around
<lennyraposo> not fbturbo
<lennyraposo> but vdpau
afaerber has quit [Quit: Ex-Chat]
robogoat has joined #linux-sunxi
al1o has joined #linux-sunxi
massi_ has quit [Quit: Leaving]
ricardocrudo has quit [Remote host closed the connection]
kelvan has quit [Remote host closed the connection]
azend|vps has quit [Remote host closed the connection]
al1o has quit [Quit: Textual IRC Client: www.textualapp.com]
IgorPec has quit [Ping timeout: 260 seconds]
al1o has joined #linux-sunxi
hrw has quit []
azend|vps has joined #linux-sunxi
jernej has quit [Quit: Konversation terminated!]
azend|vps has quit [Read error: Connection reset by peer]
<lennyraposo> backports took care of everything for dependencies
<lennyraposo> all
<lennyraposo> updates completed
paulk-aldrin has joined #linux-sunxi
jernej has joined #linux-sunxi
kelvan has joined #linux-sunxi
<lennyraposo> longsleep
<lennyraposo> I will be testing your display tool tonight
<lennyraposo> wanted to ask are we able to set display from uEnv.txt too?
<longsleep> lennyraposo: great, i just finished it up and prepare a release through ppa now
<lennyraposo> nice
<longsleep> lennyraposo: yes, just add optargs=disp.screen0_output_mode=720p60
<longsleep> or similar
<longsleep> to uEnv.txt
<lennyraposo> groovy
<lennyraposo> gotta test kodi on these images tonight before release
<lennyraposo> oh and I ahve been adding your latest to the downloads at pine64.pro
<longsleep> will not work at all as no egl
<longsleep> hopefully with the same names and signature this time?
<lennyraposo> starting this week they will be
<lennyraposo> wanna set it up so you can access and make the changes when oyu want to ;)
<lennyraposo> the infrastructure is there
Amit_t_ has joined #linux-sunxi
Nacho has joined #linux-sunxi
Amit_t_ has quit [Client Quit]
Nacho__ has quit [Ping timeout: 246 seconds]
<longsleep> lennyraposo: nah, i have everthing in place with minimal effort and i will not duplicate my stuff anyplace else
<lennyraposo> I will maintain it here as back up
<lennyraposo> I will also write up update articles
<lennyraposo> on each release
<longsleep> lennyraposo: you could setup an automated mirror like that Japanese guy did and i add it to the mirrors.txt
<lennyraposo> sure thing
<lennyraposo> I will setup this weekend then :D
<longsleep> all right, launchpad built the sunix-disp-tool, if anyone cares to test early https://launchpad.net/~longsleep/+archive/ubuntu/ubuntu-pine64-flavour-makers/+build/9701223
<longsleep> as always, feedback welcome https://github.com/longsleep/sunxi-disp-tool - just released version 0.0.1
<lennyraposo> btw a user yesterday reported 900mbit transfer rate on a 2gb pine
<lennyraposo> it's definitely an equipment issue with others
<lennyraposo> I will be able to confirm as I have various switches routers I cna test against
<lennyraposo> dlink, linksys, netgear,belkin,tplink,cisco,trendnet
<lennyraposo> even have a few things from juniper
<lennyraposo> can definitely round out the typical household device items
<lennyraposo> btw
<lennyraposo> nm
<longsleep> lennyraposo: yeah its easily doable to max out a 1000M link with the proper settings and equip
<lennyraposo> I know it is
<lennyraposo> with the 1gb model I get around 800mbits
<lennyraposo> and my network is always busy
jelle has joined #linux-sunxi
<longsleep> mhm should be no difference between 2gb and 1gb model
<jelle> did anyone ever get francios's sunxi hdmi driver working?
<jelle> It worked so far as loading the module and reading EDID, but it seems to set the wrong resolution
<lennyraposo> which baord?
<lennyraposo> board*
<jelle> lennyraposo: h3
<lennyraposo> dunno
<jelle> guess I'll have to mail him
<jelle> only seen the BSP working
<jelle> this is the latest H3_SDK_20150601_lichee bsp right?
<jelle> arggh guess I'll compile it and debug that driver
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
<lvrp16> any1 here need a 2gb pine?
<lvrp16> i have around 30
<longsleep> lol
<lvrp16> they only shipped 33/100
<lennyraposo> you have 33 2gb pines?
<lvrp16> yes
<jelle> anyone has a clue here http://dpaste.com/1W4ZJYP ?
<lvrp16> received them yesterday
paulk-collins has joined #linux-sunxi
<lennyraposo> seems liek the hdmi driver no worky
<lennyraposo> did you email about it?
paulk-aldrin has quit [Remote host closed the connection]
<jelle> lennyraposo: going too
<jelle> lennyraposo: what happens in dmesg?
<jelle> my monitor just says "invalid range" or something
<jelle> seems there is a new version
<lennyraposo> what res is your display?
<jelle> 1080p ehh 1920x1080
<jelle> going to try his new version
<jelle> lennyraposo: I guess you tried the latest and also with his kernel?
<jelle> since you need the sunxi-hdmi.ko and then kernel drive
<jelle> *driver
pmattern has joined #linux-sunxi
<lennyraposo> me?
<jelle> seems I need a new kernel..
<lennyraposo> nope
<jelle> [ 99.709616] sunxi_de2_hdmi: Unknown symbol de2_hdmi_codec_unregister (err 0)
<lennyraposo> no h3 here
<jelle> aahh
<lennyraposo> pine64 thus far ;)
<jelle> this driver should be portable to pine64 so I've heard
<jelle> anyway time to bake a new kernel
* jelle hopes the new version works, that makes it easier to get a working u-boot one
hrw has joined #linux-sunxi
<lennyraposo> hey longsleep are you opposed to a first run script for pine images
<lennyraposo> something that will check and fetch if necessary udpate then resize
<lennyraposo> lot of people still forget to resize the rootfs
<lennyraposo> I will write it ;)
staplr has quit [Ping timeout: 250 seconds]
ricardocrudo has joined #linux-sunxi
afaerber has joined #linux-sunxi
jernej has quit [Ping timeout: 265 seconds]
azend|vps has joined #linux-sunxi
azend|vps has quit [Remote host closed the connection]
staplr has joined #linux-sunxi
lerc has quit [Quit: No Ping reply in 180 seconds.]
lerc has joined #linux-sunxi
nove has quit [Quit: nove]
<KotCzarny> hmm, is bpi-r1 'switch' supported in mainline?
apritzel has joined #linux-sunxi
azend|vps has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
azend|vps has quit [Ping timeout: 252 seconds]
<lennyraposo> hey longsleep
<jelle> hrrrm
azend|vps has joined #linux-sunxi
<lennyraposo> lol
staplr has quit [Remote host closed the connection]
<lennyraposo> she works
<lennyraposo> windowed mode ;)
<jelle> lennyraposo: nice
<lennyraposo> now if we had the binaries from allwinner then I can do more
<lennyraposo> :)
<jelle> lennyraposo: binaries for?
<lennyraposo> for the mali 400
<lennyraposo> aarch64
<jelle> ohh
azend|vps has quit [Remote host closed the connection]
pmattern has quit [Quit: Genug für heute.]
zuikis has left #linux-sunxi [#linux-sunxi]
<jelle> hmm can't get it working
<lennyraposo> get what working?
<jelle> lennyraposo: h3 hdmi driver
<lennyraposo> wish I knew a bit more about it
<lennyraposo> been learnign for a month and half
<jelle> :-)
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
nashpa has quit [Quit: Going away]
nashpa has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]