| 00:44.45 | xxiao | "We want to talk with you. We are hiring hundreds of entry- and mid-level cyber professionals from across the US now!" |
| 00:45.19 | xxiao | linkedin hiring inmail |
| 00:45.50 | xxiao | "Engage in full-spectrum cyber operations. Work side-by-side with elite military and cyber professionals." |
| 00:51.36 | *** join/#arm-netbook Turl (~Turl@2606:3f00:60:21c:d00d:c0de:4:f00d) |
| 01:01.30 | *** join/#arm-netbook WarheadsSE (~WarheadsS@c-174-59-252-104.hsd1.pa.comcast.net) |
| 01:01.30 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 01:02.05 | Turl | mnemoc: fuu gotta adjust all of the remotes now >.< |
| 03:04.09 | *** join/#arm-netbook tekzilla (~jon@hmbg-5f764cbf.pool.mediaWays.net) |
| 03:19.16 | Turl | RaYmAn: ping? |
| 04:01.23 | *** join/#arm-netbook QingPei (~qingpei@114.217.185.222) |
| 05:12.41 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 05:17.43 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 05:19.21 | *** join/#arm-netbook Quarx (~Quarx@46.233.244.74) |
| 06:17.41 | *** join/#arm-netbook bsdfox\ (~Bob@c-71-197-83-152.hsd1.ca.comcast.net) |
| 07:13.20 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56154.dip0.t-ipconnect.de) |
| 07:47.41 | *** join/#arm-netbook QingPei (~qingpei@114.217.185.222) |
| 07:54.17 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 08:03.57 | RaYmAn | Turl: ? |
| 08:07.24 | jelly-home | are YOU a cyber professional |
| 08:08.59 | orly_owl | we all are |
| 09:21.46 | mnemoc | Turl: tell me about it.... I have over a dozen of different working trees :< |
| 09:23.13 | mnemoc | Turl: and need to setup some mirroring to ease the transition |
| 09:24.49 | mnemoc | what do you think about 'allwinner-v3.0-android-v2' renamed to 'sunxi-3.0'? |
| 09:25.39 | mnemoc | hno: will u-boot follow? :) |
| 10:02.11 | *** join/#arm-netbook cromo (5efbfb70@gateway/web/freenode/ip.94.251.251.112) |
| 10:04.12 | hno | mnemoc, to the shared organisation? Sure, will push a stable release there in a couple days. |
| 10:04.19 | cromo | I compiled the newest xbmca10 yesterday to try out how it works under 1080p, but it behaves strange - the xbmc theme picture seems properly scaled to 1080, but the visible area is still cropped to 720, with rest of it being black. Anyone tried it yet and can confirm that? |
| 10:04.54 | lundman | the new 1080p code didnt work for me |
| 10:06.10 | cromo | and what were the symptoms? |
| 10:06.14 | cromo | same as mine? |
| 10:07.43 | lundman | actually, mine didnt want to start when i set script to 1080p |
| 10:07.55 | lundman | the manual code change 2 weeks earlier did work fine though |
| 10:08.18 | cromo | the script.bin you mean? I used the a10_display tool |
| 10:08.31 | lundman | oh |
| 10:08.36 | lundman | yeah I change script.bnin |
| 10:08.43 | cromo | not sure if that makes any difference though |
| 10:09.09 | mnemoc | script.bin is .... safer, as your choice is the default from start |
| 10:09.23 | mnemoc | dynamic changes may trigger bugs |
| 10:09.45 | mnemoc | f* google, f* linaro/android! |
| 10:09.51 | cromo | mnemoc: and so it appears that the dynamic change to 1080 does not change entirely _everything_ |
| 10:10.01 | mnemoc | cromo: poke techn :) |
| 10:10.01 | lundman | ye |
| 10:10.11 | mnemoc | cromo: he is the sunxi-disp maintainer |
| 10:10.37 | lundman | i have a 1080p script.bin on ftp |
| 10:11.02 | mnemoc | lundman: please share patches, not full .bin ... as they aren't cross-device |
| 10:11.13 | lundman | huh? |
| 10:11.27 | mnemoc | fex to fex diffs |
| 10:11.37 | lundman | the instruction for bin->fex->bin is well documented |
| 10:11.53 | mnemoc | sure, but people will try to inject yours anyway |
| 10:11.54 | lundman | but if he has a a2000 and want a faster test, i have the bin for it |
| 10:12.00 | mnemoc | true |
| 10:12.24 | cromo | lundman: would you mind trying to boot 720, switching dynamically to 1080 and then observing the result with xbmca10? |
| 10:12.47 | lundman | doubt that works, if you look at the source to read resolution |
| 10:12.51 | lundman | also, mele is at work :) |
| 10:13.37 | cromo | lundman: I didn't look at the source much, I assumed it reads the fb resolution? |
| 10:13.52 | oliv3r | anybody messed with the linux livesuit build yet? I got 'unsupported OS' but worked around that. working out how to get from the DKMS -> working kernel module now. See http://linux-sunxi.org/Builroot bottom paragraph for what i did so far |
| 10:13.57 | cromo | besides, it actually does start and from the xbmc logs I can see it detects the 1080p correctly |
| 10:14.22 | mnemoc | oliv3r: please move that to [[livesuit]] |
| 10:14.32 | cromo | lundman: I have a1000, I think it's the same as a2000? |
| 10:14.36 | mnemoc | yes |
| 10:14.39 | oliv3r | good point |
| 10:14.52 | oliv3r | can you undo my change? |
| 10:15.11 | mnemoc | it would harm your karma :) |
| 10:15.35 | oliv3r | can i undo it myself? |
| 10:15.40 | mnemoc | yes |
| 10:17.06 | mnemoc | stupid android kernel maintainers decided to truncate and diverge their 3.4 branch. f* them all |
| 10:17.37 | mnemoc | aaaaaarghh |
| 10:18.23 | oliv3r | done |
| 10:18.24 | oliv3r | moved |
| 10:18.27 | oliv3r | gone for now :) |
| 10:18.53 | lundman | https://github.com/empatzero/xbmca10/commit/251b6e321fd3b7c0cf9ffc7dff320630d19355a7 |
| 10:20.59 | hno | mnemoc, pleae gibe u-boot a spin again. Have restructured the SPL quite a bit, making use of the common SPL framework now available. |
| 10:23.46 | mnemoc | hno: sunxi or wip/update ? |
| 10:27.28 | *** join/#arm-netbook eFfeM (~frans@dhcp-077-251-240-021.chello.nl) |
| 10:37.23 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 10:46.46 | orly_owl | any a10 based nas/raid units available? |
| 10:47.42 | lundman | :) |
| 10:47.52 | orly_owl | that smile means no |
| 10:47.55 | orly_owl | |: |
| 10:47.56 | mnemoc | with only one sata? |
| 10:47.57 | lundman | want a a10 kernel with zfs built in? |
| 10:48.18 | orly_owl | mnemoc: how many sata ports does a10 support? |
| 10:48.22 | mnemoc | 1 |
| 10:48.24 | lundman | 1 |
| 10:48.37 | orly_owl | ok then |
| 10:48.39 | lundman | 5-4 |
| 10:48.52 | lundman | plus usb though |
| 10:48.58 | orly_owl | true |
| 10:49.13 | orly_owl | not sure how good a usb nas/raid would be |
| 10:49.18 | orly_owl | im thinking 4 hdd |
| 10:49.35 | mnemoc | if you connect an external raid device which emulates a single sata, you can have a NAS :) |
| 10:49.37 | orly_owl | any other socs/chipsets that are good for this then? |
| 10:49.43 | hno | mnemoc, sunxi |
| 10:49.57 | orly_owl | that external raid device would have a chipset or a soc though |
| 10:50.02 | lundman | yeah a little 5 sata port card would be nice |
| 10:50.10 | *** join/#arm-netbook ZaEarl (~malmrose@202.155.242.30) |
| 10:50.13 | lundman | or 6 |
| 10:51.00 | orly_owl | a pcie card? |
| 10:51.03 | hno | it's mainly storage processors that have that many SATA ports in this segment. But those are SoCs as well. |
| 10:51.19 | mnemoc | my raid1 has a JMB352 inside and works nicely |
| 10:51.25 | lundman | nothing stopping them from making one for us |
| 10:51.33 | orly_owl | them? |
| 10:51.42 | hno | lundman, connected to what? |
| 10:51.43 | lundman | the magic fairies, or whatver |
| 10:52.04 | lundman | a10 board with 6 sata would be useful |
| 10:52.08 | lundman | its not useful now ;) |
| 10:52.26 | mnemoc | the imx6q support >1 sata iirc |
| 10:56.48 | *** join/#arm-netbook cromo (5efbfb70@gateway/web/freenode/ip.94.251.251.112) |
| 10:57.13 | cromo | The /sys/class/graphics/fbcon/subsystem/fb0/modes shows U:1280x720p-60 after dynamically changing the resolution with a10_display tool to 1080p. Is this normal? |
| 10:58.31 | rz2k | cromo: 1080p in native linux is not supported due to mess in sunxi-disp. |
| 10:58.38 | rz2k | max you can get is 720p |
| 10:58.50 | rz2k | 1080 will be 720 in left-upper corner |
| 10:58.52 | cromo | I think this could be the reason for xbmca10 to misbihave - the hdmi out is 1080p, xbmca10 correctly detects the 1080p, but the fb is still limited to 720p |
| 10:58.58 | cromo | yep |
| 10:59.00 | cromo | exactly that |
| 10:59.05 | lundman | you nailed it |
| 11:00.47 | cromo | so how come booting straight away with 1080 (via script.bin) make any difference? |
| 11:00.49 | rz2k | cromo: if you have time & knowledge, you can debug disp modes and find why this happens. also 1080p in android works for some reason. |
| 11:01.17 | cromo | becasue I assumed it does from empat0's commits |
| 11:01.17 | rm | 1680x1050 over VGA does work |
| 11:01.46 | rm | but you absolutely have to set the resolution in script.bin |
| 11:01.54 | cromo | time, yes, knowledge - not sure, most of my programming experience comes from high level languages |
| 11:02.01 | rm | all those silly knobs (fbset, xrandr, xorg.conf....) they do nothing |
| 11:03.16 | rm | (silly to Allwinner, I assume) |
| 11:03.24 | rm | but you still have to set the same res everywhere |
| 11:03.48 | cromo | I am really tempted to switch to odroid-x |
| 11:03.50 | rm | only that script.bin is the most important place, without the resolution set there, you will get all kinds of silly effects |
| 11:04.13 | lundman | ahh so its not just me interested in odroid-x |
| 11:04.35 | rz2k | odroid doesnt have 3d acc. in native linux, afaik. |
| 11:04.49 | rm | $129.00 pft |
| 11:04.55 | cromo | this also looks interesting: http://www.cnx-software.com/2012/10/10/droid-stick-a2-amlogic-aml8726-mx-dual-core-android-4-1-1-mini-pc/ |
| 11:04.56 | lundman | why do we need 3d |
| 11:04.57 | rm | switch to Cotton Candy while you are at it |
| 11:05.02 | rz2k | xbmc? |
| 11:05.09 | rm | $40 device vs $130 device |
| 11:05.25 | lundman | nah not interested insticks, no ether |
| 11:05.37 | lundman | but then, the new allwinner mentioned in here sounds good |
| 11:05.56 | cromo | hmmm |
| 11:06.09 | cromo | what chip does the cotton candy use? |
| 11:07.46 | cromo | hmm, 199$ |
| 11:10.06 | rz2k | considering dual core arm and mali400 it is old exynos |
| 11:11.28 | hno | rz2k, xmbc do not "need" 3d. But is nicer with it. |
| 11:12.13 | cromo | rz2k: it's single core arm I think |
| 11:16.09 | mnemoc | for a media center the having more arm cores shouldn't affect anything |
| 11:16.22 | mnemoc | the important things are made by the VPU and GPU anyway |
| 11:17.40 | mnemoc | anyone wants to dive into fixing usb on 3.4? :< ... now there is a bug report about a panic merely conencting a usb storage :'( |
| 11:33.42 | cat1 | mnemoc: i made an attempt to reproduce the problem but in my case it did not go any further than this: |
| 11:33.42 | cat1 | [ 58.390000] ehci_irq: port change detect |
| 11:33.42 | cat1 | [ 58.450000] The port change to OHCI now! |
| 11:33.42 | cat1 | [ 58.750000] usb 3-1: new full-speed USB device number 2 using sw-ohci |
| 11:33.42 | cat1 | [ 58.900000] usb 3-1: device descriptor read/64, error -62 |
| 11:33.42 | cat1 | suspect some power shortage, need to measure.. |
| 11:35.49 | mnemoc | ouch |
| 11:36.12 | mnemoc | btw, I'm renaming the main branches to sunxi-3.0 and sunxi-3.4 |
| 11:36.51 | mnemoc | amery's repo will keep a mirror with the old name for some weeks, the ease the transition |
| 11:36.55 | mnemoc | names* |
| 11:37.18 | mnemoc | tried with a Y usb cable? |
| 11:37.22 | mnemoc | to feed power |
| 11:39.37 | cat1 | nope, i am afraid i have some very ancient external usb hd that behaves similarly on my wife's laptop too.. |
| 11:42.26 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 12:10.06 | *** join/#arm-netbook tuliom (~tuliom@177.133.171.160) |
| 12:10.52 | *** join/#arm-netbook vgrade_ (~martin@cpc2-nrte22-2-0-cust128.8-4.cable.virginmedia.com) |
| 13:25.17 | cat1 | mnemoc: regarding that usb problem: what is that kernel version Linux version 3.4.12-apx6+? I do run Linux version 3.4.12+ and dmesg looks significantly different.. and btw no problem mounting usb hdd whatsoever. |
| 13:34.01 | mnemoc | good point |
| 13:34.07 | mnemoc | can you comment about it on the ticket? |
| 13:36.03 | cat1 | mnemoc: done |
| 13:37.00 | mnemoc | thanks :) |
| 13:43.28 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:d1e4:ce8d:a60:5780) |
| 13:45.39 | cat1 | mnemoc: that was not difficult at all, but now i need to help my wife with translating some chemistry related document, this is gonna be a task! :D |
| 13:46.38 | mnemoc | :p |
| 13:51.08 | mnemoc | hno: U-Boot SPL 2012.10-rc3-04244-gfa4a874 (Oct 13 2012 - 14:46:39) |
| 13:51.08 | mnemoc | ### ERROR ### Please RESET the board ### |
| 13:51.26 | mnemoc | hno: --^ sunxi on my cubie :< |
| 14:06.32 | techn | cromo: use a10_display to set correct timings.. and fbset to set correct resolution |
| 14:07.30 | techn | xbmca10 should read current display mode from framebuffer.. not from those allwinner hacky ioctl's |
| 14:09.17 | techn | I'll hope that we can get rid of those ioctl's soon.. or should we maintain backwards compatibility with them? :( |
| 14:13.03 | mnemoc | in 3.0 behind a CONFIG_, yes |
| 14:13.14 | mnemoc | in 3.4, they can die |
| 14:13.17 | mnemoc | i think |
| 14:13.29 | mnemoc | unless the android libs for JB need them :< |
| 14:14.45 | hno | mnemoc, ok. So it fails detecting current boot method. |
| 14:15.48 | mnemoc | hno: if you want I can apply a patch (from you) to make it verbose and test again |
| 14:15.58 | mnemoc | printk() for the win :p |
| 14:18.11 | hno | mnemoc, see arch/arm/cpu/armv7/sunxi/board.c |
| 14:18.23 | hno | the boot method detect is easy to see there. |
| 14:19.09 | mnemoc | so i'm missing the define? |
| 14:28.30 | *** join/#arm-netbook Gumboot (~gumboot@rev.bovine.muck.net.nz) |
| 14:29.30 | hno | which define? |
| 14:29.43 | mnemoc | 2m. adding debug()s |
| 14:31.58 | hno | ah, i see the error. forgot to update the returned values. |
| 14:33.53 | hno | no. only had forgot to git pull on this computer.. |
| 14:35.11 | mnemoc | hno: the function is never called |
| 14:35.26 | mnemoc | or debug() doesn't work by default |
| 14:35.27 | hno | it's not? |
| 14:35.41 | mnemoc | what should i use for printing? |
| 14:35.54 | hno | debug() need to be enabled by -DDEBUG |
| 14:36.35 | hno | puts always works |
| 14:42.59 | mnemoc | GPC(7) == 0x0 (vs. 0x3) |
| 14:43.04 | mnemoc | GPC(2) == 0x0 (vs. 0x2) |
| 14:43.11 | mnemoc | ### ERROR ### Please RESET the board ### |
| 14:43.54 | hno | hm. do brom reset the gpio pins? |
| 14:43.59 | mnemoc | the 0x0 is sunxi_gpio_get_cfgpin(SUNXI_GPC(n)) actually |
| 14:44.11 | mnemoc | don't know... |
| 14:44.25 | hno | try hardwirig the return for now. |
| 14:44.46 | mnemoc | ok |
| 14:45.13 | hno | can't really look at this right now. But will tonight. |
| 14:45.30 | mnemoc | what do I want. BOOT_DEVICE_MMC2 or BOOT_DEVICE_MMC1? |
| 14:46.04 | mnemoc | i would have expected MMC0 actually :< |
| 14:46.16 | mnemoc | but no check for that one |
| 14:47.38 | Turl | techn: if you can provide equivalent alternatives for the IOCTLs I can nuke them on userspace |
| 14:47.56 | mnemoc | i suppose we should implement KMS's |
| 14:49.13 | hno | Either should work at the moment. |
| 14:49.58 | mnemoc | hno: booted |
| 14:51.59 | hno | Pushed. |
| 14:52.31 | *** join/#arm-netbook ceo16 (~asus@host203-182-dynamic.56-82-r.retail.telecomitalia.it) |
| 14:53.00 | mnemoc | good fallback :) |
| 15:00.40 | hno | I really only need to detect MMC0/MMC2 somehow. NAND will need to be built differently most likely. |
| 15:01.11 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.97) |
| 15:15.17 | hno | If my cubieboard had two MMCs and JTAG.. |
| 15:16.50 | rm | [ 1321.080000] INFO: task kinteractiveup:36 blocked for more than 120 seconds. |
| 15:17.04 | rm | I think that's the reason of my always-1.0 load |
| 15:21.02 | Turl | rm try some other governor :< |
| 15:21.31 | mnemoc | i thought you used a tuned ondemand |
| 15:21.34 | rm | I am using ondemand; most likely this is the daemon of the "interactive" governor |
| 15:21.38 | rm | which is not even used atm |
| 15:21.44 | mnemoc | doh |
| 15:21.47 | rm | but the daemon still runs, collecting some stats (?) |
| 15:21.50 | Turl | rm what's your default governor? |
| 15:21.54 | rm | performance |
| 15:22.11 | Turl | why is the interactive kthread even running then? o.O |
| 15:22.47 | rm | quality android/allwinner code? |
| 15:22.51 | mnemoc | because android is evil |
| 15:23.27 | Turl | that's google's code |
| 15:23.36 | Turl | never had it do something like that on any of my devices |
| 15:23.36 | mnemoc | today G decided to truncate their 3.0 and 3.4 branches to ~april and then diverge it... |
| 15:24.06 | mnemoc | yes, interactive is android's default gov. |
| 15:24.09 | Turl | rm try disabling the governor completely, as in, don't build it |
| 15:24.19 | Turl | if you still see it you have bigger issues :P |
| 15:24.19 | rm | yes, that's what I am going to do |
| 15:26.39 | *** part/#arm-netbook QingPei (~qingpei@114.217.185.222) |
| 15:27.01 | Turl | mnemoc: I'm going to work a bit on cpufreq, would you prefer it rebased on 3.4 or 3.0? |
| 15:27.54 | mnemoc | 3.0 |
| 15:28.02 | mnemoc | more people testing it ;-) |
| 15:28.10 | mnemoc | and then I forward it |
| 15:28.19 | rm | ok, building a new one enabled NO_HZ too |
| 15:28.31 | rm | s/one/one,/ |
| 15:28.33 | rm | :) |
| 15:28.48 | mnemoc | ibot: we love you |
| 15:28.48 | ibot | Shame, I hate non-bots. |
| 15:28.56 | mnemoc | :D |
| 15:28.58 | Turl | ibot: gtfo then |
| 15:29.04 | Turl | :P |
| 15:33.09 | Turl | mnemoc: your move caused a repack of sorts :P |
| 15:33.10 | Turl | Auto packing the repository for optimum performance. You may also |
| 15:33.11 | Turl | run "git gc" manually. See "git help gc" for more information. |
| 15:34.13 | mnemoc | I also added info to http://linux-sunxi.org/Linux#Branches |
| 15:34.23 | mnemoc | going to murder the wiki in github |
| 15:36.27 | mnemoc | but still trying to adapt my working tree to the changes and the split between my wip/ branches and linux-sunxi's |
| 15:36.32 | mnemoc | trees* |
| 15:37.23 | mnemoc | i hope this move doesn't confuse people much |
| 15:38.05 | Turl | mnemoc: so now the tree on amery will be deleted after a while? |
| 15:38.19 | Turl | or will you keep it up for your own experiments and wips? |
| 15:38.36 | mnemoc | I'm going to keep the old named branches working as a mirror for a while |
| 15:38.48 | mnemoc | and keep it for my own wip/s and experiments |
| 15:40.04 | mnemoc | but only mirror sunxi-3.0 and sunxi-3.4, not the wips, mirrors, etc |
| 15:42.34 | mnemoc | i don't like it to be called "amery's kernel" :< |
| 15:47.03 | *** join/#arm-netbook cromo (5efbfb70@gateway/web/freenode/ip.94.251.251.112) |
| 15:48.33 | cromo | techn: I played with fbset however still can't get the 1920 set properly: I switched the mode with a10_tool first, then with fbset, but in the result I have screen divided in 4 parts, two upper repeating the console, two lower showing nothing. |
| 15:49.08 | rm | cromo, and in script.bin? |
| 15:49.11 | rm | switched there? |
| 15:49.23 | cromo | script bin is 720, not swtiched there |
| 15:49.27 | Turl | mnemoc: woo finally finished gc'ing |
| 15:49.34 | rm | well here's your problem then |
| 15:49.48 | rm | as I said earlier you ABSOLUTELY HAVE TO switch in script.bin |
| 15:50.01 | rm | without it none of your listed means will have the desired effect |
| 15:50.10 | rm | you will get only various weird glitches |
| 15:50.37 | mnemoc | Turl: :D |
| 15:50.41 | cromo | I assumed it is not, from what techn wrote, because once you have it set in script there's no point in using the a10_tool? |
| 15:50.54 | rm | ...maybe? |
| 15:51.28 | cromo | anyways, where do I find some info about what to change in the script to have 1080? |
| 15:51.51 | Turl | http://linux-sunxi.org/Fex_Guide ? :) |
| 15:52.04 | cromo | great, thanks |
| 15:52.42 | rm | I am unaware of the latest progress |
| 15:52.54 | cromo | is it only the [disp_init] or semewhere else, too? |
| 15:53.01 | rm | maybe techn is working on a10_tool so that it can switch resolution even despite what's in script.bin |
| 15:54.20 | mnemoc | techn: for sunxi-tools please :) |
| 16:01.44 | Turl | mnemoc: did we merge the atag tools in the end? |
| 16:02.02 | Turl | doesn't recall what happened |
| 16:02.24 | mnemoc | i don't even remember that thing |
| 16:02.30 | *** join/#arm-netbook cromo_ (5efbfb70@gateway/web/freenode/ip.94.251.251.112) |
| 16:03.40 | cromo_ | I changed the screen0_output_mode from 720p to 1080, it changed nothing. lundman, I remember you offered to share your mele script.bin with 1080 already in? |
| 16:06.11 | *** join/#arm-netbook tuliom (~tuliom@177.133.171.160) |
| 16:08.39 | *** join/#arm-netbook cromo (5efbfb70@gateway/web/freenode/ip.94.251.251.112) |
| 16:09.59 | cromo | damn, I had script.bin alongside evb.bin and the latter one is used for booting |
| 16:10.07 | cromo | or so it seems |
| 16:10.26 | mnemoc | check your u-boot env |
| 16:10.53 | mnemoc | our u-boot, and normal nanda's u-boot, uses script.bin |
| 16:11.12 | cromo | I updated the uboot |
| 16:11.19 | cromo | but it probably has old env |
| 16:11.25 | mnemoc | but some images flying around decided using evb.bin (evaluation board) was smart |
| 16:11.44 | mnemoc | you can see in the wiki how to wipe it from mmc |
| 16:12.04 | cromo | I will look at it later |
| 16:12.07 | mnemoc | in nand it's a raw partition, don't remember which |
| 16:12.13 | cromo | thanks |
| 16:13.02 | cromo | I diffed the evb and the script.bin |
| 16:13.14 | cromo | script.bin comes from nightly builds of hwpack |
| 16:13.24 | cromo | and there are some differences indeed |
| 16:13.48 | mnemoc | fix your u-boot to use script.bin |
| 16:14.11 | cromo | brb, reboot |
| 16:14.20 | hno | mnemoc, it's a separate partition in nand. "env". |
| 16:15.09 | mnemoc | or wipe it out. it's simpler, and you'll get a branch new one with boot.scr, uEnv.txt and ext2/ext3 support ;-) |
| 16:18.37 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.97) |
| 16:25.03 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56154.dip0.t-ipconnect.de) |
| 16:26.31 | rm | tickless kernel does not boot |
| 16:27.10 | mnemoc | and again only with that changed |
| 16:29.59 | rm | I have disabled tickless now, but enabled PREEMPT :p |
| 16:30.16 | rm | if that does not boot either, I am labeling them as non-working for 3 more years, thnx |
| 16:30.53 | mnemoc | and the exact same everything else disabling those two works fine? |
| 16:31.00 | mnemoc | what's on the console? |
| 16:31.15 | mnemoc | "does not boot" isn't very helpful to fix things |
| 16:33.11 | Turl | rm I run NO_HZ on all the things |
| 16:33.15 | Turl | never had any issues :< |
| 16:33.21 | rm | do you also use CPUFREQ? |
| 16:33.25 | Turl | ye |
| 16:33.27 | Turl | and DVFS |
| 16:33.30 | Turl | and PREEMPT |
| 16:34.35 | *** join/#arm-netbook cromo (5efbfb70@gateway/web/freenode/ip.94.251.251.112) |
| 16:34.38 | cromo | ha! got xbmca10 running in 1080p just fine :)) |
| 16:34.41 | Turl | mnemoc: http://paste.debian.net/199947/ any better idea? |
| 16:34.50 | rm | mnemoc, I do not have serial console connected, hmm I wonder if fbcon should have been working |
| 16:35.45 | mnemoc | fbcon comes pretty late |
| 16:35.48 | mnemoc | but can help |
| 16:40.02 | techn | cromo: Ok.. Then you need set virtual yres to 2*yres |
| 16:40.42 | cromo | techn: nah, it was old info. it works fine now, all I did was changing the resolution in script.bin and starting xbmca10 |
| 16:40.47 | cromo | works just fine |
| 16:41.32 | techn | ok |
| 16:42.20 | rz2k | cromo: only xmbc? X still in left corner in 720p ? |
| 16:42.35 | cromo | no, nothing wrong |
| 16:42.38 | cromo | plain 1080p |
| 16:42.43 | cromo | no issues whatsover |
| 16:42.51 | techn | rm: http://linux-sunxi.org/Framebuffer |
| 16:42.54 | rz2k | hdmi? |
| 16:42.57 | cromo | yes |
| 16:43.28 | rz2k | any chance for you to test vga 1080p? |
| 16:43.29 | cromo | although there is some screen tearing (not much) that I haven't seen previously |
| 16:43.36 | cromo | rz2k: don't have the cable around |
| 16:43.50 | rz2k | because I've tried to do same on vga and had 720 in 1080 |
| 16:43.58 | cromo | and quite busy next week so won't be able to do it soon |
| 16:43.59 | rz2k | maybe I did something wrong |
| 16:46.24 | rm | I had 1680x1050 to VGA |
| 16:46.27 | rm | not 720 in 1050 |
| 16:46.55 | rm | also the PREEMPT kernel does seem to work fine |
| 16:47.24 | rm | not sure if it's needed in the first place, though |
| 16:47.46 | rm | on a low-performance CPU do you really want to switch back and forth between kernel and userspace |
| 16:49.47 | Turl | you probably do, for time critical applications |
| 16:52.17 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 16:52.56 | mnemoc | "responsiveness" is time critical ;-) |
| 17:05.15 | Turl | that's my point :) |
| 17:05.35 | Turl | mnemoc: any other idea to stress test cpufreq? |
| 17:06.57 | cromo | stress |
| 17:07.02 | cromo | ;) |
| 17:07.22 | cromo | ah, cpufreq |
| 17:07.24 | cromo | nvmind |
| 17:07.37 | mnemoc | Turl: compile kde :p |
| 17:07.52 | techn | variable load? for-loop with varying sleep? |
| 17:08.59 | Turl | look at my paste up there ^ |
| 17:12.55 | techn | Turl: I think thats not the same.. I was thinkin shorter-longer sleep between 100% load |
| 17:13.26 | techn | Or how that frequency scaling works? |
| 17:14.47 | Turl | if mix=max there's not much scaling to be done :) |
| 17:14.51 | Turl | min* |
| 17:16.18 | techn | also should different methods be tested? performance/ondemand/powersave? or is yours some of them? :) |
| 17:16.42 | ManoftheSea | wow, freebirds derailed that one fast. |
| 17:16.44 | mnemoc | while true; do for x in 1 2 4 8 ...; do sleep $x; something_stressful; done; done |
| 17:17.53 | ManoftheSea | I posted how it sorta looked like EOMA-68 was going to be limited to 1400x1050 on the internal connection. |
| 17:18.17 | techn | .. and maybe switching between different method could be tested |
| 17:19.13 | mnemoc | for gov in ondemand ....; do echo $x > /sys/.... for x in 1 2 4 8 ...; do sleep $x; something_stressful; done; done |
| 17:19.16 | mnemoc | :p |
| 17:19.17 | Turl | sleep-able amounts are too big for cpufreq |
| 17:19.18 | Turl | :P |
| 17:19.38 | mnemoc | sleep 0.$x |
| 17:19.52 | Turl | can you do that? :P |
| 17:19.56 | mnemoc | yes |
| 17:20.00 | Turl | heh, neat :) |
| 17:20.09 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 17:21.05 | ManoftheSea | So, check this out, guys. The mini-engineering board? It's just a micro-board, with the usb plugged into an olimex-stm32 |
| 17:21.23 | *** join/#arm-netbook NAiL (~repvik@nslu2-linux/repvik) |
| 17:23.26 | mnemoc | ManoftheSea: I like http://www.wvshare.com/product/Open103Z-Standard.htm better ;-) |
| 17:23.35 | ManoftheSea | how does one find connector part datasheets? Like, I'd like to find an LVDS connector for the micro-board |
| 17:23.45 | mnemoc | http://www.wvshare.com/column/STM32_DevelopmentBoard.htm <--- many many models |
| 17:24.17 | ManoftheSea | mnemoc: ok. Sure, that'd work too. |
| 17:24.31 | ManoftheSea | The olimex-stm is 20 euro, this one is $40 |
| 17:24.44 | mnemoc | and adding it to the mini... $4? |
| 17:24.46 | mnemoc | 5? |
| 17:25.29 | ManoftheSea | adding to the mini? |
| 17:25.32 | ManoftheSea | What do you mean? |
| 17:25.43 | mnemoc | the stm32 |
| 17:25.59 | mnemoc | as part of the eng board instead of hacked in over usb |
| 17:26.07 | ManoftheSea | "hacked in"? |
| 17:26.15 | mnemoc | connected |
| 17:26.17 | ManoftheSea | It isn't hacked in. |
| 17:26.23 | ManoftheSea | It's a standard usb connection. |
| 17:26.33 | mnemoc | yes. ok |
| 17:26.41 | ManoftheSea | I |
| 17:26.58 | mnemoc | i only mean that it's cheaper to make a good eoma68 eng board that buying separated things |
| 17:27.01 | ManoftheSea | I'm trying to hack up a micro-board in kicad, it's basically a bunch of connectors. |
| 17:27.11 | ManoftheSea | It's cheaper, if you know what you're doing. |
| 17:27.15 | ManoftheSea | I don't. |
| 17:27.21 | mnemoc | neither do i ;-) |
| 17:27.31 | ManoftheSea | So, a connector board seems pretty easy, and a cheap stm board is easy to connect via usb |
| 17:28.04 | ManoftheSea | and those other boards have their own expansion modules. |
| 17:28.28 | ManoftheSea | I wouldn't want to try to be "arduino-compatible" when the maple, the olimex, the one you posted, all already do it. |
| 17:31.44 | mnemoc | when I mnetioned the need of the stm32 in the from-start eng board was to develop the "EC" firmware |
| 17:31.59 | mnemoc | not to be abused as arduinoish controller |
| 17:32.31 | mnemoc | it's for the controller of the laptop board |
| 17:32.44 | mnemoc | or tablet, or tv |
| 17:33.28 | mnemoc | there are already plenty cheaper boards to do arduino like tasks |
| 17:33.34 | mnemoc | starting with the olinuxinos |
| 17:33.43 | mnemoc | or the r-pi |
| 17:36.04 | ManoftheSea | chuckles at mnetioned from mnemoc |
| 17:36.27 | mnemoc | :p |
| 17:36.31 | ManoftheSea | mnemoc: right, and there are plenty of stm32f boards to do that EC firmware dev. |
| 17:36.42 | ManoftheSea | That are several revisions in, already |
| 17:36.48 | mnemoc | true |
| 17:36.49 | mnemoc | ok |
| 17:36.55 | mnemoc | but please add a hub |
| 17:37.05 | ManoftheSea | oh yeah, definitely |
| 17:37.14 | ManoftheSea | I've pulled a 7 port datasheet. |
| 17:37.21 | mnemoc | i know there are plent external usb hubs already too :p |
| 17:37.23 | ManoftheSea | I think it's multi-TT, at that |
| 17:37.28 | mnemoc | but it's annoying |
| 17:37.35 | mnemoc | nice |
| 17:37.38 | ManoftheSea | yeah, the hub is really useful for a micro board |
| 17:38.05 | penguin42 | multi-tt? |
| 17:38.20 | ManoftheSea | some downstream can be 1.1, other's 2.0 |
| 17:38.23 | mnemoc | and as the io board has power we can feed the usb ports too |
| 17:39.23 | ManoftheSea | right. I think the chip does that. |
| 17:39.32 | mnemoc | ManoftheSea: but who will we do the backlight of the lcd connected to the micro-eng? |
| 17:39.34 | ManoftheSea | as it has provision for ganged mode or not. |
| 17:39.47 | mnemoc | s/who/how/ |
| 17:39.48 | ManoftheSea | mnemoc: it'd have to be on the STM side. |
| 17:39.55 | mnemoc | ok |
| 17:39.58 | ManoftheSea | Though, you could wire it up with a GPIO. |
| 17:40.03 | ManoftheSea | perhaps. |
| 17:40.39 | ManoftheSea | I dont' know how backlights are currently done. It doesn't seem to be part of the LVDS link. |
| 17:41.04 | ManoftheSea | So... it's either GPIO from the micro-board or USB device at the STM32 side. |
| 17:41.25 | ManoftheSea | I guess it could be I2C. I'm not really sure. |
| 17:41.29 | mnemoc | stm32 side sounds more likely than a boolean gpio |
| 17:41.47 | ManoftheSea | I don't know enough about lcd panels. |
| 17:41.56 | mnemoc | i don't know anything ;-) |
| 17:42.08 | mnemoc | but i would expect it to not work as a boolean |
| 17:42.18 | ManoftheSea | But, I plan to put a connector for everything coming from the PCMCIA. I'd like them to be the right connectors. |
| 17:42.31 | ManoftheSea | So, that means it will be that TI chip. |
| 17:43.27 | ManoftheSea | er, converter chip that goes RGB to LVDS, and then an LVDS connector. |
| 17:43.40 | ManoftheSea | At which point, a dev could add their lcd screen. |
| 17:44.26 | mnemoc | olimex is going to sell cheap (~55E) panels for the A1X olinuxinos |
| 17:44.56 | mnemoc | or mimic's arduino lcd connector |
| 17:45.14 | mnemoc | lvds is too fancy at this stage |
| 17:45.20 | mnemoc | imo |
| 17:47.09 | mnemoc | but if the stm32 is in a different board that can be... complicated |
| 17:47.37 | ManoftheSea | too fancy? |
| 17:47.49 | ManoftheSea | LVDS is how you connect to a panel. |
| 17:48.49 | mnemoc | but they aren't easy to buy for a hobbiest... |
| 17:49.28 | mnemoc | or they are? .oO |
| 17:49.57 | ManoftheSea | well, amazon is full of "replacement laptop screen" |
| 17:50.24 | ManoftheSea | I don't know if there's a standard pinout for those, though. |
| 17:51.52 | Turl | mnemoc: are struct definitions well suited for a .h? |
| 17:52.27 | Turl | s/definition/array initialization/ |
| 17:52.47 | mnemoc | Turl: no |
| 17:52.51 | penguin42 | generally I'd put initializations in .c |
| 17:53.14 | mnemoc | extern goes in the .h |
| 17:53.38 | Turl | yeah but extern ... stuff[*hardcode stuff here*][2] :( |
| 17:53.38 | mnemoc | you don't want to repeat the symbol on every .c including the header |
| 17:53.57 | Turl | otherwise sizeof and friends complain |
| 17:54.45 | Turl | will have to live with a macro :P |
| 17:55.04 | mnemoc | <PROTECTED> |
| 17:55.26 | mnemoc | just be sure to use the same N/M when actually defining the a |
| 17:55.35 | Turl | yeah that's why I don't like it :< |
| 17:55.37 | mnemoc | but as a general rule, globals are evil |
| 17:55.52 | Turl | mnemoc: it's a table |
| 17:55.55 | ManoftheSea | ok, according to this TI led controller chip, dimming is achieved by PWM |
| 17:56.00 | penguin42 | hmm do you need the N in the extern, or will it let you get away with out it |
| 17:56.05 | ManoftheSea | So, I'd call that a USB device on the STM32F. |
| 17:56.09 | mnemoc | Turl: tables are usually static |
| 17:56.48 | ManoftheSea | Also... the STM32F is a handy little chip. As long as we assume someone will write the code, I could probably build a robot to build a pyramid. On Mars. |
| 17:57.25 | mnemoc | Turl: it seems to me you are approaching your problem the wrong way |
| 17:57.35 | mnemoc | Turl: even when I don't know what you are doing |
| 17:57.55 | mnemoc | Turl: needing the world to know the size of a table hardcoded in a header is BAD |
| 17:58.27 | mnemoc | only the code where the static table lives should deal with it |
| 17:58.41 | mnemoc | and in that case ARRAY_SIZE() works well |
| 17:59.24 | mnemoc | ARRAY_SIZE(A) been (sizeof(A)/sizeof(A[0])) |
| 17:59.35 | mnemoc | but only in the same .c |
| 17:59.35 | Turl | mnemoc: keeping all the tables together seems like a logical idea to me |
| 17:59.39 | penguin42 | Turl: You can do things like; int foo[][2]; in the header; and in the .c file you can do int foo[][2]={{1,2},{2,3}} |
| 17:59.53 | penguin42 | Turl: That way the header doesn't need to know the outer array index (just tested) |
| 18:00.13 | Turl | penguin42: yeah but if you use sizeof it complains because [] :) |
| 18:00.20 | mnemoc | Turl: no clue what you are doing, but global tables are just as bad as global variables |
| 18:00.36 | mnemoc | just don't |
| 18:00.39 | penguin42 | Turl: Right, but then it depends what you are doing with the table; if you terminate the table by a magic number rather than relying on size it's fine |
| 18:00.42 | mnemoc | take a differnt path |
| 18:01.06 | Turl | <PROTECTED> |
| 18:01.06 | Turl | >.< allwinner quality code |
| 18:01.36 | mnemoc | sunxi_dvfs_entry(n); |
| 18:01.55 | mnemoc | NULL when out of range |
| 18:02.02 | mnemoc | DONT use global tables |
| 18:02.04 | mnemoc | please |
| 18:02.17 | Turl | not related to that line, I just saw that and thought it was funny :P |
| 18:02.57 | mnemoc | some people likes &A[0] for simetry... |
| 18:03.17 | penguin42 | mnemoc: What do you dislike about global tables? |
| 18:03.17 | mnemoc | I'm more of A+N :p |
| 18:03.59 | mnemoc | polute the env, rely on excess of knowledge, beg for abuse, ... |
| 18:04.13 | penguin42 | mnemoc: If they're const it ain't too bad |
| 18:04.33 | mnemoc | it's a bad habit. everywhere or nowhere |
| 18:04.36 | Turl | mnemoc: https://github.com/allwinner-dev-team/linux-allwinner/blob/wip/allwinner-3.0/cpufreq/arch/arm/mach-sun4i/cpu-freq/cpu-freq-table.c#L89 |
| 18:04.39 | mnemoc | at least for me |
| 18:05.08 | Turl | mnemoc: https://github.com/allwinner-dev-team/linux-allwinner/blob/wip/allwinner-3.0/cpufreq/arch/arm/mach-sun4i/cpu-freq/cpu-freq.c#L182 |
| 18:05.32 | mnemoc | Turl: fine, add a function in that .c to grant access |
| 18:05.43 | mnemoc | check size, etc |
| 18:05.49 | mnemoc | callers don't need to know |
| 18:06.13 | Turl | that function is the only table user |
| 18:06.33 | mnemoc | then move the function |
| 18:06.48 | mnemoc | or refactor it between both places |
| 18:07.00 | mnemoc | exporting one function is saner than exporting table and size |
| 18:07.39 | Turl | cpu-freq-table.c holds tables only, and I think it makes for cleaner code that way as all the 'tunables' are in one place |
| 18:08.03 | Turl | if sun5i has different clock freqs and divs you'd just need a different cpu-freq-table.c |
| 18:08.38 | mnemoc | Turl: how will that work since 3.7 when multiplatform is required? |
| 18:10.10 | mnemoc | same kernel for A10, A12, A13, A10s, A15, ... |
| 18:10.13 | Turl | I haven't looked at 3.7 but I suppose you could have something somewhere on the init path assign the right table to the variables depending on cpu |
| 18:10.31 | mnemoc | global tables are wrong |
| 18:10.38 | Turl | if(A10) table= ... |
| 18:10.38 | Turl | elif(A13) table= ... |
| 18:10.42 | mnemoc | but i can't force you to understand it |
| 18:11.03 | mnemoc | Turl: that's better |
| 18:11.20 | mnemoc | table = sunxi_a10_table(&l); |
| 18:11.28 | mnemoc | get a pointer to the table, and it's length |
| 18:11.53 | mnemoc | no global table involved |
| 18:12.06 | mnemoc | but an access function |
| 18:16.43 | mnemoc | it can also be sun4i_tablet(&l); and the accessor will decide if it's A10 or A10s |
| 18:19.28 | ManoftheSea | what's A10s? |
| 18:19.45 | ManoftheSea | is that plural, or is that like iPhone 3s |
| 18:19.53 | mnemoc | "small" |
| 18:20.00 | mnemoc | a new variat of the A10 |
| 18:20.43 | mnemoc | but we don't know anything about it beside what is in the product page :< |
| 18:21.10 | mnemoc | sadly it seems they removed SATA |
| 18:22.22 | ManoftheSea | so it's an A13? |
| 18:23.05 | mnemoc | nope. A10 |
| 18:23.32 | mnemoc | but will less pins and features removed, aimed at hdmi dongles and settop boxes |
| 18:23.38 | ManoftheSea | I mean, I thought that was the reasoning behind the a13. It's a small a10 |
| 18:24.10 | mnemoc | A13 has different packageing |
| 18:24.15 | mnemoc | and it's tablet oriented |
| 18:24.20 | mnemoc | the A10s doesn't have LCD |
| 18:24.26 | mnemoc | only hdmi |
| 18:24.47 | ManoftheSea | LCD? Do you mean the two RGB outs? |
| 18:24.48 | mnemoc | the a13 is larger than the a10 |
| 18:25.10 | mnemoc | no rgb either |
| 18:29.20 | mnemoc | Turl: but going back to the extern. extern struct cpufreq_dvfs dvfs_table[]; doesn't work? you have a sentinel, so you don't need the lenght |
| 18:45.58 | mnemoc | it's probably a good idea to replace the length of the other tables with sentinels too |
| 18:46.46 | mnemoc | looping by index suchs |
| 18:46.49 | mnemoc | sucks |
| 18:54.40 | ManoftheSea | Ok, shit. LVDS isn't a standard connector. I'm looking at a panel from '09, it's a 40 wire connection. |
| 18:55.11 | ManoftheSea | It uses 2 channels of 18-bit color LVDS. |
| 19:00.41 | ManoftheSea | there's no indication of where the other 2 pairs would go, for a 2-channel 24-bit screen. |
| 19:00.45 | mnemoc | one way is to search for a common connector used in cheap panels and provide easy locations to buy :p |
| 19:00.51 | ManoftheSea | arg. |
| 19:01.04 | ManoftheSea | mnemoc: no, I think the connector is defined by the panel. |
| 19:01.05 | mnemoc | or adopt arduino's header |
| 19:01.22 | mnemoc | or olimex's lcd header |
| 19:01.43 | mnemoc | both are 0.1" pins |
| 19:01.45 | ManoftheSea | yeah, but those are industrial type things. I was thinking toward the laptop board. |
| 19:02.09 | mnemoc | for a laptop board you need to marry one lvds, yes |
| 19:02.14 | mnemoc | i was thinking in the eng boards |
| 19:02.20 | ManoftheSea | right. DVI it is. |
| 19:03.26 | mnemoc | btw, this is why i called lvds connector a fancy choice |
| 19:03.47 | mnemoc | people wouldn't have inexpensive options |
| 19:04.21 | ManoftheSea | when did you call it fancy? |
| 19:05.17 | mnemoc | 19:44:48 < mnemoc> olimex is going to sell cheap (~55E) panels for the A1X olinuxinos |
| 19:05.20 | mnemoc | 19:45:19 < mnemoc> or mimic's arduino lcd connector |
| 19:05.22 | mnemoc | 19:45:36 < mnemoc> lvds is too fancy at this stage |
| 19:05.24 | mnemoc | 19:48:00 < ManoftheSea> too fancy? |
| 19:05.27 | mnemoc | 19:45:43 < mnemoc> imo |
| 19:05.59 | mnemoc | even when for an EE a DVI is fancier in the sense of more layers |
| 19:06.08 | ManoftheSea | ok. |
| 19:06.23 | ManoftheSea | layers... on the board? |
| 19:06.26 | ManoftheSea | what? |
| 19:06.47 | mnemoc | no no... sorry. layer in the software sense. abstractions. conversions |
| 19:06.56 | mnemoc | lvds is "native" |
| 19:07.10 | mnemoc | to get anything else you need to add extra stuff in the board |
| 19:07.31 | mnemoc | i don't know about electronics... i'm only a C ape |
| 19:07.40 | ManoftheSea | RGB is native. |
| 19:07.46 | ManoftheSea | But it doesn't go far enough. |
| 19:07.55 | ManoftheSea | So, convert to DVI, plug in to standard monitor. |
| 19:08.12 | mnemoc | sounds good |
| 19:08.14 | ManoftheSea | LVDS is apparently for when we mate with a screen. |
| 19:08.16 | ManoftheSea | as you said, I agree. |
| 19:08.58 | mnemoc | it could even be dvi looking like hdmi |
| 19:09.05 | ManoftheSea | looking like? |
| 19:09.11 | mnemoc | normal hdmi connector |
| 19:09.16 | mnemoc | instead of large dvi connector |
| 19:09.27 | mnemoc | but without audio, so not strictly hdmi |
| 19:09.32 | mnemoc | there are cheap adapters |
| 19:09.52 | mnemoc | many do that thing |
| 19:10.02 | mnemoc | also saves them from paying hdmi royalties |
| 19:10.21 | ManoftheSea | oh, um... I'll look. |
| 19:11.22 | mnemoc | http://dx.com/p/gold-plated-1080p-hdmi-v1-3-male-to-dvi-male-connection-cable-1-7m-length-24301?item=16 |
| 19:11.53 | ManoftheSea | I meant, I'll look for chips |
| 19:11.55 | mnemoc | there are cheaper without cable |
| 19:11.57 | mnemoc | :p |
| 19:12.27 | mnemoc | i thought i had to keep trying to convince you :p |
| 19:13.33 | mnemoc | so ttl/rgb to dvi with hdmi connector... can we reach ~1080p with that? |
| 19:13.38 | ManoftheSea | no. |
| 19:13.41 | mnemoc | :( |
| 19:13.43 | ManoftheSea | Well... |
| 19:13.59 | ManoftheSea | As far as I can tell, RGB-TTL is only expected to reach 1400x1050 |
| 19:14.42 | mnemoc | still better than the 1366x768 of my laptop... |
| 19:16.07 | mnemoc | and we can always hook the 1080p on the real hdmi on the other side of the card |
| 19:16.11 | ManoftheSea | right... but from my uneducated vantage, it looks like all EOMA will be max 1400x1050, on the internal connector. |
| 19:16.20 | ManoftheSea | Yes, you can have a loopback cable. |
| 19:16.49 | mnemoc | considering lkcl aims at smart tvs too, the max 1400x1050 sounds ugly |
| 19:19.24 | hno | Next step is LVDS instead of TTL I suppose. |
| 19:20.45 | mnemoc | and why didn't we get lvds pins in the eoma68 header instead? |
| 19:21.16 | hno | Because cheap panels are TTL? |
| 19:21.20 | mnemoc | ok |
| 19:21.44 | hno | And because TTL is a common denominator for many possible SoCs. |
| 19:22.59 | ManoftheSea | Because RGB can go to LVDS, DVI, etc. |
| 19:23.16 | ManoftheSea | I suppose there's DVI->LVDS. |
| 19:23.40 | ManoftheSea | But... probably because a lot of chips put out RGB, rather than LVDS, and the conversion is another chip on the EOMA card. |
| 19:24.04 | ManoftheSea | This converter claims to require 3.3V at 1/4 A, or... a little under a watt? |
| 19:24.16 | ManoftheSea | when you only have a 4 W budget, that's expensive |
| 19:24.42 | mnemoc | how would resolution detection/change work with the rgb/dvi? |
| 19:24.42 | ManoftheSea | also... you need two lvds channels. that's... 10 wires? |
| 19:24.53 | ManoftheSea | mnemoc: I don't know how it works with anything else. |
| 19:25.19 | ManoftheSea | I've heard the term EDID. |
| 19:25.24 | ManoftheSea | I think that's across I2C. |
| 19:27.00 | mnemoc | but that is on the dvi side |
| 19:27.21 | mnemoc | the guy talking rgb needs to be... informed |
| 19:29.06 | mnemoc | puzzled |
| 19:29.43 | penguin42 | mnemoc: I don't think there is a standard way of determining the size of an LCD that's directly connected |
| 19:30.13 | mnemoc | it was told that we would need to hardcode the info about the panel in the eeprom |
| 19:30.28 | mnemoc | but having dvi in between... it's not hardcoded anymore |
| 19:31.01 | penguin42 | mnemoc: Well that's all that happens on dvi; the i2c eeprom is in the monitor |
| 19:31.18 | mnemoc | :) |
| 19:31.39 | penguin42 | mnemoc: And some of them are dumb enough to let you overwrite them |
| 19:32.19 | mnemoc | LD |
| 19:32.20 | mnemoc | :D |
| 19:32.31 | penguin42 | you occasionally come across a monitor with the wrong EDID info and all hell breaks loose (whether that's accidental or someone being nasty...) |
| 19:33.44 | ManoftheSea | ok, so... If the device is DVI, it has an i2c EEPROM with device tree that specifies, "look for edid" |
| 19:33.58 | Turl | mnemoc: https://github.com/allwinner-dev-team/linux-allwinner/tree/wip/allwinner-3.0/cpufreq/arch/arm/mach-sun4i/cpu-freq |
| 19:34.08 | ManoftheSea | if the device is LVDS, the i2c says... "resolution"? "Look elsewhere for edid"? |
| 19:34.37 | penguin42 | ManoftheSea: I'm not sure; is there a space in device tree to specify res? |
| 19:37.19 | ManoftheSea | There should be. |
| 19:37.22 | ManoftheSea | I don't know. |
| 19:37.30 | ManoftheSea | Someone check the a10 RGB output rate. |
| 19:37.44 | ManoftheSea | If it can go to 200MHz, we can have hope. |
| 19:38.12 | ManoftheSea | If it's 100MHz or less, we're stuck in sub-1400x1050 land. |
| 19:38.15 | ManoftheSea | And that's sad. |
| 19:38.54 | mnemoc | Turl: :) |
| 19:39.30 | Turl | mnemoc: testers welcome ;) |
| 19:41.25 | mnemoc | ManoftheSea: in eoma world, can we deal in the same board with modules <=100MHz and >100MHz ? |
| 19:41.39 | mnemoc | giving more or less res. accordingly |
| 19:42.25 | Maqs | does anybody know whether there's a chance to have video acceleration with mplayer etc. on linux on an A10? |
| 19:42.35 | Turl | rm, too :) |
| 19:42.39 | mnemoc | or we either design the eng board for one or the other? |
| 19:42.56 | ManoftheSea | i2c, "The monitor acts as a slave device at the 7-bit I²C address 50h, and provides 128-256 bytes of read-only EDID." |
| 19:43.14 | ManoftheSea | mnemoc: it may be possible. |
| 19:43.29 | ManoftheSea | There's a TI chip that takes one RGB in and can drive two LVDS out. |
| 19:43.36 | ManoftheSea | But it requires a hellish RGB clock rate. |
| 19:43.50 | ManoftheSea | Similarly, there may be something for driving a dual-link dvi. |
| 19:43.53 | ManoftheSea | I haven't seen it yet. |
| 19:44.00 | mnemoc | but it's smart enough to distinguish the capabilities of the eoma module? |
| 19:44.11 | ManoftheSea | Again, based on the speed of the RGB coming off the A10. |
| 19:44.27 | mnemoc | :) |
| 19:44.28 | ManoftheSea | mnemoc: no. The eoma would need to read the edid, and manage the link itself. |
| 19:44.34 | mnemoc | ok |
| 19:44.45 | ManoftheSea | i2c is a bus that comes from the pcmcia, so that can get the edid. |
| 19:44.50 | ManoftheSea | OR, the STM can do it. |
| 19:45.19 | techn | Maqs: yes.. but you have to code the support ;) |
| 19:47.05 | Maqs | are there any usable libs avaliable, especially for armhf? |
| 19:47.10 | hno | ManoftheSea, A10 does LVDS if you ask it, on the same pins. |
| 19:47.14 | mnemoc | i suppose the stm could "fake" an eeprom over i2c providing proper edid and the DT of the board |
| 19:47.29 | hno | mnemoc, yes. |
| 19:47.29 | ManoftheSea | hno, not in the EOMA spec. Reply to my arm-netbook thread. |
| 19:47.35 | ManoftheSea | I'm away. |
| 19:47.39 | mnemoc | hno: won't that break EOMA compat? |
| 19:47.48 | techn | Maqs: no armhf hwdecoder libs avalaible currently:( |
| 19:47.48 | mnemoc | LVDS i mean |
| 19:48.04 | Maqs | ok :-( |
| 19:48.54 | hno | mnemoc, it would not be EOMA 1.0. But 1.1 or whatever. |
| 19:53.39 | hno | http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 section Future Versions |
| 19:57.37 | mnemoc | Turl: can you mimic that for sun5i too? |
| 19:58.42 | Turl | mnemoc: cpufreq? |
| 19:58.52 | mnemoc | the same cleanup |
| 19:59.10 | mnemoc | then in 3.4 we can merge them it to plat-sunxi |
| 20:00.48 | mnemoc | well... maybe sending it to ML first for comments and testing is better |
| 20:02.13 | Turl | mnemoc: just compared the sun4/5i pre-patches |
| 20:02.35 | Turl | mnemoc: they're *identical* except for the comments holding the copyright, because one says sun4i and the other says sun5i on the path |
| 20:02.56 | mnemoc | happens a lot :p |
| 20:03.20 | mnemoc | that why I prefer to unify before cleaning/fixing/improving |
| 20:03.42 | Turl | yeah |
| 20:03.43 | mnemoc | Turl: what about moving the prepatch part into a driver? |
| 20:03.54 | mnemoc | unified |
| 20:04.07 | Turl | driver? |
| 20:04.16 | mnemoc | drivers/cpufreq/cpufreq-sunxi |
| 20:04.31 | mnemoc | but bool instead of tristate (not m) |
| 20:05.17 | Turl | doesn't make much sense imo |
| 20:05.22 | mnemoc | that's actually the modern way of doing things in linux arm. everything is a driver |
| 20:05.27 | Turl | and I don't see any other arch doing it that way |
| 20:05.41 | mnemoc | check at more recent trees |
| 20:05.58 | mnemoc | arch/arm/mach-foo/ are been emptied |
| 20:06.01 | Turl | there's db8500-cpufreq.c |
| 20:06.09 | mnemoc | and arch/arm/plat-foo/ been destroyed |
| 20:06.32 | mnemoc | part of the multiplatform effort were no globals are allowed |
| 20:06.42 | mnemoc | where* |
| 20:06.59 | mnemoc | Turl: thing is in 3.0 we don't have a plat-sunxi |
| 20:07.28 | mnemoc | so we can't unify the cpufreq things without moving them to the drivers space |
| 20:07.53 | mnemoc | adding plat-sunxi in 3.0 makes little sense considering we need to move 3.4 away of it anyway |
| 20:07.55 | Turl | mnemoc: we'd need to move the ccmu thingy to a driver first from what I'm looking |
| 20:08.32 | mnemoc | :) |
| 20:08.58 | mnemoc | so we know "what's next" toward mainlining ;-) |
| 20:09.10 | Turl | :P |
| 20:09.37 | Turl | I'm not too familiar with the ccmu code though, and the short scrambled names scare me :) |
| 20:09.56 | Turl | need to start reading and see what can I do there |
| 20:10.11 | mnemoc | remember, no cleanup, no improving. only relocating |
| 20:10.18 | mnemoc | and adapting to allow it |
| 20:12.25 | mnemoc | Turl: another way is simply to apply the same cleanup in sun4i and sun5i cpufreq and unify in plat-sunxi in 3.4 first and then jump to drivers/ |
| 20:12.51 | hno | mtd is making my head spin a little. Need to get a little more familiar with NAND to make sense of the interface. |
| 20:12.52 | mnemoc | mach -> plat -> driver, instead of mach -> driver |
| 20:13.19 | Maqs | is there something like an example source code or documentation for cedarx? |
| 20:13.21 | Turl | that was my original though :) I think it's better that way |
| 20:13.41 | Turl | mnemoc: moving it to plat on 3.4 should be trivial |
| 20:13.54 | mnemoc | ManoftheSea: check https://github.com/linux-sunxi/cedarx-libs |
| 20:14.03 | Turl | sun5i doesn't even have different tables :| |
| 20:14.34 | mnemoc | Turl: ok. so duplicated cleanup in 3.0. and unification in 3.4 |
| 20:14.52 | mnemoc | err |
| 20:14.55 | mnemoc | ManoftheSea: sorry |
| 20:15.02 | mnemoc | Maqs: check https://github.com/linux-sunxi/cedarx-libs |
| 20:15.19 | Maqs | mnemoc: thx |
| 20:15.48 | mnemoc | hno: adding raw access to the nand in u-boot will give you the missing knowledge to be able to write an mtd driver ;-) |
| 20:17.03 | Turl | mnemoc: I'd like some basic testing first though, before duplicating all the things :) |
| 20:17.25 | mnemoc | :) |
| 20:17.32 | Turl | *hint* :P |
| 20:17.34 | mnemoc | Turl: and send it to the list for comments |
| 20:18.23 | mnemoc | Turl: I can't test it at the momemnt :< ... need to finish some pending $work$ before monday begins :-/ |
| 20:18.34 | techn | Maqs: also xbmca10 is good example |
| 20:18.51 | mnemoc | the relocation of the repos and today's chat already consumed more than the sunxi time I had :\ |
| 20:19.33 | Turl | mnemoc: :( |
| 20:20.45 | techn | mnemoc: are we getting any new developers via cubiecoard/olinuxo? :) |
| 20:21.06 | mnemoc | doesn't look like it yet |
| 20:21.30 | techn | atleast xbmca10 progress should bring more testers :) |
| 20:21.58 | mnemoc | if only we would have armhf cerdarx libs they could test even more :| |
| 20:44.37 | hno | mnemoc, adding raw nand access to uboot is writing an mtd driver. |
| 20:45.42 | hno | but mtd surely would benefit from a somewhat higher level nand interface, operating at command level rather than signal level. |
| 20:46.09 | *** join/#arm-netbook dw4rf (~dw4rf@nl2x.mullvad.net) |
| 20:46.29 | *** join/#arm-netbook newbie (~kvirc@118-168-194-44.dynamic.hinet.net) |
| 20:49.10 | mnemoc | hno: i was mostly thinking is boot1 dumping |
| 20:49.30 | mnemoc | but yes, that can be done with the mtd driver too |
| 20:49.46 | mnemoc | assuming we kill legacy nand support |
| 20:53.01 | hno | Ah, just found code showing how to read the boot area using aw driver. |
| 20:54.59 | mnemoc | \o/ |
| 21:32.13 | *** join/#arm-netbook cncman (~root@33.Red-213-97-57.staticIP.rima-tde.net) |
| 21:33.37 | cncman | i'm designing a pcb with allwinner a10,is it possible not to put nand flash and boot from microsd?? |
| 21:33.49 | hno | cncman, yes. |
| 21:34.01 | cncman | great |
| 21:34.20 | cncman | i can't get cheap flash modules |
| 21:34.31 | hno | if you don't have nand then you can easily have two SD slots. One for OS and one for removable storage. |
| 21:34.37 | mnemoc | you can also have two microsd slots (internal/external) |
| 21:34.43 | mnemoc | meh |
| 21:34.50 | hno | B) |
| 21:35.47 | mnemoc | :) |
| 21:36.50 | cncman | i'm going to do more research ,thx a lot |
| 21:37.09 | hno | cncman, MMC2 controller is on the same pins as NAND. |
| 21:37.35 | hno | boot order is MMC0, NAND, MMC2, SPI- |
| 21:39.29 | hno | Wonder if it works to push the NAND I/O with CPU instead of DMA. |
| 21:43.35 | mnemoc | -# CONFIG_SUN5I_A12 is not set |
| 21:43.36 | mnemoc | -CONFIG_SUN5I_A13=y |
| 21:43.48 | mnemoc | ^---- "nuclear" defconfigs... |
| 21:44.33 | rz2k | cncman: please check your datasheet, if you are designing with public available ones - be aware that ddr pins are messed up there. |
| 21:45.18 | rz2k | probably olimex a10-olinuxino can be used as reference design |
| 21:46.13 | mnemoc | the only open schematics actually used to make boards already is the cubie's |
| 21:46.32 | mnemoc | there is no prototype of the a10-olinuxino yet |
| 21:47.16 | rz2k | forgot that Tom released schematic :p |
| 21:47.49 | mnemoc | and the eoma68-a10 ended up been closed :< |
| 21:48.01 | cncman | opss, ddr pins are messed up?? wtf |
| 21:48.04 | mnemoc | the real cards i mean |
| 21:48.26 | cncman | and where can i find the good datasheets? |
| 21:48.42 | mnemoc | cncman: nowhere |
| 21:48.54 | cncman | olinuxino released a preview version of schematics |
| 21:49.00 | cncman | of a10 |
| 21:49.00 | mnemoc | cncman: the "reference design" is the good datasheet |
| 21:49.18 | mnemoc | yes |
| 21:49.25 | rz2k | cncman: in datasheets floating around ddr3 pins are wrong. use cubieboard schematic as a reference. or contact Allwinner and buy 10K pcs and get official datasheets without mistakes. |
| 21:49.36 | cncman | mmm..i don't have the allwinner official reference design |
| 21:50.25 | mnemoc | cncman: olimex's schematics are based in the known good info |
| 21:50.46 | cncman | rz2k: i have 100 chips, small fish for allwinner to contact |
| 21:51.04 | rz2k | yeah |
| 21:51.19 | mnemoc | cncman: http://dl.linux-sunxi.org/A10/ <--- datasheets (including leaked manual) |
| 21:51.41 | cncman | where is cubieboard schematic? |
| 21:51.52 | rz2k | I remember Tsvetan said that when they designed a13-olinuxino they found same crap in a13 datasheets |
| 21:51.55 | mnemoc | http://dl.cubieboard.org/hardware/ |
| 21:52.04 | mnemoc | cncman: ---^ |
| 21:52.10 | cncman | thx mnemoc |
| 21:52.38 | mnemoc | cncman: help moving reliable knowledge to the wiki is appreciated :) |
| 21:53.24 | mnemoc | cncman: on pages like http://linux-sunxi.org/A10/PIO |
| 21:53.38 | cncman | ok, today is my first day in the design, when i have more information, i'll contribute for sure |
| 21:53.46 | mnemoc | thanks |
| 21:54.29 | mnemoc | cncman: you might also want to look at the datasheet of the pmu. http://dl.linux-sunxi.org/AXP/ |
| 21:54.43 | mnemoc | axp202 and axp209 seem identical |
| 21:54.51 | mnemoc | the first has datasheet in english |
| 21:56.21 | hno | rz2k, last I heard the datasheet is correct, just using a different terminology than what's normal. |
| 21:56.58 | hno | rz2k, there is no other "official" datasheet for the pinouts. |
| 21:59.09 | mnemoc | hates having to do webapps :| |
| 21:59.19 | *** join/#arm-netbook zenitraM (~zenitraM@2607:f358:1:fed5:11:0:1018:14) |
| 21:59.33 | *** join/#arm-netbook ejstacey (~ejstacey@tha.joyrex.net) |
| 22:00.44 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 22:12.55 | *** join/#arm-netbook zenitraM (~zenitraM@jardin.itram.es) |
| 22:20.13 | Turl | "Awesome HKTDC Fair video covdrage coming up. Here's I'm playing on the awesome new $149 Archos Gamepad that runs on awesome RK3066 with Mali400mp4. Perhaps it can emulate all consoles perfectly up to N64, PSX and Dreamcast! Thin, light, form factor is awesome!" |
| 22:20.29 | Turl | 150$ for a 4-core mali? not bad :P |
| 22:20.50 | ZaEarl | rk3066 has taken over the market |
| 22:21.05 | mnemoc | ZaEarl: and the news from allwinner? :< |
| 22:22.02 | techn | what is price point for sun6i? |
| 22:23.40 | ZaEarl | anybody's guess at this point, but using the a7 cores are very small, so it should be a good price. |
| 22:27.42 | mnemoc | ZaEarl: did any factory confirmed you it's a quad a7? |
| 22:30.46 | cat1 | techn: please give me any ideas why i still get this :) |
| 22:30.46 | cat1 | [ 17.975] GET_UMP_SECURE_ID_BUF1 returned 0x1 offset: 0 virt address: 0xb60e6000 fb_virt: 0xb60e6000 |
| 22:30.46 | cat1 | [ 17.977] GET_UMP_SECURE_ID_BUF2 returned 0xffffffff offset: 3686400 virt address: (nil) fb_virt: 0xb60e6000 |
| 22:30.46 | cat1 | [ 17.979] (EE) MALI(0): [maliModifyPixmapHeader:205] UMP failed to retrieve secure id |
| 22:31.05 | penguin42 | mnemoc: it would be a little odd choice; but I guess it lets you claim quad core and a good quad core without being as large/complex as an A( |
| 22:31.22 | techn | cat1: you dont have that buf2 commit? |
| 22:31.51 | cat1 | i guess i do as i am using sunxi-3.4 |
| 22:32.50 | cat1 | techn: or it is not there.. |
| 22:32.53 | mnemoc | penguin42: the A7 is the little brother of the A15 |
| 22:33.36 | mnemoc | penguin42: so i suppose it counts as better than an A9 |
| 22:33.37 | penguin42 | mnemoc: That depends how you look at it; the A7 is the little brother; but as I recall it's performance is supposed to be somewhere between A8 and A9 |
| 22:34.56 | techn | cat1: I didn't find it with quick check :( |
| 22:35.24 | cat1 | techn: uh-oh.. mnemoc? :) |
| 22:36.41 | mnemoc | afaik 3.4 doesn't include 2 buffers support |
| 22:36.59 | mnemoc | fixes are in the next_mali branch for 3.0 |
| 22:38.17 | cat1 | mnemoc: ah, but why we cannot take them into 3.4? |
| 22:38.39 | mnemoc | if they aren't good enough for 3.0 yet, why would they be good for 3.4? |
| 22:38.46 | ZaEarl | mnemoc, yes, they've told me it's quad a7, but these are basically marketing people. they've been wrong before. |
| 22:40.33 | cat1 | mnemoc: dunno, but maybe it would be good to maintain 3.4 at the same level of usability as 3.0... |
| 22:40.47 | mnemoc | cat1: that's exactly where it is |
| 22:41.02 | mnemoc | cat1: 3.0 still has r2p4, as 3.4 |
| 22:41.15 | mnemoc | and no "2 buffers" |
| 22:41.53 | mnemoc | once techn/rz2k tell me to merge something from next_mali to 3.0, I'll do it for 3.4 too |
| 22:42.44 | ZaEarl | for an arm server I'd choose a15, but for a mobile device running on battery, a7 is an excellent choice |
| 22:43.00 | mnemoc | i think a7 is a good choice for allwinner's target too |
| 22:43.34 | hno | many-little :) |
| 22:43.40 | mnemoc | :p |
| 22:43.42 | cat1 | mnemoc: sorry, my bad, i forgotten this.. i just remember it was working for me in 3.6, but now i realized that i merged next_mali.. |
| 22:43.50 | mnemoc | :) |
| 22:44.44 | mnemoc | cat1: push techn/rz2k to get that mergeable :p |
| 22:45.10 | mnemoc | at least the dual buffer for r2p4 |
| 22:46.08 | mnemoc | i've never ever ever tried x11/mali myself. |
| 22:46.35 | mnemoc | so it's not my call to decide |
| 22:46.36 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 22:49.56 | *** join/#arm-netbook The-Compiler (~compiler@ubuntuusers/supporter/the-compiler) |
| 22:52.29 | techn | question is that is should me move to r3p0 since there is working android libs for that :p |
| 22:53.55 | mnemoc | yes, need to keep same version on both worlds |
| 22:56.30 | rz2k | actually we can provide both r2p4 and r3p0/1, afaik we have r2p4 just sort of "integrated" in kernel build but it is another build invoking makefiles and such stuff detachable from kernel. I was able to build working r3p1 drivers just for test without libs and they loaded up. |
| 22:57.01 | rz2k | buf1/2 stuff can be ifdef'ed with selection of r2 or r3 |
| 22:57.36 | rz2k | also some time ago we had mali in /modules/ |
| 22:59.48 | mnemoc | we need it in tree to be able to do drm/ump integration |
| 23:00.38 | mnemoc | android doesn't care, but x11 does |
| 23:00.49 | rz2k | ump is also builds ok with our kernel |
| 23:00.53 | rz2k | from r3p1 |
| 23:01.15 | rz2k | I've copied our setup from r2p4 to right place in ump and it worked |
| 23:02.32 | mnemoc | i like the idea of updating to r3p0 better :p |
| 23:02.53 | mnemoc | we only need it to work "as-good" as r2p4 |
| 23:03.04 | rz2k | yeah, but only sort-of working opengles x11 is r2p4 on armel... |
| 23:03.16 | mnemoc | :< |
| 23:04.50 | mnemoc | what i don't understand is why cat1 is getting those dual-buffer errors in 3.4 |
| 23:04.59 | mnemoc | having r2p4 |
| 23:06.13 | rz2k | probably he grabbed my x11 drivers repo with build script :p |
| 23:06.29 | hno | mnemoc, I keep getting moderation requests for linux-sunxi, but apparently have no permission to moderate? |
| 23:06.29 | cat1 | rz2k: nope, i did not :) |
| 23:06.53 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 23:07.18 | mnemoc | hno: i think the permission error happens when messages are already moderated/passed |
| 23:07.20 | rz2k | cat1: r2p4 x11 doesnt have GET_UMP_SECURE_ID_BUF2 ioctl at all |
| 23:07.24 | cat1 | rz2k: maybe because i am using r3p0? |
| 23:07.38 | rz2k | %) |
| 23:08.14 | mnemoc | cat1: doh |
| 23:08.34 | hno | mnemoc, I don't see the last message ("LiveSuite uses awusb driver that has some trivial bugs") accepted. |
| 23:08.48 | mnemoc | uhm |
| 23:09.02 | rz2k | mnemoc: hno has same error as me. |
| 23:09.06 | cat1 | mnemoc: rz2k: yeah, it is a bit messy.. but rather in my head :) |
| 23:09.36 | mnemoc | hno: true. https://groups.google.com/forum/?hl=en-GB&fromgroups#!pendingmsg/linux-sunxi still has it |
| 23:09.40 | rz2k | I still think that it is bug in google groups |
| 23:10.00 | mnemoc | hno: but you are manager... should have permissions.... let me look |
| 23:10.04 | rz2k | Permission to manage messages denied |
| 23:10.59 | mnemoc | try now |
| 23:11.36 | hno | mnemoc, works better! |
| 23:12.14 | rz2k | same here. thanks mnemoc |
| 23:12.39 | mnemoc | great |
| 23:13.01 | cat1 | rz2k: any chance to get some r3pX-compatible stuff released, let's say into sunxi-3.4? |
| 23:13.59 | mnemoc | for r3p0 we have android and linux armhf libs |
| 23:14.45 | mnemoc | but do they work? :| |
| 23:14.45 | cat1 | mnemoc: yeah, but kernel lags behind a little bit :) |
| 23:15.08 | rz2k | for now, if you use r3 mali you need to commit https://github.com/linux-sunxi/linux-sunxi/commit/05b817314dfe0543aba938d496f9ff30a5545134 this to your tree/branch. |
| 23:16.25 | rz2k | that is the missing part, https://github.com/linux-sunxi/linux-sunxi/commit/c8c9ae7ef2bec34dc529bba763f36e8d3b1b4266 is independent from mali version (also ARM didnt change this from like r2p0 2009 or so). |
| 23:16.33 | techn | linux x11 libs doesnt work (missing symbols).. noone linux framebuffer libs |
| 23:16.35 | cat1 | rz2k: thanks, but it does not apply cleanly against 3.4 :( |
| 23:16.45 | techn | *none has tried |
| 23:17.52 | mnemoc | cat1: make a next_mali upon 3.4 and test it. your fixes in 3.4 should also apply to 3.0's |
| 23:18.05 | rz2k | mm, you mean DRM commit? because there can be actually some changes in DRM between 3.0.42 and what you use. previous issue with DRM was caused by changes in DRM between 2.6.38 and 3.0.x |
| 23:18.07 | mnemoc | and eventually both get merged |
| 23:18.21 | cat1 | rz2k: nope, the previous, fb one |
| 23:19.08 | rz2k | here you need poke hno as author of disp-ump and techn as guy who fixed it to r3 :p |
| 23:20.09 | hno | knows nothing about disp-ump, only haced up the basics to show how to split ump from disp. |
| 23:20.48 | cat1 | rz2k: no worries, i think i will manage to merge it, but probably a bit later today, it is 2:18AM here already :) |
| 23:21.23 | hno | :20 more likely. |
| 23:21.36 | techn | btw.. there now somewhat working hack for edid https://github.com/techn/linux-allwinner/commits/wip/edid .. use it with your own responsibility.. I'm not gonna pay your fried monitors :D |
| 23:21.44 | cat1 | hno: it took 2 minutes to write that :D |
| 23:22.57 | techn | .. it needs some work still every mode wont work :( |
| 23:24.41 | mnemoc | it seems we will need a repo for allwinner tools for linux, and so apply that patch |
| 23:24.56 | mnemoc | going to sleep. good night |
| 23:25.04 | cat1 | is about to make an attempt of creeping into bedroom w/o awaking wife.. |
| 23:25.06 | techn | same.. good night |
| 23:25.19 | cat1 | g'night all |
| 23:25.22 | hno | too. |
| 23:33.28 | rz2k | night. |
| 23:33.57 | *** join/#arm-netbook mikey_w (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 23:34.12 | *** join/#arm-netbook n6pfk (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 23:36.50 | *** join/#arm-netbook popolon_ (~popolon@og-free.planet-service.fr) |
| 23:43.59 | *** join/#arm-netbook QingPei (~qingpei@114.217.185.222) |
| 23:50.17 | *** join/#arm-netbook ZaEarl_ (~malmrose@202.155.242.30) |
| 23:53.26 | *** join/#arm-netbook ZaEarl__ (~malmrose@202.155.242.30) |
| 23:59.37 | *** part/#arm-netbook QingPei (~qingpei@114.217.185.222) |