<rellla>
this is the first one i want to get merged. to find people testing it and getting the patch into sunxi-3.4
cnxsoft has joined #linux-sunxi
<jemk>
i never tried to change parameters, but the default looked normal
vishnu_ has quit [Ping timeout: 260 seconds]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-sunxi
<rellla>
i will make a feature branch test enable testing it separately. the kernel code is surely wrong. and the (new) libvdpau code works as expected, though it looks complicated :p
<jemk>
if all kernels are patched we can merge it
<jemk>
but i don't want to have *.patch files in libvdpau-sunxi
<MoeIcenowy>
and I have a full lichee and android sdk
<libv>
MoeIcenowy: for a first stab that's quite good
<MoeIcenowy>
it's on china's baidu netdisk
<libv>
MoeIcenowy: try to write up a howto that mimics the one for the early sunxi socs as well
<MoeIcenowy>
I may fork from a current 7-inch tablet's page
<libv>
MoeIcenowy: there is a device page example.
<MoeIcenowy>
but forkking is more easy
<MoeIcenowy>
as many A33 7-inch tablets share same parts
<libv>
MoeIcenowy: start from scratch, and maybe people like me will have less trouble cleaning those pages up in future.
<MoeIcenowy>
ok thx
<libv>
you can oggle the other pages as much as you like, but try to do so on each individual point instead of doing it for the full page, you will miss less stuff that way and not repeat mistakes made on other pages.
<MoeIcenowy>
libv: should I include some necessary chinese characters (for example brand)
avph has quit [Ping timeout: 255 seconds]
<libv>
MoeIcenowy: in the identification section, yes
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
avph has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
premoboss has joined #linux-sunxi
<MoeIcenowy>
libv: Why can't I find the new page special page?
<swiftgeek>
i saw wiki i just don't know whether axp209 charges battery on its own, and whether driver is for just fuel gauge/control
<KotCzarny>
i think some control of the charging is still done from os
<KotCzarny>
you can set table of voltage vs capacity
<KotCzarny>
(at least someone suggested that if one doesnt want to charge to 100% every time there is a way to set max voltage to lower limit)
<swiftgeek>
that's great :3
<KotCzarny>
i might be wrong because i didnt test it yet (still have to buy me conenctor
<swiftgeek>
i just used dupont and extremely old phone flat cell with a13, works surprisingly well
<KotCzarny>
but, easy test if charging is done without os is to just connect the empty battery and wait some time, then check voltage
<KotCzarny>
(and yes, i would like to know the answer too)
<swiftgeek>
another thing is shutdown issue
<swiftgeek>
it powers down nicely i guess but after that there is not much response to power button
lemonzest has quit [Quit: Leaving]
<swiftgeek>
sigh i should check voltages first probably, whether pmic is actually ~off for real
gzamboni has quit [Ping timeout: 240 seconds]
<swiftgeek>
now there i things that i completely don't get from wiki - does mainline uboot supports nand boot?
<ssvb_>
swiftgeek: it just happens that the people working on nand support in u-boot despise documenting their work
<ssvb_>
so it might be working fine, or it might be not quite ready yet
<swiftgeek>
it would be nice to boot uboot from usb/sd and then write nand from there
<ssvb_>
somebody just has to take a look at the nand code and check whether it is any good
gzamboni has joined #linux-sunxi
<ssvb_>
jemk: my understanding that this kodi stuff has always been more political than a technical issue
staplr has joined #linux-sunxi
<ssvb_>
from my (very subjective) point of view, kodi is not any better than mplayer/mpv, but unnecessarily pulls in a proprietary dependency (the mali blob)
<ssvb_>
that's why I tried to stay away from it
<jemk>
well, i prefer mpv too and won't actively work on kodi, but i'd like to help making libvdpau usable there
<ssvb_>
I already had more than enough fun with the libhybris wrapper around the android cedar blob, the sunxi-fel hacks to workaround the FEL USB boot BROM limitations and the mali support in X11 (again, lots of workarounds for a number of ugly things)
<ssvb_>
yes, mosterta did a good job and surely deserves our support
<ssvb_>
his kernel patches look reasonable to me
<patap>
I'm pretty sure that in current state uboot doesn't (a
patap has quit [Quit: Page closed]
<jemk>
ssvb_: i just wonder if we could run into problems with the ioctl he added to get the physical address
<GeneralStupid>
ssvb_: from my point of view kodi should easily switch between video players
<GeneralStupid>
i just take sketchy look at their code base but it could be more module based for me
<ssvb_>
jemk: well, framebuffer drivers can also report the physical address (via 'smem_start') and this does not directly cause any problems by itself
<ssvb_>
but the code which has permissions and tries to use this physical memory address (for writing) should be surely careful
<ssvb_>
moreover, the allwinner's sunxi-3.4 kernel is insecure by design and we can't make it much worse :-)
staplr has quit [Ping timeout: 276 seconds]
<jemk>
thats true ;)
<jemk>
but if for some reason the cma backend isn't used it might break
<jemk>
if i understand it correctly ump doesn't necessarily provide contiguos memory by default
<ssvb_>
it just should break gracefully with a helpful error message
<ssvb_>
as for the ioctl, it is probably not a very good idea to put it into the same enum as the other ump ioctls
<mripard>
ssvb_: that's a bit unfair. The work on the NAND is not documented because it's far from stable at the moment. Both at the programming and usage levels.
lerc has quit [Read error: Connection reset by peer]
staplr has joined #linux-sunxi
<alexxy>
mripard: may be you know how to use nand on cubietruck with mainline kernel? (with some patches?)
lerc has joined #linux-sunxi
staplr has quit [Quit: Leaving]
<mripard>
alexxy: read my message above
<mripard>
it's not stable
<mripard>
as in "you'll lose data'
<alexxy>
mripard: its not a problem =D
<alexxy>
i'll give'em a try
<alexxy>
problem that its somehow undocumented at all
<mripard>
it's undocumented because we don't want people to use it.
<ssvb_>
mripard: alexxy just wants to have u-boot on nand
<ssvb_>
and this is a lot less challenging feature to implement
<alexxy>
ssvb_: mripard: if its possible to put u-boot to nand to boot system directly from sata hdd
<alexxy>
then it will be cool
<alexxy>
i have cubietruck board
<alexxy>
i see that there is some nand driver for sunxi in mainline linux, but no definitions for it in dtb
<ssvb_>
the BROM searches for the SPL at several locations (some level of redundancy exists) and verifies checksums
<alexxy>
i dont expect that it will be rock solid stable
<ssvb_>
yes, putting u-boot in nand should be possible, but it is very poorly documented
<alexxy>
but if it will work somehow, then it will be enough
<alexxy>
i tested btrfs almounst from its begining
<ssvb_>
somebody just needs to review the code, fix the remaining crap and properly document it :-)
<alexxy>
i only see somewhere in mail list that u-boot-spl.bin should be written to mtd0
<alexxy>
but there no definitions for it
<alexxy>
there some in bbrezillon tree for 4.2-rc1 kernel
<alexxy>
but i'm not sure that they are suitable for u-boot
<ssvb_>
if we can trust mripard, the current mainline mtd code stinks
<ssvb_>
you can probably also try the allwinner's nand tools to see if they can do the job
<mripard>
ssvb_: it's easier, but not trivial
<mripard>
you still have to generate an image with the ECC embedded in it, that depends on the NAND chip you're using
deskwizard has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
deskwizard has joined #linux-sunxi
MTO has joined #linux-sunxi
<MTO>
Hi! I'm hoping to boot debian on a pcDuino8Uno, which has an allwinner H8 cpu. On the wiki identification guide, there is no mention of H8 at all. Am I barking up the wrong tree when looking at sunxi in the hopes of getting a working U-boot?