Bureaucrats, dave_user, Administrators
8,186
edits
Changes
→Various
One of the greatest challenges for embedded systems manufacturers is to guarantee that the software on the system can be updated in the easiest way. On-the-field software upgradability is a major requirement that allows to replace bogus code and to enhance application features. How to perform this operation is highly platform-dependent. The following section shows in detail a specific situation.
As a general rule of thumb, '''it is highly recommended to avoid package-based systems such as rpm or deb to implement reliable software upgrade mechanisms.'''
== U-Boot/Linux system ==
'''DAVE Embedded Systems''' owns an IAB (Individual Address Block, a set of 4096 addresses), that is in the public listing, so everyone can find out that an address is associated to '''DAVE Embedded Systems'''. Note that the registration authority provides only IABs and OUIs (16000000+ addresses), and that a company is not allowed to request another IAB until at least 95% of the MAC addresses of the previous IAB have been used.
Customers who build their products using '''DAVE Embedded Systems'''' SOMs (NaonAXEL Lite, LizardAXEL ULite, QongBORA, ZefeerORCA,...) usually provide MAC numbers by themselves by acquiring them from IEEE. In fact, there are many reasons for this. Three can be stressed:
* A CPU module is NOT an end-product. It is not a product that goes directly to the final user as a LAN PCI board, or a printer server. So, in case of CPU modules, who gets a CPU module and build its own product with it, is responsible for handling the MAC address.
** in case of WDT intervention: tracking of watchdog event for software analysis
* MAC addresses handling: see [http://standards.ieee.org/develop/regauth/index.html IEEE registration authority]
* runtime automatic detection and configuration: possible usage of [[ConfigID_and_UniqueID | ConfigID]] technique