I have an ARM kit beside me and a Linux kernel source code patched with Xenomai on my machine. I understand I can send data to the kit through an USB cable and a (windows-based, of course) software, but I'm stumped as to exactly what I should be sending that would make the kit run Linux.
(clarifications from comments: It is an Atmel AT91SAM9260-EK kit. It uses SAM-BA and SAM-PROG for the loading and unloading of data through either a serial or USB cable.)
I'd start with the ATM91SAM9 Linux software package from Atmel and follow the instructions.
Linky:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4335
Otherwise, you need to get GCC setup with an ARM back end on a Linux box, build a Linux binary and then figure out how to load it on the devt board.
You might want to check out some cross compiler like OpenEmbedded which will help you compile the kernel for the ARM architecture.
i would suggest jtag and openOCD, then you just use the JTAG to place your filesystem and kernal image in the flash memory, in a place wear our bootloader can find it. you might have to change your bootloader.
another option is you might start up your micro, then insert a bootloading program into the RAM of the program then change the program counter to point at it.
that bootloading program can init the UART/USB then you have a host side program that transers the files. this method is very complicated and generally only good if you don't want to spend 100$ on a jtag (hint, buy a jtag they are useful)
Related
I'm new to the Zynq devices and also to linux and the Yocto project.
I now have a project where I need to implement a custom FPGA IP block and use it from a yocto generated linux distribution.
Obviously I will have to write the linux drivers for that custom IP. But I'm not able to find a clear explanation how the workflow for such a project may look like.
I found some old tutorials but I'm not sure if they are still the way to go, so an up-to-date best practice workflow would be great.
What I did so far:
I created a test project in Vivado and created a small led example by passing through the FPGA block in a Microzed + carrier board.
Then I exported the HW from Vivado to get a BSP package I tested in a bare metal project with Vitis.
I installed Yocto and I build a reference distro for my microzed board with just a serial interface by following a tutorial online.All this comes more or less pre-backed from Xilinx.
But now I need to use a Yocto generated linux distro and enable it to use my custom (LED) IP.
My questions:
How does a detailed workflow in this case look like (at the end I
need a bootable SD card)?
More in detail:
How can I bring the mydevice_bsp generated from Vivado into the Yocto distro?
In which environment(how to write them i'll find out my self) do I write the
drivers for the yocto Linux and bring them into the distro?
How do I load the bitstream into the FPGA fabric when the Linux image has booted up?
Unfortunately I do not have to much time to get all this working, so it would be really cool to find a step by step tutorial from the start to the end.
Thanks in advance for your help.
Regards
Martin
I´m not sure if someone has written down a workflow for this, but I can tell you how I would handle it.
Create your IP code as hardware and use the IP packager to pack the code. You can also add some driver code too, so the SDK can use this to automatic generate the drivers. So you can use the regular workflow in Vitis to write your software.
Or you skip this part and use the hardware direct in your Linux. So you will create an IP core and add him to your system in Vivado. Export the hardware to get your BSP file. Then you need the Xilinx Device Tree Generator to generate your device tree. This tool uses some basic definitions (like the base adress) of your IP core to generate the device tree part for your hardware.
Then you create a normal bitstream and a bunch of tools to create your bootloader, kernel, device tree, bitstream file, etc. (all without Yocto). Copy all files to a SD card and boot up your device. You can take a look at my Linux project and the Wiki when you need some help. Now you can begin to write the driver for your device and test him on your real hardware. At last you can create a Yocto recipe to automatic include your driver to the kernel with KConfig.
After booting Linux you find a device /dev/devcfg which can be used to reprogram the FPGA. Please note that changing the FPGA with impact on the processing system (i. e. you add some interfaces to your PS) will cause in some errors (maybe that bug is gone over the last years, but I have to issue this problem a few years ago).
So according to your LED example you have to do the following steps:
Create the IP core
Create a basic processing system and add the IP core
Generate the bitstream
Export the hardware to Vitis
Open Vitis and create a new FSBL project
Add the Device Tree Generator to the Vitis repositories
Create a new device tree project
Build BOOT.bin, uImage, devicetree.dtb and copy them to your SD card
Boot your device
Check /proc/device-tree/ for your device
Begin with the driver development
Export your driver to Kconfig and Yocto (or use him as a loadable module)
You can find all the steps in my Wiki. Feel free to ask me.
But please note: The tutorial isn´t that new and unfortunately I don´t add a custom IP integration to that tutorial (maybe I will add it soon) but it should show you the way how you can do it.
EDIT: As stated in the comments, the question seems too broad to answer, so I'll leave the explanation of the problem and the questions, because they haven't changed, but I have changed the title (it doesn't seem good yet, but it's better than before) so they are more in tune.
What lead me to the question
I want to compile OpenWRT for my board. At the moment I am compiling it to a beagle bone black, and it's quite straight forward since there are tutorials available for that, but it got me thinking. How would I build it for a completely bare board? Like it or not BBB comes with u-boot and a version of linux (Amstrong if I'm not mistaken) so when I build OpenWRT for it maybe many things have already been taken care of for me.
I know that I need to first set up the board to boot from somehere, then it must have the bootloader and finally the kernel (there is the SPL and all that, but ok, let' leave it aside for now).
Hypothetical system
Let's imagine I have a hardware similar to the beaglebone, except it has a dipswitch connected to the boot pins in order to select from where I'm going to boot my device from. Imagine I have set it to boot from ethernet, which means that on startup a bootloader located in ROM will receive a binary file and store it in flash, all that via TFTP.
The questions
At this point I imagine that the binary file given via TFTP is the bootloader, am I right?
So after that I'd need to give the bootloader the kernel?
Does this mean that it is a 2 step process? First load the bootloader an dthen the kernel?
Is it possible to compile both at the same time and load it into the microprocessor?
Does OpenWRT build u-boot as well or do I need to compile it separately? I know it downloads the kernel and compiles it.
How would I build this for production? Imagining that I have to build u-boot and openwrt separately, would I create a script that compiles both and then does the entire process of downloading it into the microprocessor?
Is it possible to pre-configure the kernel so that it doesn't need to be configured after the code is downloaded? I mean, for example, compile it with initialization scripts instead of connecting to the device and configuring this. Is it possible or do I have to connect to the board and configure it manually?
PS: Sorry for such basic questions, but it's my first time compiling the kernel for real, and I've only worked with microcontrollers and RTOSs at most
Let's try to answer the queries one by one
At this point I imagine that the binary file given via TFTP is the bootloader, am I right?
No, It should be the firmware(kernel+HLOS). TFTP is available in uboot or only after SBL(Secondary boot loader) is loaded into memory.
So after that I'd need to give the bootloader the kernel?
bootloader needs to be present in the memory and if required it can get the firmware from ethernet, This can be simply done by changing the uboot env(bootcmd), can also be configured at compile time.
Does this mean that it is a 2 step process? First load the bootloader an dthen the kernel?
Yes, bootloader needs to be loaded earlier, but if you designing a custom board, you can combine the images in a big file and then flash/load that file at once.
Is it possible to compile both at the same time and load it into the microprocessor?
Does OpenWRT build u-boot as well or do I need to compile it separately? I know it downloads the kernel and compiles it.
Yes, Openwrt is very flexible and it compiling uboot, kernel, userspace package at once and create a desired image(based upon user configuration).
How would I build this for production? Imagining that I have to build u-boot and openwrt separately, would I create a script that compiles both and then does the entire process of downloading it into the microprocessor?
You can configure the openwrt to generate the appropriate image(based upon the flash and system requirement) and then flash that image in production(so, simple).
Is it possible to pre-configure the kernel so that it doesn't need to be configured after the code is downloaded? I mean, for example, compile it with initialization scripts instead of connecting to the device and configuring this. Is it possible or do I have to connect to the board and configure it manually?
Yes, use make kernel_menuconfig to configure the kernel parameter at compile time.
Hope, I have answered all the queries!!!
i have already compile the linux kernel with arm compiler for beaglebone black.comile the uboot. and also filesystem debian. Now i want to run my compiled linux kernel on beaglebone. how can i do it?which image file has to be port? and how? using sd card or using usb to serial ttl connector? please help me descriptively.thank you
This excellent page created by Robert C. Nelson, who also maintains the official images for Beagleboard, covers it in great descriptive detail, #exactsteps even.
We are porting a solution to ARM that was originally designed to run on x86/x64 Debian based systems.
So far so good however along with this solution we ship out a printer that is compatible and comes with drivers for Linux (x86 and x64), unfortunately the manufacturer does not have ARM drivers for it, nor is capable of compiling some from source code (don't know why).
I've installed the printer with CUPS and used the x86 binary. But of course, whenever I send a task to the printer, the ARM system cannot use the binary and naturally CUPS reports:
/usr/lib/cups/filter/rastertotg2460 failed
I would like to know how I can run x86 binaries on ARM v6 based systems?
The ARM operating system is Raspbian running on a Raspberry Pi B+ board and the binaries (if you want to take a look) are here.
EDIT:
I was also made aware of this proprietary solution that claims to make it possible running x86 binaries on ARM systems, but all demonstrations are for ARM v7 systems, not sure if it will work on Raspbian with a Raspberry Pi B+ board.
I think this is going to require some serious work, but I had it the wrong way around initially.
Since you want to drive the printer, you're going to have to do the x86 emulation "inside" the CUPS system. It's not enough with a stand-alone x86 emulator, since those aim to give you a full x86 system with peripheral hardware and stuff. You don't need that, you just need to drive the printer.
I can imagine using some kind of x86 emulation library inside a CUPS "virtual" driver, which in turn loads the x86 binary you have and feeds it into the emulator. It would then need to expose the expected CUPS environment to the x86 code inside the emulator.
Something like Soft86 might be a good starting-point.
Yesterday I faced with an interview. In interview he asked me for steps to porting Linux on new board.
My answer was,
cross-compile u-boot for board architecture.
cross-compile kernel, with selecting driver for peripherals connected to board.
cross-compile filesystem, and port all on board.
But Interviewer is not happy with this answer.
Can you please suggest me which point were I missed out?
Thanks in advance.
Porting steps -
Install a cross-development environment.
Setup the board and ensure that the serial port is working so we can print data through the serial port.
Download and install the Linux kernel, most of the porting work will be done at this level.
Add board specific code into the kernel tree.
Build a kernel image to run on the board
Test that early kernel printk is working
Get the real printk working with the serial console.
For a new board, a new board-specific directory should be added as well as support for interrupt handling, kernel timer services and mapping for memory areas.
Ethernet drivers are usually the next drivers to focus on as they enable setup of NFS root file system to get access to user utilities and applications.
Filesystem can be provided in different forms which are listed on LinuxFilesystem