ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
drachensun-peng has quit [*.net *.split]
arete74 has quit [*.net *.split]
torqu3e has quit [Read error: Connection reset by peer]
RaYmAn has quit [Ping timeout: 248 seconds]
RaYmAn_ has joined #linux-sunxi
torqu3e has joined #linux-sunxi
arete74 has joined #linux-sunxi
drachensun-peng has joined #linux-sunxi
mab has quit [Ping timeout: 260 seconds]
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
mab has joined #linux-sunxi
zenitraM has quit [Ping timeout: 245 seconds]
zenitraM has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
zenitraM has quit [Quit: ZNC - http://znc.sourceforge.net]
zenitraM has joined #linux-sunxi
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
ZaEarl_ has quit [Ping timeout: 240 seconds]
ZaEarl_ has joined #linux-sunxi
torqu3e has quit [Read error: Connection reset by peer]
torqu3e_ has joined #linux-sunxi
nicktime has joined #linux-sunxi
<nicktime> Hi, I've found in this channel's logs that hansg is working on AXP PMIC driver, could anyone give me a link to his repo? Anyone else is working on AXP driver?
<nicktime> Oh, I mean mainlining efforts.
<nicktime> Though nickname make it look controversial...
wingrime has joined #linux-sunxi
torqu3e_ has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
<wingrime> A13-OLinuXino also have RTL8188CU (sdio), that simular mine RTL8188EU (usb)
<wingrime> my a13 look same but have different HW http://linux-sunxi.org/A13B
<wingrime> diferent wifi and ts IC
<wingrime> techin: this is yours: http://linux-sunxi.org/A13B ?
<wingrime> techn: also http://linux-sunxi.org/Q88 same
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
mab_ has joined #linux-sunxi
mab has quit [Ping timeout: 264 seconds]
torqu3e has quit [Ping timeout: 245 seconds]
rellla has joined #linux-sunxi
torqu3e has joined #linux-sunxi
ZaEarl_ has quit [Ping timeout: 240 seconds]
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 276 seconds]
<mripard> Turl: pong
rz2k has joined #linux-sunxi
drachensun-peng has quit [Ping timeout: 256 seconds]
drachensun-peng has joined #linux-sunxi
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
hipboi has joined #linux-sunxi
focus has joined #linux-sunxi
merbanan has quit [Ping timeout: 248 seconds]
merbanan has joined #linux-sunxi
paulk-desktop has joined #linux-sunxi
hipboi has quit [Ping timeout: 245 seconds]
<Turl> hi mripard
<mripard> hi
<Turl> mripard: yesterday I was having a look at the wemac branch on your tree
<Turl> I wondered what the hackberry_hogs stuff was in "ARM: hackberry: dt: Add Ethernet controller to the Hackberry device tree"
<mnemoc> eh? sunxi-wemac already submited upstream?
<Turl> mnemoc: no, but it's WIP :)
<mnemoc> but we don't even have an stable sunxi-wemac in sunxi-3.0....
<Turl> mnemoc: I don't have any stability issues with it
<mnemoc> tell that to rm :)
<Turl> it's just slow on full duplex :p
<mnemoc> *g*
<Turl> if I ethtool it to half duplex it actually performs decently
<mripard> Turl: it's a group where you put all the GPIOs used for your device, so that pinctrl knows what pins is already in used, etc.
<mripard> we should do the same for the LEDs actually...
<mripard> hmm, you did
<mripard> it's just a conveniance
<mripard> to avoid creating one group for each of the small pins you will use every now and then
<mripard> like, reset pins, power pins, and so on
hipboi has joined #linux-sunxi
focus has quit [Quit: Ex-Chat]
focus has joined #linux-sunxi
<Turl> mripard: so it's kind of a catch all for small sets of pins then
<mripard> yep
<Turl> mripard: I see now that you use PH19 on the power-gpios property
<focus> what would it take to get full ubuntu working on A31? (sata, usb, ethernet, lcd, hdmi, video acceleration, 3d )
hramrach has quit [Ping timeout: 276 seconds]
<hipboi> A31 doesn't have sata
<Turl> mripard: the cubieboard isn't using muxing yet, something like this should work I suppose http://sprunge.us/WcLc
<focus> hmm.. does A31 have any ways of accessing an SSD?
<Turl> USB? :)
<mripard> Turl: yes, I didn't do it because I don't have one, and so I wasn't sure about the muxing.
<mripard> feel free to osend it
RaYmAn_ is now known as RaYmAn
RaYmAn has quit [Quit: Reconnecting]
RaYmAn has joined #linux-sunxi
<Turl> mripard: I had a quick look on the u-boot code, that seems to be it
<Turl> I'll test and send in a bit
<mripard> Turl: feel free to add your acked-by to the UARTs patches if you agree with them btw
<mripard> mnemoc: you too :)
<Turl> hm, your branch doesn't build :/
<mripard> Turl: ?
<mripard> which one?
<Turl> make[1]: *** [kernel/timeconst.h] Error 127
<Turl> make: *** [kernel] Error 2
<Turl> bc not found :<
<mnemoc> install bc
<mripard> well, you have to install bc then :)
* Turl doesn't like new dependencies
<mripard> it's to drop a perl script
<mripard> which is always a good thing :)
<Turl> sh can do math too
<mripard> come on, don't troll too much ;)
<Turl> CI systems would break :)
<mripard> and which shell are you talking about ? sh? bash? dash? zsh? :)
<mnemoc> $(expr 1 + 1) is cross shell :p
<mripard> doing anything fancy with a shell script is just a nightmare.
<mnemoc> but `bc` is a fair requirement
<Turl> sh -c 'echo $((2+3))'
<mnemoc> Turl: that's bashism
<mnemoc> it took rob landley like 5 years to get his perl-removal patch accepted :p
<Turl> that's the only *sh on my box :P
<mnemoc> just install bc and stop whinning :p
<Turl> I did already :p
<mnemoc> :)
<mripard> mnemoc: and yes, I've continued the work from stefanro on the wemac driver
<mripard> It's not that bad if it doesn't work in any cases
<mripard> since we don't have any datasheet, it will be a best-effort kind of support on this one
<Turl> 1c28000.uart: ttyS0 at MMIO 0x1c28000 (irq = 17) is a U6_16550A
<Turl> console [ttyS0] enabled, bootconsole disabled
<Turl> console [ttyS0] enabled, bootconsole disabled
hramrach has joined #linux-sunxi
<Turl> is it normal that it prints the last line twice?
<mripard> hmmm, I don't know, never seen it
<mripard> never really paid attention to it neither
<Turl> the console works, so I'll assume the muxing is right
<mripard> well, since the muxing was previously done by u-boot
<mripard> if you set the wrong muxing, you won't see the difference :)
<mripard> because you'll have the two set of pins, muxed to the UART
<mripard> one that is actually used
<mripard> and the other that is useless
<Turl> mripard: this breaks it, so I suppose I'm using the right one :) http://sprunge.us/UZhV
<mripard> yes :)
<Turl> hipboi: hi
<Turl> hipboi: uart1 is not accesible on cubieboard, right?
<hipboi> Turl: i need to check the schematic
<hipboi> Turl: uart1 pin is used as emac
<nicktime> mripard: Is your I2C work available through your github repo? Which branch is it?
<mripard> nicktime: it's not complete, so it's not
<mripard> but I can push it if you want to take a look at it
<nicktime> I'd like to
<mripard> 2s
<Turl> hipboi: so it's not usable then, alright
<mripard> nicktime: it's pushed
<mripard> sunxi-3.9-wip-i2c-dont-build
<nicktime> Thanks.
<mripard> (don't look at the dont-build, my repo is under CI, it's the flag to tell the bot to ignore it)
<mripard> hmmm
<mripard> don't look at the commit log neither :)
<mripard> it's untested at this point
<mripard> so I'm definitely open to comments
<mripard> to be testable, I guess the only thing left to do is to set the clock dividers in the probe function
<nicktime> I see. Not sure if I'll fail miserably or will manage to get anything useful done:) But will take a shot still.
<mripard> nicktime: I'm going out for lunch, I'll help you a bit more when I come back if you want
<nicktime> mripard: ok, thanks
hipboi has quit [Ping timeout: 272 seconds]
mab_ has quit [Remote host closed the connection]
torqu3e has quit [Ping timeout: 245 seconds]
torqu3e has joined #linux-sunxi
<mripard> nicktime: something like that http://code.bulix.org/kwnqil-83114
<mripard> just after the /* clock dividers */ in the probe
<mripard> you'll need Turl's patches for the clock gating as well
nicktime has quit [Ping timeout: 272 seconds]
<Turl> fuu, power cut :(
<Turl> mripard: what clock is that? I'll work on a representation next if you need it
<mripard> Turl: let me check
<mripard> gates 0, 1 and 2 in APB1
<mripard> (on the A10)
<Turl> apb1 gates are all there
<Turl> but they're just gates, you cannot change the frequency
<mripard> it's not in the clocks themselves that we need to change the frequency
<mripard> the i2c controller has an internal divider
<mripard> that's what I was refering to
<mripard> I just told him to grab your patches, I know this won't be extra work for you :)
nicktime has joined #linux-sunxi
<Turl> mripard: ok
<Turl> mripard: my leds stopped working hm
<mripard> since when?
<Turl> mripard: idk, just tried on your branch + clk
<Turl> the green one is lit but the blue one doesn't heartbeat
<Turl> I cannot seem to be able to operate any of them (can't turn off the green nor turn on the blue)
<mripard> hmmm, weird
egbert_ is now known as egbert
<mripard> and if you change directly the GPIO value through sysfs?
<Turl> ok, so it's one of the gates that I shouldn't be gating
* Turl has a hunch
<mripard> oh, so it's your patch that cause this?
<Turl> yes
<Turl> well, not really the patches' fault, more like the automatic 'gate all the things that aren't in use' fault
<Turl> mripard: ok, so pinctrl must hold apb0_pio
<mripard> makes sense
<Turl> does it support clocks=?
<mripard> not for now
<mripard> but I'm pretty sure you'll come up with a patch :)
bfree_ has joined #linux-sunxi
bfree has quit [Ping timeout: 252 seconds]
<nicktime> mripard: could you give me the kernel config?
<mripard> multi_v7_defconfig, plus CONFIG_I2C_SUNXI
<nicktime> Thanks
<Turl> mripard: does the pinctrl driver support unloading?
<mripard> nope
<mripard> it doesn't make much sense to remove it
<Turl> good, I don't have to worry about unpreparing and disabling the clock then :)
<Turl> mripard: http://sprunge.us/jEOV
<mripard> looks fine
hansg has joined #linux-sunxi
<Turl> ok then, all rebased and working fine as far as I can see
<Turl> 1,9March/arm/boot/uImage
<Turl> 2,4March/arm/boot/Image
<Turl> pretty small, even uncompressed :)
<mripard> we don't have that much to put into our image though :)
dstyle has joined #linux-sunxi
rellla2 has quit [Ping timeout: 245 seconds]
paulk-desktop has quit [Quit: Ex-Chat]
ZaEarl_ has joined #linux-sunxi
<nicktime> mripard: i2c bus not added to dts file
<mripard> ah, yes, probably
<mnemoc> drivers/net/wireless/rtl8723as/hal/rtl8723a/狡籹 -rtl8723a_bt-coexist.c .... come on
<mnemoc> chinese filenames?!
<nicktime> omg
<mripard> mnemoc: hahaha
<nicktime> compiler test
rellla has joined #linux-sunxi
<rz2k> mnemoc: have you updated sunxi-bsp submodules to use latest stage merge?
<mnemoc> rz2k: not yet :|
<mnemoc> need to integrate mali-sunxi as well :\
<xenoxaos> i need to take a vacation to sit down and work on all the shit on my pile...
torqu3e has quit [Read error: Connection reset by peer]
torqu3e has joined #linux-sunxi
<techn__> how marsboard is better than cubieboard?
<techn__> "it is a credit card sized board, expansion 140 extend pin 2.0mm headers, more powerful and cheaper than cubieboard." -Wiki :)
<mnemoc> more powerful????
<mnemoc> how can an A10 be more powerful than another A10?
<techn__> more ram?
<mnemoc> same
<mnemoc> it's smaller, cheaper and has more pads (no headers/pins)
torqu3e has quit [Ping timeout: 245 seconds]
<mnemoc> rz2k: bsp updated
<rz2k> I believe we need to state on wiki about miniand/marsboard and etc being just resellers of some oem projects
<rz2k> with 0 support and etc
torqu3e has joined #linux-sunxi
anunnaki has quit [Ping timeout: 264 seconds]
<mnemoc> what about making some template banners like wikipedia's? {{wip}} {{wikify}} {{community}} ....
<mnemoc> but anyhow, adding things like "my product is better than this other product" is imo unacceptable
<mnemoc> it must be up to the reader to decide what is better for his needs
hansg has quit [Quit: Leaving]
nicktime has quit [Quit: Leaving.]
<hramrach> their home page does not work without javescript - even such basic thing like selecting the tab on the top :>
<hramrach> JS-links ftl
<mnemoc> at least it's not flash-based
<hramrach> hmmm, maybe I had just cached old version that had no links there
<hramrach> it looks ok now
paulk-desktop has joined #linux-sunxi
<wingrime> hramrach: Have you any intension to send RTL8188 to ML ?
<techn__> ssvb: libv: way to handle page flipping found
<techn__> WB_STATUS Write-back process status
<techn__> This flag indicates that a full frame has not been written back to memory. The bit will be set when write-back enable bit is set, and be cleared when write-back process ends
<hramrach> wingrime: no, that's not something you can send to a ML
<hramrach> have you checked how large the 'patch' would be?
<techn__> or atleast possibility
<hramrach> wingrime: I don't even have a device to test the driver with
<wingrime> hramach: I have using it now and there is any issue
<wingrime> hramach: merge you branch simpler than ML
<hramrach> wingrime: can you try the 8192cu driver with a .fex file that enables the USB controller?
<wingrime> hramrach: I have tryed load it manualy
<hramrach> it won't work when manually loaded when the USB is not powered
<techn__> newermind.. writeback is not used
<hramrach> so it either does not support this hardware revision or it does not work because the USB is not enabled in fex file
<hramrach> wingrime: try asking on the ML how to determine if the USB port on which the wireless is connected is enabled with your fex file
<wingrime> hramrach: what fex parameter for usb boot power ?
<wingrime> techn__: http://linux-sunxi.org/A13B this yours ?
<techn__> wingrime: yes
<wingrime> techn: my looks 100% same but have zte touch and other wifi
<techn__> ok.. so we should combine it
<techn__> propably to q88.. and express differences
<techn__> and maybe we could make common fex file for all q88 devices?
<hramrach> wingrime: I have [usb_wifi_para] usb_wifi_used = 0 usb_wifi_usbc_num = 2
<hramrach> that would make [usbc2] the port used for wifi
<techn__> ooh.. that datasheet has security system registers :)
<techn__> we could make /dev/crypto?
<wingrime> hramrach: my fex http://paste.org.ru/?jof33c
<wingrime> techin__: A13B and GONMAD PWS700YA and Q88 are same ?
ZaEarl_ has quit [Ping timeout: 240 seconds]
<techn__> q88 is reference design name :/
<hramrach> wingrime: try setting usb_host_init_state = 1
<hramrach> oh, and default for power to 1
<techn__> mnemoc: can confirm
<hramrach> but not sure how that's done with the fex mess
<hramrach> usb_drv_vbus_gpio = port:power203<1><0><default><0>
<wingrime> hramrach: same name can have different HW
<hramrach> that's totally possible
<hramrach> but so far it looks like your USb controller is powered off so you can't tell if the upstream driver would work or not
<hramrach> I have usb_drv_vbus_gpio = port:PH03<1><0><default><0>
<hramrach> looks same enough
<hramrach> so just set usb_host_init_state = 1
<wingrime> hramrach: what means usb_wifi_used = 1
<hramrach> that means that ans USB WiFi module is supposed to be mounted on the board
<wingrime> have it change power on behavior?
<hramrach> you need to set usb_host_init_state = 0
<hramrach> to 1
<hramrach> for [usbc1]
<wingrime> understand...
<hramrach> and can as well for [usbc0] too for good measure
<wingrime> wait I reboot
<wingrime> hramrach: have x11 mali drivers give performance compare with framebuffer ?
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
<hramrach> I have no idea
<hramrach> I use X only for testing and performance is consistently poor regardless of driver used
paulk-desktop has quit [Ping timeout: 240 seconds]
<wingrime> hramrach: no way... also we have Realtek 8192C USB WiFi for SW
<wingrime> "C" means SDIO
<hramrach> ?
<wingrime> "E" means USB
<hramrach> what does lsusb say?
<ssvb> hramrach: the graphics performance in X currently largely depends on what you are doing, I have documented some of the issues here - https://github.com/ssvb/xf86-video-sunxifb/issues?state=open
<wingrime> lsusb see some Realteck device
<hramrach> what device?
<wingrime> wait I make more one reboot (removed 8188eu drvier)
<wingrime> so as expected not work at all....
<hramrach> ssvb: I run gnome-session from the init script. Sometimes I open a X terminal and observe how slow the letters draw ;-)
<ssvb> hramrach: could you try to profile it and check what is the bottleneck?
<hramrach> I hope that when the doublebuffering stuff is finished at least the part with moving windows are ound looks reasonably
<hramrach> ssvb: with what driver version ;-)
<ssvb> testing all of them would be nice :)
<hramrach> the problem with the profiler is that it takes like 30% CPU time :s
<wingrime> hramrach: also I wonder why suspend not work on linux ....
<hramrach> because it's broken
<ssvb> hramrach: it is? seems to work just fine here
<wingrime> hramrach:Bus 002 Device 002: ID 0bda:8179 Realtek Semiconductor Corp.
<hramrach> haven't seen a system with working suspend for ages
<wingrime> hramrach: tablet without suspend....unumobile
<wingrime> *unusable
<hramrach> yes, it sucks for battery powered device
<hramrach> but A13 is quite new. don't expect miracles
<wingrime> i don't expect anything from chip china device I just try make it fly on wooden wings))
<wingrime> *cheap
<hramrach> 0bda:8176 appears to be RTL8188CUS (usb) device
<xenoxaos> talking about the mercury adapter that came with the cubie?
<hramrach> no
<xenoxaos> 0bda:8179 came with the cubie i got
<hramrach> got it working?
<xenoxaos> no
<wingrime> I got ))))
<xenoxaos> i have enough wireless dongles i didnt mess with it
gzamboni_ has quit [Ping timeout: 245 seconds]
<xenoxaos> did you just have to add the usb id into the rtl driver and recompile?
<wingrime> no
<wingrime> I just add driver and add it to Makefile Kconfig
<xenoxaos> i just use it in my windows box at work as a network shared AP so i can get signal on my phone
<wingrime> techn__: are you saw my mmc patch ?
<techn__> wingrime: ?
ZaEarl_ has joined #linux-sunxi
<wingrime> yes
<techn__> when you send it?
<wingrime> last night (30 hours ago)
<wingrime> oh wait
<wingrime> I resend it
<wingrime> techin:got it ?
drachensun-peng has quit [Remote host closed the connection]
drachensun_peng has joined #linux-sunxi
<techn__> wingrime: now it came trough
<techn__> looks good
<techn__> but should that crash be alsewhere also ( bcm4330.ko) ;)
<techn__> or how that sequence goes?
<wingrime> without any ops
<wingrime> wait I try again and get you log
<techn__> but I agree that it shouldn't crash if user tries something stupid
<wingrime> techn__: I think we make more one fix in bcm driver
<wingrime> techn__: after oops system remount all FS
<hramrach> wingrime: why does the patch hcange indentation?
<wingrime> see dmesg http://paste.org.ru/?wy4lxz
<wingrime> hramrach: it should not crash with stupid reason for example when some driver try change mmc card present state
<wingrime> *unexsist card
<hramrach> wingrime: the patch diffs whole function but start and end is same
<hramrach> why do you change indentation in the patch?
<wingrime> it have invalid indent
<wingrime> ./checkpatch.pl requests
<hramrach> when the code has invalid indentation throughout it's not fo code-changing patch to fix
<hramrach> because then it's not clear what the patch changes
<wingrime> hramrach: why, there is cleanup patch for it )))
<hramrach> then apply the cleanup patch first or apply this with original indent and let cleanup patch take care of the indent
<techn__> wingrime: seems that bcm4330 and mmc/sunxi-host are incompatible :/
<wingrime> techn__: it looks I have no sdio config in fex
<techn__> wingrime: oh.. newermind :)
<wingrime> techn__: I still wait my ft5x patch aprove becoes I want make two things 1) remove useless firmware 2) may be make firmware update 3) may be fix codestyle
<wingrime> *three
<techn__> wingrime: mnemoc told that he'll merge it today :/
<wingrime> techn__: also I want bring on zte ts to my a13
<wingrime> also I think that MMC is near candidate for mainline
<techn__> MMC?
<wingrime> yes
<techn__> atleast this host_op.c seems to be filled with convention errors
<wingrime> techn__: it need full refactoring
<wingrime> and void sunximmc_rescan_card not return anythng
<wingrime> it must return some result code
<wingrime> static int sdxc_prepare_pio(struct sunxi_mmc_host* smc_host, struct mmc_data* data) in sdxc.c also use BUG_ON
<wingrime> I always thik that we can crash only if kernel cannt contine runs
<Turl> the marsboard page looks like marketing speech :/
<wingrime> tech__: I make more one patch: for sdxc.c, it also use BUG_ON in strange case
rz2k has quit []
<wingrime> tech__: see patch ))
<wingrime> Turl: wtf 4GB nand
<Turl> what wingrime ?
<Turl> btw, I bet Stallman would be proud http://www.marsboard.com/
<mripard> wingrime: I'm not sure it's ready for mainline.
<mripard> sdxc is really ugly, it would require a lot of cleanups
<mripard> plus, it uses DMA, and we don't have DMA (yet)
<Turl> mripard: doesn't wemac use dma too?
<mripard> nope
<mripard> not the version we will send at least
<mripard> the driver that is in the linux-sunxi tree does
<Turl> mripard: btw, did you find out if it's really davicom's IP?
<mripard> no
<mripard> I guess I'll contact davicom and try to see if they have the datasheet.
<hramrach> for wemac?
<mripard> yes
<hramrach> would be cool
<mripard> we'll see how it turns out
<mripard> but I'm not very confident in the long term maintainance if we have neither the datasheet nor any more device using it
focus_it has joined #linux-sunxi
<hramrach> nor a working driver
<mripard> never had any problem with the one we have.
<mripard> it works, slowly, but it works
<hramrach> ssvb: ENOPROFILER
<ssvb> hramrach: apt-get install linux-tools :)
<wingrime> mtipard: so dma is hi-est priotiy ?
<mripard> wingrime: that, or make the mmc driver work without dma, which is a good thing anyway
<mripard> and mdp said he will work on this
<wingrime> mmc have PIO code )))
<wingrime> and driver small
<wingrime> (if we drop all other stuff)
<wingrime> but ethernet without dma are ugly
<wingrime> as mmc
<mripard> slow, maybe, ugly, as usual, if it's written properly....
<mripard> what I'd like very much pretty soon is storage devices support
<Turl> mripard: are timers and RTC all implemented already?
<mripard> we have all the infrastructure needed now I think
<mripard> DMA is just a convenience
<mripard> Turl: what timers are you talking about?
<mripard> RTC, no
<wingrime> mripard: I also intresting in opensource loader
<wingrime> that before uboot
<mripard> "before" uboot ?
<Turl> wingrime: there's nothing before uboot on mmc
<mripard> you can use the SPL, and nothing will come before
<Turl> nand has boot0+1
<mripard> hno: about u-boot
<mripard> Tom Rini (u-boot maintainer) is really interested apparently about Allwinner stuff
paulk-desktop has joined #linux-sunxi
<mripard> hno: so I guess you'd be really welcome to send the patches you have :)
<wingrime> how about drop SPL and boot directly
<wingrime> uboot
<Turl> mripard: I meant the high res timers, timer0
<mripard> boot directly to what ?
<Turl> wingrime: SPL is part of uboot
<mripard> u-boot in itself is meant to run from RAM
<mripard> it's the SPL job to initialize the RAM
<mripard> so you can't jump directly to u-boot
<mripard> (you could drop u-boot and go straight from SPL to linux theorically)
merbzt has joined #linux-sunxi
<wingrime> mirad: what wrong join SPL and u-boot in one image on linking map?
<hramrach> SPL is more system specific
<xenoxaos> and sometimes has to fit in a very small portion of ram
<mripard> wingrime: it's not executed from the sam place
<wingrime> wait ... why BROM not init ram ?
<mripard> because initializing the external RAM is complicated
<mripard> it depends on the chip you have, the amount of memory you have
<wingrime> read mmc or nand simpler ?
<mripard> it wouldn't fit into the very small ROM inside the SoC
<wingrime> nand to can have different amount of blanks ?
<mripard> and most presumably, you wouldn't be able to upgrade it
<wingrime> mripard: than better
<wingrime> it makes device unbrikable
<mripard> yes, because you make perfect code that has no bugs ?
<mripard> I know I don't
<mripard> and still
<wingrime> nand can have different bus size and blank size etc how it boot from?
<mripard> some part of the RAM initialization is device specific
<mripard> the nand interface is mostly SoC specific
<mripard> anyway
<mripard> it's this way on any ARM SoC i can think of
<mripard> so you'd better get use to it :)
<xenoxaos> the only thing really standardized is the core itself....any peripherals are all different
<wingrime> mripad: BROM can be debuged on FPGA before ASIC stage
vinifm has joined #linux-sunxi
<wingrime> and fixed with chip revision
<wingrime> hardware also have bugs
<wingrime> also fixed with revisions
<mripard> ok, great, you do the ram initialization in the ROM code
<mripard> how do you deal with different ram timings ?
<mripard> ram size?
<wingrime> test
<wingrime> in modern "Dark Silicon Age" we can make HW testing
<mripard> memory timings issues can't be detected right away
<wingrime> timings can be slowest before we load fully
<mripard> ok, then who change these timings ? :)
<wingrime> on config load
<mripard> changing the timings of the RAM you're running from is a bad idea.
<wingrime> it can be handled by hw
<hramrach> heh, profiling not configured in kernel
<mripard> again, how?
<mripard> also, remember, you have to have a code that is smaller than a few kB
<wingrime> my general idea make SoC detect HW how much possile
<wingrime> even in fail-safe mode
<mripard> anyway, like I said
<mripard> feel free to create your own SoC that does this
<mripard> but, if you want to deal with the real world, you'll need a first stage bootloader
merbzt has quit [Ping timeout: 252 seconds]
vinifm has quit [Read error: Connection timed out]
vinifm has joined #linux-sunxi
merbzt has joined #linux-sunxi
<wingrime> why suspend in linux not works>
<wingrime> ?
<hramrach> cause it broken
<mnemoc> android doesn't suspend, it simply freqs down
<mnemoc> so there is no real suspend for sunxi implemented
<hramrach> and powers down screen
<hramrach> ssvb: the linux-tools are not exactly helpful
<hramrach> they only allow profilinga command afaict
<hramrach> anyway, the terminal appears to work at reasonable speed at this moment
<hramrach> so whatever I collect would not reflect the case when the letters appear slower than you type
<wingrime> mnemoc: why not implement suspend as freqs down ?
<hramrach> because it is not suspend
<ssvb> hramrach: "perf record -a", "perf record -p `pidof Xorg`" or "perf top" are quite useful
<hramrach> you have cpufreq all right
<ssvb> hramrach: just try to catch the offender next time it starts running slow :)
<wingrime> hramrch: otherdevices have suspend
<hramrach> wingrime: then do it
<hramrach> but you have to make every sunxi device driver suspend capable ;-)
<wingrime> hramrach: maybe))
<hramrach> yes, will try
<hramrach> I guess I was running some earlier driver when that was the case but not sure anymore
<wingrime> hramrach: make run core at low speed not so bad idea, but if you suspend devices it will be perfect
<wingrime> hramrach: wich file ?
<mnemoc> allwinner is so lovely... drivers/video/sun6i/disp/de_bsp/de/disp_lcd.c has chinese comments in 4 different encodings o_O
<mnemoc> GBK GB18030 GB2312 and UTF8
wingrime has quit [Ping timeout: 272 seconds]
paulk-desktop has quit [Ping timeout: 250 seconds]
paulk-desktop has joined #linux-sunxi
christopher has joined #linux-sunxi
christopher is now known as Guest23833
<libv> mnemoc: how is sun6i disp looking?
<libv> mnemoc: superficially
<libv> many changes, or just minor ones (like sun4i -> 5i)
Guest23833 is now known as anunnaki
<mnemoc> libv: haven't looked at the code itself yet. just sanitizing the history before publishing it
<mnemoc> but at least he file structure looks identical :)
<libv> ah, ok :)
<libv> good
<libv> will be a painful merge though
<mnemoc> will need to do interdiffs to see how it differs from their's latest disp for sun4i/sun5i
<mnemoc> err, not interdiff. wrong term
<libv> mnemoc: how did development start on sun6i
<libv> did they start with a patchbomb, or did they copy sun5i first?
<libv> basically, what does the first sun6i commit look like, sane, or huge?
vinifm has quit [Remote host closed the connection]
<Turl> mnemoc: huh? as far as I recall sunxi suspends just fine :|
<mnemoc> libv: the core evolved decently
<mnemoc> libv: the drivers, they first made a bulk import from sun4i or sun5i and then they continued tweaking it
<mnemoc> Turl: real suspend?
<libv> ah, ok, that's not too bad then
<Turl> mnemoc: yeah
<Turl> mnemoc: don't you recall the suspend/ assembler mess that puts ram on autorefresh and other stuff?
<Turl> :p
<mnemoc> libv: a31s is awful. but a20 and a31 are more decent than a10/a13
<libv> a31s is a reduced a31?
<mnemoc> Turl: that's their "super standby"
<Turl> yeah, that's suspend
<mnemoc> libv: plus tons of phone-ish stuff
<libv> hrm, interesting
paulk-desktop has quit [Quit: Ex-Chat]
<mnemoc> will push a20-dev to my github now
clements__ has joined #linux-sunxi
<libv> clements__: i do not think that i know you
<libv> clements__: in such a case, it is not deemed very cordial to msg people out of the blue, to ask them whether they are available.
<libv> besides, most people that i know better tend to get to the point, and don't ask to ask
merbzt has quit [Read error: Operation timed out]
<clements__> well.. i was trying to be polite..
<libv> you failed.
<libv> clements__: state what you need in here.
<clements__> im getting symbol lookup error: /usr/lib/libGLESv2.so.2: undefined symbol
<libv> clements__: your sentence is incomplete.
<clements__> es2gears: symbol lookup error: /usr/lib/libGLESv2.so.2: undefined symbol: XextCreateExtension
<libv> clements__: did you read the README at the top of sunxi-mali?
<mnemoc> libv: in my github. lichee-3.3/sun7i-dev is the original -dev branch for A20, and import/lichee-3.3/a20-dev a sanitized equivalent
<libv> mnemoc: thanks, will have a look
<libv> although it has been more than 4 months since i did the sun4i/5i disp "merge"
<mnemoc> libv: will upload the -dev for A10 and A13 as soon as I finish the sanitization
<mnemoc> then we can see what they did on those after our start-point
<libv> ah, right
<libv> good :)
<mnemoc> will push a31-dev later tonight
<mnemoc> brb
<clements__> looks similar to the wiki..
<clements__> which i followed
<libv> clements__: run make clean on your tree
<clements__> done
<libv> clements__: now run make install, and paste the full log of that on hastebin.com
focus_it has quit [Quit: Leaving]
<libv> clements__: looks ok, try es2gears again
<clements__> same error.
<libv> clements__: check if there are any other instances of libUMP installed
<clements__> /usr/lib/ shows 2.. libUMP.so and libUMP.so.3
<libv> clements__: try the thorough way.
<libv> clements__: find / -name "*UMP*"
<clements__> which is..
<clements__> sorry learning
<libv> do not paste the result of that in this channel.
<libv> clements__: also, libUMP.so in /usr/lib/ is a symlink.
<clements__> oh ok.. i used find / | grep libUMP
<clements__> same output
<clements__> where should the compiled libUMP.so reside
<clements__> just in /usr/lib?
<libv> exactly there.
<libv> read what you pasted in pastebin
MadSpark has joined #linux-sunxi
clements__ has quit [Remote host closed the connection]
<libv> clements__: run ldconfig
clements__ has joined #linux-sunxi
<libv> clements__: run ldconfig
<clements__> its working.. thanks libv
<libv> clements__: what did the trick?
<clements__> copied compiled libUMP.so to /lib/x11
<libv> ?
<clements__> ?
<libv> clements__: is /lib/x11 a directory on your linaro?
<clements__> yes.. /lib/framebuffer /lib/x11 exists
<libv> did you create those yourself?
<clements__> not to my knowledge
<libv> that smells like some mess left over from a previous installation
<clements__> but i have been working on this for a few days
<clements__> very probable
<libv> fix it.
<libv> those trees will contain other copies of the mali libs
<libv> they need to go
<clements__> thanks for your help..
<libv> which does not explain the output of your find
<libv> the find should have caught the other libUMP installed there
<libv> clements__: sunxi-mali is hard to miss
<clements__> it did..
<clements__> i mean .. my find found those there
<libv> 00:17 < clements__> /usr/lib/ shows 2.. libUMP.so and libUMP.so.3
<clements__> yes
<libv> which part of "00:13 < libv> clements__: check if there are any other instances of libUMP installed" did you not comprehend?
<clements__> i did look..
<clements__> ok thanks for your help.
clements__ has quit [Quit: Leaving]