| 01:06.47 | *** join/#arm-netbook stefanro1 (~stefan@pD9FFB26D.dip0.t-ipconnect.de) |
| 01:09.51 | *** join/#arm-netbook acassis (~alan@189.101.43.52) |
| 02:03.29 | *** join/#arm-netbook cnxsoft (~Thunderbi@node-60k.pool-118-172.dynamic.totbb.net) |
| 03:05.07 | *** join/#arm-netbook eebrah (~eebrah@105.230.124.112) |
| 03:21.43 | *** join/#arm-netbook eebrah (~eebrah@105.230.65.111) |
| 03:29.03 | *** join/#arm-netbook eebrah (~eebrah@105.230.218.77) |
| 04:43.26 | *** join/#arm-netbook keebler (~keebler@aarondunlap.org) |
| 05:00.42 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 05:17.49 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 05:48.11 | SPG | master f607d4f rhombus allwinner_a10/orders/aross.mdwn * This reverts commit 47aa59a3fff8ae424ed54a3ad21f498d9d48f163 * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=f607d4f |
| 05:49.14 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 06:08.33 | *** join/#arm-netbook fragmint (~fragmint@108-77-199-24.lightspeed.tukrga.sbcglobal.net) |
| 07:13.32 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 07:38.35 | *** join/#arm-netbook Quarx (~Quarx@109.120.34.85) |
| 07:39.24 | *** join/#arm-netbook Quarx|2 (~Quarx@46.165.251.66) |
| 07:44.35 | *** join/#arm-netbook panda84kde (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 07:59.52 | *** join/#arm-netbook cnxsoft (~Thunderbi@node-60k.pool-118-172.dynamic.totbb.net) |
| 08:00.12 | *** join/#arm-netbook dfletcher (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 08:02.05 | *** join/#arm-netbook keebler (~keebler@unaffiliated/keebler) |
| 08:06.59 | *** join/#arm-netbook roric (~roric@134.191.244.57) |
| 08:52.48 | *** join/#arm-netbook Kebianizao|work (~Kebianiza@128.35.219.87.dynamic.jazztel.es) |
| 08:54.01 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 09:02.54 | *** join/#arm-netbook focus (~Doug@host81-149-149-147.in-addr.btopenworld.com) |
| 09:07.34 | *** join/#arm-netbook Quarx (~Quarx@109.120.34.85) |
| 09:25.21 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 09:31.00 | *** join/#arm-netbook fossxplorer (~fossxplor@unaffiliated/fossxplorer) |
| 09:54.13 | *** join/#arm-netbook acassis (~alan@189.101.43.52) |
| 09:58.55 | *** join/#arm-netbook popolon (~popolon@unaffiliated/popolon) |
| 10:07.59 | *** join/#arm-netbook nashpa (~nashpa@dliviu.plus.com) |
| 10:28.40 | *** join/#arm-netbook fredy (~fredy@snf-8914.vm.okeanos.grnet.gr) |
| 10:54.45 | *** join/#arm-netbook _massi_ (~massi@host164-128-static.225-95-b.business.telecomitalia.it) |
| 11:21.42 | *** join/#arm-netbook acassis (~alan@189.40.67.182) |
| 11:51.06 | *** join/#arm-netbook lerc (~quassel@121-74-1-14.telstraclear.net) |
| 12:05.47 | *** join/#arm-netbook ganbold_ (~Ganbold@173.244.215.173) |
| 13:20.56 | *** join/#arm-netbook merbanan (~benjamin@h217-27-188-82.cust.tyfon.se) |
| 13:49.41 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 14:12.01 | *** join/#arm-netbook merbanan (~benjamin@h217-27-188-82.cust.tyfon.se) |
| 14:12.53 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 14:27.13 | *** join/#arm-netbook atiti (~atiti@cpe.xe-3-0-0-3183.bynqu1.dk.customer.tdc.net) |
| 14:34.17 | *** join/#arm-netbook aesok (~aesok@95-28-87-176.broadband.corbina.ru) |
| 14:46.25 | *** join/#arm-netbook sfeole (~sfeole@91.189.91.3) |
| 15:08.42 | *** join/#arm-netbook datagutt (~datagutt@unaffiliated/datagutt) |
| 15:43.09 | *** join/#arm-netbook gordan (~gordan@host217-34-137-93.in-addr.btopenworld.com) |
| 15:46.11 | *** join/#arm-netbook datagutt (~datagutt@unaffiliated/datagutt) |
| 16:06.49 | *** join/#arm-netbook datagutt (~datagutt@unaffiliated/datagutt) |
| 16:13.54 | *** join/#arm-netbook techn_ (~quassel@a91-152-35-60.elisa-laajakaista.fi) |
| 16:25.48 | *** join/#arm-netbook datagutt (~datagutt@unaffiliated/datagutt) |
| 16:36.53 | *** join/#arm-netbook hurtigbu- (~me@pinkie.kladdkaka.org) |
| 16:38.26 | *** join/#arm-netbook fil (~phil@switch.hands.com) |
| 16:42.15 | *** join/#arm-netbook keebler_ (~keebler@aarondunlap.org) |
| 16:42.42 | *** join/#arm-netbook nashpa (~nashpa@dliviu.plus.com) |
| 16:44.47 | *** join/#arm-netbook nomadic_ (~nomadic@95.154.243.64) |
| 16:44.56 | *** join/#arm-netbook Guest21616 (~me@pdpc/supporter/active/jelly) |
| 16:45.04 | *** join/#arm-netbook fil_ (~phil@switch.hands.com) |
| 16:48.18 | *** join/#arm-netbook jelly-home (~me@pinkie.kladdkaka.org) |
| 16:51.19 | *** join/#arm-netbook adb (~IonMoldom@2a02:1205:501b:68e0:baac:6fff:fe67:305f) |
| 16:51.28 | *** join/#arm-netbook Guest27771 (~me@pdpc/supporter/active/jelly) |
| 16:53.17 | *** join/#arm-netbook jelly-home (~me@pdpc/supporter/active/jelly) |
| 17:22.51 | *** join/#arm-netbook rz2k (~rz2k@188.244.38.171) |
| 18:24.00 | *** join/#arm-netbook eebrah (~eebrah@105.230.86.161) |
| 18:34.40 | lkcl | hramrach: i think that some devices such as set-top boxes *might* have marvell SoCs in them, but to be honest i'm left wondering why marvell is in business *at all*! |
| 19:05.30 | *** join/#arm-netbook valhalla (~valhalla@88-149-226-171.v4.ngi.it) |
| 19:16.42 | hramrach | lkcl: because they do other stuff that's actually profitable ;-) |
| 19:17.19 | hramrach | note that the SoCs use Ethernet and SATA IP that marvell sells as separate chips |
| 19:17.53 | hramrach | and perhaps there are some devices with marvell SoCs nobody happened to open and put the photos on the web |
| 19:18.34 | hramrach | actually, the SoCs have MPEG IO which is specifically designed for settop boxes |
| 19:18.41 | mripard | pretty much all the NAS out there have either a Atom or a Marvell SoCs these days |
| 19:18.46 | mripard | the chromecast has one |
| 19:19.03 | mripard | a lot of set-top boxes and "smart TVs" as well |
| 19:19.11 | mripard | and some modems/routers |
| 19:19.33 | hramrach | ok, so nobody just bothers to figure out how to put Linux on the device because they are too limited in hardware to be worth the effort |
| 19:20.04 | mripard | too limited? |
| 19:21.07 | mripard | compared to what? |
| 19:21.15 | hramrach | well, qnap is supported, and has like 16mb flash on the top models and the PCIe is unavailable |
| 19:21.36 | mripard | qnap is supported where? |
| 19:21.49 | mripard | in linux? |
| 19:22.03 | hramrach | there are some pages saying how to put Linux on most if I am not mistaken |
| 19:22.14 | hramrach | Debian |
| 19:22.48 | mripard | I'm running debian on my lacie NAS that has a kirkwood |
| 19:23.23 | mripard | and Marvell Armada 370 or XP SoCs are very well supported in mainline nowadays |
| 19:23.24 | hramrach | yes, and what does it have? 1 Ethernet out of two, both sata, 0 of 2 PCIe? |
| 19:23.42 | mripard | so debian should just work. |
| 19:24.12 | *** join/#arm-netbook drachensun (~drachensu@72.238.114.145) |
| 19:24.16 | hramrach | it works as NAS out of the box so the reward for putting Linux on it is minimal, too |
| 19:24.52 | hramrach | well, maybe you could get hardware accelerated scp |
| 19:25.05 | hramrach | which is kind of cool but is about all you get |
| 19:25.34 | mripard | except for the crappy system on top of it :) |
| 19:25.35 | mripard | but anyway |
| 19:25.49 | hramrach | unless you want to make cluster of them and put ceph or something on that |
| 19:26.05 | mripard | Marvell is used, on a lot of hardware, and also happens to be very well supported in Linux. |
| 19:27.33 | hramrach | but the hardware is rather uninteresting because it has very little expansion possibilities, very little internal RAM and flash, outdated ARM architecture, and it does what it is designed to do out of the box and is pretty much useless for anything else |
| 19:27.49 | hramrach | plus the NAS boxes are quite expensive |
| 19:28.06 | hramrach | you can get a notebook for the price of a qnap box |
| 19:33.17 | mripard | outdated ? |
| 19:33.31 | mripard | a quad core armv7 SoC isn't really outdated... |
| 19:33.51 | hramrach | all the anoes I looked at were arm5 |
| 19:34.01 | hramrach | missed the newer ones then I guess |
| 19:34.44 | hramrach | so some use current arm arch but everything else still applies |
| 19:37.16 | mripard | well, it's targeted for a given market, and doesn't try to do anything else |
| 19:37.53 | *** join/#arm-netbook lerc (~quassel@121-74-1-14.telstraclear.net) |
| 19:38.13 | mripard | but saying that it's useless is pretty harsh |
| 19:38.23 | hramrach | except the very same NAS box with the two PCIe lanes accessible would be awesome device customizable in numerous ways |
| 19:39.08 | hramrach | no, it;s pretty useless for anything than what the pre-installed OS already does |
| 19:39.36 | hramrach | and the space for the OS is very small so no wonder it's somewhat lame |
| 19:40.08 | hramrach | *other than* |
| 19:40.13 | mripard | then don't blame marvell, blame the manufacturer. |
| 19:41.48 | hramrach | marvell does not do devboards. they designed them bu they are out of stock. and according to lkcl they don't even sell the chips to hardware designers. so there you go. they totally have nothing to do with unavailability of decent hardware |
| 19:41.48 | mripard | and iirc, synology base their system on debian |
| 19:41.55 | mripard | so you have access to apt and all |
| 19:43.02 | hramrach | that's cool. so not so lame OS for once |
| 19:43.23 | hramrach | but the hardware is still limited. maybe not so much to make apt fit but still |
| 19:44.20 | mripard | how can you be short on storage on a NAS? |
| 19:44.40 | hramrach | the disks on some are removable |
| 19:44.59 | hramrach | true some are fixed so can have only bootloader in flash |
| 19:45.49 | mripard | I don't know about how other NAS vendors install their system |
| 19:46.06 | mripard | but on my lacie, the system is actually stored on the hard disks |
| 19:46.13 | mripard | even though the disks are racked |
| 19:46.39 | hramrach | pretty fragile arrangement |
| 19:48.39 | mripard | yep |
| 19:51.54 | hramrach | mripard: now that I see you |
| 19:52.41 | hramrach | afaik the recommended way to make a sysfs entry is to instantiate a platform driver |
| 19:53.06 | hramrach | but to do that I need a DT entry that says the kernel to instantiate it |
| 19:53.42 | mripard | well, depending on your driver, yeah, a platform driver would be better |
| 19:53.57 | hramrach | but I just want to make a sysfs entry the moment the module is loaded or the kernel with built with my led trigger starts |
| 19:54.34 | mripard | the kernel with built with my led trigger starts ? |
| 19:54.35 | hramrach | so building the stuff should be enough. the DT entry is redundant |
| 19:54.50 | hramrach | built with |
| 19:55.04 | *** join/#arm-netbook rcg_re (~username_@82-171-58-197.ip.telfort.nl) |
| 19:55.21 | mripard | how does the led trigger relate to your sysfs file? |
| 19:55.33 | hramrach | it is a parameter for it |
| 19:56.01 | mripard | ok |
| 19:56.06 | hramrach | which can be cahnged at runtime and maybe does not even crash the kernel when changed |
| 19:56.21 | mripard | then just create your sysfs in your module_init function |
| 19:56.40 | mripard | You might need a device to do so though |
| 19:56.59 | hramrach | so back to the platform driver |
| 19:57.31 | mripard | ah |
| 19:57.35 | mripard | you just need a kobject |
| 19:57.54 | mripard | so it's probably working in module_init |
| 20:00.14 | hramrach | the function was void |
| 20:00.20 | hramrach | so no kobject there |
| 20:00.49 | hramrach | or do you get one with THIS_MODULE or something? |
| 20:02.58 | hramrach | it was DEVICE_ATTR on 3.4 and converts to device_add_file which needs a device .. |
| 20:03.53 | hramrach | * device_create_file |
| 20:06.08 | hramrach | yes, no other interface so you do need a device |
| 20:06.35 | mripard | you have sysfs_create_file |
| 20:07.22 | mripard | but it seems to be a bit hackish :) |
| 20:08.12 | hramrach | it only makes file, no content |
| 20:08.48 | hramrach | and requires a kobj which is then supposed to handle the content somehow? |
| 20:09.13 | mripard | ? |
| 20:09.34 | mripard | you have the attributes as a second argument |
| 20:09.54 | hramrach | note d_c_f takes device_attribute but s_c_f struct attribute |
| 20:10.21 | hramrach | devide_attribut has show/sote callbacks but not struct attribute |
| 20:10.35 | hramrach | store |
| 20:11.01 | mripard | hmmm right |
| 20:11.06 | mripard | then yes, you need a device |
| 20:11.13 | mripard | and thus, to make a proper driver |
| 20:11.49 | hramrach | so I have a device if I make an entry in DT |
| 20:12.39 | hramrach | but the entry is redundant. I already configured the trigger in the kernel so like every other trigger I want it instantiated automagically |
| 20:16.29 | mripard | but it seems odd that the trigger mechanism isn't able to make you set some parameters through sysfs |
| 20:16.37 | mripard | and you don't exactly need the DT |
| 20:16.52 | mripard | you can register a device matching your driver in the module_init function |
| 20:16.59 | mripard | that's hacky, but it works. |
| 20:17.13 | mripard | but really, I'm surprised you need to do this in the first place |
| 20:17.19 | hramrach | does any other trigger have argument? afaik it does not |
| 20:17.26 | mripard | I don't know |
| 20:18.11 | *** join/#arm-netbook atiti (~atiti@80.196.237.2) |
| 20:19.02 | hramrach | because to be able to do it with trigger mechanism you would need to duplicate device_*_file as ledtrig_*_file for different object type as the sysfs stuff suggests |
| 20:19.19 | hramrach | C class polymorphism at its worst |
| 20:19.50 | *** join/#arm-netbook lerc (~quassel@121-74-1-14.telstraclear.net) |
| 20:20.19 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 20:20.42 | hramrach | hmm, actually drivers/leds/trigger/ledtrig-oneshot.c: rc = device_create_fil |
| 20:21.08 | hramrach | should look where they pull the device from I guess |
| 20:22.19 | hramrach | it puts the sysfs file on the led :s |
| 20:22.27 | mripard | http://lxr.free-electrons.com/source/include/linux/leds.h#L153 |
| 20:22.58 | mripard | the activate and deactivate functions pass a device as an argument |
| 20:23.00 | mripard | yeah |
| 20:23.03 | mripard | which makes sense |
| 20:23.17 | mripard | I mean, you want to configure the trigger on a led per led basis |
| 20:23.17 | hramrach | unless you have a global argument for the trigger |
| 20:23.43 | mripard | then just have a big fat global variable in your trigger file :) |
| 20:24.08 | hramrach | I do. but how do I make it accessible to userspace? |
| 20:24.34 | mripard | by calling device_create_file |
| 20:24.44 | hramrach | on what device? |
| 20:24.54 | mripard | the lcdclass_dev one |
| 20:24.59 | hramrach | especially when I start associated with no led? |
| 20:25.40 | mripard | so, to sum up, you have a led trigger. That you don't want to associate with any led ? |
| 20:26.02 | hramrach | triggers exist independent of leds |
| 20:26.20 | hramrach | you can associate and dissociate them |
| 20:26.41 | mripard | yeah |
| 20:26.45 | hramrach | or deassociate or w/e |
| 20:26.57 | hramrach | so you can have a trigger that is not associated with any led |
| 20:27.13 | hramrach | and it still has the global parameter |
| 20:27.25 | mripard | but, what's the point of having a *led* trigger that isn't associated with any led |
| 20:27.30 | mripard | and still does something? |
| 20:27.51 | hramrach | no. it is careful to do anything only when associated with a led |
| 20:28.15 | hramrach | but you might want to set the parameter before you associate it with a led |
| 20:28.26 | mripard | ah, yes |
| 20:28.33 | *** join/#arm-netbook lerc (~quassel@121-74-1-14.telstraclear.net) |
| 20:28.45 | mripard | well, it doesn't seem possible yet |
| 20:28.45 | hramrach | and you don;t want searching a *trigger* parameter on a *led* |
| 20:28.50 | mripard | feel free to rework the whole thing :) |
| 20:29.03 | mripard | why ? it is associated to that led |
| 20:29.16 | mripard | and you want most of the time to configure it on a led per led basis |
| 20:29.25 | hramrach | but the parameter apples on every led it's associated with |
| 20:29.51 | hramrach | not in this case. it's the frequency of led update for disk trigger |
| 20:30.23 | hramrach | you don't want to go hunting for every disk and set it, only after the trigger is associated |
| 20:30.43 | mripard | but you might want different frequency for different disks |
| 20:31.12 | hramrach | it's frequency of gathering the data. the actual updates depend on the disk activity |
| 20:32.04 | hramrach | and I can't technically do that because I have just one timer, anyway |
| 20:36.12 | mripard | I don't know how to do this properly, I'm sorry. |
| 20:36.50 | hramrach | hmm, I guess I should write to lkml or something then |
| 20:37.08 | hramrach | anyway, thanks for confirming there is no obvious way to do it ;-) |
| 20:39.24 | hramrach | or I could do the ledtrig_timer way and make a timer for each active trigger, yay |
| 20:40.34 | hramrach | would not have to keep track of my triggers! |
| 20:40.39 | *** join/#arm-netbook atiti (~atiti@80.196.237.2) |
| 20:40.55 | hramrach | actually, no |
| 20:41.40 | hramrach | I need to keep track of them either way because when a block device is removed I need to remove its triggers and nobody but my driver knows where they are |
| 20:43.56 | hramrach | heh, I just noticed I added a duplicate activation callback instead of adding the self argument to it |
| 20:51.01 | hramrach | actually, the callback ahs slightly different semantics which is hard to detect outside of the framework |
| 20:51.46 | hramrach | they call activate(led) but I want activate(trigger) when trigger gets first led .. |
| 21:22.25 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:548b:256e:b034:9a54) |
| 21:30.41 | *** join/#arm-netbook drachensun (~drachensu@fw.corecashless.com) |
| 21:34.04 | *** join/#arm-netbook acassis (~alan@189.101.43.52) |
| 21:58.52 | lkcl | hramrach: the marvell pxa's are... odd. the history is that it was actually the DEC Alpha and StrongARM team that got bought by Intel. |
| 21:59.46 | lkcl | they then licensed ARM's core in a $100k cash-only royalty-free deal in which Intel promised to help fix the problems with the ARM design and give the modifications back to ARM |
| 22:00.38 | lkcl | except... the problems were *so severe* that - and this is speculation - i think what Intel did was to *entirely redesign* the PXA core from the ground up, around a proper harvard architecture with an out-of-order instruction unit and many other features |
| 22:00.55 | lkcl | putting an "ARM-like" instruction set on *top* of that main core. |
| 22:01.32 | lkcl | as a result they were perfectly within their rights to not return what they'd done to the design... because they had made *zero* modifications: they'd had to start from scratch |
| 22:02.01 | lkcl | so, actually, the Intel PXA was the world's first ARM SoC that had a superscalar architecture... *not* the Cortex A8 :) |
| 22:02.07 | lkcl | ARM were _pissed_ :) |
| 22:02.31 | hramrach | intel is not known for always producing a proper architecture - see NetBurst |
| 22:02.40 | lkcl | but... tough luck. they'd been told a decade before that their design was crap, but didn't believe people |
| 22:02.43 | lkcl | hramrach: yeah :) |
| 22:03.31 | lkcl | so anyway, the irony is that the performance/watt figures on the PXA design, made by that old DEC StrongARM team, were so much better than the Intel Atom that management decided to sell off the PXA Division. |
| 22:03.34 | hramrach | but what I don't understand is that Intel dropped ARM. They were ahead of ARM with ARM architecture ;-) |
| 22:03.36 | lkcl | marvell bought them |
| 22:03.49 | lkcl | hramrach: exactly. it was a major embarrassment to them. |
| 22:04.02 | lkcl | ... but they've kept that royalty-free license :) |
| 22:04.06 | hramrach | for both ARM and Intel, meh |
| 22:04.27 | lkcl | they still the right to create an ARM-compatible core, at any time ha ha |
| 22:04.52 | lkcl | only armv6 (or v5?) i don't know which - but it *doesn't* include the armv7 (armhf) instructions. |
| 22:04.59 | hramrach | they could not push Microsoft to extend Wintel to ARM at that time, apparently |
| 22:05.08 | hramrach | WinCE was a disaster |
| 22:05.46 | lkcl | hramrach: well, DEC had already learned that. DEC had been promised that NT would be available for Alpha etc. |
| 22:05.57 | lkcl | but the last version was NT 3.51. |
| 22:06.28 | hramrach | not that Windws RT is panning out well so far |
| 22:06.34 | hramrach | so may be not even today |
| 22:06.35 | lkcl | so DEC had to create that JIT assembly-level translation system, which ended up (after a program had been run a few times) with code that ran *faster* than x86! |
| 22:06.59 | hramrach | I wan that JIT system for armhf ;-) |
| 22:07.01 | lkcl | which was also embarrassing and probably contributed to Intel buying out the DEC/StrongARM team |
| 22:07.04 | lkcl | you can't have it! |
| 22:07.10 | lkcl | it's been bought and buried by intel |
| 22:07.40 | lkcl | you'll have to get your own amazingly-brilliant team, set them on the task for 10 years and make a fortune that way :) |
| 22:07.44 | hramrach | it's not *that* difficult |
| 22:08.10 | hramrach | Java can do faster than C compilers with its JIT |
| 22:08.44 | lkcl | hramrach: weelll.... i don't know the full story. i do know that the DEC Alpha was pretty unique. |
| 22:09.09 | hramrach | at that time they were really fast machines |
| 22:09.22 | lkcl | no floating-point unit... because there were instructions available that were fast enough on their own to efficiently emulate floating point in fixed point! |
| 22:09.35 | lkcl | yeah.... 600mhz and 130 watt (eek!). |
| 22:09.53 | hramrach | I wonder why so many media codecs do fixed point even today |
| 22:10.55 | hramrach | you save on instruction get and simpler everything except compiler ;-) |
| 22:11.02 | lkcl | inherent parallelism, it's more silicon-efficient to use less hardware in parallel than it is to have the "convenience" of floating-point |
| 22:11.34 | lkcl | you want to win in the power-performance stakes? you go with the most power-performance hardware, and the software can go fuck itself basically! |
| 22:11.52 | hramrach | yes, you get more integer cores if you ditch the fpu moster and they are *universal* |
| 22:12.08 | lkcl | except if you're ImgTec, where that mantra has been taken to such an extreme that the software is too complex for their engineers to understand. |
| 22:12.41 | lkcl | hramrach: exactly. the most extreme processor i've seen that logic applied to is the Aspex Semiconductor "ASP", which i worked with back in 2003. |
| 22:12.55 | lkcl | that was a 2-bit ALU... multipled *4096* times. |
| 22:13.48 | lkcl | and if you know about multiplication, you'll know that because 2x2 = 2+2, there's a trick you can do which makes 2-bit multiplication mind-bafflingly efficient |
| 22:14.21 | lkcl | then if you have a string of 2-bit ALUs you can do any sized add or multiply you want. |
| 22:14.29 | lkcl | really weird architecture :) |
| 22:14.30 | hramrach | and it worked like 8kbit arithmetics? |
| 22:14.52 | hramrach | not 32 or 64 bit .. |
| 22:14.53 | lkcl | hramrach: yeees... but you had to do it using long-multiplication at those sorts of sizes |
| 22:15.51 | lkcl | which meant that it would take O(N) to complete a multiply. really efficient for 2, 4 or 8-bit multiplies, but it sucked (performance-wise) when compared to e.g. a Pentium III! |
| 22:16.12 | lkcl | there were lots of efficiency tricks that have been studied for decades which simply couldn't be used |
| 22:17.05 | hramrach | you always have these concerns like does it fit in word or do I have to do some strange multiword arithmetics? but when it is the default adding a few bits is not a problem |
| 22:18.10 | lkcl | yeah with this architecture, if you wanted 128-bit or 256-bit or any-bit that was a multiple of 16, you just set arbitrary boundaries (they were dynamic switches between each group of 16 ALUs) and that was that. |
| 22:18.41 | lkcl | two groups of 16 2-bit ALUs suddenly became a string of 32 2-bit ALUs. and so on. |
| 22:19.13 | lkcl | the only thing it was truly *truly* good at though (when compared to ordinary CPUs) was a) Content-Addressable Memory lookups b) sub-8-bit arithmetic |
| 22:19.44 | lkcl | so video processing which needs say... to do some "blurring" involving the nearest 2 pixels, it was immensely fast |
| 22:19.45 | *** join/#arm-netbook roric (~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se) |
| 22:20.22 | lkcl | there isn't a single processor in the world other than the ASP that can handle say 2-bit, 3-bit or 5-bit arithmetic. |
| 22:20.36 | hramrach | heh |
| 22:20.49 | lkcl | they all have to be a minimum of 8-bit (ok, Intel 4004 .... 4 bit lol) |
| 22:21.11 | lkcl | anyway. enough of that :) |
| 22:21.28 | lkcl | anyone seen any quad-core ARM SoCs out there, other than the rockchip RK3188? |
| 22:21.32 | hramrach | is that sillicone still available or did it die? |
| 22:22.01 | lkcl | it's still available. and only $12. and 28nm. |
| 22:22.02 | hramrach | lkcl: samsung. And marvel. |
| 22:22.13 | lkcl | hramrach: marvell are clinically insane |
| 22:22.15 | hramrach | nice :o |
| 22:22.22 | lkcl | and their SoCs are too power-hungry. |
| 22:22.39 | hramrach | the Intel/Alpha heritage? |
| 22:23.06 | hramrach | I don't mind for tabletop devboards but would surely suck for tablets |
| 22:23.41 | lkcl | hramrach: yeah. it's basically armv5 compatible (armel) but with a superscalar architecture underneath that gives it superior performance |
| 22:24.17 | lkcl | ... except ARM's now moving rather rapidly with the Cortex range, and that's completely eroded marvell's edge |
| 22:24.56 | lkcl | http://www.samsung.com/global/business/semiconductor/product/application/detail?productId=7668 |
| 22:24.58 | lkcl | waaaah! |
| 22:25.11 | lkcl | over 1000 pins! |
| 22:25.13 | hramrach | they are still pretty proud of their interconnect which unlike some random Chinese IP actually connects |
| 22:25.54 | lkcl | :) |
| 22:28.20 | lkcl | Exynos 5 - SATA, HSIC, USB3 (!)... awesome |
| 22:39.03 | hramrach | tegra has PCIe iirc |
| 22:40.48 | hramrach | the thing with Marvell is they use real Gbit ethernets and real SATA which is the same they put in PCs and performs the same. |
| 22:45.13 | lkcl | hramrach: they do. |
| 22:45.41 | lkcl | you know what the power consumption is on sheevaplugs and guruplugs when you use the gbe's? |
| 22:45.58 | lkcl | ... they get a leeetle bit warm :) |
| 22:58.53 | *** join/#arm-netbook Night-Shade (~tim@217.151.109.172) |
| 23:24.31 | *** join/#arm-netbook popolon (~popolon@unaffiliated/popolon) |
| 23:56.59 | *** join/#arm-netbook Pricey (~pricey@freenode/staff/pricey) |