luoyi has quit [Quit: ChatZilla 0.9.90 [Firefox 21.0/20130514193536]]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
christopher has joined #linux-sunxi
<CaCtus491>
Hi all, I'm just starting with an A10 dev board and am trying to get my head around things. It looks like I can use LiveSuit to program NAND flash connected to the A10. Am I correct in saying that by using some tool (sunxi-tools?), I can take a kernel, a root fs and generate an image that can be programmed to NAND flash using LiveSuit?
<CaCtus491>
Is it possible to take a copy of the existing NAND flash using LiveSuit so I can always go back to what is currently there if I break things?
christopher is now known as anunnaki
christopher has joined #linux-sunxi
anunnaki has quit [Read error: Connection reset by peer]
christopher is now known as anunnaki
mturquette has joined #linux-sunxi
hipboi has joined #linux-sunxi
user_2 has joined #linux-sunxi
user_2 has quit [Ping timeout: 260 seconds]
[7] has quit [Read error: Operation timed out]
TheSeven has joined #linux-sunxi
rz2k has joined #linux-sunxi
dwilkins has quit [Ping timeout: 256 seconds]
hozer1 has quit [Ping timeout: 252 seconds]
<hno>
Turl, It's using PLL5 (DRAM) clock.
<hno>
CaCtus491, to make Livesuit images you need the pack tool from the Allwinner SDK.
<CaCtus491>
hno: Thanks. How would I go about taking an image of what is currently in NAND?
andoma has quit [Ping timeout: 252 seconds]
hozer has joined #linux-sunxi
<hno>
there is no easy way to make a complete image.
<CaCtus491>
ahh, hno = Henrik :) I'm playing around with a board from BDD (http://www.bddgroupllc.com/). They are going to send me through an image later that I can use, but in the meantime, I'm learning about how everything fits together. Using the uboot that is in the NAND already, I can't get into uboot, however if I boot from another SD image, I can access uboot from that and grab the output from md.b.
<CaCtus491>
having said that, in the existing image that is on there, once booted, I can get to /boot which contains script.bin and a script.fex. Would that contain the required information?
<oliv3r>
CaCtus491: i think most of us boot/use mmc; since we don't have nand support properly in u-boot yet, and with the new fel-boot it's unlikly anybody will invest much time in livesuit
<CaCtus491>
oliv3r: fel-boot is an opensource replacement for livesuit, allowing us to write images to NAND?
<oliv3r>
CaCtus491: fel-boot allows you to boot an A10 device directly over USB
<oliv3r>
you can boot a full linux image; and thus after booting you can do anything you can with your regular linux
paulk-desktop has joined #linux-sunxi
<CaCtus491>
oliv3r: ahh, so we get the A10 into FEL mode (no magic string at sdcard0, NAND, sdcard2), and fel-boot running on another machine manages to serve up an image for the A10 to boot from?
<oliv3r>
yep
<CaCtus491>
Is fel-boot already functional?
<oliv3r>
mind you, this is very early all; but yes, fel-boot appears to be fully functional
<oliv3r>
check the sunxi-tools github directory
<hno>
CaCtus491, script.bin/fex is quite important. And completing it with the needed DRAM info (also needed for usb booting)
<hno>
An it does not quite work that way. Via FEL we can upload u-boot, kernel & initramfs.
<hno>
to execute from RAM.
<oliv3r>
hno: fel-boot can also be used to test certain SPL things with, right? e.g. if I want to play/hack around the SPL, i can use fel-boot to piggy back on
<hno>
not really.
<hno>
normal boot and FEL boot differs noticeably.
<hno>
but it's easy to play with u-boot and later.
<hno>
FEL testing is best done using JTAG.
<hno>
err SPL testing is best done using JTAG.
<oliv3r>
really want to start playing with using SRAM B with SPL and more importantly, dynamically loading dram settings from somewhere else
<hno>
Sure, FEL is quite suitable for that.
<oliv3r>
just to run some test cases is all
<oliv3r>
see how far we can get
<hno>
See sunxi-tools/felboot/
<oliv3r>
aye
<CaCtus491>
this A10 module I have is booting Linux with uboot from NAND... Is that because it is using an old version of uboot?
<CaCtus491>
U-Boot 2011.09-rc1-dirty
<hno>
it's actually a very minimal version of the SPL.
<oliv3r>
still sucks my phy is broken :(
<oliv3r>
CaCtus491: taht's using the Allwinner hacks to u-boot; :)
<oliv3r>
hno: does u-boot have any dtb parsing ability? or can it only pass it as a blob; and that's it
<hno>
CaCtus491, we do not yet have an SPL for NAND booting.
<hno>
oliv3r, it can manipulate the dtb
<oliv3r>
well then it should be able to read it, right?
<oliv3r>
the relation SPL <-> u-boot, code wise, are they completly seperated, or is it that if you need certain functions in SPL, they get pulled in?
<oliv3r>
(never really looked at u-boot)
<CaCtus491>
so, if the current uboot doesn't support booting Linux from NAND, is there a better way to do it than using the allwinner mods to an older uboot?
eebrah|away is now known as eebrah
<oliv3r>
hmm, maybe not so easily, since SPL doesn't know about the kernel/dtb yet, the dtb would need to be stored somewhere where the SPL can find it
<hno>
CaCtus491, the older allwinner u-boot (lichee/lichee-dev branch) is quite suitable for NAND booting.
<hno>
oliv3r, there is not room for full DTB support in SPL.
<oliv3r>
well we only need 'read value' support
<hno>
We only have 24KB in total. And no BSS segment until DRAM is configured.
<oliv3r>
we can use SRAM B however
<oliv3r>
which gives us an additional 64 kiB
<oliv3r>
and USB memory is available aswel, but that's only 4k
<CaCtus491>
ok, in that case then, I'd be best to use the existing uboot already in the nand, and look at just changing the kernel / rootfs in nand.
<oliv3r>
CaCtus491: if that's all you want, that's quite easy, and doesn't require livesuit
<hno>
Is SRAM B accessible?
<oliv3r>
assuming you are using android, you can use mkbootimg to make a new kernel for the kerenl partition, and rootfs is also just a dd-able partition
<oliv3r>
hno: yep
<oliv3r>
hno: well I used 'mtest' in the u-boot shell
<oliv3r>
i wanted to write a simple test read/write test for SPL and output that
<oliv3r>
the compiled dtb for the cubieboard is 6.2 k; small, but too big for the 4 k of USB memory :(
<oliv3r>
would be cool if it fitted there ;)
<oliv3r>
I haven't managed to access the VE sram; though if that is really used to exchange macroblocks or something with the VE, it should be writeable at some point
<hno>
Wonder how much memory (BSS + allocated) the MMC driver needs.
<oliv3r>
i know some aussi guy was looking into things like that a while ago
<oliv3r>
but fat/ext loading (even if it's a compile time OR) and mmc, would be quite awesome
<oliv3r>
load dtb from fat/ext, parse memory timings, bam
<oliv3r>
no more 'per memory u-boot'
<hno>
BROM will only load us a single max 24KB image.
<oliv3r>
how much does our SPL use at the moment?
<oliv3r>
20k give or take?
<hno>
My plan is to move the DRAM parameter to an SPL header that can easily be rewitten. So you use the spl.bin image, script.bin/dts and it spits out a configured boot image.
<oliv3r>
that's probably simpler as a start
<hno>
text data bss dec hexfilename
<hno>
20506 444 1396 22346 574au-boot-spl
<oliv3r>
what command do you use to dump that info?
<hno>
size
<oliv3r>
arm-size 'file format not recognized' :(
<hno>
which file dir you run it on?
<CaCtus491>
I'm trying to start with something simple here - download a precompiled image, write to SD and get that working on this board first. To do that, would I need to copy the script.bin currently in NAND over the top of the sciprt.bin on the first partition on the SD card?
<oliv3r>
on the u-boot-spl.bin :p
<hno>
you need tu use the elf.
<oliv3r>
fdt_ro.o is 47k, ouch
<hno>
exactly. And FAT is also quite large, but I think it mostly needed huge amounts of BSS.
<oliv3r>
i think ext[2-4] read only was quite small
<oliv3r>
i can't belive fat (read only) needs to be that big
<hno>
in code yes, but allocates quite a bit of memory.
<oliv3r>
well, we'd have ... 64k!
<hno>
which is well.. nothing.
<oliv3r>
it's 3x 24k almost :(
<oliv3r>
BROM can only read 24k because it reads it all into L1 cache, right?
<hno>
ext4 needs a number of 4KB blocks, and several structures.
<oliv3r>
so the memory it has available, is SRAM A?
<hno>
BROM is simple. It loads a single image starting at 0.
<hno>
I am not entirely sure where it stores it's runtime data while loading.
<oliv3r>
i think I read that lkcl said the 24k restirction, comes from it loading stuff into L1 cache only
<oliv3r>
what about CPU L2 cache, we can't use that either?
<hno>
no it's clearly SRAM A.
<oliv3r>
ok, then I don't know why lkcl said that :p i'll find the quote again
<oliv3r>
well sram A is 64k, so the artificial 24k limit baffles me
<hno>
It's 48KB.
<oliv3r>
sorry, 48k
<oliv3r>
well 48/2 is 24 ...
<hno>
and the upper 16KB is special, which leaves 32K, and BROM also needs some memory for stack and runtime data which likely is about 8KB,
<lkcl>
oliv3r: don't take aaanything i say as authoritative :)
<oliv3r>
but once brom is done and SPL is running, isn't that memory freely available again?
<hno>
sure. I said BROM will only load 24KB for us.
<oliv3r>
so the 24k is 48 - 16 - 8
<oliv3r>
henc,e 24k
<hno>
code + data needed to get things up and running to the point that we can read more data from the boot device needs to fit in 24KB.
<hno>
which leaves us currently.. 3KB free.
<oliv3r>
but the SPL allready has the mmc bit in it, correct? i mean, we read u-boot from SPL
<hno>
which is the minimum I can live with. Needs some headroom to handle changes in future u-boot SPL framework.
<hno>
Yes.
<CaCtus491>
another silly questions here - on the SD image, I have boot.scr, script.bin, uImage. Are these as follows: boot.scr: info to tell uboot what to do, script.bin: board specific configuration of the a10, uImage: kernel image
<hno>
CaCtus491, yes.
<hno>
boot.scr is an u-boot shell script.
<hno>
wrapped in an u-boot header (mkimage)
<CaCtus491>
when I start this SD image (after copying my original working script.bin from NAND onto the SD), I get the following from uboot:
<CaCtus491>
*** Warning - bad CRC, using default environment
<oliv3r>
that's no problem
<oliv3r>
u-boot tries to read the ENV partition
<oliv3r>
which is invalid so it skips it
<CaCtus491>
ahh ok
<CaCtus491>
hmm, is this even going to work properly? would I need to compile uboot with my board specific config, or is all that contained within script.bin and read from there instead?
<rm>
you need to have u-boot SPL that doesn't try to set a too high RAM frequency
<rm>
the whole rest of it is pretty much universal
<oliv3r>
CaCtus491: you NEED board specific u-boot-SPL.bin since it contains memory timings specific for your board. That said, you can always pick a '360 MHz' board specific u-boot-spl and it will work. If you know your memory settings, you can try one of those aswell
<oliv3r>
the SPL only has specific settings for memory timings as the SPL sets up the memory
<oliv3r>
hno: ok, just a brainfart, what if, the current SPL drops the memory init bit, becomes a very simple MMC loader, loads a TPL into SRAMB, which now can hold way more then the earlier 24k, and the TPL boots u-boot? or that just to far fetched/
<CaCtus491>
does SPL stand for anything in particular?
<oliv3r>
Second Program Loader
<oliv3r>
the BROM is the FPL; First Program Loader
<oliv3r>
BROM stands for Boot ROM; and rom .. Read Only Memory ;)
<oliv3r>
the BROM is embedded into the SoC/CPU, every CPU has one, I think if you want to compare it to x86, x86 has a loader that executes code at a certain position, which we all know as the bios
<oliv3r>
the BROM is a bit more advanced, it checks if there's a valid image on MMC0; NAND; SPI-NOR; MMC2 and if all that fails, falls back into FEL mode (http://linux-sunxi.org/BROM)
<oliv3r>
because of memory limitations (that hno and I spoke of before) the BROM can only laod 24k worth of data from those locations. Since 24k is too limited to do anything usefull, it currently loads the so called SPL, which initializes DRAM, loads the bootloader (u-boot) from mmc into dram and starts executing it. U-boot in turn loads the kernel, the dtb if available etc etc and the linux kernel
<oliv3r>
the SPL wouldn't be needed if the BROM could load more then just 24k
<CaCtus491>
ahh ok
<CaCtus491>
dtb = ?
<oliv3r>
Device Tree Binary
<CaCtus491>
which is that 'compiled' fex file?
<oliv3r>
almost
<oliv3r>
allwinner has their fex file (compiled) which the kernel (driver) parses for settings
<oliv3r>
the devicetree is a linux generic (new) thing that describes the platform in a sense
<CaCtus491>
ok, so the dtb is ultimately derived from the fex file :)
<CaCtus491>
is there any reason why the current uboot doesn't support NAND?
<CaCtus491>
...and is it ever likely to be added in?
<oliv3r>
lol no
<oliv3r>
the fex and dtb are completly unrelated
<mnemoc>
both describe the board...
<oliv3r>
fex is allwinners 'invention' to have 1 kernel boot on many configurations
<oliv3r>
the dtb is a generic thing in the linux kernel for 'everybody' to use
<oliv3r>
dtb is something relative 'new' however
<oliv3r>
and the 3.0 kernels didn't really have support afaik or at the least it wasn't hot back then
<oliv3r>
for 3.9 we use dt isntead of fex :)
<CaCtus491>
ok, so we can't really blame allwinner then
<CaCtus491>
any thoughts as to why there is no NAND support in the current uboot?
<mnemoc>
because the driver is a mutant ugly beast from uranus
<oliv3r>
CaCtus491: the current u-boot doesn't support nand, because Allwinner has some nasty nand driver in use, we have early mtd support, so in time
<mnemoc>
the mtd driver still needs to get randomization support and all sorts of witchcraft before been usable
<oliv3r>
the mtd patches are in very early form and need quite some work still
<mnemoc>
and it will break backward compatibility
<CaCtus491>
ok, so no nand currently because allwinner's hack was too ugly to keep, and no-one has finished imlementing a better solution yet, however there is a general aim of eventually supporting it?
<CaCtus491>
....however progress may be slow since most people seem happy with the kernel and root fs on SD
<oliv3r>
aim yes, but someone needs to step up and do it :)
<oliv3r>
limited resources and time and all that :)
<CaCtus491>
understood
<mnemoc>
help welcoemd ;-)
<oliv3r>
someone did write a workable mtd implementation for both u-boot and the linux kernel
<oliv3r>
but needs to be integrated and refined, and as mnemoc said, randomization support added
<oliv3r>
CaCtus491: so if you are able to work on that :) feel free :D
<mnemoc>
btw, anyone with A10S around? can you get me a kernel log dump of amery's wip/sunxi-3.n/soc-detect ?
<CaCtus491>
heh. maybe eventually, but I'm still getting my head around a lot of things here. Previously I've been writing for arm7 stuff without an OS :)
<mnemoc>
arm7 or armv7?
<CaCtus491>
as in LPC2148 micros, etc
<oliv3r>
that's arm7 most likyl then, not armv7
<mnemoc>
a dump of the serial output of that branch from a13 would be appreciated too
<oliv3r>
have I ever said I HATE, with passion, the naming of ARM cpu cores?
<oliv3r>
arm1-11; amv1-8
<oliv3r>
who can make heads or tails from that
<mnemoc>
EEs...
<oliv3r>
only have a10
<CaCtus491>
Is the boot process from NAND is exactly the same as SD? What I've read suggests it differs slightly, ie reading the first block from NAND rather than 4kB at an 8kB offset as done for SD
hramrach_ has quit [Remote host closed the connection]
<mnemoc>
CaCtus491: BROM -> boot0 -> boot1 -> axf -> /dev/nanda's linux/u-boot-bin + env on nand partition -> bImage in boot.img int another raw nand partition
<CaCtus491>
ok, so a fair bit different then, ie SPL is effectively boot1 + axf
<CaCtus491>
does axf configures dram speed?
<CaCtus491>
...and if so, where does it get loaded from? env?
<CaCtus491>
hipboi: ok, perhaps when I have it all clear
<CaCtus491>
so, we have boot0 taking care of dram speed (read from SD / NAND), the rest of the chip configuration (ie stuff that is in the fex file) is handled by uboot? or does it become irrelevant when we use dtb, thus handled by the kernel instead?
<oliv3r>
SPL == boot0; U-boot == boot1
<oliv3r>
the major difference between the two, is the NAND driver, vs MMC driver; mmc is done and integrated, nand not
<oliv3r>
CaCtus491: the thing is, allwinners nand driver does more then 'just a driver'. It's bascially mtd driver, + wearleveling driver etc exposed as a block device, in true random adhoc development style
<oliv3r>
it's extremly messy, has weird things and isn't usable, maintainable etc in its current form. well useable, as it it does 'work' but that's it
<oliv3r>
hipboi: I broke my cubieboard :( PHY isn't working anymore :(
<hipboi>
yeah
<oliv3r>
hipboi: I guess you don't know if writing to certain registers can break the PHY?
<hipboi>
i don't know
<oliv3r>
it's not important, I don't need it that much to write my current drivers on
<oliv3r>
but i was a little sad :(
<hipboi>
ready for the cubieboard2
<oliv3r>
it might be that the phy 'just died' and has nothing to do with registers
<hipboi>
does the led of the rj45 blink?
<oliv3r>
nope
<oliv3r>
i wanted to see if I could write some phy registers to make the led go on/off
<oliv3r>
mii dump says everything is 0xfff :S
<oliv3r>
so it it can't see/talk to phy I guess
<oliv3r>
could be the emac is dead; but those registers hold somewhat reasonable values, or rather, it holds values :p
<oliv3r>
isn't it much easier to just ldr r1 = 0x01c20054 in one go?
<mnemoc>
tried to run them on dosemu but the char encoding and fonts don't help
<oliv3r>
not utf8?
<oliv3r>
fix it!
<mnemoc>
cp437
<mnemoc>
boxing chars and shadows were "critical" those days
<mnemoc>
and i never managed to reproduce that decently enough
<oliv3r>
ah
<RaYmAn>
oliv3r: maybe "easier" but certainly not more efficient. r1 is used multiple times with different offsets. So you save a bunch of instructions =P
<oliv3r>
RaYmAn: well, it always does a load r1 + offset, which maybe can be done in 1 instruction, I guess arm is smart like that, but how is that more efficient then reading the register directly?
<oliv3r>
the way I count it, you have 1 (L26) instruction extra :p
<oliv3r>
I dont' see r1 being used for anything else.
<RaYmAn>
oliv3r: line 32, 33, 36,37,40
<oliv3r>
yeah, but those are all address + offset
<RaYmAn>
you'd need an extra ldr r1, =0x01c200<offset> for each of those lines
<oliv3r>
but you could do ldr r2 = 0x01c200<offset>
<oliv3r>
i mean, you want in r2, the content of those registers
<oliv3r>
or am I missing something? :)
<RaYmAn>
yes, if you do 'ldr r2, =0x01c200<offset>' you load the address into r2, not the value at the address...
<oliv3r>
ah
<oliv3r>
ok, then I understand I guess
<oliv3r>
that's the difference then, address loading and value loading
<RaYmAn>
yup :)
<oliv3r>
so r1 contains the address, while r2 gets the data loaded FROM address (+ofset)
<RaYmAn>
you can load values that are close to 'yourself' directly with ldr r2, [pc, #offset]
<oliv3r>
while i'm pikcing your brain, L27 - L32 does a Read, modify, write cycle
<oliv3r>
i'm not sure i follow line 29
<oliv3r>
line 28 puts the value 0x333 into r3
<oliv3r>
line 29 substracts r3 from r2 and stores it in r2?
<oliv3r>
L30 then moves null into r3, does an ORR (L31) with r2 and stores the result
<oliv3r>
is that correct?
<Turl>
also, maybe 0x01c20054 is not representable as an immediate
<Turl>
as it's a 32 bit value on a 32 bit instruction
<RaYmAn>
L29 doesn't subtract
<oliv3r>
0x01c230054 is the clock control for CPU and APB etc busses
<RaYmAn>
"The BIC (BIt Clear) instruction performs an AND operation on the bits in Rn with the complements of the corresponding bits in the value of Operand2."
<oliv3r>
NOT AND I think
<RaYmAn>
yeah
<oliv3r>
oh yeah, i'm confused with L10 :p the first instructino i had to look up
<oliv3r>
so R2 = ^(R2 & 0x333)
<RaYmAn>
hm, I would think R2 = R2 & (^0x333)?
<Turl>
sounds like RaYmAn's to me
<oliv3r>
well then it's R2 &= ^0x333
<oliv3r>
which makes perfect sense :p
<oliv3r>
i used that on AVR's to clear bits if i recall correctly (been a while)
<RaYmAn>
yup, the name makes sense then :P
<oliv3r>
so 'ensure that 0x333' bits are cleared in R2
<oliv3r>
not sure i understand why, wouldn't all registers be 0 at startup anyway?
<Turl>
btw, usually I note complement/not as ~, and ^ is XOR
<oliv3r>
if not, would there be a loop which sets everything to 0 anyway?
<oliv3r>
Turl: you are correct
<Turl>
oliv3r: I don't think so, they have default values on the datasheet don't they? :P
<oliv3r>
true
<RaYmAn>
I wouldn't count on bare metal code doing that (also, it's probably a compiler that has decided to do that)
<mnemoc>
oliv3r: documentation is more valuable than code as there is less people doing it properly ;-)
<Turl>
hno: if it was at 0x01C00000
<Turl>
hno: have a look at page 77 of a10 user manual
<hno>
Turl, yes it's at 0x1c000xx, xx > 4
<Turl>
hno: not much help then
<hno>
chip ID & UBOOT bit easily identified, but plenty of others there.
<mnemoc>
what is that "UBOOT" thing in SRAM_BASE+0x24?
<mnemoc>
the state of the pins?
<mnemoc>
ok, just saw it on the wiki :p
<hno>
yes.
<hno>
we should expose that somehow to userspace as well.
<hno>
mnemoc, you dodn't see it before when looking up the chip id bits?
<mnemoc>
i saw the UBOOT part, but my brain decided to ignore it
rellla2 has joined #linux-sunxi
<mnemoc>
by "to userspace" you mean exposing all registers in /sys ?
<mnemoc>
or just printk()ing?
<slapin_nb>
what so cool about these regs to be exposed? as the less you know, the better...
<slapin_nb>
hi, all!
<Turl>
hi slapin_nb
<mnemoc>
slapin_nb: help to learn about the arch, and as so let us find tools we can use to make things better
<mnemoc>
for example soc-detect now doesn't rely in been able to read the BROM for example, which let's it work much sooner
<mnemoc>
and may make possible to have a single kernel bin for sun4i/sun5i
rz2k has joined #linux-sunxi
tinti has joined #linux-sunxi
<slapin_nb>
mnemoc: can't get you really... given long thought to what you say, but still can't get it. Can you tell me the usefulness in particular of these regs for userspace? probably something like devmem2 can do the job about learning the arch... as excessive sysfs entries mess up things too much... ... ...
gzamboni has quit [Remote host closed the connection]
gzamboni has joined #linux-sunxi
<mnemoc>
slapin_nb: devmem2 won't give meaning, it will only dump
* rellla
asked allwinner for a armhf-cedar-lib, kind of EULA and a complete libve-user-guide as a second step ;)
<mnemoc>
slapin_nb: /sys can tell fields, and let you read and write things safely
<mnemoc>
rellla2: what makes you think they'll collaborate this time?
<slapin_nb>
mnemoc: devmem can write too...
<mnemoc>
:(
<mnemoc>
slapin_nb: but bulk
<mnemoc>
advertise /dev/mem access to de masses (as olimex does for gpio access) is risky
<hno>
mnemoc, I mean exposing the UBOOT bit in /sys
<mnemoc>
s/de/the/
<hno>
there is no use in exposing unkowns. /dev/mem works fine for those.
<hno>
mnemoc^
Yaku321 has quit [Ping timeout: 248 seconds]
<rellla>
mnemoc: at least we got the new libve-demo-files. and i have 3 mails form allwinner. so for me they seem to will ;)
<mnemoc>
hno: agree, not unknowns.
<mnemoc>
rellla: nice :)
<hno>
They probably want to, but not tao assign resorces to it...
<mnemoc>
hno: is there an "standard" class for exposing registers?
<mnemoc>
or we make a sunxi-sramc driver and so on?
* slapin_nb
agrees, too
<hno>
you don't expose registers. You expose values & parameters.
<mnemoc>
hno: yes, but I mean a class already implementing an struct to deal with values, masks, ... in a table fashion
<hno>
And it's "System Control", not SRAMC. The SRAM registers are only the first two.
<hno>
and the only documented ones.
<mnemoc>
ok
<Turl>
rm: how's that XP installation going?
<mnemoc>
hno: so SW_VA_SRAM_IO_BASE needs a sister and my SRAMC_CHIP_ID_ and sunxi_sramc_chip_id() a rename :p
<hno>
Should be SW_VA_SC_IO_BASE I think, and SC_SRAM_CTL_REG0, SV_SRAM_CTRL_REG1
<hno>
s/SV/SC/
mixaz has joined #linux-sunxi
<rm>
Turl, it finished the 1st stage (before the reboot) in about 40 minutes
<rm>
but after a reboot it can't boot from the HDD, "Disk read failed, press Ctrl-Alt-Del"
<rm>
it's a mysterious error, I had it on real h/w too
<rm>
did not find what's the cause or solution
<rm>
my guess is it doesn't like the way partitions are set up
<rm>
going to retry with a blank disk, and possibly try SCSI instead of IDE
<mixaz>
Hi everybody, I'm sorry for my ignorance - I have some basic questions about sunxi, and I appreciate your answers. I know there are low-cost Android tablets on market based on A13 - will it be possible to boot Linux there, Arch or Debian? sunxi site says that it is possible, but I'm not sure, just to confirm. Can I boot a Linux ROM from SD, and touch screen will be supported for example? USB, GPRS, camera?
<Turl>
yes, it should be possible to
<Turl>
it's not something you can download, put on a card and get it working out of the box though
<mixaz>
depends on drivers availability, right?
<Turl>
yes, and some stuff might not function as you'd expect
<mixaz>
Any links to read about the problems I can face?
<mixaz>
May be somebody already tried to do such things...
<Turl>
I don't think there's any with all of them
<Turl>
but you can expect your touchscreen to need configuration
<Turl>
or need to set ssvb's sunxifb up to get decent X performance
<mixaz>
ok, thanks. Actually my requirements do not need high X performance, just showing some QT GUI will do. USB in accessory mode is a requirement - is it feasible?
shineworld has quit [Remote host closed the connection]
<Turl>
mixaz: I don't know tbh
<mixaz>
OK, no problem
<Turl>
mixaz: drachensun here sells tablets with X on them, maybe he can give you an idea on what kind of issues you might face
<mixaz>
Very interesting, thanks
<drachensun>
pengpod.com
<drachensun>
we dont have an A13 offering though
<mnemoc>
drachensun: do you have a A10S? can you try the wip/sunxi-3.x/soc-detect branch of my github and give me the printk() output?
<mixaz>
Ah, I already saw that site, and actually considering buying a pengpod
<drachensun>
excellent, well I'm around right now so you can ask whatever
<drachensun>
we also have a #pengpod channel
<mixaz>
ok
<drachensun>
mnemoc: I don't actually, I've noticed most of the MK802 you get now have the A10s but my supplier is still shipping the originals
<drachensun>
mnemoc: I got one batch of them in by accident from a new supplier I was considering but they wouldn't boot and I dont think they have a serial port, at least not an obvious one to try
<mixaz>
I know Android supports only sleep power mode, but per my requirements I need suspend to RAM or SD - does it work OK on pengpod?
<mnemoc>
tsvetan promised to give away a couple of a10s-olinuxinos soon
<drachensun>
No, all the low power stuff is better in Android than Linux
<drachensun>
I think some of the guys in here just fixed up the Linux suspend mode, but I haven't had a chance to test it or update my kernel with it
n01 is now known as n01|afk
<mnemoc>
wingrime iirc
<mixaz>
device needs to be installed in a car, so Android in sleep mode is not a good option. Suspend is better imho
<mixaz>
how fast Android boots on a penpod? And Linux?
<drachensun>
hmmm maybe 15-30 seconds, Linux on flash boots a little faster than Android
<mixaz>
15 seconds would be quite good
<mixaz>
I have few Android devices and they boot a minute and more
<drachensun>
well I just timed on booting Linux from an SD, it was 30 seconds almost on the nose
<mixaz>
ok, thanks for the info
<drachensun>
seems like on flash is a little faster but I don't have one of those handy at the moment
<mixaz>
ok, no problem
<mnemoc>
a good uSD can easily beat any nand used on these cheap devices
<mnemoc>
but it's not a fair comparison considering the price of the uSD C10 cards and the nand chips
<drachensun>
yeah, I am switching to all class 10 cards actually as soon as we clear the old stock, the price difference is so small now
mdp has quit [Read error: Operation timed out]
<mixaz>
ok, thanks. I wonder how faster it could be to boot Android from such uSD
<mixaz>
in theory
mdp has joined #linux-sunxi
wingrime-android has joined #linux-sunxi
<wingrime-android>
oliv3r: I add some info to re page
<wingrime-android>
hno: is any usage "undocumented sram regs" in eGON
<wingrime-android>
?
<wingrime-android>
and what about nand boot.....
<hno>
wingrime-android, I don't know. The UBOOT bit is clearly accessed in BROM however.
<wingrime-android>
who know how test cedar on linux without vlc?
<hno>
There is nothing magical about NAND boot. All is known, even code exists, just not quite polished yet.
<wingrime-android>
hno: it looks like nand too slow....
<techn_>
ssvb: great benchmarking! disp hw starts doing some extra memcpy if it doesnt get framebuffer data in time?
<hno>
wingrime-android, too slow for what?
<wingrime-android>
handle linux better than mmc
<wingrime-android>
I interested in usb flashing too
<wingrime-android>
as full usb boot
mixaz has quit [Read error: Connection reset by peer]
<hno>
Whell, you get what you pay for. Not fair to compare a budged NAND chip to high perf MMC card.
<wingrime-android>
why thay simply use inner mmc card for boot like some china tablets
<wingrime-android>
i not mean emmc
<hno>
mmc or eMMC is pretty much the same.
<hno>
Allwinner supports NAND or eMMC(MMC) as internal storage. Up to the device manufacturer to decide what to use.
<slapin_nb>
in general, NAND is not slower than MMC cards, that depends on particular chips and cards.
<hno>
and nand controller and drivers
<slapin_nb>
hno: yes, and mmc controller too
<hno>
yes
<wingrime-android>
nfc+mtd are faster than aw driver?
<wingrime-android>
with block device emulation layer?
<slapin_nb>
also, mmc is often not reliable enough as boot medium due to stupid FTL chips
<slapin_nb>
wingrime-android: I never did the benchmark
<wingrime-android>
also, aw drivers full have... busy waits
<libv>
anyone going to linuxtag?
* slapin_nb
does have 20 years old device with NAND flash as boot medium and it is still alive and working, and had wasted a ton of mmc cards at the same period
<hno>
Linux mtdblock FTL layer isn't very good.
<slapin_nb>
wingrime-android: probably
<slapin_nb>
hno: most mtd devices navar use it
<slapin_nb>
hno: there is no FTL in mtdblock
<slapin_nb>
hno: it is not intended to be used that way
<slapin_nb>
hno: there is special FTL layers in Linux for various flash mediums on top of mtd, but I never used these.
<slapin_nb>
the way to go is flash file systems, like ubifs, jffs2, yaffs, etc.
<hno>
Aha, right. there isn't even an FTL there.
<hno>
in mtdblock. No suprice it sucks so badly.
<slapin_nb>
hno: it is used by VFS to set up structure, there is no other uses
<wingrime-android>
so how using ext4 in modern android can be featre if mtdblock so bad
<slapin_nb>
hno: it is not intended to be used as block device to read/write data by user apps
<wingrime-android>
*feature
<slapin_nb>
wingrime-android: common android uses various filesystems
<Turl>
there's ubiblock if you need it
<slapin_nb>
wingrime-android: A10's use own block driver
<hno>
slapin_nb, what uses mtdblock?
<wingrime-android>
I know this
<slapin_nb>
I've seen android builds on ubifs and jffs2, too
<wingrime-android>
also this driver have cache layer
<slapin_nb>
hno: all filesystems which use /dev/mtdx use /dev/mtdblockx to setup vfs
mixaz has joined #linux-sunxi
<slapin_nb>
hno: some even don't need it that much
<hno>
Right.. At the moment, it is also required for the Journalling Flash File
<hno>
System(s) to obtain a handle on the MTD device when it's mounted
<hno>
of the mtdblock device).
<hno>
(although JFFS and JFFS2 don't actually use any of the functionality
<slapin_nb>
wingrime-android: when you use block device, you get block device cache.
<slapin_nb>
wingrime-android: but all filesystems use VFS cache and other caches
<wingrime-android>
slapin_nb: i talk about, that aw nand have own cache
<slapin_nb>
wingrime-android: no own cache
<wingrime-android>
aw nand driver
<slapin_nb>
wingrime-android: not even single bit
<wingrime-android>
see nand driver
<slapin_nb>
wingrime-android: no any cache there
<wingrime-android>
i have defenetly saw it in aw nand driver
<hno>
wingrime-android, there is some caching at the FTL layer of the aw driver. As needed for implementing an FTL.
<slapin_nb>
it is not actually cache in means to speed things up to be seen by aw annd vs mtd
<slapin_nb>
and it is not really some thought cache, just some pool
<wingrime-android>
i talking about drop this creepy code
<wingrime-android>
and use mtd and nfc
<slapin_nb>
wingrime-android: as soon as mtd=based approach will mature, I think it can replace the aw nand driver
<wingrime-android>
aw simply connected code from old projects *own os*
<wingrime-android>
to kernel
user_2 has quit [Remote host closed the connection]
<wingrime-android>
mnemoc: so what we will do with 3.0 ?
<wingrime-android>
haw you reports from androids?
<wingrime-android>
*have
<mnemoc>
not me
<mnemoc>
but i've not followed the ML or irc in a pretty long time
<wingrime-android>
what do you think about make it "fix only"
<wingrime-android>
like stable
BJfreeman has quit [Ping timeout: 240 seconds]
<mnemoc>
until 3.4 is confirmed to work fine for android people we can't break the sync between both trees or it will become unmaintainable
_BJfreeman has joined #linux-sunxi
<mnemoc>
then we can just obsolete 3.0 and focus in 3.4
<mnemoc>
(and -next)
<wingrime-android>
witch version will be next?
<mnemoc>
sunxi-next aims at mainline
_BJfreeman is now known as BJfreeman
<mnemoc>
not script.bin-based
<mnemoc>
3.4 will have enough fun integrating sun[67]i to waste time in a >3.4 legacy branch
<mnemoc>
and people wanting newer can help taking drivers from 3.4 into sunxi-next
<drachensun>
I'm actually working on a sun6i 3.4 merge now
<wingrime-android>
will uboot make script-> device table + cmdline options for config ? or only static tool?
<wingrime-android>
script conversion
<mnemoc>
drachensun: can you see what sunxi_sramc_chip_id() from amery's wip/sunxi-3.4/soc-detect returns in your sun6i?
<mnemoc>
wingrime-android: personally I find more reasonable to add dtb support into `fexc` and keep maintaining sunxi-boards in .fex for a while, at least until things settle up there
<wingrime-android>
drachensun: can you test my tool for cedar?
<drachensun>
mnemoc: I'll see what I can do, with the sun6i core its not compiling yet
<wingrime-android>
it must return cedar version also
<mnemoc>
drachensun: you can inject sunxi_sramc_chip_id() pretty early
<drachensun>
wingrime-android: I see, ok, once it is booting, I will try and test that too
<mnemoc>
drachensun: it's only to see if we can read the chip-id in a31 in the same way as in a1x
<wingrime-android>
drachensun you can also try help us, testing sram undoc reg for ID
<mnemoc>
drachensun: but you can also do it via /dev/mem
<wingrime-android>
using uboot
<mnemoc>
or uboot
<drachensun>
well I can put small bits of code in the liche 3.3 kernel for the A31 and run small test
<drachensun>
that boots
<drachensun>
but I'll have to do it a little later, I'm pretty backed up today
rellla has joined #linux-sunxi
<wingrime-android>
in this cases only jtag helpfull
<drachensun>
mnemoc: I think that is the way to go though, the sun6i source for allwinner seems to be very broken when using Linux features not called by Android, I think just merging the core back into the community kernel is the only option to really use it
<mnemoc>
wingrime-android: that's not the head of the branch ;-)
<slapin_nb>
wasn't sun6i relaeas containing blobs for everything?
<slapin_nb>
*release
<mnemoc>
not our a31-dev branch
<mnemoc>
leaked in march
<mnemoc>
but yes, they are making a very awful gpl violation with the nand driver
<wingrime-android>
blobs realy voliate gpl here
<mnemoc>
they used to include a .ko_ or .a and remove the .c
<mnemoc>
now they made a .c to wrap a gpl-violating library
<wingrime-android>
nand driver so crap, so thay not want show this to world
<mnemoc>
gpl-violating because of shame :p
<wingrime-android>
i don't see any reason hide this code, expect thay link some hard boiled 3rd code for caching
<slapin_nb>
too bad, instead of that they could make driver which use their NAND cntroller to the fullest, at least parallel operation for multichip configurations
<wingrime-android>
same with ar100
<wingrime-android>
it look like base for baseband
<wingrime-android>
as it runs in same memory , it very likely be big for handle 3rd IP for baseband
<mnemoc>
someone already decoded the blob for ar100 iirc
<mnemoc>
openrisc + little endian bus data
<wingrime-android>
mnemoc: it too simple but it look like base for modem baseband
<mnemoc>
sure, the a31s
<mnemoc>
phone oriented sun6i
<wingrime-android>
yes
<mnemoc>
the -dev for that soc was imposible to rebase :(
<wingrime-android>
but baseband not too easy wite it highly will be outsourced code
<wingrime-android>
mnemoc: only nand in blob?
<mnemoc>
iirc, yes
<wingrime-android>
that's all?
<oliv3r>
wingrime-android: i think we got a new member :)
<drachensun>
Looking at the headers on the old nand leaks I think they were using some licensed code they brought into the kernel, probably the original copyright holder objected
<oliv3r>
hno: ah, that's why they looked so clean; but the first bit, the disasembly analysis I did follow through.
<drachensun>
though of course that means they shouldn't have ever used it in a Linux kernel
<wingrime-android>
oliv3r i have add some additions to wiki for cedar
<oliv3r>
rm: that is funnyly awesome. some timing info is cool to know
<mnemoc>
wingrime-android: so the valgrind tool for replying cedarx?
<wingrime-android>
i need some player
<oliv3r>
mnemoc: yeah but documentation is boring :( though i admit, going over bootrom.s was cool to go over ;)
<wingrime-android>
vlc too long for build on tabled
<wingrime-android>
also i perfer mplayer
<mnemoc>
oliv3r: :)
<wingrime-android>
mnemoc: how about make crc32 for chip id (brom)
<wingrime-android>
it
<mnemoc>
wingrime-android: i'm sitting in a bank on a public square leeching wifi from a coffee shop, if you can add the code to soc-detect.c and test it, I can add it to the branch ;-)
<wingrime-android>
))))
<mnemoc>
also, if I still have pending patchsets from you, please tell me the date and subject
rellla has joined #linux-sunxi
<oliv3r>
someone should have linked mixaz the 1 second boot video from threewater :)
<techn_>
oliv3r: same came into my mind
<drachensun>
he is still on
<oliv3r>
slapin_nb: ftl chips? Faster then Light?
<rm>
I can't get it to boot after the first reboot
<oliv3r>
:p
<rm>
now retrying with qemu 1.1 -> 1.5
<oliv3r>
ssvb: I think L2 cache is done by BROM; I did some writing on the BROM page, takling about setup of cache + mmu (cp15)
<rm>
f**k it works :D
<hno>
oliv3r, are we talking about my BROM.s?
<ssvb>
oliv3r: nice, so you have got a dump of it and now working on disassembling it? :)
<ssvb>
oliv3r: I'm checking the settings for L2 cache timings right now, it looks like L2 can be overclocked to reduce latency by 1 cycle
<ssvb>
oliv3r: everything depends on whether it turns out to be stable or not
<ssvb>
oliver: also increasing L2 latencies can probably make the processor more overclockable if it is L2 cache failing to work correctly at 1.2GHz and higher
<mnemoc>
(only to madrid. fnot considering from there to brussels)
<oliv3r>
65 Euro's for thalys :(
<oliv3r>
15 euro's for 'normal' train i THINK
<oliv3r>
but this is ONE way
<oliv3r>
roundtrip is double that
eebrah|away is now known as eebrah
* hno
haven't managed to go to FOSDEM yet, and it's a fairly cheap (<200 EUR total both ways) 2h15m non-stop flight from here.
<techn_>
from here it's ~400e.. I need two flights per way
<techn_>
or train + flight.. by that way it would cost same and travel time would be 6h more :(
<oliv3r>
heh
<oliv3r>
so i shouldn't complain with my ~50 euro cost
<hno>
rm, that would be a first I think.
<hglm>
ssvb: I've made available a patch for sunxifb for testing/evaluation purposes. Anyone who is using the sunxifb Xorg driver, feel free to test this patch. It may improve performance a little (especially when running in 16bpp mode and when the CPU load is high).
<ssvb>
oliv3r: with 32K of L1 cache, random accesses in a 64K block have 50% hit ratio
<ssvb>
oliv3r: and this means that the L2 latency is 10ns (or 10 cycles at 1GHz) by default, and can go down to 9ns (9 cycles) if the L2 Cache Auxiliary Control Register is tweaked
<hno>
techn_, you can also jump to fel from the Allwinner bootloaders. press 1 during bootup to ask boot1 to enter fel, and can also be done with setting suitable key settings in script.bin
<hno>
so you can enter fel by holding a button at boot.
<ssvb>
oliv3r: BIC is a "bit clear" instruction, so it is not setting flags, but clearing them
<oliv3r>
could you in theory force exection from the linux kernel to execute 0xffff0020?
<ssvb>
oliv3r: also 0x1805 is not a valid immediate constant and can't be encoded in a single instruction
<oliv3r>
ssvb: i thought it was not and; my asm-foo is weak
<oliv3r>
0x1800 is and 1805 isn't? i don't understand :(
* mnemoc
wonders how gcc turns C bitops into BIC instructions
<Turl>
oliv3r: r0 &= ~0x5
<hno>
mnemoc, same way as it turns other operations into other instructions.
<hno>
loads of black magic and deeply windled code barely no one understands.
<ssvb>
oliv3r: you have only 32 bits (or 4 bytes per instruction), 0x1805 would need 16 bits which is way too much (because instructions need to encode a lot of other things like the type of operation, etc.)
<mnemoc>
hno: :)
<Turl>
oliv3r: yeah but when 0x1805 doesn't fit on the instruction you need to separate them
<oliv3r>
i still don't understand how 0x1800 does fit, and 0x05 doesn't fit
<oliv3r>
both fit in 16 bits?
<Turl>
oliv3r: it's not a direct embedding
<oliv3r>
oh
<oliv3r>
so how do you know
<ssvb>
oliv3r: the immediate constants are encoded as 8 bits with arbitrary shift
<Turl>
it has weird rules, like a part that's always shifted twice
<oliv3r>
ohhh
<ssvb>
oliv3r: so it is in fact (0x18 << 8), which is valid :)
<Turl>
oliv3r: if you read the ARM Arch Ref. Manual (ARM ARM :P) it's explained there
<techn_>
hno: btw. I dont need any hacks to felboot now :)
<oliv3r>
ok that I understand :)
<oliv3r>
good thing the ocmpiler knows about those tricks
<oliv3r>
and I have you guys to fall back on that
<ssvb>
Turl: right, the shifts are limited to 2 bits granularity if I remember correctly :)
<Turl>
oliv3r: same thing happens on other arches like MIPS
<oliv3r>
ssvb: so the 0x5 bit, is the Data RAM latency, but 9:15 is 'reserved'
<Turl>
0x1805 = 0b1100000000101
<oliv3r>
yeah bit 11 and 12 are 1
<oliv3r>
'reserved', UNP, SBZP
<ssvb>
oliv3r: no, it's some different coprocessor register, L2 Cache Auxiliary Control Register is "p15, 1, <Rd>, c9, c0, 2", but looks like you have "p15, 0, <Rd>, c1, c0, 0" in your dump
<oliv3r>
ssvb: L2 Cache Auxiliary Control Register bit functions is not right?
<oliv3r>
The ARM architecture provides a non-intrusive way of extending the instruction set using "coprocessors" which can be addressed using MCR, MRC, MRRC, MCRR, and similar instructions. The coprocessor space is divided logically into 16 coprocessors with numbers from 0 to 15, coprocessor 15 (cp15) being reserved for some typical control functions like managing the caches and MMU operation (on processors that have one).
<Turl>
techn_: android base heh
<techn_>
Turl: yeah.. but still boots a bit faster than real android :p
<hno>
s/c15/cp15/ and it's less contusing.
<techn_>
Turl: still no sunxi device for demo ;)
rz2k has quit []
<oliv3r>
hno: oh, ok
<oliv3r>
i'll update the sunxi wiki with what you just wrote
<ssvb>
techn_: "Boot to Qt is a commercial offering" does not sound very encouraging
mab_ has quit [Ping timeout: 256 seconds]
<ssvb>
techn_: kinda looks like the corporate entities want to destroy the current free software desktop "ecosystem" and replace is with some commercial closed source :(
<ssvb>
techn_: yeah the Qt itself is free, so the free software community can "contribute" to development, but the end result is the profit of the said corporate entities
<techn_>
ssvb: I dont see Qt as bad.. but best crossplatform tool there is
<mnemoc>
Qt -> C++ -> evil
<ssvb>
techn_: I don't see it as bad either (yet), but its architecture is driven by corporate interests and I doubt that the free software community can have any influence
<oliv3r>
ssvb: +10
<libv>
oliv3r: :)
<oliv3r>
libv: on fosdem, or +10'ing ssvb :p
<mnemoc>
redhat is also corporate interests driven and sometimes they do good things
<techn_>
ssvb: I has been always money driven
<oliv3r>
i can't say, redhad does sometimes bad things
<libv>
ZaEarl: no, sorry, no talk
<oliv3r>
i thin the cooperate heart, with red-hat is at the right place imo
<libv>
ZaEarl: your wife seems to be there, are you there too?
<ZaEarl>
I meant at next years fosdem
<libv>
ah :)
<ZaEarl>
linuxtag? no, we didn't make it. we're very bummed not making it.
<libv>
ah, too bad
<libv>
didn't your wife have a talk there?
* mnemoc
thought ZaEarl was from .au/.nz...
<ZaEarl>
but we're planning for next year. if you had to choose, fosdem or linuxtag?
<libv>
i vaguely remember seeing something like that in the schedule
<libv>
fosdem
<libv>
no doubt
<ZaEarl>
mnemoc, US and NZ.
<libv>
the linuxtag style conferences are dying out
<oliv3r>
libv @ fosdem2014?
<oliv3r>
what style is that? linuxtag?
<libv>
oliv3r: i will definitely be there
<libv>
i will definitely get stupendously drunk three nights in a row
<libv>
but whether i will have something useful to talk about, wait and see :)
<oliv3r>
i wouldn't mind doing a 15 minute linux-sunxi talk; but besides recruitment, what would it be about :(
<libv>
linuxtag is very old style, with booths and such
<oliv3r>
ah, hmm, kinda boring, i love the fosdem 'talks'
<oliv3r>
nerds doing keynotes :)
<libv>
there are big talks in big halls
<libv>
with few people visiting
<libv>
devrooms and one big melee of geeks lacks from linuxtag, which is where fosdem excells
<mnemoc>
ZaEarl: but living in .de now? I mean because of the "linuxtag" thing
mixaz has left #linux-sunxi [#linux-sunxi]
<ZaEarl>
no, living in US, we just travel a lot.
<oliv3r>
libv: so if we would wanna talk about sunxi @fosdem, devroom or lightening talk?
<Turl>
what about ELC?
<libv>
1h talk in a devroom
<libv>
imho even the mainline talks at fosdem are a dying breed
<techn_>
hno: network boot worked well.. but direct boot to kernel seems to be failing :/
<techn_>
hno: which kernel image format I should use?
<libv>
those talks have to be aimed broadly, and therefor people don't tend to visit them
<oliv3r>
libv: what would we possibly talk about in the devroom for an hour on sunxi
<oliv3r>
i guess 10 minutes and i'd be out of stuff to talk about ;D
mab_ has joined #linux-sunxi
<Turl>
script.bin!
<libv>
oh, it's easy to fill an hour with sunxi stuff, from history to available boards and features, to readily available images, then rolling your own, and then explaining what parts are being worked on and demonstrating a few things left and right
<oliv3r>
I'll have to think about it I suppose
<hno>
techn_, u-boot generally wants uImage (mkimage) format.
<oliv3r>
and see what people here think of it :)
<hno>
should not differ between tftboot and other booth methods.
<techn_>
hno: yeah.. but still it wont start kernel load :(
<oliv3r>
mnemoc: especially
<hno>
techn_, what are you doing?
<techn_>
hno: complains : ** Bad device mmc 0 ** n times
<hno>
yes...
<techn_>
tftp boot works ok
* hno
should move RAM boot first.
<hno>
techn_, what exactly did you try?
<techn_>
hno: great.. this is most likely RAM boot isn't first? :)
<hglm>
techn: I think I did those benchmarks, the drop has do with some kind of timing botteneck in the DRAM controller and buffer.
<ssvb>
techn_: no, it was not transferring any frames, it's just that the screen refresh starts to hinder CPU memory write speed (just the performance of 'memset' function)
<techn_>
hglm: oh.. sorry :p
eebrah is now known as eebrah|away
<ssvb>
techn_: due to some timing effects, it probably exceeds some threshold and starts geting severe penalties
<hglm>
The morale is that lowering the resolution/color depth/or refresh rate a little can speed-up your system a lot.
<ssvb>
the morale is that 1920x1080 at 60Hz and 32bpp framebuffer is unfortunately just a little bit above this threshold
<hglm>
Yes certainly on standard memory clocks.
<ssvb>
hglm: and I also did the same benchmarks a long time ago, but nobody listened :)
<hglm>
ssvb: tinymembench is a nice program, I hope it helps now the info is on the wiki
<techn_>
ssvb: I noticed them.. but I think there could be bug somewhere
<ssvb>
thanks for creating the performance tweaks wiki page, that's definitely a step in the right direction
<oliv3r>
ssvb: i always listen!
<ssvb>
oliv3r: :)
<techn_>
ssvb: If there is no bug.. we must say bye bye for multilayer support
<ssvb>
hmm, why?
<techn_>
if even one layer strugles hw
<techn_>
or is there bug that every layer is enabled by default :p
<ssvb>
but even with multiple layers disp needs to fetch the same number of pixels (unless you have translucent layers)
<ssvb>
and most of the time there is only one layer active
<ssvb>
and the users who want a responsive desktop probably should prefer to use some lower resolution
<ssvb>
after all, 1.66GHz Atom netbooks used a pitiful 1024x600 screen resolution
<techn_>
I wonder if this problem has fixed to a20 :p
<ssvb>
a dualcore Exynos5 Cortex-A15 1.7GHz beast in Chromebook also has to only handle a modest 1366x768 resolution :)
<ssvb>
and now only big optimists probably can expect silky smooth graphics on a single core 1GHz system with 1920x1080 monitor
<hglm>
techn: Does the A20 have faster memory or a wider memory bus? A10 is 360-80 MHz 32-bit.
<techn_>
hglm: dunno
<ssvb>
hglm: if somebody could run tinymembench on A20 or A31 system, we could get at least some preliminary information
<hglm>
ssvb: I was looking on the net for X benchmarks and downloaded cairo-perf-tools...then I noticed you have a trimmed version in your repo.
<ssvb>
:)
<techn_>
1920x1080 32bit @ 60Hz is 475MB/s
<hglm>
ssvb: Is it in any way possible to replay cairo-traces on screen? It seems to use off-screen rendering.
<ssvb>
there might be a way with some tweaks
<hglm>
ssvb: I guess cairo apps mostly use imageblt from off-screen to the screen.
<ssvb>
yes, most of the 2D rendering is done offscreen, people don't want to see any ugly flicker as the picture elements are drawn one by one
<techn_>
360Mhz 32bit is ~1440MB/s? .. so in theory memcpy should give 965MB/s - cache misses/extra work ?
<ssvb>
techn_: just imagine a road with a certain speed limit and a certain number of lanes
<hglm>
techn: memcpy must read + write, and then you have DRAM latencies etc.
<ssvb>
techn_: the theoretical bandwidth (cars per minute or something) can be calculated using these parameters, but that's an ideal case
<hglm>
ssvb: Do you have any idea whether Xorg fb's imageblt is optimized or suboptimal?
<ssvb>
techn_: and now imagine that we add some trailers running on this road at regular intervals (framebuffer scanout)
<ssvb>
techn_: even though they don't occupy much bandwidth by themselves, they still introduce certain inconveniences for the other drivers
<hglm>
Screen refresh at 1920x1080x32bpp @ 60 Hz is 480 MB/s bandwidth - that is lot of the bandwidth of the A10.
<hno>
techn_, RAM boot have now been reworked and usb-boot script updated accordingly.
<techn_>
ssvb: theory isn't that far if you check your benchmarks.. 1920x1080x32bpp 902 MB/s (NEON read bandwidth)
<ssvb>
techn_: so overall bandwidth available to the other users may degrade a bit more than just subtracting the theoretical 1920*1080*4 bytes*60Hz = ~500MB/s
<techn_>
ssvb: so I have to came into your conclusion.. there is not much what wie could do :(
<hglm>
techn: It's not a bug, it's normal :) Just increase memory clock or lower resolution/color/refresh rate for optimal system.
<techn_>
hglm: yeah.. I just thought that there was enough bandwith.. newer done the math :p
<ssvb>
techn_: the total ideal (and unreachable) theoretical bandwidth is something like 360MHz * 2 * 32 bits = ~2.9GB/s
<techn_>
ssvb: is it dual channel?
<ssvb>
double data rate
<hno>
DDR
<hglm>
A31 is dual-channel (64-bit DRAM bus) = 2 x memory bandwidth = fast
<ssvb>
hglm: in theory :)
<hglm>
ssvb: I guess designing an optimal DRAM controller isn't easy...
<ssvb>
I remember OMAP4430, which had excellent theoretical and really pitiful real memory performance
<hglm>
Yeah, OMAP was dual-channel which made me almost buy one for a tablet.
<ssvb>
hopefully A20 and A31 are not going to disappoint us :)
<hglm>
Dual core is nice, but on the A20 memory bandwidth will be a botteneck.
nove has quit [Quit: nove]
<ssvb>
hglm: forgot to mention one more thing - writing to the memory backwards is slightly more resistant to this screen refresh related performance drop than writing forward :)
<ssvb>
hglm: this also could be used as a workaround
<hglm>
ssvb: Yes, I noticed backwards copying was showing clearly higher numbers in those situations.
<ssvb>
unfortunately Cortex-A15 does not like backwards writes, so there is no generally universal solution
<hglm>
Most software will be doing forwards copying
<Turl>
ssvb: was your mele doing anything when running those tests btw?
<Turl>
I'm getting consistently lower numbers
<ssvb>
Turl: can you paste some details?
<ssvb>
Turl: no, the system was not running anything else
<ssvb>
Turl: what is the memory clock frequency on your device?
<Turl>
ssvb: it's running at 480
<Turl>
ssvb: I stopped transmission and now scores improved quite a bit, but still lower than yours
<Turl>
there's no other active process running now
<ssvb>
it's better to run it on a really idle system, the other processes may be thrashing caches
<Turl>
I'll give it a try on mainline+cubie next time I boot it
<ssvb>
like waking up for a really short time, running over some relatively small < 256K data structures and going to sleep again
<ssvb>
I remember people had problems getting consistent benchmark results on raspberry pi because of the constant usb related irq spam in the background
<ssvb>
even though the system seemed to be idle
<ssvb>
now they seem to have somewhat better usb drivers