| 00:10.43 | *** join/#edev missinmee (~missinmee@24-116-159-154.cpe.cableone.net) |
| 01:01.44 | *** join/#edev Belliash (~belliash@asiotec/constitutive/belliash) |
| 01:30.55 | *** join/#edev djerome (~djerome@ip68-98-228-41.ph.ph.cox.net) |
| 01:33.51 | *** join/#edev groglogic (~groglogic@ip-64-134-11-2.public.wayport.net) |
| 01:57.13 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 02:01.31 | *** join/#edev mrcan_ (~mrcan@78.173.225.0) |
| 02:01.31 | *** join/#edev mrcan_ (~mrcan@unaffiliated/mrcan) |
| 03:01.55 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 03:34.00 | *** join/#edev [7] (~quassel@rockbox/developer/TheSeven) |
| 03:38.34 | *** join/#edev JoeLlama (~snork@cpe-172-249-122-125.socal.res.rr.com) |
| 03:38.36 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 03:39.45 | *** join/#edev calculus (~calculus@adsl-99-27-129-64.dsl.pltn13.sbcglobal.net) |
| 03:39.46 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 03:50.09 | *** join/#edev Senor (~Senor@123.150.170.224) |
| 07:23.20 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 08:30.28 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 09:23.26 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 13:27.33 | *** join/#edev purl (~purl@rikers.org) |
| 13:27.33 | *** topic/#edev is Discussion of embedded systems (Hardware/Software/Linux/Commercial Device Repurposing) : Busybox and Buildroot : http://www.elinux.org : Logs available at ibot.rikers.org |
| 13:32.00 | *** join/#edev Belliash (~belliash@asiotec/constitutive/belliash) |
| 14:08.33 | *** join/#edev c00kiemon5ter (~c00kiemon@ppp-2-84-174-32.home.otenet.gr) |
| 14:09.53 | *** join/#edev Guest58979 (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 14:29.21 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 14:33.51 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 14:35.41 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 14:36.31 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 15:37.06 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 15:47.42 | *** join/#edev martyone (~martyone@ip-4-23.hlucinnet.cz) |
| 16:32.12 | *** join/#edev ffio_ (~fire@unaffiliated/security) |
| 16:42.39 | *** join/#edev landley (~landley@cpe-173-174-120-163.austin.res.rr.com) |
| 16:46.33 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 18:14.10 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 18:47.07 | *** join/#edev Umeaboy (~Umeaboy@213-21-78-12.customer.t3.se) |
| 18:55.18 | *** join/#edev TheSeven (~quassel@rockbox/developer/TheSeven) |
| 18:55.47 | *** join/#edev bsdfox (~Bob@unaffiliated/bsdfox) |
| 19:05.40 | slashbeast | landley: ping |
| 19:06.00 | slashbeast | I have weird thing, after I plug pendrive kernel does tells me in dmesg about sdb but nothing is added to /dev |
| 19:06.03 | slashbeast | wtf? |
| 19:07.29 | slashbeast | devtmpfs does not create this node either. |
| 19:17.54 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 19:31.44 | *** join/#edev SpeedEvil (~quassel@tor/regular/SpeedEvil) |
| 20:26.33 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 20:45.36 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 20:46.54 | landley | slashbeast: pong |
| 20:47.30 | landley | sounds like usb device scanning didn't quite finish. |
| 20:47.37 | landley | It knows it's a USB device but the driver didn't bind. |
| 20:54.32 | *** join/#edev damkerngt (~user@171.6.193.93) |
| 20:56.51 | *** join/#edev Omegamoon (~egoe@D97A303D.cm-3-3a.dynamic.ziggo.nl) |
| 20:58.52 | *** part/#edev Omegamoon (~egoe@D97A303D.cm-3-3a.dynamic.ziggo.nl) |
| 21:01.24 | slashbeast | landley: there was no 'scsi storage attaching' |
| 21:01.31 | slashbeast | but the pendive is working in xbox. |
| 21:01.34 | slashbeast | really really odd |
| 21:01.54 | landley | Was that what the ping was about? |
| 21:03.50 | slashbeast | nah, ping was more about how's your nbd-server code? |
| 21:03.50 | slashbeast | ;p |
| 21:03.55 | *** join/#edev djerome (~djerome@ip68-98-228-41.ph.ph.cox.net) |
| 21:09.55 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 21:17.57 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 21:33.44 | *** join/#edev amarsman (~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl) |
| 21:47.17 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 21:53.31 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 21:53.32 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 22:03.12 | slashbeast | 1st |
| 22:03.14 | slashbeast | oops |
| 22:03.16 | slashbeast | wrong channel |
| 22:22.57 | *** join/#edev Crofton|work (~balister@pool-71-171-36-155.ronkva.east.verizon.net) |
| 22:30.58 | slashbeast | landley: is qemu any good for cross compilation? |
| 22:31.10 | slashbeast | landley: I want to provide initramfs for armv6 too, but I have not even such hardware. |
| 22:31.35 | landley | slashbeast: the whole point of aboriginal linux is to do native compiling under qemu. |
| 22:32.00 | landley | Also, armv6 isn't a huge jump up from armv5, the thrust of that one was SMP support. |
| 22:32.18 | slashbeast | i have no idea about arm business. |
| 22:32.26 | landley | armv4->armv5 did a 25% performance increase if you compile for the new instruction set, which is why armv5 is the modern baseline. |
| 22:32.27 | slashbeast | I need to hook up more aboriginal into my build system |
| 22:32.35 | landley | And then armv7 added more performance stuff again. |
| 22:32.39 | slashbeast | I am not even sure if all the libs and apps I build there will work with arm |
| 22:32.46 | landley | But armv6 was mailing adding SMP capability. |
| 22:32.48 | slashbeast | I have feeling that something support only x86 |
| 22:32.54 | landley | (This is oversimplifying a bit, of course...) |
| 22:33.09 | slashbeast | does armv5 code boots on v6 devices, say raspbpi? |
| 22:33.18 | landley | armv4 is basically "the 486 of arm". |
| 22:33.25 | landley | armv3 was the 386 of arm but it's obsolete and nobody cares anymore. |
| 22:33.29 | landley | armv5 was the 586 of arm. |
| 22:33.47 | landley | So armv4 code runs on armv5 just fine. It's just 25% slower than compiling for the newer instruction set. |
| 22:33.52 | landley | (Which means 25% worse battery life.) |
| 22:34.14 | landley | armv5 works fine on armv6. |
| 22:34.16 | landley | armv7 won't. |
| 22:34.40 | landley | There were armv2 and armv1, which correspond fairly well to the 286 and 8086 respectively. |
| 22:34.46 | landley | (26 bit addressing mode. In brief, avoid.) |
| 22:35.45 | landley | As dalias said on #musl, the arm "EABI" calling convention (more or less different register layout for making syscalls) was designed for armv4t. |
| 22:35.54 | landley | t is the "thumb" extension. It's a bit like mmx, only not really. |
| 22:36.17 | landley | (It's an 8 bit instruction set designed for letting you write really small code. But it was slow, and couldn't do kernel mode stuff.) |
| 22:37.03 | landley | they eventually did a "thumb 2" that fixed most of the speed stuff and filled out the kernel side things so you actually _can_ compile a whole system (kernel too) in thumb2 instructions. |
| 22:37.23 | landley | There's some "arm M" mutant thing that _just_ does thumb 2 instructions, not conventional arm instruction set. |
| 22:37.29 | landley | But it's not really arm and didn't take off much. |
| 22:37.53 | slashbeast | I really need to dig into arm |
| 22:37.55 | landley | Anyway, thumb instructions were originally introduced as an extension to armv4. They're bundled standard with armv5. |
| 22:37.58 | slashbeast | and mips |
| 22:37.59 | slashbeast | and powerpc |
| 22:38.09 | landley | So armv4t (armv4 with thumb) is what EABI was designed for. |
| 22:38.11 | slashbeast | mips64 and ppc64 are pretty awesome |
| 22:38.13 | slashbeast | we have them at work |
| 22:38.35 | landley | The older OABI stuff is essentially obsolete now, but you can't do EABI on an armv4 that _doesn't_ have thumb instructions. (And there are still a few around.) |
| 22:38.59 | landley | Dalias was proposing a modifcation to EABI that could work on armv4. |
| 22:39.19 | landley | But it would require gcc to emit different function calling sequences... |
| 22:39.43 | landley | (There's a thumb instruction in EABI function calls, hence the need for thumb instructions.) |
| 22:40.11 | landley | slashbeast: x86 has the best price to performance ratio. That was always its schtick. |
| 22:40.21 | landley | Arm has the best power consumption to performance ratio. That was _its_ schtick. |
| 22:40.32 | landley | Once people switched to battery powered devices, arm cleaned x86's clock. |
| 22:40.45 | landley | But if you're plugged into wall current, intel is still the way to go. |
| 22:41.02 | slashbeast | yeah, we run mips and ppc on LTE base stations. |
| 22:41.03 | landley | Arm's been slowly improving its absolute performance ever since, and x86 has been trying to get more power efficient. |
| 22:41.06 | landley | But each still has its niche. |
| 22:41.11 | slashbeast | all our builders are x86_64 however. |
| 22:41.25 | landley | mips used to be the main competitor to arm, until the company behind it did a really STUPID intellectual property thing. |
| 22:42.03 | slashbeast | from what I was told now we use multiple quad core mips64 in base stations |
| 22:42.14 | slashbeast | also they told me mips64 is by far more powerful |
| 22:43.51 | slashbeast | landley: whats the property thing? |
| 22:44.00 | slashbeast | license for hardware? |
| 22:44.05 | landley | slashbeast: http://landley.net/notes-2009.html#14-12-2009 |
| 22:45.14 | landley | Basically mips shut down a clone by patent trolling and their customers abandoned them. Took a decade to recover. |
| 22:45.34 | landley | That's why they weren't even in the running for Android. |
| 22:45.45 | landley | And why game consoles went powerpc (even the ones that were originally mips). |
| 22:46.37 | landley | ppc was an IBM/motorola/apple joint venture, but motorola and apple have abandoned it and IBM is dying fast. |
| 22:47.12 | landley | It's been unloaded on power.org but I dunno of anybody actually pushing that. Somebody here might. |
| 22:48.05 | landley | slashbeast: you might like http://landley.net/aboriginal/architectures.html |
| 22:48.09 | landley | I keep meaning to finish that... |
| 22:48.43 | slashbeast | gonna read it in the morning |
| 22:48.56 | slashbeast | I am pretty tired, had working weekend. |
| 22:49.16 | slashbeast | CI failed and I was the only SCM today avaiable. |
| 22:49.24 | landley | That should give you enough background to understand wikipedia's opinion of stuff. Some of which is even accurate. |
| 22:49.33 | landley | Ouch. |
| 22:50.04 | slashbeast | and there was two software releases together so it had to be fixed asap. |
| 22:50.18 | slashbeast | whatsoever, jenkins can be impossibru slow, regardless of what hardware you have |
| 22:50.26 | slashbeast | and the more slaves you add the slower it gets. |
| 22:51.50 | slashbeast | also, seems like gcc fails hard with -relaxed on mipx. |
| 22:52.11 | slashbeast | segfaults everywhere |
| 22:52.36 | slashbeast | where on x86 and ppc you can use relax flag to linker, get smaller binary and everything works |
| 23:35.31 | MonMotha | landley: Cortex-M, which only does thumb2, is quite popular |
| 23:47.58 | MonMotha | (note that it also lacks an MMU and hence cannot run Linux or similar full OSes) |