| 00:07.51 | *** join/#arm-netbook arokux (~roman@HSI-KBW-046-005-103-006.hsi8.kabel-badenwuerttemberg.de) |
| 00:08.45 | CIA-46 | rhombus-tech: jussi master * r4f90e94484a3 /allwinner_a10/orders/jussi.mdwn: |
| 00:38.09 | A2Sheds | mnemoc: nice going, one less dev to help us |
| 00:55.03 | arokux | are those mele boards already ordered? I'd like to have one too. |
| 00:55.33 | *** part/#arm-netbook L84Supper (~ly@unaffiliated/l84supper) |
| 00:58.02 | mnemoc | A2Sheds: what did I do? |
| 00:58.49 | arokux | I've just read the logs. you did nothing... |
| 01:07.40 | mnemoc | :) |
| 01:07.43 | mnemoc | good night |
| 01:08.23 | mnemoc | https://github.com/amery/linux-allwinner/commits/allwinner-v3.0-android is now sightly closer to compile |
| 03:48.11 | CIA-46 | rhombus-tech: mab master * re5fb0136ded2 /allwinner_a10/orders/mab.mdwn: |
| 05:19.59 | CIA-46 | rhombus-tech: Adam master * r8411dbe47755 /allwinner_a10/orders/VastGsm.mdwn: |
| 05:20.27 | *** join/#arm-netbook eflatun (~eflatun@95.173.234.229) |
| 05:20.30 | CIA-46 | rhombus-tech: Adam master * r49468d789b2e /allwinner_a10/orders/VastGsm.mdwn: |
| 05:21.26 | CIA-46 | rhombus-tech: Adam master * r4ff4bb162d35 /allwinner_a10/orders/VastGsm2.mdwn: |
| 07:43.19 | *** join/#arm-netbook destinal (~chatzilla@ip70-173-29-15.lv.lv.cox.net) |
| 07:43.53 | destinal | does anyone know if there are any Renesas EV2 (cortex-a9) devices out that have released kernel / android source yet? |
| 07:49.20 | destinal | hmm I think I have answered my own question: http://tabletrepublic.com/forum/cortex-a9-renesas-ev2/bsp-sdk-nec-renesas-emma-ev2-based-android-devices-incl-tablets-custom-rom-90.html |
| 09:42.58 | *** join/#arm-netbook arokux (~roman@HSI-KBW-046-005-103-006.hsi8.kabel-badenwuerttemberg.de) |
| 10:04.31 | *** join/#arm-netbook QingPei1 (~qingpei@123.118.109.170) |
| 10:30.53 | *** join/#arm-netbook gordan (~gordan@78-86-195-86.zone2.bethere.co.uk) |
| 10:53.30 | CIA-46 | rhombus-tech: Alejandro master * rbebdfe64ac1f /allwinner_a10/kernel_compile.mdwn: corrected link to mnemoc's kernel tree on github |
| 12:12.55 | *** join/#arm-netbook eflatun (~eflatun@46.1.230.105) |
| 12:21.13 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 14:38.29 | *** join/#arm-netbook arete74 (5d954654@gateway/web/freenode/ip.93.149.70.84) |
| 14:54.23 | A2Sheds | http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h1/index.jsp |
| 14:55.16 | mnemoc | O_O |
| 14:55.28 | penguin42 | yeh, a bit of a frankenstein - with an SH as well as an ARM |
| 15:08.53 | *** join/#arm-netbook arete74 (5d954654@gateway/web/freenode/ip.93.149.70.84) |
| 15:20.49 | lkcl | destinal, thank you - can i ask you a favour, can you make a page |
| 15:20.55 | lkcl | http://rhombus-tech.net/ev2 |
| 15:21.25 | lkcl | and add that link to it? |
| 15:21.40 | CIA-46 | rhombus-tech: lkcl master * r83e0c491e583 /: Merge branch 'master' of ssh://git.hands.com/rhombus |
| 15:21.51 | CIA-46 | rhombus-tech: lkcl master * r969c3fa99b76 /ev2.mdwn: add blank page |
| 15:22.24 | penguin42 | I was wondering - does EOMA-68 have much to say on power and cooling? I guess it's not a problem with the A10 but some of the quadcore chips get noticeably hot |
| 15:25.46 | mnemoc | EOMA-68 puts a limit on how much power your card can get... |
| 15:31.15 | penguin42 | http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Thermal_Considerations |
| 15:37.25 | penguin42 | I was wondering how the heat gets from the jacket of the card to the chassis - but I don't really know much about designing stuff like that |
| 15:42.39 | mnemoc | A2Sheds: you probably know to answer that ----^ |
| 15:43.34 | mnemoc | I'm just a C ape |
| 15:48.15 | A2Sheds | penguin42: how about this then? http://rhombus-tech.net./amd_g_series/ |
| 15:55.51 | penguin42 | A2Sheds: Well, where do you put that polymer stuff? I can see you putting it on top of the chip between the chip and the outer sleeve of the card (or even making the card sleeve out of it) but when you push the card into the socket, what makes sure the card has a good thermal transfer to the chassis ? |
| 16:02.42 | A2Sheds | penguin42: it depends on how you want to design it, the polymers listed are for the enclosure, they are plastics with higher watts per K (conductivity) than Aluminum |
| 16:05.08 | penguin42 | A2Sheds: yeh but I mean in a conventional PCMCIA slot are you guaranteed anything about heat conductivity from the card to the chassis? |
| 16:10.27 | A2Sheds | I'll have no problem, not sure about others designs :) |
| 16:11.48 | A2Sheds | it's not a PCMCIA slot, so it won't work in those physically, electrically or thermally, pretty sure it would be chemically compatible though |
| 16:14.04 | Gumboot | As I read it, it sounded like you could try to stick a PCMCIA card into one of those slots. Does something block that? |
| 16:14.34 | penguin42 | Gumboot: Yeh there is a bit that sticks out in just the right place |
| 16:15.22 | penguin42 | Gumboot: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Deliberate_Mechanical_Non-interoperability |
| 16:15.22 | Gumboot | In addition to the bit in the CPU card which stops it being stuffed into a PCMCIA slot, that is, right? |
| 16:16.53 | Gumboot | I don't see anything that blocks old cards, there. |
| 16:17.10 | penguin42 | oh you mean to block pcmcia cards into eoma sockets? Oh I'd only read the other way around |
| 16:18.33 | Gumboot | And what's with the terms 'new' and 'legacy' there? It's like two different versions of the same thing when really they're completely unrelated. |
| 16:19.55 | penguin42 | well they do share a connector and general shape |
| 16:21.05 | Gumboot | But 'legacy' isn't a good way to indicate 'PCMCIA'. |
| 16:24.26 | A2Sheds | the wiki needs an editor |
| 16:25.23 | Gumboot | Well, I'm not touching it because I don't know the facts. When I look at things like that I wonder if there are already two versions of the EOMA spec. |
| 16:26.53 | A2Sheds | hmm, that is a mess, |
| 16:28.27 | A2Sheds | the original concept before I was involved had a faceplate to keep eoma cards from fitting it in PCMCIA slots |
| 16:29.20 | Gumboot | Are PCMCIA cards inherently safe from harm when inserted into an EOMA motherboard? |
| 16:29.56 | A2Sheds | the pinouts were changed to not harm them |
| 16:30.52 | Gumboot | Worth documenting for clarity, I expect. |
| 16:31.21 | Gumboot | Although, "does not fit" is always going to be far more user-friendly. |
| 16:32.12 | A2Sheds | waiting for connectors, so I'm working on 8 other projects right now, the docs should catch up |
| 16:34.30 | Gumboot | Are any of those projects a motherboard? I haven't put my name down for any units because I have no idea what to plug them into to make them useful. |
| 16:41.02 | ManoftheSea | Gumboot: you could plug them into a TV. |
| 16:41.12 | ManoftheSea | Without a case. |
| 16:41.49 | zenitraM | or talk to them using ADB over the USB port |
| 16:45.13 | penguin42 | I assume they won't accidentally fit into TV CAM slots! |
| 16:45.32 | Gumboot | Where are these connectors documented? |
| 16:46.10 | Gumboot | I see pictures of them in some of the other pages about motherboards, but not an official product page for the orderable part. |
| 16:48.02 | Gumboot | It might be easier to get to the $15 mark through volume orders if only it was easier for people to see what they were going to get and how they were going to use it. |
| 16:49.00 | CIA-46 | rhombus-tech: Andris master * re0b08136a0f1 /allwinner_a10/orders/AA.mdwn: |
| 16:52.11 | Gumboot | The rhombus-tech page gives me the impression that I've accidentally wandered into the kitchen and nobody has time to direct me to the dining area. |
| 16:56.12 | penguin42 | Gumboot: Feel free to snack from the worksurfaces |
| 16:59.36 | penguin42 | Gumboot: There's not much point creating a big sing and dance (like certain other projects) when you can't buy them |
| 17:00.41 | Gumboot | No, but a clearer explanation of what real things are coming might be good. Especially when there _is_ a pre-orders page to be filled out. |
| 17:00.57 | *** join/#arm-netbook eflatun (~eflatun@46.1.230.105) |
| 17:33.20 | lkcl | Gumboot: http://rhombus-tech.net/allwinner_a10/pcb/ |
| 17:33.44 | lkcl | we've found the PCMCIA connector. |
| 17:33.54 | mnemoc | \o/ |
| 17:34.46 | lkcl | i've just been talking to a guy who would like to get an EOMA-68-compliant tablet made |
| 17:35.06 | mnemoc | neat |
| 17:35.14 | lkcl | he's sourced a 2-point capacitive touch panel for it, already. |
| 17:35.58 | lkcl | from elan electronics |
| 17:36.00 | lkcl | which is great |
| 17:39.40 | mnemoc | what's his use case? |
| 17:46.22 | mnemoc | 2-point touch panels aren't really want the general market expects these days, but it's quite decent for industrial for example |
| 17:47.04 | mnemoc | It would be very nice to see a not too expensive eoma68 rugged tablet |
| 17:51.12 | lkcl | funny that: that's exactly what this guy wants to get made :) |
| 17:51.23 | mnemoc | :D |
| 17:51.36 | *** join/#arm-netbook gordan (~gordan@78-86-195-86.zone2.bethere.co.uk) |
| 17:51.40 | lkcl | probably industrial uses :) |
| 17:51.43 | Gumboot | "2-point" means you can poke it with two fingers at once? |
| 17:52.03 | mnemoc | yes, two fingers |
| 17:52.15 | lkcl | penguin42: be nice to Gumboot! :) |
| 17:52.18 | Gumboot | Do any standard user interfaces need _more_ than two fingers? |
| 17:52.44 | mnemoc | you may not notice but one tends to get a third in |
| 17:53.03 | mnemoc | 2-point tends to feel irresponsive |
| 17:53.28 | lkcl | btw Gumboot: the point of using a wiki to manage the web site is so that it attracts developers at this stage, rather than the "average user". |
| 17:53.41 | Gumboot | So th problem is that a third messes up the whole thing, rather than that you can't track three at once. |
| 17:53.48 | lkcl | if we wanted "average users" i would have installed pee haytch pee bee bee :) |
| 17:55.09 | Gumboot | I don't see it as particularly attractive to developers. It simply requires more effort to penetrate. |
| 17:56.23 | Gumboot | And if it takes effort to figure out what something is, then you start out without knowing what it is or whether or not you even _want_ to know what it is. |
| 18:00.21 | Gumboot | That might be a very bad filter, actually. It selects people who have time to spend looking at stuff rather than those who prefer to get on with proper work. |
| 18:20.20 | A2Sheds | industrial tablets is a great application, those things are usually pricey and way behind current tech |
| 18:20.59 | A2Sheds | many are using the old StrongARM or PXA marvell soc's |
| 18:24.03 | A2Sheds | I had a difficult time finding a Linux based handheld PC http://www.intermec.com/products/computers/handheld_computers/index.aspx arm11 or arm9 |
| 18:24.27 | A2Sheds | and all over $1K with win-CE |
| 18:25.07 | A2Sheds | http://www.intermec.com/products/computers/fixed_vehicle_computers/index.aspx these are even more outrageous in price vs features |
| 18:25.31 | A2Sheds | Intel® XScale PXA270 Application Processor, 520 MHz |
| 18:26.33 | A2Sheds | IIRC the yellow covers for these are 10+ years old |
| 18:44.51 | gordan | In fairness, the PXA XScale isn't actually at all bad for a CPU of that age. |
| 18:45.58 | A2Sheds | yes, great at the time |
| 18:48.09 | gordan | The fact that it is still quite usable even today for lower end devices is quite a testament to how good it was back then. |
| 18:48.39 | gordan | My old HTC Universal had one of those in it. |
| 18:56.12 | A2Sheds | I think i still have some iPaq's that used them |
| 18:56.32 | A2Sheds | batteries all died first |
| 19:03.46 | lkcl | gordan: oooo, you have an HTC universaaal |
| 19:04.11 | lkcl | i helped do the reverse-engineering of linux onto those. |
| 19:04.27 | lkcl | and the blueangel. and the himalaya. and the hw 6915. |
| 19:04.48 | lkcl | they were fuuuun |
| 19:04.56 | gordan | I had one yes. Sold it a few months ago. Was keeping it because I wanted to do the same thing. Android 1.5 had been hacked onto it, but I eventually concluded I'd never really have time to look into doing something worthwhile with it. |
| 19:05.04 | lkcl | i hope you installed linux on it! |
| 19:05.20 | gordan | I had Linux running on it, but none of the phone bits worked with Linux. |
| 19:05.33 | lkcl | well then you should have run angstrom ... ahh, yeah. they did.. but... |
| 19:05.35 | gordan | So I flashed WinMo 6.5 onto it and ebayed it. |
| 19:05.39 | lkcl | gpephone |
| 19:05.41 | lkcl | snorts |
| 19:05.45 | lkcl | ah well |
| 19:05.59 | lkcl | probably the best thing all round :) |
| 19:06.13 | gordan | In the day and age where an AC100 can be had for a little over £100 there seemed little point in keeping it. |
| 19:06.25 | gordan | It was too big for a phone and too small for a laptop. |
| 19:06.28 | lkcl | in a word... yeah. |
| 19:06.36 | lkcl | but... it's historic! |
| 19:06.42 | lkcl | well, it is to me anyway |
| 19:07.09 | lkcl | oo my computer's about to go into meltdown again, doing a link of xulrunner. |
| 19:07.35 | lkcl | 150mb resident RAM so far on the link phase... it gets up to 1.5gb before it stops |
| 19:07.59 | lkcl | btw... um... where the bloody hell did all these people come from? :) |
| 19:08.45 | gordan | I agree - it is historic. But life too short, as is the space I have available. :) |
| 19:09.22 | gordan | LOL! Welcome to building the current generation of Linux bloatware. |
| 19:09.23 | lkcl | hehe |
| 19:10.03 | gordan | Incidentally - I have RedSleeve Enterprise Linux 6 cooked enough for a beta. :) |
| 19:10.16 | lkcl | i concluded the same thing about 10 months ago - dumped *nine* HTC mobile phones onto someone who was buying a house for him and his young wife |
| 19:10.27 | lkcl | expecting a baby, hence the house. |
| 19:10.31 | gordan | Yup. |
| 19:10.45 | lkcl | oo goodie, i loove deadrat lunix. |
| 19:10.56 | gordan | It focuses the mind, that's for sure. :) |
| 19:11.23 | lkcl | is obligated under the rms "gnu" programme to point out that gordan meant readsleeve enterprise gnu/linux there :) |
| 19:11.33 | lkcl | pokes gordan |
| 19:11.37 | gordan | eyerolls |
| 19:11.50 | gordan | Just need to put together a rootfs and get some kind of a webpage up. |
| 19:11.59 | lkcl | ha ha |
| 19:12.38 | lkcl | can you let alain williams know? he's been meaning to port centos to arm. |
| 19:12.38 | gordan | I'm just concerned that since the server is a DreamPlug and lives on a connection with a total of about 2.5Mbit/s upstream, I might just DoS myself if I actually announce it. |
| 19:12.50 | gordan | Sure, what's his email address? |
| 19:13.16 | gordan | I've been working on this with Don Gullet. I hadn't realized there were more interested parties. |
| 19:13.18 | lkcl | well i'll be able to let you know once my computer recovers enough to let the memory-hog firefox back into resident RAM :) |
| 19:13.33 | lkcl | phcomp.co.uk |
| 19:13.40 | lkcl | http://www.phcomp.co.uk |
| 19:13.51 | lkcl | if you check that you'll find it easier than i can right now |
| 19:13.54 | gordan | Are you offering a mirror for the yum repository and the rootfs tarball? :) |
| 19:14.03 | gordan | Oh, right! OK. |
| 19:14.05 | gordan | goes to look. |
| 19:14.10 | lkcl | well... maybe you could ask phil hands |
| 19:14.17 | lkcl | or yes perhaps alain |
| 19:14.32 | lkcl | but if it's going to get big, then asking phil is probably the most sensible option. |
| 19:14.34 | gordan | Well, I was planning to get it mirrored on mirrorservice.org |
| 19:14.40 | lkcl | he runs the ftp uk debian mirror |
| 19:15.01 | lkcl | he shouuuld have some spare disk space... |
| 19:15.35 | lkcl | /dev/vdd 175461040 131057936 35490848 79% /home |
| 19:15.43 | lkcl | /dev/vdg 2074941880 1921562012 153379868 93% /org |
| 19:15.46 | gordan | Annoyingly, I've actually had it pretty much ready 3 months ago - it's taken the last two months just to get the replacement artwork for the redhat-logos package. |
| 19:15.52 | lkcl | doh! |
| 19:16.25 | gordan | RSEL6 mirroring will require somewhere in the region of 10GB to get all the rpms and src.rpms |
| 19:16.25 | lkcl | pings fil |
| 19:16.35 | lkcl | is that all?? |
| 19:17.16 | lkcl | dude, ftp.uk.debian.org is running... well you can see for yourself... almost 2Tb |
| 19:17.23 | gordan | LOL! Remember this is RHEL6 with a few bits missing (eclipse and OpenOffice at the moment). No EPEL (Fedora extras). |
| 19:17.37 | lkcl | there appears to be 153gb spare (!!) |
| 19:17.42 | gordan | It'll do. :) |
| 19:17.52 | lkcl | well, it'll do for a _few_ months... |
| 19:18.03 | gordan | Anyhoo - I can't seem to find an email address for Alain Williams... |
| 19:18.46 | gordan | addw@phcomp.co.uk? |
| 19:18.51 | lkcl | what's yours? |
| 19:18.53 | lkcl | ah yeah |
| 19:18.54 | lkcl | that's him |
| 19:19.03 | gordan | I just googled him and that came up. |
| 19:19.11 | lkcl | that'll do he he |
| 19:19.13 | gordan | OK, I'll poke an email in his direction. |
| 19:19.22 | lkcl | phil is, obviously, phil@hands.com |
| 19:19.24 | lkcl | duh |
| 19:22.31 | CIA-46 | rhombus-tech: walid master * r77cf68e907f7 /allwinner_a10/orders/Walidos.mdwn: |
| 19:23.00 | lkcl | ye gods another one |
| 19:25.54 | CIA-46 | rhombus-tech: walid master * raaf5ce6623e4 /allwinner_a10/orders/Walidos.mdwn: |
| 19:28.45 | CIA-46 | rhombus-tech: lkcl master * r91e3dc7534fd /allwinner_a10/orders/ (10 files in 2 dirs): order processing cleanup |
| 19:28.55 | CIA-46 | rhombus-tech: lkcl master * r6f012c9864ca /: :Merge branch 'master' of ssh://git.hands.com/rhombus |
| 19:29.42 | A2Sheds | anyone know the status of floating point on ARM, i recall apps like Scribus having issues with float / qreal etc |
| 19:30.29 | lkcl | that sounds a bit bizarre. |
| 19:30.39 | A2Sheds | http://bugs.scribus.net/view.php?id=9850 |
| 19:31.23 | A2Sheds | "The arm[el] float/double/qreal debacle " |
| 19:31.39 | lkcl | ahh joy |
| 19:32.29 | A2Sheds | I haven't checked in a year, did this issue ever get resolved? |
| 19:33.41 | lkcl | interesting. looks like straightforward "epic fail" on assumptions about qt4 to me. |
| 19:33.51 | gordan | qt4? |
| 19:34.06 | gordan | I have qt4 running on RSEL6 just fine. I'm running KDE on my AC100. |
| 19:34.21 | lkcl | yeah it's the _use_ of qt4 that's the problem, gordan. |
| 19:34.46 | lkcl | the programmers using qt4 made assumptions that the qt4 "qreal" is #defined to be a double |
| 19:34.58 | A2Sheds | figures, Scribus was the #1 app we needed for ARM |
| 19:35.04 | lkcl | when in the case of the ARM architecture it's #defined to be a float. |
| 19:35.07 | gordan | Is qreal even a valid C++ type?? |
| 19:35.33 | lkcl | no |
| 19:35.43 | lkcl | it's a #define (or equivalent) in qt4. |
| 19:35.48 | lkcl | the "q" is a giveaway :) |
| 19:35.59 | gordan | It sounds like you could fix the problem with a sed script and just convert all instances of qreal to double and be done with it. :) |
| 19:38.34 | lkcl | mmm... :) |
| 19:38.40 | A2Sheds | it was also something about the effect it had on font rendering and vector graphics |
| 19:38.50 | lkcl | not enough accuracy. |
| 19:38.55 | A2Sheds | yeah |
| 19:38.57 | lkcl | again that's bad programming. |
| 19:39.22 | lkcl | i bet you they multiplied large numbers together and divided by small ones |
| 19:39.25 | A2Sheds | works on x86 |
| 19:39.47 | gordan | A lot of things work on x86. |
| 19:39.59 | gordan | x86 has a lot of features that just breed bad programming. |
| 19:40.08 | gordan | Not least of which is automatic transparent alignment fixup. |
| 19:40.09 | lkcl | yes... x86 has enough power to waste so that qt4 can #define qreal to double |
| 19:40.12 | lkcl | oo ouch |
| 19:40.29 | gordan | They added that in ARM with v7 arch, too. |
| 19:40.34 | lkcl | funfunfun |
| 19:41.20 | gordan | But it means people don't think about how things are aligned and end up using char[] for buffers (byte aligned), then cast that to a struct (which isn't byte aligned). |
| 19:41.56 | gordan | And when you find this sort of crap happens all over the place in things like e2fsprogs - well, let's just say that if you're not concerned, you don't understand the problem. |
| 19:42.13 | gordan | And that's just the outright breaking of things. |
| 19:42.43 | gordan | There are a lot of subtle reasons why you want to make sure the alignment is right even with automatic transparent fixup, e.g. the performance hit if your data is straddling cache lines, etc. |
| 19:43.20 | gordan | The problem is that software has been becoming more shit as fast as Intel has been making CPUs go faster. |
| 19:43.41 | gordan | Hence why the computers today don't feel like they are getting things done faster for us today than they did 15 years ago. |
| 19:45.38 | gordan | The fact that students of computer science are being taught that "a compiler can optimize as well as a human so don't bother doing it yourself" also hasn't helped. Then again, the fact that very few places teach languages where you have enough control to make a difference makes that argument deprecated and too abstract to be comprehensible to most newbies. |
| 19:45.42 | gordan | <PROTECTED> |
| 19:47.55 | lkcl | teehee |
| 19:48.13 | *** part/#arm-netbook QingPei1 (~qingpei@123.118.109.170) |
| 20:04.19 | gordan | Right, the rootfs is uploaded now, too, as are all the src.rpms and the yum repo of the binaries. |
| 20:06.27 | gordan | You can find it all here if anyone is interested: http://ftp.redsleeve.org/pub/yum/os/ |
| 20:12.29 | penguin42 | A2Sheds: IMHO the problem with qreal is QT not ARM |
| 20:12.43 | A2Sheds | yes |
| 20:13.19 | penguin42 | A2Sheds: There is this huge random ifdef in Qt where it decides for some arch's to use float for QReal - OK, that's kind of OK (given how double was probably expensive on old ARM) |
| 20:13.41 | A2Sheds | the other 578 apps work just fine, just the most important one is buggy :) |
| 20:14.41 | penguin42 | A2Sheds: But then the Max/Min is done oddly and won't let you mix float/double - I seem to remember it might have been a C++ template with T as the two parameters; if they added some explicit instantiatiations they might have got away with it |
| 20:18.57 | penguin42 | it's a pity; armhf would have been a good time to flip ARM/Qt over to double |
| 20:41.27 | mnemoc | do you know what 'udc' means in usb context? |
| 20:43.48 | penguin42 | possibly USB Device Controller ? |
| 20:44.08 | penguin42 | that's th ecomment at the top of langwell_udc.h in the kernel |
| 20:44.17 | mnemoc | :) |
| 20:44.19 | mnemoc | thanks |
| 20:52.40 | mnemoc | drivers/usb/sun4i_usb/Makefile enabled a module when CONFIG_USB_SW_SUN4I_UDC0 is defined, but there is no Kconfig option for it... I suppse it's safe to use CONFIG_USB_SW_SUN4I_USB instead |
| 20:53.38 | mnemoc | the usb_msg_center doesn't link without some symbols from there |
| 20:55.08 | zenitraM | just got my Novo7 updated to the latest ICS beta.. which has yet another new kernel |
| 20:55.11 | zenitraM | root@android:/ # cat /proc/version |
| 20:55.11 | zenitraM | Linux version 3.0.8 (lbzhang@androidSRV) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #19 PREEMPT Fri Mar 2 16:26:08 CST 2012 |
| 21:02.07 | CIA-46 | rhombus-tech: Eric master * ra5d080f5271d /ev2.mdwn: created new page to start documenting EV2 |
| 21:02.34 | destinal | lkcl: created http://rhombus-tech.net/ev2/ and added the source code link and lots of other random information I've seen about the EV2 SoC |
| 21:04.26 | destinal | I have a sample order in with smallart for their U-Host U-1 dongle, but more interestingly, smallart is coming up with an A10 based dongle next month. for both of these, think like cotton candy, insert device into an HDMI TV, insert its USB cord into the TV's USB port or other USB power supply |
| 21:09.16 | mnemoc | smallart? |
| 21:10.21 | zenitraM | Sample Price: US$69? |
| 21:10.21 | zenitraM | wow |
| 21:10.41 | destinal | zenitraM: $40 shipping though |
| 21:10.50 | destinal | :-/ |
| 21:11.18 | destinal | and it's intended for samples for people who are considering buying 100+, you can't buy an arbitrary number below qty 100 |
| 21:11.56 | zenitraM | it's a nice price anyway |
| 21:12.00 | destinal | zenitraM: indeed |
| 21:12.50 | zenitraM | the A10 one will be cheaper I suppose |
| 21:13.18 | destinal | and their A10 they're coming out with next month could be a useful dev board for us for those of us who don't need pins broken out |
| 21:14.33 | zenitraM | unless it's way cheaper the mele is a better option i think.. |
| 21:15.08 | destinal | note, I asked for kernel and android source code for their A9 and they just about bent over backwards to avoid me the inconvenience of having to mess with that, they will build whatever firmware images I need etc |
| 21:15.10 | destinal | :( |
| 21:15.45 | zenitraM | too bad :( well at least for the A10 everything is already out |
| 21:15.50 | destinal | exactly |
| 21:15.53 | zenitraM | or in process or begin sorted out |
| 21:15.58 | zenitraM | s/or/of/ |
| 21:16.21 | destinal | and I found the source code for the A9 stuff too even if not specifically for their dongle, for the SoC |
| 21:16.34 | destinal | for the EV2 I mean |
| 21:20.02 | lkcl | destinal: superb. thank you |
| 21:20.21 | lkcl | hey that's really good. |
| 21:21.50 | lkcl | ohhhh i know why i didn't include the EV2 as a priority: it doesn't have HDMI out or something. nor SATA. |
| 21:22.37 | lkcl | so that would mean adding an HDMI converter ($1 to $2) and a USB-to-SATA converter ($1 to $2) and a USB hub ($1 to $2) |
| 21:22.38 | destinal | lkcl: hmm, http://smallart.en.ecplaza.net/u-host--319901-2474079.html has HDMI though, wonder if they had to use an encoder? |
| 21:23.21 | lkcl | yep, they all do. |
| 21:23.37 | lkcl | where did i find the datasheet on the EMMA EV2? can't remember... |
| 21:23.44 | destinal | lkcl: yeah those are good points. also the powervr is a bit weak |
| 21:24.08 | destinal | lkcl: but it is a dual core cortex-A9 at least |
| 21:24.08 | lkcl | it's ok. just... thoroughly proprietary. |
| 21:24.13 | lkcl | true |
| 21:25.15 | lkcl | just taking a look at the datasheet... |
| 21:26.11 | destinal | A10 is looking to be really nice, easy to get access to UART over SD card sockets, SATA, Mali (with the oss driver project going on), looks basically impossible to brick since it boots over SD or USB I think. Just wish it were dual core |
| 21:26.22 | lkcl | basically yes |
| 21:26.41 | lkcl | they'll get there. i'm sure they're working on a dual-core cortex a9 after the success of the A10 |
| 21:27.28 | lkcl | right, yeah, the emma ev2 is a single LCD out |
| 21:27.40 | destinal | so from the smallart dongles I'm actually a bit more interested in their A10 version even though it's not as high performance processing wise |
| 21:28.06 | destinal | mele may still be preferable for dev (I was on the group buy for that) |
| 21:28.20 | *** join/#arm-netbook Guest60220 (~pete@c-71-194-180-159.hsd1.il.comcast.net) |
| 21:28.24 | Guest60220 | hello |
| 21:28.37 | lkcl | hello Guest60220 |
| 21:29.00 | Guest60220 | I'm trying to run a simple program on an arm-board. |
| 21:29.26 | penguin42 | Guest60220: When you say on an arm board; is the board booted Linux? |
| 21:29.32 | Guest60220 | It has a kernel built with uclibc, and I compiled a hello-world with gcc |
| 21:29.38 | lkcl | hmm, it's actually got a YUV interface as well as an LCD interface. iiinteresting. |
| 21:29.50 | lkcl | so not as "dumb" as i thought. |
| 21:30.02 | Guest60220 | sorry to interrupt |
| 21:30.18 | lkcl | no problem, this is IRC, it's possible for people to hold 2 conversations :) |
| 21:30.21 | destinal | lkcl: oh nice the datasheet is linked to from the MFR page I hosted |
| 21:30.33 | destinal | s/hosted/posted/ |
| 21:30.43 | Guest60220 | i get a segv error |
| 21:30.58 | mnemoc | Guest60220: gdb is your friend ;-) |
| 21:31.11 | penguin42 | Guest60220: When you say a kernel built with uclibc, what kernel do you mean? |
| 21:31.14 | Guest60220 | gdb? oh, the debugger |
| 21:31.29 | Guest60220 | uh, 2.6.32... I'll look |
| 21:31.37 | penguin42 | Guest60220: Or do you mean a linux kernel, and a uclibc user space? |
| 21:31.43 | lkcl | but yeah only one USB out, no SATA, no Ethernet.... |
| 21:31.45 | mnemoc | Guest60220: also, the kernel is not linked to any userspace libc |
| 21:32.15 | Guest60220 | its 2.6.36.3 |
| 21:32.20 | lkcl | so whatever the cost of the EV2 is, you now have to add... errr.... at least another $6 to $8 in components to make it EOMA-compliant |
| 21:32.59 | penguin42 | lkcl: and unless it has PCI it's still a bodge to get SATA/Ether out of it at any decent speed |
| 21:33.05 | Guest60220 | I can compile the program with the cross-tools toolchain, but not gcc I installed |
| 21:33.32 | penguin42 | Guest60220: So with the cross tool chain does it work, or does it just compile? |
| 21:33.41 | Guest60220 | I should say I can compile with both, but it doesn't run |
| 21:34.11 | Guest60220 | gcc takes around 600k, where uclibc takes 5k. Maybe I'm running out of memory? |
| 21:34.14 | hno | lkcl, HDMI converter would be optional. There is no HDMI in EOMA as such. |
| 21:34.14 | penguin42 | Guest60220: OK, so what compiler tool chain are you using and what userspace are you using on the board?? |
| 21:34.27 | lkcl | destinal: page 40 is where the pinout multiplexing starts |
| 21:34.34 | lkcl | hno: good point! |
| 21:34.35 | Guest60220 | userspace? I don't understand |
| 21:34.47 | hno | Guest12039, applications. |
| 21:34.51 | penguin42 | Guest60220: OK, tell us a bit more about what's installed on the board |
| 21:34.58 | penguin42 | Guest60220: Oh and please pick a nick! |
| 21:36.35 | Guest60220 | command for nick? |
| 21:36.48 | penguin42 | <PROTECTED> |
| 21:36.53 | lkcl | without the space |
| 21:37.14 | lkcl | changes name to thenameyouwant |
| 21:37.29 | pete32 | ok, I'm pete32 |
| 21:37.31 | lkcl | yeay! |
| 21:37.52 | pete32 | I've just got a terminal installed on the board, kernel, ubooot |
| 21:38.09 | penguin42 | pete32: OK, where did the terminal/kernel/etc come from? |
| 21:38.16 | pete32 | It's a repurposed digital picture frame |
| 21:38.23 | penguin42 | OK :-) |
| 21:38.39 | penguin42 | pete32: and which cross tools are you using? |
| 21:38.40 | pete32 | repurpose_linux.net or something. Hackaday |
| 21:38.55 | pete32 | 1.13.0 |
| 21:39.11 | pete32 | both compilers are 4.6 |
| 21:39.19 | mnemoc | pete32: this isn't really the channel for your needs, try #edev or #elinux |
| 21:39.46 | pete32 | Ok, I just wanted to know if I'm flogging the wrong compiler? |
| 21:40.09 | penguin42 | pete32: Possibly; I've not heard of that one - make sure it matches the CPU on your board |
| 21:40.26 | mnemoc | pete32: http://www.bravegnu.org/gnu-eprog/ <--- this might be a good starting point |
| 21:40.51 | pete32 | yep, did that. thanks for the reference |
| 21:42.37 | hno | likes hacking devices to new uses. |
| 21:44.48 | *** part/#arm-netbook pete32 (~pete@c-71-194-180-159.hsd1.il.comcast.net) |
| 21:46.15 | lkcl | hno: something you might find as hilarious as i do: i wrote the EOMA-68 specification. you reminding me it hasn't got HDMI on the connector was just a hoot |
| 21:46.26 | destinal | lol |
| 21:47.35 | destinal | lkcl: I guess I understand not putting HDMI on the connector, for most people probably they'll buy more system cards than IO boards |
| 21:47.39 | lkcl | i will be sooo glaaad when we have actual real hardware.... |
| 21:47.56 | destinal | and we were running short on pins :_ |
| 21:47.58 | destinal | :) |
| 21:48.34 | lkcl | well... it's more than that. i also had to think "what's the lowest common denominator, here?" |
| 21:49.00 | lkcl | if pins were reaaally important, i would have said "ok, put HDMI out the 68-pin connector" |
| 21:49.01 | destinal | yeah you have to put LCD pins definitely, so LCD + HDMI on the connector is kind of redundant / more expensive than needed |
| 21:49.17 | lkcl | or maybe LVDS |
| 21:49.37 | lkcl | hell even _two_ LVDS channels (10+10) is less than 24-pin RGB (28 pins) |
| 21:49.37 | hno | need to look up what hoot means. |
| 21:49.51 | penguin42 | lkcl: Do any panels actually take raw rgb? |
| 21:49.55 | lkcl | hno: remember to make it an english slang one |
| 21:50.05 | lkcl | penguin42: yes - the really small ones. usually up to 800x600 |
| 21:50.27 | lkcl | there are a few high-quality 800x600 LCDs |
| 21:50.34 | destinal | lkcl: so most EOMA68 boards will probably have LVDS encoders on them (not sure if encoder is the right word for that IC) |
| 21:50.41 | penguin42 | lkcl: Ah ok; I've got a box full of old 640x480 ones that do (they're ancient - I've had them for about 15 years and done nothing with them) |
| 21:50.44 | destinal | err IO boards I mean |
| 21:50.56 | lkcl | but things like the AT070TN93 are i think 18-pin RGB/TTL |
| 21:51.21 | destinal | and by that I mean most IO boards designed for LCD use in laptops / tablets |
| 21:51.40 | destinal | needs to collect all thoughts before typing, lol |
| 21:51.49 | lkcl | yeah, once you get above a certain clock-rate, you get skew on running 24 parallel data lines that is simply too much to handle |
| 21:52.12 | penguin42 | nod |
| 21:52.20 | lkcl | so you serialise them. tadaaa, bye bye skew problems. |
| 21:52.53 | lkcl | for screens up to 800x600 the clock rates aren't fast enough for that to be a problem |
| 21:52.58 | mnemoc | hno: do you have time for some tiny asm work on the sun4i kernel? :) |
| 21:53.15 | hno | mnemoc, I can try. Where? |
| 21:53.31 | lkcl | 1024x600 up to about 1440x900 you can get away with a single LVDS (just about, on 1440x900) |
| 21:53.45 | penguin42 | lkcl: Oh the only time I ever ran these 640x480 panels was over a piece of ribbon cable from a VGA expansion connector - it was perfectly happy with old school stuff! |
| 21:54.00 | lkcl | penguin42: he he |
| 21:54.34 | penguin42 | I'm a little surprised there are no cheap A5 or A7 chips |
| 21:54.52 | penguin42 | they were both done as supposed to be cheaper/better replacements for A8 |
| 21:54.58 | mnemoc | hno: https://github.com/amery/linux-allwinner/blob/allwinner-v3.0-android/arch/arm/mach-sun4i/include/mach/debug-macro.S |
| 21:54.59 | hno | penguin42, there is, just not any interesting ones. |
| 21:55.11 | penguin42 | hno: Ah |
| 21:55.29 | mnemoc | hno: they removed machine_desc.phys_io and machine_desc.io_pg_offst and somehow expect addruart to return those |
| 21:55.50 | mnemoc | hno: but our addruart is an stub :( |
| 21:56.44 | mnemoc | https://raw.github.com/amery/linux-allwinner/allwinner-v3.0-android/arch/arm/mach-sun4i/include/mach/debug-macro.S ... better. their highligting of .S is totally f*ed up |
| 21:57.51 | penguin42 | (sun4i keeps confusing me, I keep thinking SPARC systems) |
| 21:58.06 | mnemoc | :) |
| 21:58.13 | hno | penguin42, yes it's a very confusing name |
| 21:59.08 | penguin42 | hmm my IPX is a bit large as a case for the A10 board |
| 21:59.55 | hno | mnemoc, when did it change? |
| 22:00.53 | mnemoc | in 0ea1293009826da45e1019f45dfde1e557bb30df they changed the semantic of addruart |
| 22:01.25 | mnemoc | and in 6451d7783ba5ff24eb1a544eaa6665b890f30466 they dropped machine_desc.io_pg_offst and .phys_io because addruart was giving all needed... |
| 22:01.28 | hno | how do this know which uart to address? |
| 22:02.35 | mnemoc | no idea :( |
| 22:03.41 | hno | Filling it in is not an issue, just needs to return the uart base address, both physical and virtual. Just don't quite get for which purpose it's used. |
| 22:03.44 | mnemoc | tried to understand the addruart of other platforms... but it's way over my level |
| 22:04.05 | hno | See mach-kirkwood/include/mach/debug-macro.S |
| 22:05.50 | hno | you can copy that and just change the addresses. The numeric constant is the offset to the UART registers. |
| 22:06.33 | mnemoc | so other pieces of code are supposed to substract that offset to know the phys? |
| 22:07.04 | hno | What? The function returns both virtual and physical address of the UART, in two different arm registers. |
| 22:07.17 | hno | s/function/macro/ |
| 22:07.27 | mnemoc | yes, but that's the address of the uart |
| 22:08.00 | mnemoc | no other use for the old machine_desc.phys_io ? |
| 22:08.39 | mnemoc | sorry for the noobness, it's the first time I go this deep |
| 22:08.58 | hno | the other uart macros works on offsets within the uart register file. |
| 22:09.27 | hno | can't tell. Haven |
| 22:09.46 | hno | Haven't been in these areas for quite some time. |
| 22:12.33 | hno | Ah, found what these are used for now. It's an alternative primitive debug output useful if printk is not working. |
| 22:14.38 | mnemoc | if you have github account I can gladly give you commit access :-) |
| 22:14.49 | hno | hno |
| 22:15.31 | hno | need to get a little more familiar with git... usually use bzr. |
| 22:15.52 | lkcl | git is fuuuun |
| 22:16.43 | lkcl | wrote a python-based JSONRPC wiki service using python-dulwich... |
| 22:17.16 | mnemoc | hno: in that branch sound isn't 3.0-ready but everything else compiles fine |
| 22:18.24 | hno | have used git a bit, but mostly linear never looking back. |
| 22:22.34 | mnemoc | the feature i love most of git is the capability of altering the past :p |
| 22:23.14 | hno | except that it doesn't. It just makes a new past. |
| 22:23.38 | mnemoc | true, it's a new timeline... but you can then destroy the other :p |
| 22:24.16 | hno | or at least not push it any further. |
| 22:25.23 | hno | Ok. UART register base is in mach-sun4i/include/mach/uart_regs.h. |
| 22:26.23 | destinal | lkcl: nice! I think I'm just thrilled to see services out there using JSON rather than XML :) |
| 22:26.58 | hno | mnemoc, what kind of UARTs do the A10 have? |
| 22:28.00 | destinal | lkcl: I kind of like the protobuf concept too |
| 22:28.03 | mnemoc | i don't know *shame* :( |
| 22:29.18 | mnemoc | i didn't even look at the other headers in arch/arm/mach-sun4i/include/mach/ :-/ |
| 22:31.10 | mnemoc | i've only fixed "C problems" which don't require to actually understand the boot process or the hardware |
| 22:32.39 | hno | Oh well.. these macros is not implemented in the original allwinner sources. |
| 22:33.24 | mnemoc | right |
| 22:33.52 | mnemoc | but feels like it might be good to do so :p |
| 22:42.37 | hno | to do so we need to know which of the 8 UARTs to address. |
| 22:43.02 | mnemoc | uhm... |
| 22:43.21 | hno | it's a "SW" UART type btw. drivers/serial/sw-uart.c is the normal driver. |
| 22:44.48 | mnemoc | sw = softwinner = alter-ego of allwinner |
| 22:45.43 | hno | :seems so. |
| 22:47.17 | mnemoc | i suppose we should pick the easier to access uart on the mele |
| 22:47.43 | hno | I kind of doubt we need these debug macros. |
| 22:48.24 | mnemoc | not needed for the serial console? |
| 22:48.31 | hno | no |
| 22:48.49 | mnemoc | early printk()s I mean |
| 22:49.37 | hno | probably |
| 22:55.00 | hno | yes |
| 22:55.35 | hno | arch/arm/kernel/debug.S printch needs to work for early_printk to work. |
| 23:07.02 | zenitraM | if i'm not wrong… the correct UART is the first one |
| 23:07.11 | zenitraM | all of the UART pinouts are defined on script.bin |
| 23:07.19 | mnemoc | going to sleep now, I hope to get the sound drivers ported tomorrow |
| 23:07.33 | mnemoc | not sure if we can use script.bin info in debug.S |
| 23:07.44 | hno | I think we can use the 8250 glue. sw-uart.c seems to be 8250 with only small differences not relevant to these debug functions. |
| 23:07.58 | zenitraM | i don't know exactly where script.bin fits here |
| 23:09.03 | zenitraM | but if i believe well the uart0 address doesn't vary, script.bin configures its pinout but the offsets should be the same |
| 23:09.41 | zenitraM | the only one with uart_used=1 is uart_para0 |
| 23:11.08 | mnemoc | if you decide (please do so) to work upon the allwinner-3.0-android branch I have in github, disable CONFIG_SND_SOC after making sun4i_defconfig |
| 23:11.52 | zenitraM | i'll try tomorrow |
| 23:12.18 | mnemoc | great :) |
| 23:12.27 | mnemoc | good night |
| 23:12.31 | zenitraM | night! |
| 23:24.34 | *** join/#arm-netbook gordan (~gordan@78-86-195-86.zone2.bethere.co.uk) |
| 23:44.15 | penguin42 | will the A10 EOMA board have a set of text layer printed on the PCB? If so will it have convenient markings for the 68 pin connector - e.g. marking every 10 pins or something like that? |
| 23:55.19 | destinal | penguin42: hmm, what benefit would putting a mark every ten pins on the silkscreen have? |
| 23:55.59 | destinal | penguin42: planning to hand solder things to the pins? |
| 23:58.11 | penguin42 | destinal: Either hand solder or use something similar to jumpers; I was assuming that it would be easy to cut a usb/sata/ether lead in two and do that |
| 23:59.13 | destinal | penguin42: the connector is I think, pretty tight pitch, you could probably do it with magnet wire to a a stripboard or something though |