2013-07-17

<ssvb> hglm: actually pixman has some yuv support, but it has poor an unusable API
<hglm> ssvb: OK, since I got started with NEON (for memcpy) maybe I will look into it.
<ssvb> hglm: but it did not seem like anyone was interested for real :)
<ssvb> hglm: not yet, there was an old discussion on the mailing lists about the potential users of native yuv support in pixman
<hglm> ssvb: It noticed you mentioned NEON support for xv in the commit log -- does pixman provide anything useful in this regard?
<hglm> ykchavan: I followed the "Debian from Debian guide". Just make sure you install proper networking connectivity before rebooting from the new rootfs.
<ykchavan> hglm, I have not created debootstrap earlier. I will go through steps and will come back if stuck anywhere.
<hglm> ykchavan: What you can also do is follow the debootstrap method with a Debian install already running on your device. I did it to create a Debian customized unstable rootfs from Wheezy.
<hglm> ykchavan: It is for cross compiling a whole rootfs on a x86 PC I think. Do you need it?
<hglm> ssvb: Maybe some cflags relating to requiring prototypes would help. The default Xorg cflags are very permissive in this area.
<hglm> I suppose it should be possible in principle to include visibility=hidden in all local definitions, but traditionally it seems all symbols are exported.
<hglm> ssvb: But it is related to the Xorg build-flags being extremely permissive and not catching errors.
<hglm> ssvb: Missing symbols were not flagged when compiling sunxifb, so the resulting X server crashed when running the module. Probably because of a missing new source file, yes.
<ssvb> hglm: you can get a missing symbol like wingrime reported, but that's because the new source file was just not compiled in
<ssvb> hglm: hmm, is this really so? never seen such problems
<hglm> When not properly rerunning autoreconf/configure when upgrading sunxifb you can also get crashes or other unexpected behaviour, which make sense I guess because the Xorg loadable modules does little error checking.
<hglm> ssvb: Interesting. I use NFS for light work (file sharing), so I didn't notice the performance regression, but I did see errors/stalls from the kernel NFS subsystem when copying large files (100MB). Not entirely sure this was on stage-3.4 or regular 3.4.
<ssvb> wingrime: thank hglm :)
<hglm> wingrime: Maybe it's a CPU frequency scaling issue? I had that too a few times (userland needs to properly set the CPU scaling thresholds, the default is very slow).

2013-07-12

<hglm_> orsic: Maybe the a10disp utility can be useful. It is a utility to change video mode in userspace. github.com/hgml/a10disp. You can try "a10disp info" to see what HDMI modes are available.
<hglm> zeRez: It's a notation for ARM assembler instructions that is compatible with both old and new ARM architectures. It looks almost the same as old syntax but is more flexible.
<hglm> zeRez: Try unified syntax (.syntax unified).
<hglm> zeRez: GNU as, like everywhere Linux.
<hglm> zeRez: To verify that the assembler works. But you may be able to test a compiled object file or binary in qemu.
<hglm> zeRez: You could run something like "armhf-...-as assembler.S -o assembler.o and then run armhf-...-objdump --disassemble assembler.o
<hglm> zeRez: Yes, you should be able to use a rpi vm. You can also cross-compile ARM assembler source files to ARM object files or executables with an ARM cross-compile toolchain.
<zeRez> hglm, but to learn basics of arm(asm), a simple rpi qemu vm should work also for me, isnt it?
<hglm> zeRez: Not sure, sounds difficult to me, qemu will need to know about the sunxi hardware. Maybe it requires a custom (minimal) kernel.
<hglm> zeRez: Maybe you can setup qemu not use a kernel image but just "interpret" assembler files (sort of debugging mode).
<zeRez> hglm, thats why i wanna run qemu with an arm image
<hglm> zeRez: I think it is easier to try asm on the native device.
<hglm> zeRez: Hi, tried assembler yet?
<hglm> zeRez: I think it is non trivial to run qemu on a sunxi kernel -- qemu needs to know how to deal with all the sunxi-specific hardware details I think.
<zeRez> hglm, hi :)

