<rm>
then replace u-boot on your SD-card, and also copy script.bin into the /boot partition on it
<rm>
and if these don't help, then also replace the kernel
<Wetomelo>
thx!
<Wetomelo>
i'm a bit rusty! about 10 years without using irc!
Wetomelo has quit [Quit: Ex-Chat]
hipboi has quit [Ping timeout: 258 seconds]
ZaEarl has quit [Ping timeout: 264 seconds]
hipboi has joined #linux-sunxi
rellla has joined #linux-sunxi
calris has quit [Ping timeout: 252 seconds]
calris has joined #linux-sunxi
ibrah has joined #linux-sunxi
n01 has joined #linux-sunxi
hipboi has quit [Remote host closed the connection]
shineworld has joined #linux-sunxi
hipboi has joined #linux-sunxi
ibrah has quit [Ping timeout: 276 seconds]
AndChat|217856 has joined #linux-sunxi
calris has quit [Ping timeout: 276 seconds]
AndChat|217856 has quit [Ping timeout: 276 seconds]
<shineworld>
following first-step I've download gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux.tar but there are some not about "incompatibility" of that ... I've do right download choice or there is another place to have the right tool ?
<shineworld>
-not +notes
<n01>
shineworld: what kind of incompatibility?
<shineworld>
Pasting: You need a working toolchain. This is a set of binaries, system libraries and tools which allow you to build (in our case, cross-compile) u-boot and the kernel for a target platform. This will, to some limited extent, need to match the target rootfs. A large and incompatible change has taken place recently, through the Hard Float ABI. Now, two different debian and ubuntu ports are binary incompatible with eachother.
<shineworld>
Recent linaro toolchains are Hard Float (hf), which only runs us into one issue with u-boot. This will be used throughout the document. Wherever you see something like
<n01>
I'm using it without any prob
<shineworld>
ok, thanks
<shineworld>
last : can I use a 32 bit to build bsp ? My lappy don't have 64 bit support
<shineworld>
*has
<n01>
well, you are xcompiling so the host arch doesn't count
<shineworld>
ok because I've saw a lot of pre-made tools in paths
<shineworld>
some of them like : script, update_23, update_MBR, and so on are ELF 64-bit LSB executable, x86-64
<n01>
never heard of those tools ... what are you using them for?
<shineworld>
I'm downloading linaro tool-chain and during waiting time I've just do a file * of all executable files downloaded with sunxi-bsp so I've asked because I've found some x64 bit tools
<n01>
ok, never actually used tools in sunxi-bsp :)
<shineworld>
first-steps on linux for me
<shineworld>
till now just used pre-made images
<shineworld>
normally with android linux part (kernel) is not so important
<oliv3r>
shineworld: of course
<n01>
I usually compile kernel, rootfs, u-boot, SPL, script.bin separately and put all together
<oliv3r>
shineworld: i think in theory, you can even cross compile a 64bit arm, on a 32bit intel
<shineworld>
that will be my road (to build separately) but how first step I would like to run the bot and follow what it produce
<oliv3r>
shineworld: it could be of course that you do run into issues, as most of us are on 64bit hosts, so if you run into something, make sure to let us know so that it can be fixed
<shineworld>
I think the upon mentioned programs are used by host pc to build last phases of image creation and not how tools for final cubieboard OS
<shineworld>
I've a 64 bit at home but here in office I'm running on a 32 bit lappy so.... I will try crossing fingers ;)
<oliv3r>
:D
<shineworld>
building
<oliv3r>
mnemoc: how should we deal with 90% identical fex files. for example my tablet uses the same fex file as the inet97f-ii except for the touchscreen, that is completly different. is it worth a new fex file? or do we want to 'polute' the fex file with various touch screens?
<hipboi>
anyway fex will be abandoned
<oliv3r>
that is true; i'll just leave all ctp settings in
<oliv3r>
also, hi hipboi :)
<oliv3r>
how is life?
<hipboi>
life is simple
<shineworld>
there is wisdom in these words...
<hipboi>
all work, no life...
<shineworld>
there is sad in these worlds ....
<oliv3r>
you work to live, or you live to work; that is the question
<hipboi>
work is life, life is work
<shineworld>
oliv3r, can you leave me any dubt about linaro release copy/pasing your arm-linux-gnueabihf-gcc --version first line ? I thank you in advance for that
<shineworld>
ah different than mine so could be you don't have issue notices on sunxi wiki
<hipboi>
ping dl9pf
<oliv3r>
shineworld: yeah, Gentoo makes building a crosscompiler very easy, so i just use that
<shineworld>
I will try to find same of your in net
<oliv3r>
dram_clk = 480 was max and should be stable right?
<oliv3r>
but the linaro supplied gfcc 'should' work
<oliv3r>
shineworld: my gcc you won't find anywhere :)
<oliv3r>
also it's 64bit too :(
<shineworld>
ok
<rellla>
<hipboi>anyway fex will be abandoned ???
<n01>
I sure hope it will :D
<hipboi>
rella: i mean dts
<hipboi>
android 5.0 will be based on kernel 3.8?
<oliv3r>
rellla: in favor of FDT/dts
<oliv3r>
but that's quite far away for now
<oliv3r>
hipboi: rumor has it, and first mainline changes for A10 are in 3.8
<oliv3r>
so that's quite exciting
<hipboi>
allwinner internal began to look at dts
<hipboi>
they found sunxi is already there
<rellla>
hipboi: you mentioned yesterday, that aw also looks at OpenMax?
<hipboi>
according to Turl, they already using OMX now
<RaYmAn>
perhaps they are starting to realize it's a good idea to let the community do a lot of the work for free ;)
<hipboi>
from the source code leaked
<shineworld>
<hipboi> android 5.0 will be based on kernel 3.8? some say that ...
<rellla>
RaYmAn: +1
<rellla>
hipboi: just for my interest: how "big" is allwinner, how many people are working there?
<hipboi>
less than 500
<hipboi>
400+
<hipboi>
last year is 200+
calris has joined #linux-sunxi
<shineworld>
is growing ...
<hipboi>
many good engineer left
<hipboi>
they are hiring
<hipboi>
a lot
<rellla>
ok. really big imo. just thought about a neat little company ;)
<hipboi>
we are one
<hipboi>
cubietech is
<hipboi>
5 people
<rellla>
4+ ;)
<rellla>
but you didn't sign any nda with aw at all?
<hipboi>
yes
<hipboi>
i mean no nda
<rellla>
so we have to wait for aw, if there's any progress with cedarx...
<oliv3r>
why did many good engineers (like yourself!) leave? they fear that after the A10 it's only going down?
<mnemoc>
oliv3r: regarding "similar" .fex files my idea was to support variants as patches, board-variant.patch + board.fex -> build/board-variant.{fex,bin}
<oliv3r>
mnemoc: well the idea will equally expand into dts too
<mnemoc>
oliv3r: if you submit the first board-variant.patch, I'll adapt sunxi-bsp for it
hansg has joined #linux-sunxi
<mnemoc>
diff
<oliv3r>
mnemoc: ok also
<oliv3r>
mnemoc: if sometthing is used=0; do we want to clutter the config file with the other options (that are not used)
<mnemoc>
oliv3r: traditionally we have kept the noise as reference and to reduce the diffs.... but after all, it's just noise
<mnemoc>
even with _used=0
<oliv3r>
well i've put all possible options up on the fex_guide
<oliv3r>
they are all documented or used as example
<oliv3r>
so the wiki is the reference
<mnemoc>
yes, that's the idea
<oliv3r>
also, all fex files are based from the AW evaluation board, so we have things in there that would not ever be used, and it really is just noise
<oliv3r>
i personally would say, get rid of anything that's used=0
<mnemoc>
we problably should change the board name within the .fex to reflect the truth
<oliv3r>
'machine='?
<mnemoc>
yes, that
<oliv3r>
yeah i did change it for the one i'm working on
<hipboi>
oliv3r: used=0 is also parsed by many drivers
<oliv3r>
but what do we want in there? tablet/phone/set-top-box
<oliv3r>
hipboi: yes, leave that in, but anything below can be gone if it is used=0
<mnemoc>
_used=0 is used, but if the section is missing it will have the same meaning
<oliv3r>
i mean, motor_used = 0; then leave out motor_shake = port:PB03...
<hipboi>
oliv3r: ok
<oliv3r>
and a 'standard' fex file, to base them all off, would it be a tree structure? like dts works?
<mnemoc>
oliv3r: be sure the motor_* example in the wiki is complete enough before cutting it out
<oliv3r>
i can see 'bare minimum.fex' -> tablet.patch -> myspecifctablet.patch
<oliv3r>
mnemoc: did you even check the wiki?!
<mnemoc>
oliv3r: nope :p
<oliv3r>
i've speent 20 hours or so on Fex_Guide
<oliv3r>
look at it atleast
<mnemoc>
i will. promised
<mnemoc>
oliv3r: I would prefer to stick with two levels, not a tree of complex patches
<mnemoc>
only for variants, not for the whole world
<oliv3r>
mnemoc: dts will be a tree of 3 or 4 levels from what I understood
<mnemoc>
oliv3r: yes. but we don't need to jump over to the most complex case right away
<oliv3r>
anyway, i'll rename inet97f-ii to be a bit more generic, then patch inet97f-ii and my tab from it
<mnemoc>
it's not worthy, specially because generating a full .dts from a full .fex will be far simpler than using a web of includes
<mnemoc>
yes, that's good
<mnemoc>
your tablet been a variant of another identical but with different ts
<oliv3r>
ok, i'll do that
<oliv3r>
though the only difference probably will be the ctp in this specific case :)
<mnemoc>
or different ram
<oliv3r>
ram is even identical, just the TS is different
<mnemoc>
perfect. lets solve that problem with a single level board-variant.patch
<oliv3r>
though the same fex can be used, as it _used = 1 all the TS's
<oliv3r>
so it'll be 1 fex + patch with TS
<mnemoc>
yes
<oliv3r>
i'll define the ctp_used = 0 by default then
<oliv3r>
would a tablet (with 1 external SD slot) have an internal mmc slot used for anything? (wifi is done over USB)
<mnemoc>
some devices use an internal uSD as alternative to a NAND
calris has quit [Remote host closed the connection]
<oliv3r>
but if you have /dev/nand[a-f] you have nfc and not mmc
<oliv3r>
kk, just makeing sure, as there's 4 mmc's defined here :p
<mnemoc>
they work over the uberly generic and ape proof template provided by allwinner
<oliv3r>
i must say though, the 'updated' fex that came with the (only ) firmware update for my tablet did atleast clean up a lot; they've actually bothered to 'used = 0' to a lot of things (sata, ms, ps2 etc) which was default 1
<mnemoc>
:)
<oliv3r>
yeah i know, it's sad though that they don't even bother
<oliv3r>
'this tablet could have sata'!
<Turl>
howdy all
<mnemoc>
oliv3r: it was probably simpler for the vendor to just rm the .ko
<mnemoc>
wb Turl
<mnemoc>
Turl: btw, Epsylon3 is totally in favour of a multi-device devices/android repo :)
<Epsylon3>
not exactly
<Epsylon3>
:p
<mnemoc>
meh :<
<Epsylon3>
its not a repo for the future
<mnemoc>
devices/allwinner I mean
<Epsylon3>
its a temporary one to show open tv state
<mripard>
Turl: hi
<Epsylon3>
the one for the future is is allwinner-dev-team
<Epsylon3>
empty yet
<mripard>
Turl: mike seems to have been brought back to life
<Turl>
mnemoc: :)
<mnemoc>
having one devicetree for each allwinner device simply doesn't scale. ever
<mnemoc>
and beside the TS they are identical
<Turl>
mripard: yes, I saw he has been replying to recent emails
<mnemoc>
Turl: you'll really force me to fork your common :<
<mnemoc>
snif snif snif
<Turl>
mripard: I sent him an email yesterday, in case he just used 'mark all read' :)
<mnemoc>
Turl: script.bin diffs mostly, and totally not worthy of the extra burned of a per-device repo
<mnemoc>
but I won't argue
<Turl>
mnemoc: but that's just 1 file, you can't compare :p
<mnemoc>
sure there are more files in the per-device *dir*
<mnemoc>
but nothing to justify needing one public repo for each
<mnemoc>
they are 99% identical
<mnemoc>
in our case per-device device repos only means people reimplements the same thing once and again, in private
<Turl>
they don't need to reimplement anything, there's a common repo :|
<mnemoc>
they do reimplement the per-device bit that you insist in needs to be separated
<mnemoc>
a single device/allwinner repo would solve that, and encourage people to submit their per-device tweakings (over a template based starting point)
<shineworld>
single get-xxx.sh does right git of /device/semc or /device/cooper or /device/your device
<mnemoc>
nah, I only mean to unify sunxi devices, not the world :p
<Turl>
mnemoc: you don't 'reimplement' a makefile or config file
<Turl>
it's 7am, let me wake at least :p
<shineworld>
ok then /device/get-cubieboard.sh /device/get-envboard.sh and son on ?
<mnemoc>
Turl: in which case what's the value of keeping that in a different .git????
<mnemoc>
Turl: but the main "scary" part for new comers is "meh, my device isn't supported" :<
<Turl>
mnemoc: permission management at github, history separation, and small size to fetch as you just need your device to build
<Turl>
mnemoc: unifying doesn't make all devices supported magically either
<mnemoc>
cp'ed Makefile/config doesn't increase the size of the repo
<mnemoc>
Turl: no, but gives a central and maintained starting point
<Turl>
bbiab
* mnemoc
back in 30m :<
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 252 seconds]
rellla2 is now known as rellla
ibrah has joined #linux-sunxi
<shineworld>
I've found that to put every device in a separate git is a good way, keeping cpu and common in other git so If I've to build android for cubieboard (for eg) is only necessary got repo the android branch and then call /device/get-cubieboard.sh which git all required repositories for it
<oliv3r>
there's 3 USB controllers on the A10 usbc0 is for the OTG port, USBC2 for wifi, what is USBC1 used by?
<Turl>
oliv3r: host
<Turl>
shineworld: yeah, the cm buildsystem has cm.dependencies that will automatically do that on brunch/breakfast
<oliv3r>
Turl: host what, there's 3 controllers right? each with 1 port? so there' OTG, wifi and ...? it's not that USBC1 is a 'hub'
ibrah has quit [Ping timeout: 264 seconds]
<shineworld>
yes for exeample to build my phone have only to call:
<shineworld>
repo init -u git://github.com/TeamFun/android.git -b gingerbread (to get cm7 for arm6vf GingerDX distro)
<shineworld>
repo sync -j6
<shineworld>
chmod +x /devices/get-semc.sh (for my shakira phone model)
<shineworld>
devices/get-semc.sh (to git the specific repos of shakira model)
<shineworld>
. build/envsetup.sh
<shineworld>
brunch shakira-eng
plan_b has joined #linux-sunxi
<plan_b>
the CFLAGS to compile qemu for the raspberry pie are ...
<shineworld>
using get-xxx you can choice what do you would
<Turl>
(yeah it says gentoo, but I think those cflags are what you need)
<shineworld>
removing that control from cm build
<Turl>
shineworld: yeah, I'm telling you CM's "roomservice" does that :)
<shineworld>
ah ok
<oliv3r>
Turl: looks like that usbc1 isn't used on most tablets
<oliv3r>
Turl: ah, you ment 'regular usb port' yeah host port, i got it :p sorry missunderstood
<mnemoc>
re
<mnemoc>
Turl: my goal is to be able to build (at least a base) CM for every board.fex we have in sunxi-boards automatically, and to encourage (by making it trivial) people to contribute back whatever device-specific change they made to improve the support of their device
<mnemoc>
obviusly minizing the recompiling of stuff
<mnemoc>
and minimizing the device-specific details
<mnemoc>
the big blobs are shared, the kernel is shared, the userspace is all shared
<mnemoc>
mostly only configuration details are device specific in the sunxi world
ibrah has joined #linux-sunxi
* Turl
needs to bring the example repo back to life
<Turl>
heh, dinodirect now offers taobao ordering service :P
<mnemoc>
oh
<shineworld>
Turl, great... what is your actual link in git ?
<Turl>
30% commission is a bit expensive though
<Turl>
shineworld: link to what? example repo?
<shineworld>
to your cm repo (where you are working for )
<rm>
can we check the RAM frequency on an A10 device?
<mnemoc>
Turl: that lets us use cedarx libs for android 4.2?
<rm>
from booted-up GNU/Linux
<mnemoc>
rm: use a10meminfo from android
<mnemoc>
linux
<rm>
hm I have a static-compiled version of it
<rm>
did not try it in Debian
<rm>
yet
<rm>
thanks
<mnemoc>
no no
<rm>
won't work?
<mnemoc>
probably
<mnemoc>
but, there is a .c too
<Turl>
it's static, it should work
<Turl>
mnemoc: idk, but it's on the newer code drops, so I assume it may be used
<Turl>
mnemoc: it doesn't break the ioctl abi so it should be fine to pick up
<mnemoc>
Turl: I mean, worked for you?
<Turl>
mnemoc: I couldn't test, I have issues on the memory alloc front :)
<rm>
would be nice to have the RAM frequency somewhere in /proc/ or /sys/
<mnemoc>
raw read/write of the reg via ioctl gives a bad feeling
<rm>
I'd say even in /proc/cpuinfo, why not
<Turl>
mnemoc: yeah
<mnemoc>
rm: sounds fair
<mnemoc>
rm: don't know if "ram" drivers exist
<Turl>
printed on boot maybe
<Turl>
together with A10 chip ID
<mnemoc>
so plat-sunxi/core.c
<Turl>
(which I saw some non A10 print as Unknown nowadays :P)
<mnemoc>
Turl: can you give me those lines?
ibrah has quit [Read error: Connection reset by peer]
<mnemoc>
to see the chip-id
<Turl>
mnemoc: it was hramrach or wingrime who had it
<Turl>
I saw it on a pastebin
<gzamboni>
hi everyone
ibrah has joined #linux-sunxi
<Turl>
hi gzamboni
<gzamboni>
there's only the csi camera to make all my cubieboard ext board to work. Does anyone know the status of this driver (sun4i-csi1) ?? i mean: working, not working
<Turl>
mnemoc: his debian pastes had low expiration, they're not there anymore
<gzamboni>
i already read a half of the book you recommended me ;)
<Turl>
:)
<gzamboni>
there are some stuff i dont understand but surelly im learning a lot
<Turl>
well, the csi stuff worked on my tablet, and I think drachensun also has his working
<gzamboni>
what tablet do you have ?
<Turl>
he tested with normal linux userspace too, I suppose he'd be a better person to ask :)
<gzamboni>
maybe i should buy it and verify the hardware connections and my schematic
<gzamboni>
ok, Thanks Turl
<Turl>
gzamboni: zatab
<Turl>
but there should be no need to buy a tablet to get your camera working :)
<gzamboni>
but you tested only in the android , right ?
<gzamboni>
i hope so ;-)
<Turl>
yes
<Turl>
drachensun also tested on linaro or sth like that for the pengpods
<gzamboni>
im using debian, but i dont think its a matter of distribution since the kernel is the same
<gzamboni>
even if the errors im getting seems to be in the userspace i think its kernel related
<Turl>
yes, it should be about the same
<Turl>
v4l commands sent might be different between android and your favorite distro though
<Turl>
what errors are you getting?
<Turl>
nevermind, just saw your email :)
<gzamboni>
its different in each app im using
<gzamboni>
almost every app does kernel panic
<Turl>
send the panic output too
<gzamboni>
using vgrabbj is the only one that i dont have a kernel panic
<gzamboni>
i will do so when i get back home in about 4hours
rz2k has joined #linux-sunxi
<gzamboni>
Thanks Turl
hipboi has quit [Quit: Leaving]
ganbold_ has joined #linux-sunxi
ibrah has quit [Ping timeout: 252 seconds]
<Turl>
Epsylon3: I just noticed my audio broke too :/
<Turl>
mnemoc: any audio changes you recall in the last months?
<mnemoc>
there is a patchset from hansg pending
<mnemoc>
feb 15
* mnemoc
really needs a device to freeze time :|
vinifm has joined #linux-sunxi
<Turl>
hramrach: that patch works, thanks
<Turl>
hramrach: please send it to the ML
<Turl>
hramrach: some of the behavior changed though
<Turl>
/sys/devices/virtual/block/nandX no longer exist, now they're at /sys/devices/virtual/block/nand/nandX
<Turl>
but I can cope with that
ibrah has joined #linux-sunxi
* theOzzieRat
hands mnemoc a tardis
ibrah has quit [Ping timeout: 245 seconds]
ibrah has joined #linux-sunxi
<mripard>
mnemoc: the follow-up button on gmane is crap btw
<mripard>
I never got oliv3r mail
<mripard>
it was only a reply, to netdev
plan_b has quit [Quit: Verlassend]
<Turl>
mripard: ok, got the alloc stuff workarounded, and now I get CEDARV_FLAG_DATA_INVALID
<Turl>
I suppose you cannot alloc it random buffers :<
<Turl>
the OS alloc lib you linked might come in handy
<mripard>
Turl: hmmmm, mind to give some context ? :)
<mripard>
I'm not sure what you're talking about
<Turl>
err, I fail, that was for mnemoc :)
<Turl>
mripard: I'm talking about cedarx
<mripard>
yes, I got that you were talking about that, but I didn't recall talking about anything related to cedarx with you :)
<mripard>
now, I get why :)
<mnemoc>
mripard: good to know :<
<Turl>
mripard: they're doing the allocs through gralloc now, I need to write some code to let it alloc from the cedar pool
<Turl>
handing it framebuffer memory doesn't seem to do the trick :)
<rm>
mnemoc, a10-meminfo-static does indeed work fine in Debian armhf
<Turl>
I'd have been surprised if it didn't
<Turl>
that's the point of being static :p
<mnemoc>
rm: cool :)
<mnemoc>
rm: but it still sound like a good idea to add that info in /proc/cpuinfo
<Turl>
bbl
rz2k has quit []
ibrah has quit [Ping timeout: 256 seconds]
<oliv3r>
what happens if you configure a GPIO port twice (well it's defined twice in the fex, but still)
<oliv3r>
mnemoc: btw, on battery powered devices, battery configuration is unique (and should be tuned to the installed battery)
<_jm>
Is there any value in me posting fex and meminfo for "old" 7inch tablet novo7 Aurora ?
ibrah has quit [Read error: Connection reset by peer]
ibrah has joined #linux-sunxi
shineworld has quit [Remote host closed the connection]
ibrah has quit [Ping timeout: 264 seconds]
<hramrach>
_jm: it might help other people who happen to have that
<hramrach>
even when not sold new anymore
<mnemoc>
_jm: please make it three commits. first the origin .fex, then dram_para fixing, and then used=0 for sections which don't really exist
<mnemoc>
original*
<hramrach>
also makes building firmware for your own tablet easier ;-)
<oliv3r>
mnemoc: you are linking my own work against me now? :p
<oliv3r>
mnemoc: i was re: the fact that we can have 1 generic fex file for quite a lot of devices and have a small 'patch' for each device. touchpanel is unique on most, but also battery on battery powerd ones! but good that your reading Fex_Guide :p
<oliv3r>
mnemoc: anyway, patch sent
<oliv3r>
see how you like it :)
<oliv3r>
if you approve, we can somehow work that into 'submititing boards'
ibrah has joined #linux-sunxi
<Dreadlish>
wingrime: driver works
<Dreadlish>
wingrime: i put script.bin in wrong place ;D
ibrah has quit [Ping timeout: 240 seconds]
<oliv3r>
mnemoc: i guess easiest way to deal with it in sunxi-bsp is cp <whatever is on top of the patch> patch -p0 < patch
<oliv3r>
but i'llleave that up to you
<mnemoc>
i don't like the idea of a generic tablet .fex at all
<mnemoc>
but will use that to implement .fex patches support in the bsp
ibrah has joined #linux-sunxi
<oliv3r>
mnemoc: how would you call it; i think it is quite the generic tablet fex
<_jm>
mnemoc: can you elaborate on the 3rd commit : used=0 for sections which don't really exist (me new at that :) )
<oliv3r>
_jm: a lot of sections start with gps_used = 0
<oliv3r>
because your tablet doesn't have gps
<oliv3r>
but then there's tons of configuration options for if you did have it
<oliv3r>
so scrap those and only leave [gps_para] \n gps_used = 0
<_jm>
oliv3r: got it. Some work to do then.
<oliv3r>
_jm: i just posted a generic_tablet.fex to the mailing list, you can use that as your starting point
<mnemoc>
_jm: your .fex might claim to have things which in reality aren't there. in order to support a generic kernel, the .fex files can not lie
<_jm>
mnemoc: so if I want to test that my non-lying fex is correct, I should compile the kernel and try to boot it on the tablet, right ?
<oliv3r>
mnemoc: it's not perfect, but it's a start I guess; you can parse the header of the diff file and use --- <filename> as the template, +++ <filename> as the final fex :)
<oliv3r>
_jm: in theory, you'd only have to replace the compiled fex file
<oliv3r>
_jm: what happens is, the kernel loads a bunch of drivers, the drivers parse the script.bin file and see if they are 'available' by checking for *_used, if true, then they think the hardware is there, if not then they don't load (or don't do anything actually)
<_jm>
oliv3r: I'd rather play with the sdcard than mess up with nanda on the tablet. Kids are still expecting Android to boot :)
ZaEarl has joined #linux-sunxi
<oliv3r>
_jm: you can have a script.bin on SD card :)
<_jm>
oliv3r: with the kernel on the sd card too, or with the kernel on nand. If nand, where do I read the docs ?
<oliv3r>
_jm: the best/easist way to start testing things with I guess, use HansG's fedora 18 image (requires an 3+ GBBBBBBB sd
<oliv3r>
_jm: everything on nand :)
<oliv3r>
quickest/easist way is to use HansG's functie
<oliv3r>
fedora image*
<_jm>
oliv3r: ok, I get it.
<oliv3r>
what hans did, is made a generic image for an SD card
<oliv3r>
(with really goo dinstructions)
<_jm>
downloading :)
<oliv3r>
and allows you to 'configure' it and run it
<oliv3r>
but, you still need a fex/u-boot-spl for your specific device
<oliv3r>
now to start with, you can use one that matches your device most closely
<oliv3r>
for that you need to figure out tttwo things, compare script.bin (decompiled) with all the fexes we currently have and what comes closest
<oliv3r>
(not everything is that important, chances are any of the tablets work)
<oliv3r>
and secondly, you need to know your DRAM parameters. boot android and run 'a10-meminfo'
<_jm>
I tried already, not much match with various fex. but I don't know which one matters. I have the meminfo already ( http://sprunge.us/dhSI )
<oliv3r>
then compare your dram parameters to the fex files dram_para; based on the script.bin and meminfo you should make a close match. (Ram parameters are most important to match)
<oliv3r>
dram_para matters (because that's the u-boot-spl you )
<oliv3r>
dram is setup by u-boot-spl. drrram parameters are compiled into u-boot-spl;
<oliv3r>
i think you can use the u-boot-spl from a10_mid_1gb
<oliv3r>
yeah absolutly, your memory parameters match that exactly
<oliv3r>
so what else is important? LCD settings I guess, since its a tablet, USB settings so you can caonnect keyboard (OR) mouse
<oliv3r>
to the OTG port (if you have an extra USB port, you can use that obviously)
<oliv3r>
that should get you booted anyway
<_jm>
let me try all that. Right now I am trying to boot the Mele A100 headless without console :)
<oliv3r>
i thought you had a tablet
<_jm>
I have a few things :)
<_jm>
the tablet is next after I get the headless going
<_jm>
remember last week I posted the A100 fex
<ibrah>
oliv3r: can HansG's fedora 18 image be run on an MK802ii?
<ibrah>
hansg: thanks, I have it .... looking for a suitably large microSD card
<hansg>
ibrah, you need a 4G+ card
<oliv3r>
yeah I hoped it would fit on a 2G card
<oliv3r>
had to steal the one from my GF's phone
<oliv3r>
now she has a 2G card :p
<oliv3r>
hansg: i'm trying ot build the sunxi-bsp 3.4 kernel and copy over modules, RTL, touch and Gsensor for now; but wifi isn't working; you use a specific branch?
<oliv3r>
allready found out that you have preempt and modversion disabled
<hansg>
oliv3r, have you tried modprobing the wifi driver ?
ganbold__ has joined #linux-sunxi
<oliv3r>
hansg: yes, because otherwise it won't work at all :p
<oliv3r>
but i have a new script.bin that has init on usbc2 enabled
<hansg>
oliv3r, as for what branches, etc. I'm using there are instructions in the README how to rebuild the Fedora images kernel + uboot from source, including links to git repo, used kernel .config, etc.
<oliv3r>
i ment, you aren't doing anything special, other then disable preempt and modversions, right?
<hansg>
The magic that ties it all together is in build-boot-root.sh of which there is a copy with the exact git tags used for the image you're using in the uboot dir of the image
<oliv3r>
ah, i'll look at that
<oliv3r>
and compare; i think i stuck the SD card into my server before i left home, so can peek :)
<hansg>
oliv3r, nope nothing really special. Not sure I disable preempt and pretty sure I don't disable modversions though. I'm using the standard Fedora .config as used for all Fedora arches + sunxi specific settings on top
ganbold_ has quit [Remote host closed the connection]
<hansg>
oliv3r, note my personal experience with the wifi is: 1) it does not work all that well at all (not the best chipset) 2) The antenna's in many of these devices are utter crap, try moving a lot closer to the accesspoint
_jm has quit [Quit: Loqui powered]
<oliv3r>
hansg: well the default sunxi config didn't work, I had to disable preempt or the module refused to load. and for the same reason, module versioning
<oliv3r>
hansg: nah, network manager doens't even show a wifi device, and lsusb doesn't show it either
<oliv3r>
but this was with my sun4i compiled driver
<oliv3r>
somehow the one you compiled in the image got corrupt (was only 750kb)
<oliv3r>
you deffinatly disabled MODVERSIONS though, according to the .config
<hansg>
oliv3r, you're talking about 8192cu.ko right? The one in the image being 750kb sounds about right, and it works for me. My advise would be to try again with the one from the original image. Or maybe even restart with a clean image to make sure you don't have another version lying around getting used instead
<wingrime>
mnemoc: looking for intresting in dev branch
<hansg>
The 8192cu.ko as distributed sure works for me, it is the driver for the wifi in all the devices I've
<hansg>
oliv3r, as for MODVERSIONS you're right having it disabled is the Fedora default
<mnemoc>
wingrime: can you cherrypick those you like and then submit the set?
<oliv3r>
hansg: why is yours 750kb and my android (stock) and sun4i versions being 8mb
<oliv3r>
though I find 8mb huge
<oliv3r>
maybe it was 850 kb and i missread a 0 :p
<oliv3r>
i'll double check now
<hansg>
oliv3r, they probably left the debuginfo in there
<wingrime>
mnemoc: I have to upload your branch
<wingrime>
it need time
<oliv3r>
hansg: I may have enabled it, because i wanted to debug the ssd253 driver
<oliv3r>
hansg: in that case, i'll just use the default_sun4i kernel and work with that for now; though
<oliv3r>
i did have the 750kb version working btw
<hansg>
ok
<oliv3r>
are we really going to have 1 specific u-boot config per board, when most mem parameters are identical/ i don't mind adding one for my specific tablet
<oliv3r>
i mean, the cubieboard has the same settings as my tablet, it's properly clocked to 480; i can just use that for my board, is there an easy way to tell sunxi-bsp that my board uses cubieboard_512-spl/ or shall I just copy it for the specific board.c anyway
<mnemoc>
fexc -O u-boot generates board.c
plan_b has joined #linux-sunxi
ibrah has quit [Ping timeout: 276 seconds]
hansg has quit [Quit: Leaving]
drachensun has quit [Ping timeout: 252 seconds]
drachensun has joined #linux-sunxi
plan_b has quit [Read error: Connection reset by peer]
ganbold__ has quit [Remote host closed the connection]
<techn__>
mnemoc: should I use IGNORE_ATAG with lichee-dev?
<mnemoc>
not needed
<mnemoc>
u-boot-sunxi's lichee-dev passes the machine id and ATAG_MEM properly
ibrah has joined #linux-sunxi
<mnemoc>
techn__: tried earlyprintk ?
<techn__>
not yet
<techn__>
Trying to find obvious problems ;)
<wingrime>
techn__: something strange on 3.4 after resume
<wingrime>
screen is black I only see flashes when mouse moves
<mnemoc>
techn__: be sure to tell your kernel to use the right uart for debug
<wingrime>
ssh shell works
<techn__>
mnemoc: that could be the problem
mdfe has joined #linux-sunxi
<techn__>
wingrime: havent had time to test 3.4.. but screen problem.. are you using which xorg display driver?
<wingrime>
techn__: xf86-sunxi
<wingrime>
wait I try kill X
<wingrime>
ok It helps
<techn__>
ok.. then it could be xorg driver problem :/
<wingrime>
who can help?
gzamboni has quit [Quit: Saindo]
ibrah has quit [Ping timeout: 256 seconds]
<WarheadsSE>
looks pike i might have my hands full with 3.9 kernels soon.......
<ssvb>
wingrime: looks like some kind of problem with the hardware cursor
<ssvb>
wingrime: you can try to add 'Option "HWCursor" "false"' to xorg.conf and check if this helps
<ssvb>
wingrime: but it's a good idea to start with just a basic xf86-video-fbdev driver to see if it survives better
<wingrime>
ssvb: I will try
ibrah has joined #linux-sunxi
<ssvb>
with the hardware cursor, whenever you move the mouse, the driver tries to update hardware cursor position via ioctls
<ssvb>
it could be that the state of the sunxi-disp kernel driver (or disp hardware) is messed up after resume, so it behaves funny
<ssvb>
killing the x server probably re-initializes the video mode and recovers it back to normal
ibrah has quit [Ping timeout: 260 seconds]
<hramrach>
[ 10.750000] netpoll: netconsole: usb0 doesn't support polling, aborting
<hramrach>
meh
n01 has joined #linux-sunxi
<WarheadsSE>
ssvb, iirc, when you init the display, it resets to the fex configuration, completely resetting any changes prior
<ssvb>
wingrime: as one more experiment, you could also try switching between some VT and back to X (ctrl-alt-f1, ctrl-alt-f7) to see if it does anything useful
<WarheadsSE>
also, could use the a10_display stuff from doozan, see what that does
<ssvb>
WarheadsSE: what do you mean? using fbset tool it is possible to change framebuffer configuration at runtime
<wingrime>
ssvb: nop HW cursor false not helped
<wingrime>
ssvb: I make some investegation
<wingrime>
ssvb: If I suspend using xfce "Suspend" but triggers
<wingrime>
ssvb: If I suspend using echo "mem" or "standby" > /sys/power/state
<wingrime>
allworks
<wingrime>
ssvb: when I change VT
<wingrime>
VT works
<wingrime>
Xorg not
<wingrime>
ssvb: I can switch VT and xorg as I want
<Dreadlish>
wingrime: i told you that it however works?
<hramrach>
maybe stuff breaks when X tries to render in suspend
<wingrime>
Dreadis: yes
<wingrime>
ssvb: screen begen to flash even while suspending
<wingrime>
ssvb: I don't know why suspend using xfce so long
<wingrime>
DreadLish: more intersing how quick gnome shell woks?
<Dreadlish>
wingrime: hm, it takes 100% from cpu ;d
<Dreadlish>
of*
<Dreadlish>
if it wouldnt, it worked better ;d
<techn__>
Dreadlish: with which xorg driver? did you try ssvb's?
<Dreadlish>
hm
<Dreadlish>
yup
<wingrime>
DreadLish: I still wait x86 based on mali gl
<wingrime>
*xf86-video
<Dreadlish>
techn__: it takes 100% on ssvbs driver
<Dreadlish>
sunxifb
<techn__>
Dreadlish: are you sure that you are using hw gl? :/
<Dreadlish>
not really
<wingrime>
DreadLish: what DE works good on sunxi ?
<Dreadlish>
its good that its any driver which isnt fbdev ;d
<ssvb>
so the performance is roughly the same as with xf86-video-mali for gnome-shell just because dri2 buffers are copied by the cpu
<wingrime>
ssvb: I failed to lauch mali drivers
<ssvb>
Dreadlish: the thing that has reasonably good performance is kwin_gles
<wingrime>
[ 984.742] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/sunxi-mali_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/sunxi-mali_dri.so: cannot open shared object file: No such file or directory)
<Dreadlish>
uh.
<techn__>
wingrime: its normal :)
<techn__>
rtfm :p
<ssvb>
Dreadlish: also assuming that the buffers flipping is fixed and we eliminate redundant copies, gnome-shell is still consuming a lot of cpu by itself
<techn__>
ssvb: nice.. also nice work with g2d. Looks like it will be usefull also in future (a20/a31) :)
<ssvb>
well, that commit does not provide any functional changes, just a bit more information to assist troublesshooting
<wingrime>
ssvb: maybe a13 have g2b
<techn__>
wingrime: I havent tried but iirc a13 doesnt have g2d
<wingrime>
techn__: he dumped reg mem ?
eebrah has joined #linux-sunxi
<techn__>
wingrime: who?
<ssvb>
techn__: the good thing about g2d in a20/a31 is that it supposedly supports premultiplied alpha, I also tried to set the same configuration bits in the hw registers for g2d in a10, but they had no effect
<techn__>
:(
shineworld has quit [Ping timeout: 276 seconds]
<ssvb>
techn__: no premultiplied alpha means that g2d in a10 can't do alpha blending in one pass, that's a serious performance issue
<ssvb>
techn__: I mean alpha blending according to xrender semantics
<Dreadlish>
hoh
<wingrime>
ssvb: we should not use g2d for such things as we have opengl gpu
<Dreadlish>
testing ts ;]
<ssvb>
wingrime: yes, after we figure out how to do efficient 2D acceleration with the opengl gpu
<wingrime>
ssvb: wait Wayland
<techn__>
qml performs really nice top of gles2 :)
<ssvb>
wingrime: amd people are experimenting with the glamor driver (implementing xrender on top of opengl), so far the results are pitiful
<ssvb>
techn__: yes, it would surely help to throw away all the linux desktop software and rewrite it with qml :)
<ssvb>
wingrime: I mean switching between VT and X involves change of the video mode, so it could probably recover the proper state in X after resume
<ssvb>
wingrime: or maybe not
<ssvb>
and yes, a lot of basic 2D graphics operations are supposed to be faster with 16bpp compared to 32bpp
<wingrime>
ssvb: still same shit
<ssvb>
wingrime: is it difficult to build thesuspend/resume?
<ssvb>
wingrime: sorry, I mean are there some extra suspend related kernel patches to be applied to stage/sunxi-3.4?
<wingrime>
not
<wingrime>
difficult
<wingrime>
just add PM_SUSPEND
<wingrime>
in menuconfig
<techn__>
ssvb: PM_SUSPEND is already there :p
<techn__>
atleast in my .config it was
<wingrime>
a13 have very old config
<techn__>
in 3.0
<techn__>
wingrime: I tried supend with a10
<techn__>
Currently trying to get a13 boot on nand
<techn__>
with cwm10
<techn__>
looks like I'm first (if I get this working) :p
eebrah has quit [Read error: No route to host]
ibrah has joined #linux-sunxi
shineworld has joined #linux-sunxi
<ssvb>
techn__: yes, I have CONFIG_SUSPEND=y in mine, and seems like it is working almost properly
<ssvb>
techn__: resuming 16bpp desktop brings it back in 32bpp mode, so it looks like the screen is split into two parts, but switching to VT and back recovers it to normal
<techn__>
hmm.. it's disp problem
<techn__>
or could be
<techn__>
disp notices "new" display and resets its state
rellla has joined #linux-sunxi
<ssvb>
techn__: actually I have just updated to the very latest kernel and this problem disappeared
<techn__>
great
shineworld has quit [Ping timeout: 276 seconds]
<wingrime>
Dreadlish: look like e17 bug like hell with touchinput
<ssvb>
techn__: yeah, does everything also work fine for you? I just wonder how to reproduce the same problems as wingrime
<Dreadlish>
wingrime: yeah it does.
<techn__>
ssvb: havent tried that yet
<wingrime>
ssvb: don't forget I have a13
<wingrime>
without g2b
<wingrime>
ssvb: it may be blacklight issue
<wingrime>
ssvb: i also have fblogo in config
<wingrime>
ssvb: i can send you mine .config
<wingrime>
ssvb: also. remember that I used "XFCE" wm "suspend" that make something with WM
<wingrime>
*xorg
<ssvb>
wingrime: I see, I could try your config on my a10, but probably it would be more interesting to hear from the other a13 owners
<ssvb>
wingrime: I tried both XFCE suspend and echo to /sys/power/state
<wingrime>
Dreadlish: can you try to suspend ?
ibrah has quit [Ping timeout: 256 seconds]
shineworld has joined #linux-sunxi
<Dreadlish>
wingrime: sorry, i'm in bed now
<Dreadlish>
maybe tomorrow ;)
ibrah has joined #linux-sunxi
rz2k has joined #linux-sunxi
ibrah has quit [Ping timeout: 246 seconds]
n01 has quit [Quit: leaving]
wingrime has quit [Ping timeout: 272 seconds]
rellla has quit [Remote host closed the connection]
<oliv3r>
mnemoc: well do we want a board.c/dram.c per tablet/board? how do i get ./configure mytablet(.fex) to use, for example cubieboard_512 u-boot
<techn__>
mnemoc: CONFIG_EARLY_PRINTK=y, CONFIG_SW_DEBUG_UART=0 .. nothing from kernel :(
<mnemoc>
oliv3r: you are seriously messing up things :<
<mnemoc>
oliv3r: for mytablet.fex you need a mytablet board in u-boot
<Epsylon3>
./configure is for the same machine
<Epsylon3>
euh
<Epsylon3>
or to build also lol :)
<mnemoc>
:)
<Epsylon3>
forgot that
<Epsylon3>
weird there is nothing to configure on android repos
ibrah has joined #linux-sunxi
<mnemoc>
Epsylon3: in the android case the bsp should populate device/allwinner/mytablet if not present, and make it use the right kernel from build/sun4i_crane-linux or whatever was chosen
<mnemoc>
but time is... limited
<Epsylon3>
the right defconfig you mean ?
<Epsylon3>
or different trees ?
<mnemoc>
no, prebuilt
<Epsylon3>
oh
<mnemoc>
well... built by the bsp
<mnemoc>
but prebuilt from android's pov
<Epsylon3>
i see
<Epsylon3>
prebuilt if present
<mnemoc>
because all A10 devices use the same, all A13 use the same, etc...
<Epsylon3>
like android, before
<mnemoc>
rebuilding the kernel for every board is (in our case) a huge waste of resources
<mnemoc>
we only need one per soc
<Epsylon3>
yep, or sources to build extra modules
<Epsylon3>
(drivers)
<Epsylon3>
thats the problem on a board with usb
<Epsylon3>
you need a lot of modules
<mnemoc>
all our boards have usb
<Epsylon3>
yep, and so all possible usb devices
<Epsylon3>
tv cards, 3G modems, etc
<mnemoc>
and a big reason to not want to rebuild for each :p
<mnemoc>
building once is enough
<Epsylon3>
and the worst, wifi dongles
<Epsylon3>
with firmwares
<Epsylon3>
tv is hard also
ibrah has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
<RaYmAn>
it's ok mnemoc , you can troll Epsylon3 all you want :P
<mnemoc>
but anyhow, including a .c is ugly^3
<mnemoc>
RaYmAn: :)
<Epsylon3>
:p
<Epsylon3>
i come back for a french Auberge :)
<Epsylon3>
the duck was nice ^^
<Epsylon3>
argh, there is no prebuilts in ics
<Epsylon3>
damn, lets go on jellybean
<Epsylon3>
:p
<Epsylon3>
i guess they removed that to reduce the tarball size
<oliv3r>
mnemoc: i haven't messed anything up yet, but every fex, how little change it has, thus needs its own u-boot config then; even when memory timings areidentical? wouldn't we get hundrereds of boardfiles :)
<Epsylon3>
nah, you have the script.bin for config
<Epsylon3>
(i didnt built uboot yet on this)
<Epsylon3>
and it will be required to reboot to fastboot mode
<Epsylon3>
only recovery is handled on "stock" one
<Epsylon3>
adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program
<Epsylon3>
adb reboot-bootloader - reboots the device into the bootloader
<mnemoc>
linux can't configure the dram
<mnemoc>
that goes "hardcoded" in the spl (or boot0 when booting from nand)
<oliv3r>
i'll make a board.c for my board then (via fexc)
<oliv3r>
hopefully it'll run at 480 MHz :p
<Epsylon3>
root@epsytour:/repos/cubieboard-tv-sdk# fastboot flash system out/target/product/cubieboard/system.img && fastboot reboot
<Epsylon3>
sending 'system' (180046 KB)...
<Epsylon3>
OKAY [ 85.454s]
<Epsylon3>
180MB/85
<Epsylon3>
hmm
<Epsylon3>
2.1MB/s
<oliv3r>
i was thinking about that, dynamic ram configurting, if we get a script.bin parser into SPL, even if it's from a raw partition (embedded devices have that often) we could atleast have embedded dynamic dram loading
<Turl>
like spl already does? :P
<oliv3r>
u-boot-spl has script.bin parser?
<mnemoc>
oliv3r: no
<oliv3r>
i was gonna say
<mnemoc>
oliv3r: also the spl can't read the fat partition either
plan_b has quit [Quit: plan_b]
<Epsylon3>
ext only ?
<oliv3r>
nothing yet
<mnemoc>
not even
<oliv3r>
that's why i say, raw partition
<Epsylon3>
ouch, you can do a raw yes :)
<Epsylon3>
like kmsg dumps
<Epsylon3>
last_kmsg
<oliv3r>
dynamic loading of script.bin from raw partition > compiling per board
<mnemoc>
that script.bin is too big to be loaded to sram
<mnemoc>
the*
<oliv3r>
mmap the raw partition ;D
<Epsylon3>
gzip it :p
<mnemoc>
oliv3r: not sure if you can do that at spl (baremetal) level
<oliv3r>
do we have uclibc or some libc support in u-boot? (probably not)
<oliv3r>
anyway, you don't have to load the file into memory, if you can read the raw data, you just read raw blocks; yes it'll be slow, but if it can be done in 250ms or 500ms it's fast enough
<oliv3r>
klibc?
<mnemoc>
one solution is to generate a dd-able binary header of the dram_para, and make the spl read that
<Epsylon3>
what is the point ?
<Epsylon3>
kernel is made for that... handle all
<mnemoc>
Epsylon3: single u-boot bin
<mnemoc>
not per-board
<oliv3r>
MUCH easier way to handle various dram parameters :)
<techn__>
stock allwinner nand image stores dram info to raw partition where it is read in really early state.. boot0 :/
<oliv3r>
Epsylon3: kernel can't initialize DRAM, only SPL can
<Epsylon3>
hmm
<oliv3r>
techn__: is it in raw partition?
<Epsylon3>
i seen that already
<Epsylon3>
releasing bootloader memory blocs
<Epsylon3>
you need to allocate it then release it
<Epsylon3>
on early boot
<oliv3r>
i haven't looked at how boot0 does memory init to be fair :p
<Epsylon3>
ive seen that in the atrix kernel
<Epsylon3>
or galaxy r one
<Epsylon3>
tegra 2 both
<oliv3r>
mnemoc: a nother solution is to seperate dram_para from script.bin and have only that section in a raw partition
<Epsylon3>
bootloader often some memory bloc for logo display
<oliv3r>
i realy have to get a cubieboard A20 to play with these things :)
<Epsylon3>
alloc some memory i mean
<oliv3r>
Epsylon3: the problem is, when the BROM loads the SPL, there is no memory available, just the 32k built in SRAM, of which only 20k are available i think
<mnemoc>
oliv3r: use fexc to turn [dram_para] into a ready-to-read struct dram_para
<oliv3r>
mnemoc: exactly, and put that in a raw partition
<techn__>
oliv3r: yes.. I think it could be 0x0 - 0x1000000 :/
<oliv3r>
how does u-boot handle the mac address? (boot from lan)? since mac is dynamic
<oliv3r>
mnemoc: cn fexc do that lalready?
<mnemoc>
not yet
<mnemoc>
but it's trivial
<oliv3r>
should be yes; well I first have to get a kernel built and get this touchscreen driver to debug
<hramrach>
techn__: does it really read dram para from partition?
<oliv3r>
i think hansg's fedora kernel doesn't let me debug or doesn't work with modules from my sunxi build :S
<oliv3r>
hramrach: doesn't sound too weird
<techn__>
oliv3r: but you could verify nand content from Ithamar (image repacker guy)
<hramrach>
because I wiped all partitions except the fist and the system still booted
<oliv3r>
hramrach: livesuit injects dram parameters into boot0, livesuit sets up mac address, how does livesuit know all this? only place that's unique to each device is the raw partition
<techn__>
hramrach: atleast it reads debug output port from script.bin
<oliv3r>
techn__: i used that to extract my default script.bin; memory section is empty
<hramrach>
well, it no longer knows. I deleted the partition
<hramrach>
but don't use livesuit so don't really care
<techn__>
or I mean that it reads debug output port from SYSCONFIG1 "partition"
<oliv3r>
hramrach: what is your mac addres?
<hramrach>
I don't care
<mnemoc>
the dram_para section of script.bin MUST be completed/verified using a10meminfo from android
<oliv3r>
hramrach: then it doesn't matter :)
<hramrach>
I think I set up some random mac address in the filesystem
<mnemoc>
because livesuit probes the ram and configures boot0 during flashing
<mnemoc>
mostly ignoring whatever comes on the image
<oliv3r>
we shhould have some backup tool that extracts the 'unique' partition from a device, so you can always have your serial/mac/dram para's from that partition :D
<oliv3r>
mnemoc: are you sure it's probing the ram?
<oliv3r>
mnemoc: isn't it possible it is stored at the same location where the mac addess is stored?
<hramrach>
oliv3r: oh and mac address was 0, anyway
<Epsylon3>
tftp is not built in this uboot version ?
<oliv3r>
unless of course, the mac is 'generated' somewhere based on CPU serial number (mine reads 000000) and 'base' allwinner mac
<mnemoc>
Epsylon3: the sunxi-current branch supports tftp
<hramrach>
oliv3r: I suspect it's generated based on daytime
<techn__>
hmm.. or does sunxi chips have internal nand? :)
<mnemoc>
oliv3r: no, it's officially "magic" done by livesuit during flashing
<mnemoc>
trial-and-error probably
<Epsylon3>
i suspect oliver to transform uboot into a kernel ;)
<hramrach>
we don't need another os loader os
<Epsylon3>
linux was like uboot 15 years ago
<hramrach>
grub is for that
<Epsylon3>
:p
<oliv3r>
i'll have to inspect some of the hidden partitions and see what'sthere
<hramrach>
you need to echo 0 > /sys/devices/virtual/android_usb/android0/enable
<hramrach>
and then 1
<hramrach>
can't cahnge functions when enabled
<Epsylon3>
yep, a reset
<Epsylon3>
or cable unplug
<hramrach>
still node device comes up
<hramrach>
no device
<Epsylon3>
lsusb ?
<oliv3r>
crap; i should have removed dram_para from the generic fex
<Epsylon3>
because most protocols need more... a deamon for the soft part
<oliv3r>
mnemoc: i may redo the entire patch set; don't do anything with it yet, there's some typo's in my board specific patch (though I can fix that easily)
<hramrach>
rndis works without a daemon when not under android
<mnemoc>
oliv3r: ok :)
<oliv3r>
i'll repost it then in combination with u-boot support
<mnemoc>
oliv3r: but please don't introduce "abstract" boards. please
<Epsylon3>
rndis on android is used for usb tether
<hramrach>
when only rndis is enabled it does something
<Epsylon3>
often in bad way : (i handle all and not you)
<oliv3r>
mnemoc: also, i may add a '-T' parameter to fexc to 'test' a fex file for errors, it checks already so should be trivial
paulk-desktop has quit [Quit: Ex-Chat]
<Epsylon3>
i was fights other android java oriented guys in CM for that ;)
<Epsylon3>
a german, eerk
<hramrach>
I can ping
<Epsylon3>
fighting*
<hramrach>
so rndis under android works when only rndis is enabled
<Epsylon3>
rndis protocol can do all
<Epsylon3>
alone
<mnemoc>
oliv3r: cool :)
<Epsylon3>
but the java part of android hide it
<hramrach>
maybe enabling one of the gadgets that requires userspace part or is otherwise broken causes the whole thing to fail
<Epsylon3>
it was present already on motorola froyo phones
<hramrach>
rndis cannot do netconsole
<Epsylon3>
netconsole ?
<hramrach>
netconsole !
<Epsylon3>
i mean its a eth interface
<Epsylon3>
you have an ip, then you can put apache if you want to
<Epsylon3>
netconsole ?
<hramrach>
[ 10.750000] netpoll: netconsole: usb0 doesn't support polling, aborting
<hramrach>
netconsole !
<Epsylon3>
i need to google that
<Epsylon3>
udp
<Epsylon3>
oh, a linux adb ?
<hramrach>
Documentation/networking/netconsole.txt in Linux
<hramrach>
I don't know what adb is
<hramrach>
never seen it working
<Epsylon3>
its that
<oliv3r>
hramrach: android debug bridge
<Epsylon3>
adb logcat
<Epsylon3>
adb logcat radio
<Epsylon3>
adb logcat kernel (seen before)
<oliv3r>
hramrach: it allows you to open a shell, send/pull files etc to an android device
<Epsylon3>
like the dmesg
<Epsylon3>
but from usb or eth
<mnemoc>
the most useful thing invested by android :)
<hramrach>
it would be cool if it worked
<oliv3r>
adb isn''t half bad
<mnemoc>
invented*
<Epsylon3>
yep, and merged recently i heard
<Epsylon3>
last year or so
<Epsylon3>
in mainline
<hramrach>
well, could give it another try now that it's even possible to install adb tools in Debian
<mnemoc>
linaro has a ppa with it for ubuntu
<Epsylon3>
that was the war first between google and linus i guess ;)
<oliv3r>
who maintains board.cfg from u-boot; its messy :)
<Epsylon3>
nvidia is worst
<Epsylon3>
adb is open, not gpl but open
<Epsylon3>
apache = do want you want to do
<Epsylon3>
sell it if you want
<oliv3r>
adb is a simple 'daemon' though that runs as root just after init? how does it need to be mainlined?
<Epsylon3>
but keep the header
<mnemoc>
oliv3r: random-sorted :p
<Turl>
going back to spl, can't you just put some markers on the dram struct, then look for it and binary patch? :)
<mnemoc>
oliv3r: the gadget driver
<oliv3r>
mnemoc: no i mean, its supposed to be whitespace sperated, but most boards are seperated with spaces, fine, but hten there's some with half-space, half-tab, and some full tab
<mnemoc>
uh
<oliv3r>
mnemoc: the gadget driver does adb? i dind't know, i thought it was adbd that was responsible for that
<oliv3r>
mnemoc: but not just allwinner stuff, it's just messy
<mnemoc>
life is messy
<oliv3r>
if i'll get board, i'll clean it up :)
<oliv3r>
but i'll do the upstream one
<Turl>
without messy it'd be boring :)
<mnemoc>
Turl: +1
<Turl>
mnemoc: just drafted some cdxalloc integration into gralloc
<oliv3r>
ok, so i modified board.cfg, i added boards/allwinner/myboard; what else do i have to do to make sunxi-bsp happy with my new board?
<mnemoc>
oliv3r: see the previous commits
<oliv3r>
do'h of course
<mnemoc>
sunxi-bsp is happy if the u-boot board and the fex are called the same
<oliv3r>
i've either overlooked osmething or did a typo, i named it the same
<Epsylon3>
adbd is required for adb
<mnemoc>
Turl: :)
<Epsylon3>
and adbd works also on the network
<Epsylon3>
wifi or ethernet
<Epsylon3>
even bluetooth
<Epsylon3>
with tcp parameter/property
<Epsylon3>
like a ftp
<Epsylon3>
its a deamon i mean
<Turl>
mnemoc: it's gonna leak all the things, but if it works then I can RE the alloc stuff properly :P
<oliv3r>
mnemoc: it somehow appends _config, i don't understand
<mnemoc>
Epsylon3: 3.8 is multi-platform already. the effort to port sunxi to 3.8 is almost equivalent to the effort needed to mainline it... so imho 3.8 is kind of a... distraction