<libv>
new_info->core_info = NULL; /* Not used by user space */
<libv>
and how am i going to tell which mali i am running against?
marcan has quit [Quit: Coyote finally caught me]
<libv>
i will be re-adding that code soon
marcan has joined #arm-netbook
<libv>
hrm, how would one distinguish between mali400-mp1 and mali400-mp4?
<libv>
hrm, new callbacks?
<libv>
err, ioctls
<slapin_>
hno: ping
<Mehhh_>
does the deb image have the mali drivers (hw accel?)
drachenphone has quit [Ping timeout: 245 seconds]
<Turl>
libv: performance? :P
drachenphone has joined #arm-netbook
popolon has quit [Quit: Quitte]
<libv>
Turl: no, to utilize all fragment shaders on the mp4, you will need to divide up the blocks, and issue 4 separate jobs, one for each core
<libv>
so you need to have this information in userspace
<libv>
anyway, creating a git tree which has all the different arm thrown-over-the-hedge kernel drivers
<libv>
so i can better see what they changed ioctl wise
t0dbld1 has left #arm-netbook [#arm-netbook]
tuliom has quit [Quit: Konversation terminated!]
stefanro has joined #arm-netbook
ssvb has quit [Ping timeout: 260 seconds]
stefanro1 has quit [Ping timeout: 240 seconds]
<hno>
Triffid_Hunter, Turl, compared to an average X86 system the A10 is relatively easy to do bare metal on. The "User guide" + ARM manuals covers most of what you need to know, with the exception of the DRAM controller if doing the early initialization part.
<hno>
slapin_, pong?
vinifm has joined #arm-netbook
<markvandenborre>
I'm fiddling with an embedded a13 board
<markvandenborre>
just compiled in full HID support into the kernel
<markvandenborre>
(my first cross compile was amazingly easy)
<markvandenborre>
this HID device now works; I can verify that by catting /dev/input/event1
<markvandenborre>
(random garble comes out of that every time I press the one key on this HID device)
<markvandenborre>
now I want to have this HID device hooked up into a small shell script that I wrote
<markvandenborre>
this shell script uses the "read" command quite often
<markvandenborre>
in other words, it expects an active terminal
<markvandenborre>
what would be the best way forward? change this script so that it picks up key press events from the HID device without being attached to it?
<markvandenborre>
auto spawn a terminal in /etc/inittab?
<markvandenborre>
I'm not sure where to ask this question; any suggestions on an appropriate channel?
<lundman>
aborre: this is a fine channel, but the timezone is awkward
merbzt has quit [Ping timeout: 264 seconds]
<Turl>
if you run your script on fbcon vt it should grab HID input I'm guessing
<Turl>
night :)
freakazoid0223 has quit [Quit: Leaving]
Svet has joined #arm-netbook
Svet has joined #arm-netbook
Svet has quit [Changing host]
Sv has quit [Ping timeout: 276 seconds]
luka has quit [Ping timeout: 240 seconds]
vinifm has quit [Quit: Ex-Chat]
luka has joined #arm-netbook
luka is now known as Guest91527
gsilvis has quit [Read error: Connection reset by peer]
<slapin_>
hno: https://github.com/slapin/uboot-allwinner/commits/work - please don't do any work based on this, I'm going to rearrange this stuff appropriately. If you can, please justify this udelay(100) - it is very flaky without it.
<hno>
which udelay?
<slapin_>
hno: see patches. at the end of command processing function
<hno>
slapin_, something you forgot to push maybe?
<hno>
I only find initialization sequence there, no command processing.
<hno>
slapin_ sunxi_nand.c missing.
<bsdfox_>
aren't there some unused timers on A10?
<bsdfox_>
why are we using delay()
alcides has quit [Quit: To be continue...]
<lkcl>
bsdfox_: there are some circumstances where it's absolute hell to organise GPIO bring-up etc. esp. in embedded systems.
<lkcl>
one such circumstance, a mobile phone's capacitors for the power-up of a GSM Radio ROM simply weren't big enough
<lkcl>
so the bring-up sequence was:
<lkcl>
* pull GPIO for 5V line power
<lkcl>
* pull GPIO for 3.3V line power
<lkcl>
pull 2nd GPIO for 2nd 3.3V line power
<lkcl>
udelay(10)
<lkcl>
pull down the 1st 3.3V power
<lkcl>
udelay(10)
<lkcl>
pull down the 5V power
<lkcl>
udelay(10)
<lkcl>
pull them back up again
<lkcl>
udelay(10)
<lkcl>
pull the GPIO for reset up
<lkcl>
udelay 10
<lkcl>
pull everything down again
<lkcl>
udelay 10
<lkcl>
by this time, the on-board GSM radio ROM's capacitors had enough charge.....
<lkcl>
so it was then possible to do this sequence a *second* time, and the device would come up properly.
<lkcl>
you _could_ do all that with timers but it would be absolute hell, and completely non-obvious
MindBeat has quit [Ping timeout: 245 seconds]
MindBeat has joined #arm-netbook
unknown_lamer has quit [Remote host closed the connection]
drachensun has quit [Remote host closed the connection]
<bsdfox_>
lkcl, if you've got a dedicated timer for application it wouldn't be a big deal
<bsdfox_>
and you wouldn't just be burning clock cycles
<bsdfox_>
also, fuck that gsm module
<lkcl>
bsdfox_: for the complexity involved due to the asynchronous code that results it's often not worth it
<lkcl>
bsdfox_: :)
<lkcl>
this was for an HTC Smartphone (reverse-engineered).
<lkcl>
people kinda expected to be able to communicate using it :)
<bsdfox_>
yeah that's the problem with reverse engineering
<lkcl>
ah no - in this case, that was direct reverse-engineering of the assembly files.
<bsdfox_>
there's probably a straight forward approach to initializing the radio that doesn't require all the funky steps
<lkcl>
this was that the... no, it didn't, that's the point.
<lkcl>
i examined the assembly code: that was what they were forced to do.
<lkcl>
istrc that WIFI was similar
<bsdfox_>
which radio did it use?
<lkcl>
it was just poor hardware design
<lkcl>
i thiiink.... it was an ericsson chipset.
<lkcl>
it just pulled so much current at startup that it couldn't cope
<bsdfox_>
from what I've seen cell phone companies invest much more in hardware than software
<bsdfox_>
lkcl, polling is fine if the code is designed for it
<lkcl>
.... qualcomm is run by three lawyers :)
<bsdfox_>
lkcl, qualcomm employs some very good engineers
<bsdfox_>
I met adrian chadd last weekend who writes the atheros drivers for linux and in his spare time ports the drivers to freebsd and also wrote/maintains their 802.11 stack
drachenphone has quit [Read error: Connection reset by peer]
drachenphone has joined #arm-netbook
drachensun has joined #arm-netbook
ppord has joined #arm-netbook
cat_x301 has quit [Ping timeout: 255 seconds]
grimes99 has joined #arm-netbook
rellla has joined #arm-netbook
<ccssnet>
bsdfox_: if so, why is it so hard to get the ubicom32v5 firmware sources to build (qualcomm bought ubicom, and i havent yet seen them take effort to support it)
<hno>
Ah, think I understand why I only got random garbage in my earlier NAND exploration attempts. The data is randomized by the controller.
<orly_owl>
i think the idea is it goes on top of your tv
luka is now known as Guest9472
Guest9472 has quit [Client Quit]
<rm>
yeah I figured that part out
luka_ has joined #arm-netbook
<orly_owl>
i dont see how its crazy then
<orly_owl>
it rotates to get the camera angle right
luka_ has quit [Client Quit]
luka has joined #arm-netbook
luka has quit [Changing host]
luka has joined #arm-netbook
<rm>
to me video conferencing seems to be a rare and fringe use, and specializing the device for it so much seems odd
<rm>
also why not just include a separate web cam
<rm>
rather than built-in to the case
<orly_owl>
cheaper to build it in of course
<orly_owl>
im not sure video chat via tv will take off
<orly_owl>
i see it advertised sometimes
ssvb has joined #arm-netbook
popolon has joined #arm-netbook
vgrade_ has joined #arm-netbook
Quarx has joined #arm-netbook
cat_x301 has quit [Quit: Leaving.]
<hno>
orly_owl, I think there is potential for "TV" chat. But requires some yet unseen intelligence in the camera part to work well in the environment.
tzafrir has joined #arm-netbook
<slapin_>
hno: ping
<slapin_>
hno: try again
<slapin_>
hno: branch was rebased, though
Svet is now known as sv
ppord has joined #arm-netbook
ppord has quit [Client Quit]
ppord has joined #arm-netbook
<slapin_>
hno:
jquip has joined #arm-netbook
tzafrir has quit [*.net *.split]
drachensun has quit [*.net *.split]
dfletcher_ has quit [*.net *.split]
markvandenborre has quit [*.net *.split]
orly_owl has quit [*.net *.split]
jeremb has quit [*.net *.split]
ccssnet has quit [*.net *.split]
ChanServ has quit [*.net *.split]
vgrade_ has quit [*.net *.split]
sspiff has quit [*.net *.split]
Mehhh_ has quit [*.net *.split]
Entropy512 has quit [*.net *.split]
raoulh has quit [*.net *.split]
stefanro has quit [*.net *.split]
rmeyerriecks has quit [*.net *.split]
tzafrir has joined #arm-netbook
vgrade_ has joined #arm-netbook
drachensun has joined #arm-netbook
stefanro has joined #arm-netbook
dfletcher_ has joined #arm-netbook
markvandenborre has joined #arm-netbook
orly_owl has joined #arm-netbook
Mehhh_ has joined #arm-netbook
ccssnet has joined #arm-netbook
sspiff has joined #arm-netbook
rmeyerriecks has joined #arm-netbook
jeremb has joined #arm-netbook
Entropy512 has joined #arm-netbook
raoulh has joined #arm-netbook
ChanServ has joined #arm-netbook
ol1ver has quit [Remote host closed the connection]
<slapin_>
hno:
ol1ver1 has joined #arm-netbook
ppord has quit [*.net *.split]
popolon has quit [*.net *.split]
phh has quit [*.net *.split]
Holo_ has quit [*.net *.split]
pawel5870 has quit [*.net *.split]
luka has quit [*.net *.split]
sv has quit [*.net *.split]
mSquare has quit [*.net *.split]
L84Supper has quit [*.net *.split]
xenoxaos has quit [*.net *.split]
e-ndy has quit [*.net *.split]
ppord has joined #arm-netbook
popolon has joined #arm-netbook
pawel5870 has joined #arm-netbook
luka has joined #arm-netbook
mSquare has joined #arm-netbook
sv has joined #arm-netbook
L84Supper has joined #arm-netbook
Holo_ has joined #arm-netbook
phh has joined #arm-netbook
xenoxaos has joined #arm-netbook
e-ndy has joined #arm-netbook
RITRedbeard_ has quit [*.net *.split]
pwhalen has quit [*.net *.split]
focus_well has quit [*.net *.split]
mikey_w has quit [*.net *.split]
Kraln has quit [*.net *.split]
The-Compiler has quit [*.net *.split]
destinal has quit [*.net *.split]
RITRedbeard_ has joined #arm-netbook
focus_well has joined #arm-netbook
mikey_w has joined #arm-netbook
Kraln has joined #arm-netbook
pwhalen has joined #arm-netbook
destinal has joined #arm-netbook
The-Compiler has joined #arm-netbook
mSquare has quit [*.net *.split]
L84Supper has quit [*.net *.split]
e-ndy has quit [*.net *.split]
xenoxaos has quit [*.net *.split]
luka has quit [*.net *.split]
pawel5870 has quit [*.net *.split]
sv has quit [*.net *.split]
mSquare has joined #arm-netbook
xenoxaos has joined #arm-netbook
e-ndy has joined #arm-netbook
L84Supper has joined #arm-netbook
luka has joined #arm-netbook
sv has joined #arm-netbook
pawel5870 has joined #arm-netbook
acfrazier has quit [*.net *.split]
blahee has quit [*.net *.split]
Triffid_Hunter has quit [*.net *.split]
acfrazier has joined #arm-netbook
blahee has joined #arm-netbook
Triffid_Hunter has joined #arm-netbook
rellla has quit [*.net *.split]
Gumboot has quit [*.net *.split]
lerc has quit [*.net *.split]
ZaEarl has quit [*.net *.split]
traeak has quit [*.net *.split]
rellla has joined #arm-netbook
lerc has joined #arm-netbook
Gumboot has joined #arm-netbook
ZaEarl has joined #arm-netbook
traeak has joined #arm-netbook
<hno>
slapin_, makes more sense now. Easier to follow if you gut out the #if 0 stuff.
<hno>
Regarding the delay, I would suppose we need to wait for some additional completion bit somewhere. Or maybe the interrupt status is off by one? Try clearing the interrupt status before seding command.
<slapin_>
hno: it is prototype code, as all features work, I'll reqrite it.
<slapin_>
hno: will try after I get home and sleep(86400)
<slapin_>
hno: feel free to try all the things
<hno>
I would, but very short on time today and tomorrow.
<hno>
slapin_, /* Waiting for interrupt flag to be set */
<slapin_>
hno: have you tested it? (I can't but I can commit fix now)
<slapin_>
hno: thanks for finding this one
<hno>
Have not tested, but quite obvious logic error.
<hno>
compared your code to allwinner code, reading side by side.
<hno>
no time to seriousy test anything until thursday.
ppord has quit [Quit: Leaving.]
<slapin_>
hno: thanks. will try tonight
Almamuetya11 has joined #arm-netbook
ZaEarl has quit [Ping timeout: 260 seconds]
Almamuetya12 has joined #arm-netbook
Almamuetya11 has quit [Ping timeout: 256 seconds]
<hno>
slapin_, tested briefly now and always get "NAND: No NAND device found!!!" on cubieboard, even without changing those int flag checks.
<hno>
so can't test if the change works. But at least it does not hang with or without the change.
<hno>
will debug it further when getting time.
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
<slapin_>
hno: try #define DEBUG in configs/sun4i.h at top before includes, then in sunxi_nand seek to sunxi_nand_command and enable debug at beginning of function, then go to sunxi_nand_read_byte and add debug("0x%02x\n", data) before return and show output (this is with udelay). Should not take more than 5 minutes of your precious time.
tinti has joined #arm-netbook
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
sspiff has quit [Ping timeout: 245 seconds]
sv has quit [Read error: Connection reset by peer]
kaspter has joined #arm-netbook
mSquare has quit [Quit: Leaving.]
sv has joined #arm-netbook
QingPei has joined #arm-netbook
<Turl>
mnemoc: installed 4.2 yet? :P
<libv>
grmbl. there is just no sane way in which the mali PP_CORE_VERSION ioctl can return -EPERM!
QingPei has quit [Ping timeout: 264 seconds]
<libv>
this while the codepath for PP_NUMBER_OF_CORES is identical, all the way to the bottom call which is not involved with the return value :(
<lkcl>
specing: i agree. just have to find connectors small enough and standard enough.
<lkcl>
7in tablets are _small_.
<RaYmAn>
I don't really see why ethernet and sata is a must on a tablet =P
<mnemoc>
afaik that "tablet" board is more of a generic reference design than a tablet
<specing>
lkcl: small? My A10 one is bulky as hell
<specing>
could fit a standard RJ45 in there
<mnemoc>
:D
<specing>
true story.
<specing>
RaYmAn: because fuck flash :)
<specing>
ducktape + 2.5" HDD FTW
<lkcl>
specing: eek!
<RaYmAn>
lol
<lkcl>
yeah as this is being driven by aaron (kde "spark" aka "vivaldi" tablet) we need to listen to his requirements.
<lkcl>
they have done a lloooooot of reviews of tablets. an insaaaane amount of testing.
<specing>
so this is yet another case of when hardware is being designed for software?
<lkcl>
specing: no. this is a case of meeting customer requirements, where customer has been through absolute hell trying to get any kind of reliable hardware *at all* out of china suppliers
<specing>
heh :)
<lkcl>
what he's found is that the 1st batch is ok but it all goes to shit when they try to redesign the PCB *without* telling them what's going on.
<lkcl>
i don't know for sure but one or two companies might even have tried to sell him a unit with a totally different processor - it wouldn't surprise me
<lkcl>
and it's like, "nooo, we neeeeed that CPU because we have the F*****G SOURCE CODE FOR IT"
<lkcl>
we don't WANT your android GPL-violating turd-in-a-can
<lkcl>
but yeah, it is more than that: the build qualities have just been so questionable that he's got fed up with it
<specing>
Plasma Active Tablet's user experience is designed around the web, social networks and multimedia content.
<specing>
Oh no, Android 2.0
<lkcl>
that's the ... *ROTFL*
<jinzo>
Again, Ainol Novo _might_ be interested.
<jinzo>
and they provide some interesting stuff and quality
<lkcl>
jinzo: with GPL-violating linux kernels because they're dealing with AMLogic?
<jinzo>
lkcl, they have some older A10 based offerings ;)
<lkcl>
jinzo: aaron's been through that one already. they managed to get supply of the linux kernel source code, originally, by one of the *engineers* violating his own company's NDA.
<RaYmAn>
allwinner isn't exactly NOT GPL violating though - even if they seem to have gotten slightly better.
<jinzo>
The elf II that I ordered for a friend was amazing (for the price ofcourse)
<lkcl>
that was one of the engineers working for the ODM.
<jinzo>
and it has the usual A10 stuff in it.
<lkcl>
great.
<lkcl>
now if they'll convert it to EOMA-68, we're good to go.
<lkcl>
do you have contact details for them?
<jinzo>
and it's not in their active offering anymore - so they could be more inclined to sell it.
<lkcl>
well i'm more looking for companies that are willing to redesign casework
<lkcl>
and use the PCB design i've been working on
<jinzo>
unfortunately no, sales@ainovo.com looks like.
<jinzo>
Like I said, I don't have any particual experiance with it - but found the quality of the Elf II really good for the price point (nothing else has came close - and I tried quite some)
<jinzo>
But their website is.... an image. This looks like a semi official shop: http://www.ainol-novo.com/
hipboi has joined #arm-netbook
sv has quit [Remote host closed the connection]
sv has joined #arm-netbook
<rz2k>
anyone here who used xbmc for android, did you have OSD in xbmc?
<rz2k>
rellla: ^
<rz2k>
s/xbmc for android/xbmc for a10/
<rz2k>
because Wills in ML claims that CedarX is not detachable from CedarFB and there is no way to have VLC GUI or even have OSD
<rz2k>
:/
<oliv3r>
so the "leaked" amlogic source is what pivos is using then?
<libv>
rz2k: seems to be yet more disp work or is this deeply embedded in the cedar blobs?
<rz2k>
dont know, seems like disp can be fine like this, we just need to convert the output from CedarX to something eatable by VLC output modules. that is most obvious way.
<rellla>
rz2k: what do you mean with osd? i can watch movies in xbmc and surf through gui while video is playing in the background?! not that perfect, but usable.
<rz2k>
I mean XBMC drawing stuff right on to video output
<rellla>
works.
<rz2k>
anyway, we need you and empat0 in VLC thread :p
<rz2k>
if you done it, you have the answer to questions there.
<oliv3r>
there, more clocking stuff up on the wiki! yay i've done some work today :p
<libv>
something tells me that noone is using DISP_CMD_VERSION yet
<mnemoc>
:)
<libv>
and of course, noone poked at the sunxi_disp_driver wiki page, meaning that they either aren't running a recent kernel, or didn't bother to read the wiki
sspiff has quit [Ping timeout: 245 seconds]
<mnemoc>
i believe the second. reading documentation is for woosies
<libv>
well, in this case, it will end up harshly affecting their abilities whenever i get tired of lima again :)
<oliv3r>
heh, i've read way more documentation then I'd want to admit
<libv>
because this page should be about keeping API/ABI stable for a limited subset
<libv>
if noone cares, then why should we care about the api/abi of /dev/disp :)
kaspter has quit [Ping timeout: 245 seconds]
<mnemoc>
xbmc was whining for months that the cedarx libs were unusable.... until empat0 silently decided to read the docu. and write code :p
orly_owl has quit [Read error: Operation timed out]
<libv>
there's too many whiners, and too little doers
orly_owl has joined #arm-netbook
<oliv3r>
break api/abi if it makes the design better :)
<libv>
it will massively break things for some people
<oliv3r>
that use the latest and greatest*
<libv>
but those people either do not seem to be using this kernel yet, or can't be arsed to read the link thrown out by the kernel
<oliv3r>
right, hometime :)
<libv>
oliv3r: in which case, they have a reason not to use the latest
<oliv3r>
wrote enough docs for one day :)
sspiff has joined #arm-netbook
<mnemoc>
libv: if breaking the old api/abi comes by the hand of a vaapi lib (Turl?) it will help to encourage people to not hardcode cedarx support directly in the players :p
drachenphone has quit [Ping timeout: 252 seconds]
<Turl>
mnemoc: :P
<L84Supper>
is there a wiki with organized info of the software?
<rz2k>
if our blob only does decoding, we might have a chance.
<libv>
oh crap, did they really shift ioctls on mali
<libv>
and yes, they did.
<libv>
tossers..
pawel5870 has quit [Quit: Leaving.]
<libv>
rz2k: try strings | grep "/dev/disp"
* slapin_
got hdmi to vga cable, might be able to boot android tonight
<libv>
cable?
<libv>
i have a box with an external powersupply to do that
<slapin_>
libv: yeah, no power supply, cable on one side is VGA, on another is HDMI connector
<slapin_>
libv: no strings attached
<libv>
slapin_: are you certain that this is not specific to a specific notebook?
<slapin_>
will android work normally on 4:3 display?
<slapin_>
libv: no any special note on it
<libv>
slapin_: url?
<slapin_>
libv: bought on ebay, don't remember which
<libv>
with me, the ebay sellers of such a thing warn that the videocard must support this
<slapin_>
libv: dunno
<rz2k>
slapin_: if it is without power supply and logic - you have hdmi/vga cable for hdmi-vga enabled devices. most embedded devices implement digital-only hdmi. check wikipedia on details.
<libv>
slapin_: it is rather crucial to this whole endeavour
<Turl>
anyone know how can I visualize a graphviz graph?
<slapin_>
libv, rz2k: can you recommend proper device?
<slapin_>
Turl: dot
<libv>
slapin_: do google for the cable you got
<rz2k>
I saw many on dealextreme and aliexpress, called hdmi to vga converter or hdmi vga box
<slapin_>
libv: let me check
<libv>
if it really is a cable with standard vga and hdmi connectors, then it's going to be useless
<libv>
good, might perhaps work, as ymmv with these devices :)
<Turl>
slapin_: what a reliable tool
drachenphone has quit [Ping timeout: 245 seconds]
<Turl>
slapin_: dot: failure to create cairo surface: out of memory
<Turl>
Segmentation fault
<slapin_>
Turl: you have too big graph it seems, try to limit it.
<slapin_>
libv: a problem is that it has big HDMI connector and it doesn't connect to output cable of device, which might mean it is VGA to HDMI, not HDMI to vga thing...
<slapin_>
so, no video today :(
<libv>
should work when i look at the picture, all you need is a mini/micro adapter
<vinifm>
is there all functions of library kernel, like inb() and outb()...
<mnemoc>
vinifm: what the *censored* are you talking about?
<mnemoc>
vinifm: please give some context
<vinifm>
functions that depend on the architecture, like inb() and outb()
<Turl>
what happens with them?
<mnemoc>
beside the bugs and the low quality code, the kernel is fully functional
<vinifm>
they are available for linux sunxi?
<Turl>
we still dont understand what you're trying to ask :/
<slapin_>
Turl: ah, your .dot file is too big for dot, try to reduce amount of information. when I build my call trees it ended-up bigger with 53M .png, and no crashes
<mnemoc>
vinifm: "linux sunxi" is a normal linux tree, + android junk + sunxi junk
<Turl>
vinifm: I found outb as a macro in arch/arm/include/asm/io.h
<mnemoc>
vinifm: everything available for a normal kernel is available for the sunxi kernel
<Turl>
in/outb is a thingy to access PCI/ISA parameters on x86 from what I can gather mnemoc
<stefanro>
Turl: thx, fixing it right now - after looking very long at this one line to find a typo ;)
<Turl>
stefanro: :P
<Turl>
stefanro: I noticed it on other files too, then realised it wasn't a normal typo :)
<drachensun>
turl: I sent you a pm
<Turl>
stefanro: what's the status of it btw? is it 'bootable'?
<mnemoc>
to initramfs
freakazoid0223 has joined #arm-netbook
merbzt has joined #arm-netbook
<lkcl>
ok folks i'm off for a few days, back on friday - i will have internet access, even possibly IRC occasionally.
* lkcl
later!
lkcl has quit [Quit: Leaving]
tinti has quit [Quit: Leaving]
<Turl>
mnemoc: :)
<mnemoc>
Turl: that's the requirement for the first submition
<Turl>
mnemoc: I wonder how will allwinner react when they upgrade kernel version and see their boards supported
<mnemoc>
submission*
<mnemoc>
they are product driven, I don't they plan to get farther than 3.0 for sun4i/sun5i. "it works, don't touch it"
<Turl>
yeah but sun6i is likely to share stuff with 4/5i
<mnemoc>
yes
<Turl>
and they won't be able to 'just merge' their stuff then
<mnemoc>
see rtlwifi
<mnemoc>
"fixed" legacy driver standing next to mainline's
MindBeat has quit [Ping timeout: 245 seconds]
<Turl>
realtek offers "android support" for it
<Turl>
:P
MindBeat has joined #arm-netbook
<hno>
slapin_, tried many things, but I only get 00 00 00 00 00 00 back.
pwhalen has quit [Remote host closed the connection]
<hno>
Have full traces of both Allwinner NAND driver register accesses and your register accesses and ther is subtle difference, but nothing that sticks out as obvious cause. But a clear symptom is that ST bit #0 is held high when Allwinner code is used but low when your code is used, can't really figure out why.
<vinifm>
one more question: bit description is the same for any ARM(NXP,Allwinner)?
<hno>
slapin_, see how allwinner code gets ST=f03 after nand chip reset, but yours get f02. The only difference I can see before is that you clear ECC_CTL.
<vinifm>
LSR: bit 0 is Data available; SW_UART0_LSR: bit 0 is the same
<vinifm>
?
<focus_it>
good to compare the RK3066 dual core with A10 sources
<Turl>
vinifm: I'd expect so, yeah
<vinifm>
hum, ok
<Turl>
hno: sunxi has an 8250 right?
hipboi has quit [Remote host closed the connection]
<focus_it>
my aim is to make SO-DIMM 200 pin A10 on KiCAD - now I think I can make also RK3066 dual core!! :-)
<focus_it>
and then open sauce it all - muahhhhaaa!
drachenphone2 has quit [Ping timeout: 252 seconds]
<hno>
Turl, 16550 kind of even, with some extra bells & wistles.
<hno>
slapin_, I don't see how it could differ.
<Turl>
vinifm: ^
drachenphone has joined #arm-netbook
<Turl>
hno: maybe it's a warm-vs-cold reboot issue?
<hno>
Turl, comparing cold boots of both.
<hno>
vinifm, 8250 register programming works with the A10. You just need to multiply addresses by 4 as ARM addressing is 32-bit word aligned. And remember to open the clock gate before trying to touch the registers or bad things will happen.
<hno>
It's also recommended to configure pinmuxing (PIO) accordingly if you intend to access the serial data somehow.
<hno>
slapin_, my code is in my github repository, mtd branch.
<hno>
with tracing and all.
<hno>
and some bugfixes here and there.
drachenphone2 has joined #arm-netbook
<hno>
Hm.. looking at the Allwinner trace again I notice they are playing some game with NAND_CTL RB_SEL bit. Could that be relevant? But it's only after the traces already diverge on the ST RB_B2R bit.
drachenphone has quit [Ping timeout: 245 seconds]
<vinifm>
hno: "open the clock gate". is there a function() for this?
Hexxeh has joined #arm-netbook
<hno>
vinifm, what are you doing?
<vinifm>
I am learning to make a uart driver
<hno>
at what level?
MindBeat has quit [Ping timeout: 245 seconds]
<vinifm>
level? beginner :)
<hno>
uart driver where?
MindBeat has joined #arm-netbook
<vinifm>
do you mean platform? olinuxino-A13
<hno>
slapin_, it's not the ECC_CTL register. Fixed that and problem still the same.
Sternennebel has joined #arm-netbook
<hno>
vinifm, I mean software platform. How are you loading and starting your code?
<hno>
The clocking gates I talked about is in the clock module of the sunxi chips. Controls every clock inside the chip.
<hno>
and each UART have a separate clock that can be enabled/disabled. All off by default.
<libv>
focus_it: i am actually waiting until archos releases their rk3066 game console
<libv>
former archos devices came with openembedded, so i expect that the kernel and a few other bits for this tablet will be free
myfluxi has joined #arm-netbook
<libv>
mali400mp4 should play a mad q3a :)
<focus_it>
libv: will they release their sources and board in say KiCAD?
<libv>
this i doubt
<focus_it>
we all suffer if we can't get hold of board AND sources together
<mnemoc>
Turl: I can't find how to enable `adb` on 4.2 (N7) :'(
<focus_it>
I had to watch a guy being sacked because we can't deliver board + linux that is cheap enough for the customer
<focus_it>
Its so sad today to be not able to access a complete board and linux + LCD working package
<libv>
well, given that i did all of my lima work so far on an android, i am already quite happy with a working proper linux
<focus_it>
all free to do as you wish
<mnemoc>
libv: :)
<mnemoc>
libv: android is nice only from a user perspective
<focus_it>
libv: do you have sources I can read?
<libv>
focus_it: google.
<libv>
focus_it: i am amazed that you do not know about it, given that you are all "free board layout" and such
<focus_it>
libv: I jumped the gun there, its android?
<focus_it>
I know linux and embedded CPU but new to Linux on embedded CPU
<focus_it>
from my perspective, the Linux situation is utter madnesss
<focus_it>
Linux on SoC? no chance in EVERY direction
<libv>
?
<focus_it>
if I got PIC chip - no problem with writing any kind of embedded app
<focus_it>
I can get data sheets and go
MindBeat has quit [Ping timeout: 245 seconds]
<focus_it>
SoC datasheets? - not a single full datasheet available anywhere
<focus_it>
covering everything from registers to settings to get say the video working and 3D working
MindBeat has joined #arm-netbook
<libv>
...
<focus_it>
I am so disppointed, I thought the best thing is to make a SO-DIMM with A10
<focus_it>
and then release the KiCAD files
<focus_it>
At least for the A10 there is remote possibility of gettting some Linux working with all the good work at sunxi
<mnemoc>
cheap soc = poor documentation, if any
<focus_it>
mnemoc: that is just cover story - without FULL documentation a chip cannot be designed and tested and released from manufacturing
<focus_it>
software cannot be written without the full documentation
<focus_it>
so all those androids out there, there is full documentation somewhere
<focus_it>
for some reason, the toads are being ordered to hide the documentation from Linux
<focus_it>
if the documentation is released, its more sales for the chip maker
<focus_it>
so any investor in the company will demand release of documentation
<focus_it>
but it don't happen
<mnemoc>
focus_it: software is all done within allwinner walls, most pcb design is also done by them
<focus_it>
probably because some investors and/or other powers be are conspiring to keep SoC datasheets from general availability
<mnemoc>
focus_it: they only need some notes in chinese and ask the guy in the next desk
<focus_it>
allwinner is a software company that merged with hardware company - but that don't excuse the rest of the SoC makers
<mnemoc>
the NDAed user manual for the A10 was leaked. and it's incomplete and in several parts invalid
<focus_it>
mnemoc: that just what I mean, the complete information is deliberately being withheld.
<mnemoc>
the parts they don't own probably
<focus_it>
if you became successful, and then licensed your own chip, would you not release the datasheet asap?
<focus_it>
its the only way you gonna get sales
<mnemoc>
not in their business model
Mazon has quit [Quit: meh]
<focus_it>
if I were rich, i'd buy IP for SoC with a view to a full datasheet
<mnemoc>
they sell ready-to-cook products, not chips
<focus_it>
but surely they make so much money they can sell chips on demand now and profit from that?
tuliom has joined #arm-netbook
<focus_it>
if I were SoC maker and make money, I'd invest in http://www.opencores.org projects and get me lots of IP that is free
<focus_it>
Then my SoC would be free and far more powerful
<focus_it>
I could put 10 CPUs in and thats just more VHDL!
<focus_it>
not pay licensing fees for the core
<focus_it>
opencores.org has already make open source CPU that runs Linux
<focus_it>
its not arm
<techn>
huihai
<mnemoc>
Turl: wtf! you have to tap the build number in the about thing 10 times to get the developer options thing
<Turl>
mnemoc: go to about phone
<Turl>
mnemoc: tap a crapton of times on the build number
<Turl>
then go to the main settings page and enable as usual
<Turl>
it'll pop up and say "you're a developer now!" or something of sorts
<Turl>
yeah, it's silly imo
<mnemoc>
23s too late :)
<mnemoc>
absolutely silly
<Turl>
my sphere camera is buggy too :<
<Turl>
did two shots, both are fail, image is all mixed up
<WarheadsSE>
quick question: adding to u-boot
<WarheadsSE>
anyone got a quick run through, of best-case steps? I've got to do something about this PLX POS before Arch dead's it out. Step one for me is the uboot being a pile of crap, and need to get to something more modern/capable.
Mazon has joined #arm-netbook
<hno>
WarheadsSE so update it?
<hno>
WarheadsSE, Is the u-boot sources you have git based or only a tarball?
<WarheadsSE>
I'm working on that. I have their POC 1.1.2 up to 1.1.4, but trying to see about a much larger jump
<hno>
ok, so you have identified the original version it's based on. Then just to a leap forward to current version and fixup whatever breaks.
<hno>
you might want to prune out crap first if they have touched irrelevant files.
<WarheadsSE>
I did a lot of that when patching w/ diff from raw 1.1.2 & 1.1.4 sources.
<hno>
Is this an SPL u-boot or plain simple u-boot loaded by some other bootloader/rom that first configures the CPU?
<WarheadsSE>
it's a stage2 only.
<hno>
plain & simple u-boot then.
<WarheadsSE>
fairly so
<WarheadsSE>
I have the sources for the stage1, but I cannot release those
<hno>
assuming stage1 is not u-boot then there is no need to touch that.
<WarheadsSE>
right
<WarheadsSE>
someone had previously supposedly made progress on this in an attept to get to 2009.11, but I have never been able to make use of their work
<WarheadsSE>
haven't quite wrapped my head around it
<WarheadsSE>
(it was 2011.09)
<WarheadsSE>
anyone know of a distinct init difference between the arm1136 & the arm11MP ?
drachenphone has joined #arm-netbook
drachenphone2 has quit [Read error: Connection reset by peer]
slash_random1 has left #arm-netbook [#arm-netbook]
<libv>
mnemoc: is mainlining the mali kernel driver actually in that wiki page?
<libv>
*sighs*
<mnemoc>
libv: :(
<libv>
that page is quite out of touch with reality
<hno>
WarheadsSE, not me.
<hno>
WarheadsSE, #u-boot might be a better place to ask, maybe..
<hno>
slapin_, aha. Seems to be something related to clocking on the cubieboard. Works if I chainload from NAND u-boot.
<hno>
pll5 is set differently there.
XenGi has joined #arm-netbook
gimli has quit [Quit: Verlassend]
<slapin_>
hno: please dump appropriate registers
vinifm has quit [Quit: Saindo]
<slapin_>
hno: /me fails to make reading work
<slapin_>
hno: nand dump reads something weird...
<mnemoc>
wrongly initialized dma or something like that?
* slapin_
gives up for today, it seems it works differently from what I thought