2013-07-11

<hglm> I am also thinking about making some contributions to the mainline kernel -- but they affect core functionality across multiple platforms so I have to be careful.
<hglm> utente: Thanks, performance can be improved a lot on small flash-based devices because most distros still enable all logging etc which is only needed for PC servers and kills performance on a small flash-based device.
<hglm> utente: Write back doesn't preserve ordering and delays and combines some writes I guess. It's less safe in case of a hard crash but not really bad.
<utente> hglm, what is the difference between the 2 modes
<hglm> See my blog at hglm.github.io for some more performance hints.
<utente> hglm, thanks.
<hglm> utente: You can change your ext4 filesystem from ordered data mode to write-back mode (which is faster) using tune2fs.

2013-07-10

<buZz> hglm: it worked before and not now .. something changed that tricked the linker into doing something bad, its fixed in newer binutils
<hglm> hramrach: OK, so it's not there yet.
<hglm> Looks like chromium-browser is present on Debian unstable (at least the package chromium-browser is available).
<hglm> On Cortex "char" on ARM is unsigned while some applications assume it is signed.
<hglm> buzz: It could be because of a difference in "char"
<hglm> oliv3r: that would probably be Chrome for android not chromium.
<hglm> Is chromium 27 supposed to work on ARM?
<hglm> But I think the A10/A20's G2D engine can theoretically be used for compositing (alpha blending), but if it does it would require some work to implement.
<hglm> Yeah dual core should work well in a Linux environment.
<zeRez> hglm, ok
<hglm> I have experience with a 3D engine running on Mali, and anything related to transparency slowed it down a low -- I think that's why GLES compositing is slow also on Mali. Mali is only meant for single-pass 3D rendering.
<hglm> zeRez: Just don't use compositing.
<zeRez> hglm, okay...so it only got trouble with composite/"big" desktops
<hglm> zereZ: When using A10 (or A20) a simple desktop is very usable, it is not slow with LXDE or XFCE.
<hglm> hrma: not true, sunxifb has some nice optimizations for dragging windows even without hw accel
<hglm> In my experience Mali is very slow when doing anything with transparency (compositing).
<hglm> ssvb: I see, nice that it uses GLES, but Mali400 isn't too fast anyway and not optimized for compositing.
<ssvb> hglm: gnome-shell is using gles compositing, and is handled in a somewhat suboptimal way
<hglm> ssvb: OK, so sunxifb's hardware blit gets used for compositing?
<ssvb> hglm: not quite software compositing, but still excessive memory copies in the case of gnome-shell
<hglm> hramrach: You are probably benchmarking software-compositing, which would be slow on any system.
<hramrach__> hglm: it is good when it runs gnome. now it crawls gnome
<hglm> hramrach: A10 is not that bad, for an older single core it runs pretty well, much faster than RPi.
<zeRez> hglm, okay :)
<hglm> hramrach: OK, then rk3188 could be usable with Linux in the future.
<hglm> zeRez: I have a standard A10 tablet (1GB) which works pretty well, also have a RPi.
<hramrach__> hglm: the rk3066 cannot boot off SD which sucks but they fixed that with rk3188
<zeRez> hglm, which devices you are working with?
<user_2> hglm, unfortunately, cubie came only wit allwinner.
<hglm> user_2: Rockchip has had a faster dual core at lower geometry out for quite a while used in millions of Android tablets (just like A10 has been for single core). I guess A20 is targeted at low-end.
<zeRez> hglm, ahh nice...so i can inspect my object files with it on assembly to know what the compiler does with my code? :)
<user_2> hglm, im not telling this to talk bad, only to report what one told me. when i will have my A20, i will be able to test and report by mysel what happen to me.
<hglm> zeRez: Yeah it helps to know how C code compiles to asm. Try objdump --disassemble <objectfile.o>
<hglm> user_2: If the CPU is idle even the A20 at 55nm should not be hot, maybe power-management is broken.
<zeRez> hglm, iam at the very beginning...learning about the processor and how it works...but hope to write my first lines of asm next days :)
<hglm> zeRez: Yes, I did x86 asm a long time ago. But ARM asm is not difficult to learn if you already know some other assembler.
<zeRez> hglm, do you have experience also with x86 asm? ask because iam at the beginning to learn and intrested in ppl also coding asm ^^
<hglm> Does Allwinner have anything in the pipeline at lower geometries? Rockchip does but they're not too Linux-friendly at the moment.
<hglm> zeRez: Yes, recently I have done some asm work in ARM, it is not too hard. You can optimize for Thumb2 mode too (reduced code size). Make sure you use the right directives in your .S files declaring the function.
<zeRez> hglm, searched for free books as well....found some pdfs on internet...think it will be enough to start. Doy you have experience in arm asm or asm at all?
<zeRez> hglm, thanks for hint but got them yesterday
<hglm> zeRez: The ARM website has a lot free ARM assembler info -- you can print some quickreference guides.

