On Fri, Aug 08, 2008 at 03:02:13PM +0200, Stefan Reinauer wrote: > Peter Stuge wrote: > >* By far the most important one: Use a more intelligent USB chip > > * Possibly, in connection with this, use SRAM or DRAM to store or > cache the images transferred from the host side. I think writing > the flash takes about as long as transferring it over serial port,
Each 128K block erase+write takes at least 1.8s. Look for a flash part with better performance for the next generation. > so using a faster USB (network instead of serial) chip would only > move the bottle neck. Exactly how a fast USB interface should work is a great question. Making the device a CDC Ethernet device like the GALEP-5 would be nice because it will be easy to interface with, but it would also require the FPGA to run a full IP stack, which I don't think we want. I would look for other device class specs but possibly the best solution would simply be a vendor specific device with two (IN+OUT) bulk endpoints and an efficient protocol. As long as documentation is provided, I don't think there's any shame in vendor specific devices. (And with the dongle there's source.) > * One habit of the dongle is very ugly; the need to reset it after > loading it. I think it would be a good idea to have the dongle > reset itself (or, the lpc part of itself) after the write process > is complete. Great point. It should not need a reset at all. Hopefully this does not go beyond the VHDL. > * 0x3f8 serial port logging support on lpc. (Sorry, I never looked > into this) Great idea, also VHDL. Besides Stefan's points I have another VHDL request; * Don't require explicit enable for full memory decode. > * A couple of jumper pins could be preconfigured as host side > software programmable GPIOs for tasks like triggering a reset on > the target system. Yes, some open collector outputs should be cheap to add. //Peter
pgpPjNUtRcgxR.pgp
Description: PGP signature
-- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
