Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.embedded > #301
| From | 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> |
|---|---|
| Subject | Re: ARM boot technology going up a notch |
| Newsgroups | comp.os.linux.advocacy, comp.os.linux.embedded |
| References | (1 earlier) <YNCdnQsXKMlyxIPNnZ2dnUVZ8kadnZ2d@lyse.net> <4ltTr.501600$v24.296354@fx11.am4> <4rGdne-OKde544PNnZ2dnUVZ8hSdnZ2d@lyse.net> <pHvTr.553622$1o5.232527@fx03.am4> <rKidnYKhVfyCWYPNnZ2dnUVZ8vKdnZ2d@lyse.net> |
| Followup-To | comp.os.linux.advocacy, comp.os.linux.embedded |
| Message-ID | <jWzTr.524984$IP4.186435@fx26.am4> (permalink) |
| Organization | virginmedia.com |
| Date | 2012-08-05 20:35 +0100 |
Cross-posted to 2 groups.
Followups directed to: comp.os.linux.advocacy, comp.os.linux.embedded
David Brown wrote: > On 05/08/12 16:46, 7 wrote: >> David Brown wrote: >> >>> On 05/08/12 14:06, 7 wrote: >>>> David Brown wrote: >>>> >>>>> On 03/08/12 21:06, 7 wrote: >>>>>> ARM boot technology going up a notch >>>>>> ------------------------------------ >>>>>> >>>>>> ARM chips are constantly evolving. >>>>>> So no two ARMs are really alike - always someone has added some >>>>>> extra lines of VHDL code to add some more functions. >>>>>> >>>>>> The latest SoC feature an impressive array of functions >>>>>> such as multiple cores, graphics accelerations, LCD controller, >>>>>> HDMI interface, USB, USB OTH, SDCard, ethernet, camera interface, >>>>>> SATA interface, RS232, ADC, sound, memory management unit, >>>>>> DMA, SPI, CAN, RS232, Real time clock, etc, and ALL ON ONE CHIP!! >>>>>> >>>>>> The point being, the chip can connect to a lot of devices >>>>>> with minimal add on chips and components. >>>>>> >>>>>> Notice the list includes a dedicated SDCard 2.0 interface >>>>>> that allows the ARM chip to directly read an SDCard. >>>>>> Some of these ARM chips have gone one step further >>>>>> and also have extra pins to tell them to BOOT FROM SDCARD!!!! >>>>>> >>>>>> That changes everything!!! >>>>>> >>>>>> For the average embedded techie who creates products from thin air, >>>>>> the way to program up an ARM is very expensive - they have >>>>>> to buy a JTAG debugger and a commercial compiler that >>>>>> works with that JTAG debugger to be able to do anything >>>>>> useful. Or he can wait a few months to years for someone >>>>>> in open source to catch up with the new chip with >>>>>> open source OpenOCD JTAG debugger and Eclipse. >>>>> >>>>> JTAG debuggers are available for less than $50, or you can make them >>>>> yourself. (More expensive devices have higher speeds and more >>>>> functions, of course.) The most popular ARM toolchain is free (though >>>>> again you can pay for more features, more support, etc., if you want). >>>>> >>>>> It is not a matter of "waiting for months or years" - support from >>>>> OpenOCD and gcc normally arrives long before the chips. >>>>> >>>>> And while booting from an SDCard may be a new feature, >>>>> microcontrollers >>>>> and processors have supported multiple boot modes for decades. People >>>>> who actually /work/ with these sorts of devices (as electronics >>>>> developers and low-level programmers) have been happily booting from >>>>> UARTs, Ethernet, CAN, SPI, QSPI, NAND flash, NOR flash, and a variety >>>>> of other devices and data stores in addition to JTAG. >>>> >>>> Not virgin devices. Some kind of software has to be put in somewhere >>>> to allow the devices to boot from UART, ethernet, CAN, etc. >>>> >>> >>> I imagine you have never had experience of using microcontrollers. Yes, >>> you have to have software to support booting from these devices - just >>> as you need software to support booting from an SDCard. It is known as >>> a "boot rom", and comes ready-programmed by the manufacturer. It is >>> /exactly/ the same principle whether it boots from SDCard or any other >>> source. >>> >>>>> Built-in boot rom support for SDCard is nothing revolutionary or >>>>> dramatic. It's a nice feature to have, but that's it. >>>> >>>> It is revolutionary - not many have it with the booting features >>>> enabled on virgin chips leaving the factory. >>> >>> Many do. All large microcontrollers have boot rom, as do a fair >>> proportion of SOCs. Traditionally, processors do not have boot rom on >>> the chip itself - but all cards will have a boot device (usually NOR >>> flash), and all manufacturers will program this as part of the >>> manufacturing process. >> >> Flash - most controllers have it - and they can boot from that once >> the software has been researched and developed and put in. > > Most /microcontrollers/ have flash (there is no strict definition of a > microcontroller - but flash is pretty much a "must have" feature of > modern microcontrollers). Some SOCs have flash, but many do not. No > processors have flash. > > But virtually all processors are capable of booting directly from NOR > flash - it does not need any sort of software or ROM in the device, just > some default settings for the bus controller and the boot controller. > Booting from NAND, SPI or QSPI flash is a little more difficult, and > /may/ require a simple program in boot ROM, or may be handled directly > in hardware by the flash controller. > >> Boot ROM - many controller can have it and contains the code >> developed for or by the customer again after R&D. >> That is common practice since whenever. > > Common practice is that is it developed by the manufacturer, not the > customer. A customer will only be involved in the development of the > boot rom code if they are getting their own specialised or customised > chip. > >> >> The next bit is different: Manufacturer puts in boot rom into SoC and >> sets aside a pin to allow it boot from SDCard and put in code into >> boot rom as part of a documented feature of the SoC. >> All their chips are sold with this feature - not custom chips >> or specially crafted one offs. So now you can boot >> the chip as part of its documented behavior, by setting >> one of its pin high and force it to boot from SDCard. > > This is /exactly/ the same as is done for booting from SPI flash, UARTs, > Ethernet, CAN, USB, etc., etc. It is not a revolution in any way - it > is the same system as has always been used. > > I don't know whether you are totally ignorant of current practices, or > just a sucker for whatever marketing exaggerations you read, but you are > clearly out of your depth talking about these things. You are an absolutely fscked up stupid troll infecting newsgroups. I await anxiously for you to name a couple of off the shelf chips with clearly downloadable datasheets that clearly proves each of your point - SPI flash, UARTs, ethernet, CAN, USB, etc..etc booting without purchasing a JTAG debugger to program in the boot loader. >> That is a big revolution. >> Now you can boot Linux directly off the SDCard >> without needing a JTAG debugger. >> >> >>>> Reading the forums, I only come across second hand info >>>> that the A10 and may be some TI/NXP chips as having it. >>> >>> The A10 is a processor core, not a chip. It has no boot rom of any kind >>> - the issue does not make sense for a core. >>> >>> Most TI and NXP chips have boot roms, as do most chips from other >>> manufacturers. >>> >>>> The tech specs seem to be a closely guarded >>>> secret so still hunting for details. >>> >>> No, they are not "closely guarded secrets". For some chips, the >>> manufacturers only sell to a few specific customers, and the datasheets >>> are only available by contacting the company directly (Broadcom is like >>> that). Since you can't buy their chips (unless you are ordering >>> hundreds of thousands), you don't need the specs. For other chips that >>> are easily available (such as from TI and NXP), the specs and boot >>> details are easily available by looking on their websites. >>> >>>> Why they are hiding the info I don't understand because >>>> all it does is hold back the sale of their own chips!! >>>> >>> >>> They don't hide the info - you just don't know what you are looking for. >>> >>>> Hower chips with built in SDCard boot >>>> which can be enabled by setting a pin high on a chip >>>> changes everything because >>> >>> Again - you have no idea what you are talking about, and SDCard boot >>> support does not "change everything". >>> >>>> previously you had to have a JTAG debugger and program the >>>> internal boot rom with the boot loader code >>> >>> You can't program rom with a debugger, and you wouldn't need to because >>> the rom is pre-programmed. >>> >>>> which can hold you back for months if you are new to a chip. >>>> Now you don't need a JTAG debugger to program the chip with >>>> a boot loader. A working gdb (if needed), an SCdard >>>> and gcc/Eclipse is all that you need to have Linux running >>>> on it without touching any of the internal flash. >>>> That must be a massive revolution in chip design. >>> >>> Boot rom support for an SDCard is nice. But it is not something you >>> would use in development - of preference, you would boot over Ethernet. >>> >>> For working with low-level development, your usual procedure is to get a >>> flexible bootloader (such as uboot) into flash (probably using a jtag >>> debugger, since they cost peanuts and no one doing low-level development >>> would be without one - but possibly using a UART bootloader from the >>> devices boot rom if that is more convenient). You use this bootloader >>> to load the Linux kernel from a TFTP server, and mount root using NFS. >>> >>> No developer who valued his time would muck around with copying programs >>> onto an SDCard for development - Ethernet is far faster, and far more >>> convenient. >> >> ? >> >> You would need a booted environment capable of running gdb >> and that must surely be best if an SDCard can boot, >> and then start up ethernet and then you can go in there through ethernet. > > You are talking from a viewpoint of zero experience and zero knowledge, > and apparently have difficulty with basic reading comprehension. > > You use a low-level bootloader (such as a rom-based UART bootloader) or > a jtag interface to get a Ethernet-capable bootloader into flash. Then > the processor will boot from that flash bootloader, load the kernel by > TFTP, and off you go. Everything else is accessed from your server (or > workstation) via NFS (or samba, if you prefer). > > There is no need to put an SDCard in your PC, copy files over, move the > card physically to your test board, re-boot from the card, test your > program - and then repeat the whole process for every change and > re-compile. You work directly. > > I'm sure there /are/ developers that have come up with a more convoluted > and time-consuming method than TFTP and NFS over Ethernet, such as using > USB sticks or SDCards, but that is not something a knowledgeable > developer would do. > >> >> If you make spanking a new card from scratch >> and solder this new CPU to brand new card, this boot pin and boot >> by SDCard is revolutionary because your Linux on >> SDCard can be scripted to do just that and be ready for >> incoming ethernet connections without a JTAG device in sight. > > It is not revolutionary, because no one has had a problem with this > before. There are several methods that are as good or better than using > an SDCard in many cases - using JTAG (I don't know what you've got > against it - it is fast, flexible and cheap), using pre-programmed flash > (the standard for large production runs, and by far the fastest method), > using UART boot mode (easy for small production runs), using plug-in SPI > cards (easy for small and medium runs), or using chips that have more > advanced boot modes. SDCard booting from rom gives another option - but > it is just one more of many options. > >> >> >>>> The closest equivalent is ROM cartridges - but that is not >>>> nearly the same as booting off an industry standard >>>> and widely supported SDCard with gigabytes of storage. >>>> >>
Back to comp.os.linux.embedded | Previous | Next — Previous in thread | Next in thread | Find similar
ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-03 20:06 +0100
Re: ARM boot technology going up a notch David Brown <david.brown@removethis.hesbynett.no> - 2012-08-05 13:32 +0200
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-05 13:06 +0100
Re: ARM boot technology going up a notch David Brown <david.brown@removethis.hesbynett.no> - 2012-08-05 16:07 +0200
Re: ARM boot technology going up a notch Hadron<hadronquark@gmail.com> - 2012-08-05 15:38 +0100
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-05 16:11 +0100
Re: ARM boot technology going up a notch "Ezekiel" <zeke@nosuchemail.com> - 2012-08-05 14:38 -0400
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-05 15:46 +0100
Re: ARM boot technology going up a notch David Brown <david.brown@removethis.hesbynett.no> - 2012-08-05 21:06 +0200
Re: ARM boot technology going up a notch "Ezekiel" <zeke@nosuchemail.com> - 2012-08-05 15:26 -0400
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-05 20:46 +0100
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-05 20:59 +0100
Re: ARM boot technology going up a notch David Brown <david@westcontrol.removethisbit.com> - 2012-08-06 08:15 +0200
Re: ARM boot technology going up a notch Grant Edwards <invalid@invalid.invalid> - 2012-08-06 14:11 +0000
Re: ARM boot technology going up a notch David Brown <david.brown@removethis.hesbynett.no> - 2012-08-06 22:37 +0200
Re: ARM boot technology going up a notch chrisv <chrisv@nospam.invalid> - 2012-08-06 07:47 -0500
Re: ARM boot technology going up a notch Big Steel <Run77712@Run77712.com> - 2012-08-06 08:52 -0400
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-05 20:35 +0100
Re: ARM boot technology going up a notch David Brown <david@westcontrol.removethisbit.com> - 2012-08-06 08:09 +0200
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-06 20:43 +0100
Re: ARM boot technology going up a notch David Brown <david.brown@removethis.hesbynett.no> - 2012-08-06 22:44 +0200
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-06 22:14 +0100
Re: ARM boot technology going up a notch Hadron<hadronquark@gmail.com> - 2012-08-06 22:41 +0100
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-06 22:51 +0100
Re: ARM boot technology going up a notch Hadron<hadronquark@gmail.com> - 2012-08-06 22:58 +0100
Re: ARM boot technology going up a notch 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-08-06 23:31 +0100
Re: ARM boot technology going up a notch Hadron<hadronquark@gmail.com> - 2012-08-07 00:51 +0200
Re: ARM boot technology going up a notch "Ezekiel" <zeke@nosuchemail.com> - 2012-08-06 19:30 -0400
Re: ARM boot technology going up a notch Hadron<hadronquark@gmail.com> - 2012-08-07 01:36 +0200
Re: ARM boot technology going up a notch Foster <frankfoster50@yahoo.com> - 2012-08-06 20:14 -0400
Re: ARM boot technology going up a notch Scott Wood <scott@buserror.net> - 2012-08-25 13:39 -0500
Re: ARM boot technology going up a notch Grant Edwards <invalid@invalid.invalid> - 2012-08-06 14:07 +0000
Re: ARM boot technology going up a notch chrisv <chrisv@nospam.invalid> - 2012-08-06 09:48 -0500
Re: ARM boot technology going up a notch Hadron<hadronquark@gmail.com> - 2012-08-06 17:23 +0100
Re: ARM boot technology going up a notch Grant Edwards <invalid@invalid.invalid> - 2012-08-06 18:36 +0000
Re: ARM boot technology going up a notch "Stonethrower" <digi_64-public[removeme]@yahoo.com> - 2012-08-06 15:15 +0200
csiph-web