2013-07-06

<hglm> Turl: But I don't know how to connect serial to my tablet :) USB to serial won't work I think.
<Turl> hglm: well, you could use serial if you have access to that
<hglm> I was thinking of experimenting with a mainline kernel, but since that doesn't yet have disp or USB support, I guess on a tablet I won't be able to see/confirm anything, correct?
<hglm> vrga: I run my tablet connected to power, except when shutting down because if you don't remove power it will reboot instead of shut down.
<vrga> hglm, kk
<hglm> vrga: I don't think so, dev boards have no battery, so support for batteries is not a priority.
<hglm> vrga: OK, I installed a new version of Debian the other day, and was look everywhere for why it was slow, but I had forgotten to change the cpufreq settings, which fixed the slowness :)
<vrga> hglm, i know :)
<hglm> vrga: The default powersave/cpufreq options are a little aggressive, the min CPU speed is only 60 MHz. You can increase that to 400 MHz for better performance (max speed is 1000 Mhz of course).
<hglm> vrga: Nice :)
<vrga> hglm, it works.
<hglm> vrga: OK, then you have to use stage/3.4, shouldn't give problems I think.
<hglm> vrga: stage/sunxi-3.4 contains the latest changes but they might be a bit experimental. sunxi-3.4 hasn't been updated for a while but does contain the updated wlan drivers.
<vrga> hglm, whats the difference between stage/sunxi-3.4 and normal sunxi-3.4
<vrga> hglm, kk
<hglm> vrga: Whatever the purpose of a13_nuclear_defconfig is, you don't want to pick it because for example it disables the console framebuffer.
<hglm> vrga: You can't be sure from looking at the defconfig file (which only has additional options), you have to run the kernel config to see the options selected.
<hglm> vrga: You should just pick the a13 defconfig and run nconfig yourself to enable the 8188eu driver.
<hglm> vrga: My guess us a13_nuclear only includes essential drivers (i.e. probably no wlan).
<vrga> hglm, you know whats the diff between normal and nuclear stuff?
<hglm> vrga: That's fine.
<hglm> vrga: If you are compiling sunxi-3.4 make sure you are using a gcc-4.7 linaro toolchain. stage/sunxi-3.4 branch should also work with latest gcc 4.8.
<hglm> vrga: OK, maybe because github reworked the repo interface recently (still buggy).
<vrga> hglm, finally managed to get the proper kernel sources in -.-
<hglm> vrga: you can download just one branch or even just an archive file.
<hglm> vrga: Not really, but when people fork the linux source it creates pretty big repo's and it's not really economical :)
<hglm> vrga: Probably has the whole linux git history from 2.x to 3.mainline.
<vrga> hglm, yeah, 2 months ago :p
<hglm> vrga: I think the 8188EU driver was updated and tested recently ( a few months ago), so you should OK I think.
<hglm> vrga: https://www.miniand.com/forums/forums/development/topics/debian-wheezy-lxde-armhf-build has some info about rtl8188eu not working with 3.4.x and needing a special 3.0.x kernel image, but it's old info.
<hglm> vrga: something like that.
<hglm> vrga: github.copm/linux-sunxi.git branch sunxi-3.4
<vrga> hglm, how do i get the 3.4 sunxi sources?
<hglm> vrga: But I think there used to be problems with 8188EU in 3.4.x.
<hglm> I have an 8188EU driver in 3.4.43+: # CONFIG_RTL8188EU is not set
<hglm> vrga: 8188eu should be support I think, check the kernel driver is enabled, there were some problems with 3.4 earlier but 3.0 was supported.
<vrga> hglm, so, what now?
<hglm> vrga: Looks suspiciously like you do have an 8188eu.
<vrga> hglm, android now lists both 8188eu and 8192cu modules.
<hglm> vrga: I think most people use the Linaro toolchain to compile the kernel.
<hglm> vrga: rootfs + kernel, different SD card image. At least to verify that the wlan works in linux-sunxi.
<hglm> vga: Not sure, trying a different image maybe?
<vrga> hglm, so, what else am i left with now?
<hglm> vrga: 8192cu is the wlan for sure, rlt8150 is probably some of USB bridge or something else small.
<hglm> vrga: Must be a 8192cu then.
<vrga> hglm, no.
<hglm> vrga: I guess nandj doesn't have the module info?
<hglm> vrga: I would help to find out the driver Android is using to confirm things.
<vrga> hglm, i can try getting that driver in.
<hglm> vrga: A possibility is that your wlan chip might not be a rtl8192cu but something like rtl8188EU.
<hglm> vrga: Main thing is the LCD of the tablet should work and be the default video output with the tablet's script.bin.
<vrga> hglm, well, the good news about my script.bin, the difference were almost minimal.
<vrga> hglm, heh
<hglm> vrga: OK, I had it easier it was rooted OOTB I think.
<vrga> hglm, if my android was rooted, it would be a lot easier.
<hglm> vrga: checking out the exact module used for wlan in Android would help identify the exact rtl wlan chip.
<vrga> hglm, yeah. should be but nandb through nandi show as without any sort of partition table.
<hglm> vrga: I am not clued in regarding Android fs, although I thought they mainly use ext4.
<vrga> hglm, just as a side note, which filesystem should the nandx be? i'm having a hard time mounting anything other than nanda
<hglm> vrga: While you're at it check out the wlan module android uses (should also be 8192cu.ko).
<hglm> vrga: I am using the tablet's script bin but customed the kernel command line in boot.cmd/.scr.
<hglm> vrga: Yes, I thought so, it shouldn't really make a difference but not sure. If the "sw-ehci" line isn't showing something may be wrong though.
<vrga> hglm, sw_ahci_platform would be a sata driver, no?
<hglm> vrga: I have an A10.
<hglm> vrga: I have sw_ahci_platform as first line in /etc/modules, maybe that is required.
<vrga> hm. hglm, you got a fex for me to compare?
<vrga> hglm, nope.
<hglm> vrga: Looks ok, it should also say "usb 4-1: new high-speed USB device number 2 using sw-ehci" below that.
<vrga> hglm, this is pretty much the only thing getting spat out Jul 6 16:06:34 localhost kernel: [ 20.240000] usbcore: registered new interface driver rtl8192cu
<hglm> vrga: dmesg is more relevant regarding detection of USB devices.
<hglm> vrga: I think lsusb bypasses the kernel USB interface and uses its own userland USB probing, it says RTL8188CUS on my system but I'm pretty sure I have 8192CU.
<vrga> hglm, lsusb -v and looking for the 8192 device should show you the same thing i think
<hglm> vrga: Sorry, I don't have udev logging enabled it seems so I can't compare.
<vrga> /var/log/udev on my system, hglm
<hglm> vrga: I want to check the udev log on my system (tablet with 8192cu), how do you view it?
<vrga> hglm, there's this tidbit in udev log http://pastebin.com/egBzZB30
<hglm> vrga: May be check the dmesg log to see what the 8192cu driver says?
<hglm> vrga: Maybe add 8192cu.ko to /etc/modules so it is loaded at boot time (and the Debian module init service should be installed).
<vrga> hglm, if you have any other ideas other than the most obvious, basic ones, i'd be more than happy to try them.
<vrga> also, hglm, please, please read both things i wrote.
<hglm> vrga: Is the module loaded? Try lsmod.
<vrga> hglm, irrelevant as i cannot get wlan0 interface around in the first place.
<hglm> vrga: Is /etc/network/interfaces properly configured?
<hglm> vrga: does running iwlist wlan0 scanning return a list of WiFi channels?
<hglm> tremun: Does X work or not?
<hglm> Yaku: Probably, but you need the userland WLAN tools to use the driver.
<hglm> Yaku: One alternative would be to manually transfer debian .deb files for wireless-tools and wpasupplicant and then install them from the package file.
<hglm> Yaku: Then you have a problem, you need those for WLAN net access.
<hglm> Yaku: it should be installed as /sbin/wpa_supplicant
<hglm> Yaku: Just type it, or type wpa_supp and then press TAB to see whether the command exists.
<hglm> Yaku: Try running 'wpa_supplicant" to see whether it is installed.
<hglm> Yaku: Do you have the wpa_supplicant daemon installed?
<hglm> Yaku: But it shouldn't matter anyway if you are root.
<hglm> Yaku: Sorry, it means there's problem with sudo.
<hglm> Yaku: That means iwlist is installed on your system, but you other problems.
<hglm> Yaku: I assume you are trying to run iwlist as root or with sudo?
<hglm> Yaku: Have you installed wpasupplicant?
<hglm> Yaku-noob: Use something like 'iwlist wlan0 scanning' to verify the kernel wlan driver is working. Make sure the right module for your wireless chip is loaded. Maybe edit /etc/modules.

