00:01.45 | *** join/#arm-netbook lerc (~quassel@121-74-228-186.telstraclear.net) |
00:25.38 | *** join/#arm-netbook lerc (~quassel@121-74-228-186.telstraclear.net) |
00:30.20 | Gumboot | What the world clearly needs is a CPU on a board with a wee bit of flash and half a dozen properly-powered USB ports. No display. No audio. No GPIO. Just attach what you need via USB at extra cost. |
00:31.06 | xenoxaos | until you run out of bandwidth |
00:31.23 | Gumboot | Attach more bandwidth! |
00:32.22 | xenoxaos | with duct tape and hot glue |
00:32.24 | Gumboot | Actually, you probably could. You could daisy-chain them so that you get more CPUs with more bandwidth communicating back just the essentials. |
00:32.27 | *** join/#arm-netbook lerc_ (~quassel@121-74-241-215.telstraclear.net) |
00:32.46 | xenoxaos | the programming logistics on that would be hell |
00:32.55 | Gumboot | It's for education! |
00:33.17 | xenoxaos | But I don't want to go to sodomy school. |
00:34.05 | Gumboot | You could even connect them in a ring. |
00:34.25 | Gumboot | I would like to disassociate that last comment from the sodomy reference, if possible. |
00:34.41 | xenoxaos | nope |
00:35.20 | Gumboot | Fine. I think there's a word for it, but I'm not going to google it. |
00:36.21 | xenoxaos | !g ring of sodomy |
00:36.38 | xenoxaos | oh...there's a picture.... |
00:42.22 | *** join/#arm-netbook mnemoc (~amery@geeks.cl) |
00:46.40 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
01:06.14 | *** join/#arm-netbook stefanro1 (~stefan@p57B9468A.dip.t-dialin.net) |
01:22.53 | hno | will likely to token ring/bus networking in the near future. Thought that was dead. |
01:24.50 | *** join/#arm-netbook focus_well (~focus@host81-149-149-147.in-addr.btopenworld.com) |
01:30.44 | *** join/#arm-netbook tinti (~tinti@bhe201062162119.res-com.wayinternet.com.br) |
01:34.39 | Marex | hno: token ring is splendid ... one ring to rule them all (tm) ;-) |
01:34.46 | Marex | btw. mail.google.com is down? nice ;-) |
01:36.03 | Marex | not anymore ... weird |
01:56.25 | *** join/#arm-netbook freakazoid0223 (~matt@pool-173-75-233-172.phlapa.fios.verizon.net) |
01:57.01 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@212.179.75.202) |
02:18.30 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
02:19.47 | *** join/#arm-netbook marcan (marcan@marcansoft.com) |
02:22.10 | *** join/#arm-netbook grevaillot (~moot@z.f00.be) |
02:23.40 | *** join/#arm-netbook markatto (~markatto@marktmerritt.com) |
02:25.41 | Mehhh | Does anyone here have a lapdock? |
02:34.00 | *** join/#arm-netbook mSquare (~selvan@122.167.98.10) |
02:44.37 | xxiao | how can I avoid the fxxx windows all together |
02:45.04 | xxiao | can't recall how to get its env variable, echo $VAR1? |
02:51.35 | xxiao | uses windows 10 hours per year |
03:25.01 | Marex | xxiao: to do taxes ? ;-) |
03:25.15 | Marex | wasnt it %VAR ? |
03:42.01 | xxiao | Marex: that's right |
03:42.45 | xxiao | it's something like %VAR%? anyway i managed to get it working, JAVA_HOME and PATH both need to be set manually |
03:56.54 | HACKhalo2 | heh |
04:07.26 | *** join/#arm-netbook Quarx (~Quarx@94.137.1.42) |
04:11.02 | *** join/#arm-netbook jquip (~johnny@27.58.128.184) |
04:58.10 | *** join/#arm-netbook Mazon (~Mazon@0138500130.0.fullrate.dk) |
05:11.44 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.103) |
05:28.16 | *** join/#arm-netbook antonl (~anton@213.33.220.118) |
05:31.22 | *** join/#arm-netbook wim (~wim@42.be) |
05:34.12 | *** join/#arm-netbook hipboi (~tom@static.88-198-149-134.clients.your-server.de) |
05:35.24 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
05:53.36 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
05:56.35 | *** join/#arm-netbook rz2k (~rz2k@37-144-46-232.broadband.corbina.ru) |
05:57.50 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
06:31.41 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
06:48.03 | *** join/#arm-netbook rellla (~rellla@p5B0784C1.dip0.t-ipconnect.de) |
07:01.15 | hno | xxiao, boot Linux in a full screen VM and forget there is a Windows bootloader. |
07:23.19 | *** join/#arm-netbook lerc (~quassel@121.75.153.100) |
07:24.24 | hno | Updated mainlining wiki page with a little more realistic order. |
07:25.33 | libv | let me add to the mali bit. |
07:32.07 | libv | hno: so the nand situation really is that bad huh? |
07:33.08 | *** join/#arm-netbook rellla2 (~rellla@p5B0784C1.dip0.t-ipconnect.de) |
07:37.28 | *** join/#arm-netbook rellla (~rellla@p5B0783DE.dip0.t-ipconnect.de) |
07:37.44 | *** join/#arm-netbook cat_x301 (~cat@gprs-internet-ffbeee00-223.dhcp.inet.fi) |
07:39.36 | Turl | libv: ping |
07:40.52 | libv | pong |
07:43.43 | Turl | libv: any idea what might be causing this error? http://pastie.org/5441726 |
07:43.53 | Turl | esp. the EGL-ERROR |
07:44.20 | Turl | libv: we're hitting that on android 4.2 |
07:44.26 | Turl | libv: it's interesting because the only affected platform is Mali GPU |
07:45.00 | Turl | PowerVR, Adreno work without issues |
07:45.52 | libv | why 720x1280? |
07:45.59 | libv | what device are you using? |
07:46.05 | libv | while being rotated |
07:46.33 | libv | printf your way out of this one, check where that calloc return -ENOMEM is |
07:47.27 | Turl | that log is not from an A10 but from some samsung device |
07:47.38 | Turl | I don't have my A10 log handy but it's the same problem |
07:49.16 | libv | still, printf your way out of it |
07:49.58 | libv | this smells like allocating an intermediate buffer failing |
07:51.49 | Turl | libv: this is the code that prints that btw https://github.com/CyanogenMod/android_frameworks_native/blob/jellybean/libs/ui/GraphicBufferAllocator.cpp |
07:54.08 | Turl | err, sorry, https://github.com/CyanogenMod/android_frameworks_native/blob/mr1-staging/libs/ui/GraphicBufferAllocator.cpp |
07:55.06 | libv | mAllocDev->alloc(mAllocDev, w, h, format, usage, handle, stride); |
07:55.18 | libv | that's probably from the libhw gralloc module |
07:55.37 | Turl | yeah that's the gralloc module |
07:55.52 | Turl | which is unchanged from android 4.1 |
07:55.57 | libv | where is the code for that? |
07:56.02 | libv | for mali |
07:56.09 | Turl | malideveloper |
07:56.31 | libv | ok |
07:56.36 | Turl | libv: https://github.com/allwinner-dev-team/android_device_allwinner_common/tree/master/gralloc too |
07:56.50 | Turl | it's mostly the same source |
07:56.50 | libv | so the currently public mali gralloc code is broken for jelly bean |
07:57.24 | Turl | 4.2 jellybean |
07:57.30 | Turl | it works fine on 4.1 jellybean |
07:57.47 | Turl | all other vendors have no issues on either version with the same graphic stack |
07:58.53 | libv | ? |
07:59.04 | libv | your last statement makes no sense to me |
07:59.35 | libv | do you mean that pvr/adreno/etc are ok with the changes to surface flinger and gralloc for jelly bean? |
08:00.22 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
08:00.51 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
08:01.11 | Turl | libv: http://paste.debian.net/hidden/e299bc47/ |
08:01.18 | Turl | hope the ascii table cleans up any confusion |
08:01.47 | Turl | gralloc didn't change 4.1 JB -> 4.2 JB |
08:02.56 | libv | different drivers == different graphics stacks imho |
08:03.10 | libv | but that's probably my pov |
08:03.29 | libv | it could be that you ran out of buffers. |
08:04.14 | Turl | the same libMali, libEGL*Mali*, libUMP, gralloc* were used on both android versions |
08:04.34 | Turl | same applies to pvr & adreno, using their corresponding libs, daemons and stuffs |
08:04.40 | libv | yes, i would think that you just ran out of buffers |
08:05.35 | libv | sprinkle some LOGE's in gralloc_alloc_framebuffer_locked in https://github.com/allwinner-dev-team/android_device_allwinner_common/blob/master/gralloc/alloc_device.cpp |
08:05.58 | libv | you have a -ENOMEM there |
08:06.37 | libv | init_frame_buffer_locked is unlikely to return -ENOMEM |
08:08.39 | Turl | buffermask is an uint32, so we have 32 buffers I'm guessing? |
08:08.57 | libv | 1 << (1 << 32) is a rather big number |
08:09.48 | Turl | m->bufferMask |= (1LU<<i); |
08:10.02 | libv | ah, yes, you are right |
08:10.37 | libv | so yes, only up to 32 framebuffers available apparently |
08:10.57 | libv | again though, LOGE your way out of it, make sure that this codepath is actually hit |
08:11.06 | libv | and where it is actually throwing back -ENOMEM |
08:14.32 | Turl | E/ ( 6888): void __egl_platform_dequeue_buffer(egl_surface*):1188 [EGL-ERROR] failed to dequeue buffer from native window (0x40421990); err = -12, buf = 0x40819ff0 |
08:14.32 | Turl | E/gralloc ( 6888): ENOMEM OVER HERE static int gralloc_alloc_framebuffer_locked |
08:14.33 | Turl | W/GraphicBufferAllocator( 6888): alloc(1024, 768, 5, 00001e02, ...) failed -12 (Out of memory) |
08:14.34 | Turl | yup |
08:17.38 | Turl | wohoo it works libv :D |
08:17.48 | Turl | I killed the buffer limit checker |
08:17.48 | libv | well, check what numBuffers and bufferMask are doing |
08:17.57 | libv | erm, you do want to fix things properly |
08:18.03 | Turl | yeah I know |
08:18.07 | Turl | was just a PoC :) |
08:20.42 | Turl | libv: numBuffers is 2 |
08:21.14 | libv | something has changed |
08:21.22 | libv | in surfaceflinger or gralloc |
08:22.31 | libv | but do review the life of numBuffers and bufferMask |
08:22.40 | libv | through logging |
08:22.50 | Turl | other platforms have supported triple buffering for a while I think |
08:23.37 | libv | well, it could be a bug in the handling of numBuffers/bufferMask between allocs and frees |
08:23.44 | libv | or it could be an actual shortage of memory |
08:23.51 | libv | memory assigned to the mali |
08:24.07 | hno | libv, the Allwinner logical nand driver is not submittable without anyone understanding the logical layer and stepping up to document it and accept being a maintainer. |
08:24.12 | Turl | hardcoding numBuffers to 3 on gralloc seems to work |
08:24.23 | hno | libv, but we will likely have a well functioning MTD driver. |
08:24.25 | Turl | I need to check where does numBuffers come from |
08:25.05 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
08:25.37 | libv | #define NUM_BUFFERS 2 |
08:25.46 | libv | framebuffer_device.cpp |
08:26.42 | libv | but the fb driver might not give back more |
08:26.46 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.104) |
08:27.38 | Turl | <PROTECTED> |
08:27.41 | libv | so find out why we need a third |
08:28.21 | libv | but we only requested 2 |
08:29.45 | Turl | http://sprunge.us/LQHI I think this is it |
08:30.35 | libv | smells like it |
08:30.50 | libv | first bump the define up to 3 |
08:31.00 | libv | i do not know how fb responds to that though |
08:31.07 | libv | might be driver dependant |
08:31.28 | libv | if both the samsung and your allwinner return that, then you might get away with it |
08:32.01 | libv | the change to services/surfaceflinger/Layer.cpp is rather scary |
08:32.31 | Turl | if they made a makefile define switch to change it it must be not that scary |
08:33.00 | libv | you would expect the hw framebuffer module to feed that back |
08:33.18 | libv | and not be hardcoded somewhere up top |
08:34.03 | libv | it's clearly dynamic for surfaceflinger, but these defines make it semi-hardcoded |
08:34.09 | libv | and the hw has no say in it |
08:35.32 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
08:35.32 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
08:36.06 | Turl | they also have a NUM_FRAMEBUFFER_SURFACE_BUFFERS |
08:38.21 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
08:50.20 | *** join/#arm-netbook svp (~svp@62.112.106.78) |
08:52.41 | *** join/#arm-netbook ssspiff (~quassel@unaffiliated/yukito) |
08:56.25 | *** join/#arm-netbook vgrade_ (50e71d67@gateway/web/freenode/ip.80.231.29.103) |
09:21.00 | *** join/#arm-netbook Mazon (~Mazon@0138500130.0.fullrate.dk) |
09:23.39 | *** join/#arm-netbook tinti (~tinti@189.3.225.5) |
09:33.33 | Gumboot | It really is tempting to set up an rpi hate site and fill it full of adverts and a couple of unkind remarks. Can you make money on adverts just being displayed, or do they have to be clicked? |
09:34.24 | mnemoc | at least google ads pays for both, obviusly differently |
09:34.45 | Gumboot | Maybe I really should, then. I wonder how much I can make. |
09:35.02 | Gumboot | And if I did, what should I do with the money? |
09:35.27 | mnemoc | buy rpis |
09:35.28 | *** join/#arm-netbook jquip (~johnny@223.230.9.32) |
09:35.43 | Gumboot | If the DSP toolchain makes any progress I'd be tempted. |
09:35.57 | Gumboot | It's only the ARM which is completely useless. |
09:39.49 | Gumboot | Without bothering to read the actual changes, the commit messages seem promising: https://github.com/mm120/binutils-vc4/commits/vc4 |
09:42.31 | RaYmAn | useful commit messages there ;) |
09:44.13 | libv | yeah :( |
09:44.24 | Gumboot | Nevermind the commit messages.... does it work? |
09:45.44 | Gumboot | I probably shouldn't look. It'll drive me mental knowing that they've got little mistakes here and there which I can't correct. |
09:47.11 | Gumboot | Does the bootloader include the GPU driver, or is that uploaded at a later stage? |
09:47.11 | mnemoc | i've seen commit messages about needing to go for coffee or to the grocery store :| |
09:48.42 | libv | Gumboot: the 2mb blob which is later contains that i guess |
09:48.48 | libv | loaded later even |
09:51.33 | Gumboot | Well that's only the same size as the startup elf file. |
09:54.45 | Gumboot | I hope these binutils use the same elf metadata as is already used in the existing elfs. It would be easy to just start from scratch and forget about compatibility. |
10:04.30 | *** join/#arm-netbook focus_well (~focus@host81-149-149-147.in-addr.btopenworld.com) |
10:09.41 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
10:13.20 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
10:50.27 | *** join/#arm-netbook arete74 (~arete74@2-226-90-244.ip180.fastwebnet.it) |
10:54.24 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@local.xorcom.com) |
11:23.06 | *** join/#arm-netbook jquip (~johnny@223.180.5.168) |
11:51.20 | *** join/#arm-netbook RITRedbeard_ (~redbeard@68.37.165.37) |
11:51.29 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
11:57.58 | *** part/#arm-netbook hipboi (~tom@static.88-198-149-134.clients.your-server.de) |
12:04.40 | *** join/#arm-netbook itamar_ (~itamar@cl-24.udi-01.br.sixxs.net) |
12:49.15 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
12:49.30 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
12:52.16 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
12:52.22 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
12:53.22 | *** join/#arm-netbook Gumboot (~sh1@rev.bovine.muck.net.nz) |
13:12.18 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
13:20.57 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
13:26.21 | *** join/#arm-netbook vinifm (~vinix@177.158.127.191) |
13:42.58 | *** join/#arm-netbook cat_x301 (~cat@gprs-internet-ffb2ee00-196.dhcp.inet.fi) |
14:24.18 | slapin | do anybody knows how I can link custom section to .rodata without using linker script? this is userspace program, so I don't want to mess with linker scripts for it |
14:35.14 | *** join/#arm-netbook Jef91 (~Instantbi@bodhilinux/team/Jef91) |
14:40.28 | *** join/#arm-netbook hg_5_ (~chatzilla@91.234.245.245) |
14:43.06 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
14:47.32 | *** join/#arm-netbook Gumboot (~sh1@rev.bovine.muck.net.nz) |
14:48.55 | oliv3r | if i have a 4 Byte variable, and i do 3 << 30; that can't be right, correct? |
14:50.38 | mnemoc | it's fine |
14:50.48 | oliv3r | won't it overflow? |
14:50.54 | oliv3r | oh wait, no |
14:50.56 | oliv3r | i'm stupid |
14:50.58 | mnemoc | 3 is 0b11 |
14:51.10 | oliv3r | yeah |
14:51.11 | oliv3r | i'm stupid :) |
14:51.15 | mnemoc | yes :) |
14:51.44 | oliv3r | ... thanks :p |
14:51.54 | oliv3r | i was thinking of 3 being 0b111 |
14:52.18 | oliv3r | i had that still in my calculator, from an earlier 7 << 0 |
14:52.19 | oliv3r | :p |
14:54.03 | mnemoc | anyhow, unsigneds don't overflow in C |
14:54.45 | mnemoc | 7<<30 == 3<<30 |
14:55.10 | oliv3r | what about chip registers :p |
14:57.22 | mnemoc | should be the same |
14:57.53 | oliv3r | still, it COULD cause bugs! |
14:58.13 | oliv3r | crashes, fires, skynet's self awareness! |
14:58.22 | mnemoc | take the ref guide and see the shift instruction you are using |
14:58.44 | mnemoc | the excess could be sent to another register |
14:58.53 | mnemoc | but i'm not an asm guy |
14:59.25 | oliv3r | oh, nah, i just thought i found a bug in a header file :p |
14:59.32 | mnemoc | nope :) |
14:59.33 | oliv3r | i'm wikiing things :p |
14:59.41 | mnemoc | which controller? |
14:59.43 | oliv3r | yeah, cause I was being stupid |
14:59.48 | oliv3r | sec, i'll save my intermediate work |
15:02.08 | oliv3r | htt://linux-sunxi.org/A10/NFC |
15:04.41 | mnemoc | afaik the NFC is identical in all sunxi socs |
15:05.04 | oliv3r | then we need a better naming convention, since we started with A10/registers |
15:05.07 | oliv3r | i just went from there! |
15:05.28 | mnemoc | that's fine, but I believe A10/NFC should redirect to just NFC |
15:05.46 | mnemoc | but it can be moved later |
15:06.31 | oliv3r | yep |
15:06.51 | oliv3r | I think a lof of devices and controllers are identical |
15:07.06 | mnemoc | do you want to learn SVG? :) |
15:07.16 | mnemoc | tables to describe registers suck badly :< |
15:07.21 | oliv3r | er, not really :( why |
15:07.30 | oliv3r | ok, NOW you say this? |
15:07.46 | oliv3r | you have any clue how much time i've spent writing register tables? |
15:07.54 | mnemoc | a lot |
15:07.58 | mnemoc | :) |
15:07.58 | oliv3r | :p |
15:08.02 | oliv3r | what did you have in mind? |
15:08.50 | mnemoc | an image :) |
15:09.07 | oliv3r | obviously :p how much would it be different though? |
15:09.11 | oliv3r | I know a table isn't ideal |
15:09.19 | oliv3r | I wonder how an image would be more usefull |
15:09.28 | mnemoc | adds visual meaning to the bit ranges |
15:09.48 | oliv3r | do you have an example of such an image? |
15:10.20 | oliv3r | 'interactive' memory map would be way cooler :p |
15:11.38 | mnemoc | http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0304c/Chdifhjd.html |
15:13.52 | mnemoc | slapin's .tex document about the NFC has such diagrams |
15:14.42 | mnemoc | http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0331c/BABEFEJE.html |
15:15.58 | *** join/#arm-netbook mikey_w (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
15:17.59 | oliv3r | slapin has a document? where is that at? |
15:18.03 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
15:18.20 | oliv3r | speaking of slaping and hno it would be awesome if they could fill in their knowlege into http:/linux-sunxi.org/A10/NFC |
15:18.33 | oliv3r | i'm done for today :) and put in the registers/bits I could find so far |
15:19.05 | mnemoc | learning svg would let use make a wiki template to generate the diagrams |
15:20.46 | oliv3r | you do realize I wanna strangle you right now |
15:20.54 | oliv3r | I talked about templates when I started doing this |
15:20.57 | oliv3r | you where opposed! |
15:21.05 | oliv3r | so i went with a table, as you thought that was best |
15:21.27 | oliv3r | I guess there could be an easy way to 'transform' the code from wiki to svg |
15:21.35 | oliv3r | i tried to be consistent with the tables :) |
15:21.46 | mnemoc | oliv3r: i opposed full page templates, not diagram templates or infoboxes :) |
15:22.21 | mnemoc | the tables are good.... they just miss a diagram on top :) |
15:22.33 | oliv3r | those grahpics do look nice |
15:22.56 | oliv3r | if the tables where a template, like i suggested! we could have generated the diagrams from that |
15:23.31 | mnemoc | +1 to per-register template :) |
15:23.39 | mnemoc | not per-controller |
15:23.42 | oliv3r | yeah yeah yeah, you say all this now! |
15:23.48 | mnemoc | *g* |
15:23.49 | oliv3r | i ment per register template! |
15:23.58 | oliv3r | back then |
15:24.02 | mnemoc | i understood full-page templates :< |
15:24.18 | oliv3r | miss communication fail! |
15:24.23 | oliv3r | well |
15:24.32 | oliv3r | how many days would it take to get it from a table to a template |
15:24.42 | oliv3r | I guess it can be automated with some bash/perl magic |
15:24.50 | oliv3r | but that's beyond my skills! |
15:24.53 | oliv3r | or desires :p |
15:24.58 | bfree | you mean the images like http://infocenter.arm.com/help/topic/com.arm.doc.ddi0304c/graphics/iecdpccr_register_bit_assignments.png ? |
15:25.04 | oliv3r | I can try to do it for the next controller |
15:25.21 | oliv3r | yes |
15:25.27 | oliv3r | bfree: exactly that |
15:25.59 | oliv3r | mnemoc: in either case, we'd need a good template for the registers to begin with |
15:27.49 | mnemoc | hopefully a bit larger so the text can be read :p |
15:28.36 | mnemoc | oliv3r: yes, next controller, always forward |
15:28.52 | oliv3r | well the older stuff will have to be adapted at some point |
15:28.56 | bfree | that could be doable on the fly in javascript from the html tables in the wiki output ;) but if you have a lot of bits in there where is all the text going to go and is it really going to be much of an improvement? |
15:29.04 | oliv3r | if you can whip up a template + example, i'll use it on the next controller :) |
15:29.19 | oliv3r | you'd only have bit + name |
15:30.04 | oliv3r | or even just bitnumber, as you can look up the bit number in the table (from template) below |
15:30.20 | slapin | oliv3r: http://ossfans.org/nand_registers.ps is postscript version |
15:30.35 | oliv3r | i'll hope to find that page tomorrow :p |
15:30.45 | oliv3r | i'll try to work in your findings into the draft wiki page |
15:30.49 | oliv3r | but gotta go home now :) |
15:30.50 | slapin | wants to put that somewhere on public with source, where it can be edited |
15:30.51 | oliv3r | bb :) |
15:31.03 | oliv3r | slapin: well i just put up http://linux-sunxi.org/A10/NFC |
15:31.17 | oliv3r | try to look at that and see :D |
15:31.22 | oliv3r | *poof* |
15:31.22 | slapin | oliv3r: no nice pictures there |
15:31.27 | oliv3r | :p |
15:31.34 | oliv3r | i'll put some boobies pics up :p |
15:31.42 | slapin | oliv3r: ok |
15:31.54 | slapin | oliv3r: I will check then |
15:32.21 | slapin | there is no such thing as too many boobs |
15:32.35 | mnemoc | mripard: hi, did you already start with the pinctrl stuff? |
15:34.41 | mripard | mnemoc: yep, a bit |
15:36.27 | mnemoc | mripard: i pushed some stuff to https://github.com/amery/linux-allwinner/commits/wip/sunxi-next/pinctrl ... but still kind of lost |
15:37.56 | mnemoc | there is a wip/sunxi-next/i2c there too, but cleanup only, no porting yet |
15:38.14 | mripard | yes, I'm having a hard time too to get how to map those completely random pins supported in A10, A10s and A13, and how to map them usefuly to pinctrl |
15:40.23 | mripard | ah |
15:41.09 | mripard | the Pio IPs are different from A10 to A13 ? |
15:41.40 | mnemoc | no, they are the same |
15:41.51 | mnemoc | i have separated .c for the statics |
15:42.16 | mnemoc | because groups and features difer between socs... obviusly |
15:42.45 | mripard | but what about the aw1626 and aw1623 |
15:42.48 | mripard | ? |
15:43.00 | mnemoc | aw1623 is the so called A10 |
15:43.06 | mnemoc | aw1626 is A13 |
15:43.09 | mripard | aaah, I see |
15:43.22 | mnemoc | "chip-id" vs. marketing name |
15:43.53 | mnemoc | the chip-id lives inside the header of the BROM |
15:44.46 | mnemoc | I was doing it detection based in 3.4... until I realized modern arm-linux hates detection, and everything needs to be hardcoded in the .dts |
15:45.35 | xxiao | hopefully u-boot etc will be able to generate dts automatically |
15:46.11 | mnemoc | eventually we will be able to turn an script.bin into dts |
15:46.20 | xxiao | actually for usb, pci or most probe-able bus it's still detected dynamically |
15:46.22 | mnemoc | but we need to model it manually first :p |
15:46.51 | xxiao | dts just assign interrupts and some basic resources for those buses |
15:47.17 | xxiao | but for misc bus/interfaces you have to hand-code them |
15:47.24 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
15:47.32 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
16:11.48 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
16:12.34 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
16:13.13 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
16:22.43 | slapin | hno: ping |
16:23.10 | slapin | hno: hi! |
16:23.47 | *** join/#arm-netbook Workboot (~gumboot@rev.bovine.muck.net.nz) |
16:36.02 | L84Supper | who was looking for the PCB breakout for the a10 bga? |
16:41.53 | L84Supper | http://imagebin.org/237442 |
16:42.03 | L84Supper | http://imagebin.org/237441 |
16:42.12 | L84Supper | http://imagebin.org/237440 |
16:42.22 | L84Supper | http://imagebin.org/237439 |
16:42.33 | L84Supper | http://imagebin.org/237438 |
16:43.12 | mnemoc | those are from the hackberry, right? can you upload them to the wiki? |
16:43.26 | L84Supper | no |
16:43.38 | L84Supper | from some other board |
16:44.51 | L84Supper | I don't post to that old wiki anymore |
16:46.05 | mnemoc | http://linux-sunxi.org ? |
16:46.16 | L84Supper | then again if you really need help with the BGA breakout I highly doubt you'll be able to design a board that works well |
16:46.41 | focus_well | L84Supper: yum yum! that be me looking for those bga tracks!!! |
16:46.52 | mnemoc | i have zero intention in designing a board, ever |
16:47.27 | mnemoc | just want to be sure no sunxi related knowledge gets lost |
16:50.32 | focus_well | L84Supper: a couple of questions |
16:51.05 | focus_well | 1. The inner BGA pads and some of the other bga pads have thick tracks. |
16:51.05 | focus_well | <PROTECTED> |
16:51.05 | focus_well | <PROTECTED> |
16:51.05 | focus_well | 2. What is the bga pad size? |
16:51.05 | focus_well | 3. What is the min track width used in the design between the bga pads? |
16:51.06 | focus_well | 4. What is the hole size for vias used in the design between bga rows of |
16:51.08 | focus_well | pads? |
16:51.10 | focus_well | 5. What is the overall via size used in the design for vias between the |
16:51.12 | focus_well | bga rows of pads? |
16:51.14 | focus_well | From some other conversation I remember |
16:51.16 | focus_well | the tracks the engineers used were 5 mils with 5 mil clearance. |
16:51.18 | focus_well | The vias are 16 mils. |
16:51.20 | focus_well | The drills were around 5 or 6 mils. |
16:51.22 | focus_well | The companies I know makes PCB with these limits |
16:51.26 | focus_well | min track width 0.075mm |
16:51.28 | focus_well | min hole size 0.15mm. |
16:52.42 | L84Supper | I'd suggest that you spend a few more years learning high speed PCB design |
16:52.59 | L84Supper | there is no way around it |
16:53.26 | L84Supper | or you end up with the usual junk |
16:53.26 | focus_well | L84Supper: I design lots of PCBs these days |
16:53.37 | focus_well | All working :) |
16:54.04 | L84Supper | then you should be able to answer this yourself :) |
16:54.04 | focus_well | The info request is specific to the A10 bga |
16:54.37 | focus_well | L84Supper: those diagrams were very good - thanks! |
16:54.44 | slapin | looks at working board, and smiles, very, very evilly, and puts it into junk bin for parts |
16:56.44 | slapin | wants to learn BGA PCB design a cheap way - any pointers? |
16:56.53 | focus_well | L84Supper: I have info here and there, but rather I use 100% certain data. But I have allow 2-3 redesigns to get it right - so I'm not in a hurry to get it right first time. |
16:57.42 | L84Supper | those pics are from a magic board, that just happens to work due to good luck |
16:57.43 | focus_well | The board i want is ideally torture tested and still working |
16:58.44 | drachensun | my last bga design had to be 4 mil clearance, there was no way to route it at 5 mils, the pads had something close to 12 mils between them, so 4 on each side and 4 for the track and that was it |
16:59.06 | drachensun | there are places that can do tighter design clearances, you just have to find them |
16:59.27 | focus_well | dranchensun: keep talking I pick up conversation in a few hours.. bye |
17:00.22 | drachensun | heh I think that was all I had to say about it. I ran into the same thing, I wanted to keep it at 5 mil because I can get cheap prototypes at that size |
17:00.59 | drachensun | but it just wasn't possible and that was an Atmel with a lot fewer pins than an A10 |
17:02.16 | slapin | drachensun: any pointers on cheap BGA prototypes (6-8 layers)> |
17:02.20 | *** join/#arm-netbook cat_x301 (~cat@gprs-internet-fffcee00-155.dhcp.inet.fi) |
17:02.23 | slapin | ? |
17:08.06 | L84Supper | sometimes you can use 5/5mil for most of the board and only go down to 4/4 or even 3 just between BGA pads |
17:09.26 | *** join/#arm-netbook RITRedbeard_ (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
17:09.32 | *** join/#arm-netbook ZaEarl (~malmrose@c-24-6-238-36.hsd1.ca.comcast.net) |
17:10.57 | *** join/#arm-netbook Jef91 (~Instantbi@bodhilinux/team/Jef91) |
17:12.52 | *** join/#arm-netbook Jef91 (~Instantbi@bodhilinux/team/Jef91) |
17:14.31 | jquip | is the cdc-acm driver a part of the kernel defconfig?? |
17:41.20 | drachensun | slapin: not really, we found one place with good pricing for tight tolerances but I think they are gone now |
17:56.33 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
17:59.30 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.99) |
18:17.54 | *** join/#arm-netbook DEAT_ (~heh@14-201-99-152.tpgi.com.au) |
18:18.58 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
18:30.57 | *** join/#arm-netbook RITRedbeard_ (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
18:38.39 | slapin | which safe resistor nominals should be for 3.3 SPI pull-ups? |
18:58.11 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
18:58.21 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
18:58.55 | *** join/#arm-netbook Mehhh (adabd66c@gateway/web/freenode/ip.173.171.214.108) |
19:01.34 | *** join/#arm-netbook HACKhalo2 (~hackhalo2@c-68-43-56-10.hsd1.mi.comcast.net) |
19:03.07 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
19:03.28 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
19:08.45 | *** join/#arm-netbook HACKhalo2 (~hackhalo2@c-68-43-56-10.hsd1.mi.comcast.net) |
19:08.54 | *** join/#arm-netbook RITRedbeard_ (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
19:34.15 | techn | drachensun: how did you enabled ft5x_ts on linaro? |
19:34.41 | techn | ts works but x.org log says that: |
19:35.15 | techn | [ 1366.144] (II) No input driver specified, ignoring this device. |
19:35.15 | techn | [ 1366.144] (II) This device may have been added with another device file. |
19:35.30 | techn | and I apt-get'd utouch |
19:36.29 | techn | on other tabled (with gt811) everything worked without hasle.. even without utouch |
19:39.41 | drachensun | let me check my Xorg log |
19:40.00 | *** join/#arm-netbook slapin_nb (~slapin@host-233-146-66-217.spbmts.ru) |
19:41.13 | drachensun | My Xorg log says that too |
19:41.15 | drachensun | but it works |
19:42.26 | drachensun | well let me check another system real quick |
19:42.45 | drachensun | I've got a bunch of these running under different rootfs |
19:46.20 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
19:49.34 | mnemoc | maybe ranting about a different input device? |
19:51.44 | drachensun | ok, I got a little mixed up, on my system with the mali drivers and my screwed up xorg conf from trying to get xrandr to rotate the screen, I have the same message and currently the touch doesn't work |
19:51.56 | drachensun | on my other system it works |
19:52.25 | drachensun | and the Xorg.0.log looks like you would expect "using input driver 'evdev' for 'ft5x_ts' |
19:53.49 | techn | drachensun: thanks.. now to track why that doesn't happen :p |
19:54.12 | drachensun | give me a sec and I'll post what logs and conf files I can from the working system |
19:56.13 | drachensun | Ok, the only difference in the conf files seems to be that 99-mali400.conf from the mali driver and my additions to it |
20:02.39 | drachensun | there is my xorg.0.log file http://pastebin.com/euu7MUMy |
20:03.16 | drachensun | and the xorg.conf files are just the stock linaro ones in this case |
20:03.54 | *** join/#arm-netbook drachenphone (~AndChat39@142.196.83.182) |
20:04.28 | techn | ft5x_ts: Applying InputClass "evdev touchscreen catchall", thats seems to be first missing print |
20:06.49 | drachensun | thats coming from /usr/share/X11/xorg.conf.d/10-evdev.conf |
20:07.13 | drachensun | off for a bit |
20:27.58 | *** join/#arm-netbook slapin_nb (~slapin@host-233-146-66-217.spbmts.ru) |
20:40.38 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
20:41.31 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
20:50.59 | *** join/#arm-netbook focus_it (~focus_it@cpc7-dals17-2-0-cust182.hari.cable.virginmedia.com) |
20:54.17 | *** join/#arm-netbook RITRedbeard_ (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
20:56.31 | *** join/#arm-netbook Sv (~Sv@modemcable190.180-203-24.mc.videotron.ca) |
20:56.31 | *** join/#arm-netbook Sv (~Sv@unaffiliated/sv) |
21:04.50 | *** join/#arm-netbook Mehhh (adabd66c@gateway/web/freenode/ip.173.171.214.108) |
21:16.31 | atari2600a | so |
21:16.32 | atari2600a | um |
21:17.00 | atari2600a | when do you guys think you'll get to that whole unified bootloader standard thing |
21:17.09 | atari2600a | it has to be one of the biggest setbacks with ARM |
21:17.53 | *** join/#arm-netbook captaini1loo (~nico@lan31-4-82-227-130-131.fbx.proxad.net) |
21:19.40 | Turl | isn't uboot that? |
21:28.54 | *** join/#arm-netbook ssvb (~ssvb@212.16.98.80) |
21:29.56 | hno | oliv3r & mnemoc, I am not pouring any original material into linux-sunxi.org wiki until the data can be managed reasonably and there is backups. |
21:44.15 | *** join/#arm-netbook slapin_nb (~slapin@host-233-146-66-217.spbmts.ru) |
21:46.09 | CaCtus491 | ...this talk about qty 100 for a small A10 board with WiFi, 3G, Ethernet... |
21:46.44 | CaCtus491 | I'm also looking for something very similar (qty 100, 3G, Ethernet), WiFi may be handy, but not required |
21:47.42 | focus_it | CaCtus491: http://cubieboard.org/ for you? |
21:47.52 | CaCtus491 | I also need 3 or 4 uarts, but can easily add that via USB via an FTDI chip or similar |
21:51.35 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
21:52.34 | libv | CaCtus491: or olinuxino |
21:56.17 | CaCtus491 | hmm, re: cubieboard, I don't see any obvious pins on the 48 pin 2mm headers that would allow me to connect a 3G module to a base board |
21:56.35 | CaCtus491 | (ie, I'd need to use the USB connector to the edge of the board |
21:56.37 | CaCtus491 | ) |
21:58.23 | focus_it | CaCtus491: 3G you can use a MyFi or similar device http://en.wikipedia.org/wiki/MiFi ? |
21:59.13 | focus_it | Use the wifi to connect to the MiFi. |
22:01.17 | libv | CaCtus491: look at the olinuxino |
22:01.36 | libv | CaCtus491: if you get the ones without wifi, you can use that usb connection to connect a 3g module |
22:04.20 | *** join/#arm-netbook tuliom (~tuliom@186.214.51.246) |
22:06.34 | libv | CaCtus491: feel free to contact olimex or tom cubie to find out how much they charge for adapting their designs to your needs and for providing the limited run you need |
22:08.21 | focus_it | CaCtus491: olimex IRC channel is #olimex on freenode |
22:08.54 | libv | but i personally consider them quite on-topic in here too :) |
22:09.08 | libv | in as far as linux-sunxi is on-topic in the eoma channel ;) |
22:09.28 | *** join/#arm-netbook alcides (~alcides@177.17.156.31) |
22:09.28 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
22:10.22 | libv | olinuxino has two uarts exposed directly |
22:11.05 | libv | olimex will not be adverse to designing a 3g submodule if the revenue is there |
22:15.07 | CaCtus491 | excellent |
22:15.23 | *** join/#arm-netbook specing (~specing@unaffiliated/specing) |
22:15.41 | CaCtus491 | the A13 OLinuXino looks pretty close to what I need |
22:16.24 | CaCtus491 | ...the 3G stuff will need to be 'integrated' in that I need to have the solution in a single extruded aluminium case |
22:17.15 | CaCtus491 | hmm, Olimex... |
22:17.44 | CaCtus491 | interesting, this project is to replace an older LPC2148 based design from a few years back |
22:18.02 | CaCtus491 | I seem to remember purchasing some LPC2148 stuff from them :) |
22:23.36 | libv | like this one? https://www.olimex.com/Products/ARM/NXP/LPC-H2148/ |
22:24.32 | libv | is a cortex a8 really what you need for your project? |
22:26.15 | CaCtus491 | heh, yeah, new revision will have many new additional features that simply aren't possible witht the existing hardware, including a LCD for UI |
22:29.10 | Turl | CaCtus491: btw, Ethernet is 100Mbit |
22:31.41 | CaCtus491 | yeah, 100Mbit is heaps, even 10Mbit would do ;) |
22:32.26 | CaCtus491 | I wonder when the Olimex A13 mini board will be ready |
22:38.07 | *** join/#arm-netbook hp__ (~kvirc@118-168-206-252.dynamic.hinet.net) |
23:24.00 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
23:34.15 | *** join/#arm-netbook raiden (u2733@gateway/web/irccloud.com/x-cbdrjmxzacetcbie) |