WO2022122946A1 - Method for an improved firmware deployment and its usage in embedded logic - Google Patents
Method for an improved firmware deployment and its usage in embedded logic Download PDFInfo
- Publication number
- WO2022122946A1 WO2022122946A1 PCT/EP2021/085037 EP2021085037W WO2022122946A1 WO 2022122946 A1 WO2022122946 A1 WO 2022122946A1 EP 2021085037 W EP2021085037 W EP 2021085037W WO 2022122946 A1 WO2022122946 A1 WO 2022122946A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- hardware platform
- firmware
- deployment
- host
- special
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 39
- 238000012360 testing method Methods 0.000 claims abstract description 30
- 230000000051 modifying effect Effects 0.000 claims abstract description 4
- 238000013507 mapping Methods 0.000 claims description 4
- 230000015654 memory Effects 0.000 description 10
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 8
- 229910052710 silicon Inorganic materials 0.000 description 8
- 239000010703 silicon Substances 0.000 description 8
- 238000011161 development Methods 0.000 description 6
- 238000011282 treatment Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000012467 final product Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Definitions
- the invention relates to a method for an improved firmware deployment for any hardware platform. It relates also to a method which uses a special firmware deployment bundle for a hardware platform generated by the previous mentioned method .
- ELF Executable and Linkable Format
- the ELF is flexible, extensible, and crossplatform. For instance, it supports different endiannesses and address sizes so it does not exclude any particular central processing unit (CPU) or instruction set architecture. This has allowed it to be adopted by many different operating systems on many different hardware platforms .
- CPU central processing unit
- instruction set architecture This has allowed it to be adopted by many different operating systems on many different hardware platforms .
- Each ELF file is made up of one ELF header, followed by file data.
- the data can include program header table, describing zero or more memory segments, section header table, describing zero or more sections and data referred to by entries in the program header table or section header table.
- the segments contain information that is needed for run time execution of the file , while sections contain important data for linking and relocation . Any byte in the entire file can be owned by one section at most , and orphan bytes can occur which are unowned by any section .
- the ELF file format can be seen as a basis for distributing compiled applications and embedded systems .
- a developer often faces challenges interfacing with the overall system, i . e . hardware and firmware running on it .
- the overall system i . e . hardware and firmware running on it .
- such a system is proprietary and - in order to protect the internals - utili zes mechanisms to prevent unauthori zed third parties from interacting with it in an unconstrained way .
- the concrete protocol might not be fixed : It might be brought up first , be slightly changed over time or even be redone entirely .
- This poses challenges on accompanying tools which e . g . need to know this protocol and run through it in order to do their work .
- a test framework which shall test the overall functionality of the application would first need to unlock the device before being able to do its testing . But whenever there is a change in the protocol , also that test framework must be updated .
- the special firmware deployment bundle as an executable by the host tool for loading the firmware deployment onto the hardware platform and / or using it as an input for other host tools for firmware loading, debugging and / or test stimuli on the hardware platform .
- the basic idea of the invention is to create an application binary during building a concrete firmware version, which knows the hardware platform it will be running on . So , the inventive approach can be reali zed in two steps : Firstly, to create a special firmware deployment and secondly, additional information and logic embedded in the deployment is used .
- firmware is built for a speci fic platform, either for real hardware or an FPGA. And it is also built with support for a very speci fic version of the hardware platform . So all the knowledge required to interact with the overall system can be encoded into the application binary .
- a hardware platform in the sense of this application is understood as a real hardware , e . g . out of silicon, or a field-programmable gate array ( FPGA) .
- firmware usually is distributed in the form of compiled machine code for a particular hardware platform, so it cannot be executed directly on a host system from where a system should be debugged or tested .
- a platform agnostic representation of the " interface logic" is combined with the firmware executable .
- firmware executable also named as firmware image
- embedded interface logic as additional information and hardware platform speci fic logic .
- This combined arti fact is then used both for loading the firmware onto a hardware platform, hence any kind of device , as well as an input for host tools to talk to said device , e . g . for firmware loading, debugging, test stimuli and so on .
- host tools do not need to be updated regularly, which keeps maintenance ef fort low and also contributes to fewer problems due to outdated tool versions in the infrastructure .
- the additional information and hardware platform speci fic logic comprise interfacing information of the hardware platform .
- Any hardware platform or device speci fic logic can be implemented in the firmware images or firmware executable as additional information .
- the hardware platform is a hardware device or an FPGA.
- the special firmware deployment bundle comprises a complete host tool , where a load and test application is built and published with each firmware build .
- This variant could be an alternative approach, hence to deliver the complete host tools which are required with each firmware . So a load & test application could be build and published with each firmware build . However, this could pose problems as this application would need to be installed with each firmware version or at least it would be required to ensure that the application can be run in place . Depending on the complexity of the overall proj ect setup, this could be di f ficult to achieve .
- the inventive method that solves the above mentioned obj ective can be used on the consuming side in a very advantageous way .
- the further inventive method which uses the special firmware deployment bundle for a hardware platform generated by the method according to claims 1 to 4 comprises the following steps or is performed in the following way :
- a host tool In order to load the embedded script and run tests on the hardware platform later on, a host tool is needed which extract the embedded script and load it into the runtime of the host tool .
- the runtime or runtime environment of a host tool is understood as a program with which applications can be made executable in an unfamiliar environment by mediating between the application program and the operating system, hence the hardware platform .
- a host tool is usually a script engine for executing the chosen language , e . g . a JavaScript engine .
- the host tool can interact with the hardware in question, forwarding any speci fic requests to the previously loaded script .
- This can already start with the loading procedure :
- a special treatment for ROM contents might be added .
- the silicon device nothing is to do , but for the FPGA the ROM contents might be loaded from the firmware image and put in into the device memory on every load .
- the previously running script will carry out the required steps .
- the script knows to which platform it belongs due to the added additional information and hardware platform speci fic logic, it can execute the right steps for it without any further ado .
- the only thing required for it to work is , that the host application needs to provide an interface for copying over the data, e . g . one for reading the compiled machine code from the image and one for writing the data into device memory .
- the script will then take care for the rest , i . e . finding all relevant sections to be copied in the image and loading them to the correct addresses in the device .
- the method comprises a further step, where the hardware platform is brought into a mode for testing by enabling a debug mode through to the previously loaded script provided by interfaces of the host tool to the hardware platform .
- the host tool can interact with the hardware in question, forwarding any speci fic requests to the previously loaded script .
- this might involve writing "magic" values to certain device registers/memory locations or doing a proper authentication of the user, depending on the desired level of security .
- the host tool does not need to know the concrete steps : I f the user wants to enable debug mode , this request is passed through to the previously loaded script , which in turn runs the required steps for that particular piece of hardware .
- the host tool is providing appropriate ( generic ) interfaces towards the hardware .
- the method comprises a further step, where the hardware platform is brought into a system test mode by implementing higher level commands by the previously loaded script for controlling said system test mode , wherein the interfaces between the host tool and the hardware platform remain the same .
- the script loaded before might implement certain higher level commands for driving such tests - keeping the interface on the host tool level the same , even i f depending on the concrete hardware di f ferent steps have to be taken .
- some peripherals might not be present or located at di f ferent addresses .
- Fig . 1 Inventive workflow for creating a special firmware deployment bundle with embedded additional information and hardware platform speci fic logic according to the invention
- Fig . 2 Workflow for using the inventive special firmware deployment bundle with embedded additional information and hardware platform speci fic logic according to the invention .
- Figure 1 shows the inventive workflow 1 for creating a special firmware deployment bundle 7 with embedded additional information and hardware platform speci fic logic, one workflow path for using an FPGA hardware platform and one path for using a hardware platform implemented as real silicon device .
- a firmware for an embedded platform is written in a language like C or C++ .
- source files 2 of the application are taken and compiled and linked 3 into dedicated firmware images 4 .
- the application needs to run on both an FPGA prototyping platform as well as , later during the development , a "real" silicon device , two speci fic firmware executables need to be built , each having the inherent knowledge about which platform it belongs to "built-in” .
- the state-of-the-art workflow is extended by an additional step 6 , where device speci fic logic 5 is embedded into the firmware images . This can be done by modi fying ELF files , assuming that this format is used for delivery, or by creating an archive file , e . g . a zip file , which contains both the firmware image itsel f as well as the additional logic .
- FIG. 2 shows a workflow 8 for using the inventive special firmware deployment bundle 7 with embedded additional information and hardware platform speci fic logic on the consuming side .
- the embedded logic is used as described in the following .
- the starting point is the firmware image with the embedded additional information and hardware platform speci fic logic, e . g . a debug logic, forming the special firmware deployment bundle 7 .
- a tool on the host which runs the following steps , is needed :
- the embedded script logic is extracted and loaded into the runtime of the host tool , whereas the steps marked with reference signs 9 , 12 and 15 are basically actions that the host tool carries out by using the logic from the extracted script logic .
- the host tool usually will be a script engine for executing the chosen language , e . g . a JavaScript engine . From now on, the host tool can interact with the hardware platform 10 in question, forwarding any speci fic requests to the previously loaded script 11 .
- the script can already start with the loading procedure : Depending on whether to load the firmware onto an FPGA prototype or a silicon device , e . g . a special treatment for ROM contents has to be added . On the silicon device , nothing is to do , but for the FPGA the ROM content has to be loaded from the firmware image and put in into the device memory on every load 12 .
- the previously running script 11 will carry out the required steps .
- the script 11 knows to which hardware platform 10 it belongs due to the added additional information ( as the script is basically the added additional information) and hardware platform speci fic logic, it can execute the right steps for it without any further ado .
- the only thing required for it to work is , that the host application needs to provide an interface 13 , 14 for copying over the data, e . g . one 13 for reading the compiled machine code from the image and one 14 for writing the data into device memory . So actually, the host tool extracts the device speci fic logic and loads it into some "execution engine" ( e . g . a JavaScript engine ) .
- Steps that require device interaction like loading firmware onto it , bringing a device into debug mode and so on, then are "driven" partly by the generic application logic and partly by the script logic. So, the script take care for the rest, i. e. finding all relevant sections to be copied in the image and loading them to the correct addresses in the device.
- a hardware platform or a device 10 could be brought into a mode where it can be used for testing or debugging 15. This might involve writing "magic" values to certain device registers/memory locations or doing a proper authentication of the user, depending on the desired level of security.
- the host tool does not need to know the concrete steps: If the user wants to enable/activate debug mode 15, this request is passed through to the previously loaded script 11, which in turn runs the required steps for that particular piece of hardware.
- the host tool is providing appropriate (generic) interfaces 13, 14 towards the hardware 10.
- the script loaded before might implement certain higher level commands for driving such tests - keeping the interface on the tool level the same, even if depending on the concrete hardware different steps have to be taken. For example, on an FPGA platform some peripherals might not be present or located at different addresses.
- the embedded script 11 provides the interactions in an abstract way, the "end user" does not need to care - the actual mapping of the desired commands is done by the script delivered embedded in the firmware itself.
- the invention is targeted at internal use cases inside the development environment of embedded applications , i . e . hardware and firmware . It makes sense in proj ects where a certain variety of hardware platforms is expected over time and hence can reduce the overhead of rolling out new tool releases when something changes in the application interfaces .
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a method for an improved firmware deployment for any hardware platform. It relates also to a method which used a special firmware deployment bundle for a hardware platform generated by the previous mentioned method. The objective to provide a method that can establish an improved firmware deployment for any kind of hardware platform, so that host tools or a test framework do not need to be updated regularly, and firmware can be easily distributed to any kind of hardware platform, will be solved by creating dedicated firmware images for the hardware platform by compiling and linking source files of an application on a host tool, building a firmware executable for the hardware platform, embedding additional information and hardware platform specific logic in the firmware images of said hardware platform, resulting in a special firmware deployment bundle, whereas the embedding is done by modifying executable and linkable format (ELF) files or by creating an archive file, and using the special firmware deployment bundle as an executable by the host tool for loading the firmware deployment onto the hardware platform and / or using it as an input for other host tools for firmware loading, debugging and / or test stimuli on the hardware platform.
Description
Method for an improved firmware deployment and its usage in embedded logic
The invention relates to a method for an improved firmware deployment for any hardware platform. It relates also to a method which uses a special firmware deployment bundle for a hardware platform generated by the previous mentioned method .
In computing, the Executable and Linkable Format (ELF) , is a common standard file format for executable files, object code, shared libraries, and core dumps. It was quickly accepted among different vendors of Unix systems. In 1999, it was chosen as the standard binary file format for Unix and Unix-like systems on x86 processors by the 86open pro ect .
By design, the ELF is flexible, extensible, and crossplatform. For instance, it supports different endiannesses and address sizes so it does not exclude any particular central processing unit (CPU) or instruction set architecture. This has allowed it to be adopted by many different operating systems on many different hardware platforms .
Each ELF file is made up of one ELF header, followed by file data. The data can include program header table, describing zero or more memory segments, section header table, describing zero or more sections and data referred to by entries in the program header table or section header table.
The segments contain information that is needed for run time execution of the file , while sections contain important data for linking and relocation . Any byte in the entire file can be owned by one section at most , and orphan bytes can occur which are unowned by any section .
The ELF file format can be seen as a basis for distributing compiled applications and embedded systems . In the domain of embedded application development , a developer often faces challenges interfacing with the overall system, i . e . hardware and firmware running on it . Usually, such a system is proprietary and - in order to protect the internals - utili zes mechanisms to prevent unauthori zed third parties from interacting with it in an unconstrained way .
For example , during the development phase of such a system, it is desirable to be able to access the internal memories , read data directly from it or write into the memories to trigger actions , for example in the scope of a system test . However, such memory accesses are not wanted in an end user scenario . In order to allow access to developers , the system has to be brought into a "debug mode" , which usually involves running through a predefined protocol and authenticating .
On the other side , especially during the very early development of such an embedded application, the concrete protocol might not be fixed : It might be brought up first , be slightly changed over time or even be redone entirely . This , however, poses challenges on accompanying tools which e . g . need to know this protocol and run through it in order to do their work . For example , a test framework which shall test the overall functionality of the application would
first need to unlock the device before being able to do its testing . But whenever there is a change in the protocol , also that test framework must be updated .
Another typical challenge is with platforms for rapid application development . When designing an application which consists of hardware and software , it is common to prototype it using e . g . FPGAs . However, interfaces for enabling "debug mode" on an FPGA and later on dedicated hardware usually di f fer . Even more , an FPGA platform might require " special" treatment . For example , using ROM is a standard approach . While ROM content is created once and then put into hardware for the final product , an FPGA does not have such " fixed" contents . Instead, an application loader, which later on uploads the firmware into an FPGA prototype might have to take care to also load such ROM contents - which clearly is not the case when running on dedicated hardware .
The common issue with these use cases is variance : Depending on which concrete hardware platform and version is used, protocols and interfaces for doing the most basic interactions between a user/application and the system are di f ferent . The common approach to handle it is put additional logic into the applications which have to interact with a concrete device . However, this in turn has disadvantages , as then the tools must be updated regularly as otherwise interactions might not be possible or even might cause real damage , e . g . i f there was a change in the protocol and an application on the host side still uses an old version of it , which then might cause e . g . wrong configurations to be written, in the worst case in a non- recoverable manner .
It is therefore an obj ective of the present invention to provide a method that can establish an improved firmware deployment for any kind of hardware platform, so that host tools or a test framework do not need to be updated regularly, which keeps maintenance ef fort low and firmware can be easily distributed to any kind of hardware platform, and the risk of errors , e . g . wrong debug protocol in use , can be avoided .
The obj ective of the invention will be solved by a method for an improved firmware deployment for a hardware platform comprising the following steps :
- creating dedicated firmware images for the hardware platform by compiling and linking sources files of an application on a host tool ,
- building a firmware executable for the hardware platform,
- embedding additional information and hardware platform speci fic logic in the firmware images of said hardware platform, resulting in a special firmware deployment bundle , whereas the embedding is done by modi fying executable and linkable format (ELF) files or by creating an archive file ,
- using the special firmware deployment bundle as an executable by the host tool for loading the firmware deployment onto the hardware platform and / or using it as an input for other host tools for firmware loading, debugging and / or test stimuli on the hardware platform .
The basic idea of the invention is to create an application binary during building a concrete firmware version, which knows the hardware platform it will be running on . So , the inventive approach can be reali zed in two steps : Firstly, to create a special firmware deployment and secondly,
additional information and logic embedded in the deployment is used .
Usually, firmware is built for a speci fic platform, either for real hardware or an FPGA. And it is also built with support for a very speci fic version of the hardware platform . So all the knowledge required to interact with the overall system can be encoded into the application binary . A hardware platform in the sense of this application is understood as a real hardware , e . g . out of silicon, or a field-programmable gate array ( FPGA) .
As mentioned above , firmware usually is distributed in the form of compiled machine code for a particular hardware platform, so it cannot be executed directly on a host system from where a system should be debugged or tested . To work around this , a platform agnostic representation of the " interface logic" is combined with the firmware executable .
This is a main advantage over the methods known so far . Only a single arti fact has to be passed on : The firmware executable ( also named as firmware image ) with embedded interface logic as additional information and hardware platform speci fic logic . This combined arti fact is then used both for loading the firmware onto a hardware platform, hence any kind of device , as well as an input for host tools to talk to said device , e . g . for firmware loading, debugging, test stimuli and so on . This reduces the risk of errors , e . g . a wrong debug protocol in use . Additionally, due to the fact that the actual logic for interfacing with the hardware platform is part of the firmware image , host tools do not need to be updated regularly, which keeps maintenance ef fort low and also contributes to fewer
problems due to outdated tool versions in the infrastructure .
In a variant of the inventive method, the additional information and hardware platform speci fic logic comprise interfacing information of the hardware platform .
Any hardware platform or device speci fic logic can be implemented in the firmware images or firmware executable as additional information .
In another variant of the inventive method, the hardware platform is a hardware device or an FPGA.
Depending on the hardware platform special treatments of said hardware platforms are required . E . g . using an FPGA requires loading and updating ROM content as mentioned above . This can be easily solved by the inventive method, as all required treatment will be considered by the embedded additional information and is handled by the embedded script explained later .
In a further variant of the inventive method, the special firmware deployment bundle comprises a complete host tool , where a load and test application is built and published with each firmware build .
This variant could be an alternative approach, hence to deliver the complete host tools which are required with each firmware . So a load & test application could be build and published with each firmware build . However, this could pose problems as this application would need to be installed with each firmware version or at least it would be required to ensure that the application can be run in place . Depending
on the complexity of the overall proj ect setup, this could be di f ficult to achieve .
The inventive method that solves the above mentioned obj ective can be used on the consuming side in a very advantageous way . The further inventive method which uses the special firmware deployment bundle for a hardware platform generated by the method according to claims 1 to 4 , comprises the following steps or is performed in the following way :
- Extracting an embedded script out of the generated special firmware deployment bundle and loading it into a runtime of a host tool ,
- Interacting of the host tool with a hardware platform by forwarding any speci fic requests configured by the previously loaded script , wherein the host tool only provides interfaces for copying over said requests , wherein any mapping of desired commands or requests is done by the loaded script , which is delivered embedded in the special firmware deployment bundle .
In order to load the embedded script and run tests on the hardware platform later on, a host tool is needed which extract the embedded script and load it into the runtime of the host tool . The runtime or runtime environment of a host tool is understood as a program with which applications can be made executable in an unfamiliar environment by mediating between the application program and the operating system, hence the hardware platform . A host tool is usually a script engine for executing the chosen language , e . g . a JavaScript engine .
As soon as the host tool has extracted the embedded script ,
the host tool can interact with the hardware in question, forwarding any speci fic requests to the previously loaded script . This can already start with the loading procedure : Depending on whether the firmware is loaded onto an FPGA prototype or a silicon device , a special treatment for ROM contents might be added . On the silicon device , nothing is to do , but for the FPGA the ROM contents might be loaded from the firmware image and put in into the device memory on every load .
Instead of having the host tool to take care for this , the previously running script will carry out the required steps . As the script knows to which platform it belongs due to the added additional information and hardware platform speci fic logic, it can execute the right steps for it without any further ado . The only thing required for it to work is , that the host application needs to provide an interface for copying over the data, e . g . one for reading the compiled machine code from the image and one for writing the data into device memory . The script will then take care for the rest , i . e . finding all relevant sections to be copied in the image and loading them to the correct addresses in the device .
In a variant of the inventive method using the improved firmware deployment for a hardware platform, the method comprises a further step, where the hardware platform is brought into a mode for testing by enabling a debug mode through to the previously loaded script provided by interfaces of the host tool to the hardware platform .
As previously mentioned above , as soon as the host tool has extracted the embedded script , the host tool can interact
with the hardware in question, forwarding any speci fic requests to the previously loaded script . Bringing a hardware platform or a device into a test or debug mode , this might involve writing "magic" values to certain device registers/memory locations or doing a proper authentication of the user, depending on the desired level of security . Here as well , the host tool does not need to know the concrete steps : I f the user wants to enable debug mode , this request is passed through to the previously loaded script , which in turn runs the required steps for that particular piece of hardware . Here as well , as that is needed from the host tool is providing appropriate ( generic ) interfaces towards the hardware .
In a further variant of the inventive method using the improved firmware deployment for a hardware platform, the method comprises a further step, where the hardware platform is brought into a system test mode by implementing higher level commands by the previously loaded script for controlling said system test mode , wherein the interfaces between the host tool and the hardware platform remain the same .
When interacting with the device , e . g . during a system test , the script loaded before might implement certain higher level commands for driving such tests - keeping the interface on the host tool level the same , even i f depending on the concrete hardware di f ferent steps have to be taken . For example , on an FPGA platform some peripherals might not be present or located at di f ferent addresses . By having the embedded script providing the interactions in an abstract way, the end user does not need to care - the actual mapping of the desired commands is done by the script delivered
embedded in the firmware itsel f .
The inventive methods will be described in more detail using exemplary embodiments .
The appended drawings show
Fig . 1 Inventive workflow for creating a special firmware deployment bundle with embedded additional information and hardware platform speci fic logic according to the invention;
Fig . 2 Workflow for using the inventive special firmware deployment bundle with embedded additional information and hardware platform speci fic logic according to the invention .
Figure 1 shows the inventive workflow 1 for creating a special firmware deployment bundle 7 with embedded additional information and hardware platform speci fic logic, one workflow path for using an FPGA hardware platform and one path for using a hardware platform implemented as real silicon device . Typically, a firmware for an embedded platform is written in a language like C or C++ . During the build of the firmware , source files 2 of the application are taken and compiled and linked 3 into dedicated firmware images 4 . Usually, for such languages , it is common to build platform speci fic versions for the various concrete hardware platforms that need to be supported . As shown in the examples , i f the application needs to run on both an FPGA prototyping platform as well as , later during the development , a "real" silicon device , two speci fic firmware executables need to be built , each having the inherent knowledge about which platform it belongs to "built-in" .
To aid loading and debugging these applications later on, the state-of-the-art workflow is extended by an additional step 6 , where device speci fic logic 5 is embedded into the firmware images . This can be done by modi fying ELF files , assuming that this format is used for delivery, or by creating an archive file , e . g . a zip file , which contains both the firmware image itsel f as well as the additional logic .
Often, the di f ferences between platforms are quite large , so it makes sense to have the power of a high language available to represent it . For this reason, a high level programming language like JavaScript or Lua is chosen, which are typical "extension languages" for host applications , for example , JavaScript is commonly used in Web Browsers to allow web sites to provide advanced user interfaces . They typically have a very limited " standard library" available and cannot access the file system freely . Instead, the host application must provide interfaces to the script being run i f such accesses are allowed .
Figure 2 shows a workflow 8 for using the inventive special firmware deployment bundle 7 with embedded additional information and hardware platform speci fic logic on the consuming side . The embedded logic is used as described in the following .
The starting point is the firmware image with the embedded additional information and hardware platform speci fic logic, e . g . a debug logic, forming the special firmware deployment bundle 7 . In order to load this script file and run tests on the hardware platform later on, a tool on the host , which runs the following steps , is needed :
First , the embedded script logic is extracted and loaded into the runtime of the host tool , whereas the steps marked with reference signs 9 , 12 and 15 are basically actions that the host tool carries out by using the logic from the extracted script logic . The host tool usually will be a script engine for executing the chosen language , e . g . a JavaScript engine . From now on, the host tool can interact with the hardware platform 10 in question, forwarding any speci fic requests to the previously loaded script 11 .
For example , the script can already start with the loading procedure : Depending on whether to load the firmware onto an FPGA prototype or a silicon device , e . g . a special treatment for ROM contents has to be added . On the silicon device , nothing is to do , but for the FPGA the ROM content has to be loaded from the firmware image and put in into the device memory on every load 12 .
Instead of having the host tool to take care for this , the previously running script 11 will carry out the required steps . As the script 11 knows to which hardware platform 10 it belongs due to the added additional information ( as the script is basically the added additional information) and hardware platform speci fic logic, it can execute the right steps for it without any further ado . The only thing required for it to work is , that the host application needs to provide an interface 13 , 14 for copying over the data, e . g . one 13 for reading the compiled machine code from the image and one 14 for writing the data into device memory . So actually, the host tool extracts the device speci fic logic and loads it into some "execution engine" ( e . g . a JavaScript engine ) . Steps that require device interaction, like loading firmware onto it , bringing a device into debug
mode and so on, then are "driven" partly by the generic application logic and partly by the script logic. So, the script take care for the rest, i. e. finding all relevant sections to be copied in the image and loading them to the correct addresses in the device.
In a next possible step, a hardware platform or a device 10 could be brought into a mode where it can be used for testing or debugging 15. This might involve writing "magic" values to certain device registers/memory locations or doing a proper authentication of the user, depending on the desired level of security. Here as well, the host tool does not need to know the concrete steps: If the user wants to enable/activate debug mode 15, this request is passed through to the previously loaded script 11, which in turn runs the required steps for that particular piece of hardware. Here as well, as that is needed from the host tool is providing appropriate (generic) interfaces 13, 14 towards the hardware 10.
Finally, the same is true when later on interacting with the device, e. g. during a system test 16. The script loaded before might implement certain higher level commands for driving such tests - keeping the interface on the tool level the same, even if depending on the concrete hardware different steps have to be taken. For example, on an FPGA platform some peripherals might not be present or located at different addresses. By having the embedded script 11 providing the interactions in an abstract way, the "end user" does not need to care - the actual mapping of the desired commands is done by the script delivered embedded in the firmware itself.
The invention is targeted at internal use cases inside the development environment of embedded applications , i . e . hardware and firmware . It makes sense in proj ects where a certain variety of hardware platforms is expected over time and hence can reduce the overhead of rolling out new tool releases when something changes in the application interfaces .
Method for an improved firmware deployment and its usage in embedded logic
List of Reference Signs Workflow for creating a special firmware deployment bundle Source files Compiling and linking step Dedicated firmware image per supported type or hardware Additional information and hardware platform speci fic logic Embedding additional information and hardware platform speci fic logic step special firmware deployment bundle workflow for using the special firmware deployment bundle read loader and debug script from the special firmware deployment bundle 0 hardware platform, e . g . silicon or FPGA 1 hardware speci fic script logic ( running e . g . in a script logic ) 2 load firmware onto a device 3 interface for reading data from the executable file by the script 4 interface for writing data onto the device by the script5 activate test/debug mode 6 run system test
Claims
Method for an improved firmware deployment and its usage in embedded logic
Claims . A method for an improved firmware deployment for a hardware platform ( 10 ) comprising the following steps :
- creating dedicated firmware images for the hardware platform by compiling and linking sources files ( 2 ) of an application on a host tool ,
- building a firmware executable for the hardware platform ( 10 ) ,
- embedding additional information and hardware platform speci fic logic in the firmware images of said hardware platform, resulting in a special firmware deployment bundle ( 7 ) , whereas the embedding is done by modi fying executable and linkable format , ELF, files or by creating an archive file ,
- using the special firmware deployment bundle ( 7 ) as an executable by the host tool for loading the firmware deployment onto the hardware platform ( 10 ) and / or using it as an input for other host tools for firmware loading, debugging and / or test stimuli on the hardware platform . . The method for an improved firmware deployment according to claim 1 , wherein the additional information and hardware platform speci fic logic comprise interfacing information of the hardware platform ( 10 ) . . The method for an improved firmware deployment according
to claim 1 , wherein the hardware platform ( 10 ) is a hardware device or an FPGA. The method for an improved firmware deployment according to claim 1 , wherein the special firmware deployment bundle ( 7 ) comprises a complete host tool , where a load and test application is built and published with each firmware build . A method for using a special firmware deployment bundle for a hardware platform generated by the method according to claims 1 to 4 , the method comprising the following steps :
- Extracting an embedded script out of the generated special firmware deployment bundle ( 7 ) and loading it into a runtime of a host tool , Interacting of the host tool with a hardware platform ( 10 ) by forwarding any speci fic requests configured by the previously loaded script , wherein the host tool only provides interfaces for copying over said requests , wherein any mapping of desired commands or requests is done by the loaded script , which is delivered embedded in the special firmware deployment bundle ( 7 ) . The method for using the improved firmware deployment for a hardware platform according to claim 5 , wherein the method comprises a further step, where the hardware platform ( 10 ) is brought into a mode for testing by enabling a debug mode through to the previously loaded script provided by interfaces of the host tool to the hardware platform ( 10 ) .
18 The method for using the improved firmware deployment for a hardware platform according to claims 5 or 6, wherein the method comprises a further step, where the hardware platform (10) is brought into a system test (16) by implementing higher level commands by the previously loaded script for controlling said system test, wherein the interfaces between the host tool and the hardware platform (10) remain the same.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP20213564.6 | 2020-12-11 | ||
EP20213564 | 2020-12-11 | ||
EP21181488.4A EP4012566A1 (en) | 2020-12-11 | 2021-06-24 | Method for an improved firmware deployment and its usage in embedded logic |
EP21181488.4 | 2021-06-24 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022122946A1 true WO2022122946A1 (en) | 2022-06-16 |
Family
ID=79171329
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2021/085037 WO2022122946A1 (en) | 2020-12-11 | 2021-12-09 | Method for an improved firmware deployment and its usage in embedded logic |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2022122946A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117075958A (en) * | 2023-10-16 | 2023-11-17 | 广东优力普物联科技有限公司 | Firmware generation method suitable for multiple models, storage medium and electronic equipment |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130080832A1 (en) * | 2011-09-23 | 2013-03-28 | Roche Diagnostics Operations, Inc. | Protocol independent interface supporting general communications interface debugging and testing tool |
CN111352668A (en) * | 2020-02-27 | 2020-06-30 | 珠海格力智能装备有限公司 | Device testing method and device based on plug-in and testing system based on plug-in |
-
2021
- 2021-12-09 WO PCT/EP2021/085037 patent/WO2022122946A1/en active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130080832A1 (en) * | 2011-09-23 | 2013-03-28 | Roche Diagnostics Operations, Inc. | Protocol independent interface supporting general communications interface debugging and testing tool |
CN111352668A (en) * | 2020-02-27 | 2020-06-30 | 珠海格力智能装备有限公司 | Device testing method and device based on plug-in and testing system based on plug-in |
Non-Patent Citations (2)
Title |
---|
ANONYMOUS: "GNU Debugger - Wikipedia", 2 December 2020 (2020-12-02), pages 1 - 6, XP055868891, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=GNU_Debugger&oldid=991913885> [retrieved on 20211203] * |
TYLER HOFFMAN: "gdbundle - GDB and LLDB's Missing Plugin Manager | Interrupt", 14 April 2020 (2020-04-14), pages 1 - 16, XP055868749, Retrieved from the Internet <URL:https://interrupt.memfault.com/blog/gdbundle-plugin-manager> [retrieved on 20211202] * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117075958A (en) * | 2023-10-16 | 2023-11-17 | 广东优力普物联科技有限公司 | Firmware generation method suitable for multiple models, storage medium and electronic equipment |
CN117075958B (en) * | 2023-10-16 | 2024-01-23 | 广东优力普物联科技有限公司 | Firmware generation method suitable for multiple models, storage medium and electronic equipment |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10019256B2 (en) | Systems and methods for incremental software development | |
US11354144B2 (en) | Java native interface and windows universal app hooking | |
US7263689B1 (en) | Application program interface for dynamic instrumentation of a heterogeneous program in a distributed environment | |
US8745643B2 (en) | Method and arrangement for re-loading a class | |
US10331425B2 (en) | Automated source code adaption to inject features between platform versions | |
US20160232017A1 (en) | System and Method for Reloading Constructors | |
US7805717B1 (en) | Pre-computed dynamic instrumentation | |
US7409675B2 (en) | Code rewriting | |
Hayden et al. | State transfer for clear and efficient runtime updates | |
US11507362B1 (en) | System and method for generating a binary patch file for live patching of an application | |
US8843920B2 (en) | Systems and methods for deferring software implementation decisions until load time | |
US9459986B2 (en) | Automatic generation of analysis-equivalent application constructs | |
Yadavalli et al. | Raising binaries to llvm ir with mctoll (wip paper) | |
JP2000181725A (en) | Method and system for altering executable code and giving addition function | |
JP7042270B2 (en) | Self debugging | |
Cook et al. | Model checking boot code from AWS data centers | |
US9411617B2 (en) | System and method for matching synthetically generated inner classes and methods | |
EP4012566A1 (en) | Method for an improved firmware deployment and its usage in embedded logic | |
WO2022122946A1 (en) | Method for an improved firmware deployment and its usage in embedded logic | |
WO2008073044A9 (en) | Method and arrangement for software dependency resolution | |
Hoque et al. | Webassembly for edge computing: Potential and challenges | |
Olivier et al. | A syscall-level binary-compatible unikernel | |
Kang | Function call interception techniques | |
CN113454606B (en) | Software checkpoint-recovery between different compiled executables | |
Kotselidis et al. | Cross-ISA debugging in meta-circular VMs |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21835257 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 21835257 Country of ref document: EP Kind code of ref document: A1 |