<\\Mr_C\\>
what about the stuff thats already there?
<\\Mr_C\\>
pre-installed
<\\Mr_C\\>
i dont over right it with a current one?
<\\Mr_C\\>
+w
<Turl>
\\Mr_C\\: I didn't understand your question
<\\Mr_C\\>
that link says First, we need to get the boot partition we downloaded earlier on onto the NAND. You can either copy it over using SCP, then use dd to write it to /dev/nand (dd bs=4096 if=./cubie_nand_uboot_partition_image.bin of=/dev/nand),
<\\Mr_C\\>
i did that
<\\Mr_C\\>
and there is some stuff on nanda
<\\Mr_C\\>
i tried to put the newer version of the same files
<\\Mr_C\\>
but not enough space
<\\Mr_C\\>
so what i was going to do is just wipe the nand and create my own partitions
<Turl>
I haven't looked at the files, but from what the guide says you shouldn't touch nanda at all after flashing the thing
<\\Mr_C\\>
oh
<Turl>
your kernel goes on /boot/uImage inside of nandb which should be an ext4 partition
<\\Mr_C\\>
the nanda has a uImage
<\\Mr_C\\>
thats all i was wondering about
<Turl>
I dunno then, ask /w 12
<Turl>
err, mixing commands when typing doesn't work :p
<Turl>
... ask lawrence, which did the image from what it says there
<lxsameer>
oliv3r: not much, using arch was i my biggest mistake, Debian is awesome
booss has joined #linux-sunxi
<oliv3r>
ah
<oliv3r>
lxsameer: doesn't debian have a pre-compiled arm compiler in its repo?
<oliv3r>
http://wiki.debian.org/BuildingCrossCompilers specifically says: MOST PEOPLE SHOULDN'T BE BUILDING THEIR OWN CROSS-TOOLCHAIN - THEY SHOULD JUST INSTALL A PRE-BUILT ONE LIKE ANY OTHER PACKAGE.
<oliv3r>
but that page lists how to install your cross compiler
<lxsameer>
oliv3r: yeah it does and its awesome
<lxsameer>
oliv3r: but i have debian on my laptop not my pc
rz2k has joined #linux-sunxi
<hramrach_>
lxsameer: what do you have on your pc?
<lxsameer>
hramrach_: arch,
<hramrach_>
anyway, it's probably easier to install debootstrap and then install the corsscompiler in a Debian/Ubuntu chroot
<hramrach_>
plus Arch might have packages for that
<hramrach_>
building the croscompiler yourself is quite pointless unless you package it for your distro
<lxsameer>
hramrach_: yeah you're right
<lxsameer>
hramrach_: but i want to compile it write now
<hramrach_>
compile right now=instal debootstrap
<hramrach_>
should give rou compiler in a few min
<hramrach_>
much faster than building, nad probably less disk space too
<mripard_>
you have the "arm" port of debian, that uses the prefix "arm-linux-gnu", which is OABI
<oliv3r>
i thought that the HF gcc these days, could do softfloat if you tell it too, but the softfloat gcc can't do hf :)
<oliv3r>
extended ABI and orignal ABI?
<mripard_>
the "armel" port, using EABI soft-float, with the prefix "arm-linux-gnueabi"
<mripard_>
and armhf, arm-linux-gnueabihf
<mripard_>
oliv3r: Old ABI and Embedded ABI
<mripard_>
and OABI is... old :)
<hramrach_>
ugh, too many variants
<hramrach_>
forgot some already
<hramrach_>
anyway, for kernel builds anything that contains gnueabi in the target name should work unless the packager is insane
mab has joined #linux-sunxi
jemk has quit [Ping timeout: 264 seconds]
wigyori has joined #linux-sunxi
<wigyori>
hi
jemk has joined #linux-sunxi
mab has quit [Remote host closed the connection]
jemk has quit [Quit: bye]
<oliv3r>
mripard_: so is platform_get_resources() the prefed way over of_iomap, of_address_to_resource?
<mnemoc>
the world really needs an LDD4 :(
<n01>
lol
<oliv3r>
well I do
<oliv3r>
:p
<oliv3r>
with some good examples :)
<oliv3r>
i did read ldd3 atleast parts
<oliv3r>
but there's "so many top frameworks" that sometimes you just don't know which one you should use :p
tinti has joined #linux-sunxi
<n01>
the problem is that ldd3 is really getting old
<mnemoc>
almost to the point of been useless as reference
<mnemoc>
LDD4!!
<n01>
a bit better is Linux Kernel Development IMO
<n01>
but is someone already writing an ldd4?
<mnemoc>
but love's book aims at a broader knowledge, and as so more superficial
<n01>
yes I know :(
<jinzo>
Damn, I see A20 tablets for as low as 62USD from china ofcourse
<jinzo>
that's quite something.
<oliv3r>
ldd3 didn't well in explaining the underlying architecture, kobjects etc; but lacked the higher frameworks, though maybe i overlooked parts, i'll reread it again sometime
<oliv3r>
jinzo: yeah, its awseome, just need one reputable vendor with a good (better then the really cheap ones) displays. IPS pereferd
<jinzo>
indeed. but I didn't really believe they're targeting A10 price range...
<jinzo>
if only would they lower the price of A10, it could actually become a somehow viable alternative to mcu-s in some projects.
* slapin_nb
hopes that A10 will be cheaper now...
<mripard_>
oliv3r: they're all tied together actually
<mripard_>
of_iomap calls of_address_to_resources
* slapin_nb
needs SATA for next project
<mripard_>
the point is that calling of_address_to_resources parse the device tree
<mripard_>
while it has already been parsed once to fill the resources array that platform_get_resources uses
<mripard_>
so if you want to get a reference to a resource, while avoiding do several lookup in the dt, you have platform_get_resources
<mnemoc>
slapin_nb: saw the olinuxino-a20 ?
<mripard_>
(the same more or less applies to platform_get_irq vs irq_of_parse_and_map)
<mripard_>
mnemoc: btw, I received my A10s-olinuxino today, you should expect yours soon I guess
<mnemoc>
mripard_: I'm not getting one because I don't have a fixed address atm
<mripard_>
oh :(
<mripard_>
you're moving ?
<mnemoc>
not clear yet
<mnemoc>
hope to have a better idea next week
<mripard_>
ok
<mnemoc>
but i have an a10s reserved and waiting for a shipping address
<mripard_>
I hope you will find something
PiyushVerma has quit [Quit: Konversation terminated!]
<oliv3r>
jinzo: well aw's plan was to have the a20 replace the a10
<oliv3r>
i wonder if we get a20s etc
<oliv3r>
jinzo: i bet they took a10 out of production to replace with a20
<jinzo>
that's what I fear too.
<oliv3r>
mripard_: so platfrom_get_resource should be used if you don't want to parse the dt more then once, of_address_to_resources, if you only plan on parsing it once?
<mripard_>
the dt will always be parsed once, even when you don't have any code in your driver :)
<mripard_>
so, platform_get_resources will result in one dt lookup
<mripard_>
at the very early boot of the kernel
<mripard_>
while with of_address_to_resources, you actually have that first parsing, plus the one you explictly ask for
<n01>
weird thing is that _a lot_ of drivers still use of_iomap()
<oliv3r>
so you re-parse the tree. hmm a silly
<oliv3r>
ok so best practise is to use platform_get_resource and be happy?
<oliv3r>
btw, i liked the slides you linked, though i've only read through the stuff I allready knew for now, the kernel setup etc, day 1 basicallyl
<mripard_>
n01: the problem with of_iomap is different actually
<mripard_>
platform_get_resources vs of_address_to_resources essentially boils down to an optimisation problem
<mripard_>
it has no functionnal impact at all.
<oliv3r>
mripard_: btw, if you do one more version of your patch; check the have and has in your comments, you've mixed them up a few times :)
<mripard_>
while the problem with of_iomap is that actually, it only gets the resource to map from the dt and maps it through ioremap
<mripard_>
while every driver should call request_mem_region before calling ioremap to make sure that there is no one already using that memory space
<oliv3r>
i've rewritten the sid driver to use platform_get_resource; just have to test it when i get home later tonight
<mripard_>
oliv3r: did I ? ok, thanks
<oliv3r>
mripard_: btw, I really liked your round_down solution, if Only I knew of it before
<oliv3r>
and moreso ioread32be, fixes the endianess immediatly! only issue is, for some rason, i get ioread32 from linux/io.h i belive, but for ioread32be i need to include asm/io.h
<oliv3r>
But that's the proper include, right?
<mripard_>
oliv3r: do you have an example for the has/have?
<slapin_nb>
mnemoc: not seen it yet
<oliv3r>
mripard_: sure
<mripard_>
oliv3r: hmmm, odd, but yeah, it seems like you have to include asm/io.h
<slapin_nb>
mnemoc: and no a20 version on their site
<slapin_nb>
mnemoc: how can I buy it?
<oliv3r>
Address + Write bit have been transmitted, ACK has not been received.
<mnemoc>
slapin_nb: check their blog
<oliv3r>
bit has, or bits have
<oliv3r>
n01: btw, i think the dt that's in some of maxime's tree's allready, uses 0x10 as memory space, but I think it should only be 0x08, only 2 registers, iirc the next register up is used by the next timer
<mripard_>
oliv3r: in my mind, it was Address byte and write bit have been transmitted
<mripard_>
if it makes more sense
<oliv3r>
so the byte AND the bit, ok, that I follow
<oliv3r>
wouldn't address bits and write bit make more sense?
<oliv3r>
(i'm not a native english speaker, so could very well be wrong)
<oliv3r>
but yeah, 1 byte and 1 bit together would be plural I suppose
<mripard_>
that was my assumption as well :)
<oliv3r>
i don't know what the grammar rules say about that :p then again, is + really grammer
<oliv3r>
any native english speakers here? lkcl: ping!
jemk has joined #linux-sunxi
<oliv3r>
mripard_: btw, why didn't you use linkely()? not that optmizization on these spots is really interesting
<mripard_>
do we care to save a few cycles for a function that will be executed once ?
<mripard_>
or for a bus that run at 100kHz
<oliv3r>
no :p that's why I said, it's not really interesting
<oliv3r>
but every cycle saved, saves a tree!
<oliv3r>
i am a dirty tree hugger :(
<n01>
oliv3r: I'll check that
<n01>
BTW I have started working also on RTC
<oliv3r>
i saw :( was gonna do that in parallel with PWM
<oliv3r>
but i'll leave you the RTC, :p
<oliv3r>
since it's the same register of sorts :)
<oliv3r>
you gonna start with a plain RTC, and add alarms etc later?
<n01>
oliv3r: yep, even though my spare time is _very_ limited ç_ç
<oliv3r>
:p
<oliv3r>
linux-sunxi - mainlining Allwinner, one driver at a time (tm)
<mnemoc>
to move 3.4 drivers a little closer to mainline we can do generic script.bin parsing to create the platform devices and resources
<oliv3r>
i really wanna start testing 3.4 drivers under android on my tablet; but without uart, i'm very limited
<oliv3r>
what clocks are brought out to pins on the cubie
<oliv3r>
i can check them, if i can connect to them
<Turl>
mmc I think
<oliv3r>
checking the pin header now
<oliv3r>
we have LCD pins, LCD0-VSYNC which is interesting imo, LCD0-CLK otherwise
<oliv3r>
SPI0-CLK
<oliv3r>
LC0-HSYNC, LCD0-SCK
<oliv3r>
csi-PCLK; TWI1-SCK; LCD1-VSYNC and LCD1-HSYNC, AVCC, CSI1-MCLK SD3-CLK!! CSI0-Data, no clocks strangly
<oliv3r>
so there's a few clocks brought out; yeah i'll scope what I can from that selection that matches your pll work
<oliv3r>
what git remote shall I add?
<Turl>
I haven't pushed it yet, sec :p
<oliv3r>
no rush
<oliv3r>
won't be home fora few hours
<Turl>
ok then, I'll play with my toys a bit more, let me know when you're back :p
<oliv3r>
tonight around 19:00 Amsterdam time at the earliest :p
<oliv3r>
so 3-4 hours from now
<oliv3r>
I'm bummed that tom didn't bring out PS/2[0-1]
<oliv3r>
was going to try hooking up PS/2 keyboard + mouse
<oliv3r>
Turl: the list is a little confusing; ir[0-1] shows up twice?
<oliv3r>
oh that's cause it can connect to either 24 MHz directly, or to pll1->ahb
<oliv3r>
mmc0 clock should be probeable
<Turl>
oliv3r: one is ir0 and the other ahb_ir0 (the data bus clock)
<oliv3r>
Turl: i probably should look at the datasheet first :p but i'll ask first
<oliv3r>
ohhh yes of course
<oliv3r>
it needs 2 clocks
<oliv3r>
oh ahb, apb; i've spotted the difference :p nvm that
<oliv3r>
Turl: btw, docbook pdf thing has been installed
<lkcl>
oliv3r: ack
<oliv3r>
lkcl: hi!
<lkcl>
allo. wassup?
<Turl>
oliv3r: great
<oliv3r>
mripard_: and I where talking about have vs has; I found the line "Address + Write bit have been transmitted, ACK has not been received."
<oliv3r>
Turl: checking how to generate pdf's now
<oliv3r>
lkcl: the + threw me off actually
<lkcl>
it's "address and write bit have both been transmitted, ACK has not been received"
<oliv3r>
I read it as write bit have been transmitted, which felt wrong. but appearantly it's addres + write bit (thus several bits) have been transmitted; which of course is right
<oliv3r>
both, oh that helps a lot
<oliv3r>
but it's address bits and the write bit, have all been tranmitted?
<lkcl>
waaaa? text has gone invisible!
<oliv3r>
it's several address bits (a byte rather)
<hno>
oliv3r, yes it appears it's doing the same. not what I expected.
<oliv3r>
mmc rescan and mmc info did show Sunxi MMC btw
<rellla>
dragonn: did you try them with vlc? maybe i should enable it and test it with libhybris.
jemk has quit [Quit: bye]
Undertasker has quit [Quit: Leaving.]
<wingrime>
nove: can valgrind also to function call trace
<wingrime>
nove: not only mmio
hglm has joined #linux-sunxi
<wingrime>
nove: simple memtrace
<wingrime>
function trace
<nove>
wingrime, i will see want can be done
<dragonn>
rellla, I have only tested the MPEG4V1 it sems like it works on VLC
<rellla>
dragonn: so i'm a new build...
paulk__ has joined #linux-sunxi
<wingrime>
cedar can scale and rotate
jemk has joined #linux-sunxi
eebrah|away is now known as eebrah
<dragonn>
BTW Some one are willing for kernel 3.4.47? I have succesfull update the sunxi-3.4 from .43 to .47
<mnemoc>
anything for us in those stable updates?
<mnemoc>
or just for the sake of using the last?
<dragonn>
mnemoc, just for using the last :P, I hooped this will allow us to build the kernel with gcc-linaro 4.8.1, but it doesn't help ;p, still works only with 4.7.2
<mnemoc>
:)
<jemk>
anyone tried to play with the security subsystem?
<dragonn>
But maybe gcc-linaro is broken - on my tablets it crashes after try boot Android
n01 is now known as n01|away
dragonn has quit [Quit: Wychodzi]
<hno>
wingrime, can it? I thought the scaler was used for that
<hno>
jemk, yes, but I don't remember who. Most likely linger around here however so just keep asking.
<hno>
jemk, there is some documentation in the A13 User Guide.
dragonn has joined #linux-sunxi
<hno>
dragonn, which gcc version?
<dragonn>
hno, 4.8.1
<wingrime>
uho: I think mpeg4 engine can scale and rotate
<hno>
dragonn, our kernel is not compatible with linaro gcc 4.8.
<dragonn>
hno, I know, I tried to made it compatible
<hno>
how?
<dragonn>
hno, update the sources to latest 3.4.X version (3.4.47)
<hno>
that won't help. It crashes in one of our drivers.
<hno>
you need to look into why it crashes and how to fix it.
<dragonn>
hno, do you know in with driver? Because the log didn't tell me anything usefull
<hno>
I do not remember.
<dragonn>
hno, ok, it is not so big problem, sems like more kernel have this problem, on my tablet with 4.8.2 it crashes too, not direct after boot but when Android tried to use the GPU... Now I need to remap the ir-keymap.h again.... I lost the old version with codes for my remote :/
user_2 has joined #linux-sunxi
<user_2>
does cubieboad have a unique number hard-coded into soc? if yes, how to read it?
<hramrach_>
yes but you hve to type that in by hand :/
<oliv3r>
i guess the SID can be backported to 3.4; but first want to get it submitted
<hramrach_>
including the address ..
<user_2>
CB is so good hardwre, but software is not so good, at the moment.
<hramrach_>
well, it's good hardware for the price
<oliv3r>
software will imrpove
<oliv3r>
it just needs time
<hramrach_>
as for software all arm support is junk so far
<user_2>
yes, i know many people are doing strong effort on arm/linux.
<hramrach_>
the only somwhat supported hardware is Intel (as in really made by intel, not clones nor junk intel licensed elsewhere) :s
<user_2>
i wish to do my onw istallation based on debian and linux 3.4, so im collenting info here :-)
<user_2>
mnemoc, i do 'memdev2 0x01c23800 w' and i get: 0x16236745. somenoe cna do the same and report the his result, please?
<hno>
oliv3r, unless I am doing my math wrong that PLL1 setting is 480MHz.
<mnemoc>
user_2: that's the first word of the SID. it has 4
<hramrach_>
where do you get memdev2?
<user_2>
oh...
<user_2>
hramrach_, apt-get install devmem2
<hramrach_>
they had to swap the name parts ..
<oliv3r>
hno: and it should be 1008 MHz if i'm not mistaken?
<oliv3r>
user_2: check A10/SID
<hramrach_>
no, I don't have that
<oliv3r>
you need to read 128 bits
<hno>
Yes.. but maybe FEL is reconfiguring PLL1. I don't know.
<user_2>
wait
<oliv3r>
user_2: matter of fact, if you could be so kind and add your 4 bits in the same style to the SID table; that'd be great, or post yours here and I'll add it
<user_2>
oliv3r, wait a moment
<oliv3r>
hno: well that we can check, i mean, boot from SPL+U-boot from SD, check PLL1, boot from nand to U-boot; check PLL1
<hno>
U-Boot SPL do set it to 1008MHz.
<user_2>
oliv3r, here it is:
<user_2>
devmem2 0x01c23800 w = 0x16236745
<user_2>
devmem2 0x01c23808 w = 0x50554848
<user_2>
devmem2 0x01c23812 w = 0x0
<user_2>
devmem2 0x01c23804 w = 0x80778052
<hno>
oliv3r, and it's also 1008MHz in NAND u-boot.
<user_2>
sorry, last is wrong, i redo
<user_2>
devmem2 0x01c23800 w = 0x16236745
<user_2>
devmem2 0x01c23804 w = 0x80778052
<user_2>
devmem2 0x01c23808 w = 0x50554848
<user_2>
devmem2 0x01c2380c w = 0x7C171AD
<user_2>
ok
<oliv3r>
user_2: ok i'll post it to the SID page; thank you
<oliv3r>
hno: so looks like FEL changes the clocks?
<user_2>
oliv3r, wait a momet
<oliv3r>
it'll be anonymous :p
<user_2>
why u want to publish that nombers i give you?
<oliv3r>
we use those codes to determine if we can detect the SoC type from it
<oliv3r>
like 0x1623
<oliv3r>
appears to be an A10 cpu
<oliv3r>
0x01625 is A13
<hno>
oliv3r, yes it seems so. And something is also mucking with the AXI/AHB/APB divisors both in FEL and NAND u-boot.
<user_2>
it is a A10, it is on CB, so for sure is A10 (i can control sata disc, A13 hs not sata interface afaik)
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
<oliv3r>
user_2: 0x01c2380c seems to be short 1 charachter
<oliv3r>
hno: i'll look at ffff0000.s from your repo to see if pll1 is modified at all
<user_2>
oliv3r, yes it is. it appear strange to me also, but that is what i got from devmem2
<oliv3r>
must be a 0 before the 07 then
<mnemoc>
iirc from fel you get one byte per word
<user_2>
here the command and the result:
<user_2>
root@cubieboard:~# devmem2 0x01c2380c w
<user_2>
/dev/mem opened.
<user_2>
Value at address 0x1C2380C (0x401af80c): 0x7C171AD
<user_2>
Memory mapped at address 0x401af000.
<oliv3r>
user_2: you have a 1G ram version?
<oliv3r>
user_2: yeah, all have a zero prefixing that :)
<oliv3r>
user_2: check the wiki and compare it to the other boards (that's why we have it, to learn from it)
<user_2>
yes, 1G (but running 'htop' command i can see only 814MB)
<oliv3r>
yeah, that's g2d, VE, GPU memory reservation
<hno>
user_2, that's normal. The framebuffer, cedarx, mali and some other stuff eats a bit of your ram.
<oliv3r>
if you don't use any of those, you can set those to 0
<user_2>
i use CP in "desktop" activities, so i suppose hat ram is occupied for some activities,... in any case, (i.e. as headless server) how can i free memory?
<oliv3r>
if you only use 'desktop', not mali and not cedar, you can put those to 0 and get a little more memory
<oliv3r>
mnemoc: hushy :p I bet it's somewhere on the wiki :)
<mnemoc>
*g*
<oliv3r>
i just haven't searched and that's fster for my lazyness :)
<hno>
oliv3r, FEL rom quite clearly sets the divisors on line 46. (008c)
<oliv3r>
i was trying to dot hat for hno; but hno is faster
<user_2>
oliver, but mali is not dedicated to graphic? isnt it used to run desptop and so on?
<oliv3r>
user_2: mali is 3D engine, so if you don't do opengl, you don't need it
<hramrach_>
and your desktop has slow effects then
<hramrach_>
some effects at least
<hramrach_>
lxde seems ok without 3D (and canot use it) gnome crawls faster with 3d
<user_2>
well, sometime linaro seems to "freeze" adn i get delay in desktop acrivities? is it possible to make it more resmonding, more fluid?
<oliv3r>
IF your desktop uses opengl; but do we have any rootfs that uses that?
<hramrach_>
yes, set up GLES driver and the sunxi video driver
<oliv3r>
linaro is xfce i belive, which doesn't do opengl
<user_2>
im running a linaro image i get from cubieboard.org, i dont know else .-)
<hramrach_>
you don't get OpenGL anyway, only GLES
<hramrach_>
but activities sounds like that Gnome thing that does use 3D wehn it can
<hramrach_>
and is dreadfully slow because it repaints whole screen to pop up
<user_2>
so, how can i have a "good-speed-desktop"?
<hramrach_>
use a desktop environment tha does not repaint whole screen
<hramrach_>
with CB memory bandwidth it's never going to be snappy doing that
wingrime has quit [Ping timeout: 246 seconds]
<user_2>
hramrach_, do you have a desktop enviroinmet to suggest me? i have no idea
<hramrach_>
try lxde
<user_2>
hramrach_, ok., iwill do
<oliv3r>
user_2: HansG's fedora 18 image works quite nicely
* dwilkins
nods
<user_2>
oliv3r, do you have the link from where i can downolad it?
<oliv3r>
only problem with it, the default CPU govenor is ondemand, which is nice, but can be slugish, if you don't have battery requirements, using the 'performance' govenor works much better
<oliv3r>
user_2: that README i pasted you is from it
<user_2>
ok.
<oliv3r>
remove README from the link
<oliv3r>
and there are the files :)
<user_2>
no batery, i tun with normal power from 220V
<user_2>
oliv3r, that fedora is with lxde?
<oliv3r>
user_2: or xfce, try it on a spare SD card :)
<oliv3r>
mnemoc: have you looked at the SID table recently, starting to become somewhat usefull
<user_2>
ok i will do
<hno>
oliv3r, and again in the function at ffff0c60
<hno>
there it also sets the divisor to 113.
<oliv3r>
hno: is it interesting if i map out fel mode tomorrow at bored-time @work?
<hno>
If you want to do something interesting then try to document the OTG controller registers a bit more.
<oliv3r>
well, we found out that the USB controller is some other IP that has a kernel driver
<hno>
The OTG one?
<oliv3r>
so when a little more is known
<oliv3r>
oh, no t sure
<hno>
The HOST one (1 & 2) is a standard controller mostly.
<oliv3r>
any chances that the OTG one is IP aswell?
<hno>
The OTG controller likely originates from somewhere else also. There is significant similarities with some other, but also differences.
<mnemoc>
hno: sunxi-current doesn't support the good old myboard_config ?
<hno>
What good old myboard_config?
<mnemoc>
the ${BOARD}_config rule
<mnemoc>
for configure-only
<hno>
sure it does. use that quite often.
<mnemoc>
uhm...
<hno>
but some board names are different.
<mnemoc>
cubieboard ?
<oliv3r>
hno: oh you found most registers allready then :)
<hno>
yes, but not much documented on them.
<hno>
the register offsets are easy, we do have source.
<hno>
mnemoc, [henrik@localhost u-boot]$ make CROSS_COMPILE=/home/henrik/toolchains/arm-linux-gnueabihf/bin/arm-linux-gnueabihf- O=build/t cubieboard_config
<hno>
Configuring for Cubieboard - Board: sun4i, Options: CUBIEBOARD,SPL
Undertasker has joined #linux-sunxi
<hno>
and there is also cubieboard_fel
<mnemoc>
hno: wiping the O dir solved it :)
<mnemoc>
do I need the _fel variant for felboot ?
<hno>
yes
<hno>
but only the SPL
<hno>
make ... $O/spl/u-boot-spl.bin
<hramrach_>
how come a10s has max 2GB ram?
<hramrach_>
does it also have dual-channel RAM controller?
<hno>
In theory even the A10 supports 2GB ram if given the right DRAM chips.
<hramrach_>
but a13 does not
<hno>
no.
<mnemoc>
A10S with 2GB???
<mnemoc>
where?
<hramrach_>
so the controller is autodetected somehow or selected with fex_
<hramrach_>
mnemoc: the wiki ů=0
<hramrach_>
argh, garbage
<oliv3r>
well the sun4i/sun5i memory maps reserve 2 GiB addressing for RAM, so why not
<hramrach_>
nobody made it work so far. 2GB is not in reference board design and the memory controller is undocumented :/
<hramrach_>
even rk3066 has sticks with 2G ram but AW refuses to release enough info for that to happen with AW SoC
<hno>
hramrach_, the memory controller is mostly the same as in A10 & A13. But for 2GB you need a dual-rank configuration and have not yet heard of anyone doing a working dual rank configuration for Allwinner.
<hno>
It's quite obvious how to enable dual-rank configuration in the fex, but it is unclear if the timing registers need other values or not.
<hramrach_>
the A13 is way more limited if it relly cannot do more than .5G
<hno>
and also routing requirements in dual-rank configurations are unknown, but should not be too hard if you are used to doing dual-rank DDR3 routing then maybe possible. What I do know is that it is quite more complex than single-rank.
<hno>
unless using dual CS DRAM chips.
mdfe_ has joined #linux-sunxi
<hramrach_>
yes, technically should be possible but nobody made it and AW does not even document how it is *supposed* to work on their side
<hramrach_>
the wiki lists 2G max ram for A10s and 0.5G for a13, odd
<oliv3r>
typo
<hramrach_>
which one?
<hno>
Those values are from Allwinner data sheets.
<oliv3r>
then again, the A13 lacks pins to do more memory I suppose
<user_2>
oliv3r, to double the memory addressable, it is necessary only one pin, afaik
<hno>
A13: 16-bit data, 15 address bits, 3 bank select = 1Gbyte in theory. Data sheet says up to 512MB.
<hramrach_>
well, A13 is listed as 16bit memory, a10/a10s as 32bit
<hramrach_>
so really too few pins
<hramrach_>
thanks
<hno>
math still do not quite add up between pins and data sheets.
<hno>
wait, right. A13 only supports single rank. so 512MB max.
<hramrach_>
yes, it looks all right. half data and half chip select gives quarter memory
<hno>
yes.
<oliv3r>
why only single bank though? shortage of pins?
shineworld has quit [Remote host closed the connection]
<mnemoc>
the a13 is craplet oriented, 512MB is "enough"
<hramrach_>
a13 has really few pins, yes. Plus nobody uses that pin, anyway
<mnemoc>
same reason for dropping lvds
<oliv3r>
my A10 has 512 MB and it makes me cringe and cry
<oliv3r>
it really is not enough
jemk has quit [Quit: bye]
<mnemoc>
oliv3r: price-range
<hramrach_>
depends on the use
<hramrach_>
good enough for FB brosing I guess
<oliv3r>
hardly
<oliv3r>
bearly
<oliv3r>
it's really lacking ram
<hramrach_>
barely enough is the card played by craplet manufacturers
<oliv3r>
heh; well it was a gift, so can't compalin
<hno>
oliv3r, that tables is from before A13?
<oliv3r>
yeah
tinti has quit [Remote host closed the connection]
tinti has joined #linux-sunxi
<hno>
oliv3r, read the backlog and techn_ says Arnd have identified the USB controller as Mentor Graphics Inventra USB Controller (musb) which is also what I remember comparing to earlier.
<techn_>
hno: oliv3r: I pasted that from wiki :)
rellla has quit [Remote host closed the connection]
<hno>
I do not think a DT will be sufficient. Register order is quite different from the normal musb.
tinti has quit [Remote host closed the connection]
dwilkins has quit [Ping timeout: 264 seconds]
dwilkins has joined #linux-sunxi
<techn_>
mnemoc: How do I apply that patch to allwinner-tools?
<mnemoc>
techn_: saw my reply?
<techn_>
mnemoc: that sounds too strict :/
<mnemoc>
you can't inject a ^M unless you are working on a windows machine
<mnemoc>
injecting the ^M now will fail on the next commit
<mnemoc>
also encoding is a problem. many of those have GBK comments
<techn_>
:)
<mnemoc>
it must be fixed via .gitattributes
<mnemoc>
but my doubt is, do we need eol=crlf or not
<mnemoc>
that will force crlf on linux. without it windows people will get crlf, linux people lf
<mnemoc>
once told they are text files, git will do the right thing
<oliv3r>
hno: yeah, that's what I heard, so maybe the usb-otg part is also from same company?
<techn_>
mnemoc: how about livesuit/*.ini
<mnemoc>
the musb thing smells a lot like sunxi-emac vs. davicom
<mnemoc>
techn_: livesuit/.gitattributes ;-)
<techn_>
you can do directory specific attributes? :p
<mnemoc>
i think so...
<mnemoc>
just like .gitignore
<techn_>
hmm.. I suppose so since root .gitattributes is in directory :p
<mnemoc>
*g*
<mnemoc>
`man gitattributes`'s example at the bottom confirms livesuit/.gitattributes support
<mnemoc>
but my question still open, do we *need* eol=crlf or text is enough
<mnemoc>
matson!!
<mnemoc>
and, do we reencode as utf-8 or leave as GBK
<oliv3r>
utf-8 ++
paulk__ has quit [Read error: Connection reset by peer]
_whitelogger has joined #linux-sunxi
<mnemoc>
a magic `* text=auto` only altered files in livesuit/
<mnemoc>
.fex, .cfg and .ini
<techn_>
commit? :)
<mnemoc>
ok
<mnemoc>
pushed
notmart has quit [Quit: notmart terminated!]
<mnemoc>
techn_: what about the reencoding?
<techn_>
mnemoc: you can change it with gitattributes?
<mnemoc>
no :(
<mnemoc>
iconv
<mnemoc>
reencoding pushed
<mnemoc>
hope to not need to revert in future if it makes livesuit die
<mnemoc>
oh, it DOES support encoding
<mnemoc>
but only for GUIs
ZaEarl_ has joined #linux-sunxi
ZaEarl has quit [Ping timeout: 264 seconds]
<mnemoc>
techn_: problem solved?
<hno>
oliv3r, that is the OTG part.
<techn_>
mnemoc: Atleast I was now able to reproduce it.. and fix it :)
<mnemoc>
techn_: but livesuit happy with the ini now?
<hno>
mnemoc, no, there really is very strong similarities between musb and the allwinner otg controller. But it is not an all trivial match.
nove has quit [Ping timeout: 246 seconds]
<techn_>
mnemoc: I'll test it tomorrow
<oliv3r>
hno: ah, so we are lucky then
<hno>
oliv3r, I honestly do no know if it's lucky. There is similarities, but we have no clue on which musb version it is based on, and a quite large shoehorn is needed to make the musb driver fit, maybe bigger than the shoehorn used for blackfin.
<oliv3r>
well we do have a 'working' driver allready
<oliv3r>
so we know 'some' things, it surely can help
<techn_>
mnemoc: File /home/techn/sunxi-bsp/build/cubieboard_livesuit/dlinfo.fex Not ExistBuildImg 360
<techn_>
after utf-8 conversion :/
<mnemoc>
meh
<techn_>
but you didn't touch that file :p
<mnemoc>
it's bin...
<techn_>
I'll investigate that tomorrow
_BJfreeman has joined #linux-sunxi
<mnemoc>
reverting the utf-8 commit solves it?
<mnemoc>
<3 proprietary crapware
BJfreeman has quit [Read error: Connection reset by peer]
rz2k has quit []
<techn_>
mnemoc: "add gitattributes to make text files's eol consistent" seems the problem
Undertasker has left #linux-sunxi [#linux-sunxi]
n01 has quit [Read error: Operation timed out]
<mnemoc>
techn_: add *.ini text eol-crlf then rm -rf livesuit; git checkout livesuit