| |||||||||||||
|
| |||||||||||||
gNewSensegNewSensePosted Sep 21, 2007 2:48 UTC (Fri) by gdt (subscriber, #6284)In reply to: gNewSense by epa Parent article: MadWifi developers move to ath5k
I reserve my opinion because we haven't seen the obstacles a vendor who did choose to do the Right Thing would face. For example, how long would it take to get the code for the proprietary "CPU" into the gcc tool chain? I can quite understand why a vendor might choose not to be the first one down that path.
(Log in to post comments)
gcc ports Posted Sep 21, 2007 6:19 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Oh, come on. It's standard practice for vendors of new CPU architectures to work on a gcc port very early, and the gcc team is happy to cooperate with such efforts, and offer assistance (or point people to qualified consultants who will do the port for pay). You wouldn't be first down a path, you'd be on a well-travelled road.
gcc ports Posted Sep 27, 2007 18:29 UTC (Thu) by iabervon (subscriber, #722) [Link] A lot of microcontrollers embedded in existing devices use architectures that GCC doesn't support. A lot of them actually use an architecture that's been around for 27 years and has never gotten a GCC port: the 8051. GCC also doesn't support PIC microcontrollers. Then there are FPGA-based systems, which need an entirely different firmware design. In fact, most embedded platforms that GCC targets will have embedded flash, meaning that firmware wouldn't be part of drivers anyway; the hardware would come with a version installed, and any changes would be released by the vendor as a download that users can install at their leisure.
gcc ports Posted Sep 27, 2007 19:38 UTC (Thu) by zlynx (subscriber, #2285) [Link] Many of these microcontrollers really are micro. When a programmer only has a few KB of instruction space, he does not want to write code in C. Assembly is the only way to go, and it isn't so bad.
You know the saying that C is portable assembly. Well, a good assembler makes it as easy to write as C, it just isn't portable.
gNewSense Posted Sep 27, 2007 20:06 UTC (Thu) by moxfyre (guest, #13847) [Link] Doing the "Right Thing" doesn't necessarily mean that the vendor has to do all the extra work. Sure, it'd be nice if device vendors would release firmware source code that could be modified and rebuilt with the standard toolchain.But that's not necessary. All they really need to do to be Linux-friendly is release the source code under GPL in *some form*. Maybe it's assembler code. Maybe it's C code. SDCC is a Free software compiler targeting 8-bit microcontroller architectures, including 8051, Z80, and even PIC (which has the worst instruction set imaginable for C compilers). GCC is aimed at 32/64-bit architectures, and I think that SDCC is a REALLY valuable complement to it for the low-end embedded space. When hardware vendors provide basic device information and initial code, the Free software community can usually run with it. For example, Linksys released the code for its Linux-based routers... and now there are several polished and powerful distros for those routers. ATI has just released programming information--not even code, really--for their GPUs, and suddenly there's a veritable blizzard of open-source display driver development. As Greg K-H pointed out, "if you release specs, the Linux community will produce drivers"... often, they'll be better than the proprietary drivers!
|
|
||||||||||||