Turl changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
<mnemoc> probably the simplest way will be just extend fexc
<mnemoc> oliv3r: but feel free to backport the rest of sunxi-next, I'll test it :p
cajg has quit [Read error: Operation timed out]
<oliv3r> mnemoc: i'll try to work on that; but this month will be fully devoted to playthings (RE BROM for fun) fosdem slides; book
<oliv3r> and that pesky $work$ thing
ganbold has joined #linux-sunxi
<oliv3r> mnemoc: anyway, talk to mripard about bablefish :)
<mnemoc> any url to a related post?
n01 has joined #linux-sunxi
<mrnuke> oliv3r: Hi. Did you guys ever have issues on the cubieboard where raminit worked, but trying to read from it hung the CPU?
<oliv3r> mnemoc: don't wanna ruin his moment/announcement, but it IS publically on github: https://github.com/mripard/sunxi-babelfish
<oliv3r> mrnuke: you mean you init it properly, it runs, until you read from it?
<oliv3r> mrnuke: not really, as one of the first things after init we do, is load u-boot into it
<mrnuke> oliv3r: dramc_init() returns fine, I can write to the SDRAM, but when I try to read from it, it hangs
cajg has joined #linux-sunxi
<oliv3r> that's odd, but since you can't verify what you wrote, it may not work at all :p
<mnemoc> uhm... so mainline is ioremap()ing each resource independently
<mnemoc> oliv3r: thanks for the point, gladly it's a completely different approach :)
<mnemoc> s/point/pointer/
<oliv3r> mnemoc: yeah mainline does it quite differently
<oliv3r> but more sensibly
<oliv3r> clocks are handled by the clock framework; you request one from the clock framework; and don't just do everything in your own little driver
<mrnuke> oliv3r: if I don't run dramc_init(), then it hangs when attempting to write to the RAM. Run it, and I can write fine, just can't read it
<oliv3r> did you copy our entire dram.c and use it 'as is'?
<mrnuke> yeah, pretty much as is
<oliv3r> :(
<mnemoc> oliv3r: one used to be very conservative regarding the number of ioremap'ed blocks.... now they ioremap each register separatedly
<oliv3r> well the dramc code is very very fidgidy
<oliv3r> curse the lack of documentation :::(
<oliv3r> mnemoc: who maps each register seperatedly?
<mrnuke> well, to be honest, i delayed asking this for a few days until I got the AXP109 up and running, to make sure it's not a power issue
<oliv3r> mnemoc: the way it SHOULD be done, is you define your whole block in the DT, and map the whole thing
<mnemoc> oliv3r: of_iomap()
<mnemoc> taking the reboot code as reference
<mnemoc> but it might be an old implementation.... after all it's 3.10
<oliv3r> mrnuke: assuming your dramc_init() is doing exactly the same thing, you might be missing a clock somewhere, as those are setup outside of dramc (well they might, not 100% sure)
<oliv3r> mnemoc: ah, reboot code is ugly, it uses the watchdog timer to do a reset
<mnemoc> sure, and accessing the watchdog registry, which is mostly the same thing I want to do with soc-detect
<oliv3r> mnemoc: but the watchdog is implemented in the wdt framework; however it doesn't have its own set of registers, it is part of the timer block
<mrnuke> oliv3r: AXI SDRAM clock.. Is that relevant? (although ungating it does not help)
<oliv3r> mrnuke: i do not recall; but it does sound like it yes
<oliv3r> mrnuke: i recall some other bootloader also working on sunxi stuff
<mrnuke> there's an SDRAM clock on AHB, and one on AXI. dramc_init ungates the one on AHB, but I haven't seen the AXI one touched anywhere
<oliv3r> also there's MBUS
paulk-collins has quit [Remote host closed the connection]
<mrnuke> yeah, that seems to be the actual, physical memory bus
<oliv3r> we can tune it on a13 and a20
<oliv3r> a10 the registers are ignored
n01 has quit [Ping timeout: 272 seconds]
<oliv3r> mrnuke: bed time now though :(
<mrnuke> oliv3r: gn8
<mrnuke> thanks for the info
<oliv3r> mrnuke: sorry i can't help you more yet :(
<oliv3r> mrnuke: if i have more time next week; i'll diginto it a little more
<mrnuke> sounds good. Just get your share of alcohol, tobacco, and firecrackers tommorow
<oliv3r> mrnuke: barebox! i think they started it
<oliv3r> so maybe some inspiration from there
<oliv3r> anywa,y nn :) and thanks
Black_Horseman has quit [Ping timeout: 248 seconds]
<mnemoc> [ 0.000000] sunxi: Allwinner AW0 detected lovely.... but better than a panic
Black_Horseman has joined #linux-sunxi
<mnemoc> [ 0.000000] sunxi: Allwinner AW1651 detected
<mnemoc> :)
ZetaNeta has quit [Ping timeout: 240 seconds]
ZetaNeta has joined #linux-sunxi
<andhe> where can I get the cubietruck wifi firmware?
ZetaNeta has quit [Ping timeout: 272 seconds]
<keebler> Did some math, to get 3Mhs in Litecoin Mining from an Allwinner A20 ARM CPU, you'd need to buy 2500 cards, at $50 a piece, that's $125,000
<spv> I was under the impression that Litecoin mining was already unprofitable at the GPU level. Is that true?
hero100 has joined #linux-sunxi
<keebler> Yes. Unless you have $10K to drop on hardware.... however, it's quite profitable mining Dogecoin atm and converting it to btc
<keebler> mined .15btc ($90) in 4 days.
<keebler> Dropped quite a bit though.
bamvor_ has quit [Quit: Leaving]
bamvor has joined #linux-sunxi
<keebler> only doing 9K dogecoin a day now, and the price of dogecoin has dropped since I started. (although still higher than some swings), anyway, only mentioned it since this is a sunxi channel and I was trying to see (as an exercise in mental curiosity), what it would take to get the EOMA or Olimex cards mining altcoins.
<keebler> TL:DR, it's completely pointless.
kivutar has quit [Quit: Ex-Chat]
<spv> Were you including the Mali GPU?
<buZz> hahaha bitcoins
<buZz> mali gpu doesnt do opencl , sadly
<buZz> and mine :)
passat has joined #linux-sunxi
<hero100> cool but not beautiful
FR^2 has quit [Quit: und weg...]
<mnemoc> 3.4? I thought they were using 3.8 for those new chips
<wens> I only looked at the front of the SDK... not enough disk space left on my VM :p
hero100 has quit [Read error: Connection timed out]
<wens> let me look at the file list
passat has quit [Remote host closed the connection]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens> nope, only 3.4
hero100 has joined #linux-sunxi
NightShade has quit [Ping timeout: 252 seconds]
NightShade has joined #linux-sunxi
hero100 has quit [Quit: Leaving]
codyps has quit [Ping timeout: 260 seconds]
codyps has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
<spv> This is going to be a stupid question ... but what endianness are the Cortex-A7s in the A20s?
<HdkR> bi-endian
<HdkR> Starts out in regular little-endian
<HdkR> Same as most things
<mrnuke> hold on. You can set an A7 to big-endian?
<HdkR> Rest of the SoC probably doesn't support running the entire system as bi-endian
<HdkR> It's just a feature of ARMv7 to be able to switch endian-ness on the fly
<mrnuke> on the fly? that sounds handy. Is it a mandatory or optional feature? (I know the Cortex-M has it optional)
<HdkR> I'd have to read the specs again. I think everything supports it
<spv> Thanks for the info!
<mrnuke> it would be interesting to hijack and application and silently change the endianess
<mrnuke> actually, it's a great way to test cross-platform code
<spv> Is there an Armv7 handbook somewhere that includes information on how to do inter-processor interrupts or communication or somesuch?
<spv> Looking for info for making smp handlers.
FDCX has quit [Remote host closed the connection]
<HdkR> spv: Look at the arm architecture reference manual for ARMv7-a/r
<HdkR> mrnuke: That would only work for code that supports switching endianness at any time. Which nobody does
FDCX has joined #linux-sunxi
<HdkR> It's always going to be compile time differences :P
<mrnuke> HdkR: u32 val32 = mem[0] | mem[1] << 8 | mem [2] <<16 | mem[3] << 24; // Read LE 32-bit value
<mrnuke> I do that in my programs when reading from streams
<HdkR> Sure, that's a simple bswap32
FDCX has quit [Remote host closed the connection]
<mrnuke> I guess if the compiler optimizes that, you're SOL
<HdkR> but if one just swapped the endianness just prior to reading a u32 it would be broken
<HdkR> Yea, no compiler would be in their right mind to support something that crazy
<mrnuke> oliv3r: I don't know if you read backlogs, but I managed to get ram functioning by dialing down the clock. No idea why it works, but it works
tomboy64 has quit [Ping timeout: 252 seconds]
<spv> getting ram functioning sounds important. How far did you get into boot beforehand?
<spv> Do Cubie* boards simply choose random MAC addresses?
<spv> Running the android BSP seems to result in random MAC addresses
<spv> (or whatever was default-installed)
tomboy64 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 248 seconds]
<mrnuke> spv: I'm porting coreboot to the cubieboard, so I only had a nice shiny console that told me ram init failed :p
<spv> I feel like I must misunderstand coreboot. My current understanding is that coreboot is a replacement for BIOS on x86 machines.
<spv> *must be misunderstanding
<spv> What is it actually? A really fast bootloader?
<mrnuke> nope. coreboot is just the core boot code. BIOS, or EFI, or whatever (you can boot straight to linux) comes afterward
<spv> So is the boot ROM on AW parts actually writeable?
<wens> nope
<spv> Then where's coreboot going?
<spv> Replacement for U-boot?
<mrnuke> nope. I hijack the BOOT0 stage, and take control of the system at that point
<mrnuke> chromebooks use coreboot to initialize the hardware, then use uboot as a payload, and uboot loads the OS from that point
<spv> I thought we already ported hardware initialization to the SPL in U-boot ...
<mrnuke> well, coreboot is like the SPL
<spv> kk
<mrnuke> then you can load SeaBIOS to get a BIOS from the machine, load linux directly, load tianocore to get EFI, etc
<mrnuke> some people load GRUB2, and use that to further load the kernel. It's pretty fast
<spv> I see large advantages here if the loaders support SATA.
<spv> the bios / tianocore / grub2 parts
<mrnuke> on x86, SATA is pretty standardized via PCI, but on ARM, you most likely need device-specific drivers
<mrnuke> but hey, on ARM, you got SRAM from the start, so you can start your bootblock with a stack and all the bells and whistles
<mrnuke> on x86, you have to ask the CPU to switch some of it's cache to behave as RAM (cahse-as-ram), and you need to do all that in assembly
<mrnuke> and you also need to make sure you use very little of that cache, since the cache eviction mechanisms are still enabled
<spv> I recently dealt with writing a new loader for a PPC board. Having locked cache entries to act as pretend sram was awesome.
<mrnuke> it's a pretty neat trick indeed
wingrime has joined #linux-sunxi
<spv> It also showed how unreliable DDR3 controllers are.
<spv> you can't turn them off.
<mrnuke> what did you expect? perfect bug-free silicon?
<spv> I expected a reset routine
<spv> that wasn't "remove power for a few seconds"
<mrnuke> why do you think USB3 controllers need firmware?
hero100 has joined #linux-sunxi
<spv> yes yes because having firmware means you can dynamically change chips to fix stuff
<spv> it's software
<spv> speaking of these firmwares, someday I want to spend some time and find a few of the NSA backdoors in hard drives, BIOSes, etc.
<mrnuke> have you heard of Intel Mangement Engine?
<spv> Isn't that the feature that prevents inspection of memory, for use for DRM?
<spv> best way to hide malware ever.
<mrnuke> Intel southbridges contain an ARC code. it runs out-of-band with the OS, survives system resets, can emulate virtual PCI devices, has full DMA access to memory, and
<mrnuke> ready for this?
<mrnuke> It has access to the network adapter(s) in a way that is completely transparent to the OS, including different MAC and IP
<spv> And that would be where to look first.
<spv> But it's not modifiable, is it?
<spv> (the code)
<mrnuke> it's cryptographically signed, but the pubkey is in the firmware package
<mrnuke> it's unclear if one can replace it with their pubkey and run modified firmware
<mrnuke> but it is updateable
<spv> mrnuke: that is seriously cool
<mrnuke> the logo?
<spv> no, the fact that this group exists
<mrnuke> oh come on. you gotta give those guys some credit for the logo
<mrnuke> :p
<spv> true
<spv> I feel like there must be something wrong with that new_year jpg.
<mrnuke> the monitors are chinese fakes?
<spv> hmm
ganbold_ has joined #linux-sunxi
diego71 has quit [Ping timeout: 272 seconds]
Quarx has joined #linux-sunxi
deasy has joined #linux-sunxi
wolfy has joined #linux-sunxi
diego71 has joined #linux-sunxi
<wingrime> oliv3r: whats up with a23 userman
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
panda84kde has joined #linux-sunxi
_massi_ has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
n01 has joined #linux-sunxi
shineworld has joined #linux-sunxi
hero100 has quit [Quit: Leaving]
naobsd has quit [Ping timeout: 272 seconds]
wolfy has quit [Ping timeout: 252 seconds]
pacopad_ has joined #linux-sunxi
<eagles0513875> hey all
<eagles0513875> oliv3r: ping
pacopad has quit [Ping timeout: 246 seconds]
pacopad_ is now known as pacopad
Black_Horseman has quit [Ping timeout: 272 seconds]
<oliv3r> mnemoc: grats!
naobsd has joined #linux-sunxi
<oliv3r> mrnuke: that's odd most cubies should run at 520 MHz even (not 100% reliably)
<oliv3r> gzamboni: said something abbout 3.8; maybe we misunderstood it? http://irclog.whitequark.org/linux-sunxi/2013-12-27#5990751
<shineworld> I don't know but my N4 4.4.2 stock is using 3.4.0
<shineworld> ah A31....
<oliv3r> mrnuke: speaking of boot0 and hijacking, when you boot from boot0/boot1, you can send a 2 i thinkt o go into fel mode; you can then upload code with the dram actually allready initialized
<oliv3r> mrnuke: you can use that to compare what you have or have not set
penghb has quit [Quit: Leaving.]
<eagles0513875> oliv3r: hey do you know what revision i need for build root where mmc was implemented?
<eagles0513875> i think i have the wrong revision set in build root
<oliv3r> wingrime: we don't have it :)
<oliv3r> eagles0513875: never used buildroot; but isn't hte kernel that uses mmc? so swap out kernel
<eagles0513875> im not sure if that mmc stuff was sent upstream
<oliv3r> eagles0513875: 3.0 and 3.4 from our repo's all do mmc without problem
<eagles0513875> oliv3r: is hans in here or does he just use the mailing list?
<oliv3r> oh no, you there is no mailnine mmc yet
<oliv3r> he's here sometimes
<oliv3r> but mainline doesn't do mmc
<eagles0513875> oliv3r: where was that mmc stuff on the list pushed to?
<oliv3r> eagles0513875: i think sunxi-next should have it
<eagles0513875> oliv3r: ok
<eagles0513875> you have a link to the repo if you dont mind please
<oliv3r> now your just being lazy :p
<NightShade> sunxi-devel in the main sunxi git tree has the most upto date tree
<oliv3r> there
<oliv3r> :)
vector80 has joined #linux-sunxi
<oliv3r> gitorious down?
<vector80> hi oliv3r
<oliv3r> vector80: hi
<gzamboni> oliv3r, i said android 4.4 (kitkat) is based on kernel 3.8, so probably the AW sdk 4.4 is based on 3.8.
<vector80> I have compiled the sunxi BSP
<oliv3r> gzamboni: ahh you made assumptions! :p
<vector80> I compiled uboot and kernel
<oliv3r> gzamboni: well good though that they are still on 3.4 then :)
<oliv3r> vector80: very cool
<vector80> but when I compile kernel, I can't find uImage file
<vector80> as I know, it must be under arch/arm/boot
<vector80> am I wrong ?
<oliv3r> if you compile withthe bsp; check sunxi-bsp/build/sun7i_defconfig/
<oliv3r> vector80: you are right but also wrong
<oliv3r> vector80: one of the nice things is, it builds everything with make O=sunxi-bsp/dir
<oliv3r> meaning all compiled object files etc and resulting binaries end up in sunxi-bsp/
<oliv3r> this means, you don't ever have to do make in a tree, you can simply rm -r build and everything compiled is gone
<oliv3r> but all source is always untouched
<vector80> waww, cool
<vector80> I have seen uImage file there
<oliv3r> of course you can still do cd linux-sunxi; make clean O=/sunxi-bsp/sun7i_defconfig/
<oliv3r> even the bsp supports some basic cleaning
<vector80> So, I must copy u-boot-sunxi-with-spl.bin file to my eMMC first, right?
<vector80> Just to make sure if it is working fine or not?
<oliv3r> it should be working fine, you can always test it i guess :)
<oliv3r> but yeah, that file you need to store somewhere, as you will have to do dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblkemmc
<oliv3r> then run a script to create partitions
<oliv3r> format them; copy files
<oliv3r> but that script is your job :p
<oliv3r> but that shouldn't be hard :)
<vector80> ok cool
<vector80> I will try one by one
<vector80> 1- uboot
<vector80> 2) umage and modules
<vector80> oh, where are the modules..
<vector80> let me find
<oliv3r> vector80: if you do 'make' in the bsp, you get a 'hwpack' in the build dir
<oliv3r> try that; just run 'make'
<oliv3r> and explore the hwpack.zip
<oliv3r> you should find it interesting :)
<vector80> ok let me try
<gzamboni> yeah, sorry, i read somewhere android 4.4 would be based on 3.8
<oliv3r> gzamboni: afaik 3.10 as that was lts
gzamboni has quit [Read error: Connection reset by peer]
<eagles0513875> oliv3r: the next or devel repo which one would you recommend i use?
<oliv3r> roflmao
<oliv3r> gitorious is one of the few opensource backed git sites
<oliv3r> but for 'support tickets' etc, they use google groups
gzamboni has joined #linux-sunxi
<wingrime> oliv3r: new sdk ?
<oliv3r> wingrime: yeah for a23
<wingrime> oliv3r: i hope we get it soon
<oliv3r> wingrime: scinserly doubt it
hero100 has joined #linux-sunxi
_massi_ has quit [Read error: No route to host]
<vector80> oliv3r: I got that tar.xz file, and it creates a folder with same contents also
<vector80> So I should copy all these to my SDcard, and overwrite with the ones on the eMMC ?
hero100 has quit [Remote host closed the connection]
_massi_ has joined #linux-sunxi
penghb has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
quintin_ has joined #linux-sunxi
foubarre has joined #linux-sunxi
<foubarre> Hi. Is someone aware of a (recent or not too recent) release of linux where at least OTG (g_mass_storage/..) and GPIO do work? All releases i tested so far (3.3, 3.4) have CPU usage bug or driver disabled. Enabling driver does not make OTG work.
<foubarre> oh. this is for a CB2 board...
jemk has joined #linux-sunxi
paulk-collins has quit [Quit: Ex-Chat]
paulk-collins has joined #linux-sunxi
foubarre has quit [Remote host closed the connection]
shineworld has quit [Ping timeout: 252 seconds]
tomboy64 has joined #linux-sunxi
wolfy has joined #linux-sunxi
_massi_ has quit [Quit: Leaving]
earny has joined #linux-sunxi
foubarre has joined #linux-sunxi
shineworld has joined #linux-sunxi
<oliv3r> vector80: the HWpack basically is a collection of bootloader; kernel, kernel moduels + mali modules even
<oliv3r> vector80: learn to use it and appreciate it :)
<oliv3r> vector80: you could, in theory, boot from SD; make partitions, format partitions, extract your OS image
<oliv3r> vector80: then, extract the HWpack over it (e.g. installing the kernel and the modules and libraries (like opengl libs)
<oliv3r> vector80: dd the bootloader that resides in the hwpack and you should have a bootable emmc
<oliv3r> vector80: e.g. this is basically in layman terms what your master SD should be
wolfy has quit [Ping timeout: 252 seconds]
naobsd has quit [Ping timeout: 272 seconds]
Quarx has quit []
<quintin_> Hello I am trying to compile my own kernel version 3.4.75 with the gmac module for ethernet on a cubieboard2 (a20). I think that I mess up the script.bin configuration which contain only the gmac par (not the emac). if I put only the gmac driver I don't see ethernet interface with eth0. If I put the emac I see the eth0 but I can't use it (https://www.google.fr/search?client=safari&rls=en&q=sunxi_gmac+cannot+register+as+MDIO+bus&ie=UTF-8
<quintin_> soory for the link it was just sunxi_gmac cannot register as MDIO bus
ZetaNeta has joined #linux-sunxi
jemk has quit [Read error: Operation timed out]
JohnDoe_71Rus has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
foubarre has quit [Remote host closed the connection]
<oliv3r> quintin_: i think 3.4 gmac's driver is limited to cubietruck; cb needs emac driver, but i could be wrong
<quintin_> thus I have to change also my script.bin
<quintin_> I though that was inside the a20 proc
shineworld has left #linux-sunxi ["Leaving"]
<quintin_> thus the cubieboard2 should get it too
<quintin_> thank for your answer
Gerwin_J has quit [Quit: Gerwin_J]
ZetaNeta has quit [Ping timeout: 246 seconds]
<quintin_> ssh
<quintin_> sorry it seems to work with emac
<quintin_> thanks oliv3r
jemk has joined #linux-sunxi
<mnemoc> oliv3r: ping
<n01> anyone with jtag on cb2 here?
<oliv3r> mnemoc: pong
<oliv3r> n01: i haven't invested time into jtagging
<oliv3r> quintin_: in theory, the gmac driver should work with cb2 and even better; but the driver doesn't talk to MII yet afaik
<oliv3r> quintin_: its hardcoded to rgmii only
<oliv3r> but don't quote me on that
<wens> what?
jemk has quit [Ping timeout: 240 seconds]
<wens> gmac in u-boot has proper support. gmac in sunxi-devel requires u-boot to setup mii/rgmii mode
<quintin_> thanks for your time oliv3r
<libv> i just got a "leliktec" A20 tablet
<libv> "Super duolcore A20"
<libv> yes, duol
<quintin_> thus to get gmac working I should change my uboot?
<wens> quintin_: yes. update to latest u-boot-sunxi
<libv> k701hc seems to be the modelname
<libv> will be taking pictures in a bit
<quintin_> thanks good information I modify my kernel and script.bin but not the uboot
<quintin_> the last time I have done it I got screw but at least I have now a working version with emac
<quintin_> thanks to both of you for the information
<quintin_> have a nice day
<wens> what? it was 3.4?
<mnemoc> oliv3r: would you mind look at amery's wip/sunxi-3.10/soc-detect and telling me if it's too ugly?
<wens> quintin_: what I said refers to mainline kernel
<mnemoc> oliv3r: it's for the legacy drivers
<quintin_> wens I am on the 3.4.75 the last stable
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<mnemoc> oliv3r: just diff it against experimenta/sunxi-3.10
<oliv3r> mnemoc: er ok let me pull
<wens> quintin_: ignore what i said then :(
<oliv3r> wens: we're talking 3.4 here :)
<oliv3r> libv: super duol! still no a13?
<oliv3r> libv: or where you after a20 hardware, i forgot
<libv> it will take a few more days for the a13 to arrive
<libv> but i stumbed over an a20 tablet as well
<oliv3r> why tablets? cubietruck is a20 hardware?
<libv> because LCDs are not the easiest things to implement properly
parabyte has joined #linux-sunxi
<libv> hdmi is trivial, vga was tricky due to bad implementations
<oliv3r> ah okay, very fair enough
<parabyte> vga is easy
<libv> LCD... well, that gets pretty nasty pretty quickly
<parabyte> come on libv RGC analogue signals
<parabyte> EASY
<libv> parabyte: oh?
<oliv3r> libv: yeah def.
<parabyte> I like vga
<parabyte> for electronics hacking reasons
<libv> parabyte: what other signals are there on a vga connector?
<parabyte> plus its easy to get vga out of anything
<libv> parabyte: or is it only rgb?
<parabyte> RGB and some other stuff
<oliv3r> i2c
<libv> oh. handwaving.
<oliv3r> some sync
<libv> yes, handwave enough and everything is easy
<parabyte> you can generate an vga signal with any old DAC
<libv> parabyte: there's h/vsync
<libv> parabyte: which in our case ties the vga connectors that are implemented fully to the first CRTC
<libv> parabyte: then there is the fact that all but the cubietruck implement DDC
<libv> yet all ship with a blue connector, which signifies ddc
<parabyte> i just like vga sometimes its handy :)
<libv> parabyte: and then there is the little matter of load detection
<parabyte> libv, i need to get in this century and ditch these vga displays in my workshop!
<libv> with hdmi, you eiter have hdmi or you don't. you get hpd and i2c _always_
<parabyte> new years resolution!
<libv> parabyte: i have been developing graphics drivers for more than a decade
<libv> parabyte: and i love CRTs
<parabyte> me too :(
<libv> parabyte: they show exactly what is going on
tomboy64 has quit [Ping timeout: 252 seconds]
<parabyte> there is indeed that, i guess get with the times with hdmi
<libv> and no, vga is not easy compared to the likes of hdmi
<oliv3r> Turl: ! where are you when I need you!
<parabyte> only recently ditched some legacy isa 8bit devices!
<libv> electronically it is, but driver wise, it isn't
<parabyte> i think its the olimex a20 board with the vga on board
<parabyte> good stuff!
<parabyte> lol
<libv> parabyte: well, depends
<libv> although, the cubietruck is the one with the vga wired
<libv> i didn't think olimex came with vga connectors directly
tomboy64 has joined #linux-sunxi
<parabyte> I do not think armel boards are strong enough for my needs yet
<parabyte> !
<libv> and the provided vga cables implement just the bare necessities
<parabyte> give em a few more years and im sure they be good
<parabyte> sorry i have to keep it short and sweet but my boss is on the hoover!
<parabyte> hover
<parabyte> sorry typo
<parabyte> take care
parabyte has quit [Quit: Leaving]
<oliv3r> oh 'and the provided' nvm then :p
<libv> oliv3r: 6 wires...
<libv> oliv3r: gnd, r, g, b, hsync, vsync
<libv> so no i2c either
<libv> also, i wish i had done this work earlier, so i could've given some advice to the cubie folks on how to implement their VGA connector
<libv> as now we can only ever have a single monitor attached to our SoCs
<libv> unless you are using a TV
<libv> as all vga connections implement H/VSync on the LCDC0 signals
<libv> and hdmi seems permanently wired to LCDC0
<libv> and most LCDs are hooked to LCDC0
<libv> we only have a good use case for LCDC0, so only a single timing is possible
<libv> so the second scaler (FE), composer (BE) and LCDC are just wasted
<libv> and why they have a second TVEC is totally beyond me
<libv> if cubietruck had stuck VGA to the LCDC1 H/Vsync, then you could run two displays with no problem
<libv> (apart from memory bandwidth issues)
<oliv3r> libv: do give the advice to olimex and radxa though :)
<oliv3r> especially olimex
<oliv3r> i think i recall seeing the olimex boards using lcd1
<oliv3r> let me double check
<oliv3r> nope, they didn't
<oliv3r> LCD0 also
<wens> allwinner "best practice" ?
<libv> wens: indeed
<libv> wens: cubietruck improved over allwinner by actually wiring up ddc
<wens> the whole 2d graphics pipeline seems complicated
<libv> 2d is not too complicated
<libv> but according to ssvb it has some holes
<libv> display, yes, but not more complicated than other display engines
<libv> nice.
<libv> popped open the device... and there are three pads... with labels
<libv> GND, RX, TX
<libv> right next to the case, and there is even room for drilling a small hole
<mnemoc> oliv3r: I'm done with the soc-detect stuff for 3.10, but would like your comments first
binaryferret has quit [*.net *.split]
<libv> nice.
binaryferret has joined #linux-sunxi
<mnemoc> you own that one?
<libv> yup
<libv> can't seem to get it into fel mode though :(
<libv> grmbl
<libv> it's either nothing (and plugging in usb starts charging the battery) or full android
tmonjalo_ has joined #linux-sunxi
<tmonjalo_> Hello all,
<tmonjalo_> I'm looking for help to make the framebuffer working on my TV
shineworld has joined #linux-sunxi
<libv> tmonjalo_: what hardware, and are you already running a linux-sunxi kernel?
shineworld has left #linux-sunxi [#linux-sunxi]
<tmonjalo_> I have a Mele A2000 connected with the analog composite output
<tmonjalo_> I have a fresh kernel 3.4.75
<tmonjalo_> I've configured script.bin for 2 screens in TV mode
<libv> tmonjalo_: what have you tried already?
<libv> 2 screens?
<libv> hrm
<tmonjalo_> I've tried many configurations in script.bin
<tmonjalo_> with only 1 screen
<tmonjalo_> But I've only a horizontal white line moving on the screen
<libv> stick a dmesg in http://pastebin.com/
<tmonjalo_> libv: ok, thanks for your help
<libv> i don't know of anyone who has so far succeeded or even tried to get composite to work
FR^2 has joined #linux-sunxi
<tmonjalo_> libv: You mean everybody is using HDMI ?
<libv> and i was kind of hoping it stayed that way so i wouldn't need to bother implementing it on my kms driver :p
<tmonjalo_> Oh :/
<libv> tmonjalo_: let me dig around in disp again to see what can be done to make it more noisy
<tmonjalo_> libv: ok thanks
<libv> i have all the necessary hw to go and try this myself, but i have never done so
<libv> tmonjalo_: can you paste the relevant sections of your .fex into pastebin as well?
pacopad_ has joined #linux-sunxi
<tmonjalo_> Me too, I've never tried hard but today I am preparing new year's day for the children and was thinking about displaying a cartoon on the TV :)
<libv> bad plan :)
<libv> not something you tend to be able to fix in the space of a few minutes :)
pacopad has quit [Ping timeout: 248 seconds]
<libv> tmonjalo_: first off, are you certain that you are properly connected to the TV's composite input?
<libv> although, that doesn't matter, if you happen to connect to s-video, you should just get black and white
pacopad_ has quit [Read error: Operation timed out]
<tmonjalo_> libv: Yes I think it's well connected: a yellow cable into the SCART
<libv> first off, there is no point in confusing the stupid driver even more
<tmonjalo_> But we never can be sure with hardware ;)
<libv> so disp_mode = 0 please
pacopad has joined #linux-sunxi
<tmonjalo_> ok
<libv> tmonjalo_: how old is your tv?
<tmonjalo_> very old :)
<tmonjalo_> 15 years I think
<libv> then set screen0_output_mode = 11
<libv> you will need to set it to pal
<tmonjalo_> with disp_mode=0, we use only screen 0
deasy has joined #linux-sunxi
<libv> tmonjalo_: yup
<tmonjalo_> I trusted that screen 0 is HDMI output
<libv> nope
<tmonjalo_> how screen 0 is connected to composite ? with mode ?
<libv> this is how display hw works :)
atiti has quit [Ping timeout: 252 seconds]
<libv> our engine is pretty limited with switching "outputs"
<libv> but composite should be more easily switchable
<libv> do you need hdmi?
<tmonjalo_> not at all
<libv> then take that out of the equation
pacopad_ has joined #linux-sunxi
<libv> so, disp_mode = 0, screen0_output_mode = 11
<tmonjalo_> yes, it's done
pacopad has quit [Ping timeout: 246 seconds]
pacopad_ is now known as pacopad
<tmonjalo_> I've the white line blinking
<libv> now test the dacs
<tmonjalo_> oh wait
<libv> we have 8 dac lines btw
<tmonjalo_> % sudo ./a10disp info
<tmonjalo_> Error: Failed to open /dev/fb0: No such file or directory
<tmonjalo_> why am I no /dev/fb now ?
<libv> so expand the dacX_src to count from 0 to (and including) 7
<libv> and set all to 0
<libv> you have gotten the display engine going before, right?
<tmonjalo_> libv: sorry, I don't understand your question
<libv> tmonjalo_: have you had console output or X before on your device?
<libv> without the TV
<libv> with some other monitor
<libv> or is this a totally new area for your device?
pacopad has quit [Ping timeout: 265 seconds]
<tmonjalo_> When I received the device, I've tested the android stuff on this TV
<libv> ok, but you never did so with sunxi stuff
<libv> ok
<tmonjalo_> with composite so I think
<tmonjalo_> no never tried display output after removing android
<libv> ok
popolon has joined #linux-sunxi
<tmonjalo_> Is it normal the /dev/fb* are gone ?
<libv> tmonjalo_: nope, not really
<libv> tmonjalo_: were they there before?
<libv> on sunxi?
<libv> with a different .fex
<tmonjalo_> yes
<libv> ok
<libv> stick the dmesg in pastebin
<libv> hrm, as helpful as ever
JohnDoe_71Rus has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
pacopad has joined #linux-sunxi
<tmonjalo_> oh my fault
<tmonjalo_> libv: I'm not drunk but I set enable=0 instead of mode=0 :(
<tmonjalo_> rebooting
<tmonjalo_> my god !
<tmonjalo_> libv: you're the hero of my children !
quintin_ has quit [Quit: Leaving.]
<libv> it works?
pacopad has quit [Ping timeout: 252 seconds]
<libv> tmonjalo_: please paste the relevant bits in pastebin again
<tmonjalo_> with 8 dacs to 0, it's working ! I see the penguin
<libv> tmonjalo_: ok, if you have some time left, can figure out which of the dac lines really is composite?
<libv> tmonjalo_: do it by bisecting: first set the top 4 to something else
<libv> then whichever 4 it is, select 2 which are something else
<libv> you should be able to figure out the exact line in three steps
pacopad has joined #linux-sunxi
<tmonjalo_> libv: you mean toggling from 0 to 1 ?
<tmonjalo_> or removing the lines ?
<libv> 0 to 7 is probably better
<tmonjalo_> by the way, thanks a lot :)
<libv> or yes, 1 should also be good
<tmonjalo_> ok
<libv> tmonjalo_: if you figure out which line it is, then it can be documented on the wiki
<tmonjalo_> ok, I've an account on the wiki
<libv> i actually expect it to be dac4
<libv> why: because i seem to remember our disp driver swapping the count depending on which tv encoder it uses
<libv> both tv encoders can drive all lines
arete74_ has quit [Read error: Operation timed out]
<tmonjalo_> still working with dac4=1
<tmonjalo_> bisecting
<libv> so since we are using the first crtc and tvec, and dac0/1/2 are used by the vga connector, ...
<libv> aha
fredy has quit [Excess Flood]
arete74 has joined #linux-sunxi
fredy has joined #linux-sunxi
naobsd has joined #linux-sunxi
<tmonjalo_> libv: ok, it's dac3
<libv> cool :)
<tmonjalo_> in fact, not really
<tmonjalo_> I had 4/5/6/0
<tmonjalo_> it was KO
<libv> ...
<tmonjalo_> and now 0/0/0/0/1/1/1/1
<tmonjalo_> it is OK
<tmonjalo_> dac3 was already 0
<tmonjalo_> I don't know what these numbers mean
<libv> so 1/1/1/0/1/1/1/1 works?
<libv> each of the dac lines can be switched
<libv> to a number of different input signals
<libv> 0 is composite
<libv> 1 is luma
<oliv3r> mnemoc: i'll try to review, but busy cooking :)
<tmonjalo_> 1/1/1/0/1/1/1/1 is OK
<libv> tmonjalo_: and what about all 1 ?
<tmonjalo_> all 1 is not working
<libv> cool, dac3 it is
<tmonjalo_> but why 4/5/6/0 was not working ?
<n01> oliv3r: what are you cooking? :)
<tmonjalo_> oh maybe because mode was not 11
<libv> tmonjalo_: yeah
<tmonjalo_> libv: OK fine
<tmonjalo_> I'll document it tomorrow, promise
<tmonjalo_> libv: great thanks
<tmonjalo_> now time cooking :)
stervochka has joined #linux-sunxi
mrnuke has quit [Remote host closed the connection]
mrnuke has joined #linux-sunxi
<libv> tmonjalo_: i just documented things in the fex and mele a1000 pages
<tmonjalo_> libv: ok nice
<libv> as i know those "i promise"s as i know myself
<tmonjalo_> :)
<tmonjalo_> bye
tmonjalo_ has left #linux-sunxi ["Konversation terminated!"]
stervochka has quit [K-Lined]
<libv> aha, density is 4096 rank is 1
<libv> so 2 * 4096 / 8 ?
<libv> and 1024x600 :)
<libv> great, even the gpio wiring is the same as my a7hd
<libv> how not to buy hw to further display driver development
<oliv3r> inet-tek! ahh they make the inet tablets, my a10 tablet is of inet design too
<libv> :)
<mrnuke> oliv3r: I've never actually gotten USB communication to wotk with FEL
<Turl> sup oliv3r
captaini- has joined #linux-sunxi
captainigloo has quit [Quit: Bye Bye]
captaini- is now known as captainigloo
vector80 has quit [Quit: Konversation terminated!]
<wingrime> ssvb: as I see CMA finaly in mainline....
nedko has joined #linux-sunxi
panda84kde has quit [Quit: Konversation terminated!]
nedko has left #linux-sunxi [#linux-sunxi]
bsdfox has joined #linux-sunxi
rz2k has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
<mrnuke> oliv3r: BTW, did you see this https://github.com/hno/u-boot/blob/lichee/lichee-dev-mmc/arch/arm/cpu/armv7/sunxi/dram.c ? What's up with that?
ZetaNeta has quit [Ping timeout: 246 seconds]
ZetaNeta has joined #linux-sunxi
vincenzo has joined #linux-sunxi
vincenzo has quit [Client Quit]
VargaD_ has joined #linux-sunxi
VargaD has quit [Ping timeout: 248 seconds]
oliv3r has quit [Read error: Operation timed out]
book` has quit [Ping timeout: 265 seconds]
book` has joined #linux-sunxi
oliv3r has joined #linux-sunxi
wolfy has joined #linux-sunxi
FR^2 has quit [Read error: Operation timed out]
slapin has quit [Read error: Operation timed out]
FR^2 has joined #linux-sunxi
slapin has joined #linux-sunxi
VVocach has joined #linux-sunxi
<VVocach> hey guys
<VVocach> what do you think about kali linux? is there another good system like it
VVocach has left #linux-sunxi [#linux-sunxi]
wolfy has quit [Ping timeout: 252 seconds]
rings_IIV has quit [Read error: Connection reset by peer]
rings_IIV has joined #linux-sunxi
rings_IIV has quit [Remote host closed the connection]
rings_IIV has joined #linux-sunxi
slapin has quit [Read error: Operation timed out]
slapin has joined #linux-sunxi
<wingrime> mnemoc: cool
* mnemoc hopes for A20 family instead of A31 family
<wingrime> cutting-edge OpenGL ES 3.0 compliant, GPU
Gerwin_J has joined #linux-sunxi
<mnemoc> mali6xx? :p
<mnemoc> dreaming is free
wolfy has joined #linux-sunxi
wingrime has quit [Ping timeout: 246 seconds]
wolfy has quit [Ping timeout: 252 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<mnemoc> ^--- picture of the A80 board
<n01> looks nice
<mnemoc> no sata
<mnemoc> but usb3.0
<mnemoc> weird they have two PMUs
<mnemoc> I wonder what is that AC100 and the silver chip
lgentili has joined #linux-sunxi
<lgentili> looks like a BT/Wifi chip
fredy has quit [Excess Flood]
<lgentili> something with RF, that's why the shield
<HdkR> The A80 has some Mali-T6xx thing in it right?
<mnemoc> no one knows
fredy has joined #linux-sunxi
<HdkR> hm
<mnemoc> hopefully not a PVR
<HdkR> "A80 packs a cutting-edge OpenGL ES 3.0 compliant, GPU compute optimized graphics processor" So t6xx or PVR6
<mnemoc> hope for the first
<HdkR> Guess we'll most likely find out at CES
<HdkR> In the case that it is PVR6 it'll be interesting just because it is the first thing that actually will be released on the Android front with it. For anything beside that it is the worst thing of course
<lgentili> memory from the picture is a 2Gbyte ddr3
Black_Horseman has joined #linux-sunxi
<lgentili> Hope there is a eMMC at the bottom side and not only a uSD slot.
<mnemoc> somehow it looks like the cubieboard.... hope cubietech managed to get involved
<lgentili> The AC100 is an audio/amp companion chip I guess, there is a connector near, says HP (headphones??)
<mnemoc> true
<lgentili> I like the board... but the important thing here is...... that we want MALI inside!! :)
<mnemoc> hopefully allwinner learned from the sgx544 mistake as samsung, and return to mali
<lgentili> That's exactly my bet.
<lgentili> Mali T6xx = OpenCL full profile with alot of new potential uses.
<lgentili> Not only the open community support.
Xaros has joined #linux-sunxi
FDCX has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 245 seconds]
kz1 has quit [Ping timeout: 272 seconds]
Fangorn has quit [Read error: Connection reset by peer]
Fangorn has joined #linux-sunxi
penghb has quit [Ping timeout: 252 seconds]
penghb has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 252 seconds]
ZetaNeta has joined #linux-sunxi
Wizzup has joined #linux-sunxi
lgentili has quit [Quit: Page closed]
tomboy65 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 265 seconds]
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 240 seconds]
slapin has quit [Ping timeout: 272 seconds]
slapin has joined #linux-sunxi
popolon has quit [Quit: Quitte]
<n01> happy new year :)
<mnemoc> happy 2014
<mrnuke> why are you guys talking from the future?
<Wizzup> yay \o/
tomboy64 has quit [Ping timeout: 272 seconds]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
tomboy64 has joined #linux-sunxi