On AMVv7, I use U-boot as my bootloader.
Question
Once it has initialized my board, and put itself in the ram, can my code overwrite it?
(I will provide my vector table, my TLB logic and so on).
I read that a cpu reset won't need the full initialization u-Boot does.
The plan is to use U-boot and to ditch it completely once it has done its work (saving me to do it in the first place) and take full control of the board, without sacrificing any bit of ram.
What is the problem with that approach (if there is one)?
What you want to do is fine. This is for example how the Linux kernel operates as (generally speaking) nothing of U-Boot is around after U-Boot starts execution of whatever it has been told to load and execute.
If your application capable of handling your board functionality,then no need of worrying about u-boot, because once it execute load and execute, this RAM location is usable memory.
If you run your standalone program under u-boot program space, it cannot be overwrite by your program. if you try to overwrite, the board will reboot.
Related
I'm currently working on an IoT project and I want to log the execution of my software and hardware.
I want to log them then send them to some DB in case I need to have a look at my device remotely.
The wip IoT device will have to be as minimal as possible so the act of having to write very often inside a flash memory module seems weird to me.
I know that it will run the RTOS OS Nucleus on an Cortex-M4 with some modules connected through SPI.
Can someone with more expertise enlighten me ?
Thanks.
You will have to estimate your hourly/daily/whatever data volume that needs to go into the log and extrapolate to the expected lifetime of your product. Microcontroller flash usually isn't made for logging and thus it features neither enduring flash cells (some 10K-100K write cycles usually compared to 1M or more for dedicated data chips - look it up in the uC spec sheet) nor wear leveling. Wear leveling is any method which prevents software from writing to the same physical cell too frequently (which would e.g. be the directory for a simple file system).
For your log you will have to create a quite clever or complex method to circumvent any flash lifetime problems.
But the problems don't stop there: usually the MCU isn't able to read from Flash memory when writing to it where "writing" means a prolonged (several microseconds up to milliseconds depending on the chip) sequence of instructions controlling the internal Flash statemachine (programming voltage, saturation times, etc.) until the new values have reliably settled in the memory. And, maybe you guessed it, "reading" in this context also means reading instructions, that is you have to make sure that whichever code and interrupts that may occur during the Flash write are only executing code in RAM, cache or other memories and not in the normal instruction memory. It is doable but the more complex the SW system that you are running above the HW layer, the less likely it will work reliably.
I have an evaluation board (Olimex STM32-P103) which supports a SD-card connector. I want to put my program in to a SD memory instead of internal flash of the micro-controler; and run it from there.
I don't know if it is possible to do that according to boot-loader issue!
P.S my goal is running linux on this board and then port my application over it.
To run programs from SD-Card in general you should know that you can't run them "right away". This means, you have to load it in a executable memory somewhere in your address space which is done by a (more or less) simple bootloader. In the simplest instance, the bootloader is capable to read from a SD-Card a specific binary and copy it into the memory.
That being said you should think about this considering you only got 20k of RAM and 128k of Flash on your board. So where should your program go? Or better: Why not flashing the program in the 128k of Flash from the very beginning? Especially you should know that Linux is a bit "hungry" in terms of memory.
If your goal is to run a "normal" Linux on this board, I'm afraid you're screwed. This because from what I know Linux needs a MMU to run and the chip on this board does not provide one (as far as researchable without access to datasheets from ST).
If you're lucky you can go with uCLinux. I'm not sure if a finished port exists for the STM32 but it seems there are some resources based on a short google search for "STM32 uCLinux". But even if you manage to run uCLinux I'm afraid there's not much left in your system for your application, so the result might be a bit disappointing.
Depending on why you are looking for Linux running on this MCU, there are maybe other solutions like a FreeRTOS in combination with a lwIP-stack (if networking is needed) or a FAT library like FullFAT if you are looking for reading SD-Cards and stuff.
Edit: One thing i'd like to add is that booting from the SD-Card is typically something you do with "bigger" (not much but slightly) systems where you have enough RAM to keep the whole image you'd like to run in it and still have some space left for the data you want to process.
You're going to have to have some code in the STM's onboard flash (typically called a "boot loader") that implements this since the "bare metal" very likely can't boot from SD card.
You're going to have to build that code, which figures out how to use the STM's onboard peripherals to talk to the SD card, finds the file you want to run in the file system (which you also have to implement), and loads it.
I wanted to include a link to the STM standard peripheral library, but it seems to be down (being moved). :/
The data on the SD card is not memory mapped, so cannot be executed directly.
It is possible to dynamically load the data from the card into RAM for execution. WindRiver's VxWorks RTOS supports loading and linking object modules dynamically, I know of no other OS that would scale to a Cortex-M that directly supports that but it would be possible to write your own.
However, I would suggest that in the case of the microcontroller you are using the idea is ill-advised; optimal performance on Cortex-M is achieved when the code is in on-chip flash and data in RAM allowing the data and instruction to be fetch to occur simultaneously on the separate buses (Harvard architecture). If you execute the code from RAM the performance will be severely hit since then data and instructions must be fetched sequentially over the same bus.
The board is entirely unsuited to running Linux, with only 128K Bytes Program Flash, and 20K Bytes RAM is is not at all feasible. Even the smallest Linux distribution requires 600Kb RAM plus whatever is needed by application code. uClinux can just about run on higher-end STM32 with external RAM and Flash, but that would suffer from the same bus contention performance hit and Linux without an MMU is rather missing the one major benefit of using Linux at all. The part on your board lacks an external memory interface, so cannot be expanded to support Linux.
If you need an OS consider a RTOS such as uC/OS-II, FreeRTOS, or emBOS for example.
AS other says you cannot directly execute your code directly from the SD CARD.
But like those "linux board", you can load the stored kernel/programm into an external SDRAM that can be mapped and execute it from there.
You'll still need to write that "bootloader" and store it in the internal flash.
That'is a lot work to my opinion, for limited application.
If you want to write your application in a linux environnement then port it suck small target, I would rather design my application using dependency injection, or even use an emulator.
I've started writing a boot loader for my z80 system.
So far the program can accept hex via serial and load it to a location in the memory.
The problem I have though is the boot loader is at the start of memory and uses the interrupts,
How can I load a new program with out overwriting the boot loader?
(Also a loaded program might want to use the interrupts as well)
The best and most widely used approach is to split your app into a stable boot loader that is never updated, and the application that you can replace from time to time.
AFAIK, in Z80 there are just interrupt vectors and there no support for replacing them in the CPU itself. You need to have something in your hardware that will replace your memory blocks.
Othewise you need to have feature that bootloaders is not using anything in the app part during the download and block any interrupts that can call anything in the app.
W.r.t. locations, you may place the bootloader at the top of the address space and load a program at the beginning of the address space.
You can also include the location and size of the program in the protocol so the bootloader would be able to check whether the pair of values is compatible with the bootloader location and size (IOW, whether or not the program would overwrite the bootloader if loaded).
Another option is to include relocation information in the program and a simple relocator in the bootloader. That way you'd be able to load the program at any location if there's enough free memory. This is what many OSes do when they load programs.
As for the interrupts, I don't see a problem. Who or what is there not to allow the program to use interrupts? Or do you want the bootloader to say resident and either continue to do something in the background or be able to return to it from the program? If you don't need any of these, just let the program use the interrupts (you probably don't even need to do anything to allow that).
If, OTOH, you do want the bootloader to remain functional you can introduce an extra layer of indirection by maintaining an additional interrupt vector table. The primary ISRs would extract the secondary ISRs from this interrupt vector table and jump there. Your bootloader and program would then need to do this in order to add a new or override an existing ISR:
disable interrupts
get the old ISR address from the additional interrupt vector table
put the new ISR address into the table
enable interrupts
Removing an ISR is obvious and similar to the above.
The new ISR can then:
before doing its work call the old ISR (the address is preserved at step 2 above)
after doing its work call the old ISR
just do its work without calling the old ISR
You need to require that the programs and bootloader use this table and restore it when they no longer need to have their own ISRs in it.
I don't know what issues you may need to solve if you chain ISRs by executing the old ones before/after the new ones. But in some systems that's a possible design. Many x86 PC programs and drivers did that in MSDOS.
I'm working on a custom Cortex-M3-based device and I need to implement in-application programming (IAP) mechanism so that it will be possible to update the device firmware without JTAG (we'll use TFTP or HTTP instead). While the IAP-related code examples available from ST Microelectronics are clear enough to me, I don't really understand how the re-flashing works.
As far as I understand, the instructions are fetched by the CPU from the Flash through the ICode bus (and the prefetch block, of course). So, here's my pretty silly question: why doesn't the running program get corrupted while it re-flashes itself (i.e. changes the Flash memory from which it is being run)?
A common solution is to have a small reserved area in the flash, where the actual flashing program is stored. When new firmware has been downloaded just make a jump to the code in this area.
Of course, this small area is not overwritten when flashing firmware, it can only be done by other means (like JTAG). So make sure this flashing-program works good to start with. :)
I'm not familiar with STM implementation, but in NXP chips the IAP routines are stored in a separate, reserved ROM area which can't be erased by user code.
If you're implementing the flash writing code yourself by using HW registers directly, you need to either make sure that it doesn't touch the sectors it's running from, or runs from the RAM.
Now a days many micro-controllers supporting IAP, that it is possible to program its flash memory while program execution in the same flash.
For IAP, program memory in the flash may be divided into 2 parts, one executable & other backup parts.
Generally we program the flash memory at a location (say, part-1) through JTAG, whose firmware version is 0.01. For IAP, i.e, program the flash in another part (part-2) while code is executing, corresponding API's should be provide in firmware version 0.01, which helps to program the flash part-2, After completion of programming successfully firmware version will be updated as 0.02. Upon processor restarts, program execution jumps to latest firmware by checking firmware version at initialization.
The part where the firmware is executing is called executable part, and other is back-up. why it is called back-up mean, suppose if there exists any firmware corruption while programming, firmware version will not update & upon restart, program control will automatically jumps back to back-up firmware after checking version number.
Another good way to do it is using custom made bootloader. However STM IAP is not stored in Flash so it can not be overwritten by it self. What generally people do is to spilt the flash in two parts , one is reserved for Custom made Bootloader and Another is for application. Bootloader makes sure that it does not write to its own assigned area. Bootloader can be programmed through JTAG and later application can utilize bootloader to program itself.
As far as I understand, the instructions are fetched by the CPU from the Flash through the ICode bus (and the prefetch block, of course). So, here's my pretty silly question: why doesn't the running program get corrupted while it re-flashes itself (i.e. changes the Flash memory from which it is being run)?
This is because, in general case writing/programming to flash memory is not allowed while you are reading from it(i.e executing code).
Have a look at this for some ideas on implementing IAP.
I have been given a general explanation of how a computer boots up.
However a very loose definition to the term 'boot file' was given.
Could someone explain 'boot file' to me in a very simple but concise manner?
I have read about the POST, the clearing of registers, BIOS in the CMOS, etc.
What I understand is that the boot file is different to the boot program.
the boot program gets the system ready to accept an OS while the boot file contains some of the parameters by which the system will operate.
The boot program is stored on ROM and the boot file isnt?
cheers,
jazz
It really depends on what they meant by "boot file".
First of all, there's the code in the first sector of the partition that locates the OS kernel, copies it into memory, and gets it running.
Then there's the file on disk that actually has the kernel code, including the stuff that controls the boot process once the boot sector stub has loaded it into memory.
Which one did you want to know about?