| 00:34.41 | *** join/#arm-netbook DEAT_ (~heh@14-201-99-152.tpgi.com.au) |
| 00:52.34 | ManoftheSea | truecrypt? |
| 00:52.39 | ManoftheSea | Bleh at truecrypt. |
| 00:58.01 | *** join/#arm-netbook traeak (~bolsen@75-151-91-165-Colorado.hfc.comcastbusiness.net) |
| 00:58.01 | *** join/#arm-netbook hno (~hno@squid/developer/hno) |
| 01:08.48 | Turl | RaYmAn: ping me when around |
| 01:25.15 | lundman | doont do it! |
| 01:49.18 | *** join/#arm-netbook Boulet (~sid6581@207.126.93.2) |
| 02:09.18 | Boulet | all sleeping? |
| 02:10.31 | ManoftheSea | no. |
| 02:12.09 | orly_owl | yes, sssssh |
| 02:14.32 | lundman | WHAT? |
| 02:21.12 | Turl | hey lundman |
| 02:21.47 | Turl | lundman: what's the network perf of wemac like for you? |
| 02:22.07 | Turl | trying to figure out if I need to blame the wifi or something else without running any actual tests |
| 02:33.33 | *** part/#arm-netbook rmull (rmull@nooperation.org) |
| 02:34.46 | *** join/#arm-netbook hno (~hno@squid/developer/hno) |
| 02:37.36 | *** join/#arm-netbook hipboi (~hipboi@123.64.148.140) |
| 02:42.10 | *** join/#arm-netbook ManoftheSea (~ManoftheS@64.150.161.184) |
| 03:08.43 | WarheadsSE | X11: I hate you |
| 03:08.48 | WarheadsSE | X: malloc.c:2810: mremap_chunk: Assertion `((size + offset) & (_rtld_global_ro._dl_pagesize-1)) == 0' failed. |
| 03:09.45 | hipboi | : D |
| 03:09.46 | WarheadsSE | xxiao & hno : its not like these things are expensive |
| 03:09.51 | WarheadsSE | dupe & ship |
| 03:10.29 | *** join/#arm-netbook tallnerd1985 (~tallnerd1@c-67-171-158-206.hsd1.or.comcast.net) |
| 03:10.32 | WarheadsSE | hipboi: thanks for straightening out the name.. but seriously ""Arch Linux ARM"" |
| 03:10.47 | hipboi | ok |
| 03:12.09 | hipboi | changed |
| 03:13.00 | hipboi | i may take a while to change in the foregroud |
| 03:14.38 | WarheadsSE | :) |
| 03:15.02 | WarheadsSE | heh |
| 03:15.08 | WarheadsSE | "mele a100 arch" |
| 03:15.15 | WarheadsSE | platform page, smack in front :) |
| 03:16.38 | WarheadsSE | You can add this whenever you want :) http://archlinuxarm.org/platforms/armv7/mele-a100 |
| 03:17.43 | hipboi | aha |
| 03:17.44 | hipboi | good |
| 03:44.30 | Turl | WarheadsSE: am I the only one that doesn't get /dev/mmcblk* stuff? |
| 03:44.43 | Turl | on all my systems and devices it's /dev/*block*/mmcblk* |
| 03:45.28 | rz2k | tons of bots registrated again http://linux-sunxi.org/Special:RecentChanges |
| 03:45.38 | rz2k | we need captcha or something |
| 03:49.08 | Turl | yeah |
| 03:49.17 | Turl | as long as they don't spam it's not so bad though |
| 03:54.33 | CIA-121 | rhombus-tech: Jean-Luc_Aufranc master * r29b539205ccb /allwinner_a10/nightly_build_images.mdwn: Removed text about download hardfloat libs, since the build has been updated to use those. |
| 03:55.22 | WarheadsSE | Turl: let me boot it back up... |
| 03:56.53 | WarheadsSE | http://pastie.org/4453599 |
| 03:57.36 | Turl | WarheadsSE: yeah but it's /dev/block/NAME over here |
| 03:57.45 | WarheadsSE | what kernel |
| 03:57.55 | WarheadsSE | anroid/linux |
| 03:58.01 | Turl | the A10 one for example |
| 03:58.09 | WarheadsSE | well yeah.. |
| 03:58.28 | WarheadsSE | anroid or linux though ? |
| 03:58.47 | WarheadsSE | And I suppose it depends a bit on the distribution and devtmpfs + udev rules |
| 03:58.47 | Turl | the kernel is the same? :P |
| 03:59.00 | Turl | hmm |
| 03:59.11 | Turl | my mele has weirdo num:num entries on /dev/block/ only |
| 03:59.46 | Turl | all my android phones use /dev/block/ |
| 03:59.56 | WarheadsSE | might be an android thing then |
| 04:00.05 | Turl | my pc has /dev/block/ too with the weird numbers :P |
| 04:02.11 | xxiao | WarheadsSE: see quite a few of your posts in archlinux on pogoplug |
| 04:03.10 | xxiao | i have not used archlinux, what's the advantage of it? |
| 04:03.12 | WarheadsSE | well, yeah |
| 04:03.20 | WarheadsSE | I'm a core developer. |
| 04:03.22 | xxiao | smaller? faster? more stable? more hackish? |
| 04:04.14 | xxiao | looks like archlinux replaces other projects for all sorts of 'plug' computers |
| 04:04.19 | WarheadsSE | as compared to... |
| 04:04.27 | xxiao | debian |
| 04:04.34 | xxiao | debian stable |
| 04:04.37 | WarheadsSE | much more up to date |
| 04:04.46 | xxiao | sid? |
| 04:05.17 | WarheadsSE | the front page covers ut really |
| 04:05.20 | WarheadsSE | i have to go to bed |
| 04:05.26 | xxiao | ok, thanks, will check out |
| 04:27.57 | Turl | as far as I understand it, Arch is like Gentoo but without the "build all the things" part |
| 04:40.22 | furan | heh |
| 04:40.29 | furan | here I am scrounging for the kernel and it's u-boot.bin |
| 04:51.36 | *** join/#arm-netbook qubits (~nul@c-67-164-149-207.hsd1.nm.comcast.net) |
| 04:51.36 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 04:51.40 | furan | is there source for the silabs f76x? |
| 04:52.24 | qubits | will the lapdock and mele a2000 work well |
| 04:52.37 | qubits | or is there a better combo like the bluetooth minikb with trackpad |
| 04:52.47 | qubits | im thinking a 4 inch screen would be too small to see a shell on? |
| 06:42.03 | *** join/#arm-netbook Quarx (~Quarx@46.233.200.45) |
| 06:56.33 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 07:35.08 | RaYmAn | turl: dev block names are ueventd or udev |
| 07:58.58 | RaYmAn | Turl: also, I didn't write that dump_atags tool... but the headers are from linux kernel, so..I guess we GPL it? :P |
| 07:59.53 | mnemoc | everytging else in sunxi-tools is gplv2+ too |
| 08:00.34 | RaYmAn | 'k |
| 08:02.56 | RaYmAn | I did actually write a dumpatags (I didn't know this one was out there at the time), but I can't find my source anymore :( |
| 08:10.38 | RaYmAn | you wouldn't happen to have a linux dist for arm that's small enough to fit in ramdisk? :> |
| 08:12.27 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:9954:d564:6b6:712f) |
| 08:35.44 | *** join/#arm-netbook arokux_h (~arokux@HSI-KBW-37-49-124-55.hsi14.kabel-badenwuerttemberg.de) |
| 08:58.14 | mnemoc | rayman: rob landley's linux has minimal rootfs-s |
| 08:58.59 | mnemoc | RaYmAn: ----^ |
| 09:01.09 | Boulet | i'm also interested in a very very very small linux dist like this :) |
| 09:02.34 | mnemoc | http://www.landley.net/code/aboriginal/downloads/binaries/simple-root-filesystem/ |
| 09:02.46 | mnemoc | irc on android sucks even with znc |
| 09:05.42 | RaYmAn | mnemoc: irssi + irssi-connectbot is decent :> |
| 09:06.14 | RaYmAn | mnemoc: ah, cool - I'll try it out.. I was considering going custom with buildroot |
| 09:09.47 | Boulet | mnemoc this is for armv4 ??? |
| 09:10.05 | Boulet | what's armv4 ? hum arm7 ? ;) |
| 09:10.18 | mnemoc | one tarball per optimization |
| 09:10.35 | Boulet | oh sorry, did not see, for some reasons the names don't appear correctly |
| 09:10.48 | mnemoc | too long |
| 09:11.09 | Boulet | he does not have armv7 though |
| 09:14.49 | mnemoc | poke him on #elinux or #edev |
| 09:15.29 | Boulet | bah i don't know how to use all this anyways |
| 09:15.57 | mnemoc | just extract it and the cpio + gz |
| 09:16.04 | mnemoc | bbl |
| 09:17.49 | RaYmAn | Boulet: armv7 is backwards compatible |
| 09:17.54 | RaYmAn | so it can run armv4 just fine |
| 09:21.24 | Boulet | yes i am sure |
| 09:21.29 | Boulet | but maybe it's not as optimized |
| 09:22.01 | Boulet | and in armv7 if the CPU supports NEON, some basic stuff like string compare, copy, memset, memcpy can be even faster |
| 09:22.20 | hno | RaYmAn, who wrote dump_atags? |
| 09:22.20 | arokux_h | mnemoc, hi, what is going on with kernel development? |
| 09:22.25 | Boulet | just trying to save some precious cycles .... haahha |
| 09:22.45 | RaYmAn | I doubt there's anything preventing you from using NEON in your own app |
| 09:22.54 | Boulet | yes |
| 09:23.07 | hno | arokux_h, we are getting a hang on booting A10 b& A13 nicely |
| 09:23.09 | RaYmAn | hno: http://www.mesa.nl/~marcel/ |
| 09:23.11 | Boulet | no problem with that |
| 09:23.33 | arokux_h | hno, which branch are you working on? |
| 09:24.50 | hno | arokux_h, none. |
| 09:26.56 | hno | RaYmAn, ok, if the new tool is baeed on that then we need to ask if it's GPL before slapping a license on it. Most likely is. |
| 09:27.02 | arokux_h | hno, ok, let's put the question the other way. I've compiled and booted 3.0.x kernel and willing to do smth. is there anything you can point me to? |
| 09:27.47 | RaYmAn | hno: depending on whether Turl read the code or not :> The atag.h is verbatim from linux kernel source, so he definitely has no say over that |
| 09:27.56 | RaYmAn | hno: but yeah |
| 09:28.42 | hno | RaYmAn, ofcourse. Only if anything of the .c is used. |
| 09:29.17 | RaYmAn | hno: to be completely honest, I doubt any of the actual sourcecode in dumpatags would be useful for creating createatags. And it's clearly based off the kernel code that parses those tags :) |
| 09:30.18 | hno | arokux_h, mnemoc is the man to answer that, but you could try looking in the issue tracker. |
| 09:32.06 | specing | RaYmAn: compress whatever you have now with squashfs and upload it |
| 09:34.12 | RaYmAn | specing: If I had anything, that'd be what I would do ;) |
| 09:36.42 | RaYmAn | specing: also, can linux kernel use that from memory entirely? |
| 09:36.47 | specing | yes |
| 09:37.14 | specing | I've booted Gentoo over PXE like this before |
| 09:38.29 | RaYmAn | hm |
| 09:39.04 | hno | Yes. atag is just a TLV. Hard to fail writing one. |
| 09:39.05 | RaYmAn | how though? I mean, a cpio'd gzipped bundle I can just upload to memory and set initrd2 tag and it'll *poof* work :P |
| 09:40.02 | hno | RaYmAn, squashfs can be run from a ramdisk, so initrd mechanism works. |
| 09:40.45 | RaYmAn | what advantage does it have over a cpio'ed gzipped image? |
| 09:41.31 | specing | moar compression |
| 09:42.06 | hno | it stays compressed in memory, decompressed on access. |
| 09:42.13 | hno | runs slower |
| 09:42.15 | RaYmAn | ah |
| 09:42.18 | hno | much harder to extend |
| 09:42.49 | arokux_h | sun3i <--- is that of interested or is it some older code? |
| 09:42.50 | hno | the initramfs images is trivial to extend. Just concat another cpio.gz archive with the changes. |
| 09:43.16 | hno | arokux_h, that's the older F20 chips. |
| 09:43.27 | hno | not sure if there is any activity on those at the moment. |
| 09:47.40 | RaYmAn | pokes Turl |
| 09:47.48 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.111) |
| 09:56.21 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
| 09:57.30 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
| 09:59.34 | *** join/#arm-netbook Quarx|2 (~Quarx@46.233.200.45) |
| 10:09.39 | *** join/#arm-netbook arokux_h (~arokux@HSI-KBW-37-49-124-55.hsi14.kabel-badenwuerttemberg.de) |
| 10:28.52 | arokux_h | hno, I'm somehow confused. how is the mainlining done in general? fixing some issues on the github means backporting of some bug fixes from the upstream. but is this mainlining? |
| 10:37.21 | rz2k | mainlining is getting rid of all allwinnerization of kernel, unification of platform/machine specific stuff. long story short: getting code to kernel standards. only when code is done like other machines/platforms for archeticture it can be added to upstream kernel. |
| 10:37.59 | rz2k | usually its done by SoC/CPU manufacturers themselves. |
| 10:49.40 | arokux_h | rz2k, for example there is the following issue, which describes the possible bug in the ibm_newemac: https://github.com/amery/linux-allwinner/issues/49 |
| 10:50.12 | arokux_h | however, such a driver exists in the mainline. so should we really need to care about fixing this? |
| 10:50.53 | arokux_h | isn't the first priority just to get vanilla kernel running on the allwinner and only after that to fix all the bugs left? |
| 10:51.36 | RaYmAn | arokux_h: I don't see any reference to ibm_newemac anywhere in that bug? |
| 10:52.39 | RaYmAn | arokux_h: also, keep in mind that mainlining is a *huge* effort |
| 10:53.25 | RaYmAn | Allwinner has done a lot of things in their own ways, so things have to be rewritten to use mainline ways |
| 10:54.10 | arokux_h | ibm_newemac = wemac |
| 10:54.37 | RaYmAn | yeah, I figured that what was you meant, but are you sure that's the case? =P |
| 10:55.03 | arokux_h | oh.. probably not! |
| 10:55.31 | arokux_h | shit, I haven't scrolled the grep results till to the end. |
| 10:56.55 | Boulet | RaYmAn, so when fel execute some code, MMU is enabled ? |
| 10:56.57 | arokux_h | there is sun4i_wemac too. ok. so in this case will be the right mainlining way to mainline this driver and push it upstream? |
| 10:57.17 | RaYmAn | arokux_h: yeah - that's the plan. |
| 10:57.18 | arokux_h | I'm just confused as what is the correct workflow... |
| 10:57.38 | RaYmAn | Boulet: seems like it. But I guess someone has to write code to verify. |
| 11:04.27 | arokux_h | RaYmAn, another stupid question: suppose I've rewritten sun4i_wemac to be a shiny canonical driver. how could I test it? could I use this driver together with allwinner-v3.0-android-v2 or it depends? |
| 11:04.51 | RaYmAn | SHould be possible, I'd say |
| 11:05.10 | arokux_h | basically the question is if the inner APIs of the ethernet drivers changed between 3.0.0 and linux-torvalds. |
| 11:05.48 | RaYmAn | The big problem is, does it make sense & would it be accepted to submit such a driver by itself? It's for an allwinner specific builtin device |
| 11:06.14 | RaYmAn | e.g. do we need basic support for allwinner a10/a13 in kernel first before we can start submitting drivers |
| 11:07.08 | arokux_h | I see. I'm just looking for a corner for me to hack. |
| 11:08.06 | RaYmAn | I'm not trying to discourage you, it's just not easy to find out where it makes sense to work |
| 11:08.14 | arokux_h | also: in the driver module it says: Davicom wemac network driver. could it be that this device is used *only* on allwinner boards?! |
| 11:08.18 | RaYmAn | though, I believe most of the mainlining effort goes on in the 3.4 branch |
| 11:08.45 | RaYmAn | arokux_h: that's my theory :P (on allwinner, it's actually part of the SoC, NOT an external component) |
| 11:10.02 | arokux_h | RaYmAn, hm.. isn't it the same with normal intel ethernet modules which are also builtin into the motherboard? |
| 11:10.31 | rz2k | arokux_h: ping rm about davicom, I remember he said something about allwinner grabbing some IP core for ethernet and public driver for it |
| 11:10.58 | arokux_h | IP core? |
| 11:11.03 | RaYmAn | arokux_h: mm, it's possible. It's a bit more integrated when it's actually in the SoC, rather than on the board. |
| 11:11.42 | rz2k | arokux_h: http://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core |
| 11:12.15 | rz2k | instead of making own ethernet, they just buy core and integrate it with their ASIC |
| 11:13.07 | arokux_h | rz2k, ok, but the buy only the logic and produce the hardware themselves? |
| 11:15.34 | arokux_h | RaYmAn, what falls under "basic" support? and what happens currently if vanilla kernel is booted on A10? :) |
| 11:15.56 | RaYmAn | arokux_h: try it! :) |
| 11:16.14 | arokux_h | I work on it remotely.. :) |
| 11:16.27 | RaYmAn | embedded devices are quite different than normal x86 systems |
| 11:16.43 | rz2k | they integrate IP core in their design, usually core has in/out ports and needs only light customization/configuration, then they grab public linux driver for that core and ethernet is done. |
| 11:17.00 | rz2k | fast and simple. |
| 11:17.12 | RaYmAn | while obviously some of the code will work (because it's arm), it won't know how to talk to anything. Register mappings are per-SoC etc - and arm has no real "auto-configuration" support |
| 11:17.22 | RaYmAn | arokux_h: so basically, you'll mostly see nothing happening |
| 11:18.24 | rz2k | lets bring device tree support to sun4i |
| 11:18.47 | RaYmAn | of course that's part of the plan =P |
| 11:18.53 | rz2k | then mainline guys will be interested in us, because its sorta, bleeding edge technology. |
| 11:19.09 | RaYmAn | I think device tree support is required for new devices, isn't it? |
| 11:19.14 | rz2k | yes |
| 11:20.17 | rz2k | for all of them, I have pretty dumb situation here regarding device tree, Renesas officially added EV2 support to mainline in 3.5, BUT they didnt release U-Boot with device tree support for EV2. |
| 11:20.36 | rz2k | so basically I cant even load it right without JTAG :3 |
| 11:21.09 | RaYmAn | sucks :( |
| 11:21.48 | RaYmAn | I saw on tegra, they made a 'hack' (iirc mainline), where it uses a kernel-appended device tree and then merges it with bootloader provided (old) values |
| 11:24.36 | arokux_h | what is done of the "basic support"? |
| 11:26.51 | arokux_h | RaYmAn, and what is the relation of the linux-sunxi-3.4 to the android kernel? :) |
| 11:28.11 | RaYmAn | no idea |
| 11:28.15 | RaYmAn | "the android kernel" |
| 11:28.21 | RaYmAn | that's a really broad non-specific term .P |
| 11:30.14 | arokux_h | RaYmAn, so do you do some kernel development yourself? |
| 11:30.39 | RaYmAn | yes - haven't done a lot wrt allwinner yet though. |
| 11:33.08 | rm | arokux, afaik Allwinner's wemac is not a derivative of a Davicom chip, it's just vaguely similar and the Davicom driver was used as a template for the wemac driver |
| 11:33.14 | lkcl | arokux: the ethernet driver looks very much like it's a DM9000, with the registers being slightly different due to the way that allwinner connected them together |
| 11:33.39 | rm | but the way hardware is controlled is quite different, afaik lundman done some comparison of these drivers |
| 11:34.29 | rm | thanks lkcl :) |
| 11:34.51 | lkcl | i believe it was established that yes, the hardware is the same but the connectivity is different from a "DM9000-as-sold-as-a-separate-integrated-IC" and "DM9000-circuits-as-used-inside-the-A10" |
| 11:35.07 | arokux_h | let me understand some another thing guys: is a purpose to mainline into vanilla linux or vanilla android kernel? |
| 11:35.38 | RaYmAn | linux. Android kernel is just addons on top of linux |
| 11:35.43 | lkcl | so, allwinner went "hmm, if we wire this DM9000 circuit up onto the AMBA bus, we're going to have to make register1,2,3 and 4 all addressable on the same 32-bit memory location" |
| 11:35.48 | lkcl | etc. etc. blah blah :) |
| 11:36.18 | RaYmAn | so if we get a10/a13 support into mainline linux, it will automatically (kind of) show up in new android kernels :P (eventually) |
| 11:37.25 | lkcl | RaYmAn: well... maybe, and maybe not. the allwinner team *might* decide that the code isn't right for them, strip it all out, start using different subdirectory names and continue on their existing (isolated) path |
| 11:37.52 | RaYmAn | lkcl: sure, I didn't mean allwinner kernel,I meant google android kernels. |
| 11:38.01 | lkcl | same thing. |
| 11:38.22 | RaYmAn | how so? |
| 11:38.42 | lkcl | doesn't make any difference. yes, sure, it would "turn up" in the kernel.org and/or code.google.com "official" android sources |
| 11:38.50 | RaYmAn | As far as I'm concerned the goal is to ignore allwinner mostly and only pull in any fixes we might get from them by accident |
| 11:38.55 | lkcl | but what good does that do you for a *specific* device? |
| 11:39.05 | lkcl | oh, ok - great! :) |
| 11:39.25 | RaYmAn | It certainly makes the process easier for supporting new devices |
| 11:39.39 | RaYmAn | if we have generic allwinner in mainline + google android kernels |
| 11:39.50 | lkcl | i thought you meant "show up in new android kernels i.e. in mass-volume hardware products i.e. in binary form i.e. as sold" |
| 11:39.52 | RaYmAn | especially with device tree support |
| 11:39.57 | RaYmAn | oh, nah |
| 11:40.06 | RaYmAn | I was purely talking about the kernel source |
| 11:40.19 | lkcl | sorry, jumped ahead a step there |
| 11:40.23 | RaYmAn | I'm not expecting allwinner to use "our" code |
| 11:40.34 | RaYmAn | I have little faith in allwinner, other than hipboi |
| 11:40.36 | RaYmAn | heh |
| 11:40.45 | arokux_h | why then android kernel is merged into linux tree?! https://github.com/amery/linux-allwinner/commit/6fe780051563e857d3892d19559054a74393457f |
| 11:41.14 | RaYmAn | lkcl: your notes on your site makes allwinner seem so nice, yet in practice it's nowhere near as nice ;) (the comments about board of directors and gpl) |
| 11:42.29 | RaYmAn | </random comment> |
| 11:42.30 | RaYmAn | :) |
| 11:42.41 | RaYmAn | arokux_h: so we can use android? :) |
| 11:44.11 | arokux_h | RaYmAn, so it could be merged very easily..? |
| 11:44.21 | lkcl | RaYmAn: directors aren't the ones who have to action their decisions.... :) |
| 11:44.37 | lkcl | ok, not in huge companies... |
| 11:46.18 | RaYmAn | arokux_h: as I said, android parts are (mostly) just extra drivers and a few differences in setup. It's still a linux kernel. |
| 11:46.48 | RaYmAn | lkcl: mmm, but they decide to make silly (illegal) NDA's with their customers still. |
| 11:46.52 | RaYmAn | :) |
| 11:52.06 | arokux_h | RaYmAn, so the current development branch is linux-sunxi-3.4 and allwinner-v3.0-android-v2 being a legacy stable one? |
| 11:53.23 | RaYmAn | both are actively developed (linux-sunxi-3.4 mostly in seperate topic branches) |
| 11:53.30 | RaYmAn | mainlining is longterm |
| 11:54.57 | arokux_h | RaYmAn, why is 3.0 still developed? |
| 11:55.10 | RaYmAn | presumably because it's the most complete branch. :) |
| 11:56.12 | arokux_h | ok, this was my guess to. |
| 11:56.16 | arokux_h | too* |
| 11:57.30 | RaYmAn | hno: you happen to know the C entry point of u-boot? |
| 12:03.30 | arokux_h | RaYmAn, what does the prefix "wip/" at the number of branches mean? |
| 12:03.44 | RaYmAn | work in progress |
| 12:03.46 | techn | whee.. I got first output from fbcon :) |
| 12:03.58 | RaYmAn | oh, cool! on a10? |
| 12:04.03 | techn | yep.. a10 |
| 12:04.07 | RaYmAn | awesome! :) |
| 12:04.22 | techn | still bit slow, but just proof of concept |
| 12:04.32 | RaYmAn | it's certainly better than blank :) |
| 12:04.49 | techn | trying to clean it today and send patch if u are interested |
| 12:04.58 | arokux_h | techn, on 3.4 branch? |
| 12:05.17 | techn | i'm using androidv2 |
| 12:07.34 | rz2k | awesome techn |
| 12:07.48 | arokux_h | does anyone knows if linux-sunxi-3.4 is bootable on A10? |
| 12:08.03 | arokux_h | and if it will have ethernet? |
| 12:08.44 | techn | after decre |
| 12:09.15 | techn | after decreasing prints.. it's pretty fast.. :) |
| 12:09.45 | rz2k | afaik, 3.4 has a weird bug regarding memory mapping, some time ago I've tried to boot it and it always failed at LCD memory initialization |
| 12:10.02 | rz2k | on mele it worked |
| 12:10.28 | techn | btw.. can I put disp, hdmi etc drivers inside kernel? So that we'll get boot traces? |
| 12:11.14 | arokux_h | rz2k, what was the other device you were booting it on? |
| 12:11.18 | RaYmAn | I think previous attempts have shown failures wrt initializing mali stuff if you do that? |
| 12:11.48 | rz2k | techn: you need correct modules order to make mali work |
| 12:12.23 | rz2k | arokux_h: LY-F1 tablet, http://linux-sunxi.org/LY-F1 |
| 12:12.28 | techn | so inorder to get bootlogs, we'll need to refactor codes.. cleanup dependencies? |
| 12:14.15 | techn | or would initramfs help as workaround? |
| 12:14.35 | rz2k | j1nx did initramfs support for a10 |
| 12:14.42 | rz2k | it was in his blog |
| 12:14.46 | rz2k | with examples and everything |
| 12:14.53 | techn | k |
| 12:15.34 | rz2k | http://www.j1nx.nl/initramfs-support-for-the-allwinner-a10/ |
| 12:17.48 | arokux_h | another stupid question guys..: what is the status of http://linux-sunxi.org and rhombus-tech websites? |
| 12:25.15 | arokux_h | hm.. doe cubieboard has something in common with Tom Cubie aka. hipboi? |
| 12:25.31 | RaYmAn | yeah, he's making it |
| 12:25.31 | RaYmAn | :P |
| 12:25.43 | rm | i.e. has everything in common :) |
| 12:29.39 | arokux_h | what about websites? |
| 12:42.27 | hno | techn, what is problem with getting logs when having kernel modules? Have never heard of such problems before. |
| 12:43.16 | hno | arokux_h, what about the web sites? Both are alive and kicking. |
| 12:43.25 | techn | hno: just verifying, that modules can be loaded early enough :) |
| 12:43.38 | arokux_h | hno, but duplicating each other a bit. |
| 12:43.40 | hno | early enough for what? |
| 12:43.50 | techn | to get boot logs |
| 12:43.54 | hno | arokux_h, it's a web. |
| 12:44.08 | hno | Why can't you get logs when loading modules? |
| 12:44.25 | techn | I mean logs to fbcon |
| 12:44.47 | hno | There is no fbcon on A1x yet. |
| 12:44.59 | techn | hno: I have :) |
| 12:45.06 | hno | you have? |
| 12:46.02 | techn | prototype currently |
| 12:46.51 | hno | please push any changes to mnemoc. |
| 12:47.54 | hno | arokux_h, we work on reducing the duplication. But there will always be some, even if there was just one web side for all. |
| 12:48.50 | techn | I'll send patch/push when everything is ok for me.. There is propably still some things to do after that.. I'm currently newbie with kernel coding ;) |
| 12:49.30 | hno | techn, it's fine to push early. |
| 12:49.39 | hno | actually preferred even. |
| 12:55.10 | arokux_h | hno, what component of the kernel has the best chance of accepting in upstream? |
| 12:58.18 | RaYmAn | hno: u-boot actually gets surprisingly far on a13 - it fails completely at mmc, presumably because I'm using it for console and jtag ;) |
| 12:58.39 | RaYmAn | hno: do I need a specific branch to be able to use nand from it? or even just completely ignore storage |
| 12:59.15 | hno | arokux_h, mach-sunXi has reasonable chance. Most drivers not.. |
| 13:00.29 | arokux_h | hno, by mach-sunXi, do you mean arch/arm/mach-sun4i/* ? |
| 13:06.32 | hno | arokux_h, yes. |
| 13:07.00 | hno | RaYmAn, I have a wip/explorenand branch. |
| 13:08.16 | hno | but license header on u-boot nand driver have not been updated. Now most of it is the same as in kernel, but need allwinner to slap a suitable license on some u-boot unique files. |
| 13:10.18 | RaYmAn | hno: hmm..Aren't they by definition GPL though? :) |
| 13:11.40 | RaYmAn | but I get your point |
| 13:15.06 | WarheadsSE | @ #fosscon |
| 13:17.41 | hno | RaYmAn, licensing do no work that way. |
| 13:19.10 | RaYmAn | hno: mm. I guess. But legally speaking, it's either GPL or illegal. |
| 13:20.03 | RaYmAn | given they've released binaries based upon it |
| 13:20.04 | hno | something non-GPL do not get GPL license only because you mix them. What you get is a mess that can not be redistributed in compliance with GPL. |
| 13:20.45 | hno | and only copyright owners can assign license |
| 13:21.15 | RaYmAn | I get your point - and I know technically speaking, you're of course right |
| 13:24.04 | RaYmAn | You just get the urge to say fuck you to GPL violating companies and go "if they can break license, so can I" :) But I know- two wrongs doesn't make a right. :) |
| 13:24.22 | WarheadsSE | it just means they can't rightfully sue you for it |
| 13:24.53 | WarheadsSE | doesnt mean they wont try |
| 13:24.57 | *** join/#arm-netbook Quarx (~Quarx@46.233.200.45) |
| 13:25.43 | xenoxaos | we may be working with some lawyers to poke at gpl violators for arm targeted devices |
| 13:26.21 | RaYmAn | The issue, as usual, is that most of these chinese companies couldn't care less, because you are so unlikely to 1) even get them in court 2) win in china |
| 13:26.32 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.103) |
| 13:27.34 | xenoxaos | we'll still try working with some of them |
| 13:27.45 | RaYmAn | sure :) |
| 13:27.53 | WarheadsSE | True, but when they officially become an american-selling business, they come into our jurisidction |
| 13:30.11 | xenoxaos | is actually making headway with via/wondermedia |
| 13:30.34 | RaYmAn | via has a fairly large american side don't they? |
| 13:30.57 | xenoxaos | ya |
| 13:31.42 | WarheadsSE | yup |
| 13:31.49 | WarheadsSE | and now the APC.IO |
| 13:31.54 | WarheadsSE | which is american targetted |
| 13:31.57 | WarheadsSE | ding! |
| 13:33.12 | Boulet | should allwinner open CedarX ? |
| 13:33.31 | RaYmAn | that's probably one of the few things they aren't required to |
| 13:33.41 | Boulet | how so ? |
| 13:34.07 | RaYmAn | there's no evidence CedarX is GPL violating afaik |
| 13:35.32 | Boulet | so they can create .so libraries and not open them because "it seems like" they are not violating GPL ? |
| 13:35.54 | Boulet | i thought as soon as you had a user-mode application, you had to publish its source code, even the dynamic libraries |
| 13:35.59 | RaYmAn | no |
| 13:36.08 | arokux_h | the prefix "mach-" means micro arch or what? |
| 13:36.11 | RaYmAn | that's completely wrong |
| 13:36.32 | WarheadsSE | no, thats not how it works |
| 13:36.38 | Boulet | RaYmAn, so someone who creates a dynamic library that is not based on anything does not need to publish its source code ? |
| 13:36.46 | WarheadsSE | just because you link against the glibc does not make it free |
| 13:36.49 | RaYmAn | Boulet: user-mode applications can be any license they want to be. *IF* they use GPL libraries they have to be GPL |
| 13:36.55 | WarheadsSE | re: ati & nvidia video drivers |
| 13:37.18 | WarheadsSE | and *using* does not mean linking to. |
| 13:37.30 | WarheadsSE | if they incorporate the code library. |
| 13:37.30 | RaYmAn | really? that sounds wrong. |
| 13:37.41 | Boulet | RaYmAn, if a main application loads some dyn lib that are GPL and some dyn lib that are non-GPL, the main app needs to have its source code published ? |
| 13:37.51 | RaYmAn | Boulet: yes, read the GPL. |
| 13:37.52 | WarheadsSE | you can use an API without being required to use that API's library |
| 13:38.10 | WarheadsSE | it depends on the licenses really |
| 13:38.28 | RaYmAn | Boulet: it doesn't matter whether it's dynamically loaded or not. |
| 13:38.43 | RaYmAn | Boulet: it depends on license. Glibc for example is LGPL, not GPL. |
| 13:38.53 | RaYmAn | LGPL specifically allows dynamic linking |
| 13:39.16 | RaYmAn | so if you use an LGPL library, you're only required to publish any changes you make to the library itself |
| 13:39.29 | Boulet | i understand, but one could publish the code of a main app that uses GPL stuff, and not publish the code of a dynamically loaded library that is based on nothing |
| 13:40.18 | WarheadsSE | ^ like cedar x |
| 13:40.38 | Boulet | right, so cedar x is not violating anything |
| 13:40.40 | Boulet | ok |
| 13:40.41 | RaYmAn | I believe that's kind of a gray area, lol |
| 13:40.49 | Boulet | well it should not |
| 13:40.54 | Boulet | it should be black or white ! |
| 13:41.02 | RaYmAn | legal is never black or white. |
| 13:41.11 | WarheadsSE | nor is morality, so |
| 13:41.15 | WarheadsSE | welcome to earth |
| 13:41.16 | RaYmAn | indeed |
| 13:42.03 | RaYmAn | Boulet: also, keep in mind android is Apache licensed, not GPL. |
| 13:42.18 | RaYmAn | So GPL things do not apply to CedarX |
| 13:42.39 | Boulet | can't you use cedarx libs without android ? |
| 13:43.06 | RaYmAn | probably, but that's not how licenses work |
| 13:43.24 | RaYmAn | I mean, if you make an app that uses cedarx lib and you GPL it, it won't suddenly apply CedarX... |
| 13:44.19 | WarheadsSE | ah the joys of licensing.... |
| 13:44.27 | RaYmAn | indeed |
| 13:44.31 | Boulet | it seems really a big pain in the .... |
| 13:44.45 | RaYmAn | really, you need a lawyer to be sure of anything |
| 13:44.55 | Boulet | soon any small software company will need some lawyers to deciphers those things |
| 13:45.08 | Boulet | and he will say "that's a gray area" |
| 13:45.11 | Boulet | and thank you |
| 13:45.27 | RaYmAn | any small software company that intends to "get around" legal licenses to software. |
| 13:45.30 | RaYmAn | Everyone else is fine. |
| 13:45.46 | Boulet | personally, i don't want to get around legal licenses |
| 13:45.52 | Boulet | but i'd like to make sure i understand |
| 13:46.30 | RaYmAn | did you read GPL, LGP and similar? :) |
| 13:46.32 | RaYmAn | that's a good start |
| 13:46.51 | Boulet | too complex for me hahahahah |
| 13:47.12 | Boulet | so i assumed, i'll always give my source code away |
| 13:47.18 | arokux_h | the prefix "mach-" means micro arch or what? |
| 13:48.10 | WarheadsSE | machine |
| 13:50.26 | Boulet | RaYmAn are you going to try that small linux that fits in a ramdisk ? |
| 13:50.52 | RaYmAn | Boulet: yeah, whenever I get a chance to uhm, create my atags. Waiting for Turl ;) |
| 13:51.17 | Boulet | i'm curious to know how fast that thing can boot |
| 13:51.45 | Boulet | although i guess things can be improved, like initializing DDR3 and CPU with faster clocks |
| 13:51.55 | WarheadsSE | eh |
| 13:52.03 | Boulet | i haven't tried to go above 360 MHz yet |
| 13:52.10 | WarheadsSE | my a100 hits console in ~ 4 seconds |
| 13:52.14 | Boulet | and i wonder if one has to play with AXP209 to give more current |
| 13:52.30 | Boulet | WarheadsSE, not bad ! |
| 13:52.41 | WarheadsSE | class 10 sd |
| 13:53.36 | Boulet | ah you boot it all from SD ? |
| 13:54.02 | WarheadsSE | yes |
| 13:54.13 | Boulet | neat :) |
| 13:54.17 | Boulet | what file system you have on it |
| 13:55.03 | WarheadsSE | ext4 noatime |
| 14:03.29 | arokux_h | any idea why early_print needed to be changed for A10? https://github.com/amery/linux-allwinner/commit/941fe44a605833895fb5d75a0869237d015dc6b3#diff-4 |
| 15:02.14 | *** join/#arm-netbook tuliom (~tuliom@177.133.177.58) |
| 15:09.23 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 15:10.25 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 15:10.50 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 15:14.19 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 15:24.13 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 15:42.37 | *** join/#arm-netbook Vayun (~yundin@85.233.249.22) |
| 15:43.41 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 15:53.25 | Turl | ohai RaYmAn ;) |
| 15:57.47 | RaYmAn | hno: here? |
| 16:08.26 | blahee | I did aquire a Alink Smart TV. Runs android by default and of course i did open it. Does have AMlogic AML8726-M (soemthing like 800Mhz Cortex-A9) |
| 16:09.27 | blahee | That does have a RF-connected keyboard + mouse which does have internal reciver in just internal USB-port, so the keyboard is usable for anything. Tested that the keyboard just works with my PC desktoip too |
| 16:09.49 | *** join/#arm-netbook Boulet (~sid6581@207.126.93.2) |
| 16:18.17 | xenoxaos | is working on the amlogic chip |
| 16:18.39 | hno | RaYmAn, barely here. |
| 16:18.52 | hno | is outside at the grill |
| 16:19.11 | RaYmAn | hno: 'k, nevermind :) was just wondering if you knew how much data there were before nanda - the answer is 0xFFFFF bytes |
| 16:19.48 | RaYmAn | hno: also, u-boot compiled for a10 runs just fine on a13 :) Booting from fel after running test1 that is. |
| 16:19.51 | specing | 2M? |
| 16:20.28 | RaYmAn | isn't it more like 1MB? |
| 16:20.35 | specing | yeah, sorry |
| 16:20.53 | RaYmAn | I guess technically speaking it's actually 0x100000 bytes |
| 16:21.05 | RaYmAn | with the last byte being at 0xFFFFF |
| 16:21.09 | Turl | 0x100000 bytes = 1 megabyte |
| 16:23.18 | hno | RaYmAn, you got access to the boot blocks? |
| 16:23.34 | RaYmAn | hno: yes - I just applied the sun4i patch to the sun5i driver |
| 16:23.57 | hno | The MBR one? That's not the boot blocks.. |
| 16:24.09 | RaYmAn | oh, hmm |
| 16:24.25 | RaYmAn | I assumed the point of that patch was to expose the full nand |
| 16:25.05 | RaYmAn | but now that you mention it, is does seem completely empty after the MBR data |
| 16:25.25 | hno | It exposes the full logical block device. Below it there is wear levelling, and raw nand. The boot blocks is in the first erase blocks. |
| 16:25.33 | RaYmAn | hm |
| 16:25.39 | RaYmAn | so uhm, is there any way to access those? :P |
| 16:26.18 | hno | sure. just haven't succeded in doing so yet... |
| 16:26.30 | RaYmAn | fair enough |
| 16:26.30 | RaYmAn | heh |
| 16:26.43 | RaYmAn | So I guess I'm not homefree just yet :( |
| 16:27.39 | RaYmAn | The whole point of getting this kernel booting over fel was so I could dump using serial-over-sd without flashing a possibly non-working kernel to device :S |
| 16:27.55 | hno | there is code in the u-boot nand driver tat is supposed to give a reasonable api for accessing those block, but only got garbage when trying to use it |
| 16:28.22 | hno | RaYmAn, you don't need the boot blocks for that. |
| 16:28.41 | RaYmAn | hno: Can I count on the boot blocks being identical across different a13 devices? |
| 16:29.09 | hno | no, they contain DDR setup etc. |
| 16:29.17 | RaYmAn | cause the issue is, I only have a somewhat generic livesuit image for a13... |
| 16:29.33 | RaYmAn | so if I break it, I can't really recover |
| 16:30.00 | RaYmAn | (well, ok - that's not really true - Now I can that boot kernel over fel, I can really just boot and revert things to stock) |
| 16:36.44 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 16:38.10 | RaYmAn | So that works ok :) Can boot kernel, incl. ramdisk from fel |
| 17:22.14 | Quarx | someone pro in linux kernel modules? |
| 17:23.14 | Turl | Quarx: I'm not 'pro' but maybe I can help? |
| 17:25.44 | Quarx | Turl: yea, i want make KSM module... almost part already in kernek except ksm.c. errors: http://epsy.ath.cx:888/paste/?783 this symbols already in kernel, but how say this to compiler. |
| 17:27.55 | Turl | Quarx: epsy paste not working? :/ |
| 17:28.12 | Quarx | Turl: http://pastebin.com/Jeb5zmep |
| 17:28.27 | Quarx | linker problems.. |
| 17:28.35 | Turl | you need to export the symbols |
| 17:28.57 | Quarx | in ksm.c? |
| 17:29.10 | Turl | EXPORT_SYMBOL(munlock_vma_page) etc |
| 17:29.16 | Turl | in the file where munlock_vma_page is defined and used |
| 17:29.21 | Turl | etc |
| 17:30.52 | Turl | Quarx: for example |
| 17:30.53 | Turl | http://lxr.linux.no/#linux+v3.3/mm/mlock.c#L106 |
| 17:31.17 | Turl | add EXPORT_SYMBOL(munlock_vma_page) after that declaration |
| 17:32.51 | Quarx | and i should include this file to obj? |
| 17:33.17 | Turl | hm? |
| 17:34.04 | Turl | Quarx: http://www.mail-archive.com/kernelnewbies@nl.linux.org/msg03562.html |
| 17:35.09 | Turl | also http://www.mail-archive.com/kernelnewbies@nl.linux.org/msg03545.html |
| 17:35.12 | RaYmAn | Quarx: it's functions your module needs to CALL in the kernel in order to work properly |
| 17:36.01 | RaYmAn | so they need to be available for calling from external => EXPORT_SYMBOL |
| 17:36.38 | Quarx | i added EXPORT_SYMBOL(munlock_vma_page); |
| 17:36.38 | Quarx | recompiled kernel with it, then i tried compile module and got this error again |
| 17:36.49 | RaYmAn | for same symbol? |
| 17:37.08 | Quarx | yes ERROR: "munlock_vma_page" [mm/ksm.ko] undefined! |
| 17:37.08 | RaYmAn | you need to do it for all the symbols it's complaining about |
| 17:38.08 | RaYmAn | you might need to make clean if you haven't |
| 17:39.52 | arokux_h | http://www.youtube.com/watch?v=3DLBI-JXvFQ |
| 17:42.57 | Quarx | ok, now module compiled without errors, but module can't find this symbols in kernel |
| 17:43.06 | Quarx | <4>[ 930.767181] ksm: Unknown symbol page_address_in_vma |
| 17:43.33 | Quarx | cat /proc/kallsyms | grep page_address_in_vma |
| 17:43.33 | Quarx | c00c084c T page_address_in_vma |
| 17:43.53 | RaYmAn | and you are booting the kernel you just compiled? |
| 17:44.04 | Quarx | i can't use custom kernel... |
| 17:44.10 | Quarx | i can use only modules |
| 17:44.39 | RaYmAn | ok, that's your issue then. |
| 17:44.53 | RaYmAn | You didn't give enough information for us to provide a suitable answer ;) |
| 17:49.01 | Quarx | i'm think me need use SYMSEARCH |
| 17:49.45 | RaYmAn | then you're mostly screwed tbh. Depending on what the missing symbols do, it may or may not be possible to 'reimplement' them in your module - or call them by address if that's possible |
| 17:52.48 | Turl | RaYmAn: that's what symsearch does I believe |
| 17:53.20 | RaYmAn | yeah, I kind of figured |
| 17:53.21 | RaYmAn | :P |
| 18:02.20 | CIA-121 | rhombus-tech: Nguyen master * r08429bdbfb27 /allwinner_a10/orders/snowflake.mdwn: |
| 18:06.54 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@37.26.146.230) |
| 18:09.09 | Quarx | yea, symsearch works:) |
| 18:10.25 | Quarx | thanks guys:) |
| 18:11.56 | RaYmAn | what device is it? |
| 18:12.53 | Turl | RaYmAn: defy most likely |
| 18:17.39 | Quarx | yes, defy |
| 18:19.34 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 18:21.53 | *** join/#arm-netbook eFfeM (~frans@g235028.upc-g.chello.nl) |
| 18:39.49 | hno | RaYmAn, livesuit for A13 should auto-detect your hardware and configure the boot blocks accordingly |
| 18:39.49 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 18:40.55 | RaYmAn | hno: hm, ok. |
| 18:41.34 | RaYmAn | hno: I guess even if it doesn't I should be relatively ok when the test1 app successfully initializes the ram, shouldn't I? |
| 18:42.40 | RaYmAn | hm - I guess if ram paramenters is all that's different, I should be able to dump those from "live" registers after booting with boot0 |
| 18:47.40 | hno | RaYmAn, yes |
| 18:48.21 | hno | or use JTAG to dump boot0 after BROM have loaded it. |
| 18:49.02 | RaYmAn | hm |
| 18:51.31 | hno | a breakpoint @0 shuld do the trick. |
| 18:51.39 | RaYmAn | yeah, except that doesn't work :/ |
| 18:52.04 | hno | why? |
| 18:52.55 | RaYmAn | it looses connection when device reboots and it seems like it isn't really able to reconnect properly |
| 18:53.07 | RaYmAn | and breakpoints definitely aren't preserved across reboots |
| 18:53.19 | ManoftheSea | loses |
| 18:54.57 | RaYmAn | I guess best bet is replacing uboot with a simple app that just loops forever, so I can break on that and hope that LR is preserved =P |
| 18:55.03 | hno | RaYmAn, not even on a reset triggered via jtag? |
| 18:55.33 | RaYmAn | hno: there's no JTAG reset signal brought out |
| 18:55.46 | RaYmAn | I tried the watchdog reboot method, but seemed to have same issue there |
| 18:56.01 | RaYmAn | so I need a better way to reboot for that to work I guess |
| 18:56.52 | RaYmAn | alternatively, maybe brom doesn't mind running again ;P e.g. just jump to brom entry point |
| 19:02.21 | hno | RaYmAn, I do mean reset via JTAG. You can reset the CPU by JTAG commands. |
| 19:02.44 | RaYmAn | in that case openocd doesn't seem to know about it. |
| 19:03.13 | RaYmAn | The config files I've rummaged through, all either use the jtag RESET pin or per-SoC specific commands for reboot |
| 19:07.29 | arokux_h | hno, sorry for a long break. what is the point of mainlining if there is a little or no chance the code to be accepted upstream? |
| 19:08.16 | RaYmAn | Now you're starting to see why this is a long process. |
| 19:08.28 | RaYmAn | Mainlining == rewriting code to be acceptable |
| 19:11.32 | arokux_h | RaYmAn, no, not only.. for example, wemac driver couldn't be accepted because it is special to A10 |
| 19:12.15 | RaYmAn | I'm sure there are plenty of device-specific drivers in kernel already |
| 19:12.48 | RaYmAn | There's just no chance it would be accepted if a10 support isn't already in kernel. |
| 19:16.35 | penguin42 | lots of them |
| 19:17.22 | penguin42 | it's only a problem if it's obviously a copy of another driver - like if all it took was a slight tweak to another driver then there isn't much point in a whole new driver |
| 19:25.21 | *** join/#arm-netbook gimli_ (~gimli@xbmc/staff/gimli) |
| 19:25.42 | hno | there also need to be someone accepting to be maintainer, which is hars for a device with no documentation |
| 19:26.05 | RaYmAn | Well, we can worry about that when the kernel is in a maintainable state ;) |
| 19:26.16 | RaYmAn | Not exactly something happening next week or next month |
| 19:27.25 | hno | yes |
| 19:28.14 | hno | the main reason is to avoi being dependent on Allwinner for kernel updates imho |
| 19:28.42 | RaYmAn | yeah, definitely |
| 19:42.50 | hno | RaYmAn, SD boot to a program that sets the SD port to JTAG and then loops infinitely. Eject SD and attach JTAG. Set breakpoint @0, and reset PC to ffff4000 |
| 19:43.31 | hno | might work. |
| 19:44.39 | arokux_h | I slowly understand why everybody says that arm is a mess. |
| 19:55.47 | hno | arokux_h, all embedded platforms are a mess, with high diversity and little interest, fast product cycles and little interest in mainlining anything. |
| 19:56.13 | hno | well, fast is relative.. |
| 19:56.35 | arokux_h | I've watched some videos from the last Linaro Connect |
| 19:56.52 | arokux_h | people are trying to organize things... |
| 19:57.49 | RaYmAn | would be interesting if anything came from that |
| 19:58.40 | arokux_h | RaYmAn, one kernel maintainer said they are able to compile a generic kernel for 5 boards (not sure this is the correct term) |
| 20:02.05 | RaYmAn | okay? |
| 20:02.48 | arokux_h | RaYmAn, ? |
| 20:03.28 | RaYmAn | it's just very unspecific :) |
| 20:03.39 | RaYmAn | it could be 5 different boards with same SoC for all I know :P |
| 20:04.13 | arokux_h | RaYmAn, hm.. the correct was to say SoC. |
| 20:04.24 | arokux_h | those were 5 produces |
| 20:04.33 | RaYmAn | okay |
| 20:04.36 | arokux_h | vendors* |
| 20:04.49 | arokux_h | samsung, TI, freescale, ... |
| 20:05.09 | RaYmAn | yeah, those are afaik some of the better vendors wrt mainlining |
| 20:05.25 | arokux_h | RaYmAn, https://www.youtube.com/watch?v=qJ0LL0Ugbx0 |
| 20:05.43 | hno | devicetree enables a lot of flexibility which were not there before. |
| 20:05.50 | RaYmAn | yeah |
| 20:11.36 | arokux_h | RaYmAn, tell me the difference between a board and a SoC, please. Can there be several different boards of one SoC? |
| 20:12.21 | RaYmAn | hm |
| 20:12.36 | RaYmAn | as an example |
| 20:12.39 | RaYmAn | Tegra2 is a SoC |
| 20:13.10 | RaYmAn | there are acer tablets, asus tablets, and a ton more tablets each having different boards but the same SoC |
| 20:13.39 | RaYmAn | a SoC is a system-on-a-chip |
| 20:14.08 | hno | A10 another. |
| 20:14.12 | RaYmAn | indeed |
| 20:14.26 | RaYmAn | And A13 another as well (even if it is quite similar to A10) |
| 20:16.20 | RaYmAn | hno: btw, CWM on my a13 tablet using allwinner-v3.0-android-v2 branch: http://www.youtube.com/watch?v=55zKgWrNuJk&feature=g-upl |
| 20:16.27 | RaYmAn | fel-booted, but still :) |
| 20:17.06 | hno | fel-booted is even more impressive imho |
| 20:17.43 | RaYmAn | :) |
| 20:18.13 | Turl | +1 |
| 20:19.27 | RaYmAn | hno: so uhm, what is plan? adapt the memory setup into sunxi dram.c for SPL usage? Or do we even know that the spl doesn't work? |
| 20:21.57 | hno | SPL needs to have DRAM setup parameterized, currently hardcoded in code. |
| 20:22.06 | RaYmAn | ah |
| 20:22.32 | RaYmAn | so intermediary step is dropping that sun5i dram setup into a dram_sun5i.c, then parameterize it once that works =P |
| 20:23.17 | RaYmAn | I suppose parameterizing it in test1 is a good way to start |
| 20:23.23 | RaYmAn | pretty easy to test it works |
| 20:23.27 | hno | The DRAM controller as such is nearly identical in A10 and A13. |
| 20:23.43 | hno | yes |
| 20:24.17 | hno | The dram setup in test1 is a mix of toms u-boot code and code from kernel mach-sun5i/pm/standby/ |
| 20:24.28 | hno | the standby code is fully parameterized. |
| 20:24.50 | RaYmAn | ah |
| 20:25.57 | hno | diff -uw mach-sun4i/pm/standby/dram_init.c mach-sun5i/pm/standby/dram_init.c |
| 20:26.06 | hno | shows very little differences. |
| 20:26.14 | RaYmAn | I noticed nand driver is 100% identical as well |
| 20:26.22 | hno | it should be. |
| 20:26.37 | *** join/#arm-netbook _whitelogger (~whitelogg@kaunan.whitequark.org) |
| 20:26.42 | hno | I don't think they have touched the NAND controller in a long time. |
| 20:27.01 | RaYmAn | I was considering just removing sun5i driver and setting up hidden compat config's that auto-selects SUNXI_NAND (so current .config's still work) |
| 20:27.13 | hno | For the DRAM controller the most difference is in connection to CCM (clock controller) |
| 20:27.52 | hno | yes, we need to eleminate much of the duplication. |
| 20:28.14 | arokux_h | RaYmAn, so the kernel should be developed per SoC, not per board, right? |
| 20:28.31 | RaYmAn | arokux_h: it's kind of..inbetween |
| 20:28.54 | RaYmAn | obviously SoC support predates board support. With Device tree the per-board stuff has been minimized a hell of a lot |
| 20:29.11 | hno | I would not say it's inbetween. Kernels are developed for SoCs, then mutilated by board vendors. |
| 20:29.16 | RaYmAn | lol |
| 20:29.20 | RaYmAn | well, ideally |
| 20:30.54 | hno | fantastic connection tonight. Been able to view 75% of that linaro video since link was posted here. |
| 20:48.13 | arokux_h | hno, you connection is normally not that good?! |
| 20:49.42 | arokux_h | s/you/your |
| 20:51.01 | hno | 10min youtube in 45 minutes. Almost streaming. |
| 20:52.10 | arokux_h | mm.. haven't got it, sorry |
| 20:52.25 | hno | Connection quality varies a lot here. On the edge of 3G connectivity due to a piece of rock shielding me from the radio mast.. |
| 20:52.44 | arokux_h | you do not have wired connection?! |
| 20:53.35 | hno | not at the family summer house in stockholm archipelago no. |
| 20:53.59 | arokux_h | ah, ok :) |
| 20:54.13 | hno | at home I have some kind of ADSL which delivers 60% of promised quality. |
| 20:57.37 | Turl | hno: 60% of how much? |
| 20:57.55 | Turl | at my parent's house I barely get 1Mbit ADSL :P |
| 21:02.59 | hno | Turl, of what the operator says they can deliver, so I get about 12Mbit. |
| 21:24.30 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 21:27.25 | arokux_h | poor you are guys |
| 21:36.06 | Turl | I currently use a 6Mbit cable connection |
| 21:45.16 | arokux_h | probably naming variables by ?, @ and < was a bad idea... |
| 22:06.50 | Turl | arokux what are you, make? :P |
| 22:09.16 | arokux_h | yes.. |
| 22:09.29 | arokux_h | trying to understand kernel make files |
| 22:16.01 | hno | RaYmAn, The debug unit in Cortex A8 have a "Device Power Down and Reset Control Register" which controls the A8 core. |
| 22:16.16 | *** join/#arm-netbook revident (~scott@76-10-173-74.dsl.teksavvy.com) |
| 22:23.44 | Turl | arokux_h: $@ is the 'left' part, before the :, $< is the right part, after the : |
| 22:23.49 | Turl | arokux_h: see https://github.com/allwinner-dev-team/atag-tools/blob/master/Makefile#L12 |
| 22:23.56 | RaYmAn | hno, interesting. got a link? |
| 22:24.18 | arokux_h | Turl, I've read make documentation, thanks! |
| 22:24.27 | arokux_h | http://www.gnu.org/software/make/manual/make.html#Automatic-Variables |
| 22:25.05 | Turl | :) |
| 22:25.17 | arokux_h | trying to understand how #include <mach/....h> magic is done generically |
| 22:28.06 | Turl | it's probably this ultra weird looking code :P https://github.com/amery/linux-allwinner/blob/lichee-3.0.8-sun4i/arch/arm/Makefile#L235 |
| 22:29.19 | arokux_h | yes :) |
| 22:29.23 | arokux_h | you were quick |
| 22:29.48 | arokux_h | I was also decyfering it right now |
| 22:30.01 | arokux_h | deciphering* |
| 22:39.30 | arokux_h | what kind of UART controller is embedded into A10, is this something standard? |
| 22:41.46 | RaYmAn | 16650, seems more or less identical to tegra. at least in low speed modes |
| 22:42.03 | RaYmAn | so yeah, i guess it is standard |
| 22:42.27 | RaYmAn | just the base register address differing |
| 22:43.19 | arokux_h | in the mach/platform.h there is UART0 and UART1, but physically there is only one on the device |
| 22:43.28 | arokux_h | at least in mele |
| 22:43.42 | RaYmAn | there are more in soc |
| 22:43.58 | RaYmAn | at least 4 i believe |
| 22:47.48 | hno | RaYmAn, The A8 reference manual is on arm.com. Requres a registered login to access so they can track that you agree to their license (anti-patent-war clause) |
| 22:49.08 | arokux_h | hno, have you registered there? |
| 22:49.15 | RaYmAn | yeah. ill look into it tomorrow |
| 22:50.26 | hno | arokux_h, yes. A little hard to hack on ARM without their manuals. |
| 22:50.36 | arokux_h | :) |
| 22:51.46 | hno | and the license they use for these is not harmful to me. |
| 23:01.12 | arokux_h | hm, I've found some info on uarts: http://www.lammertbies.nl/comm/info/serial-uart.html. According to the table (a bit lower on the page) SW_UART0_LSR should be + 5, and not +20 (0x14) as in platform.h... |
| 23:09.00 | arokux_h | and what the _USR means? :( |
| 23:14.52 | arokux_h | RaYmAn, why have you said it's similar to tegras one? |
| 23:37.01 | arokux_h | anybody still not sleeping? :) |
| 23:38.37 | Turl | it's "early" in here |
| 23:38.41 | Turl | 20:38 :) |
| 23:39.36 | arokux_h | ah, ok |
| 23:39.46 | arokux_h | do you know smth about UART? :) |
| 23:40.04 | arokux_h | because it somehow strange |
| 23:41.05 | Turl | arokux_h: I know how to wire it on my mele and use it on my PC |
| 23:41.12 | Turl | and text magically shows and I can use a shell :P |
| 23:41.20 | Turl | that's all I know fwiw |
| 23:41.43 | arokux_h | ok |
| 23:41.44 | arokux_h | ) |