2013-07-05

<ssvb> hglm: so one needs to know the exact cache line size in order not to corrupt data :)
<ssvb> hglm: MIPS has PrepareForStore prefetch, but it is a bit dangerous because it discards the data from the cache line
<hglm> ssvb: Good to know that.
<ssvb> hglm: PLDW does regress memset performance significantly
<hglm> ssvb: So it does not help when implemented in (say) memset? Maybe it depends on the particular details of the L2 cache architecture.
<ssvb> hglm: they added this instruction to ISA (probably as reserved for future use), but none of the real CPU cores manages to benefit from it
<hglm> ssvb: I guess so, preload stuff always needs to be benchmarked carefully.
<ssvb> hglm: that's what happens when one is coding from the book and doesn't verify the results
<ssvb> hglm: I have seen some people who managed to use it to regress the performance significantly on Cortex-A9 :)
<ssvb> hglm: yes, such instruction exists
<hglm> ssvb: Did you know that ARM7MP (i.e. Cortex A7 used on A20) has a "Preload to write" instruction? Maybe that's what is required to get optimal memory throughput on A20.
<pirea> hglm cpu is set on performance
<hglm> pirea: Maybe you are seeing the effect of CPU frequency scaling. If little CPU is used, CPu runs at 60 MHz or 400 Mhz or whatever your cpufreq configuration is, giving erreonous CPU load stats.
<ssvb> hglm: the framebuffer mali drivers have zero cpu usage when waiting for vsync and running simple gles demos
<hglm> Maybe the Mali driver does busy-waiting when executing SwapBuffers waiting for vsync.
<pirea> hglm this is happening when i am not playing videos
<hglm> pirea: I don't think xbmc can use opengles for video acceleration, you are probably seeing xbmc using 100% CPU video decode.
<ssvb> hglm: g2d has some sort of a weird memory allocation ioctl api, which is simply too bad to be used
<hglm> ssvb: I thought so, so you disable it and still enable G2D in sunxifb I guess. Must be a relic from Allwinner Android.
<hglm> But you have to be careful that your userland environment knows how to deal with Thumb2 code.
<oliv3r> hglm: your right: http://linux-sunxi.org/ARM/Thumb-2
<hglm> oliv3r: I don't think that really makes sense, thumb2 is a different instruction set.
<hglm> ok, -mthumb should work. But it may depend on another things in archlinux userland.
<pirea> hglm i use archlinux arm crosscompiler
<hglm> pirea: thumb2 is default when you compile C code on Debian/Ubuntu

