On Mon, 2009-10-12 at 15:54 +0200, Fortini Matteo wrote: > Yes, that's what we're currently using, but the problem is a little > broader: I should answer to CAN messages in at most 100-200ms from > powerup, and that can be done in u-boot.
if you are in that interval you definitely need to go to a more exotic start sequence than usual. one solution would be to do as you suggest and do a special driver that is living outside of the kernel during startup. you still need to hack into the interrupt code to let your "external" driver handle the CAN. then you need to hack up the ordinary driver to take over from yours. I have not seen this solution on any project I worked on but should be doable. optimizing the boot time of linux so it starts up in 200ms is probably going to be quite hard. I did 2 seconds to /sbin/init started from ide driver without to much trouble. removing the IDE and going to a root on NOR would probably get closer to 1.5 but to get down to 200ms would probably mean removing most of u-boot and only keep the dram setup then you probably need to remove most of the drivers from the kernel and load them later as modules. I have never really tried to do a insane fast boot like this so I'm not sure what problems you will run up against. but maybe it's possible. but 200ms feels a bit to optimistic. > However, handing CAN transmission control over to Linux is quite > complicated nowadays, since it would involve passing structures in > memory and hacking through device init. > It'd be nice to have a framework with which u-boot could hand-over > devices to Linux in a clean and defined way. not likely to happen as a generic solution. Much better to just remove the boat loader then and work on optimizing the linux startup code. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
