ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
_BJfreeman is now known as BJfreeman
user_2 has quit [Ping timeout: 246 seconds]
mdp has quit [Ping timeout: 260 seconds]
mdp has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
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 ( 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?
dwilkins has joined #linux-sunxi
<CaCtus491> nvm, I just found:
rz2k has quit []
rellla has joined #linux-sunxi
andoma has joined #linux-sunxi
<oliv3r> Turl: which register is that?
<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> i'll go read up on that
<hno> yes, and extract values, add values, delete values etc etc,
<oliv3r> extract is what i'm after
<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/
simosx has joined #linux-sunxi
simosx has joined #linux-sunxi
simosx has quit [Changing host]
hansg has joined #linux-sunxi
<oliv3r> lkcl: i still haven't found your quote!
<oliv3r> lkcl: but gave up :p
<oliv3r> Turl: bottom of the page lists initial values, 0x1c20088 is 0x00000000
<oliv3r> 0x1c2008c reads 0x82000004
<oliv3r> (on cubieboard)
mturquette has quit [Ping timeout: 240 seconds]
hglm has joined #linux-sunxi
<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 (
<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> oh, not env - I've just read
<mnemoc> boot0 configures dram iirc
<mnemoc> livesuit injects a header with the info during flashing
<CaCtus491> Am I missing a document that describes all this that I should be reading first that describes all this?
<CaCtus491> hrm, I should read what I type before pressing enter, but you get the idea :)
<mnemoc> there is some text in rt's wiki. not sure if it was migrated to our wiki
<CaCtus491> where is rt's wiki?
<CaCtus491> oh
<CaCtus491> rhombustech?
<mnemoc> yes
<hipboi> CaCtus491, happy to see it move here
<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
<mnemoc> can you bring that to our wiki?
<mnemoc> bbl
<oliv3r> ok i will :p
<oliv3r> well I documented half of it here allready :
<oliv3r> hno: wasn't FEL code located at 0xffff4000? (half way into the brom?)
<oliv3r> or was it the other way around, 0xffff0000 is fel mode, and 0xffff4000 is the real BROM? eGON.BRM
jinzo has quit [Changing host]
jinzo has joined #linux-sunxi
paulk-desktop has quit [Quit: Ex-Chat]
<oliv3r> hno: or rather, fel is at 0xffff0020 which probably is 0xffff0000 without some fluff/header?
hramrach_ has joined #linux-sunxi
<oliv3r> i think, we even have code to the BROM, or big parts of it, in the boot0/1 code. I think it's built using the same code
<oliv3r> hno: is that why you triggered on the sram register 024?
shineworld has joined #linux-sunxi
eebrah is now known as eebrah|away
<rm> ha
<oliv3r> ho
<rm> booted FreeDOS i386 ISO in QEMU on an A10
<rm> works pretty snappy
<oliv3r> lol
<oliv3r> wasn't there some work in porting dos to arm?
<oliv3r> though being able to emulate i386 software on A10 is very cool in itself
<rm> next, GRML64 amd64 LiveCD
<oliv3r> lol
<rm> loaded initrd
<rm> aaaand either locked up, or "doing something"
<rm> I only have 512 MB of RAM on that MK802, gave QEMU 400, may be not enough for a LiveCD
<oliv3r> ah
<oliv3r> wiki wiki :p
<oliv3r> should be cool still, to load dosbox-arm without qemu
<rm> I'm going to try Windows 98
<rm> we hand-wave @ people with "it would be extremely slow"
<rm> but how slow exactly
<rm> or ...maybe usable?
<rm> I remember running Windows 9x on Pentium 100 with 8 MB of RAM
<rm> though 16 or 32 certainly help
<rm> point is, 100 MHz is 10x less than A10's 1GHz
<oliv3r> welld dosbox is an emulator allready isn't it
<oliv3r> so dosbox + qemu is kinda double the emulation
<rm> I don't mean dosbox
<oliv3r> arm-dosbox would be cool; and then win98
<rm> I mean running old x86 binaries unchanged
<rm> on full emulated OS
<oliv3r> dosbox-arm should allow that?
<rm> "should"
<rm> afaik dosbox is much more limited than QEMU
<rm> in what it can actually run
<oliv3r> you either use QEMU to emulate a full x86 cpu; whereas dosbox emulates less, because it doesn' thave too but is faster?
<rm> that's correct
<oliv3r> well yeah, but dos WAS allready much more limited
<rm> I want to look at the performance of full h/w emulation
<oliv3r> so having a x86 CPU, and run dos on it, you still have the same emulatio
<oliv3r> ah ok
<oliv3r> well you should be able to emulate XP just aswell :)
<oliv3r> with qemu 1.5; you can even do vga passthrough :p
<oliv3r> are there windos mali drivers :)
<rm> D:
<oliv3r> but yeah, dosbox has been done on mali
<oliv3r> erm raspberry
<oliv3r> so pure as an exercise, that should be very interesting
* mnemoc still maintain a couple of clipper apps running on dos 3.3
<rm> afk
<oliv3r> mnemoc: ouch
<oliv3r> ok, please help me understand the purpouse of this instruction: and the next line
<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)
<oliv3r> RaYmAn: true
<oliv3r> i should have re-read taht :)
<Turl> what's this disassembled code btw? :P
<oliv3r> foo &= ~0x01;
<oliv3r> Turl: the BROM :p
<Turl> oh, cool
<oliv3r> just was dabbling in documenting stuff, and kinda got stuff
<oliv3r> stuck*
<oliv3r> i won't do the whole thing
<oliv3r> just the interesting bits
<oliv3r> if you gimme a few, i'll save my intermediate work
hipboi has quit [Quit: Leaving]
<oliv3r> Turl: that's boot0
<oliv3r> it probably is the 'text' string BROM compares against, the 'header' it checks
<oliv3r> and i guess that's where it happens
<oliv3r> is what I was after documenting, specifically line 2402
<oliv3r> hmm; what if, memcpy is copy/pasted from GPL software, would they then have to release the source code for the BROM? >: )
<Turl> libc's are usually LGPL
<RaYmAn> Turl: but LGPL default doesn't have a static linking exception, does it?
<Turl> ah, it's embedded there
<oliv3r> well it's probably copy/pasted though
<oliv3r> doubt they linked in *libc
<Turl> yeah I guess it doesn't make a difference in this case
<oliv3r> they just copy pasted some basic functions?
<Turl> maybe they wrote it themselves
<oliv3r> well for now, I only noticed 'memcp' in the brom
<RaYmAn> it's also pretty hard to find out whether it's from GLIBC or somewhere else with a non-gpl/lgpl license
<oliv3r> Turl: doubt it, 'google memcp' copy, paste, slash what you don't need
<oliv3r> btw, my first intermediate save is here:
<Turl> oliv3r: writing a basic memcpy is trivial :p
<oliv3r> Turl: but copy paste iseasier :p
<oliv3r> anyway
<oliv3r> The most basic information i wanted to log/document there, is which clocks etc BROM sets up for us
<oliv3r> looks like its a copy/paste job from there
<oliv3r> looks like its a copy/paste job from there
<oliv3r> nvm
<oliv3r> that copy paste was wrong
<oliv3r> ok maybe googling for it isn't as easy :p
<oliv3r> enough distraction, bathroom break; then i'll write a little more
hansg has quit [Quit: Leaving]
tinti has quit [Remote host closed the connection]
<hno> gcc have memcpy implemented internally.
<oliv3r> hno:;a=blob;f=lib/string.c;h=09dfae03c247554deb48c29ce98693ffd9c25f9d;hb=HEAD
<oliv3r> copy-paste :)
<hno> oliv3r, u-boot is 90% copy-paste. what is the point?
<hno> probably more.
<oliv3r> u-boot is 90% BROM?
<oliv3r> and boot0/1?
<hno> no, copy-paste from other sources.
<oliv3r> well yeah
<oliv3r> but it appears BROM, boot0/boot1 contain u-boot bits
<oliv3r> u-boot lib/string.c is from linus, even has his copyright, but with a few commits that make it u-boot special
<hno> What have you found in BROM that with such unique signature that you can tell it's copied?
<hno> memcpy and friends have countless implementations.
<hno> most of which is not GPL.
<oliv3r> Assembly compiles to exact same code? :p
<oliv3r> it's not important, it's just really intersting is all
<hno> many different sources compiles to the exact same code for functions at this complexity level.
<oliv3r> gut feeling!
<oliv3r> anyway, back on editing:
<Turl> oliv3r: why does it setup mmc3?
<RaYmAn> Turl: iirc the boot order is mmc1, nand, mmc3? :P
<oliv3r> Turl: if only I knew
<oliv3r> Turl: but those address match?
<Turl> RaYmAn: mmc0 & mmc2 I think
<oliv3r> yeah, but it ONLY sets up mmc3 (probaly the others later)
<Turl> ffff405c:e3c22001 bic r2, r2, #0x1
<oliv3r> i may have made a naming booboo on the CCM wiki
<oliv3r> Turl: and don't ask me why, i didn't writ ethat :p
<Turl> ah, 0x1 is not a comment, crappy github highlighting
<Turl> indeed, 94 is mmc3 or mmc4 if you number them from mmc1
<Turl> it clears bit 0 though, doesn't it? that's 1/3rd of the divisor field
<Turl> doesn't make much sense :P
<oliv3r> Turl: i agree :)
<oliv3r> but that's not too bad, devisor 0 is still a division
<oliv3r> divisor bit 0 still yields a division
<oliv3r> i don't know at what clock speed the CPU runs at that time, e.g. what clock PLL6 runs at
<oliv3r> iirc the higher clockspeed gets set later in the boot process?
<oliv3r> some safe minimum value is the default, isn't it
<Turl> it's sourced from osc24M/hosc at that time judging by the defaults
<Turl> that disables MMC0 and I guess sets jtag up after it
<oliv3r> comment of JTAG1? :)
<oliv3r> if only we had a tool that would take that source, and graph it out nicely :p
<oliv3r> f_4c8c is hard to remember
<oliv3r> following a graph much easier
<hno> oliv3r & CaCtus491, some clarifications on the boot process:
<hno> SPL initializes DRAM clocks etc so that u-boot can be loaded into DRAM and executed from there. SPL is very small and does nothing else.
<Turl> this seems to set up mmc0 sourced from osc24M, no divisors
<hno> When using Allwinner botloaders the setup is slightly different.
<hno> boot0 does a partial system initialization, barely sufficient for it to load boot1.
<hno> boot1 then does a full system initialization, mounts the boot media and loads boot.axf.
<oliv3r> why would that be? why do they want a more featured boot1?
<oliv3r> hno: could you be so kind and proof-read my modifications to then?
<oliv3r> just saved it
<hno> boot1 does have a lot more drivers than boot0, including FAT filesystem driver and AXP PMU driver.
<oliv3r> so why does boot0 setup extra things for boot1?
<oliv3r> lazy programming?
<Turl> hno: would you happen to know off the top of your head how is mmc0 configured when leaving uboot?
<oliv3r> Turl: didn't you ask for one of those registers earlier? I responded to you :)
<Turl> oliv3r: yes, I bet it didn't fit on znc buffer though
<oliv3r> ah, i'll repaste
<Turl> oliv3r: it's 82000004, not all zeroes :)
<oliv3r> nuh uh
<oliv3r> that's diff
<oliv3r> ok maybe i read diagonal
<oliv3r> Turl: but does that answer your question? :)
<oliv3r> Turl: lookslike btw, that one of the last bits load_from_mmc does; is reconfigure the port to jtag
<oliv3r> so in theory, you could load from mmc0, swap out the card with JTAG and continue
<Turl> oliv3r: that register says it's sourced from pll5 and divided by 5
<Turl> is it from inside linux oliv3r ?
<oliv3r> Turl: u-boot console i did those dumps
<Turl> hm
<oliv3r> which booted from MMC
<oliv3r> i'll double check with nand-stock-uboot
<Turl> hno: did mmc config change "recently"?
<Turl> my uboot is from last year or so
<hno> Turl, mmc clocking haven't changed in our u-boot ever. But it's likely the allwinner u-boot clocks it differently.
Yaku321 has joined #linux-sunxi
<Turl> hno: we're both using your uboot though
<Turl> hno: I tftp my stuff and don't load anything from storage however, would that affect clocking? or is it clocked regardless?
<Turl> hm, it loads uEnv now that I think of it, so it shouldn't matter
egbert_ is now known as egbert
<oliv3r> mnemoc: don't rename the linux-sunxi github; alias to it if you want, but renaming is a bad idea imo and breaks links
<mnemoc> github announced redirects support a couple of days ago
<mnemoc> but won't do anything without community approval
<oliv3r> well you can make a redirect from sunxi to linux-sunxi :p but there's quite some links up on the wiki
<oliv3r> that would break
<Turl> the point of redirects is that if you rename it won't break
<Turl> :P
<mnemoc> no broken links, both URLs keep working
<Turl> mnemoc: what do you want to rename it to?
<oliv3r> sunxi :)
<oliv3r> mnemoc: ok copied the a10_boot_process in a new form over
<Turl> as long as AW doesn't want to sue us after it, I'd say go for it
<oliv3r> no cubieboard?
<oliv3r> i should upload mine :)
<oliv3r> Turl: is sunxi copyrighted by AW?
<Turl> I dunno
<oliv3r> besides, they love copying :)
<oliv3r> sunxi is a name btw in china
mixaz has joined #linux-sunxi
<oliv3r> Sun Xi is a mountain retreat
<oliv3r> mnemoc: hope you happy now that i wasted most of my day on the wiki; instead of writing code3!
<oliv3r> see nothing to worry abot
<Turl> mripard: implementing MMC clocks means implementing TS, SS, SPI, IR, IIS and possibly more :D
<oliv3r> why that many?
<Turl> because they're all the same
<oliv3r> aren't they all gated off something?
<Turl> just need to add the DT nodes and they'll work magically :D
<Turl> oliv3r: yes, they all have a gate
<oliv3r> so AHB buss, unmask MMC?
<oliv3r> mmc0*
<Turl> oliv3r: that's AHB MMC gate
<Turl> mmc takes another clock to work
<oliv3r> hmm
<oliv3r> ok, how do you know though? (I don't)
<Turl> oliv3r: because that's on the AHB register :P
<oliv3r> i don't follow :(
<Turl> and there's another gate on its own register that's muxed to other things
<Turl> oliv3r: the MMC part takes a clock to work and another clock to talk to the cpu via AHB bus
<oliv3r> CPU_CLK -> AXI_CLK -> AHB_CLK
<oliv3r> oh
<oliv3r> yeah
<oliv3r> bus clock, 'work' clock
<oliv3r> still don't understand why taht means TS, SS< SPI etc etc clocks
<oliv3r> having said that, yes; implement then! i need them :D
<Turl> oliv3r: touchscreen, security system, spi
<Turl> oliv3r: look familiar? :)
<oliv3r> i know what those clocks mean, but why they have to be implemented
<oliv3r> Turl: i wrote the CCM page :p so yeah
<oliv3r> yeah, they all use the same structure
<Turl> oliv3r: it's not that 'they have'
<Turl> oliv3r: once you implement MMC, you get all the others 'for free'
<oliv3r> ah you mean because they are nearly identical'
<oliv3r> ok got ya
<oliv3r> check the ccm headerfile from some of the dumps
<Turl> just add dt nodes with the compatible matching mmc and they'll work
<oliv3r> it lists very nicely all the dupes
<Turl> nice, I'll have a look
<oliv3r> well not 'nice' but reasonable
<oliv3r> don't call the main clock mmc! :p
<oliv3r> anyway, hometime
<oliv3r> see ya later/tomorrow :)
<Turl> I need to find a nice way to name them
<Turl> mod maybe? as in module
mixaz has quit [Quit: Page closed]
simosx has quit [Quit: Αποχώρησε]
<hno> oliv3r, looks reasonable to me. Keep in mind that any function names added in the disassembly is my own.
<Turl> aw calls them module0, I guess I'll go with that too
<hno> Turl, I do not think u-boot unconfigures anything before booting the kernel.
<hno> oliv3r, TS, SS, SPI etc are all different I/O modules.
<Turl> hno: where were these magic registers that you didn't know what they did?
<rm> it's pretty fast
<rm> 2 minutes later, 9% -> 20%
<Turl> rm: see how long it takes to boot then
<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> 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.
<hno> what about NAND boot?
<wingrime-android> hno: do you trued ida?
rellla has quit [Quit: Nettalk6 -]
<wingrime-android> ida can find all refs to reg
user_2 has joined #linux-sunxi
<wingrime-android> *tryed
<hno> Not sure I want more regs..
<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]
paulk-desktop has joined #linux-sunxi
rellla2 has quit [Quit: Nettalk6 -]
<ssvb> hno: who enables L2 cache on A10? is it u-boot? or maybe boot rom?
<wingrime-android> mnemoc: can you forw
<wingrime-android> forward rtl8188eu to 3.4
<wingrime-android> ssvb: brom, but I too interested where
<mnemoc> wingrime-android: isn't it already in stage/sunxi-3.4?
<wingrime-android> as I remeber, you have issue with wakelocks
<mnemoc> my port was naive and blind. I merged hansg's
<wingrime-android> than close this
<mnemoc> once it's confirmed to work I'll delete my branch
<mnemoc> wingrime-android: i don't have the hardware to test if it works or not
<mnemoc> so I can't close it
<wingrime-android> mnemoc: my hardware work perfect but it my port
<wingrime-android> i simply disabled wakelocks
<mnemoc> can you test the code in stage/sunxi-3.4?
<wingrime-android> not today maybe on week
<mnemoc> thanks
<wingrime-android> can be closed as patch merged
<wingrime-android> trivial fix
<mnemoc> done
<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
<wingrime-android> we still need differ a13 and a10s
<mnemoc> wingrime-android: there is code for that in that file
mab_ has joined #linux-sunxi
<mnemoc> but it's based in allwinner code, not in real-hardware experiments
<mnemoc> that's why there are so many printk()s
<wingrime-android> also you can make s,a
<wingrime-android> checksumm for brom
<wingrime-android> small database for it
<mnemoc> kind of fragile :p but it can be a last resource
rellla has quit [Quit: Nettalk6 -]
<mnemoc> it would be amazing if we end up been able to run the same bin on all a1x
mturquette has joined #linux-sunxi
<wingrime-android> mnemoc you should remove machine_is from it
mturquette has quit [Changing host]
mturquette has joined #linux-sunxi
<wingrime-android> and use sram way
<mnemoc> wingrime-android: I did. using sunxi_is_foo() instead on that branch
<wingrime-android> from it I mean
<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 ;-)
<wingrime-android> sorry
<mnemoc> still needs a lot of cleanup, but first need to know if it works :p
<mnemoc> will turn that into bitmasks eventually
<mnemoc> #define sunxi_is_sun5i()(sunxi_chip_id() == SUNXI_MACH_SUN4I) .... nice copy&paste error :(
<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
mixaz has quit [Quit: Leaving.]
mixaz has joined #linux-sunxi
nove has joined #linux-sunxi
<oliv3r> rm: awesome :D
<oliv3r> techn_: thanks, i've only backread entirely now :)
<oliv3r> (i'm slow backreader)
<oliv3r> ssvb: no, hno made the dump ages ago (5 months?) he put some details that he found in his file (linked from the BROM page)
<techn_> oliv3r: I finished 20min ago ;)
<oliv3r> i translated it somewhat to readable stuff; hno acked it :D
<oliv3r> libv: i wish i could go, too poor. aiming for fosdem next year
<oliv3r> hno: i belive we are :)
<mnemoc> oliv3r: how far from you fosdem is?
<mnemoc> 1h?
<oliv3r> hno: well brom.s being the .s from your github dump 0xffff4000 etc
<oliv3r> mnemoc: lol almost, i guess 2; public trnasport is probably a little longer
<oliv3r> <- poor carless schmuck
<oliv3r> but yes, i'm in Eindhoven, 10 minutes from belgian border
<oliv3r> fosdem is in brussels, about 2 1/2 hours
<mnemoc> oliv3r: 2h is a worthy trip
<mnemoc> 2.5 too
<mnemoc> so stop whinning and plan your trip to fosdem 2014
<oliv3r> lol you beter be there too :p
<oliv3r> i have a significant other to play around :p
<oliv3r> let me check public time
<mnemoc> only flying to madrid costs me over 150E. not your case
<mnemoc> (or 80E in a 12h trip by train)
<oliv3r> 3 hours, 00 minutes to brussels south, 15 minutes or so to fosdem?
<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).
<techn_> ssvb: have you bencmarked scaler and normal layer differences?
<techn_> or cost of multiple layers :/
<mnemoc> google maps refuses to show me a route by train, but it's 20h by car (which i don't have)
<mnemoc> by plane it's like 6h and 400E
<mnemoc> so 50E/3h is AWESOME
rellla has quit [Quit: Nettalk6 -]
<oliv3r> stop making me feel bad :p
<oliv3r> besdies, for me, even 50E is a lot :p
<oliv3r> i'm poor!
<mnemoc> fosdem worths it
<oliv3r> anyway, i really wanna go, only been once
<oliv3r> absolutly
<mnemoc> then start saving :)
<oliv3r> :p
<oliv3r> money is only half the equasion
<mnemoc> yoy have time
<oliv3r> that's the bigger problem :p
<mnemoc> for saving
<oliv3r> anyway, if someon goes, we should do a 15 minute linux-sunxi talk!
<ZaEarl> I expect libv to do another talk/demo
<oliv3r> probably focusing on lima(re)
<mnemoc> showcasing the mesa3d lima driver on a20 :D
<oliv3r> most probably :p
<oliv3r> gallium3D driver? :)
<mnemoc> libv: ---^ ? :)
<mnemoc> "Gallium3D has been a part of Mesa since 2009"
<mnemoc> -- holy wikipedia
<oliv3r> you made everyone go quiet :p
<oliv3r> ssvb: how's it going? Can you change those things as you expect?
<oliv3r> ssvb: was the brom.s usefull?
<mnemoc> oliv3r: :p
<techn_> can I make fel boot without pressing fel button?
<Turl> techn_: yeah, make a fel card :P
<techn_> Turl: what it needs? dead sd card? :p
<Turl> techn_: a sdcard with a jump instruction
<ssvb> oliv3r: it is ("Tag RAM latency" and "Data RAM Latency"), this register can be easily modified
<ssvb> oliv3r: right now Tag RAM latency is configured as 2 cycles and Data RAM latency as 3 cycles
<ssvb> oliv3r: reducing "Data RAM latency" to 2 reduces the measured latency for random accesses in a 64K block from 5.0ns to 4.5ns (see example at )
<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
<oliv3r> ssvb: confuses me a little though; don't they both set 1800 and 05? wouldn't 0x1805 do the same? so you set flags 1805 as features?
<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.
<oliv3r> Turl: yeah but r0 &= ~0x5; r0 &= ~0x1800 == r0 &= ~0x1805
<oliv3r> Turl: isn't it?
<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> i have no knowledge of such atrosities
<oliv3r> ssvb: so if I look at I can use 0x1805 and counts its bits to check the fields right?
<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?
<ssvb> oliv3r: this one is right - (c1, Control Register)
<ssvb> oliv3r: just download the PDF file with Cortex-A8 TRM and find them all there
<Turl> disabled instruction cache and program flow prediction then
<Turl> also data cache and mmu disabled
<hno> quite suitabe things to do on reset.
<hno> oliv3r, the first cN is the coprocessor register number accessed.
<oliv3r> ssvb: that's more like it
<oliv3r> ssvb: porbably should; i find the online resource horrible to use
<oliv3r> well i read that c15 is the cache/mmu coprocessor
<oliv3r> which gets disabled appearantly :p
<hno> c15 is the system control coprocessor (virtual)
<hno> controls the operations of the CPU core.
<oliv3r> oh; i read the wikipedia paragraph
<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? :)
<libv> oliv3r: fosdem is a long time away
<hno> Well, if it complains on mmc 0 then it could not have found an environment there.
<hno> techn_, the RAM boot alternative do not know what to use as root. Kind of expects to have an initramfs.
<hno> but should start kernel anyhow.
<techn_> hno: really? I cant have rootfs in sd card?
<oliv3r> libv: well plan early, plan well :)
<techn_> yeah.. even kernel wont start for me
<hno> techn_, technically yes, but not with my current default u-boot env.
<techn_> ok
<techn_> can I push env to ram?
mab_ has quit [Remote host closed the connection]
paulk-desktop has quit [Quit: Ex-Chat]
<ssvb> techn_: <techn_> ssvb: have you bencmarked scaler and normal layer differences?
<ssvb> techn_: do you mean the numbers from and from the other parts of this wiki page?
<techn_> ssvb: yeah.. which layer did you use?
<hno> techn_, not yet. But I will rework the default env to look for a boot.scr in RAM for ram-booting.
<ssvb> techn_: how does it work?
<techn_> ssvb: L143 should inform hw that registers has changed.. now it is done on every vblank
<techn_> ssvb: so every register change is triggered simaltanious
<techn_> *simultanious..
<ssvb> techn_: I have not looked into this part, but for example all the changes to layers take effect only on vblank
<ssvb> techn_: I have some comments inside of this demo program -
<ssvb> techn_: somehow it makes some sense
<techn_> yeah.. L143 triggers changes to effect
<techn_> ssvb: L143 then causes interrupt -> , which causes vsync to trigger
<ssvb> are you worried that it might do some work even when no changes are necessary?
<techn_> ssvb: I'm seeing some extra work from your benchmarks :/ Every frame could be transferred twice?
<ssvb> hmm, which benchmarks exactly?
<hglm> The sunxi-disp-vsync-demo was showing tearing on my system or wasn't smooth.
<ssvb> hglm: maybe you had scaler mode enabled?
<hglm> ssvb: Probably yes.
<techn_> ssvb: | 1920x1080-24@60Hz | 408MHz memory = ~840 MB/s write speed
<techn_> | 1920x1080-24@60Hz | 384MHz memory = ~430 MB/s write speed
<techn_> that is huge drop
<mnemoc> for merly 24Mhz
<techn_> ssvb: or how you can explain that?
<techn_> I have no other idea :/
<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.
<oliv3r> why isn't Allwinner in that list?1
<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.
<hglm> ssvb: I guess there were some bugs in the 4430.
<ssvb> yes, here are some more comments -
<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
<Turl> maybe wemac is stealing the missing MBs
<Turl> memory bw on ARM is comparatively tiny next to x86 systems
<Turl> except for chromebook that somehow manages to do 6GB/s :p
<libv> did anyone ever catch that serial reloading bug?
<libv> Turl: not sure
<Turl> libv: if you're not sure what's the bug like.. :)
<Turl> totally offtopic, but I just realised why do people use "--- >8 ---" as markers on emails and such
<libv> well, serial console dying upon loading of the kernel driver
<libv> strange thing is, it worked np on another image, and i transplanted the uImage and the modules 1-1
<Turl> libv: well, it's not that one then
<Turl> libv: maybe some misconfiguration on the other image, like not launching a login shell on ttyS0?
<Turl> or some funny init daemon disabling kernel logs somehow
<libv> would the latest linaro rootfs really be that broken?
<libv> as that is the only thing that is different
<Turl> I dunno
<libv> i doubt that it is that though
<Turl> libv: does it break too if you use a working one and dist upgrade it?
<libv> last two lines are the 8250 driver loading
<libv> that's my next move indeed
<Turl> libv: before 8250 loads you're using earlyprintk right?
<Turl> are you using the same cmdline on both?
<libv> hrm, not too certain, as i supposedly fixed image loading
* libv copies over the uboot start log, and tries the older sd card
<libv> ah, indeed
<libv> yup, bangon
<libv> Turl: thanks alot
<libv> boot.cmd didn't have ",115200"
<libv> and it now was actually passed directly.
<Turl> yw :)
<Turl> weird that you didn't get garbage though if it was running at a different speed
<libv> just went blank :)
hglm has quit [Quit: leaving]
tinti has quit [Ping timeout: 256 seconds]
<hno> 115200 / 9600 = 12. Can at worst give you some all-zero bytes.
<hno> or is it all-one bytes. Don't remember.
<hno> whish maybe gets read as serial break even.
<hno> or should.
<libv> do we actually have info on all nand installation? apart from the rather strange cubieboard one?
<hno> what do you mean?
<libv> how to partition and set up nand, with uboot, kernel, etc
<Turl> libv: you need the aw bootloaders to boot from nand don't you?
<libv> a7hd really is rather dogslow (now that i am used to odroid-x2)