<libv>
hah, you need an arm proprietary header file for anything to build against the mali driver on fb.
<traeak>
d20d ?
<traeak>
hehe
<lundman>
facebook doesnt build anythign!
<libv>
ok, pbuffer egl test seems to have worked
L84Supper has quit [Quit: <puff of smoke>]
L84Supper has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 252 seconds]
ZaEarl has joined #arm-netbook
tinti has quit [Quit: Leaving]
popolon has quit [Quit: Quitte]
DEAT has quit [Read error: Connection reset by peer]
Gujs has quit [Ping timeout: 276 seconds]
DEAT has joined #arm-netbook
<bsdfox>
what's the status of sata on sunxi-3.4?
<bsdfox>
still broken because PLL6 is clocked for MALI?
Gujs has joined #arm-netbook
Gujs has quit [Ping timeout: 246 seconds]
kop has quit [Ping timeout: 260 seconds]
Gujs has joined #arm-netbook
Gujs has quit [Ping timeout: 240 seconds]
stefanro1 has joined #arm-netbook
Gujs has joined #arm-netbook
stefanro has quit [Ping timeout: 245 seconds]
ZaEarl_ has joined #arm-netbook
ZaEarl has quit [Ping timeout: 256 seconds]
kop has joined #arm-netbook
Gujs has quit [Ping timeout: 240 seconds]
freakazoid0223 has joined #arm-netbook
alcides has quit [Quit: Fighter by day, lover by night, drunkard by choice! Ready to fight!]
DEAT has quit [Read error: Connection reset by peer]
Gujs has joined #arm-netbook
benjamin__ has quit [Ping timeout: 240 seconds]
DEAT has joined #arm-netbook
<slapin_>
hno: nand stuff is so frustrating in lots of places, see for example nand_sunxi/src/physic/nand_simple_r.c:892 and its neighbours, and look at usage.
tuliom has quit [Quit: Konversation terminated!]
<slapin_>
hno: could you please help me decrypt the "why" clause in this pattern?
ZaEarl_ is now known as ZaEarl
ibot has quit [Ping timeout: 255 seconds]
mSquare has joined #arm-netbook
lansd has joined #arm-netbook
<lansd>
hello everyone
<drachensun>
hello
<lansd>
how to making Linux image and support the attachment file .
<lansd>
$cd lichee/
<lansd>
$./build.sh -p sun4i-lite -k 3.0
<lansd>
$./build.sh pack
<lansd>
when the comand: $./build.sh -p sun4i-lite -k 3.0
<lansd>
it always failed at last by the error msg:cp standby.bin standby.code
<lundman>
zpool status (for checking health, disk, io errors). zpool get all $pool (for dedup), zfs list , and zfs get all $zfs (compression and settings)
<lundman>
for arcstats, you want to be in /proc/spl/mstat/arcstat
<hno>
slapin, the Allwinner nand driver & controller an optimized single-channel controller.
<hno>
slapin, but you don't need to use any of the multi-plane or interleave optimizations to access nand. It's only optimizations, multiplying the performance of the NAND bus but still only optimizations.
<hno>
bsdfox, wemac crash. Do you have ethernet? What device are you running on?
<lundman>
hmm man, very few examples on how to use this
graffiti has joined #arm-netbook
pawel5870 has joined #arm-netbook
DEAT has quit [Read error: Connection reset by peer]
<hno>
lundman, what?
DEAT has joined #arm-netbook
<lundman>
trying to do AEAD crypto call
<hno>
sorry, not familiar with that.
cat_x301 has joined #arm-netbook
rellla2 has quit [Remote host closed the connection]
rellla has joined #arm-netbook
gx260 has left #arm-netbook ["Leaving"]
arnd_ has joined #arm-netbook
alcides has joined #arm-netbook
alcides has quit [Changing host]
alcides has joined #arm-netbook
<graffiti>
rellla: please can you share your xbmc .deb
<graffiti>
i asked you in XBMC forums u doubted that moderators may block it
<rellla>
but you always have to create one yourself before. sunxi-bsp only bundles kernel etc..
<mnemoc>
I personally use ubuntu alip as initial roofs
<mnemoc>
i see no point in making "images" if you only need a 10M + 120M download to get a working system on any card size with your favourite distro on it
<rellla>
+1
<mnemoc>
in the worse case, provide an improved rootfs
<mnemoc>
but not a dd-able image
<rellla>
is there a need to provide a vanilla debian-armhf-rootfs? i don't need it, because i build it myself. imho dd-able images are too confusing and not transparent enough.
<mnemoc>
debootstrapping can be annoyingly slow
<rellla>
i haven't meant to include debootstrapping in sunxi-bsp scripts, but providing a already done debian-armhf-rootfs.tar.xz? - as a alternative to the ubuntu images.
<mnemoc>
yes, that is what I understood
<mnemoc>
debian-armhf-rootfs.tar.xz would be great because "debootstrapping can be annoyingly slow"
<rm>
dd is just less work
<rm>
when you consider that you need: 1) partitioning 2) mkfs 3) uboot-spl 4) uboot 5) mount stuff 6) untar
wingrime has joined #arm-netbook
<rm>
oh, and uImage, script.bin
<wingrime>
mnemoc: you asked about sysconfig support in gpio driver from source drop
<wingrime>
I think it not requied
<mnemoc>
wingrime: i knew that. I asked for testing and comments :)
<wingrime>
you can use any gpio without premission from fex
<mnemoc>
rm: works is done by scripts
sspiff has joined #arm-netbook
<mnemoc>
wingrime: so you already tested it? how are the pins presented? works fine?
<wingrime>
mnemoc: think you can remove this ugly driver from source and use from source drop
<wingrime>
mnemoc: Not, I don't tested but Last time I tryed add some pins to gpio_para I have brick
<wingrime>
It about old driver
<wingrime>
New driver uses gpio_class interface
<mnemoc>
their own class, not the standard stuff
<wingrime>
It even better than old driver and anyway better
graffiti has quit [Ping timeout: 245 seconds]
<wingrime>
mnemoc: Anyone tryed make some profiling to make system run qucker ?
jquip has quit [Read error: Connection reset by peer]
<rellla>
rm: therefore you have sunxi-media-create.sh. you need to 1) download hwpack 2) download rootfs 3) execute sunxi-media-create.sh
Gujs has quit [Ping timeout: 255 seconds]
<rellla>
1) and 2) could be included in 3)
<mnemoc>
a wrapper maybe
<mnemoc>
but only you know what hwpack you want
<mnemoc>
and what rootfs you want
<mnemoc>
so having the 3 steps separated is (imho) the only right way
Gujs has joined #arm-netbook
rz2k has joined #arm-netbook
jquip has joined #arm-netbook
<rm>
I don't trust those automagic scripts
<rm>
which claim to "do everything" for you
<mnemoc>
it doesn't "do everything"
<rm>
because they fail way too often, in ways that are non-obvious
<mnemoc>
it partitions, dumps u-boot, copy some files, and extracts a tarball
<mnemoc>
as long as it stays that simple it should be reliable
<mnemoc>
but still needs lots of cleanup
<mnemoc>
we can eventually simplify them even more if we get .deb/.rpm files for the libs (and apt/yum repos)
<mnemoc>
also for the kernel
arnd_ has joined #arm-netbook
<oliv3r>
.ebuild!
<oliv3r>
:p
<mnemoc>
:)
cheng has quit [Quit: Leaving]
<oliv3r>
i've been slackin' and probably will slack today and tomorrow even due to other things i have to sort!
<oliv3r>
sorry :(
<mnemoc>
slacker
<rm>
sunxi-media-create.sh still makes a 16MB /boot???...........
<mnemoc>
yes
<mnemoc>
and still vfat ;-)
<rm>
can barely fit 3 kernel version there
<rm>
as I said those scripts are b/s
<rm>
versions*
<rm>
64 MB is a sane minimum
<rellla>
rm,mnemoc: i'd prefer an additional wrapper with 3 params: "wrapper.sh /dev/sdb debian-sid-armhf mele". so you can use the wrapper or do the things yourself, even from scratch.
mSquare has joined #arm-netbook
<rm>
not to mention a 16MB FAT32 can't even exist by standard
ZaEarl has quit [Read error: Connection reset by peer]
<mnemoc>
rm: true, that needs fixing
ZaEarl has joined #arm-netbook
<rellla>
or you do a ./configure before with all these parameters, disp_mode ...
<mnemoc>
there are some funky script.bin editors out there
<rellla>
for example?
<mnemoc>
i don't remember, but I saw one once
mSquare1 has joined #arm-netbook
<rellla>
fex2bin / bin2fex - wrapper?
<mnemoc>
people does weird things to avoid to use an editor or the command line
<mnemoc>
i think it was even a cgi
mSquare has quit [Read error: Connection reset by peer]
<mnemoc>
yes, I assume they wrap those
<mnemoc>
rm: does the default u-boot env work fine with an ext4 /boot ? (beside changing the default size to 64MB)
<rm>
no idea
<rm>
I am okay with a FAT /boot
<rm>
just has to be at the very least 32 MB, 64 is better
focus_well has quit [Quit: Leaving]
focus_well has joined #arm-netbook
focus_well has quit [Client Quit]
focus_well has joined #arm-netbook
<focus_well>
I'm trying to make an A10 board with LCD and Lubuntu
<focus_well>
I got MK802 working with Lubuntu and HDMI
<focus_well>
The LCD is 4.3 inch
<focus_well>
Any pointers to where I can go configure Lubuntu to switch to using LCD?
<focus_well>
I have Gemei G2 tablet to practice doing this first
<focus_well>
rm: I think I understand what mean about G2 - I assume when script.bin is modified in the software MK802 image reconfigures to switch from HDMI to LCD?
<rm>
or just find a script.bin already used/tested by someone on an A10 tablet
mSquare has quit [Ping timeout: 240 seconds]
<focus_well>
rm: thank you - the two links you share already furthered my knowledge - knows a bit of linux - but new to this type of task
<focus_well>
rm: for connecting the 4.3" LCD, I was going to convert the G2 to Lubuntu and then go back through the source code to find where the LCD had been configured
<focus_well>
rm: Then I plan to make SO-DIMM module with A10 and connect to LCD
<rm>
._. okay
<mnemoc>
you might want to play with a cubieboard first, the lcd pins are exposed there
<focus_well>
rm: I make motherboard and SO-DIMM 200 pin module in KiCAD (damn good open source software package!) with the SO-DIMM board having 2 lesser ARM chips
<focus_well>
rm: then I find the lesser ARMs too slow to update LCD - about 10 frames a second :-(
<mnemoc>
focus_well: not interested in joining lkcl in his eoma68-a10?
<focus_well>
rm: so I now switch to A10 CPU
<focus_well>
rm: I have one developer working in CN.
<rm>
don't highlight me every damn line, thanks :)
<focus_well>
mnemoc: subcribed to mailing list - thanks
<mnemoc>
focus_well: but it's still a good idea to get a cubieboard to use a devkit ;-)
<rz2k>
anyone tried to compile VLC?
<focus_well>
mnemoc: I see your post about cubie board and they have offers - good ones gone - but yeah $59 and up still available. I order it later - thank you!!
<focus_well>
do you know if the sata works for cubieboard?
<rz2k>
yes
<mnemoc>
focus_well: but only one drive
<focus_well>
rz2k: Sata already work?! Then they have a distro that works as well? Which distro(s)?
<rz2k>
linaro
<focus_well>
one drive ok
<rz2k>
some guy at mail list created one click installer from raspberry pi's berryboot
<mnemoc>
any linux distro
<mnemoc>
there is nothing special kernel/linux wise about the cubieboard
<focus_well>
Do you think it will be easy to configure cubie to run on LCD - the one I have is 4.3 inch 40 pin parallel RGB
<mnemoc>
it's just another sun4i board
<focus_well>
So as tablets run sun4i, I should be able to configure X to run on the 4.3 inch once I figure out which registers to intialise
<mnemoc>
lcds are a problem, but all the details go in the script.bin file
<mnemoc>
and eventually in a DTS
<focus_well>
DTS?
ZaEarl has quit [Ping timeout: 256 seconds]
<mnemoc>
a more standard format
<focus_well>
OK I learn up about DTS
<mnemoc>
the eoma68 card is expected to read a DTS describing the base/io board via i2c
<mnemoc>
and then been able to use the attached LCD
<focus_well>
So the data in script.bin is converted to DTS file. Is the DTS file a text file that can be edited?
<rz2k>
focus_well: I believe rgb is present on pins of cubieboard, you will need to make your self a breakout board to connect LCD
<focus_well>
breakout boards no problem - got EEs to turn them out for breakfast! :-)
<rz2k>
lcd's are usually connected by flat flex pcb with tiny pitch between pins
<mnemoc>
focus_well: script.bin includes data that goes to the bootloader, data that goes into a DTS for the card, and data that should go to a DTS for the base board
<rz2k>
yes multiplexing is defined by script.bin values
slapin has quit [Ping timeout: 276 seconds]
<rz2k>
check fex guide for full list, it is on wiki too.
<focus_well>
rz2k: thank you for those PDFs! The video one looks very interesting - its in CN but I don't believe in whining! - I go get it translated using google translate - but that doc looks just right!
<mnemoc>
we have some stuff translated on the wiki
<mnemoc>
google translate works great, if you do sentence by sentence
<focus_well>
Thanks - I go read it all step by step starting with converting the Gemei G2 to run Lubuntu, and then go help eoma with KiCAD board, and then go make another version of that with SO-DIMM and then make my 4.3" LCD work
<focus_well>
wonderful!!
<focus_well>
thanks guys!!
<focus_well>
Then I open source it all
<focus_well>
And post back here in a few weeks
<focus_well>
:-)
<mnemoc>
please don't discard the eoma68 path
<focus_well>
I help eoma as much as I can
<focus_well>
:-)
<mnemoc>
:)
lkcl has quit [Ping timeout: 276 seconds]
<slapin_>
hno: ping
<slapin_>
hno: about weird NAND code parts
<mnemoc>
rm: sunxi-media-create changed to make 64MB /boot partitions now
merbanan has quit [Ping timeout: 248 seconds]
lkcl has joined #arm-netbook
<rz2k>
crap, VLC compilation in wills wang sources is completely broken
<rz2k>
seems like he didnt push everything needed
cat_x301 has quit [Ping timeout: 255 seconds]
<mnemoc>
:(
sspiff has quit [Ping timeout: 245 seconds]
merbanan has joined #arm-netbook
slash_random has joined #arm-netbook
<rz2k>
even better, default supplied with vlc configure doesnt know about arm-none-linux-gnueabi and arm-linux-gnueabihf machines. and autoreconf doesnt work because something is missing in /modules.
<rz2k>
also vlc actually can do output thru EGL, I didnt know that, it is disabled in Linaro's vlc for some reason.
<rz2k>
maybe we could do ultimate mali-400 egl + cedarx decoding combo
<mnemoc>
libv was going to add headers and makefile to mali-libs
<mnemoc>
to be able to make civilized packages
<mnemoc>
instead of random files dropped into the hwpack
<slapin_>
hno: nand_sunxi/src/physic/nand_simple_r.c:127 _cal_real_chip(nBank) function frustrates me most
<rz2k>
thats awesome
<rz2k>
we should really throw this by-folder crap out and give user more intelligent way to get the libs.
<slapin_>
mnemoc: do you have some nand_sunxi-fu to share?
<mnemoc>
rm: the goal is to have packages obviusly
<mnemoc>
err
<mnemoc>
rz2k: the goal is to have packages obviusly
<mnemoc>
slapin_: not really
<mnemoc>
slapin_: but there are some nanda fixes in the latest source drop
<mnemoc>
nand*
<slapin_>
mnemoc: when hno is usually here so for me to whine?
<mnemoc>
jquip: can you add that to the wiki page of the mele in linux-sunxi.org?
<jquip>
yeah sure
<bfree>
I finally managed to get a sunxi-3.0 sun4i kernel deb to build (and even cross-compile) though I have no hardware to test it on ;-) It's very rough packaging, just ripping off and cutting back the debian sid linux packaging (and updating the debian patches and packaging the first little bit needed). if any brave soul wants to test it or just poke at it ...
<bfree>
http://celtux.org/cubie (please don't publicise the link, apart from the fact it's just a rough first cut, it's just a toy tinykvm server used "just for fun" with limited bandwidth, I'm hoping that initial space kept it out of the logs)
<mnemoc>
can you make some scripts so I can replace it?
<RaYmAn>
bfree: this channel is publicly logged =P
<mnemoc>
i can test your .deb later tonight, but obvisly the goal is to keep an apt server for both debian and ubuntu
<hno>
slapin_, I am here.
<bfree>
RaYmAn: yep ... and already seen one of the bots hit it :-p I may yank it sooner then I'd thought ;-)
<mnemoc>
bfree: give me your ssh public key
<bfree>
mnemoc: for quick gross hacking you just need to replace the orig.tar.xz (instructions to build one from the git is there)
<slapin_>
hno: hi, I'd like you to look at _cal_real_chip(nBank)
<libv>
i doubt that anyone has succeeded running the framebuffer mali libs
<hno>
libv, r2p0 (i think) framebuffer libs is said to work.
<jquip>
quickie -> does the sunxi-tools package work on the arm itself/ or is it arch neutral?
<libv>
hno: for pbuffer, yes
<libv>
hno: but for actual fb access?
<libv>
hno: getting a native window is not trivial
<hno>
isn't there integration in the A10 directfb libs?
<slapin_>
libv: is mali framebuffer stuff open? if I don't need 3D graphics?
<hno>
never looked at getting mali work
<hno>
slapin_, mali is only 3d, no framebuffer. leaches on the disp framebuffer
<slapin_>
ah, so I can make a10's fb work without mali?
<hno>
which is mostly open and partially documented
<hno>
slapin_, yes
<libv>
that does not seem to depend on gl/egl
<jquip>
oh sorry, nevermind..
<rz2k>
there is directfb with g2d integrated somewhere
<rz2k>
based on vmware drivers
<slapin_>
hno: as I understand, the nand_sunxi driver hardcodes NAND soldering layouts and allows choice at compile time, hence _cal_real_chip/_cal_real_rb exists?
<libv>
which is quite different from mali-libs integrated
<libv>
g2d is in absolutely no way related to the mali
<slapin_>
hno: that's terrible defines here and there :(
<hno>
the storage info is embedded in boot0/boot0.
<hno>
boot0/1
* slapin_
will never trust #define again
<slapin_>
hno: and in case of absence of these info? how it is supposed to read these w/o knowledge of layouts?
<libv>
ah, ok, worked this time round.
<hno>
slapin_, all nand access outside the initial access of the boot blocks have this info available.
<hno>
and boot blocks is in first chip first blocks, so not so much to handle there.
<hno>
not sure how livesuit gets these values in the initial flash of the device on a blank NAND.
<slapin_>
hno: I see, a lot of fun is going on!
cat_x301 has joined #arm-netbook
<hno>
for making an MTD driver the important parts is the command interface I think. In a defined wiring. Lets worry about wiring flexibility once basic NAND access works.
<slapin_>
hno: ok, I will finish with init sequence soon, so it might happen
<hno>
It's not really that complex. It's a single channel bus with 8 CE and 2 RB lines.
<slapin_>
hno: and weird data paths
<hno>
slapin_, not on the board. But the driver have many odd parts.
<hno>
controller looks much simpler.
<hno>
The driver have many layers of cotton hiding the hardware behind abstract definitions.
<slapin_>
hno: I see. I just don't quite understand this DMA-related and SRAM-related things
<slapin_>
hno: and how to not use DMA and/or SRAM to start clean and add things on proper ground
<hno>
From what I understand the controller operates on SRAM, and the DMA channel gates between SRAM and DRAM.
<hno>
The controller does the NAND handshake, and 1K at a time I/O operations with ECC.
<hno>
each controller operation involves up to 4 NAND commands and one data transfer.
<hno>
and bulk DMA operation for >1K transfers it seems.
<slapin_>
hno: so there is no way to read data byte-by-byte? I mean command answers, for example, chip ID.
<hno>
slapin_, sure. You can both access the SRAM directly, and access the FIFO data register.
<hno>
not sure when which method is appropriate.
<slapin_>
hno: handshake is not a problem because I can monitor ALE/CLE state machine and operate accordingly.
<slapin_>
hno: which FIFO register?
<hno>
IO_DATA:
<hno>
which is also the register accessed by DMA.
<slapin_>
I'd prefer u-boot code as minimalistic as possible, even trading performance for simplicity.
<hno>
yes.
<slapin_>
hno: and how can I know at which state is FIFO or can I reset it to sane state? only by resetting all controller?
<hno>
It's part of the NAND controllre and reset when the controller is reset. There is also registers to read the FIFO status iirc.
wingrime has quit [Read error: Connection reset by peer]
<hno>
Err... there is not much FIFO status. Only a signle bit in ST
Quarx|2 has joined #arm-netbook
<slapin_>
hno: which means it is not empty. But there is separate command FIFO it seems... which is accessible only by register. so IO_DATA is data-only fifo. How complex this might be?
Quarx has quit [Read error: Connection reset by peer]
<slapin_>
hno: can 2 commands one of which send data and the other receive data, execute at the same time?
<hno>
No idea.
<hno>
probably not.
<slapin_>
hno: I don't see where it prohibits interleaved operations and blocks the bus. Probably this code is intended for u-boot hence it has protections relaxed...
<lkcl>
slapin_: no. i'm not interested in the A13. EOMA68 requires SATA and Ethernet. the A13 is low-cost (and shit - 16-bit DDR RAM interface). if you add in the cost of a USB Hub ($1.50), USB-to-SATA Converter IC ($3 from TI) and a USB-to-Ethernet IC (maybe another $2) it comes to *more* than the cost of most other ARM Cortex A8s which are better anyway because they have 32-bit DDR3 RAM interfaces
<lkcl>
that was the whole point of the exercise - a deliberate conscious choice was made by Allwinner here so as *not* to ruin their own market for their own processor (the A10)
<lkcl>
!!
<lkcl>
focus_well: one small correction of perception i need to point out to you (i'm reading the conversation back through the irc history) - eoma is *NOT* repeat *NOT* repeat *NOT* solely and exclusively about this one processor known as "A10".
<lkcl>
many people make this mistake :)
<lkcl>
the A10 CPU Card is just the first: there will be many more. i'm working on a TI AM3892 EOMA68 CPU Card for example.
<slapin_>
lkcl: I think for completeness of allwinner library, A13's symbol is nice to have
<mnemoc>
and A10s :)
<slapin_>
mnemoc: donno if it is even exists
<mnemoc>
it does
<mnemoc>
it's TFBGA336
<mnemoc>
it's very similar to the A10, but doesn't have SATA
<mnemoc>
an it's much smaller in size
<mnemoc>
the A13 is larger than the A10
<slapin_>
mnemoc: A13's selling point is that it is TQFP which lowers rnd and production costs
<mnemoc>
yup
<slapin_>
mnemoc: at least here
<hno>
slapin_, olimex have scematics and layout for A13. Not in kicad, but openly abailable.
QingPei has joined #arm-netbook
<slapin_>
hno: I just try to sell my opinion to lkcl that A13 is cool to have in allwinner.lib
<hno>
slapin_, so draw one then
<hno>
but finish the nand controller stuff first
<slapin_>
hno: I have bought Eagle, learn Kicad but I lack time to do things now, it is good I have my 1/2 hour a day to play with nand
<lkcl>
slapin_: its un-selling points are that it only has a 16-bit DDR RAM interface. that alone absolutely cripples it when compared to other 1ghz processors. i *did* provide Allwinner with a multiplexing diagram (plan) which would to do only 308 pins and still allow them to do 32-bit DDR3 RAM, but they really really didn't want the A13 to compete with the A10... so crippled it.
<slapin_>
hno: I think Eagle patterns and symbols can be converted to KiCad with some tool, iif Olimex allows such distribution
<lkcl>
i'll add the kicad part for completeness if you submit a patch, but i won't do the work for you.
<lkcl>
hmm, must update the web site to mention the kicad part
<slapin_>
lkcl: I'm not commercially interested in A13, only as toy. I need some platform for next GPS tracker, so I'm interested in newer low-end solutions. Time to say to 200-400MHz arm926 goodbye
<lkcl>
:)
<hno>
slapin_, the olimex scematics are Creative Commons Attribution-Share Alike 3.0 United States License.
<lkcl>
slapin_: STM32Fs not fast enough?
<slapin_>
lkcl: I want some heavy platform with gigs of everything. A small platform will be STM32F.
<lkcl>
ahh ok.
<hno>
slapin_, the A10 have builtin GPS support, only needing a radio. Might be interested in reversing that?
<lkcl>
eyy, i found some schematics with the help of a guy called adrian, for doing camera (directly!), audio (mic and speakers) - all from the STM32F yaay!
* lkcl
pleased
<lkcl>
cos i was "talking up" using the STM32F and was concerned it would be too complex for me actually do!
<hno>
which camera resolutions can it handle?
<lkcl>
hno: it'll juuust about manage 640x480 @ 30fps.
<hno>
and still picture?
<lkcl>
actually it might be more - the STM32F apparently has DMA so it wouldn't need to do bit-banging
<lkcl>
turns out that if you try to ramp things down too far it *degrades* the picture quality
<lkcl>
you set the external clock to 6mhz with a PCM output from the STM32F, and leave it running
<lkcl>
then just read the data off some of the pins via DMA.
<lkcl>
someone's already done this btw! done it, built the circuits, bought the t-shirt....
<lkcl>
schematics available for Eagle, and everything.
<lkcl>
yee-haw :)
<lkcl>
it's for a robot which follows you by using a camera to tell it's looking at a particular colour, or face, or something.
hipboi has quit [Ping timeout: 252 seconds]
<lkcl>
i saw one demo'd at pycon UK 2010 but i didn't realise at the time that it was using an STM32F
cheng has joined #arm-netbook
<slapin_>
hno: any radios on market?
<slapin_>
hno: or any tablets with this wired?
<slapin_>
hno: or sticks?
<hno>
slapin_, absolutely but have no clue where. Did find some GPS chipset datasheets and the interface between the radio chip and the processing chip is the same as the pins available on A10.
bsdfox has joined #arm-netbook
bsdfox has quit [Changing host]
bsdfox has joined #arm-netbook
<slapin_>
hno: this might be some serial port and everything done in software
<hno>
it's not quite serial.
<hno>
but at least digital.
<slapin_>
by the way, have anybody tried xenomai on A10 or similar?
<slapin_>
hno: GPS math is quite cumbersome to implement...
<bsdfox>
hno, sorry for the delay.. went to sleep. the wemac crash is on mele A2000 with ethernet
<hno>
slapin_, I know.
<mnemoc>
we got a gps.ko for a10/3.0.8 if someone wants to RE that controller
<slapin_>
so many boards and none can be at hands - some won't ship to Russia, some are still pending, some are not drawn yet :(
<mnemoc>
16:13:42 < mnemoc> push Tsvetan to get his A10 olinuxino out soon
<mnemoc>
who doesn't ship to .ru?
<slapin_>
TI
<mnemoc>
did they get the memo about the end of the cold war?
<mnemoc>
I can understand cuba or north korea.... but russia?
<slapin_>
mnemoc: dunno, probably military lobby hides it from them
<mnemoc>
:(
<mnemoc>
how stupid
<slapin_>
well, lots of things can't be shipped to russia, some due to stupid customs regulations, some due to stupid export restrictions.
arete74 has quit [Quit: leaving]
<slapin_>
TI is usually worked around via China and some adventureous US companies, but all that costs money, and these are short on research phase.
arete74 has joined #arm-netbook
<slapin_>
digikey helps sometimes (by ignorance/latency)
<rz2k>
digikey is $129 ups shipping
<slapin_>
I really still don't understnd why I just can't buy any board I like.
<rz2k>
use farnell uk
<slapin_>
rz2k: farnell adheres to US exports regardless, had lots of problems with OMAP3530 with them.
<mnemoc>
do they have reasonable shipping prices?
<rz2k>
interesting
<rz2k>
mnemoc: 20 euro
<mnemoc>
clearly hobbiest are not welcomed :|
<mnemoc>
but less absurd than digikey
<slapin_>
and both UPS and DHL won't ship to private person here, only to organizations.
<rz2k>
ups is easy to believe to anything, I've filled my university address and got the package, lol.
<slapin_>
I had fun talking digikey to use USPS, it worked 2 of 4 times...
<rz2k>
s/my university address/my university as organization and my home address/
<ibot>
rz2k meant: ups is easy to believe to anything, I've filled my university as organization and my home address and got the package, lol.
<slapin_>
as I filled my company address for UPS I had to return parcel because customs considrerd it commercial package because of that, the same for DHL.
<hno>
slapin_, the point is that once the interfacing is somewhat understood then there is plenty of existing work to base the processing on.
lkcl has joined #arm-netbook
vinifm has joined #arm-netbook
arnd_ has quit [Ping timeout: 244 seconds]
avernos has joined #arm-netbook
avernos has quit [Changing host]
avernos has joined #arm-netbook
QingPei has left #arm-netbook [#arm-netbook]
slapin has joined #arm-netbook
<slapin_>
hno: hope so
* slapin_
is back to nand woes
<slapin_>
hno: haven't you seen where in init sequence NandStorageInfo is read? The code is messy since SCN_AnalyzeNandSystem() stuff...
<focus_well>
lkcl: I see your message through history. I understand about more than 1 CPU - that also my aim!
<focus_well>
lkcl: I have engineer and factory that can make PCBs - enough to bang out a couple of SO-DIMM 200 pin modules. Interested?
<focus_well>
lkcl: I can get the PCB laid out now that I got your KiCAD libs to produce circuit diagram and work on it until finished.
<focus_well>
lkcl: Then I release it all open source. I need the module for somethin else - so no point in holding on to the files after I finish.
<focus_well>
lkcl: My aim is to slot the SO-DIMM to a motherboard that has 4.3" LCD and get Lubuntu working on it.
<focus_well>
lkcl: The SO-DIMM will have the CPU, RAM, Flash, uSD card, and the power management chip. Power may reach the board through thicker wire extra connector to free up more pins on SO-DIMM connector.
<focus_well>
lkcl: Another module I want to make is DDR3 connector based with 240 pins. Them good for vertical stacking to get arrays of them boards going :-)
<focus_well>
lkcl: The plan is to build the 200 pin SO-DIMM, then test, find its failings, then refine and make DDR3, the refine that and make SO-DIMM and ping pong
<focus_well>
lkcl: it a couple of times to make sure the the thing can work without crashing problems.
cat_x301 has joined #arm-netbook
<hno>
slapin, it's scanned for in the early setup in the nand driver. See src/scan/nand_scan.c
Quarx|2 has quit []
jquip has left #arm-netbook [#arm-netbook]
<lkcl>
focus_well: great! helloooo
<lkcl>
focus_well: i'm not going to say "no" because it's a great idea :)
<lkcl>
focus_well: i've found a number of app notes on DDR3, it's fuuun achh the timings are soo precise
<lkcl>
i can upload them somewhere if you like
<hno>
slapin, oh, on a closer reading I see that the nand driver scans for the chips and not prerecorded information stored by livesuit. That simplifies things a bit.
<lkcl>
focus_well: btw would you be willing to help review some op-amp and MOSFET H-Bridge circuits, help me calculate the RC and LC filter circuits and so on? i know *of* these things having done them 25 years ago at school.
<lkcl>
i've made a decision to use PWM volume control for the mic and speakers, and Class D (PWM) for the audio output.
<lkcl>
there's a couple of fantastic circuits i found which were done by people who have used 8-bit micros with limited pincount for *exactly* these purposes, and they report reasonable results, so i'm happy
<techn>
mnemoc: tuc salt crackers are breaking that patent :p
<mnemoc>
:D
<hno>
It's a design patent, not a patent.
<mnemoc>
which happen to be automatically valid in EU iirc
<techn>
mnemoc: we should get bsp for mk802 and mk802 II
slapin has joined #arm-netbook
<libv>
aren't we rapidly converging to a state where we only need script.bin for each device?
<mnemoc>
sure, do you have a .fex with _verified_ dram_param ?
<mnemoc>
libv: problem is the script.bin usually doesn't come with all the dram info
<mnemoc>
and if it comes with it, it can be BS
<libv>
yeah, i know, i was handheld by you and and hno for the a7hd :)
gsilvis has quit [Ping timeout: 260 seconds]
<libv>
i was just wondering where this whole notion of bsp came from if it is generic sunxi stuff with a correct script.bin
gsilvis has joined #arm-netbook
<techn>
mnemoc: yep.. I'm just wondering that why no one has delivered those.. since those devices are most common
<mnemoc>
libv: initially yes
<mnemoc>
libv: until we realized we can't trust script.bin for dram_para :<
<mnemoc>
libv: so now our hope is in slapin
<techn>
libv: also kernel differs on a13 and a10
freakazoid0223 has quit [Read error: Connection reset by peer]
<libv>
who here is not running a debian based distribution or android on their allwinner?
<hno>
techn, probably because most people with MK802 devices do not have UART.
<libv>
i am wondering what gcc -dumpmachine returns on your machine, if your are using hardfloat
<techn>
libv: WarheadsSE was using ALARM
* hno
is not running sndroid or debian.
* techn
still waiting serial adapter from Tom :/
<libv>
oh, and i take it that arm-linux-gnueabi is returned on armel machines, right?
<WarheadsSE>
huh whut
<WarheadsSE>
We recently moved to armv5tel-linux-gnueabi to match the latesst toolchains.
<WarheadsSE>
let me the v7 is slightly different.
<slapin>
not that much to make different name on armel :/
<WarheadsSE>
debian rupports armel being armv4t
<WarheadsSE>
otherwise, its armv7h blah
<libv>
the blah bit is quite important, so i can try to do some automated checking in the makefile
<WarheadsSE>
K, give me a sec
<hno>
WarheadsSE, ah, that explains the linaro toolchain softfload multilib breakage.
<hno>
s/fload/float/
<WarheadsSE>
:)
<ibot>
hno meant: WarheadsSE, ah, that explains the linaro toolchain softfloat multilib breakage.
<libv>
on the other hand, i can do what i can test myself, and let people provide patches for the rest
<WarheadsSE>
once this system is done upgrading, I'll get you the exact string we use from the chain
<slapin>
weird, strange, why armhf then?
<WarheadsSE>
armel != armhf
* slapin
is happy user of debian armel in dreamplug
<WarheadsSE>
Yeah, works fine, not optimized to the device, but works fine
<hno>
linaro tollchain fails to link programs compiled with -mfloat-abi=soft unless -march=armv4t and absolutely nothing else, and only because they insist on it being there.
<WarheadsSE>
I was under the impression they were stopping softfloat support on v7+ chains
<hno>
the support is there both in linaro and ubuntu gnuabihf toolchains, but only if you explicitly state -march=armv4t and have the right multilib libs installed.
<hno>
the linaro toolchain comes with the libs by default. ubuntu package has libs separate.
<slapin>
poor fpu-less a8 targets...
<WarheadsSE>
/usr/bin/armv5tel-unknown-linux-gnueabi-gcc on our v5 chain
<hno>
slapin, is there any fpu-less a8 targets?
<WarheadsSE>
there are fpu-less A8s?
<hno>
I don't think so.
<slapin>
dunno, I know of one v7a without neon and vfp
<hno>
Both VFP and NEON is mandatory in A8 A profile.
<slapin>
tegra?
<hno>
For v7a neon is optionsl, but vfp is mandatory iirc.
<hno>
tegra have vfp.
<WarheadsSE>
uhm, i think you are thinking ARMv8 not A8
<WarheadsSE>
yes, afaik, v7a requires vfpv3-d16
<WarheadsSE>
you can add neon (not directly fp) and expand to vfpv3-d32
<WarheadsSE>
even on the v7-M's
<slapin>
I know of one chinese processor of armv7-a arch without vfp as it chokes on fpu instructions and there's no kernel emulation
<slapin>
neon on v7-m is fantastic
<WarheadsSE>
i wonder then, if it is mislabled.
<slapin>
never seen socs with v7-m and neon
<WarheadsSE>
Hmm, I misspoke slightly. apparently only M4 has optional fpu.
<WarheadsSE>
ARMv7E-M has DSP, they could attach a neon if they chose
<slapin>
supports wfi and other v7 stuff but no vfp or neon
<WarheadsSE>
wfi
<WarheadsSE>
?
<WarheadsSE>
I do have one of these coming, whenever it ships: EK-LM4F120XL
freakazoid0223 has joined #arm-netbook
<slapin>
wait for interrupt insn, not coprocessor bit
<focus_it>
lkcl: I look over your op-amp, MOSFET H-bridge and general electronics. Leave me link for the pdfs of the circuits in question.
<focus_it>
lkcl: The DDR3 CPU module is same as SO-DIMM module - it just has 40 more pins from the A10 brought out for doing more things.
<focus_it>
lkcl: The initial LCD is 4.3" but after the recipe is discovered to make Lubuntu + X work properly with it, we try a couple more examples and open source the lot for everyone else to make their own LCDs work with as little pain as possible.
<specing>
ubuntu...
<specing>
/facepalm
<WarheadsSE>
heh
techn_ has joined #arm-netbook
<mnemoc>
"You have existing Linux kernel code to support your SoC? There are 99% chances that you should throw it away
<mnemoc>
Turl: I know, I was 2h fighting that crap last night
<Turl>
and with O= your shell `pwd' is /tmp/whatever (O= value)
<Turl>
$(PWD) on the other hand is the kernel source tree location
<Turl>
so when it looks for files it doesn't find them because they're not relative to O= but to -C
<Turl>
mnemoc: what was the motivation for your patch btw?
<mnemoc>
that -C with O= wasn't working
<mnemoc>
err
<mnemoc>
that -C without O= wasn't working
<focus_it>
lkcl: I'm looking...
<Turl>
without O= $(PWD) is == $(pwd)
<Turl>
interesting
<Turl>
$(shell pwd)*
<lkcl>
focus_it: star. the originals you can find as png/jpgs in there, i pretty much cut/paste them :) oh i had to put numbers on amp_schematic.png to match the ROHM-US6M1TR-MOSFET-DUAL-NP.pdf
<lkcl>
i was getting reeaaallly confused....
<lkcl>
all right, apologies: i have to sleep. too many late nights.
Sternennebel has joined #arm-netbook
slash_random has joined #arm-netbook
<lkcl>
focus_it: email me (or the list). thanks again.
benjamin__ has joined #arm-netbook
<focus_it>
lkcl: good night - I'll send it via the list
<Turl>
mnemoc: mind testing a patch and commiting if it works?