<bonbons>
nahom: you might have some more success (though no GFX accel and some missing features) with mainline kernels (4.1.x or even 4.2rc) and using device-tree
<bonbons>
not sure about compatibility or how FEX info must be passed to 3.4 sunxi kernels from mainline uboot...
<bonbons>
nahom: which version of uboot are you using? it might be that your uboot and your kernel are not compatible...
<bonbons>
nahom: which uboot did you use?
<bonbons>
nahom: maybe you need to ask uboot to set console=ttyS0,115200 on kernel cmdline (and note that you should have a kernel that matches uboot in device-tree versus fex)
<bonbons>
nahom: sure you didn't mix TX and RX while connecing?
2015-06-08
<bonbons>
bgola: there is no mainling u-boot version that fully supports nand as far as I know (though there are patches on the mailing list)
2015-03-21
<bonbons>
then it should probably display something (unless improperly configured or your device is not sufficiently supported)
<bonbons>
sillysnowflake: depends on uboot version, older ones only know serial console
2015-03-06
<mzki>
bonbons: thanks for the suggestions, i'll try and look for options
<bonbons>
no, I don't (maybe it's even doable with simple chip-select change at middle of scan-out) though then it mostly depends on what your displays accept as input
<mzki>
bonbons: do you know of any such chips?
<bonbons>
or with a proper chip in between also have your two displays seen by SOC as a single larger one
<bonbons>
mzki: not optimal, but you could connect one display via SPI and push framebuffer to it on change
2015-03-04
<mzki>
bonbons: I mean what for instance the A10 datasheet refers to as "HV-DE-Sync(digital parallel RGB)"
<bonbons>
from libv's presentation at FOSDEM 2014 at least A20 can drive two displays (though with some limitations).
<bonbons>
mzki: what do you mean with "via RGB"?
2015-02-16
<bonbons>
graphics memory tends to be the same as system memory... and a quick calculation tells me 2GB/s bandwidth are needed to just refresh display with 4K at 60Hz
<bonbons>
leviathanch: isn't memory bandwidth one of the bigger issues to drive 4K screen and populate it with smooth animated content (and still to something else in the background)?
2015-02-07
<viccuad>
bonbons: many thanks
<bonbons>
viccuad: using recent uboot (2015.01) and recent mainline kernel with simplefb would give you a framebuffer on whichever output is available when uboot starts up
2015-01-29
<bonbons>
you would probably need to "configure" the gpio with pinctrl first but I don't know the details... (you can automate this via dts file, take a look at how LEDs are defined in there)
<flok420>
bonbons: 3.4 kernels had the gio
<bonbons>
if it was for 3.4 sunxi kernel, then some details of the FEX file were not ported to device-tree. In that case it's also important to note exactly which board you are using
<bonbons>
flok420: for which kernels did the naming work as expected?
<bonbons>
it's know that the website has some trouble, a few disk failures keeping the machine from booting (properly)
2015-01-17
<bonbons>
ok, that's fex. Check your boot partition for fex/bin files, your system definition should be there
<bonbons>
raffahacks: kernel version you can check with `uname -a`
<bonbons>
with that information it's possible to tell you where to look further
<bonbons>
let's turn the question the other way around, what do you have software side: uboot, kernel (userspace distro I don't care)
<bonbons>
`ip link list` is the best offer I have, next would be looking at your platform meta-data (as I don't know what kernel you are using, hard to guide you)
<bonbons>
those ARM busses are not runtime-discoverable as are USB or PCI, thus what is connected and how SOC pins are to be multiplexed must explicitly be described in platform data (fex, dtb)
<bonbons>
it should be described either via fex (3.4 linux-sunxi or android kernels) or device-tree for mainline kernel
<raffahacks>
Thanks bonbons, in that case how can I see if it's attached or if it is not?
<bonbons>
raffahacks: are you sure the wifi is be usb-attached? On ARM it often is attached via a different bus
2015-01-05
<Faisal>
bonbons: thanks, that makes sense actually
<bonbons>
(no acceleration, no modesetting, just like vesafb on desktop)
<bonbons>
faisal: because uboot sets up the display engine and kernel then only takes over pre-configured hardware and uses it as bumb framebuffer
2014-11-30
<bonbons>
so looks like either you have some rather different (mainline) kernel version than I or you have not selected the right options for gmac. I'm on 3.17.2
<bonbons>
iuno: here it's saying only: stmmaceth - in my config: CONFIG_SUN4I_EMAC=y, CONFIG_STMMAC_ETH=y, CONFIG_STMMAC_PLATFORM=y, CONFIG_DWMAC_SUNXI=y
<iuno>
bonbons: from dmesg: sunxi_emac Using MAC from SID: 02:c5...
<beboom>
bonbons: I will try to patch the uboot and see if it can boot my A10s from NAND. Thank you very much !
<iuno>
bonbons: well I guess I missed that point, thank you. anyways, ifconfig showed a mac adress
<bonbons>
beboom: dig around on sunxi mailing list
<bonbons>
iuno: but make sure you have a MAC address configured in uboot or you network scripts!
<bonbons>
iuno: network works fine here though lossy TX when running at gigabit speed
<bonbons>
can't tell for sure, but vanilla mainline uboot doesn't unless I missed something recent
<beboom>
bonbons: can u-boot recognize the NAND ?
<bonbons>
s/MMC/nand ;)
<bonbons>
beboom: last I read on mailing list there are patches floating around to accessing nand but with caveats. So it's try and see/fail to boot from MMC with mainline
<beboom>
bonbons: do you know if is it possible to boot from nand instead of MMC ?
<iuno>
bonbons: thanks, I guess I'll just wait for a UART cable to arrive or go on trying with the network. Do you have any tips for that?
<bonbons>
or you could do with a USB-HDMI adapter and use corresponding KMS driver ;)
<bonbons>
iuno: in mainine kernels there is no display driver (yet), so you need UART or working network
2014-11-09
<bonbons>
libv: as far as I know, autofs is not mandatory for systemd while fhandle and cgroup (not controllers) are
2014-10-23
<nabblet>
bonbons: hramrach_ leio thanks for your advice
<bonbons>
nabblet: Gentoo updates fine here - though running mainline, but don't know why 3.4 would cause any Gentoo specific trouble...
<bonbons>
dack: check your logs and make sure debug logging is enabled
<dack>
bonbons: I have connmanctl with "monitor on"... it keeps telling me the "ethernet" connection is "unchanged"
<dack>
bonbons: yeah, I'm pretty sure I had it working before, so I'm not sure what's changed... my config has remained the same and I think the connman version has remained the same. Something in linaro, I suspect.
<bonbons>
if I remember well you can tell connman to be pretty verbose on what it does, so it should be able to tell you if it gets informed
<bonbons>
dack: connman does detect link going down here (though not tested on sunxi device) - so unless your device does not properly send the notifications your connman configuration needs revisiting?
<bonbons>
it's up to your userspace to unconfigure things if it wants to
<bonbons>
dack: linux keeps interface configured, even if link goes down
2014-09-17
<Wes->
bonbons: Just fine. It's a Lenovo IdeaTab FWIW. Even more interesting: if I toggle either USB Tether or USB debugging on the device during the detect...fail cycle, it breaks the cycle and the driver loads. Even if USB debugging is *pre-checked* it doesn't work. (can't pre-check Tethering on this device, it is reset with each USB insertion)
<bonbons>
Wes-: how does that same device behave on other usb controllers?
<Wes->
bonbons: wierd, isn't it? Bus is definitely powered, no hub, and works okay with other peripherals. Interestingly, it triggers a USB power event on the device (and android tablet) for each cycle of detect...failure
<bonbons>
Wes-: that looks rather like a problem on USB bus, maybe your USB bus is not powered and just detects that there is something on the data lines?
2014-09-13
<bonbons>
libv: hope you have running 3D acceleration on the eeepc, otherwise ubuntu with unity will be a real patience fight!
2014-08-18
<bonbons>
wens: for the AXP, it may be a rather subjective decision on which ADC to put under power_supply class and which ones under hwmon...
2014-08-16
<mawe242>
bonbons: ok, thanks. then I've got some other problem i guess.
<bonbons>
mawe242: probably works as well, though beware of register size (int or char or short) - but if you are going to reuse the value multiple times take care of volatile or copying it to a variable
2014-08-15
<rafaelMOD>
bonbons: You are right. I was biased by Itead Coreboard + Iteaduino that implements a different scheme, they use a pullup with 3.3V in VBUS, really strange.
<bonbons>
rafaelMOD: axp does have USB connection detection and even triggers IRQ when USB gets connected
2014-08-14
<bonbons>
rafaelMOD: yes, that's the way it is
2014-07-27
<bonbons>
libv: if stuff was documented properly it would all be boring!
2014-07-24
<Turl>
bonbons: at least it's got online= :P
<bonbons>
Turl: maybe no battery but still such a node :)
<bonbons>
at least a look at /sys/class/power_supply/ should tell on your system, which nodes to you have there?
<bonbons>
ok, will see how it looks here on mainline for those regs. 3.4.x does fill them with data, though would have to check if there is some bail-out for "no battery"
<bonbons>
Turl: which kernel is it, sunxi 3.4.x or mainline?
<bonbons>
your 0xC? and 0xBA/0xBB regs do contain a few values, so probably also configured OCV
<bonbons>
Turl: sure - my 0x03 is 0x41 - AXP209 on cubietruck
<bonbons>
can people share their values for reg 0x03 on AXP PMUs ()? Might be a PMU identification byte according to power-supply code
<Turl>
bonbons: try to make sense of them and document them on the wiki :)
<bonbons>
should I just poke at them the same way?
<bonbons>
how should I proceed, Xpower's AXP driver is poking at undocumented 0xB? and 0xC? registers (apparently for OCV - open circuit voltage - for battery gauge?)
<mripard_>
bonbons: plus potentially some other components, like the CRTC, the interface controllers, etc.
<bonbons>
:)
<bonbons>
so with simplefb and the like just the display engine is concerned - to use the right term
<bonbons>
mripard_: then inaccurate terminology from my side
<libv>
bonbons: everything except the display engine takes stuff from some memory and sticks it into some memory
<mripard_>
bonbons: it ends at when the computation are done
<bonbons>
sure, but where does processing end? at byte thinking or converting to electrical signal on a connector?
<mripard_>
bonbons: well, a GPU is a Graphics Processing Unit.
<bonbons>
mripard_: depends on how you define GPU, but sure for SOCs it's not a "single piece of HW" as it's for x86.
<mripard_>
bonbons: you can have a DRM/KMS driver without a GPU, and a GPU without a DRM/KMS driver
<bonbons>
so KMS driver would be in charge of taking over and then disabling whatever is not needed with all outputs are shut down - that's assuming GPU has been announced in ftd/fex
<bonbons>
simplefb (or simpledrm) are too simple for that as they just assume a memory area they got told about it show somehow to the user
<bonbons>
for headless the best certainly would be to disable (or not enable) GPU on bootloader side. For anything else either platform or whatever driver takes over should be able to undo things
<libv>
bonbons: display is enabled or disabled at boottime
* bonbons
out to lunch - back later
<bonbons>
libv: disable vesa via int10 (in boot-loader), then start your kernel with vesafb driver (maybe even later with kexec?)
<bonbons>
just write nice black picture to framebuffer an be done with it
<bonbons>
libv: not at all I guess
<bonbons>
libv: how does x86 behave if you do so and still load vesafb?
<libv>
bonbons: the only proper solution is for the platform code to be smart about it all, and to be knowledgeable enough to disable the display.
<bonbons>
later framebuffer swapping would then release that memory are
<bonbons>
for b) I think the kms driver could consider the simplfb framebuffer area as initial framebuffer
<libv>
bonbons: but you could disable vesafb through the int10 vbe interface
<bonbons>
it's meant as a replacement for vesafb to have a framebuffer device until whatever better GPU driver takes over (like mod-probe later during boot process)
<bonbons>
it should know about the platform firmware-setup framebuffer - as it takes over the GPU/Display device
<bonbons>
because there will be someone who just builds in KMS driver and no simplefb/simpledrm!
<bonbons>
that one could consider it reserved until informed by non-generic GPU driver that it took over from simplefb (or just unused platform frambuffer device!)
<bonbons>
who manages that cma area?
<bonbons>
from drivers/video/fbdev/core/fbmem.c
<bonbons>
the kick-out is triggered by remove_conflicting_framebuffers()
<bonbons>
once kicked-out the simplefb does not exist anymore, and I don't think and platform can resurrect it at a later time (except by creating a new platform device for it)
<libv>
bonbons: read my statements again
<bonbons>
the kick-out is done by conflicting resources during fbdev registration
<libv>
bonbons: i understand all that.
<bonbons>
when a proper driver for the GPU gets loaded it is expected to kick out simplefb
<bonbons>
libv: if I recall correctly simplefb is the generic variant of vesafb. It gets the pointer to the memory from a platform device (display_info or screen_info, don't remember exact name)
<Turl>
bonbons: got the link handy so I can have a look?
<bonbons>
Turl: not sure I read the schematic correctly, especially the page 6 with SATA power block. Is the BOOST-5V connected to SATA-5V?
<Turl>
bonbons: you could have a look at the schematic
<bonbons>
with rootfs on SATA that's slightly annoying ;)
<bonbons>
booting with both connected power is distributed on both, booting with just power plug and connecting OTG later on power plug provides all of the power - didn't try adjusting configuration yet
<bonbons>
could this be a APX configuration issue or is it just a design limitation of CT?
<bonbons>
when booting with just OTG as power source SATA disk remains unpowered
<bonbons>
when I plug in both power connector and OTG to USB power plug I get system working. If I unplug power plug (just otg remaining) SATA disk gets power cut but otherwise system continues running
<bonbons>
anyone knows how SATA (disk) power is wired on cubietruck? According to my testing it seems not to be via APX or at least in a way incompatible with VBUS (OTG connector)
<bonbons>
bbrezillon: above question might for apx20x might be of interest to you to as you are doing axp22x
<bonbons>
does it make sense to leave just the DATACACHE as cached and have all the others volatile?
<bonbons>
e.g. ADC regs for reading voltage/current should not be cached as aging measurements are not that useful!
<bonbons>
should I just mark all those regs I care about and that get changed by hardware as volatile (as are IRQ ones) or shall a call regcache_drop_region() for those regs I care about before reading them?
<bonbons>
ccaione: you put most of the registers of axp20x as cached within regmap, is there a good reason for this?
2014-07-21
<bonbons>
the battery driver though will be more work
<bonbons>
anyhow, the vbus/usb, ac and backup-battery (for RTC) parts are getting into shape
<bonbons>
it probably was too late yesterday when I looked at it!
<bonbons>
oh, Ok I think I see what I missed, the regmap_irq_get_virq() call
<bonbons>
with irq = platform_get_irq_byname() which is successful and returns 1-digit positive values
<bonbons>
well I get -EINVAL for devm_request_any_context_irq(&pdev->dev, irq, handler_fn, 0, "some-string", pdev)
<ccaione>
bonbons: not really. If you follow the pek driver example you should be able to use the IRQs
<bonbons>
ccaione: do I need something extra to use the interrupts with drivers/mfd/axp20x.c? I defined IRQ resources there as you did for pek input driver, then behave the same in my probe function but get -EINVAL
2014-07-19
<bonbons>
I'm looking at assembling power_supply subdrivers for your axp20x MFD driver
<bonbons>
ccaione: any idea where the axp20x device tree patches are on their path to mainline? Looking at 3.16-rc5 I don't see them...
2014-07-16
<bonbons>
I didn't look at whatever tcp-offloading options there are that might break/unbreak things - running on defaults
<bonbons>
previous and later packets of the connection get through, with SACK hint for the missing packet(s) but usually it does not recover
<bonbons>
though it looks more like it's a packet the driver/hardware does not like as usually it kills the corresponding tcp connection
<bonbons>
Turl, Dodger78: for CubieTruck ethernet, I seem to be seeing the TX issues as well, on 3.4.x kernel as wells as 3.16-rc
2014-05-24
<bonbons>
not seen it yet on reboot (as far as I remember), but reboot is not nice to SATA disks as it does not stop the disk before resetting (and thus cutting SATA power)
<bonbons>
mnemoc: seems to happen mostly on shutdown -h -> power-on via power button.
<mnemoc>
bonbons: that means it didn't see the mmc
<bonbons>
in practice as well, but not sure why sometimes it likes to boot from nand instead of mmc
<bonbons>
looks better from dmesg side... (ct/sunxi-3.4 branch)
<bonbons>
will try
<ssvb>
bonbons: maybe some other patches are also missing? you can probably try to compile the cubieboard kernel fork and check if it works
<bonbons>
which means it's not poking at the i2c registers at all
<bonbons>
ssvb, mnemoc: seems not to help, dmesg says: "rtc: get i2c master0 failed"
<bonbons>
ssvb: hm, how do I get github to present me raw patch?
<ssvb>
bonbons: if you confirm that it really helps, then mnemoc may probably sanitize and apply it to the stage/sunxi-3.4 branch
<bonbons>
anyone know how rtc is powered on cubietruck? When I shutdown (sunxi 3.4.x kernel), pull the power cable, wait 5 minutes, plug cable back in rtc time is lost (and cubietruck boots immediately while I would expect it to stay off until pressing power button)
2014-05-20
<RzR>
bonbons, I figured out
<bonbons>
(if you have no initrd replace $initrd_addr with a dash)
<bonbons>
rZr: does your uboot support device-trees? if so `bootm $kernel_addr $initrd_addr $dtb_addr`
<bonbons>
sure, but being able to recover makes debugging easier :) - you may also want to `echo t > /proc/sysrq-trigger`and capture dmesg again in order to determine what all tasks (kernel threads and processes) are doing, if you have some deadlock that lock should be visible
<bonbons>
otherwise your rootfs is hosed anyhow (but you may still be smarter :)
<bonbons>
with multipath you can unplug your usb device and plug it back (hoping it unfreezes the usb stack) or do the unbind+bind, then reassign it to the upper device-mapper layer and continue using your rootfs
<bonbons>
hm, one way of playing could be to unbind and re-bind the usb hci - but be sure to capture kernel log (dmesg) whenever you can
<bonbons>
that way when the usb device comes back it can be reconnected below your rootfs and resume operation of your system
<bonbons>
one option "around" that would be to put single-path multipath layer between your usb storage device (/dev/sdX) and the rootfs
<bonbons>
not however that any usb disconnect will ruin your rootfs as it would cause the usb storage to obtain a new /dev/sdX node
<bonbons>
well, in that case, put a statically compiled busybox on a tmpfs and let it listen on ttyS0 so you can still access your system
<tipolosko>
bonbons: seems that usb controller is locking, not the whole kernel
<bonbons>
Tipolosko: if it's the kernel that is hardlocking (usually panic) your best bet would be recoding output on serial console
<bonbons>
Lumocolor: but you should be able to talk to that chip from userspace via one of the /dev/i2c* nodes
<bonbons>
well, that depends if your kernel already has the drivers (sunxi i2c probably yes, for the chip on sparkfun board, that's a different question)
<Lumocolor>
bonbons: so it looks like editing the fex text file then compile it into a bin and copy and paste then done? no recompiling of the kernel
<bonbons>
(but for cubietruck there is probably a bug in power-off sequence sent to AXP as power-off usually fails when battery is connected)
<bonbons>
as far as I understood, to get expansion ports doing what you want you will have to change FEX file (to assign appropriate function to the pins of interest)
<bonbons>
cubietruck has one, not sure for the older two
<Lumocolor>
bonbons: I don't see one. olimex has builtin bat chargers
<Lumocolor>
bonbons I don't see one. olimex has builtin bat chargers
<bonbons>
Lumocolor: dont all cubieboards have built-in battery controller? (which lists battery status in /sys/class/power_supply/battery/)
2014-03-30
<bonbons>
out of the box I only get scancodes for twinhan remote control and a kenwood one, but none for the sony or jvc I have around
<bonbons>
has anyone played with sunxi_ir (various types of remote control, to capture e.g. sony remotes, jvc remotes, ...)?
<bonbons>
:)
<hramrach>
bonbons: you are probably one of the two or so people using battery with an a20 devboard. The driver and settings needs more testing
<bonbons>
(uart connected in both cases)
<bonbons>
hramrach: with connected battery android fails to power-off and reboot, with disconnected battery it shuts down properly
<bonbons>
hm, the android is not that much better at getting shutdown right, some tries it works, others it just reboots
<hramrach>
bonbons: with disconnected UART the board should power down completely
<bonbons>
sometimes system even reboots instead of halting
<bonbons>
hramrach: exactly (and even trying with disconnected uart I get same results)
<bonbons>
and shutdown from android that's present on nand works fine
<bonbons>
the uart cable has only rx/tx and gnd connected
<hramrach>
bonbons: disconnect the UART cable
<bonbons>
On Cubietruck, with 3.4.79 kernel (as with 3.4.61) shutdown does not happen properly. The red power-led seems to remain powered by the rtc battery and pushing power button causes board to boot from nand instead of mmc
2014-03-23
<bonbons>
but yeah, those initrds are a pain (especially when kernel refuses to start, in a silent way, when it dislikes the initrd), even on x86/amd64
<bonbons>
peterbjo1nx: you may try to build the initrd into the kernel binary
2014-03-18
<bonbons>
adding "select WEXT_PRIV if WIRELESS_EXT" to config BCMDHD in drivers/net/wireless/bcmdhd/Kconfig fixes the build
<bonbons>
defconfig includes pretty much all available wireless drivers!
<bonbons>
not sure yet what (other wireless driver?) from defconfig select WEXT_PRIV...
<bonbons>
drivers/net/wireless/bcmdhd/wl_iw.c fails to build if WIRELESS_EXT is set but WEXT_PRIV is not...
<libv>
bonbons: store your current .config, then start with sun7i_defconfig, and then work your way back
<bonbons>
will try again after lunch, first getting back to more modular configuration in the hope of getting something that builds
<bonbons>
I agree with both of you
<bonbons>
yeah that's the other useful part of it, just a single file (kernel) to care about
<bonbons>
but yes, that might be incompatible with distro aproeach and vendor drivers that only work as modules :/
<libv>
bonbons: please do measure bootup time.
<bonbons>
I like kernels with fewer modules so hw gets initialized more in paralell during early boot instead of serialized module loading
<bonbons>
I took the config from cubietruck ubuntu kernel, then switch some items from modular to built-in
<libv>
bonbons: did you build a defconfig?
<bonbons>
ump_dd_secure_id_get symbol missing and a second one
<libv>
bonbons: what do you mean with ump/mali "area"
<bonbons>
:), any idea for the ump/mali area?
<bonbons>
eek, bcmsdh_probe is exported 5 times through sunxi-3.4 tree!
<bonbons>
trying to build kernel (sunxi-3.4) with most sunxi drivers built-in I end up having symbol errors, is that expected? (e.g. bcmsdh_probe exported twice, ump_dd_secure_id_get undefined)