Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I'd like to run a Debian OS .iso image for ARM processors using QEMU in a host running Ubuntu (over an x86 architecture).
I executed the following line in a terminal:
aaron#aaron-HP-ZBook-14:~/Descargas$ qemu-system-arm -machine sabrelite -cdrom debian-10.7.0-arm64-netinst.iso -m 1024
But then, the following window appears.
https://i.stack.imgur.com/rB2PZ.png
I don't know why Debian OS is not initiating after executing the previous line. Instead, a QEMU command line interface appears waiting for the user to enter some commands.
Thanks in advance!
Aarón.
You're trying to boot a 64-bit Arm CDROM image on a board which is 32-bit only, so this is never going to work.
More generally, most Arm boards will not simply boot from a CDROM image passed via the -cdrom option, because they don't have firmware/BIOS images which will run on QEMU and do the handling of booting from CD. Many boards don't even have an IDE or SCSI interface that a CDROM drive could be plugged into!
You should decide whether you want (a) to boot an image on the sabrelite board, (b) to boot a 32-bit arm image, but you don't care which board (c) to boot an arm64 kernel, and find a suitable tutorial or set of instructions accordingly. Lenna's link is good for option (b); there's a similar tutorial also for option (c). I don't know of any sabrelite specific instructions.
It's worth reading the QEMU documentation section on choosing an Arm board model -- unless you have a strong reason why you want to use a particular board model and a kernel that you know works on that board model, then 'virt' is usually a better choice. Even 'virt' won't boot directly off a cdrom, though, unless you also pass it a suitable UEFI bios image.
Generally if you try to run qemu and only see the monitor there is likely something wrong with your image.
In this case you are attempting to boot "debian-netinst" which is the debian network-install image. If you want to emulate a debian-arm image I would recommend following this tutorial to get debian-arm up and running.
Here is a script that will automate the process in that tutorial
The script runs two QEMU commands. The first is a lengthy install process that should extract a debian initrd/kernel. The second QEMU command will boot the actual image. After the second command runs you should see the QEMU monitor open in a window. Use ctrl+alt+(1 or 2) to switch to the terminal/gui display
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I programmed a little code for motion detection device(DA14531 SmartBond TINY module based on a CortexM0+) and I am having some experiments with it. at the end and after debugging and testing, I generated an ISO file and now I want to flash the device. Is the process similar to burning the ISO file on a USB flash or is the process different? I only have one device and I dont want to do something irreversible so I came here for some guidance first.
I looked online for a while but nothing matches my specifique situation, so providing me with the correct links is also helpful
The ISO 9660 format was designed for optical disks, using it is likely irrelevant to your use case, since there is IMHO a near to zero chance you will find a tool that will allow you to flash directly your program in a Cortex-M0+ device from a file in ISO 9660 format.
And if you may flash the ISO file as is in your Cortex-M0+ flash memory, your device will likely be unable to boot since it does rely on very specific information (stack pointer, first instruction to be executed) to be flashed in a verify specific location, not mentioning the waste of flash memory space this would cause.
That is, if Dialog documentation does not specifically mention the possibility of flashing a file in ISO 9660 format, this is likely (and not surprising) that this is not possible using Dialog software and hardware support tools.
So when you read the documentation for this product you noticed there is an SWD interface which is certainly one way into the part. When you further examined the pro kit and other solutions from them you see they mention segger jlink interfaces for debugging etc. Further reinforcing SWD as at least one interface into the part. Through that interface (SWD is ARM) you access the flash controller (has nothing whatsoever to do with arm it is chip specific) and through that you write your application binary that the part will run (the machine code and data that the processor uses, your application).
ISO is closely related to PC's with a BIOS/EFI which also means x86, and has nothing whatsoever to do with a microcontroller much less a non x86, non BIOS/EFI PC/Laptop. It is extremely unlikely that you can get enough software on a cortex-m0(+) based platform that if you had an interface to media that can hold it that you could parse it and extract anything useful, and then have resources left to load and execute any programs in ram. No way whatsoever in any part I have heard of that you could do this in ram such that you could extract something you could load to the flash on the part. Plus you have to get that program into the part before you can then later support ISO, if you could, which you can't.
The only remote way an ISO makes any sense at all or has any context is if on your PC you boot off of an ISO image and that ISO image for the PC (not the mcu) contains a development system. For example a pre-prepared Linux operating system distro with the tools from the vendor for this part so that you don't have to install the development system on your computer you can run it off a ramdisk using a live image on an ISO. That development system would not use ISO files but the proper file formats to develop binaries and load them to the board via SWD or some other chip/board specific interface.
Beyond that there is no further reason to talk about ISO's and microcontrollers.
Some chip vendors (not arm, the chip vendor) may also provide a factory bootloader or logic that supports for example a uart, maybe spi, maybe i2c, maybe usb interface that you can use chip (not arm) specific software to talk to software running on that chip (the bootloader) that can then write to the flash. You can also write your own bootloader if there are enough resources in the system. The (arm based) mcu world is moving away from these bootloaders, two of the three main companies that used to always have them have started to remove them or disable them as a default feature.
Other companies provide no other interface than SWD to program the part, SWD or nothing. Certainly in the cortex-m0+ market where every penny counts and the extra flash for a bootloader and extra chip real estate, etc add to the overall cost for a legacy feature that is becoming less important because developers can now easily obtain SWD interface modules for a few dollars. It is not like the old days where a JTAG board cost $2000. At this time all cortex-m parts support SWD, making it the most useful interface and reminding developers that having tools that can access that interface being worth the ($5, plus time to learn to use it) investment.
The tools used to write the flash dictate what file formats are supported, these days a raw binary image or an elf file format are the main two. The old days included file formats like Intel hex and Motorola s-record but it is only old timers like me that favor those file formats, even though an elf is trivial to parse, and a raw binary image even simpler, about four lines of code.
Some chip vendors do not provide enough information to roll your own, but most often they do. Arm long ago released the SWD interface information, so it is technically possible to roll your own and then support whatever file format you want. But you would have to distribute this tool along with the ISO file, so you would what use a second ISO file to distribute the tools to read the first one. Based on your question and comments you are a long long way from writing tools like these. Especially when working tools like openocd exist that support the main file formats (elf and raw binary) and can speak SWD into the current line of cortex-m cores.
Again if you are suggesting using an ISO to distribute tools along with your binary to be loaded and run on a PC that might make sense, but it is easier for the end user to simply download the tools from the chip vendor or tools vendor and then download the binary file from you, rather than put in the extra work to deal with an ISO.
How to run a virtual machine with qemu on an Ubuntu 18.04 x86_64 host system, when I want the guest system to be ARMv8 (Raspberry Pi 3, more specifically interested in the Cortex A53 processor)?
Background:
I want to compile a project for a real machine with ARMv8 on the mentioned host system. Currently, this is done with cross compile directly in the host system. For many different reasons, I want to set up a virtual machine which compiles binaries (virtually) native for the ARMv8. The binaries need to be runable on the real ARMv8 machine later.
Apart from Qemu and the right qemu-system-aarch64 to be installed on the host system, there is an image of the operating system needed. Ideally the same as the one running on the real ARMv8 device. The Ubuntu IoT Core 18.04 64-bit is available at https://ubuntu.com/download/raspberry-pi and I saved it to a local folder with the name ubuntu18045arm64rpi3.img.xz.
After extracting it, I got the extracted image 'ubuntu18045arm64rpi3.img'
To start a virtual machine with the given image and the wanted architecture, I type this:
sudo qemu-system-aarch64 -m 1024 -cpu cortex-a53 -M virt -drive if=none,file=ubuntu18045arm64rpi3.img,id=hd0
which gives me a window like that:
Now my main questions are:
I expected a virtual machine to boot up, where I can install the OS from the given image. What did I do wrong or how to achieve this goal?
Later on, I want to install a compiler (if not already there) on the guest ARMv8 machine and compile my project there. Afterwards I plan to transfer the compiled binaries to the real ARMv8 machine and expect them to run without difficulties. Is this possible with the current approach?
You can't just pass a disk image to the aarch64 QEMU and have it boot. You need to either pass a kernel to boot, or a BIOS (probably UEFI) image (which can then read a kernel off a disk image).
This blog post has an example of running Debian on QEMU; getting Ubuntu booting is probably similar.
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
Your link is to a raspberry pi specific disk image -- since you are not asking QEMU to model a raspberry pi board I would recommend against using that. You want whatever Ubuntu provides as their most normal/generic aarch64 image. If you're going the "boot via UEFI" route then you want a disk image intended for SBSA/UEFI systems.
On your second question about portability of compiled binaries, this is the same as for any two Linux systems, really. If the two systems have the same OS/distro version (so they have the same library versions etc), and the same sets of runtime libraries installed, and you didn't tell the compiler to compile to use CPU features that the destination CPU doesn't have, then it should work.
Compiling inside this emulated setup is going to be significantly slower than either your current cross-compile setup or compiling the binaries directly on the real AArch64 hardware, incidentally.
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.
tl;dr - How do I build a Linux kernel from source for the beagle bone (white), install it, then debug it?
I am trying to break into kernel hacking - specifically porting an experimental kernel feature that has been implemented on x86 over to ARM. I chose the Beagleboard white as a development platform because of the built in J-Tag over USB.
I want to get a development environment set up using openocd and gdb so that I can debug running kernels, and nail down a routine for building Linux from source and installing it onto the beagle board. I have truly scoured the internet and although I feel like all of the pieces may be out there somewhere, I'm having trouble putting everything together.
I hope that responses to this question might be a roadmap for those who come after me and want to start doing some kernel development on ARM.
Thanks!
Things I have tried:
I have NOT tried CCS5 because, as far as I can tell, it is not open source, does not have a command-line interface, and is not fully supported on Linux.
I HAVE run openOCD. I can halt and resume the processor on the beagle bone through a gdb session connected to the OpenOCD process. I have NOT been able to load any meaningful symbol table into that GDB session and therefore have not been able to break on a system call (a milestone I am shooting for).
I HAVE installed many premade kernel images onto the beagle board and have run through the tutorial at http://eewiki.net/display/linuxonarm/BeagleBone, but it did not start from stock linux and hid the necessary configuration options to build for the BeagleBone.
I understand my question is broad, but I asked that way by design in the hopes that people who come after me can find a solid starting point rather than specific snippets of info from people who are stuck at various points along the process. If that is not the proper way to use SO, my sincerest apologies.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I followed these instructions and was successfully transmitting IEEE 802.15.4 frames on a GINA Mote. I know it was working because I have a packet sniffer that captured transmitted packets.
Here is the source code: https://github.com/openwsn-berkeley/openwsn-fw/tree/d1ec9982fbc101061b4bc70bde239e54cd1367c4/firmware/openos/bsp/boards/gina
I'm a little confused how and why it's working though. Is this code loading an operating system (like RTOS) on the Gina mote or is this project OS-less ?
I'm looking for a solution that does not require an OS / bootloader.
I would appreciate if one of the experts in the community could weigh in on this.
The JTAG adapter rams the executable image up the MSP430 processor's butt, sets up the MSP430 to start executing at the image's start address, and lets 'er rip. That's it. There ain't no OS, and there's no code onboard the little processor board required for loading the executable image. Your program is the only code it ever knows. (And the JTAG adapter probably burns the code into the processor's flash, so it stays resident even when the JTAG adapter is removed.... and starts executing again any time the processor is reset.)
Now, you may wonder... There may be C runtime facilities available that you might think are associated with an operating system... perhaps printf(), malloc(), new, etc. Those are part of the C runtime & I/O subsystem, and can of course be implemented for a custom platform with no OS.
UPDATE: Hmm. What I mentioned above was true when I played around with small MSP430's back in 2008. At that time I only recall IAR, I don't recall there being mspgcc. I believe the IAR solution is as I described above. The mspgcc solution seems to involve a "BSL" (bootstrap loader), per this web page. Or perhaps the BSL is just pre-loaded on the MSP430, and even IAR uses it... I dunno. In any case, with either the IAR or mspgcc toolchain, ultimately you should be able to burn your program into the processor's built-in flash, and once burnt into it, you can remove your JTAG programming/debugging adapter, and from then on, the CPU will automatically run your program every time it boots.