Is there a way in vxWorks-7 to restart to the bootloader, we are using u-boot. We have a hardware issue with our current board, and would like to jump to u-boot to restart the bard instead of power cycling it.
Dennis
A methode is maybe to use the reboot() function on console (that of course can also be used from code).
If the BSP implementation is okay, it should restart without a power-cycle.
At least that works for us -> VxWorks7 with an ARM system. But i have to say, we are not using u-boot (we are using barebox).
Related
I have Fedora installed on my PC and I have a Friendly ARM Mini2440 board. I have successfully installed Linux kernel and everything is working. Now I have some image processing program, which I want to run on the board without OS. The only process running on board should be my program. And in that program how can I access the on board camera to take image from, and serial port to send output to the PC.
You're talking about what is often called a bare-metal environment. Google can help you, for example here. In a bare-metal environment you have to have a good understanding of your hardware because you have to take care of a lot of things that the OS normally handles.
I've been working (off and on) on bare-metal support for my ELLCC cross development tool-chain. I have the ARM implementation pretty far along but there is still quite a bit of work to do. I have written about some of my experiences on my blog.
First off, you have to get your program started. You'll need to write some start-up code, usually in assembly, to handle the initialization of the processor as it comes out of reset (or is powered on). The start-up code then typically passes control to code written in C that ultimately directly or indirectly calls your main() function. Getting to main() is a huge step in your bare-metal adventure!
Next, you need to decide how to support your hardware's I/O devices which in your case include the camera and serial port. How much of the standard C (or C++) library does your image processing require? You might need to add some support for functions like printf() or malloc() that normally need some kind of OS support. A simple "hello world" would be a good thing to try next.
ELLCC has examples of various levels of ARM bare-metal in the examples directory. They range from a simple main() up to and including MMU and TCP/IP support. The source for all of it can be browsed here.
I started writing this before I left for work this morning and didn't have time to finish. Both dwelch and Clifford had good suggestions. A bootloader might make your job a lot simpler and documentation on your hardware is crucial.
First you must realise that without an OS, you are responsible for bringing the board up from reset including configuring the PLL and SDRAM, and also for the driver code for every device on the board you wish to use. To do that required adequate documentation of the board and it devices.
It is possible that you can use the existing bootloader to configure the core and SDRAM, but that may not meet your requirement for the only process running on the board should be your image processing program.
Additionally you will need some means of loading and bootstrapping; again the existing Linux bootstrapper may suit.
It is by no means straightforward and cannot really be described in detail here.
I'm using Arm DS-5 and Xilinx SDK for developing programs on Zynq board.
I'm trying to boot Zynq 702 board from Qspi Flash.
What I've done so far is generating FSBL project from Xilinx SDK, and combining it with my application using Bootgen tool in SDK, then program it into the flash.
There are several questions in my mind.
DS-5 produces an .axf file, Bootgen requires an .elf file. Can I use
the .axf file by just changing its extension to .elf or do I require
some more steps?
Is there a tool that shows the inner structure of an .axf file?
Showing what is where?
And how can I debug if I managed to boot from QSPI. For example I want to debug my application from the beginning of FSBL, is it possible? Because in Qspi Boot, When I power on the board, my application would start running and when I connect with JTAG, it would be in somewhere in my application.
An AXF might have some extra ARM-toolchain magic in it (I'm not sure off-hand), but at heart it's an ELF file - the ARM toolchain provides fromelf for poking around inside them, but other tools like readelf and objdump also work.
I'm not familiar with the Zynq platform so I don't know any specific debugger tricks, but a general one is just to put an infinite loop at the start of your code (possibly using volatile or inline asm trickery if necessary to prevent optimisation) - once the debugger's connected and broken into it, you just move the PC past the loop and continue.
You can totally halt QSPI-booted Zynq via JTAG and do whatever you want with it. However, there are some quirks. Sometimes Zynq goes into some kind of lockup, and JTAG doesn't work at all, and you need to power-cycle before retrying. Some not-so-well-written peripherial might die after starting software over JTAG, so you might need to re-load bitstream first. And there are some Vivado-related bugs (like the one where you cannot re-flash the board unless you downgrade to 2017.2 or change MIO2-6 pulls or patch the FSBL) but i'm not sure if they apply in your case.
I've been following the "Mike OS Guide" to make my own kernel, and I got it working. But then I went onto the many guides on the internet for making a boot sector in NASM that loads a main function from a compiled C object. I have tried compiling and linking with all kinds of GCC installations:
x86_64-pc-linux-
arm-uclinux-elf-
arm-agb-elf-
arm-elf-
arm-apple-darwin10-
powerpc-apple-darwin10-
i686-apple-darwin10-
i586-pc-linux-
i386-elf-
All of them fail once I put them onto a floppy like I do with the MikeOS bootstrap. I've tried various tutorials on http://www.osdever.net/ like the one here and I've tried http://wiki.osdev.org/Bare_Bones , but none work when trying to compile on a Mac, yet I have not tired on an actual Linux machine yet. But I was wondering how I could get a bootstrap in assembly the calls the C function and put them together into a working kernel file and then load the onto a floppy file then onto an ISO like in the MikeOS tutorial. Or should I just make the kernel.bin and load it with syslinux? Could anyone give me a tip on how to make this all work on a Mac developement environment? I have tolls via macports and homebrew so that helps. Anyone successively done this?
EDIT
Here's my bootsector so far.
I just wanna know how to jump to an extern function from the C and link it.
There's a few problems with this. First of all, all the compilers you mentioned output either 32-bit or 64-bit code. That's great, but when the boot sector starts, it's running in 16-bit real mode. If you want to be able to run that 32-bit or 64-bit code, you'll need to first switch to the appropriate mode (32-bit protected mode for, well, 32-bit, and long mode for 64-bit).
Then, once you switch to the appropriate mode, you don't even have that much space for code: boot sectors are 512 bytes; two bytes are reserved for the bootable signature, and you'll need some bytes for the code that switches to the appropriate mode. If you want to be able to use partitions on that disk or maybe a FAT filesystem, take away even more usable bytes. You simply won't have enough space for all but the most trivial program.
So how do real operating systems deal with that? Real operating systems tend to use the boot sector to load a bigger bootloader from the disk. Then that bigger bootloader can load the actual kernel and switch to the appropriate mode (although that might be the responsibility of the loaded kernel — it depends).
It can be a lot of work to write a bootloader, so rather than rolling your own, you may want to use GRUB and have your kernel comply to the Multiboot standard. GRUB is a bootloader which will be able to load your kernel from the disk (probably in ELF format) and jump to the entry point in 32-bit protected mode. Helpful, right?
This does not free you from learning assembly, though: The entry point of the kernel must be assembly. Often, all it does is set up a little stack and pass the appropriate registers to a C function with the correct calling convention.
You may think that you can just copy that rather than writing it yourself, and you'd be right, but it doesn't end there. You also need assembly for (at least):
Loading a new global descriptor table.
Handling interrupts.
Using non-memory-mapped I/O ports.
…and so on, not to mention that if you have to debug, you may not have a nice debugger; instead, you'll have to look at disassemblies, register values, and memory dumps. Even if your code is compiled from C, you'll have to know what the underlying assembly does or you won't be able to debug it.
In summary, your main problem is not knowing assembly. As stated before, assembly is essential for operating system development. Once you know assembly thoroughly, then you may be able to start writing an operating system.
I'm new on OpenOCD, has anyone attempted to use Olimex OpenOCD to actually flash program hex file (from Kiel say) into ARM CORTEX M0 (generic).
What do I need to setup script file to take each word of the hex file to performs mww (memory write word) within the MCU flash?, can anyone provide an example. I use python.
I open for suggestion.
I use Window PC.
All Cortex M0 that I know of have no JTAG, but only SWD support. SWD is not yet available in OpenOCD - it is still in development.
Another note: The method for writing the flash memory is specific for each vendor/chip.
Sure, what platform in particular? some googling will find the exact sequence. flash unlock, erase, program, etc.
Section 6 of this page for example.
http://pygmy.utoh.org/riscy/cortex/led-lpc17xx.html
I am trying to figure out what board I did it on but those were pretty much the commands I followed and it worked just fine. It may have been the leaflabs maple mini. The steps are the same. To avoid the steps or scripting it, etc. what I ended up doing was writing a few lines of bootloader that said if ram+0 = 0x12345678, and ram+4 = 0x87654321 then branch to ram+8 else infinite loop. then it was trivial to use the jtag to load a program into ram with the two words and an entry point at 0x08 bytes into ram, press reset and run the program. On a cold power up it just hits the infinite loop. I spend my day on a bigger arm based system loading everything into ram using jtag so it made it quite comfortable. You could just script it in openocd and simply type the openocd command have the flash load happen.
Update for people stopping by...
You do not have to use mww, if you're just trying to flash-program (eg. upload your own code) to your microcontroller.
Some time ago, OpenOCD got a ("built-in") convenience-script, that you can use for programming, this "command" is called "program".
Here's an example from the documentation on the "program" command:
openocd -f interface/ftdi/jtag-lock-pick_tiny_2.cfg -f board/stm32f3discovery.cfg -c "program filename.elf verify reset"
-Replace "stm32f3discovery" by your board. If you use a different adapter, replace the interface with the appropriate configuration file.
I have done some hacking in windows interrupt table and trying to test it through an application. I don't want to put a break point in the kernel functions which gonna get invoked.(I have modified some of the first level interrupt handlers.) I want to start from the application and then wanna go to the actual hacked part of the code by single stepping. I wanna know if Windbg is good enough to do that? Can I put a breakpoint in my application and then go onto debug windows?
Thanks
You will need to use remote debugging (e.g, from a second computer) to single-step through the kernel. It is impossible to use breakpoints or single-stepping on the kernel of the local machine, as the debugger and other applications rely on the kernel to work.
http://support.microsoft.com/kb/151981