| 00:10.38 | drachensun | I've been digging through the chat log and ceo16 managed a succesful build but said he had to use g++-4.5 not 4.6 |
| 00:10.58 | drachensun | rellla: do you know compiler version you have? |
| 00:11.22 | drachensun | I tried to install 4.5 but from apt only 4.4 and 4.6 were available ( I think) |
| 00:11.32 | drachensun | and 4.4 has problems also |
| 00:16.29 | lundman | now I've got to rememer how to unpack a dep file |
| 00:38.02 | lundman | hmm new xbmc does not start in 1080p mode |
| 01:33.02 | *** join/#arm-netbook gzamboni (~gzamboni@2a02-8426-513b-5100-0224-21ff-fe57-307c.rev.sfr.net) |
| 01:37.09 | *** join/#arm-netbook Lupu_ (566b65f5@gateway/web/freenode/ip.86.107.101.245) |
| 01:38.42 | *** join/#arm-netbook Lupul (~lupu@86.107.101.183) |
| 02:15.33 | *** join/#arm-netbook destinal (destinal@unaffiliated/destinal) |
| 02:16.01 | *** join/#arm-netbook dyoung-away (dyoung@2001:4800:780e:510:7cfc:f3f0:ff04:36e3) |
| 02:16.26 | *** join/#arm-netbook dyoung (dyoung@nasadmin/dyoung) |
| 02:27.00 | *** join/#arm-netbook QingPei (~qingpei@219.141.159.54) |
| 02:57.22 | drachensun | lundman: can you put the package up for download? |
| 03:01.14 | *** join/#arm-netbook tekzilla (~jon@hmbg-5f76690a.pool.mediaWays.net) |
| 03:02.51 | lundman | already is |
| 03:04.12 | drachensun | the build deb package? would you mind sending a link? |
| 03:04.35 | drachensun | built deb package I mean |
| 03:05.21 | lundman | http://www.lundman.net/ftp/mele/xbmca10-101012.tar.gz |
| 03:06.56 | *** join/#arm-netbook mSquare (~selvan@122.172.242.200) |
| 03:08.11 | drachensun | excellent, thanks |
| 03:08.28 | drachensun | the other guys package file was 87 M |
| 04:21.43 | *** join/#arm-netbook wingrime (~AndChat12@213.87.240.43) |
| 05:27.39 | *** join/#arm-netbook rellla (~Thunderbi@p5B0793DC.dip0.t-ipconnect.de) |
| 05:42.23 | rellla | drachensun: if I can trust my config.log, then it was 4.6.3-11 |
| 05:48.09 | *** join/#arm-netbook QingPei (~qingpei@219.141.159.46) |
| 05:59.01 | *** part/#arm-netbook QingPei (~qingpei@219.141.159.46) |
| 06:27.48 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 06:42.40 | *** join/#arm-netbook Quarx (~Quarx@178.74.72.161) |
| 06:51.12 | rellla | morning all |
| 06:52.02 | lundman | rella |
| 06:52.20 | lundman | I'm guessing your hilight colours of course :) |
| 06:53.29 | rellla | ;-) |
| 06:53.29 | rellla | since yesterday my mele isn't booting anymore |
| 06:53.29 | rellla | what does that mean: [sw_hcd0]: <0>Internal error: Oops - undefined instruction: 0 [#1] PREEMPT |
| 06:53.29 | rellla | full log: http://pastebin.com/ePbxPDU4 |
| 06:53.44 | rellla | something corrupted? |
| 06:54.21 | lundman | undefined instruction, that is new |
| 06:55.05 | rm | rellla, did this kernel ever boot for you? |
| 06:55.37 | rellla | yes, i did a 6h compile orgy and xbmc testing yesterday |
| 06:58.16 | rm | well, no idea other than afaik enabling preemption in the kernel config is a bad idea |
| 06:59.02 | rellla | it was the def-config from amerys branch |
| 06:59.19 | lundman | yeah why is everyone turning on PREEMPTIVE.. i think they might believe that means preemptive :) |
| 06:59.35 | lundman | maybe the uImage was corrupted, with 00s |
| 07:00.40 | rellla | i'll try recopy uImage and libs later ... |
| 07:01.43 | rm | defconfig has a number of stupid things :P |
| 07:01.55 | rm | like enabling tickless |
| 07:02.01 | rm | which is not even supposed to work afaik |
| 07:19.36 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 07:20.40 | oliv3r | I got a10 hardware for my birthday, :D |
| 07:23.26 | lundman | \o/ |
| 07:23.39 | mnemoc | :) |
| 07:23.44 | mnemoc | oliv3r: happy birthday ;-) |
| 07:24.17 | popolon | happy birthday |
| 07:27.38 | valhalla | oliv3r: happy hacking birthday |
| 07:38.01 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 07:50.00 | *** join/#arm-netbook phh (~quassel@137.194.15.151) |
| 07:51.34 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-220-30.cust.bredband2.com) |
| 07:52.53 | *** join/#arm-netbook sspiff (~quassel@103.4-78-194.adsl-static.isp.belgacom.be) |
| 07:52.54 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 08:03.16 | oliv3r | finally! :p |
| 08:03.21 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 08:03.23 | oliv3r | no mele though; a tablet |
| 08:03.35 | oliv3r | <PROTECTED> |
| 08:03.56 | oliv3r | it has uSD slot, so should be able to boot from it :) |
| 08:04.44 | mnemoc | yes |
| 08:06.37 | mnemoc | and so to play with the registers ;-) |
| 08:06.45 | oliv3r | gonna install cm9/10 first on it though (the default android is horrible) and start playing with uBoot etc via SD |
| 08:06.53 | oliv3r | and! play with registers :D |
| 08:06.58 | oliv3r | and hopefully not break it :p |
| 08:07.28 | mnemoc | http://linux-sunxi.org/Starting_a_CyanogenMod_device_tree |
| 08:07.40 | oliv3r | but thre's some learning curve to go passing by :p; I really have to refrain myself from starting with registers, so I can finish on the documentation :) |
| 08:07.51 | oliv3r | there's no clockworkmod tree is there |
| 08:08.08 | oliv3r | on the wiki; anyway, if i discover anything i'll write a page on it |
| 08:08.14 | mnemoc | :) |
| 08:08.29 | mnemoc | refactoring existing pages is also welcomed |
| 08:08.56 | mnemoc | every tutorial decided to teach (again) how to install a compiler :| |
| 08:09.04 | oliv3r | while linux documentation overal is good and things are wel explained, i find android/roms to be more like the 90's 'warez' scene, zips, binaries and half/vague instructions |
| 08:09.14 | oliv3r | <- gentoo user |
| 08:09.36 | mnemoc | there are many gentoo users here |
| 08:09.42 | mnemoc | but not me :p |
| 08:09.46 | oliv3r | lol |
| 08:12.48 | oliv3r | http://linux-sunxi.org/CWM_on_a_SDCard |
| 08:13.17 | oliv3r | its redumentary but there's _something_ :p |
| 08:15.18 | zub | rm: I'd also vote for cleaning up defconfig, as some options seems wrong/useless |
| 08:16.23 | mnemoc | patches welcomed |
| 08:16.23 | zub | rm: btw. I've been playing with my "minimal config" and I keep running into strange issues, crashes on boot. It seems to be related to CONFIG_PREEMPT |
| 08:16.34 | zub | rm: and CONFIG_BLK_DEV_INTEGRITY |
| 08:16.49 | rm | zub, https://github.com/amery/linux-allwinner/issues/52 |
| 08:16.58 | zub | mnemoc: I think I already used up my credit :( and I'm not really sure myself what should be included in the defconfig, jsut some options seems obviously useless, while some just suspect |
| 08:17.46 | mnemoc | the problem with preempt should now be solved with the fix on the regulator detection and the changes in the clock handling |
| 08:18.02 | zub | rm: thx |
| 08:18.23 | mnemoc | rm: i would rather take a patch |
| 08:18.55 | mnemoc | #52 is more of a wishlist |
| 08:18.56 | oliv3r | What are the differences in speed between a reasonable fast SD card, and the onboard nand? how fast IS the nand? will i notice much difference in speed when using an older 512mb SD card for example (for testing) |
| 08:19.21 | mnemoc | oliv3r: I personally totally ignore the NAND |
| 08:19.53 | mnemoc | it's driver is crap and loves to halt the world when there is some writting |
| 08:19.59 | oliv3r | good, since i have an arsenal of old SD cards (512MiB-8GiB) |
| 08:20.17 | oliv3r | one of the 'improvements' needed I assume?/ |
| 08:20.45 | mnemoc | totaly rewrite I would say :| |
| 08:20.56 | mnemoc | but we still don't know enough about the nandc to do so |
| 08:21.03 | oliv3r | :S |
| 08:21.11 | mnemoc | using mtd |
| 08:21.45 | zub | mnemoc: I've been getting crashes somewhere in drivers/usb/sun4i_usb/hcd/hcd0/*: http://linux.fjfi.cvut.cz/~zub/crash.log |
| 08:21.54 | zub | but have not had time to investigate deeper |
| 08:22.01 | mnemoc | zub: how old is your kernel? |
| 08:22.02 | zub | it seems to be randomly caused by changing config |
| 08:22.04 | oliv3r | the hardware DOES expoxe the mtd 'layer'? |
| 08:22.19 | mnemoc | nope |
| 08:22.27 | zub | fea836a3876514a9097de4fe6181d0cb1b332a44 is the latest commit, linux-sunxi-3.4 |
| 08:22.31 | zub | so I think it's up to date |
| 08:23.19 | mnemoc | usb on 3.4 is known to have troubles, yes |
| 08:23.29 | mnemoc | the forward-port is still incomplete |
| 08:23.34 | mnemoc | specially on the gadget side |
| 08:23.48 | mnemoc | but needs love in general |
| 08:23.53 | zub | mnemoc: the actual line that dies is "status = usb_add_hcd(sw_hcd_to_hcd(sw_hcd), -1, 0);" (line 1480 in sw_hcd0.c), and that is caused by usb_add_hcd (dies in dev_info(hcd->self.controller, "%s\n", hcd->product_desc); |
| 08:24.20 | zub | the pointr is not null... but apart form that I don't know how/why dies it explode |
| 08:24.40 | mnemoc | zub: we still don't have usb maintainer... do you volunteer? ;-) |
| 08:25.12 | zub | funny thing is it's sort-of-random, I didn't figure out one config item that causes it... it seems idfferent ocnfig = different result, maybe affected by build |
| 08:25.29 | zub | mnemoc: I have already failed |
| 08:25.45 | zub | if you need some touchscreen hacks, or freescale framebuffer hacks, I could know something :-P |
| 08:25.55 | zub | too bad there's not freescale FB on the allwinner :) |
| 08:25.57 | mnemoc | failure is a requirement to real success ;-) |
| 08:32.49 | zub | I already asked, but let me try again: CONFIG_BLK_DEV_INTEGRITY - does this make sense on the allwinner? does it even do anything at all? it's on in the defconfig |
| 08:33.23 | mnemoc | silence usually means "no idea" |
| 08:33.54 | zub | it seems to have affected the crashes with usb, but it could be that just the code is laid out differently/soem random effect |
| 08:35.44 | zub | btw. anybody here is using gdb/something to debug the kernel? I guess JTAG is one option. Bit what about things like kgdb? (I don't have JTAG. I guess I could get it via the uSD hack, but don't have it so far.) |
| 08:37.27 | mnemoc | hno and RaYmAn use jtag |
| 08:38.21 | mnemoc | i bought one, but haven't needed to learn to use it yet... |
| 08:38.33 | zub | so you're going with printk? :) |
| 08:38.40 | mnemoc | yup :p |
| 08:38.51 | zub | what irritates me the most is inserting/removing the uSD all the time... :( |
| 08:39.19 | zub | MK802+ doesn't have the eth connected, so I guess I can't boot from net even if uBoot could do it; maybe boot-over-serial (never tried) |
| 08:39.37 | mnemoc | i keep two uImage files, if the development one fails I tell u-boot to use the known-to-work one |
| 08:40.04 | mnemoc | zub: you can try using `fel` |
| 08:40.09 | zub | ah, and then you update the uImage w/o removing the card. good idea |
| 08:41.04 | zub | mnemoc: is it possible to use FEL to receive and start an uImage? |
| 08:41.51 | zub | (or, well, any kernel image) |
| 08:44.00 | mnemoc | spl + atags + uImage, theoretically should work |
| 08:44.39 | zub | A10 is magic! :) |
| 08:44.54 | zub | I think two uImages will work for me, that sounds easy enough |
| 08:45.13 | mnemoc | err. spl + atags + script.bin + kernel image |
| 08:45.44 | mnemoc | works for me well enough to not need to explore other options yet ;-) |
| 08:49.05 | mnemoc | zub: the A10 is VERY hacker friendly |
| 08:51.11 | lundman | gets a 8/10 in hacking, and 6/10 for developer :) |
| 08:51.31 | *** join/#arm-netbook ZaEarl (~malmrose@202.155.242.30) |
| 08:51.42 | mnemoc | a 2/10 for user wanting video decoding on linux :< |
| 08:54.49 | RaYmAn | mnemoc: psh, next thing, you'll say tegra is very hacker friendly |
| 08:54.50 | RaYmAn | :P |
| 08:56.56 | *** join/#arm-netbook ZaEarl_ (~malmrose@202.155.242.30) |
| 08:57.06 | ZaEarl_ | ugh, crummy hotel wifi |
| 08:57.26 | rellla | rm: doing a recopy of uImage and kernel libs did it. it's online again ;-) |
| 09:01.47 | mnemoc | RaYmAn: :p |
| 09:02.26 | mnemoc | RaYmAn: i meant the design of the chip itself.... the lack of documentation and crappy code hurts obviusly |
| 09:04.34 | RaYmAn | ;) |
| 09:05.08 | RaYmAn | Tegra isn't very friendly at all. You look at it wrong and it starts to sleep-of-death |
| 09:05.45 | RaYmAn | (Seriously - ASUS disabled the low-power core in their JB release for the tegra3 tablets because of SOD) |
| 09:07.02 | mnemoc | o_O |
| 09:09.14 | oliv3r | ironically, video decoding in linux is 8/10 for me :) |
| 09:10.04 | ZaEarl | anyone else in Hong Kong this week? |
| 09:10.21 | zub | I wish :) |
| 09:11.01 | oliv3r | next to searching all over the net, what's the best option to identify the harware in my tablet? I'll get busybox with lsusb and lspci to work; but then there's probably some i2c hardware? |
| 09:11.49 | mnemoc | oliv3r: usually people takes them apart :p |
| 09:12.10 | ZaEarl | oliv3r, a lot of devices don't show up in lsusb/lspci |
| 09:13.18 | oliv3r | zaearl why not? I'd expect anything connected to those busses to show up |
| 09:13.38 | mnemoc | ts for example is usually connected via i2c |
| 09:13.41 | oliv3r | oh, gotta look for some teardown pics/stuff; the yarvic tab26[04]/momo9 is quite common |
| 09:13.44 | ZaEarl | because they're connected other ways |
| 09:13.51 | oliv3r | ah, well duh then :) |
| 09:14.00 | zub | wasn't there some tool to list stuff on i2c (to the extent the stuff can be probed...) |
| 09:14.10 | oliv3r | i know lm_sensors probes stuff with sensors detect |
| 09:15.10 | zub | http://www.lm-sensors.org/wiki/I2CTools |
| 09:15.18 | rellla | strange behaviour: boot up mele->ok, 1st reboot->ok, 2nd reboot->kernel hangs, recopy uImage, boot->ok !? kernel version 3.0.42 |
| 09:15.52 | mnemoc | rellla: got a serial console? |
| 09:15.55 | rellla | yep |
| 09:16.03 | mnemoc | rellla: where does it hang? |
| 09:16.47 | ZaEarl | I haven't seen hipboi in ages. Anyone know what he's been up to? |
| 09:17.05 | rellla | once it was this sw_hcd PREEMT-thing I mentioned above, i try to reproduce and post log |
| 09:17.18 | rellla | ...waiting 10s for reboot.... |
| 09:17.28 | mnemoc | he is usually available on xmpp/gtalk from an android phone |
| 09:17.32 | oliv3r | saw him log on/off yeseterday? day before yesterday for sure |
| 09:18.16 | ZaEarl | nickserv says he hasn't been on for 4 weeks. |
| 09:18.20 | zub | sw_hcd... |
| 09:18.44 | mnemoc | ZaEarl: that only counts users when they authenticate |
| 09:19.21 | mnemoc | ZaEarl: btw, sw_ is short of softwinner... one of the old alter-egos of allwinner's software division |
| 09:19.24 | mnemoc | err |
| 09:19.31 | mnemoc | zub: btw, sw_ is short of softwinner... one of the old alter-egos of allwinner's software division |
| 09:19.42 | mnemoc | ZaEarl: sorry, wrong <tab> completion |
| 09:20.00 | zub | mnemoc: softwinner, hardwinner, allwinner... :) |
| 09:20.30 | oliv3r | I saw on the mailing list, that the A10 rev C has a bug with PLL4 (sata?); /proc/cpuinfo does list some form of rev numbers, but mine is 'rev 2'. I doubt there's been 11 revisions since? the rev C correlate to the /proc/cpuinfo? |
| 09:20.59 | mnemoc | oliv3r: afaik all new A10 chips are rev C |
| 09:21.04 | oliv3r | boxchip may have been better |
| 09:21.08 | oliv3r | :p |
| 09:21.20 | oliv3r | mnemoc: well version 2, could be rev B then? |
| 09:21.43 | mnemoc | i guess so |
| 09:21.57 | mnemoc | unless the code counts from 0 |
| 09:22.13 | RaYmAn | i2cdetect is..well.. unstable by definition. There's no standard way to detect if a device is present on the i2c bus (it's device specific to the target device) |
| 09:22.21 | oliv3r | true, well tablets don't use sata ports anyway, so it shouldn't matter, but still |
| 09:22.27 | RaYmAn | but you can probably find some info from sysfs i2c stuff |
| 09:22.49 | oliv3r | well on a pre-configured running stock ROM you should get most/all i2c connected devices i'd say |
| 09:23.14 | RaYmAn | sure, but i2cdetect will not necessarily show them all (is my point) |
| 09:24.32 | oliv3r | yeah, i guess they guestimate on based on known chips |
| 09:30.30 | *** join/#arm-netbook jquip (~johnny@223.178.64.107) |
| 09:31.28 | oliv3r | does anybody use any of the windows only tools? Like 'redscorpio's' tools etc? Do they work reliably in wine? I guess any big fuckup can be fixed by booting via uSD? as long as you don't break the BROM |
| 09:32.16 | RaYmAn | If possible, it's a good idea to dump boot0 and boot1 before starting to play |
| 09:32.34 | RaYmAn | but might require JTAG to do properly |
| 09:32.43 | ZaEarl | oliv3r, yeah, a lot of that stuff works nicely in wine |
| 09:32.55 | ZaEarl | you can't break brom |
| 09:33.37 | oliv3r | i'd imagine that with jtag you can still flash BROM, oth, it also makes a lot of sense if it where true rom baked into the asic |
| 09:33.51 | RaYmAn | indeed, but you can end up in a place where your device no longer works if you don't have the boot0/boot1 because they contains ram initialization parameters and similar |
| 09:34.11 | ZaEarl | right, so keep a LiveSuit image around. |
| 09:34.13 | RaYmAn | also, no , BROM is read only |
| 09:34.55 | oliv3r | so boot0/boot1 is still read (by BROM) even when booting from uSD? |
| 09:35.04 | mnemoc | nope |
| 09:35.23 | mnemoc | when booting from uSD both are bypassed |
| 09:36.35 | oliv3r | so in theory, i could fill the entire nand with 0; only have BROM working (duh) and safely boot from uSD and restore boot0/1 (from a backup) |
| 09:37.16 | RaYmAn | we don't know how to access the part of the nand that contains boot0/boot1 :/ |
| 09:37.23 | RaYmAn | but otherwise, yes |
| 09:38.06 | oliv3r | so you cannot end up in a place where you cannot boot, as long as you have a workable bootable uSD card then |
| 09:38.13 | RaYmAn | correct |
| 09:38.19 | ZaEarl | LiveSuit can install a fresh rom without booting the device |
| 09:38.33 | RaYmAn | ZaEarl: it kind of assumes you have a livesuit image for your device |
| 09:38.35 | RaYmAn | or a compatible one |
| 09:38.38 | oliv3r | livesuit a DFU utility? (direct flash) |
| 09:38.39 | ZaEarl | of course |
| 09:39.04 | mnemoc | he code to do raw access to the nand is available... we only need time and willing to dive into it and export those raw blocks as a /dev |
| 09:39.12 | mnemoc | s/he/the/ |
| 09:39.17 | RaYmAn | ah |
| 09:39.33 | RaYmAn | mnemoc: where? |
| 09:40.03 | mnemoc | in drivers/block/sunxi_nand/ :) |
| 09:40.04 | ZaEarl | there are tons of generic livesuit images out there, that'll restore basic funcationality to most devices |
| 09:43.00 | RaYmAn | ZaEarl: yes, assuming they have compatible ram. |
| 09:43.56 | oliv3r | once you have restored some functionality via livesuite, you can always go from there I suppose |
| 09:44.12 | oliv3r | I guess a 'livesuite' image, is nothing mmore then a complete nand dump |
| 09:44.34 | RaYmAn | in essense, yeah (as usual, it's a bit more than that, but yeah) |
| 09:44.40 | ZaEarl | it's a bit more complicated than that |
| 09:44.40 | oliv3r | inc. the android stuff? or just boot stuff, u-boot etc |
| 09:44.51 | mnemoc | livesuit seems to do some probing and write whatever it wants in boot1's header. not exactly what is in the provided script.bin |
| 09:45.25 | oliv3r | well since we can't access boot0 and boot1 yet, doinga complete dump is imposslbe atm anyhow |
| 09:45.40 | mnemoc | oliv3r: we can, from nand's uboot |
| 09:45.41 | RaYmAn | without jtag, yeah |
| 09:45.57 | oliv3r | oh, so with jtag we can doa full dump |
| 09:46.01 | RaYmAn | even if jtag can't access nand, it's possible to dump it from memory |
| 09:46.09 | oliv3r | maybe i should talk to hipboi and see if he sells me one of those uSD -> jtag adapters |
| 09:46.32 | zub | what is the relationship between boot0/boot1 and /dev/nand? |
| 09:46.37 | oliv3r | mnemoc: oh; so if i boot into a proper u-boot from uSD, i can use that to dump the full nand? |
| 09:46.53 | mnemoc | oliv3r: no, only if you boot from nand's u-boot |
| 09:46.59 | zub | is boot0/boot1 in an area that is not visible in /dev/nand? |
| 09:47.04 | oliv3r | so based on zub's question, I'd assume, the linux/android kernel doesn't expose ALL of the flash in /dev/nand |
| 09:47.05 | *** join/#arm-netbook ZaEarl_ (~malmrose@202.155.242.30) |
| 09:47.16 | RaYmAn | zub: yes |
| 09:47.16 | mnemoc | oliv3r: only the logical layer |
| 09:47.29 | zub | :( |
| 09:47.33 | mnemoc | boot0/boot1 live before that |
| 09:47.40 | oliv3r | mnemoc: confusing, but I understand, the original u-boot knows more and thus exposes it properly |
| 09:47.41 | RaYmAn | mnemoc: it must be slightly more complicated than that, otherwise the /dev/nand expose patch would make it appear |
| 09:47.53 | zub | btw. how does the nan partitioning (/dev/nanda, /dev/nandb...) work? can we alter the partitioning? |
| 09:47.56 | zub | nand |
| 09:48.19 | mnemoc | zub: there is a tool in sunxi-tools to repartition /dev/nand |
| 09:48.20 | oliv3r | is this info on the wiki btw? instead of bombing you with the same questions over and over :) |
| 09:48.32 | oliv3r | mnemoc: i assume to partition only the 'known' region |
| 09:48.49 | mnemoc | oliv3r: the logical layer, yes |
| 09:48.57 | oliv3r | so the A10 doesn't need to be told what the partition sizes are! (I know some phones with mtd based partitions, get told the partition sizes at boot time) |
| 09:49.20 | mnemoc | /dev/nand has a custom partition table |
| 09:49.33 | mnemoc | in the first block before nanda |
| 09:50.22 | mnemoc | but "the tool" deals with that |
| 09:50.23 | oliv3r | yeah but the partition table is (exposed) actually written to nand! that's good :) my phone doesn't have a partition table, i think the internal SPL/bootloader tells the kernel the partition dimensions via mtd= boot cmdline |
| 09:50.34 | mnemoc | yuck |
| 09:50.46 | zub | oliv3r: yup, seen that with mtd too |
| 09:50.50 | oliv3r | well it is 'stored' in some way I suppose :) |
| 09:51.18 | oliv3r | you can modify it, but only by overriding the mtd parameter, i think the spl stored value, is no way around it. a lot of phones actually do it that way it seems |
| 09:52.55 | zub | oliv3r: you could hack the kernel to ignore the supplied mtd and use some hardcoded :) |
| 09:53.02 | oliv3r | well yeah |
| 09:53.03 | zub | yay for ugly hacks! |
| 09:53.20 | mnemoc | that's the way of "the industry" |
| 09:54.14 | oliv3r | I still fail to understand why are they so hard trying to make it 'annoying' (not hard, not difficult, just annoying). |
| 09:54.22 | mnemoc | "get it done now! no one cares how. but it has to be done NOW!" |
| 09:54.24 | oliv3r | regular consumers aren't ever gonna mess with this |
| 09:54.38 | oliv3r | i ment their 'protection ''schemes''' |
| 09:54.52 | oliv3r | but yeah, crappy code is deffinatly in that department |
| 09:55.10 | oliv3r | I guess on the hardware side they shouldn't be allowed to work that way |
| 09:55.14 | mnemoc | carriers claim they protect the networks |
| 09:55.20 | oliv3r | it's hard to release a software update for a hardware flaw :) |
| 09:55.24 | mnemoc | because a rooted phone is a liability |
| 09:55.40 | oliv3r | that may be true and well |
| 09:55.53 | *** join/#arm-netbook pawel5870 (~pkarpins@pc.193147149.ip.amg.net.pl) |
| 09:55.55 | oliv3r | but you can have hacker friendly hardware, and still sell unrooted phones |
| 09:56.07 | oliv3r | my tablet btw, came pre-rooted |
| 09:56.20 | oliv3r | no official market, and I think it runs some development mode rom |
| 09:56.25 | mnemoc | that's the case for most A10 devices |
| 09:56.39 | oliv3r | Ah ok |
| 09:56.39 | zub | I hate the idea of me buyin a device and not being allowed to do whatever I polease with it. I paid the $. Now give me my device w/o stupid DRM/locks/... |
| 09:56.48 | oliv3r | exactly |
| 09:57.04 | mnemoc | zub: apple fanboy I presume ;-) |
| 09:57.10 | oliv3r | *I* worked for the money, *I* bought the device, *I* own it, yet i cannot do whatever I please with it |
| 09:57.27 | zub | mnemoc: ehm? never had any apple device and I don't plan to buy any |
| 09:57.37 | oliv3r | (cedar/mali even here applies, boot0/1 etc follows) |
| 09:57.38 | zub | mnemoc: I prefer Allwinner to Apple :-P |
| 09:58.39 | oliv3r | I must say, I do find the A10 SoC very very interesting chip (probably due to its hacker friendlyness/price) |
| 09:58.40 | mnemoc | same. no sony, no apple, no amazon. no any device from a company who believes they need to keep control of the products after they are sold |
| 09:59.11 | zub | but I bought an HTC phone. Part of that $ came to M$ (patents). :( |
| 09:59.24 | zub | and it was locked, but I picked one that was easy to root |
| 09:59.32 | ZaEarl_ | now, if we could just get the OEMs to respect the GPL |
| 09:59.34 | oliv3r | i got an old (used) iPhone 3gs from work, that i had for a few days and traded it for an old very little used HTC hero |
| 09:59.47 | oliv3r | but it was free, so can't complain. I do own a samsung washingmachine though :) |
| 09:59.53 | zub | :) |
| 09:59.59 | zub | oliv3r: does it have JTAG? :) |
| 10:02.12 | RaYmAn | hacking your washingmachine seems like taking things a bit far :P |
| 10:02.58 | mnemoc | but hacking those cleaning robots seems fun :p |
| 10:03.20 | RaYmAn | yeah |
| 10:08.09 | oliv3r | lol haven't it opened it yet :D |
| 10:08.34 | oliv3r | RaYmAn: now, maybe, but in time, when we have all opensource sofware everywhere, we'll need a new challange i'm sue :p |
| 10:08.48 | oliv3r | also, washing mashines will get more 'powerfull' and will feature a true OS at some point |
| 10:08.54 | oliv3r | think, touch screen, 'options' |
| 10:09.05 | zub | "clone my great washing programme from git:/... :)" |
| 10:09.22 | oliv3r | washes twice as clean, twice as fast, at half the cost |
| 10:09.43 | oliv3r | and no more reboots! |
| 10:10.12 | oliv3r | hmm, the momo9 tablet (twin brother it is said, or rebadged) boots from USB |
| 10:11.42 | mnemoc | oliv3r: http://linux-sunxi.org/Momo9 |
| 10:11.48 | oliv3r | oh! |
| 10:12.02 | oliv3r | do'hh I should have looked (but i still have 8 tabs open needing some reading :p) |
| 10:12.13 | mnemoc | nah, it's still empty |
| 10:12.56 | oliv3r | lol |
| 10:21.06 | oliv3r | right, all this talking and having lunchmeans i haven't started on finishing the timers page, which i'll get to in a few :) |
| 10:21.24 | mnemoc | good idea :) |
| 10:29.12 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 10:31.57 | mnemoc | hno: around? |
| 10:37.33 | andoma | anyone been using mali together with FB? |
| 10:37.38 | andoma | i get lots of tearing artifacts, etc |
| 10:38.06 | mnemoc | hno: http://sprunge.us/eRRH?diff <--- reworked memory mangling proposal |
| 10:42.50 | oliv3r | one last question before I get to work; all those CWM/Android flashing 'tools/instructions' don't really do anything other then format/mount/rm -rf/extract? If I change the partitioning scheme, those all should remain to work error-free I assume |
| 10:43.18 | mnemoc | CWM/Android flashing are windows-people oriented |
| 10:44.54 | mnemoc | but livesuit images come with encrypted partition images and a .fex file including repartitioning info |
| 10:45.06 | mnemoc | so it will kill anything you do |
| 10:48.08 | oliv3r | yeah, everything is dumbed down too much imo and it's all 'hacker-secret-club' sorta thing |
| 10:48.17 | oliv3r | anyhow, the stock software is quite crap, and some people have build CM9 roms and CWM roms, so installing those should be no prblem after partitioning :) |
| 10:48.58 | mnemoc | Turl has a pretty clean tree for CM10 for A10 |
| 10:49.11 | *** join/#arm-netbook rz2k (~rzk@95-24-11-84.broadband.corbina.ru) |
| 10:49.24 | oliv3r | but even things like 'built from allwinner's sources (baseband 1.2) ... what? baseband is a wireless communication thing I would think, I know they use it on radio-firmwares too, but not sure what baseband relates to wrt allwinner |
| 10:49.43 | oliv3r | yeah but I wonder if it'll work on my tablet, can try of course, i'll look it over |
| 10:52.25 | mnemoc | as long as you keep your script.bin and you don't rely in a .ko we don't have in the open tree. it will work |
| 11:05.47 | oliv3r | the wiki mentions for nand-part that you need a kernel patch to expuse the FULL nand block device, i take it that is not entirly true? since there's some hidden bits (where boot0 and boot1 reside)? |
| 11:06.12 | mnemoc | it's the full *logical* nand block |
| 11:07.39 | oliv3r | thought so |
| 11:11.53 | mnemoc | rm: have you tried to enable thumb2 on an A10 kernel? |
| 11:12.04 | rm | no |
| 11:12.16 | rm | you mean "compile kernel as thumb (experimental)"? |
| 11:12.31 | mnemoc | yes |
| 11:13.32 | rm | no, didn't try that |
| 11:14.51 | rm | sounds interesting, would be nice to try and somehow benchmark the effects |
| 11:15.02 | mnemoc | indeed |
| 11:15.04 | rm | but I'm afraid the kernel will flat out not boot |
| 11:15.13 | rm | and I don't have convenient means to debug |
| 11:15.18 | lundman | did you try --force! |
| 11:16.45 | mnemoc | hno: http://sprunge.us/ZaeS?diff <--- improved simmetry and dropped CONFIG_ rename (for the sake of 3.0 "stability") |
| 11:17.16 | jquip | <PROTECTED> |
| 11:17.17 | mnemoc | CONFIG_THUMB2_KERNEL=y .... so here we go |
| 11:17.46 | mnemoc | jquip: on linux you don't have raw nand, so raw nand filesystem don't work |
| 11:18.03 | mnemoc | same on SD cards |
| 11:18.22 | jquip | mnemoc: yes yes and no no... ubifs/yaffs works I hear.. |
| 11:19.04 | mnemoc | /sys/kernel/debug/kmemleak is always angry :< |
| 11:19.36 | jquip | or am i mistaken? |
| 11:19.44 | mnemoc | jquip: never tried myself |
| 11:20.47 | rm | mnemoc, I was turning it off in rc.local |
| 11:20.53 | rm | and now I think I disabled it in .config |
| 11:34.54 | *** part/#arm-netbook jquip (~johnny@223.178.64.107) |
| 11:40.39 | *** join/#arm-netbook tuliom (~tuliom@177.133.177.95) |
| 11:51.04 | *** join/#arm-netbook tzafrir (~tzafrir@local.xorcom.com) |
| 11:56.46 | mnemoc | rm: http://dpaste.com/812381/plain/ <--- with thumb2 enabled |
| 11:57.05 | mnemoc | crashed with an alignment error on the usb junk-driver |
| 11:57.06 | rm | turn off preempt!!!!! |
| 11:57.14 | rm | but yeah |
| 11:57.20 | rm | wouldn't bet it will help |
| 11:57.29 | rm | facepalm |
| 11:57.34 | rm | and you also run tickless |
| 11:57.55 | mnemoc | we are supposed to have those problems fixed... |
| 11:57.55 | rm | that's almost like TRYING to build a kernel that won't work |
| 11:59.46 | mnemoc | i don't want to have a kernel that runs only disabling things |
| 12:01.18 | mnemoc | but the point was, it boots |
| 12:01.55 | mnemoc | and that usb driver needs fixing ;-) |
| 12:05.38 | rm | maybe try disabling USB driver! |
| 12:05.39 | rm | :D |
| 12:05.48 | mnemoc | :p |
| 12:26.26 | *** join/#arm-netbook zub (~zub@217-112-174-181.cust.avonet.cz) |
| 12:45.25 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 12:59.32 | *** join/#arm-netbook destinal (destinal@unaffiliated/destinal) |
| 12:59.32 | *** join/#arm-netbook dyoung-away (dyoung@2001:4800:780e:510:7cfc:f3f0:ff04:36e3) |
| 12:59.50 | *** join/#arm-netbook dyoung (dyoung@nasadmin/dyoung) |
| 13:31.39 | mnemoc | rm: anyhow, can you test if you still have inestabilities when using tickless and preempt? |
| 13:31.46 | mnemoc | rm: they should be gone by now |
| 13:33.45 | zub | mnemoc: aaah, my favourite crash (the usb driver) |
| 13:34.00 | mnemoc | :) |
| 13:34.01 | hno | mnemoc, I think you are overdoing it here, but looks fine other than that. |
| 13:34.04 | zub | somebody should fix that :-P |
| 13:34.25 | zub | I know nothing about it... but maybe I can at least try to figure out the cause... |
| 13:34.34 | mnemoc | zub: I only got it on a thumb2 experimental build |
| 13:35.14 | zub | I get very similar crash randomly... http://linux.fjfi.cvut.cz/~zub/crash.log |
| 13:35.36 | zub | very similar ~ in similar parts of the code |
| 13:36.32 | hno | zub, please read code and expand on the register guide so a better driver can be written. |
| 13:36.55 | mnemoc | hno: what do you think it's an excess there? |
| 13:38.10 | hno | Having more than one define. |
| 13:38.11 | zub | hno: I'll give it a try, but knowing myself (I know nothing about USB/kernel, and I don't have that much free time anyway) I can't promise anything :( |
| 13:39.28 | oliv3r | hno: do you know more about the CPUCFG register with regard to the chip version? you write 00 = A, 11 = B and ?? = C. with only 2 bits available, got any more info by any chance now? |
| 13:39.37 | mnemoc | hno: it's one for allwinner boot hacks, and a second to request mali's reserve |
| 13:39.44 | hno | mnemoc, and head.S part is not about mali, it's about booting directly from boot1. |
| 13:40.22 | mnemoc | hno: yes, that change is to kill the machine type hack together with the memsize hacks |
| 13:40.45 | oliv3r | hno: the datasheet says default: 0x03 (I assume that to be rev C, but you claim it to be B?) and says 'reserved to 2'b11 ?? |
| 13:40.52 | mnemoc | hno: obviusly the define needs to be renamed |
| 13:41.26 | mnemoc | 'A'+x == 'C' for x == 2 |
| 13:41.56 | oliv3r | anywhere in the source I could check that? |
| 13:42.06 | mnemoc | hno: but the idea was to bind both hacks in the same CONFIG_ |
| 13:42.55 | hno | And that head.S code should move somewhere else. I.e. zimage header or a custom header. |
| 13:42.56 | oliv3r | mnemoc: i get the simple math behind it :p; but if 0 = A, and 3 = B, C would have to be either 1 or 2, which ... seems odd :p |
| 13:43.49 | hno | oliv3r, rev A & B have the same value. |
| 13:44.03 | oliv3r | so that register is somewhat useless? :S |
| 13:44.40 | hno | Olny RevC needs code to behave slightly different. |
| 13:45.15 | oliv3r | let me rephrase, what shall I put up on the wiki :p |
| 13:45.31 | oliv3r | your notes seem to not match what you say here |
| 13:48.25 | oliv3r | I doubt there's any reference in the source about it? other then reading the value |
| 13:52.36 | oliv3r | hno: I take it you refer to the PLL4/Sata patch? |
| 13:52.54 | mnemoc | oliv3r: in arch/arm/mach-sun4i/core.c of the kernel look for sw_get_ic_ver |
| 13:53.54 | mnemoc | oliv3r: and yes, 0 == MAGIC_VER_A (0), 3 == MAGIC_VER_B (1), anything else == MAGIC_VER_C (2) |
| 13:54.18 | oliv3r | but hno just said that A and B share the same magic number? |
| 13:55.01 | oliv3r | mnemoc: found sw_get_i2_ver; thank you :) |
| 13:55.19 | Turl | rm I run with preempt on all the things A10, no issues |
| 13:55.24 | mnemoc | i don't know... i didn't write those functions |
| 13:55.57 | hno | Hmm.. seems I remember wrong there. A = 0, B = 0b11, C= anything else. |
| 13:55.59 | Turl | $ ssh mele "uname -a; uptime" |
| 13:56.00 | Turl | Linux mele 3.4.12+ #6 PREEMPT Wed Oct 10 19:24:57 UTC 2012 armv7l GNU/Linux |
| 13:56.00 | Turl | <PROTECTED> |
| 13:56.08 | rm | Turl, also with cpufreq enabled? |
| 13:56.14 | Turl | ye |
| 13:56.45 | rm | and on 3.0.x as well? |
| 13:57.00 | Turl | yes |
| 13:57.11 | rm | ok, will try it next time |
| 13:58.19 | oliv3r | hno: you made me all confused! I will change that and then save the timers page; which means its ready for review and done! took me only 2 1/2 days! :( |
| 14:00.36 | oliv3r | http://linux-sunxi.org/A10/TIMER done |
| 14:01.20 | zub | oliv3r: looks impressive |
| 14:01.35 | mnemoc | oliv3r: amazing job. thank you! |
| 14:08.26 | oliv3r | i saw the next section though; which scared me |
| 14:08.31 | oliv3r | i think it's about twice as long :S |
| 14:08.49 | oliv3r | anyway, i'll go a few chapters back and start with something smaller :p |
| 14:08.55 | oliv3r | it may need some minor formatting |
| 14:09.03 | oliv3r | I still think a template would have been usefull for those tables :p |
| 14:11.41 | oliv3r | Tech companies should just use wiki's to begin with for their datasheet, much easier to revise :D |
| 14:13.48 | oliv3r | Clock control module will be tomorrow's goal! |
| 14:15.23 | mnemoc | :) |
| 14:15.48 | zub | http://limadriver.org/ ... so there is some hope :) |
| 14:16.08 | mnemoc | that one is critical, after migrating our kernel to pinctrl, common clock framework driver will be next |
| 14:16.20 | mnemoc | zub: that basically means libv |
| 14:17.09 | mnemoc | unfortunatelly he has been way to busy doing $work$ these months :< |
| 14:17.18 | mnemoc | s/to/too/ |
| 14:17.20 | Turl | mnemoc: have you noticed the lack of spambot registrations? :D |
| 14:17.31 | mnemoc | Turl: yes, thank you! :) |
| 14:17.45 | Turl | I thought it wouldn't work, but it seems it has done the trick :P |
| 14:17.50 | mnemoc | Turl: do you know if we can *delete* the bogus accounts? |
| 14:17.59 | Turl | yeah you can |
| 14:18.02 | Turl | one by one :< |
| 14:18.05 | mnemoc | :< |
| 14:18.16 | mnemoc | mediawiki's admin side sucks badly |
| 14:18.22 | libv | yeah, only tend to spend a few h per weeks on lima, sadly |
| 14:18.38 | libv | s/weeks/week/ |
| 14:19.22 | mnemoc | libv: any perspective of change on that? |
| 14:19.37 | mnemoc | libv: hi :) |
| 14:19.49 | libv | not atm, and hi back :) |
| 14:20.26 | oliv3r | pinctrl, is that the first step to mainlining sunxi? |
| 14:20.32 | libv | with any luck, i can get the demo i had planned for XDC going in time for FOSDEM :( |
| 14:20.38 | oliv3r | was* (sounds reasonable as it sounds quite low) |
| 14:21.06 | mnemoc | oliv3r: not the first in general, but it's critical for core mainlining |
| 14:21.12 | oliv3r | I figured CCM and Timers be equally important :) |
| 14:21.39 | oliv3r | well in that case, i'll go with CCM for sure, which would you reccon I should look at after? |
| 14:21.49 | mnemoc | oliv3r: drivers unification and bug fixing is also toward mainlining |
| 14:21.54 | oliv3r | (htough I think ccm will take 2 days easy) |
| 14:22.30 | ManoftheSea | lkcl: Hoy Luke. |
| 14:22.38 | oliv3r | probably system control register; after those two, i'll refactor the ones I did (to match the timer one in style) |
| 14:22.51 | mnemoc | :) |
| 14:23.13 | ManoftheSea | Have people seen ZaReason's got an A10 tablet? |
| 14:23.52 | mnemoc | ManoftheSea: ZaEarl has been here for like a year |
| 14:24.01 | ManoftheSea | Is that it. I figured someone was. |
| 14:24.14 | mnemoc | Turl is also part of that team |
| 14:28.08 | oliv3r | time to go home! |
| 14:28.11 | oliv3r | see you all tomorrow :) |
| 14:28.21 | mnemoc | good night oliv3r |
| 14:29.02 | oliv3r | it's only 16:30 here :p |
| 14:29.04 | oliv3r | but thank you :) |
| 14:29.18 | zub | ha, same TZ :) |
| 14:30.12 | Turl | is still in the AM :P |
| 14:31.45 | andoma | CET ftw |
| 14:35.22 | mnemoc | not really when you live in the westernest edge of europe and you are forced to use germany's TZ |
| 14:36.03 | ManoftheSea | I'm thinking on the Laptop shell for an EOMA card... specifically, power. |
| 14:36.26 | ManoftheSea | The laptop shell should be able to charge and turn-on without an EOMA card, right? |
| 14:36.47 | mnemoc | yes, the laptop board needs it's own STM32F controller it |
| 14:36.51 | mnemoc | controlling* |
| 14:36.51 | ManoftheSea | Then, when EOMA card is inserted and user says "go", power goes across the connector. |
| 14:37.00 | mnemoc | right |
| 14:37.37 | ManoftheSea | mnemoc: in the STM32F case, the STM just gets out of the way? Until when? The EOMA signals "hey, turn me off"? |
| 14:38.07 | mnemoc | then the module reads the description of the io board from an eeprom over i2c and learns about it's periferals |
| 14:38.30 | ManoftheSea | mnemoc: right, I understand the idea of the EEPROM, even if I don't totally get device tree yet. |
| 14:38.51 | mnemoc | ManoftheSea: it shouldn't get out of the way... it will still need to take care of battery charging and stuff |
| 14:39.06 | ManoftheSea | well, out of the way of the screen, if it ever was there. |
| 14:39.20 | mnemoc | i don't think it should ever be |
| 14:39.24 | ManoftheSea | But how does the EOMA do power management/backlight control/power-off? |
| 14:39.45 | mnemoc | don't know... isn't that part of the LCD pins set? |
| 14:39.46 | ManoftheSea | Battery info can go across USB, I imagine. |
| 14:39.56 | ManoftheSea | backlight control? I didn't think so. |
| 14:40.14 | mnemoc | afaik the idea was to use openEC to let both talk |
| 14:40.38 | ManoftheSea | openEC refers to x86 ports. I'm not claiming to understand it. |
| 14:40.39 | mnemoc | no clue how is that implemented in reality |
| 14:41.11 | ManoftheSea | Yeah, LCD pins are just pixel data, v- and h-sync, and an enable. |
| 14:41.40 | ManoftheSea | Well, that's what I'm thinking on. How does the card turn its I/O board off? |
| 14:41.44 | mnemoc | http://wiki.laptop.org/go/Embedded_controller <--- this thing |
| 14:41.55 | ManoftheSea | Or, in the case of a capable laptop, return control to the STM32F |
| 14:42.13 | mnemoc | i think so, the "EC" has to take care of it |
| 14:42.30 | mnemoc | but i'm not familiar with the life at that depth |
| 14:42.56 | ManoftheSea | yeah, that page says an LPC interface. |
| 14:43.05 | ManoftheSea | whatever that is (/me uses the google) |
| 14:43.24 | mnemoc | http://wiki.laptop.org/go/Ec_specification |
| 14:43.24 | ZaEarl_ | I wouldn't expect the EOMA card to have an EC |
| 14:43.34 | mnemoc | not the card. the device |
| 14:44.07 | ManoftheSea | the laptop shell side. |
| 14:44.24 | ManoftheSea | Hmm, Low Pin Count, it's 4 wires, and it's like ISA. |
| 14:44.39 | ManoftheSea | I don't think we want it. |
| 14:45.20 | mnemoc | ManoftheSea: send an email to the list about it |
| 14:45.32 | mnemoc | luke rarely looks at here |
| 14:45.40 | ManoftheSea | I will. I'm currently limited only to Google's web interface. Bleh. |
| 14:45.49 | ManoftheSea | points finger in mouth. |
| 14:46.08 | mnemoc | you can post from gmane too |
| 14:46.12 | ManoftheSea | mnemoc: regarding luke, I was just hoping to catch him, but nothing important. |
| 14:46.15 | ManoftheSea | Oh hey, good idea. |
| 14:46.32 | ManoftheSea | On the other hand, I'd like to do a little research first, and present what I think are options. |
| 14:46.44 | ManoftheSea | Rather than just asking you (plural) to do everything. |
| 14:47.44 | ManoftheSea | oh hey! GPIOs. Those could bitbang a 4-wire protocol. |
| 14:47.52 | ManoftheSea | Even if it is emulation of something ancient. |
| 14:48.46 | mnemoc | bitbanging is still popular :p |
| 14:49.49 | *** join/#arm-netbook lerc_ (~quassel@121-74-226-42.telstraclear.net) |
| 14:50.25 | drachensun | where can I get the cedar libs for cedarxplayertest |
| 14:50.59 | drachensun | I figured it all out before and I didn't write it down it seems |
| 14:51.14 | mnemoc | the xbmca10 thing has an script to download them ..... from my dropbox :| |
| 14:51.29 | drachensun | ok cool |
| 14:51.37 | mnemoc | there are tons of .zip and .rar files inside, not sure which he uses |
| 14:51.44 | mnemoc | but the script knows |
| 14:51.59 | drachensun | I'll try and figure it out |
| 14:52.14 | drachensun | maybe put them back up in a github instead |
| 14:52.31 | drachensun | yeah, there were a ton of different pieces in there |
| 14:52.40 | ManoftheSea | do ARM chips "use" ACPI? |
| 14:52.48 | drachensun | I couldn't figure out how they all were different |
| 14:54.29 | mnemoc | drachensun: can you do a pull request to update https://github.com/amery/allwinner-a10-video ? |
| 14:54.46 | mnemoc | once you have figured out what files are worthy :) |
| 14:55.49 | drachensun | heh sure |
| 14:56.07 | mnemoc | thank you :) |
| 15:05.44 | ManoftheSea | mnemoc, I seem to think you've got extensive arm device experience. How does Linux signal an ARM core to turn off the system? |
| 15:06.02 | ManoftheSea | (Very high level is okay! I'll research from there) |
| 15:07.03 | mnemoc | ManoftheSea: i'm a noob. but i know the kernel asks the PMU to do so |
| 15:08.11 | ManoftheSea | So, it goes through to runlevel 0, everything shutdown/unmounted, then sends some kind of signal? |
| 15:08.41 | ManoftheSea | and in x86, that signal seems to be an ACPI or APM signal. Which are told to the chip by the bios. |
| 15:08.44 | mnemoc | [ 5913.230000] Power down. |
| 15:08.44 | mnemoc | [axp] send power-off command! |
| 15:08.49 | mnemoc | ^--- from A10 |
| 15:09.03 | ManoftheSea | So, in device tree, it'd have to identify a signal to cut power. |
| 15:09.07 | ManoftheSea | ok. |
| 15:09.10 | ManoftheSea | writes that down. |
| 15:09.16 | mnemoc | in EOMA he will tell the EC to do so |
| 15:10.03 | ManoftheSea | yep. I'm just wondering how flexible that is. Given the set of signals that cross the header.... I'm wondering if you can't have a USB device to do that. |
| 15:10.26 | zub | ManoftheSea: w.r.t. the user-space part, see man 2 reboot - an interesting syscall :) |
| 15:10.30 | ManoftheSea | Assuming the STM32F is wonderful and great and all that: It's doing mouse, keyboard, backlight... |
| 15:10.52 | ManoftheSea | zub: I have to tell my current laptop "reboot=e" at the cmdline. |
| 15:11.00 | ManoftheSea | So, certainly there are many ways to cut powre. |
| 15:11.02 | mnemoc | i assume one will be able to write something in a magic address (register) |
| 15:11.23 | ManoftheSea | mnemoc: register of the ARM? |
| 15:11.27 | mnemoc | EC |
| 15:11.41 | ManoftheSea | Er, yeah, I guess I should call it that. |
| 15:11.50 | ManoftheSea | But EC is so tied to x86 |
| 15:12.13 | mnemoc | EC = MCU of the i/o board where the module is connected |
| 15:12.24 | ManoftheSea | MCU? |
| 15:12.28 | mnemoc | micro controller |
| 15:13.11 | mnemoc | don't know if that "openec" uses a register (memory mapped) or a protocol over i2c |
| 15:13.33 | ManoftheSea | that's the LPC I was talking about. |
| 15:13.58 | mnemoc | first time I see that 3-letter-acronym |
| 15:13.59 | ManoftheSea | The chip does some EC stuff in hardware, from port 62h and 66h. |
| 15:14.20 | ManoftheSea | That's where I said "Low Pin Count". It's a quad pumped 4 wire interface to replace ISA. |
| 15:14.34 | mnemoc | too low for me :) |
| 15:15.01 | ManoftheSea | too low? ISA being Industry Standard Architecture (?) |
| 15:15.27 | mnemoc | for me ISA is the slot that came before PCI |
| 15:17.21 | mnemoc | but nevermind. I got it. |
| 15:17.38 | ManoftheSea | yeah, that's what I'm saying. It's OLD. '85 |
| 15:18.01 | mnemoc | we don't need something fancy to talk with the EC |
| 15:18.55 | *** part/#arm-netbook mSquare (~selvan@122.172.242.200) |
| 15:19.02 | *** join/#arm-netbook NAiL (~repvik@nslu2-linux/repvik) |
| 15:21.00 | ManoftheSea | ok... there's discussion of "gpio-poweroff" driver, through i2c gpios. |
| 15:21.15 | ManoftheSea | Which fits into device tree. |
| 15:23.12 | mnemoc | afaik lkcl goal is to port openec, not to implement something new |
| 15:23.56 | ManoftheSea | Hmm, I'm assembling info on why that's wrong. I'll make a case later. |
| 15:24.07 | ManoftheSea | Though, gpio-poweroff isn't "new" |
| 15:24.08 | mnemoc | :) |
| 15:24.11 | ManoftheSea | It's from the arm discussion list. |
| 15:24.17 | mnemoc | but it's poweroff-specific |
| 15:24.34 | mnemoc | we need full access to whatever is going on there |
| 15:24.49 | ManoftheSea | OpenEC would make the EOMA card have to emulate x86 to communicate. |
| 15:24.57 | ManoftheSea | Which would be great for an x86 EOMA card. |
| 15:25.50 | mnemoc | i suppose the idea is to implement an open standard already suppoered by the kernel |
| 15:25.58 | ManoftheSea | That's what I'm looking for, yes. |
| 15:26.04 | rm | http://bifferos.co.uk/ |
| 15:26.07 | rm | this can fit |
| 15:26.41 | ManoftheSea | I guess it'd be useful to know more about what a BIOS does. |
| 15:26.57 | ManoftheSea | Because, all I can think of is "apply power to EOMA" or "remove power from EOMA" |
| 15:27.10 | mnemoc | ManoftheSea: look at the specs of openec |
| 15:27.12 | ManoftheSea | doing the battery charging is more like an UPS |
| 15:27.18 | mnemoc | it's very detailed on what info is provided |
| 15:28.58 | ZaEarl | would the axp209 do the job, since lots of a10 systems already use it. |
| 15:29.23 | ManoftheSea | I would think so, ZaEarl. Also, the openec list seems to have died in Jan '11 |
| 15:29.45 | ManoftheSea | er, sorry... there are two places for power management. |
| 15:29.57 | ManoftheSea | The EOMA card has an axp209, almost certainly. |
| 15:30.20 | ManoftheSea | It does power from 5V to 3.3, 1.?, as well as USB-OTG management |
| 15:30.37 | ManoftheSea | Also, if there's any kind of battery on the EOMA card side. |
| 15:31.04 | ManoftheSea | But the laptop/tablet/monsterboard(maybe) will also have a battery. |
| 15:31.19 | mnemoc | eoma is not a10 specific |
| 15:31.24 | ManoftheSea | And that I/O-board battery is more like an uninterruptable power supply. |
| 15:31.34 | mnemoc | so axp209 has absolutely nothing to do |
| 15:31.36 | ManoftheSea | mnemoc: thank you for correcting my imprecise language. |
| 15:31.51 | ManoftheSea | An A10-based EOMA card will almost certainly have an axp209 |
| 15:32.02 | mnemoc | not necesarily |
| 15:32.19 | ManoftheSea | What part of "almost certainly" are you disagreeing with? |
| 15:32.47 | mnemoc | i would say a "maybe" at most |
| 15:32.55 | ManoftheSea | ok. |
| 15:33.15 | ManoftheSea | I believe the current A10-based EOMA card has an AXP209. |
| 15:33.23 | mnemoc | ah, cool then |
| 15:33.53 | ManoftheSea | That's the Wits-tech model, in my understanding |
| 15:34.14 | mnemoc | good point. now i agree with the almost certainly |
| 15:34.16 | ZaEarl | yes, rhombus tech seems to have an axp209 |
| 15:35.02 | *** join/#arm-netbook Maqs (~marcus@marcus.eunomia.de) |
| 15:35.26 | ManoftheSea | ZaEarl: does your zatab have an axp209? |
| 15:35.33 | ZaEarl | yup |
| 15:35.52 | mnemoc | very few a1X devices don't have it |
| 15:36.17 | mnemoc | iirc the mk802 and olimex's "micro" board |
| 15:36.44 | mnemoc | but i don't see a reason for the a10 module to need it |
| 15:36.45 | ManoftheSea | alright. Now that we're past that... most of what I can find about openEC is {battery info, temperature info, keyboard controller} |
| 15:37.07 | ManoftheSea | mnemoc: there's not a reason it needs it. It's just part of the reference model and comes from the same company. |
| 15:37.10 | ManoftheSea | right? |
| 15:37.14 | mnemoc | display backlight and that stuff? |
| 15:37.23 | mnemoc | ManoftheSea: yes |
| 15:37.27 | ManoftheSea | actually, I don't see that in what I'm reading. |
| 15:37.33 | Turl | without an axp you cannot use dvfs |
| 15:37.34 | ManoftheSea | Not that I am certain I'm reading the right place. |
| 15:37.40 | ManoftheSea | http://wiki.laptop.org/go/OpenEC |
| 15:38.26 | ManoftheSea | and then the datasheet at http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf |
| 15:38.39 | ManoftheSea | "EC standard commands as described in ACPI 2.0 spec" |
| 15:38.57 | ManoftheSea | So... OpenEC is to implement ACPI? |
| 15:39.19 | mnemoc | seems so... |
| 15:40.41 | ZaEarl | whenever I hear ACPI I cringe. |
| 15:40.45 | ManoftheSea | And that's mostly for old crap (x86). |
| 15:41.08 | ManoftheSea | I'm thinking the EOMA-compliant device wants to use USB as much as possible. |
| 15:41.12 | ManoftheSea | Because it's discoverable. |
| 15:41.47 | ManoftheSea | So, if kbd and mouse are USB devices, you don't need the kbc. Or at least it's not as promenent a device. |
| 15:44.27 | *** join/#arm-netbook alcides (~alcides@187.23.192.105) |
| 15:44.27 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 15:44.41 | mnemoc | most of the stuff will be usb, sure |
| 15:44.45 | mnemoc | but not everything can |
| 15:44.55 | alcides | http://www.cnx-software.com/2012/10/10/droid-stick-a2-amlogic-aml8726-mx-dual-core-android-4-1-1-mini-pc/ |
| 15:47.07 | ManoftheSea | mnemoc: no, but whatever's not usb is i2c or gpio, and specified in device tree. |
| 15:47.12 | ManoftheSea | Making it discoverable. |
| 15:47.34 | ZaEarl | I sure wish Allwinner would announce something about sun6i this week. |
| 15:47.37 | ManoftheSea | Hmm, I'll try looking up that dvi-lvds chip that's specified in the EOMA page. |
| 15:48.11 | *** join/#arm-netbook ZaEarl_ (~malmrose@202.155.242.30) |
| 15:48.37 | *** join/#arm-netbook gzamboni (~gzamboni@2a02-8426-513b-5100-0224-21ff-fe57-307c.rev.sfr.net) |
| 15:49.00 | mnemoc | ManoftheSea: btw, are you Gordan Bobic? |
| 15:49.10 | ManoftheSea | no. I thought you were. |
| 15:49.11 | mnemoc | Derek LaHousse |
| 15:49.15 | ManoftheSea | yeah |
| 15:49.19 | mnemoc | :) |
| 15:49.21 | ManoftheSea | what? did you /who me? |
| 15:49.27 | mnemoc | yes |
| 15:49.34 | mnemoc | should have done it before asking :p |
| 15:53.00 | ManoftheSea | oh, it's not dvi->lvds, it's RGB->lvds |
| 15:54.31 | ManoftheSea | so yeah, the SN75LVDS83B doesn't do backlight. |
| 15:58.31 | *** join/#arm-netbook phh (~quassel@137.194.15.151) |
| 16:03.04 | ManoftheSea | Did I sound particularly knowledgeable? |
| 16:03.47 | mnemoc | here? sure, you know far more than I about hw |
| 16:14.44 | *** join/#arm-netbook techn (~quassel@a91-152-35-60.elisa-laajakaista.fi) |
| 16:26.06 | *** join/#arm-netbook vinifr (b1138417@gateway/web/freenode/ip.177.19.132.23) |
| 16:31.05 | *** join/#arm-netbook pawel5870 (~pkarpins@staticline54070.toya.net.pl) |
| 17:06.36 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 18:06.59 | lkcl | ManoftheSea: yeah OpenEC is far more involved than it seems. it's 10,000 lines of c-code. keyboard matrix. mouse driver. battery charging (PWM and level reading). the works. it's... complex. |
| 18:07.45 | lkcl | ManoftheSea: TFP410 and TFP401. they're DVI-to-RGB/TTL (and vice-versa) |
| 18:08.27 | ManoftheSea | lkcl: I take it you've been reading back? |
| 18:08.37 | lkcl | ManoftheSea: que? :) oh - yes :) |
| 18:09.10 | ManoftheSea | What's the DVI comment about? |
| 18:09.23 | lkcl | "ManoftheSea> Hmm, I'll try looking up that dvi-lvds chip that's specified in the EOMA page." |
| 18:09.37 | lkcl | TFP410 for dvi->rgb/ttl |
| 18:09.38 | ManoftheSea | I was discussing going from EOMA RGB to the panel LVDS. I mistakenly thought the EOMA was DVI |
| 18:09.41 | ManoftheSea | I see. |
| 18:09.48 | lkcl | TFP401 rgb/ttl -> DVI |
| 18:09.56 | ManoftheSea | No, I actually meant the SN75LVDS83B |
| 18:10.01 | lkcl | ah then you want SN75LVDS83B or equivalent. |
| 18:10.11 | ManoftheSea | Which you've specified EOMA must be compatible with. |
| 18:10.13 | lkcl | that's only for panels up to (about) 1440x900 |
| 18:10.33 | ManoftheSea | I thought it provided up to 5 LVDS channels. |
| 18:10.37 | lkcl | well, it's the easiest way to put it, that the signals must be 5V tolerant etc. etc. |
| 18:10.56 | lkcl | SN75LVDS83B is only single-channel LVDS |
| 18:11.19 | lkcl | the reason for specifying 24-pin RGB/TTL is because you can do *anything* with it, not costing a fortune in ICs. |
| 18:11.57 | ManoftheSea | oh, is it 5 line drivers in a single LVDS channel? |
| 18:14.27 | lkcl | sounds about right. |
| 18:14.40 | ManoftheSea | So, there's another chip to do higher screens? |
| 18:15.10 | lkcl | a single LVDS channel involves 3 colours and i think one clock line pair. |
| 18:15.21 | lkcl | yes, a different IC is needed - one that does dual LVDS. |
| 18:15.39 | lkcl | i don't know one: if you find one that's popular please do let me know, i need to document it. |
| 18:16.00 | ManoftheSea | hmm... The SN75LVDS83B shows 4 7-bit shift registers, and a clock. Rather than 3 8-bit colors. |
| 18:16.14 | ManoftheSea | If I find something, I'll shout. |
| 18:16.28 | ManoftheSea | But I did want to ask a bit more about OpenEC, and whether it's necessary. |
| 18:16.31 | lkcl | star. |
| 18:16.36 | lkcl | it is. |
| 18:16.46 | lkcl | cost of a battery management IC: $1.50 |
| 18:16.57 | lkcl | cost of a 0.5 watt audio driver IC: $1.50 |
| 18:17.09 | lkcl | cost of a USB-based keyboard/mouse driver IC: $1.50 |
| 18:17.13 | ManoftheSea | No no, not just doing battery management on the I/O board with STM |
| 18:17.26 | ManoftheSea | But specifically the EC protocol |
| 18:17.31 | ManoftheSea | Which seems to pull in ACPI |
| 18:17.43 | lkcl | EC "protocol"? |
| 18:17.44 | ManoftheSea | And ancient x86 cruft |
| 18:17.52 | lkcl | yeah all that would go. |
| 18:18.02 | ManoftheSea | go... out? go in? |
| 18:18.11 | lkcl | out. |
| 18:18.18 | *** join/#arm-netbook rellla (~Thunderbi@p4FE560D1.dip0.t-ipconnect.de) |
| 18:18.24 | ManoftheSea | http://wiki.laptop.org/images/a/ab/KB3700-ds-01.pdf |
| 18:18.26 | ManoftheSea | page 26 |
| 18:18.31 | lkcl | it's not like ARM systems support ACPI |
| 18:18.34 | ManoftheSea | EC stuff in firmware, doing ACPI 2.0 |
| 18:18.40 | mnemoc | doesn't uefi brings acpi into arm? |
| 18:18.59 | ManoftheSea | ick at that too. |
| 18:19.37 | mnemoc | feel inevitable... |
| 18:19.56 | ManoftheSea | So, from the linked stuff around OpenEC and XO, it looks like EC is a term that means a lot of x86 cruft. |
| 18:20.02 | ManoftheSea | Given that chip is doing it in hardware. |
| 18:20.12 | ManoftheSea | From an "LPC" bus. |
| 18:20.12 | lkcl | ManoftheSea: KB3700-ds-01: not interesting. as in, yes sure the STM32F would do the same job but otherwise ... |
| 18:20.16 | lkcl | ah no, it's... |
| 18:20.18 | ManoftheSea | It may be an overloaded term. |
| 18:20.28 | lkcl | ok, do you know how battery management algorithms work? |
| 18:20.35 | ManoftheSea | can't say I do. |
| 18:20.42 | lkcl | you can't just "apply power" |
| 18:20.48 | lkcl | you have to use PWM |
| 18:21.09 | lkcl | and it depends on what the state of the battery is (how charged / depleted it is) |
| 18:21.23 | lkcl | so you start off if it's very very low doing 100% charge |
| 18:21.35 | lkcl | then as the state rises you reduce it to say... 50% |
| 18:21.47 | ManoftheSea | lkcl, let me ask you this: Would it be more apt to compare the shell to a Uninterruptable Power Supply. |
| 18:21.56 | lkcl | then, when it approaches 80% or above, you start to "pause" for several seconds |
| 18:21.56 | ManoftheSea | Those have batteries, but provide a specific output. |
| 18:22.26 | ManoftheSea | Also, they have USB interfaces, which are discoverable |
| 18:22.28 | lkcl | no it wouldn't - not unless you were looking to do a UPS *using* the STM32F |
| 18:22.37 | lkcl | ManoftheSea: you're really confusing me |
| 18:22.46 | ManoftheSea | yeah, I've been rather confused |
| 18:23.11 | ManoftheSea | I'll claim that as my problem. |
| 18:23.38 | lkcl | i'm endeavouring to explain what tasks a $1.50 STM32F needs to do when used to replace 3 or even 4 other discrete $1 to $1.50 components |
| 18:24.03 | ManoftheSea | And I agree that it seems quite capable of replacing them. |
| 18:24.11 | ManoftheSea | But I don't quite see how it communicates with the EOMA card. |
| 18:24.14 | lkcl | normally those tasks would be covered by e.g. the dedicated periperals of e.g. the A10 |
| 18:24.17 | lkcl | over the USB 1.1 bus |
| 18:24.25 | lkcl | an STM32F has USB 1.1 |
| 18:24.37 | mnemoc | nice |
| 18:24.47 | ManoftheSea | So, the STM32F has to provide a USB device that emulates the LPC? |
| 18:24.57 | ManoftheSea | Why doesn't it just present itself as an UPS? |
| 18:25.01 | lkcl | so what you would do e.g. in the audio driver case would be to write a linux driver that recognised the STM32 |
| 18:25.07 | ManoftheSea | And a keyboard, and a mouse, and a and a and a |
| 18:25.11 | lkcl | because you have to multiplex quite a bit of data onto that... yeeees |
| 18:25.12 | lkcl | exactly |
| 18:25.30 | lkcl | so it will be necessary to write a communications protocol, splitting out the data |
| 18:25.43 | lkcl | quite a challenging and interesting task. |
| 18:26.05 | lkcl | hence the need for a little bit more than libopenstm32, and why something like RTEMS is needed |
| 18:26.13 | ManoftheSea | I agree that far. But I don't believe EC is the right term any more. |
| 18:26.15 | mnemoc | *cough* micro-eng-board-with-stm32f *cough* |
| 18:26.22 | lkcl | yeah all right mnemoc :) |
| 18:26.24 | ManoftheSea | mnemoc: at that point, it's the mini |
| 18:26.50 | lkcl | it's the closest term that the industry will recognise. |
| 18:27.23 | mnemoc | ManoftheSea: we don't need lvds or wifi |
| 18:27.34 | lkcl | yes. do really want someone to come forward and take the leaflab's maple schematics and add the extra connectors |
| 18:27.38 | ManoftheSea | I must bow to your greater experience, but from the research I did, they'll recognize it as "x86 stuff" |
| 18:28.01 | ManoftheSea | I haven't heard from Prof Pierce in 2 weeks either. |
| 18:28.42 | ManoftheSea | er, Pearce. |
| 18:28.52 | mnemoc | uefi on arm is real, and will become the standard regardless who likes it or not :| |
| 18:28.59 | *** join/#arm-netbook raver2046 (raver2046@mer90-1-88-166-249-240.fbx.proxad.net) |
| 18:29.06 | ManoftheSea | mnemoc: the standard for people who want Windows 8. |
| 18:29.32 | mnemoc | and that means every major manufacturer and most mid/small ones |
| 18:29.42 | mnemoc | then the rest will fall |
| 18:29.45 | mnemoc | as usual |
| 18:29.46 | ManoftheSea | But since Win8 UEFI devices are completely locked out... they're uninteresting. |
| 18:29.46 | lkcl | ManoftheSea: ah hmm... well... that may be an advantage. maybe not. we'll see. |
| 18:30.08 | xxiao | M$ die die die |
| 18:30.17 | mnemoc | uefi doesn't need to lock linux out. that's a contract thing between MS and manufacturers |
| 18:30.35 | lkcl | ManoftheSea: ah? hm. wonder where he's got to? |
| 18:30.48 | ManoftheSea | yes. In the x86 world, it says "consumers must be able to run their own code." In the ARM world, it says "FOAD". |
| 18:30.57 | mnemoc | unlocked devices will come with uefi too |
| 18:31.21 | lkcl | xxiao: peace! we want to take M$'s money! :) we would *love* them to make an EOMA-68 CPU Card, because the patent licensing will help fund their replacement :) |
| 18:32.58 | xxiao | hopefully |
| 18:33.29 | xxiao | but that sounds more of a intel thing |
| 18:33.42 | jelly-home | I'd also love a board to plug said card into! |
| 18:34.23 | ManoftheSea | oh hey... there's a USB audio streaming demo for the STL |
| 18:34.26 | ManoftheSea | STM |
| 18:34.39 | ManoftheSea | It needs an external audio DAC, though... |
| 18:35.28 | xxiao | anyone benchmarked A10's SATA port? |
| 18:35.55 | lkcl | ManoftheSea: yeah. well, it'd work for low-ish quality audio. i don't imagine it'll require that many external discrete components |
| 18:36.16 | xxiao | i was told by a guy that Marvell's kirkwood has issues on sata etc but its price is irresitable |
| 18:36.51 | mnemoc | lkcl: btw, http://dev.laptop.org/git/users/rsmith/ec-1.75/ seems to have superseeded http://dev.laptop.org/git/projects/openec/ |
| 18:37.36 | ManoftheSea | mnemoc: oh cool. The last message on the latter list was Jan '11 |
| 18:37.41 | ManoftheSea | brb |
| 18:38.07 | lkcl | mnemoc: great |
| 18:38.15 | mnemoc | http://lists.laptop.org/pipermail/openec/2011-January/000158.html |
| 18:38.25 | mnemoc | the announcement |
| 18:42.57 | *** join/#arm-netbook tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 18:45.41 | mnemoc | using eluaproject.net would be fun :p |
| 18:46.26 | mnemoc | lkcl: once the stm32 is in the board, how do we flash it? special pins? |
| 18:49.34 | mnemoc | or code lives in the same eeprom as the DT description? |
| 18:49.48 | ManoftheSea | mnemoc: looks like it uses JTAG. |
| 18:50.43 | mnemoc | so that's yet another thing to add to the board |
| 18:50.56 | ManoftheSea | it's a header, is all. |
| 18:51.15 | mnemoc | yes. but has to be considered |
| 18:51.18 | mnemoc | lkcl: ---^ |
| 18:53.49 | mnemoc | eoma68-a10 board + expansion header + eng-board + jtag header = eoma68 devkit |
| 18:54.19 | ManoftheSea | what's the "expansion header" here? |
| 18:54.31 | mnemoc | in the card |
| 18:54.45 | ManoftheSea | oh, for no-sleeve cards? |
| 18:55.14 | mnemoc | i think that will be the case until there are no devices |
| 18:55.23 | mnemoc | devkit-ish |
| 18:58.00 | mnemoc | not that we need another A10 dev board after the CB and A10-olinuxino |
| 18:59.03 | mnemoc | the most critical part is having a module and having an stm32 with jtag in the first dev i/o^W^Weng board |
| 18:59.09 | lkcl | mnemoc: ta |
| 18:59.29 | mnemoc | .oO(ta?)o |
| 18:59.50 | lkcl | ok. mnemoc could you update the elinux.org pages to note that a jtag for STM32F is needed? |
| 18:59.54 | lkcl | i gotta run |
| 19:00.03 | lkcl | yeah. 8. gotta go |
| 19:00.15 | mnemoc | lkcl: need to convince you first :p |
| 19:00.28 | ManoftheSea | we all agree, the STM32F needs a JTAG header. |
| 19:00.38 | mnemoc | lkcl: also, there is no micro-eng page |
| 19:00.47 | mnemoc | cu lkcl |
| 19:01.30 | ManoftheSea | mnemoc: the microboard is at the bottom of the miniboard page |
| 19:03.34 | ManoftheSea | I added mention here: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68/MiniEngineeringBoard#Components_and_Interfaces |
| 19:06.38 | mnemoc | thanks |
| 19:48.46 | *** join/#arm-netbook rellla (~yaaic@p4FE560D1.dip0.t-ipconnect.de) |
| 19:55.58 | *** join/#arm-netbook tuliom (~tuliom@177.133.177.95) |
| 20:01.33 | *** join/#arm-netbook eFfeM (~frans@dhcp-077-251-240-021.chello.nl) |
| 20:09.15 | *** join/#arm-netbook raver2046 (~raver2046@mer90-1-88-166-249-240.fbx.proxad.net) |
| 20:14.15 | *** join/#arm-netbook xxiao (~xxiao@ec2-50-112-57-59.us-west-2.compute.amazonaws.com) |
| 20:35.52 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 20:57.45 | ManoftheSea | So, I've got a problem... |
| 20:58.18 | ManoftheSea | TI's documents say 1 channel of LVDS (18-24 bit color) go up to 1400 x 1050 |
| 20:58.44 | ManoftheSea | While it takes two LVDS channels (6-8 LVDS pairs) to reach 1920 x 1200. |
| 20:59.54 | ManoftheSea | So... EOMA-68 is limited to 1400x1050 on the internal connector? BOO! |
| 21:01.26 | ManoftheSea | also, lkcl, DS90C387A is TI's dual-LVDS chip. |
| 21:08.39 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 21:11.44 | ManoftheSea | oh, the DS chips are 1.8 V input, while the SN have 3.3 |
| 21:11.46 | ManoftheSea | Mah bad. |
| 21:13.39 | ManoftheSea | er... nope. The chip I menioned, ...387, is a 3.3 input and 5V tolerant |
| 21:18.42 | zub | hmmm... if I want to use the OTG USB as a host - ti shoudl work automagically, right? that's the whole point of OTG, is it not? |
| 21:19.04 | ManoftheSea | no, the driver has to do something. |
| 21:19.11 | zub | ehm? |
| 21:19.35 | zub | I don't care what the driver does, I was talking from the user point of view... you plug a device in, and it's recognized, and works |
| 21:20.17 | ManoftheSea | oh, yeah. |
| 21:20.20 | zub | my trouble is: I connect something, lsusb doesn't show it... so whatever needs to happen doesn't happen |
| 21:20.31 | zub | can I force the port to host mode somehow? |
| 21:20.47 | lkcl | ManoftheSea: no! EOMA-68 is *not* limited to 1400x1050! all you do is find (as you did) a dual-channel RGB/TTL-to-LVDS IC! |
| 21:20.49 | lkcl | honestly :) |
| 21:21.07 | ManoftheSea | lkcl: but... there are only 24 parallel color lines. |
| 21:21.11 | Turl | zub: you need an OTG cable usually |
| 21:21.27 | lkcl | ManoftheSea: so you connect all 24 of them to the Dual-channel LVDS IC |
| 21:21.45 | lkcl | the Dual-channel LVDS IC takes 24-pin parallel colour lines as input |
| 21:21.45 | ManoftheSea | the dual-channel lvds IC has 48 inputs... |
| 21:21.51 | ManoftheSea | well, 51. |
| 21:21.55 | lkcl | ah then you've found the wrong IC. |
| 21:22.00 | ManoftheSea | but red1 is 8, and red2 is 8 |
| 21:22.03 | lkcl | let me take a look at the datasheet ok? |
| 21:22.12 | Turl | and some devices need 5v feed to them on some pin to switch modes |
| 21:22.17 | zub | Turl: there was some adapter with micro (or whatever) USB on one and, and USB A female on the other, I assumed that is an OTG adapter |
| 21:22.18 | ManoftheSea | http://www.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=532&uiTemplateId=NODE_STRY_PGE_T |
| 21:22.49 | zub | can I just force the port to host? I tried to change the kernel config, but selecting "HOST", it does not compile :( |
| 21:23.20 | ManoftheSea | with 8 "serial data transmitter channels", the DS90C387A looks good... |
| 21:23.26 | ManoftheSea | but I think that inputs is lying. |
| 21:25.54 | ManoftheSea | or rather than "it doesn't exist"... I did not find the chip you're looking for. |
| 21:26.35 | ManoftheSea | away |
| 21:27.57 | *** join/#arm-netbook bsdfox (~Bob@unaffiliated/bsdfox) |
| 21:28.16 | lkcl | ManoftheSea: page 2 says that it supports "option single pixel transmitter imputs" |
| 21:28.58 | rm | inexplicably I have 399 MB free instead of 315, and this is on a mali-enabled kernel |
| 21:29.37 | mnemoc | VE disabled? |
| 21:29.46 | mnemoc | VE takes 80 |
| 21:30.02 | rm | CedarX? |
| 21:30.06 | mnemoc | yes |
| 21:30.07 | Turl | rm check dmesg |
| 21:30.14 | lkcl | p16 explains that you can set the "DUAL" pin to 1/2 voltage (1.65V) and the chip will go into "single input, dual LVDS output" mode. |
| 21:30.14 | Turl | all the allocations are printed there |
| 21:30.20 | rm | # CONFIG_VIDEO_SUN4I_CEDAR is not set |
| 21:30.22 | rm | right! |
| 21:30.36 | rm | currenlty it does not work anyway in X11, correct? |
| 21:30.40 | rm | tl |
| 21:31.07 | mnemoc | it might work on armel/armv4 systems |
| 21:31.17 | mnemoc | but not on armhf |
| 21:31.28 | rm | I see |
| 21:31.33 | Turl | armv4? o.O |
| 21:31.38 | mnemoc | armel is armv4 |
| 21:31.47 | Turl | I thought it was armv5 |
| 21:31.58 | mnemoc | doubts |
| 21:32.19 | jelly-home | Debian's armel is armv5t |
| 21:32.33 | jelly-home | if you're talking about that ABI |
| 21:33.16 | mnemoc | http://wiki.debian.org/ArmEabiPort says v4 |
| 21:33.24 | jelly-home | if you had a v4 you'd run the older "arm", now nonexistent in debian |
| 21:33.26 | mnemoc | yes, libs ABI |
| 21:34.22 | Turl | https://es.wikipedia.org/wiki/Arquitectura_ARM#Familias awesome table for us spanish speakers :) |
| 21:35.47 | jelly-home | mnemoc: dunno, armel chroot completely failed to work last time I tried it on a v4 |
| 21:36.26 | mnemoc | jelly-home: thumb is required |
| 21:36.35 | mnemoc | jelly-home: that might be the reason |
| 21:36.45 | mnemoc | not all v4 had thumb |
| 21:36.53 | jelly-home | didn't even know there were v4t until I read that wiki page |
| 21:37.14 | mnemoc | :) |
| 21:38.28 | mnemoc | Turl: armel/armhf are debian platform names, including tons of chosen optimization flags, not exactly bound to an arm family or feature |
| 21:39.32 | mnemoc | armhf for example doesn't only mean hardfloat, also v7, neon and thumb2 iirc |
| 21:39.47 | Turl | mnemoc: I know |
| 21:40.07 | mnemoc | Turl: ah, ok. i got confused by the paste of the link |
| 21:40.17 | *** join/#arm-netbook Gujs (~Gujs@cpe-92-37-75-238.dynamic.amis.net) |
| 21:44.22 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 21:47.36 | TomNL | does anyone know if cnx hwpack work for mele? |
| 21:48.07 | TomNL | i have one from 19 september which works..but the ones from october dont even get to start u-boot it seems |
| 21:50.27 | mnemoc | problem is no one updates the hwpack generation code when the kernel or u-boot get changed |
| 21:50.53 | TomNL | ah ok, and it's changed? |
| 21:51.24 | mnemoc | yes |
| 21:51.49 | mnemoc | u-boot has changed dramatically during the last weeks |
| 21:51.56 | TomNL | ah ok |
| 21:52.03 | TomNL | hehe |
| 21:52.11 | TomNL | looking for different bin files now? |
| 21:54.12 | mnemoc | it does per-board dram and pmu initialization |
| 21:54.54 | mnemoc | in the case of the mele it means it has to be built using the mele_a1000 target instead of sun4i |
| 21:55.37 | TomNL | ah ok :) i will check the hw-pack create script and see if i can change it |
| 21:56.14 | mnemoc | it's on github |
| 21:56.36 | mnemoc | unfortunatelly it supports boards from which we don't have reliable dram initialization info yet |
| 21:57.12 | mnemoc | but for those which worked with the generic 'sun4i' using the mele's will probably work fine |
| 21:57.27 | mnemoc | and for 'sun5i' the a13_olinuxino's will do too |
| 21:57.58 | mnemoc | but those that required patching stuff need to be rethought |
| 23:02.53 | *** join/#arm-netbook ZaEarl_ (~malmrose@202.155.242.30) |
| 23:34.33 | ManoftheSea | lkcl: but that's just pixel doubling. |