2013-07-04

<hglm> There are even some Thumb2-only CPUs that are supposed to be supported I think.
<hglm> Turl: Possible, but it must have been working in the past looking at work that was done for it.
<Turl> hglm: or maybe thumb2 is broken and nobody noticed because nobody uses it :p
<hglm> Turl: So that's on mainline. Some sunxi-specific part that is present in mainline must be broken for thumb-2 then?
<hglm> rz2k: Yeah it would be useful to see where it fails. I could also try disabling most drivers.
<hglm> rz2k, no I don't. I am not very experienced with remote debugging.
<hglm> rz2k:I only have a tablet, USB serial console gives no output but it is probably too late in the booting process.
<rz2k> hglm: hno attached OpenOCD jtag via ftdi2232, iirc. other OpenOCD supported adapters should work too
<rz2k> hglm: any chance for you to attach jtag?
<hglm> wingrime: I have the same experience with a Thumb2 kernel, it compiles but doens't boot, no console output. I think Thumb2 kernel has never worked for linux-sunxi. I added some comments to the wiki about this (http://linux-sunxi.org/ARM/Thumb-2#Status_of_Thumb-2_support_for_linux-sunxi). Userland Thumb-2 seems to work fine.

2013-07-03

<ssvb> hglm: otherwise the test results would be too boring, and no funny flamewars in the forums
<ssvb> hglm: but that's phoronix, they deliberately use different compilers in tests, never pay attention to throttling, etc :)
<ssvb> hglm: regarding arm vs. thumb2, I think gentoo has beaten crap out of ubuntu in one phoronix test, partially thanks to gentoo still using arm mode - http://www.phoronix.com/scan.php?page=article&item=gentoo_linaro_odroid&num=6
<hglm> ssvb: I guess 64-bit would need a whole new thumb instruction set.
<ssvb> hglm: 64-bit ARM ISA does not have any thumb counterpart yet (any sort of variable length instructions encoding for code size reduction)
<hglm> thumb2 does seem to be the way forward with ARM to the point of some ARM processors only supporting Thumb2 and not ARM mode.
<ssvb> hglm: and the reduction of I-cache misses may be indeed very good for lower consumption
<ssvb> hglm: that's what they are writing in their advertisement materials (they can't write that their super-duper new feature is crap, do they?)
<hglm> ssvb: Yes, I am running debian which has thumb2 userland, and optimizing my experimental memcpy function shows a slight benefit to thumb2 in optimized asm. But I haven't really tested larger benchmarks that are affected by C compiler quality.
<hglm> ssvb: thumb2 is supposed to help with power consumption, maybe it's specific to cpuburn.
<ssvb> hglm: have you tried to run some benchmarks for arm vs. thumb2?
<ssvb> hglm: maybe the thumb2 instruction decoder in cortex-a8 was not properly optimized for lower power consumption
<ssvb> hglm: this seems to be cortex-a8 specific, because cortex-a9 and cortex-a7 are rather neutral to arm/thumb2 mode selection in this respect
<ssvb> hglm: but at least thumb2 is good for getting measurably higher power consumption in cpuburn :)
<geecko> ssvb, hglm, can i use sun4i_defconfig without any problem?
<hglm> ssvb: point taken, and I agree on the compiler quality affecting Thumb2 code (Thumb2 has some clever new instructions/instruction combinations that can be used to speed things up). Maybe gcc 4.8+ improves on this.
<ssvb> hglm: but even in the userland, thumb2 heavily depends on the compiler code generation quality (sometimes it is good, sometimes it is not so much)
<ssvb> hglm: the kernel itself is not that large, and I prefer it to be as much stable as possible because debugging it is a pain
<hglm> ssvb: OK, but from limited testing I get the impression that it could bring some benefits in real-world performance (old thumb gives it a bad reputation). Benchmarks that fit in the L1 cache won't show much difference, but for large memory footprints (such as real-world usage) using Thumb2 might be faster.
<ssvb> hglm: no, imho it is not worth the effort
<geecko> ssvb, hglm, will the inux-sunxi 3.4 kernel work without any modification on a oLinuXino board?
<hglm> ssvb: Do you have experience with kernels compiled with Thumb2? It doesn't seem to work on sunxi.
<hglm> geecko: Possible, the latest stable 3.0 may also support those options. But generally I think 3.4 is preferable.
<geecko> hglm, do you think it is also available on kernel 3.0? https://github.com/linux-sunxi/linux-sunxi
<hglm> geecko: Probably, but you may have to upgrade from 3.4.29 to 3.4.43 if the image has 3.4.29.
<geecko> hglm, so i have to update the kernel to 3.4
<hglm> geecko: Probably that version of linux-sunxi doesn't support the reserved memory disable options.
<hglm> geecko: What kernel version are you using? (cat /proc/version)
<geecko> hglm, didn't work ;_;
<hglm> Also http://linux-sunxi.org/FirstSteps has this info, better use this one.
<geecko> hglm, nice, thank you
<hglm> See http://linux-sunxi.org/Building_on_Debian for an example boot.cmd, it also shows the mkimage command to convert boot.cmd to boot.scr.
<geecko> hglm, but i don't know the default arguments...
<hglm> You have have to add them to the setenv bootargs line (the kernel arguments)
<geecko> hglm, can i put a boot.cmd file containing:
<hglm> geecko: Your Debian image may not support uEnv.txt yet, but editing boot.cmd and converting it to boot.scr will work.
<hansg> hglm, IIRC for uEnv,txt to work, some extra stuff is needed in boot.cmd, it was a while ago I put this all together for the Fedora images..
<hglm> Using uEnv.txt is not explained anywhere on the wiki, it would be a nice addition. The only info is about boot.scr/boot.cmd.
<hglm> atiti: I get the same on normal boots but below it is says it succeeds mounting as ext4, so the root fs may be mounted correctly.
<oliv3r> hglm: usb to serial or uSD to serial
<hglm> Is there any way to get early kernel messages from a kernel that doesn't boot (no video output) on a tablet? Do you need to use a USB-to-serial converter?
<geecko> hglm, oliv3r, awesome
<oliv3r> oh hglm muxch much better
<hglm> I have been looking for references of a working Thumb2 *kernel* for sunxi but haven't found one -- it should work in principle but I think there must be a non-compliant piece of code in the sunxi-specific part of the kernel that fails on Thumb2.
<hglm> rm: In my experiments Thumb2 doesn't seem to have much downsides -- it's a little faster. Of course it also depends on the compiler used because Thumb2 has some extra instructions and a few instructions are different.
<hglm> rm: I think almost everything is Thumb2 compiled.
<hglm> Only thing missing is a kernel compiled in Thumb2 mode, when trying it compiles OK (with gcc 4.8) but doesn't seem to boot.
<hglm> I was surprised to find Debian's armhf userland is already using Thumb2 mode, which results in 20-30% smaller code size than ARM mode and performs better (less cache misses etc).

