| 00:00.41 | *** join/#edev prpplague (n=prpplagu@ppp-70-244-162-142.dsl.rcsntx.swbell.net) |
| 00:00.59 | prpplague | ho ho ho |
| 00:01.04 | prpplague | merry freakin wednesday |
| 00:04.03 | g1powermac_PB | meh, that it is |
| 00:07.10 | landley | And lo, the cp -r bug with reiserfs which toybox has had for many moons is finally fixed. |
| 00:07.26 | landley | solar of gentoo was kind enough to give me a login on a fast quad processor gentoo build machine. |
| 00:07.45 | landley | It's got 16 gigabytes of ram... and a reiserfs filesystem on the home directories. :P |
| 00:07.57 | prpplague | lovely |
| 00:08.05 | landley | Turned out to be a 1 line fix since dirtree is already statting the files, but it's the principle of the thing. |
| 00:08.11 | landley | It's a _bug_ in _reiserfs_. |
| 00:08.17 | landley | Oh well. Fixed now. |
| 00:32.22 | joe_bleau | Freakin' credit card company thinks they're going to get an extra $3 out of me. |
| 00:35.08 | MonMotha | landley: I thought that filesystem was DEAD |
| 00:44.33 | landley | MonMotha: so did I. Ping solar about it, not me. :) |
| 00:44.57 | landley | I reaaaaaaly shouldn't say that. |
| 00:44.59 | landley | But I"m going to. |
| 00:45.08 | landley | Technically, it's that filesystem's wife that's dead. |
| 00:45.16 | landley | Sorry, couldn't resist. |
| 00:45.34 | landley | I'm quite aware the statement was in horrible taste. |
| 00:45.36 | landley | Nevertheless... |
| 00:51.55 | MonMotha | that doesn't mean it isn't funny |
| 00:52.22 | landley | Keating 5, reiser 3... |
| 00:52.26 | landley | Yeah, I know. |
| 00:53.14 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 00:53.14 | *** mode/#edev [+o GPSFan] by ChanServ |
| 01:00.56 | *** join/#edev JohnnyL (i=JohnnyL@ool-182ddad4.dyn.optonline.net) |
| 01:30.40 | solar | haha |
| 01:31.36 | solar | the box was installed with r3 way back in the day. it works good now and moving to ext3 has no real advantages that we need. |
| 01:31.52 | solar | make a loopback if you need other fs |
| 01:32.21 | landley | solar: actually I just put a workaround in toybox. |
| 01:32.34 | landley | It's up to the mips build as we speak. |
| 01:32.51 | solar | landley: using -j4 or -j8 ? |
| 01:33.02 | landley | -j4, why? |
| 01:33.15 | solar | make options for each core. |
| 01:33.32 | landley | I could do "sources/build-all-targets.sh --fork" which would build all targets at once. |
| 01:33.35 | solar | ie.. make -j4 |
| 01:33.41 | landley | But you said other people use the server... :) |
| 01:34.35 | solar | landley: maybe not as ideal as simply using makes own builtin feature. |
| 01:34.48 | solar | but no matter. You got the loads to a nice place. so enjoy |
| 01:35.03 | landley | Actually each individual make would be doing -j $(however many cpus there are in /proc/cpuinfo) |
| 01:35.57 | landley | I can get the load on the server way, way up. It's just not _polite_. :) |
| 01:37.11 | landley | solar: is there any way to install qemu 0.9.1 on the server? |
| 01:37.16 | solar | think I need to get that blade moved into a san enabled chassis |
| 01:38.31 | solar | landley: need sdl support enabled in qemu-softmmu ? |
| 01:38.43 | landley | Not really. I call it with -nographic. |
| 01:38.54 | landley | Emulated serial console on stdin/stdout. |
| 01:39.09 | landley | You can pipe a script into qemu and log the output via "tee" if you do that. :) |
| 01:39.13 | solar | wait a sec. |
| 01:39.19 | solar | this box already has it installed. |
| 01:39.28 | solar | sec let me give you a login to port 222 |
| 01:39.47 | landley | $ qemu |
| 01:39.47 | landley | bash: qemu: command not found |
| 01:42.06 | solar | see /msg |
| 01:46.01 | solar | will that work for you? or do you really need it in the same ROOT |
| 02:15.58 | *** join/#edev jerm^home (n=jerm7861@NW-ESR1-74-215-103-147.fuse.net) |
| 02:21.30 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 02:23.46 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 02:53.47 | *** join/#edev prpplague (n=prpplagu@ppp-70-244-162-142.dsl.rcsntx.swbell.net) |
| 03:08.32 | jerm^home | anyone have any good micro recommendations? :) |
| 03:08.45 | jerm^home | we are currently using AT91SAM9263 but it just does not have enough guts |
| 03:09.15 | jerm^home | thinking about trying the OMAP3503 but we have had issues with fab houses and BGAs below .8mm |
| 03:09.30 | prpplague | jerm^home: all depends on what kind of power you need |
| 03:10.01 | jerm^home | well, we were trying to minimize power consumption, our typical mode of operation when developing boards for our typical customer |
| 03:10.25 | jerm^home | but we have a new customer that wants a more flexible platform, which tossed us into our first embedded linux development |
| 03:11.53 | prpplague | i'm biased, but i like the s3c24xx series |
| 03:12.04 | jerm^home | In the past we've used Philips XA and LPC (ARM7) and Renesas SH3, and some random AVR parts |
| 03:12.41 | jerm^home | all our larger non battery powered jobs use PowerPC and VxWorks |
| 03:13.05 | prpplague | jerm^home: the s3c24xx is pretty power friendly and there are many many reference designs |
| 03:13.52 | jerm^home | We are really starting to see the promise of linux but just dont have the talent around to take on a porting project... |
| 03:14.02 | jerm^home | do you know about availability in low quantities |
| 03:14.04 | jerm^home | ? |
| 03:14.20 | prpplague | jerm^home: yea the s3c24xx is availabe in low qty |
| 03:14.28 | prpplague | jerm^home: what os do you normally use? |
| 03:15.00 | jerm^home | we've used CMX RTOS but recently we've mostly moved over to uCOS |
| 03:16.08 | prpplague | ahh |
| 03:16.32 | jerm^home | so Linux has been a pretty big jump for us |
| 03:17.02 | prpplague | ahh indeed |
| 03:17.05 | jerm^home | we have lots of userland Linux experts...but very little kernel experience... |
| 03:17.18 | prpplague | you are going to have some learning curve |
| 03:17.31 | prpplague | jerm^home: how did you find #edev? |
| 03:17.42 | MonMotha | jerm^home: what kind of "guts" do you need? 9263 has lots of bandwidth, but it is only an ARM926EJ-S |
| 03:18.08 | jerm^home | using OE |
| 03:18.59 | jerm^home | MonMotha: Ethernet bandwidth has been an issue. 10mbit isnt horrible, but we'd like to see more. |
| 03:19.05 | prpplague | jerm^home: some OE folks pointed you here? |
| 03:19.08 | MonMotha | jerm^home: the MAC on the 9263 is 100Mbps capable |
| 03:20.09 | MonMotha | I've been able to attain ~19-25Mbps throughput from it, and I have a layout issue that is messing with the clock on the PHY some, so that could probably be better |
| 03:20.18 | jerm^home | MonMotha: sure, but we have not been able to get there |
| 03:20.18 | MonMotha | IIRC, that was also using SSH, so probably again could be better |
| 03:20.36 | jerm^home | MonMotha: we have some memory (PSRAM) and layout issues as well |
| 03:20.42 | MonMotha | I see |
| 03:20.47 | MonMotha | those won't go away with a different micro |
| 03:21.50 | prpplague | jerm^home: this going to be in a handheld design? |
| 03:22.06 | jerm^home | its a strange R&D platform, no graphics |
| 03:22.23 | jerm^home | sensor data collection, processing, and exfil |
| 03:22.59 | MonMotha | I'm not sure why the 9263 isn't working for you, then |
| 03:23.02 | jerm^home | Has 2 ISP1761 USB 2.0 host controllers supporting 11 USB ports (with hubs) |
| 03:23.13 | jerm^home | Plus the ethernet |
| 03:23.23 | jerm^home | we made a mistake with the rootfs on SD card...I thin |
| 03:23.26 | jerm^home | I think |
| 03:23.30 | jerm^home | pretty slow... |
| 03:23.44 | MonMotha | oh, yeah, the Linux driver doesn't support 4 wire mode for SD |
| 03:24.00 | MonMotha | that's only available under NDA, so nobody has made it work in a GPL driver |
| 03:24.08 | jerm^home | 4 wire mode? |
| 03:24.17 | jerm^home | 2.6.27 has it |
| 03:24.20 | MonMotha | aka nibble mode |
| 03:24.22 | jerm^home | i'm sure |
| 03:24.23 | MonMotha | really...that's new |
| 03:24.34 | MonMotha | we're back on some ancient kernel at this point |
| 03:24.39 | jerm^home | also the Atmel libraries for bare metal development has support |
| 03:24.46 | prpplague | jerm^home: well #edev is a pretty good source for both hardware and kernel development, most people are more that willing to help, as long as we are doing 99% of your job for you |
| 03:25.07 | jerm^home | prpplague: eh? :) |
| 03:25.09 | prpplague | doh |
| 03:25.13 | jerm^home | haha |
| 03:25.15 | prpplague | s/are/are not |
| 03:25.19 | prpplague | long day |
| 03:25.21 | jerm^home | np |
| 03:25.31 | jerm^home | yeah...i've just been lurking for a while |
| 03:26.01 | MonMotha | jerm^home: well, the 9263 has a lot of on-chip bandwidth. The only other thing I can think of that is in the same realm is the i.MX stuff from Freescale, but those tend to be multimedia oriented |
| 03:26.03 | jerm^home | I am definately not the type to use the knowledge of other...too much of a know-it-all! :) |
| 03:26.15 | MonMotha | both have a crossbar switch for on-chip DMA |
| 03:26.18 | jerm^home | err...use the knowledge of others exclusively |
| 03:26.38 | MonMotha | the 9263 also has two external memory busses, though, which can help a lot, especially if you are using the LCD controller (which it sounds like you are not) |
| 03:27.00 | MonMotha | prpplague: you know if any S3C stuff has a crossbar switch? |
| 03:27.10 | MonMotha | seems like they are becoming popular these days on the SoC ARMs |
| 03:27.16 | jerm^home | MonMotha: we have the PSRAM on one EBI and the 2 USB host controllers on the other |
| 03:27.24 | prpplague | brb gotta put the yoots to bed |
| 03:27.31 | MonMotha | jerm^home: no SDRAM? |
| 03:27.43 | jerm^home | MonMotha: nope...we were concerned about energy consumption at first |
| 03:27.47 | MonMotha | I see |
| 03:28.03 | MonMotha | are you using the DMA features of the uC and USB chip? |
| 03:28.27 | MonMotha | I think it's possible to chuck the a device and some RAM on one EBI and let them DMA while the micro runs out of RAM in the other EBI or internal SRAM |
| 03:28.53 | jerm^home | that is true, each EBI and the internal is a master |
| 03:28.57 | MonMotha | then the uC has direct access to the RAM the device DMA'd in to once the bus is free, and you can either copy (with DMA) from one RAM to another or whatever |
| 03:29.24 | MonMotha | I haven't really read up on the external DMA stuff much for the 9263 as I didn't need it, but I know it has it |
| 03:30.04 | MonMotha | the ethernet frame buffer you could use the internal SRAM for, which should be plenty fast (and again DMA-able) |
| 03:30.12 | MonMotha | er ring buffer |
| 03:30.23 | jerm^home | It does, we want to use it on the external USB host controllers but getting up to speed on the DMA API in Linux has been rough for me :) |
| 03:30.29 | MonMotha | there's like 22Gbps of on-chip bandwidth on that thing. I'm surprised that isn't enough :) |
| 03:30.51 | jerm^home | MonMotha: I am in the process of moving the Ethernet structures and buffers to the internal SRAM |
| 03:30.53 | MonMotha | ah yes, the Linux DMA stuff can be complicated because it has to work on all sorts of different devices, so there's a fair bit of abstraction rom the bare metal |
| 03:31.06 | MonMotha | jerm^home: that should help, since I'm pretty sure that's all DMA |
| 03:31.16 | MonMotha | might as well take advantage of that crossbar switch :) |
| 03:31.23 | jerm^home | MonMotha: it is, I can dedicate the SRAM to the Ethernet |
| 03:31.26 | jerm^home | exactly |
| 03:31.33 | MonMotha | you can theoretically have like 6+ transfers going at once |
| 03:31.37 | MonMotha | there are actually two SRAMs on there |
| 03:31.43 | MonMotha | one is also a TCM |
| 03:31.54 | jerm^home | Is the TCM like cache? |
| 03:31.55 | MonMotha | so the uC has direct access even if all other busses are occupied |
| 03:32.26 | MonMotha | basically, the CPU can access the TCM without using the bus the CPU would normally use to access other stuff in the system |
| 03:32.52 | jerm^home | I was really suprised that the Ethernet is experiencing so many receive overrun errors. |
| 03:32.55 | MonMotha | I'm not sure if the ARM926 pipeline allows it, but that means that a memory access to the TCM and a program fetch from system RAM to the cache could both occur simultaneously |
| 03:33.10 | jerm^home | The datasheet claims the error basicaly means that the bus was not arbitrated in time. |
| 03:33.27 | MonMotha | I know there's an errata on that...make sure you're not hitting it |
| 03:33.35 | MonMotha | that chip does have a lot of rather nasty errata to be aware of |
| 03:33.38 | jerm^home | The PSRAM is pretty fast...70ns timing |
| 03:33.46 | jerm^home | Yeah, we learned that the hard way |
| 03:33.53 | jerm^home | built all our boards with A rev parts |
| 03:34.01 | MonMotha | well, but that main system RAM is also being used for program fetch and data store/load |
| 03:34.06 | jerm^home | then found out that the SD card boot was not functioning |
| 03:34.09 | MonMotha | oh, yeah, rev A doesn't support SD or NAND boot :) |
| 03:34.20 | jerm^home | haha |
| 03:34.22 | MonMotha | and rev B has another undocumented errata on the SPI controller. You have to reset it twice |
| 03:34.23 | jerm^home | yeah that really sucked |
| 03:34.44 | jerm^home | Well...good thing we are not using the SPI controller |
| 03:34.48 | MonMotha | I was fortunate enough to read the errata, so our boards have a spot for dataflash |
| 03:35.08 | jerm^home | I was not involved in the board design process so did not get a chance before they came to me |
| 03:35.55 | jerm^home | We have been fighting an issue with the static memory controller the last few weeks |
| 03:36.10 | MonMotha | what's it doing? |
| 03:36.16 | jerm^home | not really Atmel's fault but PSRAM requires CS to be released every 4 uS to refresh |
| 03:36.33 | jerm^home | in async page mode, the uC can hold the CS line low for a long time |
| 03:36.38 | MonMotha | I thought the SRAM controller had a feature to support that |
| 03:36.46 | MonMotha | I know it can handle page bursts |
| 03:37.00 | jerm^home | we looked at it with a logic analyzer, when it switches pages, it just waits longer for the data to arrive |
| 03:37.07 | jerm^home | it never deasserts CS |
| 03:37.18 | MonMotha | awesome |
| 03:37.23 | jerm^home | yeah |
| 03:37.37 | jerm^home | The PSRAM was pretty ticked off :) |
| 03:38.10 | jerm^home | I think we're ditching the PSRAM and going to SDRAM |
| 03:38.15 | jerm^home | on our next spin |
| 03:39.35 | jerm^home | boot speed has been a huge issue as well |
| 03:39.47 | jerm^home | we were hoping more MIPS would fix that problem... |
| 03:41.46 | MonMotha | that usually has more to do with bootloader, access speed to /, and number of services started at startup |
| 03:42.01 | MonMotha | if you're using OE, it likes to put a bunch of rather unnecessary stuff in there that runs at startup |
| 03:42.09 | MonMotha | like we have Avahi, for some reason |
| 03:43.29 | jerm^home | yeah, udev is good at eating up that time |
| 03:43.41 | jerm^home | bootloader is pretty quick...minimum u-boot |
| 03:43.50 | jerm^home | just inits SD, copies, and launches |
| 03:44.40 | jerm^home | definately in learning mode...i've been studying the initscripts pretty throughly the last few days |
| 03:45.27 | jerm^home | but unforunately, we have quite a few custom services that are going to be taking the place of those that we remove |
| 03:46.00 | jerm^home | is Avahi like Bonjour? |
| 03:46.04 | MonMotha | yes, it is |
| 03:46.14 | MonMotha | and there are other init methods that you might look in to |
| 03:46.19 | jerm^home | one of our devs wanted to put that on our board...I quickly vetoed |
| 03:46.29 | jerm^home | oh yeah? |
| 03:46.33 | MonMotha | you can launch multiple things at once just obeying dependencies (ala "make") |
| 03:46.41 | MonMotha | that can help if anything has time that it just spends waiting |
| 03:46.48 | MonMotha | since something else can be using those precious CPU cycles |
| 03:47.00 | jerm^home | i've seen some suggest that approach with the udev settle operation |
| 03:47.10 | MonMotha | certainly |
| 03:47.49 | jerm^home | what do you think about busybox? |
| 03:47.54 | jerm^home | our userland devs hate it |
| 03:48.43 | *** join/#edev linac (n=lin@125.77.68.62) |
| 03:49.50 | landley | Well, _I_ like busybox. :) |
| 03:49.56 | landley | But I'm biased. |
| 03:50.00 | jerm^home | I actually found an issue with udevd when it calls the busybox modprobe. For some reason udevd either does not inherit or resets the environment (particularly path). When udev calls modprobe to autoload a driver, the insmod call inside modprobe fails because it cannot find it in glib's default path... |
| 03:50.26 | jerm^home | hi landley |
| 03:50.31 | MonMotha | landley: you would... |
| 03:50.33 | jerm^home | are you a dev? :) |
| 03:50.56 | landley | jerm^home: I maintained it for about a year and a half. (1.0.1->1.2.2) |
| 03:51.04 | jerm^home | just started hanging out here so don't really know who does what around here.. |
| 03:51.09 | jerm^home | landley: awesome |
| 03:51.11 | landley | Less thrilled with some of the recent directions, but eh. Denys is smart. |
| 03:51.31 | jerm^home | I saw someone grumbling about it earlier...mentioned something about toybox? |
| 03:51.32 | landley | Have you tried mdev? |
| 03:51.40 | landley | That would be me, yes. :) |
| 03:51.44 | jerm^home | haha :) |
| 03:51.46 | jerm^home | nice |
| 03:51.48 | landley | When I left busybox, I started my own from-scratch reimplementation. |
| 03:51.55 | jerm^home | cool |
| 03:52.20 | jerm^home | I have been too afraid to try mdev...what do you think about it's current state? |
| 03:52.30 | landley | It's only about 40 commands at the moment. |
| 03:52.44 | landley | jerm^home: well, the mdev I wrote was fairly cool. I can't speak for its current state. |
| 03:52.50 | landley | They rewrote large chunks of the guts. |
| 03:53.13 | landley | mdev -s currently works ok without a .config file, now that they've got it to stop complaining repeatedly about the lack of a config file. :) |
| 03:53.20 | jerm^home | haha |
| 03:53.21 | jerm^home | wow |
| 03:53.28 | jerm^home | maybe i'll try it out tomorrow... |
| 03:53.52 | jerm^home | udev seems so bloated |
| 03:53.52 | landley | In _theory_, mdev is a fairly straightforward thing that looks in /sys to populate /dev, and gets called via the /sbin/hotplug mechanism to add or remove devices. |
| 03:53.58 | landley | It is. |
| 03:54.12 | landley | The mdev config file is one line per entry. |
| 03:54.42 | landley | The first word is a regex to match a device name, the next bits are uid:gid the new device should belong to and permissions. |
| 03:55.02 | landley | And the optional end of the line is a command line to run under certain circumstances (when device is inserted, when device is removed, or both.) |
| 03:55.36 | landley | With some environment variables you can embed in it to specify certain things (is it an insert/remove, the /dev/name of the device, the /sys directory with more info...) |
| 03:55.49 | landley | Very simple, very straightforward, and extensible so you can make it do other things if you like and it's not our problem. |
| 03:56.04 | landley | How far the implementation's diverged from that in the past year, I could't tell you. |
| 03:56.13 | landley | Test before deploying, as always... |
| 03:56.16 | jerm^home | sounds pretty cool |
| 03:56.28 | landley | They're very responsive to bug reports on the mailing list, and they have frequent releases. |
| 03:56.46 | jerm^home | luckily we are an R&D shop so we do not have too many stability expectations |
| 03:57.19 | jerm^home | our customers get nervous when they don't see any catastropic failures at our demos... |
| 03:57.22 | jerm^home | :) |
| 03:57.43 | landley | Always fun. :) |
| 03:58.29 | jerm^home | well all..thx for the advice/help/etc |
| 03:58.44 | jerm^home | i'm out till tomorrow... |
| 04:22.40 | *** join/#edev DrZimmerman (n=theo@77-56-228-246.dclient.hispeed.ch) |
| 04:38.23 | *** join/#edev Ian_Daniher|xo (n=it@69.61.230.246) |
| 04:44.07 | *** join/#edev landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 04:44.07 | *** mode/#edev [+o landley] by ChanServ |
| 05:31.55 | *** join/#edev redb1ue (i=star@ppp028.108-253-207.mtl.mt.videotron.ca) |
| 06:00.38 | *** join/#edev roxfan2 (n=dunno@156.196-246-81.adsl-dyn.isp.belgacom.be) |
| 06:18.02 | *** part/#edev sorphin (n=dans@adsl-70-135-18-86.dsl.stlsmo.swbell.net) |
| 06:55.00 | *** join/#edev harpal (n=Harpal@122.169.108.195) |
| 07:31.50 | *** join/#edev lyakh (n=lyakh@p57BD37B4.dip0.t-ipconnect.de) |
| 08:10.47 | *** join/#edev boris_OmegA (n=boris@194.51.141.172) |
| 08:21.37 | *** join/#edev [AD]Turbo (n=turbo@host162-220-dynamic.59-82-r.retail.telecomitalia.it) |
| 08:22.35 | [AD]Turbo | yo all |
| 08:24.47 | *** join/#edev hw (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 08:29.05 | *** join/#edev roxfan (n=dunno@93.46-244-81.adsl-dyn.isp.belgacom.be) |
| 09:21.27 | *** join/#edev harpal (n=Harpal@122.169.108.195) |
| 09:33.50 | *** join/#edev mbuf (n=user@59.92.68.110) |
| 09:51.22 | *** join/#edev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 09:57.02 | *** join/#edev mbuf` (n=user@59.92.26.118) |
| 10:46.15 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:36.54 | *** join/#edev g1powermac__PB (n=g1powerm@76.177.147.36) |
| 11:55.33 | *** join/#edev chouimat|away (n=dieu@kde/developer/chouinard) [NETSPLIT VICTIM] |
| 11:55.33 | *** join/#edev mnemoc (n=amery@shell.opensde.net) [NETSPLIT VICTIM] |
| 12:03.05 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 12:59.12 | *** join/#edev BitSlop_ (n=BitSlop@mail.forwardengineering.com) |
| 13:34.59 | *** join/#edev linac (n=lin@121.201.118.13) |
| 13:36.22 | *** join/#edev samrobb (n=samrobb@eng.arriad.com) |
| 14:07.42 | *** join/#edev boris_OmegA (n=boris@194.51.141.172) |
| 14:12.16 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 14:12.16 | *** mode/#edev [+o GPSFan] by ChanServ |
| 14:36.18 | *** join/#edev prpplague^2 (n=dave@mail.americanmicrosystems.com) |
| 14:50.42 | *** join/#edev boris_OmegA (n=boris@194.51.141.172) |
| 14:53.08 | prpplague | http://www.acidmods.com/forum/index.php?topic=25141.0 |
| 14:53.30 | prpplague | they are using the same trackball as on the 8050, can't believe they actually soldered to the leads |
| 14:55.06 | *** join/#edev prpplague^2 (n=prpplagu@ppp-70-244-162-142.dsl.rcsntx.swbell.net) |
| 15:13.38 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 15:58.23 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 16:05.31 | prpplague | ho ho hum |
| 16:05.47 | prpplague | pokes CosmicPenguin with a stick to see if CosmicPenguin is alive |
| 16:14.08 | chouimat|work | prpplague you can stop now ... you're enjoying that way too much ;) |
| 16:14.27 | prpplague | hehe |
| 16:17.47 | prpplague | funny how there are technology dead zones in the US |
| 16:18.05 | chouimat|work | you mean in the redneck zone? |
| 16:18.05 | prpplague | areas of the country where there is almost no technology related work other than low end IT work |
| 16:18.35 | prpplague | i wouldn't call it redneck, i find the term kind of misleading |
| 16:18.47 | chouimat|work | :) |
| 16:20.47 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 16:23.29 | CosmicPenguin | I'm always alive |
| 16:23.35 | CosmicPenguin | you never know when I might be listening |
| 16:23.40 | CosmicPenguin | wooo-ooo-oooo |
| 16:24.20 | prpplague | jokes with CosmicPenguin |
| 16:24.32 | prpplague | CosmicPenguin: i wasn't sure since you smelled like something dead |
| 16:24.41 | CosmicPenguin | Common mistake |
| 16:28.10 | kergoth | morning |
| 16:34.09 | kergoth | prpplague: fyi, lifehacker posted on another sound effect site, like freesound - http://www.soundsnap.com/ |
| 16:34.27 | CosmicPenguin | neat |
| 16:34.41 | CosmicPenguin | I trolled ccmixter for remixes for my home video - works out really well |
| 16:34.45 | CosmicPenguin | they have some great stuff on there |
| 16:34.54 | prpplague | kergoth: ahh thanks |
| 16:35.09 | kergoth | CosmicPenguin: nice |
| 16:42.55 | *** join/#edev mpk (n=mpk@aggr.com) [NETSPLIT VICTIM] |
| 16:42.55 | *** join/#edev dmead (n=dan@ip226.sensaphone.us) |
| 16:42.55 | *** join/#edev ohsix (i=ohsix@66.220.111.222) [NETSPLIT VICTIM] |
| 16:47.43 | *** join/#edev gandhijee (i=akp@host-66-202-34-165.spr.choiceone.net) |
| 17:01.17 | kergoth | CosmicPenguin: this script to populate a git repo from an oe package isnt quite as easy as i'd hoped, since there can be multiple non-patch sources in an SRC_URI, but with a git repo everything is relative to /the/ upstream source tarball. thinking having it unpack everything and check which one created ${S}.. it'd fail on custom do_unpack's, but what can ya do.. |
| 17:01.20 | kergoth | heh |
| 17:33.48 | *** part/#edev wmat (n=btraynor@gromit.mixdown.ca) |
| 17:40.28 | *** join/#edev Ei5GTB_ (n=Paul@194.125.21.24) |
| 18:05.04 | *** join/#edev RobotGuy (n=robotguy@pool-96-225-210-142.ptldor.fios.verizon.net) |
| 18:38.45 | *** join/#edev lyakh (n=lyakh@p57BD37B4.dip0.t-ipconnect.de) |
| 18:47.57 | *** join/#edev miknix (n=miknix@gentoo/developer/miknix) |
| 19:21.39 | *** join/#edev frikker__ (n=blaine@107.135.68.216.DED-DSL.fuse.net) |
| 19:42.17 | prpplague | ho ho hum |
| 19:43.00 | agaffney | I don't suppose anyone has messed with unionfs-fuse in an initramfs with a busybox environment... |
| 19:43.16 | agaffney | I'm getting an error message that not even google has heard of :P |
| 19:43.21 | agaffney | mount: getcwd: No such file or directory |
| 19:46.32 | agaffney | I've had to statically compile unionfs-fuse and patch busybox to accept the -i option to mount |
| 19:46.34 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 19:46.36 | agaffney | but now I'm stuck :P |
| 20:17.57 | *** join/#edev Geicus (n=chatzill@64.132.1.226) |
| 20:18.51 | keesj | agaffney: are you using a shell script? |
| 20:19.05 | agaffney | yes |
| 20:20.49 | agaffney | keesj: does that make a difference? |
| 20:22.08 | keesj | well it depends on the implementation of mount in busybox I guess |
| 20:22.29 | keesj | O wait you are doing fuse... |
| 20:22.57 | agaffney | yes, trying to avoid patching the kernel for unionfs support |
| 20:23.07 | agaffney | I wish they would just add that in mainline... |
| 20:23.11 | keesj | and you get the error when performing the pivot_root? |
| 20:23.28 | agaffney | nope, when trying to do the unionfs-fuse mount |
| 20:24.04 | keesj | and the standard /sys /proc are mounted? |
| 20:24.54 | agaffney | yep |
| 20:26.14 | keesj | then I give up |
| 20:30.32 | keesj | happy happy joy joy! |
| 20:31.17 | keesj | is booting and debugging a kernel that is uploaded via jtag on a arm11 target! |
| 20:31.51 | agaffney | heh |
| 20:32.59 | keesj | using openocd that is |
| 20:38.35 | prpplague | keesj: using the flyswatter? or something else? |
| 20:41.07 | keesj | the jtagkey (I have a 20 pins board) |
| 20:45.54 | jerm^ | keesj: just curious...which processor? :) |
| 20:48.38 | keesj | sorry, can't but I will try the same trick on a samsung64xx |
| 21:14.37 | *** join/#edev ohsix (i=ohsix@66.220.111.222) |
| 21:41.11 | prpplague | ho ho hum |
| 21:41.15 | prpplague | solar: ping |
| 21:46.57 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 21:52.12 | *** join/#edev henux (i=henrih@unaffiliated/henux) |
| 21:53.54 | henux | Hmmm, buildroot failed with an error because it tried to use /usr/bin/install (I have install at /bin in my Arch Linux system). I wonder if this is the standard location of install tool? |
| 21:54.36 | henux | I fixed the problem by making a symbolic link. |
| 22:17.43 | ds2 | anyone know if there is an on screen keyboard that works with fbcon (i.e. no X, directfb, etc, just plain frame buffer console) |
| 22:22.56 | prpplague | ds2: hmm, good question |
| 22:23.08 | prpplague | ds2: i dont recal every having seen one |
| 22:23.41 | ds2 | that would explain why there aren't many touch screen terminal mode apps ;) |
| 22:25.28 | CosmicPenguin | What, like text based using GPM? |
| 22:27.15 | ds2 | yeah |
| 22:27.37 | ds2 | having that work would eliminate a whole truckload of X overhead |
| 22:28.36 | CosmicPenguin | Its possible, I'm sure - but groking the input would be tough |
| 22:28.51 | *** part/#edev henux (i=henrih@unaffiliated/henux) |
| 22:31.38 | ds2 | what I was thinking of is a normal OSK keyboard image alpha blended onto the lower part of the console; a background process could watch the touch screen and generate keyevents; there is a /dev/kbde driver to take care of that |
| 22:31.57 | ds2 | s/OSK keyboard/keyboard/ |
| 22:32.25 | ds2 | but it seems not all frame buffer drivers support the alphablending capability |
| 22:33.06 | CosmicPenguin | do any of them? |
| 22:33.11 | CosmicPenguin | I guess you could do a video overlay |
| 22:33.29 | ds2 | fbcon.txt hints that some may support it |
| 22:34.03 | CosmicPenguin | it wouldn't be accelerated though |
| 22:34.22 | CosmicPenguin | So I guess anybody can alpha blend - but ick - thats some crunching |
| 22:34.26 | CosmicPenguin | plus the cost of reading the video memory |
| 22:35.44 | ds2 | on th devices I am thinking of, it should be no more expensive; they share main memory |
| 22:36.50 | ds2 | but the math and more importantly the power consumption of doing this in the CPU is unappealing |
| 22:42.45 | ds2 | I suppose this could be done like an old DOS TSR; no blending/transparency |
| 22:43.19 | ds2 | enough interesting thinking..back to the boring world of chasing leads :( |
| 22:48.04 | MonMotha | ds2: while they may share memory, that's a lot of extra accesses on th bus |
| 22:50.04 | ds2 | MonMotha: good point; it would have to be uncacheable |
| 22:50.19 | MonMotha | indeed |
| 22:51.27 | CosmicPenguin | yep - the Geode is UMA but still has the cache penalty |
| 22:51.34 | *** join/#edev linac (n=lin@121.201.127.251) |
| 22:51.39 | CosmicPenguin | plus, I think the architecture adds an additional penalty, but thats not important now |
| 22:53.49 | prpplague | ds2: minimal X with a terminal? |
| 22:53.58 | ds2 | So tossing out the transparency stuff, a simple overwrite/restore (a-la DOS TSRs) should avoid that |
| 22:54.17 | ds2 | prpplague: think that is still too heavy and too userland centric |
| 22:54.33 | CosmicPenguin | ds2: if you have video overlays, that might work out too |
| 22:54.38 | prpplague | ds2: directfb? |
| 22:55.09 | prpplague | ds2: you can do a minimal x pretty small footprint |
| 22:55.31 | ds2 | prpplague: that would be my second choice.. It is not as light as one would think (played with it not too long ago) |
| 22:55.58 | prpplague | ds2: *cough* there is always picoqui |
| 22:56.00 | prpplague | gui |
| 22:56.03 | prpplague | picogui |
| 22:56.19 | ds2 | prpplague: let's say for purposes of discussion; I want to do this on the hammer with a retrofitted LCD + touch screen just to set a baseline for how limited the resources are |
| 22:56.44 | ds2 | I think I would consume about 20-30% of the total resources (storage + run time stuff) |
| 22:59.01 | CosmicPenguin | On the hammer, the alpha blending math might not be too bad |
| 22:59.14 | CosmicPenguin | if you do integer math, and don't change anything on the screen while the key board is up |
| 22:59.31 | ds2 | the hammer has hardware support for it in the fb? |
| 23:00.05 | CosmicPenguin | I don't think so - but you could generate the original screen with only a moderate delay |
| 23:00.11 | ds2 | not changing the screen is hard to guarantee; syslogd might decide to print out crap for example (I know is configurable blt that's just an example) |
| 23:00.14 | CosmicPenguin | your pain will come up if you try to modify the screen every key press or something |
| 23:08.35 | *** join/#edev roxfan2 (n=dunno@75.167-244-81.adsl-dyn.isp.belgacom.be) |
| 23:12.18 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |
| 23:18.20 | prpplague | ds2: yea |
| 23:18.28 | prpplague | ds2: it has support for fb |
| 23:18.47 | prpplague | ds2: you can do 8-bit stn, or 3-2-3 tft |
| 23:19.06 | *** join/#edev Geicus (n=chatzill@64.132.1.226) |
| 23:19.28 | prpplague | ds2: t0mW did an entire kiosk with the hammer |
| 23:19.35 | prpplague | ds2: 640x480 lcd and touch screen |
| 23:19.38 | prpplague | ds2: running x |
| 23:22.49 | prpplague | ds2: http://www.openhardware.net/HammerLCD/ |
| 23:26.24 | ds2 | prpplague: I know it has support for an FB; the question is does itsupport alphablending or transparent overlays in the hardware |
| 23:26.40 | prpplague | ds2: ahh, no it does not, sorry i misunderstood |
| 23:27.14 | prpplague | ds2: you simply want an onscreen keyboard with the console? |
| 23:27.41 | ds2 | prpplague: yep |
| 23:27.52 | prpplague | ds2: aml's terminal app that we use for the M7220 would do that pretty well |
| 23:27.57 | ds2 | so I can then use dialog as my main "gui" |
| 23:28.05 | ds2 | and use vt's for the "windowing" |
| 23:28.22 | prpplague | ds2: exactly what we do |
| 23:28.41 | prpplague | ds2: but we have a fb library we wrote to do alot of menus and such |
| 23:28.48 | prpplague | ds2: much better than dialog |
| 23:28.49 | ds2 | prpplague: heh... so you guys have code for a OSK in console mode? |
| 23:29.10 | *** join/#edev linac (n=lin@121.201.127.251) |
| 23:29.11 | ds2 | prpplague: once it works with dialog, swapping in something else is easy |
| 23:29.36 | prpplague | ds2: yea, its open source, but it doesn't currently have an onscreen keyboard, but it could be added pretty easily |
| 23:30.24 | ds2 | I can do the the rest pretty easily but the OSK is a bit harder |
| 23:31.15 | ds2 | good to know the entire world is not completely insane and use X for everything ;) |
| 23:31.39 | prpplague | ds2: well displaying it won't be hard, decoding the TS co-coordinates shouldn't be that bad either |
| 23:31.42 | prpplague | ds2: using tslib |
| 23:32.09 | prpplague | ds2: what lcd resolution did you need? |
| 23:32.54 | prpplague | ds2: and what console Rows X Cols ? |
| 23:33.04 | ds2 | prpplague: anywhere from 320x200 up to 800x480 |
| 23:33.41 | prpplague | ds2: and what a standard 25x80 ? |
| 23:33.50 | ds2 | displaying seems to be the hardest thing unless you are talking about the fall back mode like a DOS TSR |
| 23:33.59 | *** join/#edev Ian_Daniher_ (n=it@69.61.230.246) |
| 23:34.30 | ds2 | prpplague: I am not describing the rowxcols simply cuz the other thing I wanted to weak is the font size |
| 23:34.45 | prpplague | wanted to weak? |
| 23:34.55 | ds2 | the 800x480 is the Nokia 770/N800 LCD so it is pretty small |
| 23:34.58 | ds2 | ack... tweak I mean |
| 23:35.30 | prpplague | ds2: out term apps has about 10 different fonts |
| 23:35.38 | ds2 | the latest Maemo bugs has me irritated enough that I am thinking of taking the replacement kernel project I did a while ago further |
| 23:35.39 | prpplague | ds2: 4x6 being the smallest |
| 23:35.57 | ds2 | problem is 4x6 is not readable w/o a loupe on the N800 ;) |
| 23:36.12 | prpplague | ds2: indeed it was designed for a large 160x160 display |
| 23:36.17 | ds2 | I am thinking going the other way like using a 16x16 font or even bigger |
| 23:36.19 | prpplague | ds2: but we have up to 12x24 |
| 23:36.21 | *** join/#edev Ian_Daniher_ (n=it@69.61.230.246) |
| 23:36.39 | prpplague | ds2: ahh |
| 23:36.39 | ds2 | sounds like you are familiar with this problem |
| 23:36.43 | prpplague | ds2: yea |
| 23:37.13 | prpplague | ds2: when we first started doing the 7100 we need something, and x was just too slow for a 133MHz arm back then |
| 23:37.21 | prpplague | has to go, they are closing the office |
| 23:37.26 | ds2 | later |
| 23:37.29 | prpplague | ds2: bbi about 30 minutes |
| 23:37.33 | prpplague | ds2: you be around? |
| 23:37.36 | ds2 | yeah |
| 23:37.39 | prpplague | great |
| 23:37.49 | prpplague | disappears with a poof of smoke |
| 23:45.05 | *** join/#edev kergoth (n=kergoth@ip68-3-163-239.ph.ph.cox.net) |