> Well, I'm the one who was asking Marc the questions, and part of the > frustration was that I'd helped him with an email problem, but got no I guess I missed some mails. I'm having problems with the company exchange server that mangles my mails and considering the MX record, I would not be surprised if some mails get lost :( The exchange server seems to nibble the empty lines in my mails. If it passes 2 of those server, my mails are nothing but one long line :( > response to my questions until I sent the 'stupid' email. Why did you > -publish- this particular email Marc? As I subsequently told him, Because you wanted to know about emdebian, and I know little of that system myself. I'm working with a busybox/uclibc system to get a small filesystem (1.5 Meg). > Sure there's a place for commercial vendors, but I want to learn > this stuff, and there's really no 'on-ramp' --or at least perspective-- > in the wiki for n00bs. It's work in progress. It started a number of weeks ago and we'll add more info as time goes by. From my part, they're mainly copy/pastes from our wiki. Your input in the wiki as an outsider would be very valuable! > The toolchain is already provided by Scratchbox, and I can also add a > very basic Debian devkit if need be. But what's next? Where's I cannot help you with emdebian itself, but would be very interested in the replies :) There is a project where I dream of having it on, but before I can convince some ppl (it's now a normal debian system), I need to know what I'm talking about X-). I hope to learn a lot on this on FOSDEM in a couple of weeks. I guess it would be the difference between a working solution and a good and working solution on which to be proud. > EmDebian? The target flash can be as large as 64MB. I'd like to > install an EmDebian environment with kernel 2.6.n, and support apps > for the final functions. It would be nice as well to have QtEmbedded, Are you planning to have it field upgradeable? In that case, you might consider dividing your flash in a number of systems: e.g. a basic system to perform a network update and a running system with all the features enabled. Though it would not matter much, since you'll only be needing about 2 MB for this upgrade system. Or you can go for full redendancy of course; where you have the basic system (production) and a location to upload new versions with the certainty to be able to go back to the good old proven production system. You can use e.g. U-Boot to read a number of bytes of the flash to determine the image to boot. If the new image boots, you change the flash to indicate this, otherwise you'll boot back the old one (after reading the conf with U-Boot to test the new image, U-boot can change it back to default). This way, you'll be (almost) always assured that your system boots decently even if the upload broke. If you are running ia32, you could also have a look on DSL (Damn Small Linux). Its Knoppix/Debian based and fits on 64 MB. Might be a quick start (I have it booting of a USB stick). I can provide a dd if it's any help. > a web server, and Radius client. Then I need to create an image which > can be burned to CF flash for booting by the target platform. Are > there instructions? I guess you need a JTAG probe for that. I think I added how we configured our BDI2000 probes in twiki (which was summarised from somewhere else IIRC). -- Marc Leeman R&D Firmware Engineer Barco Control Rooms Noordlaan 5, Industriezone, B-8520 Kuurne (BE) Tel. +32 56 368 428 http://www.barcocontrolrooms.com mailto:marc.leeman@barco.com
Attachment:
signature.asc
Description: Digital signature