S?bastien Bourdeauducq wrote: > No no. We keep everything on the internal flash. I do not want > involvements with low-level debugging of the memory card protocol > idiosyncrasies (and there are many)
Hmm, what specifically are you concerned about ? If all you want is read blocks from a memory card and don't care about optimizing speed or power consumption, you should be able to ignore pretty much all those weird descriptors and things. I mean, you've already implemented memory card support. What's missing for a simple boot loader ? > coupled with users deleting the > wrong files or formatting the card with unsupported filesystems. Oh, you want filesystems :-) Well, FAT16 probably won't go away too quickly. (And there's no need for patent-encumbered VFAT.) Partition tables may face extincion sooner, i.e., when memory cards approach 2 TB. Probably sooner, because magnetic disks already pass this barrier. If you're really worried about that, you could always fall back to a sequential search, allowing people to write their boot file with "dd" and whatever the legacy operating systems use. > Also, there might be no memory card and only Ethernet in the end. > That would even be preferable if possible without blowing up the > cost. Hmm, that doesn't sound very nice from an integration point of view. The memory card makes the device self-contained. If it depends on Ether, you need a rather complex life support system. > I do not believe USB storage will ever happen. Why not ? If you target this low-cost device specifically at developers, it wouldn't be too unreasonable to expect that some of them will actually contribute to the infrastructure. Or did you mean "patch developers" ? > I do not > expect USB stack functionality to grow a lot because this work is > painful and no one wants to do it. I think it all depends on getting the critter to run Linux properly and then turning that USB host into at least a general Full-Speed host (i.e., without offloading some of the USB stack into the Navre). I agree that most people able to make significant contributions to that side of the system would consider extending RTEMS' USB stack a dead end. > >It's not quite clear to me how you want to position the device. > >If it's for M1 developers, they'd probably want more M1 features. > >If it's intended as a cost-down replacement of M1, that may work. > >If it's for FPGA enthusiasts, you can probably cut off some more > >fat. > > It is an entry-level M1, which is all of the above. Heh, now you have conflicting feature sets :-) Maybe we have to go back a few steps. What is it really that's bothering you most about the current situation ? - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
