| 00:04.51 | *** join/#edev albech (n=thomas@119.42.78.105) |
| 00:26.17 | *** join/#edev albech (n=thomas@119.42.77.198) |
| 00:57.01 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 01:01.00 | *** join/#edev sunrunner20| (n=jamesdoe@pool-72-64-102-151.dllstx.fios.verizon.net) |
| 01:24.04 | *** join/#edev roxfan (n=dunno@235.167-244-81.adsl-dyn.isp.belgacom.be) |
| 01:28.16 | *** join/#edev agaffney (n=agaffney@gentoo/developer/agaffney) |
| 02:10.19 | ds2 | anyone heard of malloc issues with uClibc 0.9.27 (ancient)? |
| 02:28.45 | *** join/#edev roxfan (n=dunno@235.167-244-81.adsl-dyn.isp.belgacom.be) |
| 02:28.46 | *** join/#edev L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) |
| 02:28.46 | *** join/#edev mgsnr (i=ydhy6kkd@cpe-65-24-173-154.columbus.res.rr.com) [NETSPLIT VICTIM] |
| 02:28.46 | *** join/#edev MonMotha (n=monmotha@72.86.127.225) [NETSPLIT VICTIM] |
| 02:28.46 | *** join/#edev cjameshuff (n=cjameshu@pool-71-97-181-172.aubnin.dsl-w.verizon.net) [NETSPLIT VICTIM] |
| 02:30.47 | solar | ds2: oh yeah |
| 02:31.08 | solar | malloc returns null often kicks ppl in the rear |
| 02:40.26 | MonMotha | malloc is permitted to return null |
| 02:40.32 | MonMotha | just that nobody ever seems to check for it |
| 02:43.38 | solar | indeed and many people have come to expect glibc behaviors of malloc(0) returning a live ptr |
| 02:44.06 | solar | which is why it's an option now probably due to the sheer number of things that misbehave |
| 02:44.57 | MonMotha | malloc(0) returns a valid ptr on glibc? |
| 02:45.00 | MonMotha | I'd argue THAT'S broken |
| 02:45.34 | MonMotha | though I guess the docs allow it |
| 02:47.08 | ds2 | I am getting some weird behavior on a no MMU system at free() actually |
| 02:47.13 | solar | feel free to argue it with drepper. |
| 02:47.17 | solar | he wont listen |
| 02:47.18 | ds2 | trying to see if there is an obvious uClibc bug or not |
| 02:47.44 | MonMotha | how large is the allocated chunk of heap you get from malloc(0)? |
| 02:47.51 | solar | 1 |
| 02:47.55 | MonMotha | ok, that's dumb |
| 02:48.01 | ds2 | so you can write to that address? |
| 02:48.08 | MonMotha | and people actually call malloc(0) and use the result? |
| 02:48.21 | solar | let me check on the result |
| 02:48.33 | ds2 | heh... so I can run out of memory by doing while(1) malloc(0); in glibc? |
| 02:48.37 | ds2 | Hmmmm }:-) |
| 02:52.36 | solar | http://rafb.net/p/DPp0qT84.html (yes) |
| 02:52.45 | solar | returns 1 |
| 02:52.55 | MonMotha | ds2: yes, you definitely can |
| 02:53.48 | MonMotha | solar: even worse, malloc always returns a pointer suitably aligned for any access, so each call of malloc(0) actually wastes 4 or 8 bytes, depending on your arch |
| 02:53.54 | MonMotha | or possibly larger, on some archs |
| 02:54.30 | MonMotha | sizeof((void *)x) will always return 1, though |
| 02:55.10 | MonMotha | er sizeof(*(void *)x) |
| 02:59.00 | solar | hrmm you are right |
| 03:00.36 | MonMotha | remember that, in C, types are entirely a compile-time thing |
| 03:01.07 | MonMotha | which is why you can generally typecast a pointer for anything to a pointer for anything else |
| 03:01.09 | solar | sizeof(*ptr) should point at the value of the ptr vs the void type |
| 03:01.25 | MonMotha | the resulting access may be unaligned and therefore break at run time, but the code is otherwise "valid" |
| 03:01.42 | MonMotha | the sizeof operator is pretty dumb |
| 03:01.58 | MonMotha | (as in not smart, not "don't use it") |
| 03:13.30 | *** join/#edev redblue (i=star@ppp122.108-253-207.mtl.mt.videotron.ca) |
| 04:34.07 | *** join/#edev DrZimmerman (n=theo@77-56-240-146.dclient.hispeed.ch) |
| 04:45.05 | *** join/#edev onnoval (n=sam@123.252.146.52) |
| 04:46.52 | *** join/#edev mbuf (n=mbuf@61.16.248.242) |
| 05:17.02 | *** join/#edev harpal (n=Harpal@59.162.116.80) |
| 05:33.22 | *** join/#edev onnoval (n=sam@123.252.146.52) |
| 06:08.59 | *** join/#edev brolin (n=brolin@190.157.13.75) |
| 06:15.41 | *** join/#edev HcE^ (i=egtvedt@cassarossa.samfundet.no) |
| 06:19.42 | *** join/#edev onnoval (n=sam@123.252.146.52) |
| 06:56.59 | *** join/#edev sleipnir (n=Sleipnir@p4FDD57E2.dip.t-dialin.net) |
| 07:08.21 | *** join/#edev lyakh (n=lyakh@p57BD2955.dip0.t-ipconnect.de) |
| 07:26.59 | *** join/#edev hw (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 07:44.35 | *** join/#edev albech (n=thomas@119.42.77.198) |
| 08:11.10 | *** join/#edev pytey (n=pytey@84.233.192.144) |
| 09:50.57 | *** join/#edev JoeLlama (n=snork@206.169.63.10) |
| 09:58.09 | *** join/#edev methril|work (n=Methril@213.27.233.98) |
| 09:58.47 | methril|work | yo |
| 10:00.55 | *** join/#edev florian_kc (n=fuchs@port-217-146-132-69.static.qsc.de) |
| 10:06.52 | florian | good morning |
| 10:25.31 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 10:32.38 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 10:50.44 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:06.12 | *** join/#edev like2wise (n=likewise@atwork-193.r-212.178.107.atwork.nl) |
| 11:50.44 | *** join/#edev Dufflepod (i=Dufflepo@82-42-186-240.cable.ubr10.live.blueyonder.co.uk) |
| 11:53.30 | wmat | morning |
| 11:59.36 | Dufflepod | morning |
| 12:12.19 | *** join/#edev onnoval (n=sam@123.252.146.52) |
| 13:02.33 | *** join/#edev pytey (n=pytey@84.233.192.144) |
| 13:19.12 | *** join/#edev pytey (n=pytey@84.233.192.144) |
| 13:28.33 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 13:28.33 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:52.02 | *** join/#edev samrobb (n=samrobb@eng.arriad.com) |
| 14:00.44 | *** join/#edev adyer1 (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 14:08.21 | *** join/#edev CosmicPenguin (n=nobody@66-162-99-237.static.twtelecom.net) |
| 14:17.33 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 14:23.22 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 14:25.38 | *** mode/#edev [+o prpplague] by ChanServ |
| 14:53.24 | prpplague | ~seen landley |
| 14:53.51 | purl | landley <n=landley@cpe-70-116-30-223.austin.res.rr.com> was last seen on IRC in channel #uclibc, 6d 14h 10m 55s ago, saying: 'I'm told if you replace the missing files it sometimes works for some platforms, but testing?'. |
| 14:53.51 | solar | not in a few days |
| 14:57.32 | prpplague | solar: hey bud, whats cookin? |
| 15:00.11 | *** join/#edev frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net) [NETSPLIT VICTIM] |
| 15:00.30 | florian | hey prpplague |
| 15:00.39 | prpplague | florian: greetings earthling |
| 15:01.34 | Dufflepod | Can anyone help with a GNU assembler ARM question? |
| 15:02.49 | Dufflepod | Target is a Samsung S3C2410, ARM920T core. Assembler chokes on ADR PC, 0x30000A78 |
| 15:03.21 | Dufflepod | But if I hard code the opcode, 0xE28FF203, all is well. What assembler switch am I missing? |
| 15:03.39 | prpplague | Dufflepod: that should a good address in the sdram section |
| 15:04.04 | Dufflepod | It is, SDRAM base is in BANK6 @ 0x30000000 |
| 15:04.34 | prpplague | Dufflepod: just out of curiosity, why are using assembly? this part of a bootloader? |
| 15:04.53 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 15:04.58 | Dufflepod | Yep - it's the reset code, HW setup & copy flash to RAM. |
| 15:05.10 | kergoth | morning |
| 15:05.15 | prpplague | kergoth: greetings |
| 15:05.42 | prpplague | Dufflepod: is there a particular reason you are re-inventing the wheel? |
| 15:05.48 | *** join/#edev like2wise (n=likewise@atwork-193.r-212.178.107.atwork.nl) |
| 15:06.07 | florian | hi kergoth |
| 15:07.10 | Dufflepod | lol - it's the bootloader from an internet radio. Read it out with JTAG and want to embed some flash routines in the spare space. Just tinkering basically. |
| 15:08.38 | Dufflepod | I've tried ARM specific switches for the assember controlling the program counter size, -mapcs-32 and -mapcs-26 but they didn't help. |
| 15:09.11 | Dufflepod | It's not exactly a show-stopper but it is pissing me off a bit not knowing what's wrong. |
| 15:10.41 | prpplague | Dufflepod: ahh |
| 15:10.50 | Dufflepod | :-) |
| 15:10.58 | prpplague | Dufflepod: might try replacing it with Apex, much easier to work with and easier to code |
| 15:13.08 | Dufflepod | It's not a problem working in assembler, I just can't get a handle on why GNU 'as' wont accept that instruction. It's more of a tools question. |
| 15:17.18 | prpplague | Dufflepod: which net radio are you using? |
| 15:17.33 | MonMotha | Dufflepod: are you specifying the architecture to GNU 'as'? It may default to an ARM arch that doesn't have that instruction |
| 15:17.50 | *** join/#edev like2wise_ (n=likewise@atwork-193.r-212.178.107.atwork.nl) |
| 15:18.12 | Dufflepod | An IR100, or that's what they call it in th UK. It has a baracuda processor board in it that does all the work. |
| 15:18.47 | Dufflepod | MonMotha: Yes, CPU is specified as arm920t. |
| 15:19.14 | prpplague | Dufflepod: ahh yea that's pb_ 's design |
| 15:19.26 | Dufflepod | lol |
| 15:19.52 | prpplague | i actually have a couple of those boards around here somewhere |
| 15:20.45 | Dufflepod | I bought two radios cheap from eBay just to tart around with. Had them about a year and mess about with them every so often. |
| 15:22.58 | Dufflepod | It takes about 20 hours to reflash using JTAG/parallel port from the PC, so I wanted to stick some flash routines in the spare apce in the boot sector. Just something to do really. |
| 15:23.52 | Dufflepod | [ "space", iffy typing ] |
| 15:25.00 | MonMotha | yeesh, that's really slow JTAG |
| 15:25.16 | MonMotha | that sounds like attempting to dump the whole root filesystem to a tuxscreen using the old jflash stuf |
| 15:26.10 | prpplague | Dufflepod: jeeze are you reflashing the entire device flash via jtag? |
| 15:26.18 | Dufflepod | Yep :-) |
| 15:26.32 | Dufflepod | You've got to laugh haven't you. :-) |
| 15:27.11 | *** join/#edev flavioribeiro (n=avaty@189.71.66.144) |
| 15:27.20 | prpplague | Dufflepod: doesn't sound too productive |
| 15:27.21 | Dufflepod | Only tried it once to prove the JTAG code was working OK. And believe me, once was enough. |
| 15:28.07 | prpplague | pb_ probably can you some more info on hacking that board |
| 15:28.29 | MonMotha | yeah, people learned a while ago that if you want to program in more than a small bootloader, you really want to have hardware JTAG acceleration rather than bit-banging it off the pport |
| 15:28.53 | Dufflepod | prpplagye: Needless to say I would owe you many, many beers if you could get me some board info. |
| 15:30.26 | Dufflepod | There's a hobbyists group for this radio in google groups, and people with minimum skills keep bricking their boards, and aren't confident enough with asoldering iron to wire up the JTAG. Hence my idea. |
| 15:31.11 | Dufflepod | i.e., serve a flash image over the USB and blow it straight in. Far less pain. |
| 15:31.14 | prpplague | checks to see if he still has a datasheet for the baracude board |
| 15:32.46 | prpplague | yea i still have a datasheet for it, not sure if i can release it though |
| 15:32.52 | prpplague | i'll check with pb_ |
| 15:32.57 | Dufflepod | Good man. :-) |
| 15:34.04 | Dufflepod | Knowing me, I'll probably get fed up with it soon and shelve it for another few months. |
| 15:34.54 | *** join/#edev albech (n=thomas@119.42.77.198) |
| 15:35.54 | *** join/#edev like2wise (n=likewise@atwork-193.r-212.178.107.atwork.nl) |
| 16:04.54 | solar | prpplague: hey bud. I jumped in the shower and then took off for work. |
| 16:05.15 | solar | feels like I've spent the last few days researching phone stacks for linux. It's in one sad state. |
| 16:05.40 | florian | shares this opinion |
| 16:05.41 | solar | as fso-framework is about the only thing that really exists. And they put python directly on the embedded device. |
| 16:05.51 | prpplague | solar: imho, user land for small gui devices running linux is generally in a sad state |
| 16:05.52 | solar | on the device $%^ |
| 16:06.30 | florian | prpplague: I hope you have a nice new job now where you get paid to help fixing this! ;) |
| 16:06.44 | prpplague | florian: we will see |
| 16:06.56 | solar | oh yeah. Whats going on your world? |
| 16:07.03 | prpplague | florian: i've heard a few rumors at AML that there might be a change in management |
| 16:07.13 | prpplague | solar: just job hunting |
| 16:07.18 | solar | you have been MIA for a bit.. |
| 16:07.22 | prpplague | solar: trying to finish up QA stuff for the 8050 |
| 16:07.47 | prpplague | solar: yea, got really frustrated and depressed over all the crap at AML, had to just get away from it all for a bit |
| 16:08.15 | florian | still ants to see one of these running |
| 16:08.29 | MonMotha | prpplague: imho, userspace on Linux is generally in a sad state |
| 16:08.29 | florian | s/ants/wants |
| 16:08.47 | prpplague | florian: one of the 8050's ? |
| 16:08.56 | florian | prpplague: yes.. |
| 16:09.07 | prpplague | MonMotha: pc desktop is in better shape than the mobile/embedded devices |
| 16:09.31 | prpplague | i still could use some good oe and/or generic distro work for the 8050 |
| 16:10.19 | solar | I've been keeping my 8050 gpe repo up2date :) |
| 16:10.22 | prpplague | now that we've gone into production, i should be able get about 10 or 15 units for people to dev with |
| 16:10.34 | prpplague | solar: ahh dandy |
| 16:10.51 | florian | prpplague: oh |
| 16:12.06 | prpplague | florian: the kernel stuff is pretty rock solid at this stage, its the gui stuff that is lacking |
| 16:12.16 | prpplague | florian: i'm using an old gpe build for oe |
| 16:12.28 | prpplague | hrw did a bunch of it for me |
| 16:13.00 | solar | still with the mixed openmoko stuff on there? |
| 16:13.30 | prpplague | naw, i ditched the openmoko stuff, its pretty generic angstrom build with gpe |
| 16:14.05 | florian | prpplague: it takes a while to find out that just having a device running is different from making it a real produce. a well adapted stack of userspace software is a lot of work. |
| 16:14.42 | prpplague | florian: yea, fortunately most of the people that purchase our stuff write their own stuff |
| 16:15.02 | MonMotha | prpplague: that is true, but even the PC/desktop is getting kinda sorry, and that stuff is slowly encroaching on the server world, too |
| 16:15.07 | prpplague | florian: but for us to get a wider market, AML really needs a decent gui for basic apps |
| 16:15.12 | solar | vendors love it. It keeps the $$ flowing |
| 16:15.16 | florian | prpplague: right... but a solid base and a well documented environment would be beneficial for these customers too |
| 16:15.34 | prpplague | florian: indeed |
| 16:15.55 | prpplague | MonMotha: btw, you found any work? |
| 16:16.20 | florian | has a customer that insists of calling executables like fswebcam and amixer instead of using the APIs |
| 16:16.24 | MonMotha | prpplague: kinda. It requires relocation to an area with substantially higher cost of living (and a much, much longer commute), so I'm still kinda weighing it. |
| 16:16.59 | MonMotha | seems like a cool place to work, though |
| 16:17.25 | prpplague | ahh |
| 16:18.19 | MonMotha | relocation would also of course involve selling my house, and now's an absolutely wonderful time to attempt that... |
| 16:18.47 | prpplague | yea, the think i wish would happen is we send out some freebie units to some folks who are interested in doing linux dev commercially for the 8050, people we can send our customers to for custom work |
| 16:19.41 | MonMotha | hey, if you need a company to do Linux dev work for you, I know of one :) |
| 16:19.56 | florian | too |
| 16:21.32 | prpplague | the work wouldn't be directly for AML, it would be with the end user/customer |
| 16:23.00 | prpplague | our #1 request is to have our handhelds talk to quickbooks |
| 16:23.31 | prpplague | a generic x based terminal app that would talk to quickbooks would be one killer app |
| 16:23.55 | chouimat|work | wanders in |
| 16:24.10 | florian | hi chouimat|away |
| 16:25.00 | MonMotha | hum, I guess I should mail my tax return |
| 16:25.01 | chouimat|work | is looking at a fun day ... jtag :( |
| 16:25.15 | chouimat|work | hey prpplague |
| 16:25.51 | prpplague | chouimat|work: hey hey |
| 16:26.04 | florian | chouimat|work: unless you try to use jtag for an avr cpu and an open source jtag application jtag usually is not too bad ;) |
| 16:28.38 | chouimat|work | florian: I have a development prototype of the sheevaplug ... where the jtag is that standard 20pin header so I'm trying to figure out to get it working with the flyswatter and openocd ... it's not a problem with production model with the miniusb but we sent the last one last week for a demo |
| 16:29.13 | MonMotha | florian: I take it you've attempted to battle avarice, too? |
| 16:29.19 | prpplague | chouimat|work: yea, the 20pin is basically the same as the 14pin just that every other pin os ground |
| 16:29.27 | prpplague | chouimat|work: you need pinsouts for them? |
| 16:29.45 | chouimat|work | prpplague: yup so I can make a cable |
| 16:30.16 | chouimat|work | prpplague: I'm sick lately so I made a huge mistake yesterday ... like erasing uboot |
| 16:30.20 | MonMotha | florian: I never found debuggers too useful on small micros like AVR, though. Tons of interrupts flying around and not a lot of "algorithmic" stuff that's debuggable and isn't just simulatable on a host. |
| 16:30.35 | prpplague | chouimat|work: doh |
| 16:30.52 | prpplague | chouimat|work: http://www.elinux.org/upload/e/ea/JTAGpinouts.pdf |
| 16:31.04 | prpplague | chouimat|work: that has both the 14 and 20 pin configurations for arm |
| 16:31.22 | chouimat|work | prpplague: management want us to use ubifs because some sales drone told them it was faster |
| 16:31.24 | chouimat|work | and thanks |
| 16:31.39 | MonMotha | chouimat|work: well, in many cases, the stats say that it is |
| 16:31.50 | MonMotha | when compared to JFFS2, at least |
| 16:32.03 | chouimat|work | I agree ... |
| 16:32.12 | MonMotha | also is supposed to handle NAND more sanely |
| 16:33.55 | florian | chouimat|away: ah nasty... if it doesn't know the cpu things start to become nasty. you can try urjtag too |
| 16:34.12 | adyer1 | prpplague: did you ever get the TI pickaxe/openocd/flyswatter combo working? |
| 16:34.59 | chouimat|work | rpplague how the pins works? I connect the same pins together? I never made a jtag cable |
| 16:35.10 | florian | MonMotha: i didn't manage to get that far yet. I do not have a JTAGICE so I tried the USBProg that's supposed to be compatible... but does not work at all. |
| 16:35.49 | MonMotha | florian: the 3rd-party AVR JTAG devices only work on really old stuff |
| 16:36.15 | MonMotha | they're based on the original JTAGICE design and either run a ripped copy of the firmware off said device or some hacked up somewhat-compatible thing |
| 16:36.22 | MonMotha | you need a JTAGICE mk2 |
| 16:36.26 | prpplague | adyer1: kees finally got it done, the code is now in the openocd repo |
| 16:36.29 | MonMotha | or one of their new Nexus things, I guess |
| 16:36.40 | prpplague | adyer1: they just started adding th cortex-a8 debug support in |
| 16:36.50 | MonMotha | I have to say that the JTAGICE mk2, while not overly cheap (about $300), does seem very fast, and it works |
| 16:36.57 | MonMotha | avarice, on the other hand, can be a little iffy |
| 16:37.02 | adyer1 | prpplague: and that was with OMAP3530 right? Anybody try with the one in a DaVinci? |
| 16:37.02 | prpplague | adyer1: TCT is getting ready to release the Beagle PuppE daughter board |
| 16:37.03 | MonMotha | too bad avr studio isn't opensource |
| 16:37.26 | prpplague | adyer1: i have a dm355 board, but just haven't had time to test it |
| 16:37.31 | florian | MonMotha: the USBProg has a firmware that emulates the mkII (not using the original one) but I didn't even manage to get it recognized |
| 16:37.45 | chouimat|work | PuppE ? |
| 16:37.49 | prpplague | adyer1: it isn't such a big deal with the davince since the davinci stuff has a default TAP config |
| 16:37.52 | MonMotha | florian: somebody finally reverse engineered Atmel's JTAG debug protocol? |
| 16:38.01 | MonMotha | it's only a matter of time, but I hadn't seen it done, yet |
| 16:38.11 | florian | MonMotha: a part of it at least |
| 16:38.36 | MonMotha | or does that firmware emulate the PC side protocol of the mk2, but not the device side? |
| 16:38.36 | prpplague | chouimat|work: daughter board with the micrell 10/100baseT, 2nd sd/mmc slot, 2nd uart, battery backed rtc |
| 16:38.38 | MonMotha | the PC side protocol of the mk2 is pretty fully documented |
| 16:38.47 | chouimat|work | prpplague: this is interesting :) |
| 16:38.55 | prpplague | chouimat|work: $79USD |
| 16:39.02 | MonMotha | I just wish the mk2's USB wasn't so half-ass |
| 16:39.08 | MonMotha | it resets itself CONSTANTLY |
| 16:39.11 | chouimat|work | prpplague: nice |
| 16:39.49 | MonMotha | it uses some old Philips chip (now NXP, I presume), so I'm guessing it predates Atmel's foray into the land of USB |
| 16:41.06 | florian | MonMotha: I guess its the PC side, but it is supposed to support quite some debugging features |
| 16:41.59 | MonMotha | florian: what seems to have happened is that the old JTAGICE (the original model, which is ancient and doesn't support hardly any of the newer devices) didn't have the firmware lock set on it, so people read the firmware back and started to reverse engineer it to build clone devices |
| 16:42.16 | MonMotha | as one would expect, the quality of said clone devices varied highly (some were quite good, others barely work) |
| 16:42.47 | MonMotha | I wonder if your "mk2 emulation" just uses that old stuff but speaks the new PC side protocol |
| 16:42.53 | MonMotha | that might explain why it doesn't see anything |
| 16:43.19 | prpplague | i still need about half a dozen small applets for my gpe desktop |
| 16:43.28 | florian | MonMotha: I guess I'll find out. I have a quite new avr... |
| 16:43.34 | MonMotha | the JTAGICE mk2 has quite a lot of hardware in it, so I'm usually a little suspicious whenever I see cheap clones claiming to do everything it does |
| 16:43.44 | florian | prpplague: I know a company that would do this for you ;) |
| 16:43.54 | MonMotha | prpplague: I also know a company that would do this for you |
| 16:44.14 | prpplague | hehe, yea, well, problem is no $$$ |
| 16:44.34 | MonMotha | that seems a common problem these days |
| 16:44.42 | prpplague | they've already laid of all the non-essential staff, and the folks that are still here have gotten their pay cut by 10% |
| 16:45.07 | MonMotha | sounds like they're in bleed-out mode |
| 16:47.39 | mnemoc | where do people in US expects to touch the bottom and start resurrecting (economy) again? 2011? |
| 16:47.42 | mnemoc | when* |
| 16:49.33 | MonMotha | estimates at this point place the bottom somewhere late 09 to early 10 |
| 16:49.56 | MonMotha | if the present rally in stocks is a long-term thing, then that would suggest late 09 |
| 16:50.10 | MonMotha | stock market in the USA typically leads the overall economy by about 6-8 months |
| 16:50.25 | MonMotha | unemployment as a stat typically lags 2-3 months |
| 16:53.53 | chouimat|work | mnemoc: canada might be a little earlier :) |
| 16:53.57 | mnemoc | ic |
| 16:53.57 | *** join/#edev HcE^ (i=egtvedt@egtvedt.no) |
| 16:54.39 | MonMotha | depending on when the bottom actually hits, this will likely be the 2nd or 3rd longest recession on record in the USA |
| 16:54.50 | MonMotha | the "Great Depression" obviously being the doozy of all doozies |
| 16:55.00 | MonMotha | there was one in the early 80s that was also pretty bad |
| 16:55.21 | MonMotha | though I seem to recall the one in the 70s was longer, but not as "deep" |
| 16:55.59 | MonMotha | suffice to say, this one is already something of an unusual one in terms of length. Typical contractionary cycles are 8-12 months. This one's approaching 16+ at this point. |
| 16:57.28 | mnemoc | the thrash (?) of the 80s made all the banks of my country (chile) get bankrupted |
| 16:57.38 | mnemoc | no exception |
| 16:58.20 | mnemoc | fortunelly they are in better shape now |
| 16:59.06 | MonMotha | yes, the so-called "savings & loan crisis" |
| 16:59.13 | MonMotha | this feels something like deja vu |
| 16:59.33 | MonMotha | the reality is that Americans (mostly those in the US, but Canada somewhat, too) were abusing credit |
| 16:59.56 | MonMotha | it was bound to come crashing down, especially when combined with the obvious housing bubble |
| 17:00.04 | MonMotha | unfortunately, both unwound quickly and at the same time |
| 17:10.49 | CosmicPenguin | not onlywere Americans abusing credit, but the banking institutions figured out a way to make money on abused credit |
| 17:13.36 | solar | sure |
| 17:13.51 | solar | same internatioal bankers pulling strings all over the world |
| 17:21.32 | *** part/#edev wmat (n=btraynor@gromit.mixdown.ca) |
| 17:26.11 | *** join/#edev btraynor (n=btraynor@gromit.mixdown.ca) |
| 17:28.49 | *** join/#edev flavioribeiro (n=avaty@189.71.66.144) |
| 17:30.33 | *** join/#edev flavioribeiro (n=avaty@189.71.66.144) |
| 17:40.58 | *** join/#edev pytey (n=pytey@84.233.192.144) |
| 17:41.40 | *** join/#edev flavio_ (n=avaty@189.71.66.144) |
| 17:42.52 | *** join/#edev flavio_ (n=avaty@189.71.66.144) |
| 17:42.54 | *** join/#edev damunix (n=damunix@brc29-1-82-245-194-55.fbx.proxad.net) |
| 17:45.50 | MonMotha | CosmicPenguin: yes, there were some "regulatory failures" |
| 18:10.15 | prpplague | argh i hate gtk+ |
| 18:11.14 | florian | would like to use gtk right now :-/ |
| 18:23.13 | prpplague | florian: you use gtk+ much? |
| 18:23.20 | solar | umm gpe ^ |
| 18:25.00 | florian | prpplague: yes quite a lot but i'm having a kind of break. for some reason both company and home projects are mostly kernel stuff currently |
| 18:25.35 | prpplague | florian: i'm having hell getting this to properly use multiple windows |
| 18:26.20 | florian | prpplague: if you like i can take a look later, right now i have to head home |
| 18:26.29 | prpplague | florian: thanks |
| 18:26.34 | florian | bbl |
| 18:26.48 | MonMotha | prpplague: everybody who's told me much about GTK says that it sucks. Having had to use glib, I can imagine it does. |
| 18:27.14 | mnemoc | loves EFL |
| 18:27.41 | MonMotha | I've heard good things about Qt |
| 18:27.48 | MonMotha | oh, and FLTK |
| 18:28.21 | prpplague | i love fltk |
| 18:29.28 | kergoth | doesn't like it when people try to wedge OO into C |
| 18:30.16 | Dufflepod | Just had a look at the FLTK website. I haven't heard of it before but it looks damn good. |
| 18:40.40 | prpplague | hmm, now the darn radiobuttons are driving me nuts |
| 18:40.50 | prpplague | gtk+ just doesn't fit my coding style |
| 18:42.14 | mnemoc | has anyone tried vala? |
| 18:43.05 | kergoth | not yet, been meaning to |
| 18:43.25 | MonMotha | kergoth: thank you |
| 18:43.54 | MonMotha | wedging OO into C tends to end badly |
| 18:43.57 | MonMotha | witness C++ :) |
| 18:44.06 | kergoth | indeed |
| 18:44.52 | chouimat|work | ARRGGGG |
| 18:46.04 | mnemoc | vala seems to be a very nice alternative when you already have glib in the system |
| 18:46.57 | MonMotha | most of the nastiness of gtk seems to stem from glib, though |
| 18:48.19 | mnemoc | but when you are already bound to glib/gtk finding projects relying in apr is like a shoot in the belly |
| 18:49.44 | MonMotha | as sad as it is, the C#/.NET pair seems to be the best I've found for general "application" development |
| 18:49.54 | MonMotha | as in things that directly interact with users, not "servers" |
| 18:53.00 | kergoth | i've been quite impressed with the CLR platform, i like how easy it is for one .net language to use code from another. and C# seems pretty nice as a language |
| 18:53.03 | kergoth | still pretty new to them though |
| 18:53.21 | prpplague | bangs head on desk |
| 19:01.40 | *** join/#edev JoeLlama (n=snork@206.169.63.10) |
| 19:05.56 | *** join/#edev dijenerate (n=dijenera@65.48.165.51) |
| 19:14.46 | *** join/#edev damunix (n=damunix@brc29-1-82-245-194-55.fbx.proxad.net) |
| 19:27.10 | *** join/#edev edcba_ (n=edcba@82.67.199.204) |
| 19:32.34 | MonMotha | kergoth: yeah, they are newcomers, but the common libraries are some of the best I've seen so far in a "major framework" like that, and syntax of C# is, for the most part, not horrible, and the RAD tools are usable |
| 19:32.56 | MonMotha | if you could build native binaries using all that stuff, I might actually take the pill |
| 19:33.15 | MonMotha | unfortunately, it only targets the CLR VM |
| 19:34.43 | kergoth | yeah.. that is unfortunate, the startup time in particular is pretty hefty, downside for embedded |
| 19:35.39 | kergoth | http://lambda-the-ultimate.org/node/3238 looks somewhat interesting |
| 19:39.27 | MonMotha | kergoth: I don't think it's startup of the VM, but rather just loading all the libraries and such |
| 19:39.45 | MonMotha | that may be "fixable" using XIP techniques or but making things smaller ("trim the fat") |
| 19:39.52 | MonMotha | s/but/by/ |
| 19:40.51 | kergoth | yeah, true. i know mono makes it particularly easy to trim out bits of the libraries. haven't done it myself yet though |
| 19:41.05 | kergoth | cbrake was playing with mono on an arm board, it was like 4-5 second startup.. ow |
| 19:43.22 | MonMotha | that is kinda ouchy |
| 19:43.28 | cbrake | mnemoc: I like Vala a lot -- seems to be very well done |
| 19:43.31 | MonMotha | possible to precache some stuff during startup activities? |
| 19:43.48 | MonMotha | also, mono wouldn't be able to benefit from Jazelle |
| 19:44.08 | MonMotha | I think if you're going to use one of those "heavy" stacks on embedded ARM, you probably have to just go with Java |
| 19:44.38 | kergoth | mono does have the ability to do the JIT stuff ahead of time. they had to do it for some platforms that don't allow the dynamic stuff |
| 19:44.39 | cbrake | MonMotha: mono actually runs quite well on ARM |
| 19:44.52 | MonMotha | cbrake: really? hum... |
| 19:45.01 | MonMotha | easy translation from the VM to native? |
| 19:45.05 | mnemoc | .oO( mono on ARM? )o |
| 19:45.32 | MonMotha | I'm still not sure I like the idea of running a VM on my embedded devices, but it's what all the big application dev stuff targets |
| 19:46.07 | kergoth | MonMotha: http://www.mono-project.com/AOT |
| 19:46.12 | kergoth | i'm not sure how much benefit you'd get from it though |
| 19:46.29 | kergoth | really needs to pick up a cheap arm board, doesn't have any embedded hardware handy anymore |
| 19:46.35 | mnemoc | that's what makes vala sexy |
| 19:46.42 | mnemoc | C# without VM |
| 19:46.53 | mnemoc | well... C#-alike |
| 19:47.00 | prpplague | what i hate about glade is unlike fltk's fluid, you can't easily edit the generated code |
| 19:47.22 | MonMotha | kergoth: ah, I didn't know they supported that |
| 19:47.37 | CosmicPenguin | oh |
| 19:47.42 | kergoth | iirc, D is a pretty nice language, i might consider messing with it if i wanted to avoid a VM... been a while since i've looked at it though |
| 19:47.45 | kergoth | isn't sure of the status |
| 19:47.48 | CosmicPenguin | I was going to say - who in their right mind was pro-FLTK, but it was prpplague... |
| 19:47.50 | CosmicPenguin | I should have figured |
| 19:49.14 | prpplague | hehe |
| 19:50.40 | kergoth | wonders how much AOT would reduce the arm startup time |
| 19:51.03 | cbrake | prpplague: if you use GTK+/glade, then stick with XML files + libglade -- don't bother with generated C code |
| 19:51.14 | adyer1 | CosmicPenguin: could be worse :-) someone was talking on the eCos list about how small their curses lib was when compiled ;-) |
| 19:53.07 | cbrake | is learning again why people use Vala/C# as he is in the middle of doing some C++ work ... |
| 19:53.28 | cbrake | but right tool for the right job -- I routinely use c, vala, c#, and now c++ for app dev |
| 19:53.28 | kergoth | poor cbrake |
| 19:54.00 | *** join/#edev florian (n=fuchs@f048109146.adsl.alicedsl.de) |
| 19:54.24 | kergoth | not a big fan of c++, but qt really isn't a terrible framework.. i'm still not sure how i feel about it being all about the MVC nowadays, but... |
| 19:56.02 | cbrake | kergoth: I've done the system sw on a few systems that ran qt, but never got into qt much yet. That will probably change with lgpl ... |
| 19:56.25 | solar | qt really isn't a terrible <-- just slow as dirt on anything but >600MHz |
| 19:57.14 | cbrake | solar: GTK+ is not exactly fast either on 520MHz ARM -- with openmoko, the qt env seems to perform a lot better than the GTK one |
| 19:57.44 | solar | cbrake: openmoko is poorly designed as is. |
| 19:57.55 | cbrake | solar: IC |
| 19:57.55 | solar | they have some good things about them yes. |
| 19:58.20 | solar | take it you are playing with the 2007.x stuff? |
| 19:58.54 | cbrake | solar: couple months back -- have not done much with it lately |
| 20:11.57 | *** join/#edev redblue (i=star@ppp064.108-253-207.mtl.mt.videotron.ca) |
| 20:13.42 | MonMotha | cbrake: what gets me, as a hardware guy, is how slow everything seems to be on 200-500MHz processors |
| 20:14.04 | MonMotha | my 8.6MHz XT clone wrote text files just fine, why can't my 200MHz ARM926? |
| 20:16.38 | *** join/#edev JoeLlama (n=snork@206.169.63.10) |
| 20:17.20 | cbrake | some mono blatherings: http://bec-systems.com/site/tag/mono |
| 20:17.59 | cbrake | MonMotha: yeah, I hear that. We have a 50,000 line GTK+ app with about a dozen threads, and most of the cpu time goes to GUI parts |
| 20:19.01 | cbrake | ponders grub systax to get serial console on geode board ... |
| 20:19.32 | ohsix | http://www.qprox.com/technologies/qtouch.html hot |
| 20:19.50 | solar | on a 201MHz omap1 current xorg(kdrive)-1.5.3/gtk/gpe-2.8+ it runs like a charm (cept for a few of the higher res themes) |
| 20:19.53 | MonMotha | cbrake: we had a WxGTK app. We had responsiveness issues. I ended up being the guy who ran some benchmarks. The most time was spent in glib mutex lock/unlock stuff. Never figured out why. |
| 20:20.16 | MonMotha | only thing I could come up with was that it was using some instructions that bypassed cache and therefore had to constantly wait on main memory (which shared with the LCD framebuffer) |
| 20:20.21 | solar | when we tested the qtopia suite. it looks really nice. But was nearly unusable |
| 20:20.28 | cbrake | MonMotha: that is odd -- I've never messed with WxGTK |
| 20:20.39 | MonMotha | cbrake: it didn't seem to be WxWidets, but rather GTK/glib |
| 20:20.51 | MonMotha | it had to do with creating large numbers of buttons I recall |
| 20:20.52 | cbrake | does: "kernel /boot/bzImage root=/dev/hdc1 console=tty0 console=ttyS0,115200" look right for grub? |
| 20:20.56 | MonMotha | (where "large" means 20) |
| 20:21.36 | MonMotha | interestingly, profiling it on a PC resulted in a much different view of how much CPU time each thing took. The locking completely disappeared from the radar |
| 20:21.39 | cbrake | MonMotha: yeah, GTK widgets seem to be very expensive. We have taken to just drawing much of the GUI in cario -- that seems to very fairly well |
| 20:22.31 | MonMotha | I guess now that Qt is LGPL, it would be possible to try to use Qt instead of GTK as the "backend" |
| 20:22.34 | MonMotha | beauty of WxWidgets |
| 20:25.04 | florian | From my experience the major problem with gtk are the themes - bad themes mean bad performance. |
| 20:25.13 | florian | That was one of the problems OpenMoko faced. |
| 20:28.22 | MonMotha | this was the default stuff that came with GTK |
| 20:28.28 | MonMotha | if you saw this, you'd instantly recognize it as GTK |
| 20:28.37 | florian | heh |
| 20:32.02 | MonMotha | it was just so strange to see all the time spent in locking |
| 20:32.21 | MonMotha | I wish I could remember the actual function name |
| 20:32.33 | MonMotha | I think it may have just been pthread_lock (GTK was of course using pthreads) |
| 20:35.26 | florian | Maybe that's why I usually refuse to use threads ;) |
| 20:36.37 | MonMotha | this had two threads, only one of which touched the GUI |
| 20:45.44 | cbrake | MonMotha: hmm, GTK+ does not use threads -- everything is driven by a mainloop |
| 20:46.26 | cbrake | MonMotha: so it seems that your issue is likely an application architecture issue. I don't know about WxGTK ... |
| 20:47.10 | MonMotha | cbrake: the calls to pthread_lock (or whatever it was) were definitely determined to be coming from within the bowels of glib |
| 20:48.05 | MonMotha | more interesting though was that, while on ARM the locks seemed to be an absolute bottleneck (showed up like 60% of the spots in the profile), on a PC it didn't even show up |
| 20:48.10 | cbrake | MonMotha: hmm, very strange. We'll its possible to write a complete GTK app with only one thread, so I'm not sure what is going on there |
| 20:48.35 | MonMotha | yes, I know you can do a GTK app in one thread, and near as I know, this app was basically done so. The other thread handled some communications tasks. |
| 20:48.57 | MonMotha | I wonder if "using threads" caused glib/gtk to get set up in "lock the crap out of everything to protect me" mode |
| 20:49.17 | cbrake | MonMotha: seems pretty typical -- I've done several GTK apps with lots of threads and never had any problems |
| 20:49.26 | MonMotha | but that still doesn't explain why acquiring the locks took so long, and didn't take any time at all on x86 |
| 20:49.33 | cbrake | MonMotha: agreed |
| 20:49.48 | MonMotha | like I mentioned, I came up with a plausible explanation, but never got to test it |
| 20:50.32 | ohsix | glib will use different locks based on the target, and if its lunix some of the ports dont support the fast mutex types that they use on x86 |
| 20:50.41 | MonMotha | if the lock acquisition used an instruction which caused a non-cacheable access (which may be required in the extremely rare SMP ARM situation), then it would have to hit memory, which would have had lots of latency on this system |
| 20:51.15 | MonMotha | well, glib was just calling pthread_lock |
| 20:51.21 | ohsix | peculiar |
| 20:51.41 | MonMotha | I agree |
| 20:51.53 | MonMotha | that's the only plausible explanation I could come up with, and it seems unlikely at best |
| 20:52.12 | MonMotha | I guess it would have been pthread_mutex_lock |
| 20:52.28 | ohsix | do the arm pthread runtimes use green threads or native ones? |
| 20:52.47 | MonMotha | I do not know |
| 20:52.53 | MonMotha | I mostly do hardware |
| 20:53.16 | MonMotha | It's somewhat irrelevant as I'm not even employed there anymore, but it's still an interesting question to answer |
| 20:54.29 | ohsix | ic, i do know that some times arm gets the short end of the stick on the kernel side of things, wouldn't be surprised if threads were kind of not worried about since you're usually in a speed crunch scenario anyways |
| 20:54.32 | *** join/#edev phenix (n=blabla@41.226.155.50) |
| 20:54.32 | MonMotha | sadly, anything that isn't x86 or x86-64 seems to get the short end of the stick on the kernel side |
| 20:54.35 | phenix | hi guys |
| 20:55.00 | ohsix | well the IHVs are the ones with the hardware, lots of people have x86 though :D |
| 20:56.06 | phenix | guys does sh die when no standard input available? |
| 20:58.01 | ohsix | and even then that assumes you're using a full stack of software, not sliding in one of the smaller crts or the like |
| 20:58.18 | solar | phenix: no |
| 20:58.35 | phenix | thanks solar! |
| 20:58.38 | phenix | :s |
| 20:58.50 | phenix | i have a pb :)) |
| 20:58.54 | solar | you question did not make all that much sense however ;p |
| 20:59.22 | phenix | i have a panic attnd to kill init |
| 20:59.43 | phenix | i give as args to kernel init=/bin/sh |
| 21:00.14 | phenix | but am not sure that the console drv was correctly initialised |
| 21:00.17 | solar | that should work fine. You just wont have job control |
| 21:00.45 | solar | as you are not using a {m,a,}getty |
| 21:01.20 | chouimat|work | bangs head on desk |
| 21:02.14 | phenix | solar am sorry i can understand you very well my english is not so good! |
| 21:02.17 | ohsix | there are even a lot of arm thread/lock related changes in the changelog as of may last year |
| 21:02.29 | phenix | what you mean by a{m,a} |
| 21:03.01 | solar | mgetty agetty or getty. It's how init passes you control of a tty |
| 21:03.18 | solar | they are spawned at init by /etc/inittab |
| 21:03.32 | solar | and setup usually tty[0-6] |
| 21:03.42 | solar | serial ports etc. |
| 21:03.57 | phenix | oki! |
| 21:04.23 | phenix | am using a cut down of busybox |
| 21:05.24 | solar | good deal. |
| 21:06.28 | ohsix | linuxthreads w/glibc actually seem to do exactly what you're suggesting |
| 21:07.13 | MonMotha | ohsix: locks are god-awfully slow? |
| 21:07.33 | phenix | thanks again for your help solar |
| 21:08.21 | ohsix | well, yea, but so is linuxthreads, i mean non cachable swp |
| 21:09.04 | MonMotha | it's entirely possible that this system was running linuxthreads |
| 21:09.13 | MonMotha | I didn't make the BSP |
| 21:09.40 | ohsix | ports without mmus and some others usually use uclibc, so it could be those doing silly things too |
| 21:10.48 | MonMotha | oh, this was definitely glibc, and it was full blown linux |
| 21:10.52 | MonMotha | ARM926EJ-S |
| 21:11.07 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 21:11.11 | solar | is fond of of the 926ej-s |
| 21:11.21 | MonMotha | it seems to work pretty well |
| 21:12.29 | solar | well using nptl on one now. It maybe sucks a lot less than maybe it used to. |
| 21:13.00 | MonMotha | the system worked pretty well overall, just that one issue |
| 21:13.08 | MonMotha | and if it's running linuxthreads instead of nptl, that would explain it |
| 21:17.14 | ohsix | it seemed you could use nptl with codesourcery's gcc toolchain and a changed eabi, as early as 2005, and they only pushed those changes out to the main trees fairly recently (10 months ago or so) |
| 21:17.15 | ohsix | pbrook should know everything though, if you're really keen on nailing it down :) |
| 21:21.06 | MonMotha | ohsix: well, the BSP is more than 10 months old, so that would explain it |
| 21:21.22 | MonMotha | and it's not codesourcery based |
| 21:24.06 | kergoth | anyone played with the sheevaplug? |
| 21:24.37 | florian | if i had one... ;) |
| 21:26.36 | solar | we are using one to do weekly builds for armv5tel |
| 21:27.16 | mnemoc | OT dumb question, what user space NFS server do you recommend? |
| 21:27.41 | mnemoc | actually I have only found nfs-ganesha |
| 21:31.05 | chouimat|work | likes electronics components store with stupid hours |
| 21:31.53 | chouimat|work | kergoth:I have a few around, still waiting for mine and I bricked one yesterday |
| 21:32.14 | kergoth | needs to pick up a cheap arm box to test on |
| 21:32.31 | chouimat|work | solar: I use a rd-6281 as build machine here :) |
| 21:36.56 | *** join/#edev florian (n=fuchs@f048109146.adsl.alicedsl.de) |
| 21:37.06 | *** join/#edev pytey (n=pytey@84.233.192.144) |
| 21:43.02 | solar | chouimat|away: I take it.. not the same as this http://www.canadiansilver.com/product.php?id=1876 |
| 21:47.45 | mnemoc | wth is that? |
| 21:48.09 | *** join/#edev pytey (n=pytey@84.233.192.144) |
| 21:48.58 | chouimat|work | solar: not quite ... I mean the marvell Reference Design for the 88F6281 |
| 21:49.23 | chouimat|work | this one the cpu is not event a A0 but a Z0 ... |
| 21:49.47 | kergoth | ordered a sheevaplug. finally, will have an arm machine again |
| 21:50.55 | keesj | cool i almoost pressed the buy button but didn't want to wait |
| 21:51.12 | chouimat|work | I ordered mine 2 weeks ago ... I hope they will start shipping them soon ;) |
| 21:52.45 | chouimat|work | looks at his "prototype" sheevaplug on his desk ... serial number 04 |
| 21:52.55 | solar | thinking about getting a few more. So we can offer autobuilds for uclibceabi as well and offload some of the armv4tl to a faster node. |
| 21:53.59 | chouimat|work | solar: if only qemu arm usermode supported the eabi ... |
| 21:54.28 | keesj | eabi port sf port isn't good enough? |
| 21:54.37 | solar | would not matter. |
| 21:54.46 | chouimat|work | solar: not for me |
| 21:54.48 | keesj | what kind of stuff are you building? |
| 21:55.01 | solar | qemu is even on a dual quad core with 16-32G of ram is still slower than the real hardware |
| 21:55.08 | keesj | I meam more why do you need arm for that? |
| 21:55.55 | solar | tindebox runs.. We have over 10k pkgs in our tree. |
| 21:56.10 | chouimat|work | solar: I managed to have acceptable speed by using the x86_64 crosscompiler in the emulated chroot instead of the native (arm) compiler |
| 21:56.27 | solar | of which only about ~1200 or so I've confirmed cross compile support |
| 21:59.02 | keesj | that's a lot is that Jaunty? |
| 22:03.13 | phenix | solar is the dual quad core with 16G of ram yours! ^^ ( i am using redhat 2 on a p2 400 MHZ :p) |
| 22:04.09 | chouimat|work | phenix: it's probably mine ... and it's 32GB or ram ;) |
| 22:04.38 | phenix | oh god!! |
| 22:04.56 | phenix | so nice |
| 22:05.41 | chouimat|work | phenix: too bad I don't have it at work |
| 22:07.48 | phenix | it can't be any where else in a safe at home |
| 22:07.50 | phenix | mdrr |
| 22:08.50 | MonMotha | redhat 2? |
| 22:08.59 | MonMotha | um, I think that's older than the PC... |
| 22:09.16 | MonMotha | heck, was there even a redhat 2? |
| 22:10.10 | phenix | loll MonMotha a prehistoric distribution :p |
| 22:10.39 | phenix | oups i mean fedora :p |
| 22:10.45 | phenix | ^^ |
| 22:11.07 | MonMotha | that makes a lot more sense |
| 22:11.22 | MonMotha | redhat 2, if it exists, would certainly predate my experience with Linux, which only goes back to about Slackware 3.4 |
| 22:11.47 | chouimat|work | remember slackware 1.0/1.2 |
| 22:11.51 | chouimat|work | ok time to go home |
| 22:19.45 | solar | phenix: More or less mine. I kinda have access to some pretty sick resource power. (416 spares almost exactly like the other one) |
| 22:19.46 | *** part/#edev phenix (n=blabla@41.226.155.50) |
| 22:41.14 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 22:41.46 | *** join/#edev JohnnyL (i=IHadToWr@ool-182f0b98.dyn.optonline.net) |
| 22:42.36 | JohnnyL | what are some good sensors? (like humidity, temperature, lighting) |
| 22:47.10 | g1powermac_PB | moist finger tip? |
| 22:47.13 | g1powermac_PB | ducks ;-) |
| 22:50.42 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-252-208-52.dllstx.fios.verizon.net) |
| 22:55.34 | g1powermac_PB | does anyone know if there's a chip out there that is a true hardware based random number generator? |
| 22:58.07 | MonMotha | g1powermac_PB: haven't seen a solution on a chip, though I seem to recall hearing Microchip may have one |
| 22:58.28 | g1powermac_PB | hmm |
| 22:58.32 | MonMotha | it's not too hard to rig up a zener diode (or better, if you can generate the "high voltage" for it, a schottky) and use the noise |
| 22:58.33 | g1powermac_PB | thanks, I'll take a look |
| 22:58.43 | MonMotha | you do need a 12V rail for that, though |
| 22:58.55 | g1powermac_PB | yea, I was thinking of doing that, but would rather have a verified truly random source |
| 22:58.59 | MonMotha | or something similarly high (5V isnt enough since you need an avalanche zener) |
| 22:59.12 | MonMotha | hum, like FIPS certified type stuff? |
| 22:59.40 | g1powermac_PB | not actually certified, per se, but something a bit more credible than me just wiring up some analog stuff |
| 22:59.48 | MonMotha | I know of some micros that have built-in stuff |
| 22:59.57 | MonMotha | I think NXP had some |
| 23:00.18 | g1powermac_PB | oh |
| 23:00.24 | MonMotha | and what level of credibility are you looking for? It's not too hard to show that a source is "reasonably random" |
| 23:01.34 | g1powermac_PB | well, basically if the circuit has been tested by a manufacturer, it should be enough |
| 23:01.39 | MonMotha | it's probably harder to show that it works at all across all operating conditions. Jumping from that to "hey, that's pretty darned random" isn't terribly difficult |
| 23:01.42 | g1powermac_PB | thats why I was looking for prebuilt chips |
| 23:01.44 | MonMotha | I see |
| 23:02.00 | MonMotha | I've not seen one. I've seen plenty of tricks, though |
| 23:02.12 | MonMotha | I have seen micros with built in RNGs, but no dedicated chips |
| 23:03.13 | g1powermac_PB | hmm, http://home.comcast.net/%7Eorb/index.html |
| 23:03.51 | MonMotha | that's just a micro with an outboard trick |
| 23:04.11 | g1powermac_PB | aha |
| 23:04.19 | g1powermac_PB | yea, just figured that out |
| 23:05.32 | MonMotha | from the looks of it, the zener/schottky diode trick is likely to yield much more entropy |
| 23:06.12 | MonMotha | though it'll probably cost more |
| 23:07.16 | g1powermac_PB | do you know of the specific nxp chips that have hardware rngs on them? |
| 23:07.39 | g1powermac_PB | brb |
| 23:13.03 | g1powermac_PB | back |
| 23:18.04 | MonMotha | g1powermac_PB: I do not. I just seem to recall that they had some. |
| 23:18.21 | g1powermac_PB | oh, I just found something interesting |
| 23:18.30 | MonMotha | I know the AT91SAM7X series has one, but it's not exposed. It's only used for the AES module. |
| 23:18.32 | g1powermac_PB | there's an 8051 with an RNG on it from dallas |
| 23:18.42 | MonMotha | that sounds like something Dallas would make |
| 23:19.04 | MonMotha | maybe that's what I'm remembering. 8051 sounds familiar (but then 8051 is everywhere) |
| 23:19.54 | g1powermac_PB | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3932 |
| 23:21.30 | g1powermac_PB | its doesn't look easy to get though |
| 23:26.42 | g1powermac_PB | seems like most of the chips with RNGs on them are these ultra security chips |
| 23:30.50 | g1powermac_PB | meh, guess it will prolly be easier to do my own circuit |
| 23:31.44 | g1powermac_PB | what do you think of this guys circuit? http://www.cryogenius.com/hardware/rng/ |
| 23:34.00 | MonMotha | g1powermac: I took a zener, reverse biased it (more bias current is generally better, but there are diminishing returns), AC coupled it to an op-amp input biased at halfway between ground and the + rail, allowed the gain on that amp to go to "infinity" at AC and unity at DC, then chucked that into an ADC |
| 23:34.36 | MonMotha | FFT of the analog data showed that it was pretty flat until it rolled completely off at high frequency (exceeded the usable bandwidth of the op-amp), and there was some DC roll-off too, of course |
| 23:34.57 | MonMotha | of course, chuck the ADC results into a pool and hash the bejeezus out of it |
| 23:35.44 | MonMotha | you can also use a reverse biased transistor junction like they show, but experience has shown that it doesn't work as well (though it's usually cheaper) |
| 23:36.21 | g1powermac_PB | hmm |
| 23:37.16 | MonMotha | the transistor amplifier in there probably actually has greater noise bandwidth, but will be harder to get working over all conditions |
| 23:37.37 | MonMotha | also is likely to result in more skewed output |
| 23:37.45 | MonMotha | whether or not you care is another matte |
| 23:37.53 | g1powermac_PB | do you have a schematic of the circuit you made? |
| 23:38.14 | MonMotha | nope |
| 23:38.22 | MonMotha | it was company property, so I deleted it when I got laid off |
| 23:38.23 | g1powermac_PB | has little grasp on analog circuitry |
| 23:38.26 | g1powermac_PB | ahh |
| 23:38.26 | MonMotha | couldn't have given it to you anyawy |
| 23:38.31 | g1powermac_PB | ok |
| 23:38.42 | solar | anybody a fan or using lua in a commerical product? |
| 23:38.45 | MonMotha | I don't think I had pinned down component values 100% anyway |
| 23:39.06 | g1powermac_PB | well, I'll get back to this in a little while, need to head out again |
| 23:39.09 | solar | if so please read. http://www.lua.org/bugs.html |
| 23:39.13 | g1powermac_PB | thanks for the info |
| 23:39.15 | g1powermac_PB | bbl |
| 23:39.50 | MonMotha | solar: what, it has bugs? |
| 23:40.09 | CosmicPenguin | stops the presses |
| 23:40.25 | solar | more that the type of bugs it might have and the security problems that could relate to them in commercial products. |
| 23:40.59 | CosmicPenguin | restarts the presses |
| 23:41.19 | CosmicPenguin | ponders how the term "stop the presses" will probably be a complete mystery to my daughter |
| 23:41.33 | MonMotha | CosmicPenguin: clog t3h tubez! |
| 23:42.05 | CosmicPenguin | okay, ted |