2013-06-29

<hglm> You can also use Debian (on which Ubuntu is based), there are Debian images that use LXDE as wm.

2013-06-27

<hglm> OK, I'll check the latest stable 3.4 upstream release to see whether it has the fix.
<ssvb> hglm: maybe we should also check the newer point releases of the stable 3.4 kernel
<hglm> It would be useful for linux-sunxi to backport the fix to be able to use gcc 4.8.x.
<hglm> Turl: Maybe that's because mainline already incorporates the fix that is mentioned in the link ssvb posted.
<hglm> I succesfully compiled and booted sunxi-3.4 with gcc 4.8 -- I did apply a patch which fixes a bug in memset which may be the reason it works. I did not verify whether sunxi-3.4 compiled with gcc 4.8 works without the patch.

2013-06-24

<hglm> ssvb: That's good, when I looked at it a few versions back it seemed gcc was broken in performing some trivial loop optimizations etc.
<hglm> I guess there are a lot of variables in the toolchain etc, and a trivial alignment change would make a big difference, but still zImage is supposed to be pure code.
<hglm> The zImage produced by gcc 4.8 is 5K smaller than gcc 4.7, proof of better optimization?
<hglm> ssvb: Ah, didn't know that about perf.
<ssvb> hglm: adding "-e cpu-clock" option will make perf use the generic timer
<hglm> ssvb: Well perf only supports hardware performance counters, and OProfile does also support hardware performance counters. But the ARM hardware apparently doesn't.
<ssvb> hglm: oprofile is out of fashion nowadays :) everyone is supposed to use perf
<hglm> ssvb: BTW, I used your OProfile patch wih good results on the RPi platform. I do get a "sample buffer overflow" warning now and then.
<hglm> hglm: Yeah it seems to be some kind of dependency issue.
<ssvb> hglm: I think the mali module might be not parallel build friendly and may trigger spurious failures (don't remember if I have seen this information somewhere or it was just my guess)
<hglm> I am now trying to compile the kernel with gcc-4.8, there seems to be a problem with drivers/gpu/mali...but running make again fixes it.
<hglm> I will try experiment with compiling the kernel with a newer gcc version -- I have already fixed the memset bug so maybe it will work.
<hglm> But the assembler memset function doesn't return any sane value.
<hglm> The problem is that the assembler memset function has a C prototype returning a void * (not void) that gcc expects to hold the destination address of the memset call following memset specifications.
<hglm> I was think it might have to do with the ARM memset bug which is related to C-compiler optimizations...
<hglm> What is the reason gcc 4.8+ cannot be used? Is there a known problem?
<hglm> Does anyone know what the current situation is with respect to the gcc version (linaro for example) used to compile linux-sunxi? gcc-4.8+ doesn't work?
<hglm> It helps the X server too (the X server process gets run in parallel and becomes sort of CPU-based accelerator).
<hglm> ssvb: Still, the dual cores should still make it a lot faster in practical use compared to A10.
<ssvb> hglm: yes, A20 needs to use SCU, which adds a bit to the latency and makes memory subsystem somewhat more complex
<hglm> ssvb: I guess the L2 cache is the main reason (different method due to multiple cores) for the reduction in peak memory bandwidth.
<ssvb> hglm: the cache in Cortex-A7 is write-allocate by default, but can switch to read-allocate mode automatically
<ssvb> hglm: the effectively available memory bandwidth in A20 seems to be much worse than for A10, maybe some special tricks are needed, but I have not figured it out yet
<ssvb> hglm: the preload instructions are necessary to get good performance on A7 as the automatic prefetcher seems to be of limited use
<hglm> ssvb: I understand, when the source stride is bigger than the width of the image, the A7 will constantly prefetch data that isn't used...I guess preload instructions won't help to counter that.
<ssvb> hglm: and the automatic prefetcher in A7 seems to track only a single data stream, based on the description - http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464e/CHDIGCEB.html