<oliv3r>
i only followed half of it, but what if my board only has 32 MiB ram?
<oliv3r>
linux is happy with 16+ afaik
<oliv3r>
or even 8 if you have a small kernel I guess
paulk-collins has joined #linux-sunxi
<paulk-collins>
you guys aware of the PengPad devices?
<paulk-collins>
PengPod*
<oliv3r>
paulk-collins: of course
<mripard_>
oliv3r: it's just a mapping
<oliv3r>
mripard_: so no relation at all?
<mripard_>
it doesn't mean that you actually have enough RAM. just that it sets up a virtual->physical mapping for 256MB
<mripard_>
that's all
<paulk-collins>
oliv3r, can it be used with free u-boot, does the linux-sunxi kernel work on it?
<paulk-collins>
for some reason RMS is asking me to evaluate that tab
<oliv3r>
paulk-collins: ah, you are with the fsf? :)
<paulk-collins>
oliv3r, we are in touch with them, a lot
<oliv3r>
paulk-collins: pengpod is pretty much like any A10 based device, it's just some OEM tablet rebranded to pengpod
<paulk-collins>
and since yesterday, they also accept donations on our behalf
<oliv3r>
that said, neal (a regular here) does try to support it as good it can
<paulk-collins>
oliv3r, ok
<oliv3r>
so anything that relates to A10 in general, relates to pengpod equally
<paulk-collins>
but I mean, usually, there is board-specific u-boot support to add
<oliv3r>
If you want to speak of A10, the SoC, as to the GPL; we're quite good
<rm>
Realtek wifi => binary firmware, Mali GPU => no 3D or any acceleration of note, without binary blobs
<rm>
also boot1/boot0 are proprietary and upgradeable via livesuit
<oliv3r>
any A10 based device, can boot from either NAND or uSD
<rm>
afaik
<oliv3r>
rm: they are not proprietary anymore :)
<paulk-collins>
oliv3r, so the fist stage looader that is in the uboot tree would work too?
<oliv3r>
paulk-collins: currently, we have very very basic nand support in the opensource u-boot, basically, that is not usable yet
<paulk-collins>
yes I'm aware :)
<oliv3r>
as for uSD boot, that's 100% GPL boot :)
<paulk-collins>
good
<oliv3r>
the only requirement we have for any a10 soc is; the SoC has the MMC pins connected properly (as we can only boot from mmc0)
<oliv3r>
the one problem that you might have, is that the BOOTROM (embedded in the soc) is closed (and unchangable)
<oliv3r>
it is very likly GPL violating and lkcl and allwinner are sorting that out in time
<paulk-collins>
yes I know, but RMS doesn't care about that :)
<paulk-collins>
so I'd say we're good
<oliv3r>
now if you use Allwinners booatloader (boot0 (u-boot-spl))
<oliv3r>
and boot1 (u-boot) then we're working on that oto
<oliv3r>
boot0 and 1 for A20 based hardware has been released in GPL form, but not all files are properly copyrighted yet and lckl is still working in getting sources for the other version
<oliv3r>
the big problem is however, the current code we have, does not appear to be what runs on most hardware
<oliv3r>
but since we have u-boot, it's a really low priority/issue
Offshore has joined #linux-sunxi
<oliv3r>
we use the code we have to make u-boort better, so all is good
<paulk-collins>
ok
<paulk-collins>
thanks
<oliv3r>
now as for the linux side, there's as rm said mali
<paulk-collins>
that's inevitable…
<oliv3r>
there's the hardware video accelator (cedarx, a gpl violating horror)
<paulk-collins>
that too
<rm>
and wifi, all A10 devices including WiFi come with some variant of Realtek 8188 (CU/CUS/EU)
<oliv3r>
which is being reverse engineerd :) so should be ready ina year or so
<rm>
afaik firmware for those is not FOSS
<oliv3r>
i think you are right
<oliv3r>
depending on your tablet, wifi can be an issue
<paulk-collins>
there is always a firmware indeed
<oliv3r>
pengpod does use the 8188 or 8192 realtek wifi chips
<paulk-collins>
indeed
<oliv3r>
well atheros firmware is open
<paulk-collins>
ath9k_htc, right
<paulk-collins>
I wonder about the touchsreen driver also
<oliv3r>
so with regards to GPL compliance, any A10 based device should be RMS's wet dream (and mine too :p)
<paulk-collins>
sometimes it needs a firmware too
<oliv3r>
yes, that largly depends
<oliv3r>
most touchscreen controllers we know, are simply specialized microcontrollers that require firmware
<oliv3r>
but most have it programmed in, and isn't really user serviceable
<hno>
mripard_, arokux1 , so why it worked then with no limit set? arokux1 what address did the FDT get relocated to then?
<oliv3r>
i think wingrime looked at the one for his controller and said 'if he had tons of time or source he could greatly improve it (chinese quality firmware, with bugs )
<paulk-collins>
I see
<oliv3r>
paulk-collins: the A10 soc has an internal (gpl) resistive touch screen
<oliv3r>
and capactivie is handled via an I2C controller
<paulk-collins>
I guess that's CONFIG_TOUCHSCREEN_SUN4I_TS ?
<oliv3r>
some touchscreens we have drivers for (check github.com/linux-sunxi)
<oliv3r>
paulk-collins: exactly
<oliv3r>
but nobody uses that really
<paulk-collins>
ok
<paulk-collins>
my a13 tab uses i2c too
<oliv3r>
yeah most all do
<hno>
some of the cheapest tablets and some game console do.
<oliv3r>
btw, when I say a10, i mean the whole sun[457]i range
<hno>
and OlinuXino.
<paulk-collins>
perhaps I'll get a pengpod then
<oliv3r>
oh really? I didn't know
<oliv3r>
paulk-collins: get a pengpod to support its development :)
<paulk-collins>
thanks for the infos
<paulk-collins>
yeah
<oliv3r>
but nearly all of them are the same, except for the touch screen controllers :)
<oliv3r>
but yeah, I think a10 socs are one of the most gpl friendly ones
<paulk-collins>
are there other allwinner tablets from developer-friendly companies out there?
<oliv3r>
paulk-collins: and! they run hansg's Fedora 19 image very well (which doesn't have any binary blobs afaik)
<paulk-collins>
nice!
<paulk-collins>
I'm more interested in Android though
<paulk-collins>
but that's great
<hno>
paulk-collins, Olimex have quite nice boards. Not tablets, but...
<paulk-collins>
yep I've seen that :)
<paulk-collins>
there are plenty nice boards
<oliv3r>
Olimex has open-hardware boards! they are amazing
<paulk-collins>
cubieboard seems really great too
<paulk-collins>
I even wondered whether I should get a cubieboard as home server, over a Marvell kirkwood soc
<hno>
cubieboard is smaller but much more restricted than OLinuXino.
<oliv3r>
yeah, tim cubie (of cubietech) is one of the reasons we have such great support imo
<paulk-collins>
that's nice
<hno>
Tom.
<oliv3r>
paulk-collins: as a home server, there's cubieboard 2, or olimeixno-a20
<oliv3r>
tom* sorry
<oliv3r>
Tiang-lang :p
<hno>
Yes.
<paulk-collins>
oliv3r, my problem is upstream debian support… the kirkwood plugcomputers have u-boot and kernel packaged and ready to go, debian-installer support, etc
<oliv3r>
and i always get olimex + linux typed wrong too :)
<paulk-collins>
that's really perfect
<oliv3r>
paulk-collins: his ist hat a problem? :p
<oliv3r>
paulk-collins: hno is working on getting u-boot support mainlined in time, but our tree is in sync with mainline
<paulk-collins>
good
<oliv3r>
paulk-collins: we just lack time to get it all hammered in submitable shape, except for mtd, functionality wise, it's all fine
<oliv3r>
(besdies the bugs we dont' know about yet ;)
<hno>
mtd isn't that far off.
<hno>
except time...
<oliv3r>
linux support is 2 fold, we have our 3.0 and 3.4 android kernels based on allwinner dumps; and we have preliminary mainline support, which for a server, isn't so bad, we have ethernet and CPU support :p so nfs root + initramfs is possibel :
<oliv3r>
yeah, i'm happy slapin_nb is back working on mtd
<oliv3r>
mtd support will be awesome
<oliv3r>
paulk-collins: as for A31 (their current quadcore offering) GPL wise, stay away from it with a 10 foot pole
<paulk-collins>
ouch, really?
<oliv3r>
paulk-collins: the SoC as a server is good, but the GPU is PowerVR
<paulk-collins>
ahh
<oliv3r>
which, as you know, is a pos :p
<paulk-collins>
no hope of anything free for powervr, but we can manage
<paulk-collins>
sometimes the Xorg drivers aren't so bad
<oliv3r>
but binary only :)
<paulk-collins>
no no, I mean the free ones
<paulk-collins>
like on omap
<oliv3r>
paulk-collins: there's free powervr stuff? or only 2D?
<paulk-collins>
you can run e17 in a pretty decent way
<paulk-collins>
only 2d
<paulk-collins>
but there is some sort of compositing support
<hno>
paulk-collins, 2d support is all GPL and even documented on Allwinner.
<hno>
including acceleration.
<paulk-collins>
good
<oliv3r>
paulk-collins: if I may be so ignorant and ask who you are and what relation you have to fsf/rms?
<oliv3r>
i'm just curious is all
<hno>
There was someone doing an EXA 2d acceleration driver for XOrg, but not sure what the current stat is.
<oliv3r>
the A10 soc has great potential, albeit slightly underpowered soc, but requires some manhours to get in good shape, all possible (with the docs we have)
<oliv3r>
paulk-collins: so if you know some FSF developers who want to write some code for the greater good, send them this way ;)
<paulk-collins>
oliv3r, well I'm mostly the main Replicant (fully free Android) developer and the fsf is very interested in our project (many people use replicant phones there), so they encourage us in many ways (they paid for a galaxy tab) and now they've lunched a directed donations support program
<oliv3r>
ohhh
<oliv3r>
paulk-desktop
<paulk-collins>
ah yeah
<oliv3r>
hi paul
<oliv3r>
lol
<paulk-collins>
I changed nick
<oliv3r>
i thought you knew all this allready!
<oliv3r>
what phones does FSF use specifically? S2?
<paulk-collins>
Well I was seeking specific infos about the pengpod, but about the A10, yes I knew most
<paulk-collins>
Nexus S iirc
<oliv3r>
if you would have said that you where paulk-desktop; then I could have given ya the short version :)
<paulk-collins>
RMS seems interested in ARM devices, he's very aware of allwinner and the work on reversing mali
<oliv3r>
making me type all that you allready knew ;)
<paulk-collins>
oliv3r, sorry for wasting your time :p
<oliv3r>
paulk-collins: well he should pad libv on the back, he's doing amazing work with lima :)
<paulk-collins>
yep, he knows that :)
<oliv3r>
if you learned anything new from it, it wasn't wasted ;)
<paulk-collins>
once I ate with him and he told me he though lima was one of our best shots
<paulk-collins>
thought*
<paulk-collins>
oliv3r, I didn't know about A31
<oliv3r>
well freedreno is in really good shape too
<oliv3r>
thanks to libv for inspriing rob clarke iirc
<oliv3r>
brb, loo
shineworld has quit [Quit: Leaving]
<oliv3r>
so what phone does RMS use ;)
mouchon has quit [Ping timeout: 250 seconds]
<tkoskine>
oliv3r: I think he doesn't have a mobile phone at all.
<mripard_>
or a GTA04 maybe ? you know, that phone with an OMAP, a libertas wifi chip, but is still endorsed by the FSF </troll> :)
Black_Horseman has quit [Remote host closed the connection]
<oliv3r>
libertas yeah, that was a big flop
<oliv3r>
from what i remember, libertas was supposed to be this all open wifi chipset, for the XO laptop
<ssvb>
paulk-collins: what is so good in omap free drivers for Xorg?
<oliv3r>
from what I know, libertas is pretty closed down isnt' it
<oliv3r>
paulk-collins, our new RMS hotline ;)
<oliv3r>
well a fully GPL-able phone should be usable by RMS i would think?
<ssvb>
paulk-collins: the commonly used omap hardware does not have 2D accelerator, so it's all software rendering for 2D graphics
<oliv3r>
llvmpipe!
<paulk-collins>
ssvb, they're faster than others
<mripard_>
oliv3r: yeah, FSF asked to put the firmware in a ROM on the board, and poof, it's not upgradable anymore, it's not part of the software, so it's not tainting the system, is it?
<paulk-collins>
the gta04 with e17 runs pretty well
<ssvb>
paulk-collins: faster than what?
<paulk-collins>
ssvb, than say, the openmoko freerunner
<paulk-collins>
than PowerVR on Exynos
<paulk-collins>
oliv3r, RMS wouldn't use a phone even if it was fully free
<paulk-collins>
he doesn't carry one because it can track his moves
<oliv3r>
while RMS IS my hero, I do agree with his viewpoints from many many angles, the 'firmware is not software' is simply not true (ANYMORE, it possibly used to be)
<ssvb>
paulk-collins: we should be doing a better job for xorg 2d graphics on sunxi hardware compared to omap
<paulk-collins>
and the gta04 is not endorsed by the FSF because of the firmware issue and powervr I think
<paulk-collins>
ssvb, I think you are, indeed
<oliv3r>
paulk-collins: he can turn all radios off when not in use (being fully free, it should be possible)
<paulk-collins>
oliv3r, agreed
<paulk-collins>
on the firmware point
<oliv3r>
firmware is just as much software, as u-boot is
<paulk-collins>
oliv3r, then how does he get incoming calls?
<oliv3r>
pff, who uses a phone for calls?
<rm>
perhaps he would use a wifi-only phone using SIP and routing all calls via Tor
<oliv3r>
check e-mail, surf the web
<rm>
that'd be actually very nice
<paulk-collins>
oliv3r, yeah, right
<oliv3r>
yeah, but lag etc would be horrible :)
<rm>
people are experimenting with VoIP over Tor (Mumble)
<oliv3r>
and he can make calls, or make an appointment for a call :)
<paulk-collins>
anyway he has a netbook, I guess that's as mobile as a phone
<paulk-collins>
he uses it anywhere
<paulk-collins>
like in a car, etc
<rm>
it's actually somewhat usable, in the Push-to-talk mode
<oliv3r>
rms is awesome, don't get me wrong, but sometimes his autism/paranoya is unfounded :)
<rm>
when you also have to say "Over" etc
<rm>
like on a radio
<rm>
half-duplex*
<oliv3r>
paulk-collins: what netbook does he have now? his old laptop was stolen :(
<paulk-collins>
oliv3r, though some of the decisions he makes are personal to him and he does't want them to apply to everyone
<paulk-collins>
oliv3r, a MIPS one
<paulk-collins>
a lemote
<oliv3r>
funny; introduce me to obama, i'd be done talking in 2 minutes; give me RMS, and we can talk for hours :)
<paulk-collins>
it has a free bios
<oliv3r>
lemote again?
<paulk-collins>
yeah
<paulk-collins>
I think they have many at the fsf
<paulk-collins>
basically when I met him, they were using a 3G to wifi thing
<oliv3r>
But chinese tracking chips! and hacked secret backdoors in chips!
<paulk-collins>
then we could connect to the wifi using the lemote
<paulk-collins>
he *
<oliv3r>
i bet the software in the 3G to wifi wasn't free ;)
<paulk-collins>
right
<paulk-collins>
but he doesn't care
<paulk-collins>
'cuz it's hardware
<oliv3r>
I do hope that RMS has someone to follow in his footsteps
<paulk-collins>
I don't agree
<paulk-collins>
ah yeah
<oliv3r>
he was right, 30 years ago
<paulk-collins>
(I don't agree to 'cuz it's hardware)
<paulk-collins>
people at the FSF are doing an amazing job
<paulk-collins>
but for the traveling around the world part, I don't know who's gonna be there
<hno>
paulk-collins, he have replaced the NAND flash with a ROM in his 3G dongle?
<paulk-collins>
hno, no it's not a dongle, it's like a box where you put a sim card and that creates a wifi network that he can connect to from his laptop
<paulk-collins>
anyway as long as the thing is not his, I guess it's not an issue if it's non-free (he doesn't check that every router he uses are running free software)
<hno>
ok, so it's most likely a GPL violating device even...
<paulk-collins>
why violating? there may be sources around :)
<hno>
with binary-only kernel modules, tons of firmware and all being compiled into a monotholic kernel..
<oliv3r>
<- proud sponsor
<oliv3r>
make monthly donations :)
<paulk-collins>
to the fsf?
<hno>
last time I met RMS he got depressed from learning that cars engines runs software these days.. and is upgradeable with the right equipment.
<oliv3r>
yep, fsf donation
<oliv3r>
personally, I say, firmware should be opensource just as much as software does. All the freedoms apply there equally
<oliv3r>
one can rationalize 'A pc is a black box, I don't care what it runs, as long as it works, it's all 'ROM'"
<paulk-collins>
oliv3r, I completely agree
<paulk-collins>
moreover I think loaded firmwares give better advantages compared to read-only ones
<paulk-collins>
since they can be reversed/replaced
<paulk-collins>
so it's a bit sad the fsf and rms are strongly opposed to loaded firmwares but are ok with read-only firmware
<paulk-collins>
however I agree no free system should distribute them
<oliv3r>
well the whole reason of the FSF existance is the X freedoms
<oliv3r>
the freedom to change a devices behaviour
<oliv3r>
the freedom to look at the code
<oliv3r>
the freedom to know that your not having a trojan horse
<oliv3r>
well, a read-only firmware can be just as bad as a trojan horse as a rw one :p
<oliv3r>
actually its worse, as you can't replace it with a free one :)
notmart has joined #linux-sunxi
<oliv3r>
but preaching to the choire here :p
<oliv3r>
if i ever meet him, i'll have a little chat with him :p
<paulk-collins>
oliv3r, don't count on that too much
<oliv3r>
ever meting him?
<oliv3r>
or chatting with him?
<paulk-collins>
having a serious talk with him
<paulk-collins>
the best way to have a real discussion with him is through email
<paulk-collins>
when you meet him, you barely have time to talk
<oliv3r>
he talks a lot
<oliv3r>
?
<paulk-collins>
because he's always running and never has time to settle down and have a talk
<paulk-collins>
basically if it's at a public event
<paulk-collins>
you won't get a chance
<oliv3r>
yeah, I understand :)
<oliv3r>
well i was just saying 'if' :p
<paulk-collins>
right :)
<oliv3r>
maybe i'll write him an e-mail :)
<paulk-collins>
yeah that's the way to go
<hno>
paulk-collins, he is not that bad to chat with.
<paulk-collins>
No sure, it was fun eating with him, though I would have expected to have more time for real discussion
<hno>
and the he knows the ROM:ed firmware is not good. It is an unfortunate effect of having to draw a border somewhere that can be explained.
<paulk-collins>
hno, indeed
<paulk-collins>
I understand that too
<paulk-collins>
I just don't make it my personal choice
<hno>
neithe rdo I.
<hno>
but it is his.
<paulk-collins>
though if the line was drawn where I put it, they just couldn't recommend using computers
<slapin_nb>
hno: hi, please ignore memalign issue
<slapin_nb>
hno: the problem had entirely different roots
<hno>
I have a more network oriented view. I don't mind distributing binary-only firmware, as long as that firmware runs in an environment that have no impact on my computing. I.e. a device connected over some slave bus with hard isolation of functionality.
rellla has joined #linux-sunxi
<hno>
At a first glance the RPi could apply, but it doesn't because there is no isolation.
<hno>
RPi GPU.
<oliv3r>
the ROM border is OKay if he says " I don't personally persuit it, but it should be on the FSF radar" He IS only 1 man and can only fight for so much
<oliv3r>
Personally, I do use firmware, as that's the only way to make the device work; but would much prefer open-firmware
<oliv3r>
the moment i can replace my rasbmc with axbmc (with reverse engineerd cedarX and lima) will be a happy day in my book
rellla has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
arete74 has quit [Ping timeout: 246 seconds]
<oliv3r>
gonna ebay a new PHY
<oliv3r>
only 2 euro's, so hopefully that fixes my cubie's ethernet :(
rellla2 is now known as rellla
arete74 has joined #linux-sunxi
vinifr has joined #linux-sunxi
pacopad_ has joined #linux-sunxi
<arokux1>
hno, "without the limit set" <-- I do not know what the address to which FDT was relocated was. will check it tonight.
<arokux1>
mripard_, how this initial mapping of 256MB relates to bootm_mapsize, which according to docs should limit the amount of memory accessible by the kernel during early boot?
<oliv3r>
mripard_: ping
hipboi has quit [Quit: Leaving]
<mripard_>
arokux1: well, you made the relation yourself.
<slapin_nb>
hi, all!
<mripard_>
oliv3r: yes?
<slapin_nb>
is there any lowlevel android gurus here?
<arokux1>
mripard_, but is this setting respected by the kernel?
<slapin_nb>
I need to force the damn thing to mount ext3 hdd on boot, is there any analog of fstab or something?
<mripard_>
arokux1: it's the other way around.
<mripard_>
the kernel creates a 256MB mapping during the early boot
<mripard_>
and u-boot has to put whatever is to be used inside those 256MB
<mripard_>
it's not passed in any way to the kernel
<mripard_>
the two just have to be consistent.
<arokux1>
mripard_, ok, but if bootm_mapsize is set to say 16MB, shouldn't the kernel just create mapping for those 16MB only?
<slapin_nb>
oliv3r: hi, do you know where rz2k's linux repo is, I want to look at the code, as I need to tune some strings in my head
<mripard_>
arokux1: I told you, the kernel has no way of getting whatever bootm_mapsize was
<mripard_>
plus, it actually needs more RAM than that.
<oliv3r>
mripard_: check your e-mail :)
<arokux1>
mripard_, what is the point of bootm_mapsize then..? from the doc: "... it
<arokux1>
defines the size of the memory region starting at base
<arokux1>
address bootm_low that is accessible by the Linux kernel
<arokux1>
during early boot ..."
<mripard_>
oliv3r: yeah, saw that
<mripard_>
arokux1: to relocate stuff within that initial mapping area
<vinifr>
many ADCs use clock source, but sunxi LRADC do not use, right?
<arokux1>
mripard_, sorry, but I'm not getting it..... suppose bootm_mapsize is 512MB, in that case kernel won't be able to access the second half of this memory. but according to the doc of bootm_mapsize it defines the size of the memory which *is* accessible by the kernel.....
<hno>
arokux1, docs are confusing.
<oliv3r>
i'll go fix some compiler errors and work on the next bit to push. btw, this is just to have something ou tin the public, not that it's 100% working or accurate :)
<mripard_>
arokux1: and the kernel doesn't care *at all* of bootm_mapsize
<oliv3r>
slapin_nb: turl is
<oliv3r>
slapin_nb: android has something like fstab, but its in your initramfs, which is built into the boot.img
<arokux1>
mripard_, i see, but then the promise of the uboot is false. (second half of 512MB isn't accessible by the kernel), right?
<oliv3r>
slapin_nb: if you want to modify that, there's a perl script called 'split_bootimg.pl' i think, that lets you split the boot.img (extracted from the boot partition)
<slapin_nb>
oliv3r: ah, too bad, I need to make ext3 disk appear without too much intrusion, I can mount it by hand, so I hoped it can automout for me :(
<mripard_>
arokux1: I don't see where it's promised such thing, but anyway...
<oliv3r>
slapin_nb: i don't know much about the android astrocities, but normally when you insert an SD card, that gets automounted
<oliv3r>
slapin_nb: but most 'core' stuff is in the initramfs, the rest in /system/etc, so poke in /system/etc to see if that helps you
<oliv3r>
slapin_nb: but confirm with turl, he's the real android man :)
<oliv3r>
Turl: ^
<hno>
arokux1, seems this info is in fact passed to the kernel on some architectures, but not on arm.
<arokux1>
mripard_, in the doc of bootm_size :( "size of memory region that is accessible by the Linux kernel"
<slapin_nb>
oliv3r: FAT, yes, but not ext3. Even my TV just mounts ext3, but these all android things can't :(
<oliv3r>
slapin_nb: maybe it's an option? maybe it only does ext4 :p
<slapin_nb>
oliv3r: if I type mount -t ext3 /dev/sdb1 /mnt it mounts ok
<oliv3r>
slapin_nb: i don't know what and why android automounts. if it's location (mmc0) or fs
<oliv3r>
yeah i mount tons of ext4 stuff in android
<oliv3r>
but even mount /dev/sdb1 /mnt doesn't work
<oliv3r>
mount on android is quite picky
<oliv3r>
picky = crappy :p
<slapin_nb>
oliv3r: USB fat32 disk of old win95 mounted ok
<oliv3r>
they may have changed the mount that it always tries to do fat mount, unless -t is specified? i don't know :(
<arokux1>
hno, you mean power pc? as in here- --> arch/powerpc/lib/bootm.c:91
<hno>
arokux1, yes, and also via lmb -> fdt on arches that uses lmb.
<hno>
Hm.. ARM do have CONFIG_LMB set, so info should be passed in the fdt.
<arokux1>
mripard_, ----^
<arokux1>
hno, question: is ftd analyzed during early boot?
<arokux1>
fdt*
<mripard_>
arokux1: find me the code in the kernel that uses this property then.
<slapin_nb>
Turl: ^
<hno>
arokux1, I do not know. I spend my time in u-boot and Linux device drivers.
<oliv3r>
slapin_nb: unfortunatly turl's time zone is like hours behind, so he's sleeping now :(
<hno>
Hm.. no I misunderstood the LMB code.
<hno>
thought it updated the fdt with info from lmb, but was the other way around.
<arokux1>
abybody aware if a _fast_ git server which hosts kernel?
<oliv3r>
git.kernel.org?
<arokux1>
if downloading android kernels from google server it is so much faster....
<oliv3r>
github.com/linus?
<arokux1>
oliv3r, *fast* :)
<oliv3r>
git.schinagl.nl?
<oliv3r>
:p
<oliv3r>
i don't think i have my kernel(s) there
<hno>
arokux1, github is usually quite fast..
<arokux1>
hno, try to use google git servers, you will redefine the notion of "fast" :)
<oliv3r>
arokux1: i have 100Mbit fiber, github looks fast to me
<hno>
arete74, allwinner A10/A13/A10s/A20 and maybe A31 is our focus.
<hno>
err. arokux1 I meant.
<oliv3r>
+ A31sd
<oliv3r>
-d
<arokux1>
ah, so the SoC itself, ok
<oliv3r>
sunxi stands for sun4i, sun5i, sun7i (and maybe sun6i)
<oliv3r>
the linux- bit is a bit deceiving, as we also do u-boot support
<oliv3r>
and anybody working on bsd or the like is more then welcome here
<hno>
and for the time being we also have to worry about a bunch of mangled touchscreen drivers and even worse mangled wifi drivers used on most boards..
<hno>
but done with a long stick..
<oliv3r>
done with a long stick?
<arokux1>
till now i find it amazing how much stuff fits into that SoC chip
<oliv3r>
arokux1: pretty much everything is in it
<oliv3r>
you can build quite extensive systems, if only drivers where better :(
<oliv3r>
i wonder if google would have used their soc for any device, if allwinner would have mainlined their drivers at the soc design stage
<hno>
oliv3r, yes, poking on the wifi & ts drivers.
<oliv3r>
we are done poking them with a long stick? so we are using a short one now? (Sorry i don't get it :(
<hno>
no, we are poking them with a long stick, hoping they stay put..
<oliv3r>
ohh ok
<arokux1>
are there any SoCs with wifi IP inside, or this is not possible in principle..?
<arokux1>
(maybe this is a stupid question..)
<oliv3r>
well you can connect wifi via USB
<oliv3r>
or via SDIO
leowt has joined #linux-sunxi
<oliv3r>
sdio == SD I/O e.g. those wifi adapters that fit in an SDCard reader/mmc slot
<oliv3r>
sdio requires more pins then usb and chips are usually a little bit more expensive (but have higher throughput i think and lower CPU overhead)
<oliv3r>
because the USB variant is cheaper, they pretty much all use those
<Kolyan>
Hello
<oliv3r>
hi
<hno>
arokux1, there is many SoCs with wifi inside, just look in a random WIFI router/bridge..
<arokux1>
hno, ah, ok
<Kolyan>
I have not found touchscreen driver at linux-sunxi source code but i found driver in other sources. But this driver made for rockchip based board, So i think i can modify this driver but i need to know what address should i use.
<oliv3r>
sadly, chinese comments got lost of the firmware
<oliv3r>
Kolyan: you should contact the manufacturer of the touch screen IC and ask for GPLed source code + firmware
<Kolyan>
oliv3r, ok, i will try to do this. Thanks.
<oliv3r>
it'll be very hard to distribute the driver/firmware otherwise
<oliv3r>
sad, but true
<oliv3r>
Kolyan: I have written to some manufactures, asking for datasheet and gotten replies, belive it or not
<oliv3r>
some gave up a data sheet, some added reference code (which is what oems usually just copy paste)
<oliv3r>
so all hope is not lost :)
<Kolyan>
oliv3r, but i have np experience in linux drivers programming. So i hope the manufacturer will send source code. At least i can try to fix sources.
rz2k has joined #linux-sunxi
<oliv3r>
Kolyan: datasheet is more important, since you can give that to someone who can :)
<oliv3r>
geecko: lychee 3.3 kernel is supplied by the Allwinner SDK
<oliv3r>
geecko: we are not connected to olimex nor allwinner and try to bring the kernel in a good shape
<oliv3r>
geecko: olimex ships whatever allwinner releases, and with good reason
<mripard_>
arokux1: I still don't get why you get so upset about it. Just set it to 256MB and you'll be fine.
<geecko>
oliv3r, ok, that's nice!
<geecko>
one question though
<geecko>
we upgraded from A10s to A20
<arokux1>
mripard_, i'm idealist. we've spent 2 evenings to find out what is wrong, also detected potential problems. why not fix it *properly* now, so the others won't loose their time?
<geecko>
i'm wondering if it is really twice as powerful? :x
<geecko>
we don't even know the CPU frequency...
<oliv3r>
geecko: 912 MHz
<geecko>
and i'm not sure if the Cortex A7 equals the A8 at the same frequency.
<oliv3r>
geecko: and it depends on your workload. Single threaded performance is better on A10 it seems; A20 is better suited for multi threaded worklaods
<mripard_>
arokux1: yes. of course. But fixing properly when you have no background at all is unrealistic.
<geecko>
oliv3r, multithread is what we do :D
<mripard_>
(no background with u-boot that is)
<geecko>
we wouldn't mind about a octo-A7
<geecko>
:P
<oliv3r>
geecko: a7 is slower then a8, but you got 2x a7 so you win a bit there :)
<mripard_>
for all we know, it's *always* been there, so it has an history going for like 10+ years
<geecko>
oliv3r, kewl, and the power consumption seems to be a bit lower even with two cores.
<oliv3r>
geecko: that I don't know, ti seemed higer to me, but i have to test it in a few weeks
<geecko>
oliv3r, ok
<geecko>
oliv3r, were did you find about the frequency?
<oliv3r>
geecko: the source :)
leowt has quit [Ping timeout: 261 seconds]
<geecko>
oliv3r, hah, obviously :D
<arokux1>
mripard_, yeah.. i'm trying to gather the info. somebody must now it :) but yes, it gets in the way of my prior goals, so i won't push it too hard.
<oliv3r>
once it has been seen, it can not be unseen.
<oliv3r>
liberated!
<mripard_>
oliv3r: remove it from IRC!
<mripard_>
:)
<oliv3r>
to late! once it has been seen, it can not be unseen!
<oliv3r>
heh, it's only a few commits, but i'm mighty proud :p
leowt has joined #linux-sunxi
<oliv3r>
next i'm working on uart, looks like it's the same, so that's good
Soru has joined #linux-sunxi
geecko has quit [Quit: Quitte]
mouchon has joined #linux-sunxi
<hno>
oliv3r, you have an A31?
rellla has joined #linux-sunxi
naobsd has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
alcides has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
mouchon has quit [Quit: Page closed]
n01 has quit [Ping timeout: 264 seconds]
<Turl>
oliv3r: slapin_nb you pinged?
Soru has quit [Ping timeout: 246 seconds]
Soru has joined #linux-sunxi
pacopad_ has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<wingrime>
oliv3r: mnemoc pooled hasg branch?
fredy has quit [Excess Flood]
<wingrime>
oliv3r: ping
fredy has joined #linux-sunxi
<wingrime>
mnemoc: ping
bsdfox_ has joined #linux-sunxi
bsdfox has quit [Ping timeout: 264 seconds]
<mripard_>
Turl: ping
<Turl>
mripard_: pong
<mripard_>
did you test the LED on your cubieboard
<mripard_>
like, try to enable both LEDs on it :)
<mripard_>
(hint, it won't work ;))
<Turl>
recently? no
<mripard_>
always
<mripard_>
it has never worked
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<Turl>
mripard_: pinctrl lack of locks? :P
aexl1 has joined #linux-sunxi
<mripard_>
nah
<mripard_>
lack of sense.
<mripard_>
I wasn't reading the register content before setting it
<mripard_>
so it was only setting the last gpio set
<Turl>
mripard_: haha indeed, as soon as I turn one the other one goes off :)
<mripard_>
so much for the heartbeat trigger :)
Soru has quit [Ping timeout: 268 seconds]
* slapin_nb
finished his Grant's bottle, time for NAND
<wingrime>
mripard_: how your sdio driver?
<mripard_>
not had much time to work on it
<mripard_>
I focused on A31 and A20 lately
alcides has quit [Remote host closed the connection]
<wingrime>
mripard_: good, but we still lacks docs
<mripard_>
the only thing missing for now for both of these is the SMP
<mripard_>
clocks, gpio and basic board support work
<mripard_>
i2c should work to
Soru has joined #linux-sunxi
<mripard_>
*too
<wingrime>
mripard_: I booted 3.4 on cb2 without smp, and it slow as hell
<wingrime>
mripard_: it strange
<mripard_>
yeah, I encountered that too
<mripard_>
the SMP bit has to be set in the Cortex A7 to enable the caches
<mripard_>
and it's not set if !CONFIG_SMP
<wingrime>
mripard_: lack of sence
<wingrime>
mripard_: there good explan for it?
<mripard_>
I don't have much time, bottom line is: d-cache isn't enabled
<mripard_>
enable CONFIG_SMP, it will be enabled after decompression
<wingrime>
mripard_: I noticed that AW new dma driver add two layers of code , but IP realy same , except some new security features
<wingrime>
mripard_: now dma driver looks like worser that old ((
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
jemk has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 264 seconds]
aexl1 has quit [Ping timeout: 250 seconds]
paulk-collins has joined #linux-sunxi
arokux has joined #linux-sunxi
<hno>
wingrime, they are mainly HW people, not so experienced with software.
paulk-collins has quit [Ping timeout: 276 seconds]
<arokux>
at what allwinner's kernel should I look while upstreaming usb host support?
<arokux>
sunxi-3.3, 3.4?
<oliv3r>
hno: unfortunatlyno
<oliv3r>
wingrime: pong, not yet, we are gonna try to fix any outstanding issues, and when hansg comes back; we'll do the big pull
<wingrime>
hno: ?
<wingrime>
oliv3r: I find that hdmi sound crashes when you set to pause and try start again with mplayer
<hno>
wingrime, aw
<oliv3r>
arokux: hat do you mean? 3.11-r2 should be your reference, you can 'spy' on the 3.3 one I guess, that's the newest code we have, but 3.4 has more fixes
<oliv3r>
hno: unfortunatly, no; so i haven't tested any of those patches at all
<oliv3r>
and still tons to do
<oliv3r>
going to focus on uart next
<hno>
oliv3r, what patches?
<wingrime>
oliv3r: what patches AW sended to mainline?
<oliv3r>
the a31 patches that i pushed to github :)
<oliv3r>
wingrime: nothing
<arokux>
ok, 3.3 is the newest dump. that is what I needed to know
<oliv3r>
arokux: which is a fork of 3.0
<oliv3r>
3.4 is a fork of 3.4, with tons of fixes by us
<rz2k>
3.3 was sent here by allwinner (no idea how - dont ask)
<oliv3r>
arokux: dumped by allwinner
<rz2k>
and our 3.4 kernel has actually more fixes and cleanups than 3.3
<rz2k>
from allwinner
<rz2k>
also it has unified su45i usb support iirc
<oliv3r>
yes, all true
<oliv3r>
but, 3.3 is the continuation of 3.0 by allwinner, and hence carries fixes to hardware which we have no docu about
<arokux>
rz2k, so I better take 3.4 code and do my best to add it to mainline.
<rz2k>
yes
<wingrime>
jemk: ping
<oliv3r>
so 3.3 is still the most interesting to look at, copare it to 3.3 to see what changed etc, but always look at 3.4 for the fixes that we introduced
<arokux>
good
<oliv3r>
rz2k: not exactly, you'd be missing all the bug fixes allwinner did with 3.3
<rz2k>
i bet they were about sun67i only
<rz2k>
:p
<jemk>
wingrime: pong
<wingrime>
jemk: any new news?
<wingrime>
jemk: SO, whats next?
<wingrime>
jemk: I thinking moving toward h264 , but it much difficult for my understanding
<jemk>
wingrime: im working on vdpau for mpeg12 at the moment, cause i dont want to have to write a whole parser for h264 and want to use vdpau there
<hno>
rz2k, 3.3 is in the A20 SDK.
<rz2k>
oh right
<rz2k>
forgot about that
<hno>
oliv3r, plust the bugs they added...
<wingrime>
jemk: mpeg12 can decoded fast enought with cpu ...
<jemk>
wingrime: it basicaly works, but it's far from complete vdpau implementation and has a randomly(!) apearing bug
<wingrime>
jemk: can explain
<jemk>
wingrime: i know, but i want vdpau to give me bare h264 slices later
<hno>
rz2k, yes AW has the same work process as most hardware companies. Fork everything for every new iteration, hack it into something that makes people think it works. Dump it when done.
<wingrime>
hno: working? sell!
<hno>
wingrime, thats a different team fortunately.
<hno>
but also bosses over the dev department...
<arokux>
i wonder. image all sunxi socs get mainlined. will allwinner pick it up and submit there code upstream then? :)
<arokux>
I meant "maintain and extend to future socs"
<wingrime>
hno: strnage , I have no idea why thay rewrited dma , it not fits "strategy" (I mean "don't touch if it works)
<hno>
wingrime, I bet one of the devs got bored and tried to do something..
<wingrime>
jemk: you too fast with vpdau , normay we need pull most decoding part to kernel (mainline idealy)
<hno>
arokux, I don't think they will start submitting. Bot hopefully they take it.
leowt has quit [Quit: leowt]
<wingrime>
jemk: map IO to userspace newer get accepted (security issues)
<jemk>
wingrime:i know, i only use it as helper to not having to write my own player
BJfreeman has quit [Quit: had a good time]
<ssvb>
jemk: a working vdpau implementation is a good news
<wingrime>
ssvb: indeed
<jemk>
ssvb: working is good, random bugs in there are bad. i think i have messed with the threadsafety
<wingrime>
jemk: there some strange mechanism in cedar kernel part
<wingrime>
jemk: engine_req and engine_rel
<wingrime>
jemk: can it be related?
<ssvb>
jemk: are you using just vdpau api emulation for testing within a client process or integrating it with xorg?
<jemk>
wingrime: when i trace my prog the errors get much more then when not tracing
<jemk>
ssvb: no xorg integration yet, only simple disp as in my pocs
<ssvb>
jemk: ok, that's reasonable
<jemk>
ssvb: disp lacks some features a full vdpau implementation would need
<ssvb>
yes, but g2d still could help
<wingrime>
jemk: how do you implement vpdau api ? emulation with LD_PRELOAD or >
<wingrime>
?
<ssvb>
does cedarx always decode to a tiled format?
<jemk>
wingrime: libvdpau wrapper from nvidia
<wingrime>
ssvb: vpdau needs "slices" ?
<jemk>
ssvb: think so, havent found anything different
<wingrime>
jemk: it runs in same thread?
<ssvb>
jemk: yep, this wrapper is quite nice
<ssvb>
jemk: the tiled format can cause some troubles, we might need to convert it to normal planar of nv12 using something if extra post-processing is needed
<ssvb>
jemk: the disp writeback pipeline could possibly do it
<jemk>
ssvb: yes, disp should be able to do everything necessary, but the current kernel driver cant
<ssvb>
jemk: we can fix it :)
<wingrime>
jemk: I begin understand why AW write own implemetation with avoid OpenMAX, etc .
<wingrime>
jemk: things begin complicated without any reason
<ssvb>
jemk: in the case of subtitles or osd, we may need to configure disp for write back in order to pass the tiled data through and get more conventional yuv or rgb output in the memory buffer
<ssvb>
jemk: then use g2d to blend some bitmaps and pass the final data again to disp for sending it to the monitor this time :)
<ssvb>
jemk: though don't know what kind of performance implications it may have
<libv>
overlays and colorkeys.
<ssvb>
haha
<libv>
where the subtitle isn't, the colorkey is
<wingrime>
ssvb: whats wrong with disp layers?
<ssvb>
wingrime: you can't do the full range of complex bitmap operations using just layers
<libv>
ssvb: do you need to for subtitles?
<wingrime>
ssvb: as I remeber disp layers support color key, or I wrong?
<ssvb>
libv: implementing full vdpau would be nice, that's what standards are for
<ssvb>
libv: if we don't care, we can just use a custom patched xbmc build
<ssvb>
libv: and implement subtitles in the most easy and straightforward way
notmart has quit [Quit: notmart terminated!]
<ssvb>
wingrime: yes, the color key feature is supported by disp and used for xv
<wingrime>
ssvb: can we use xbmc with blob where opensoure impl work, or using vpdau where not work, that kind of autoselect possible ?
<wingrime>
* use opensoure when possible
<ssvb>
wingrime: a specialized application is always easier to implement than standard api usable by many existing applications
<wingrime>
ssvb: I not know much soft that use vpdau
<wingrime>
ssvb: write plugins for mplayer , vlc , xbmc may be much faster than do vdpau(in summary)
<ssvb>
wingrime: yes, and we already have vlc and xbmc
<wingrime>
ssvb: that nvida wrapper use some separated thread ?
<ssvb>
wingrime: just replace the blob with the reverse engineered code and everyone will be happy ... or not
<libv>
from quickly reading the description at nvidia.com, it seems to me that vdpau does not allow for subtitles being handled by the display or other engines, but instead relies on the video decoder or whatever is being used on doing an extra step on combining the result into a new buffer
<libv>
unichrome had a special low colour overlay for just subtitles
<ssvb>
libv: G2D should be useful, or even CPU if the subtitle area is reasonably small
<libv>
not sure to what extent the disp engines sprites can be used for that, as there seem to be multiple of those
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<libv>
ssvb: i am not a fan of offloading it to other engines while special provisions are there
<ssvb>
libv: vaapi is usually offloading post processing to gl
<Black_Horseman>
Hell -o
<libv>
but sadly i have limited time
<ssvb>
libv: vdpau should not cause many problems for us
<ssvb>
there are many alternative solutions to try, it is not like we are running out of ideas yet
<libv>
i wouldn't know, the last time i did media work, vdpau was announced only a few months before
<libv>
unichrome had a pretty extensive filter/scaler/deinterlacer, which could be switched before the overlay
<libv>
to the extent that you could toss data in the mpeg2 decoder, and have the 2 subsequent engines triggered in step, automatically
<libv>
it would be interesting to see how, if at all, vdpau would handle that
<wingrime>
ssvb: problem is , temportary solutions have intension become "final"
<wingrime>
jacq: I used sun4i default config and than 1) change machine type to sun7i 2) disable serial driver 3) disable old mmc driver and enable new
<wingrime>
4) enable smp
<wingrime>
mnemoc: ping
<wingrime>
ssvb: I totaly noobe in x11 interfaces, I mostly like work with kernel side
<wingrime>
ssvb: understanding code base most problematic and takes time
<oliv3r>
hno: i know it's not perfect, but it's a start? (a31)
<wingrime>
oliv3r: you have a31 hw?
<jacq>
wingrime. OK, i followed you until ssvb... will try to understand that later... (I am quite newbie)
<oliv3r>
wingrime: mpeg12 can be decoded fast enough with CPU means also your cpu is busy 90% of the time, so your OS won't have anything left
<wingrime>
oliv3r: how your cb1?
<wingrime>
oliv3r: still not works?
<ssvb>
oliv3r: more like 30-50% CPU load (depending on how much action we see on screen) for MPEG2 720x576 25.000 fps 7800.0 kbps (starship troopers movie from a double layer DVD) :)
<oliv3r>
wingrime: no i do not, only cubie1 with broken phy; but i orderd new phy for 2 euro today
<oliv3r>
i still think mpeg12 will be a good exersize, relativily simple and easy to implement/test before doing greater things