I have precompiled Android Kernel and modified it. After builduing I got an zImage. The Question is how can I install and boot the zImage on my raspberry pi 2?
I'm using a SD-card.
The RPi won't load a normal zImage. You will need to use a tool called imagetool-uncompressed.py available in the Raspberry PI Tools repo to convert the zImage into the format used by the Raspberry PI.
After doing that, you can copy the kernel.img file into /boot on the SD card.
There is a reasonably complete tutorial on compiling and installing your own kernel here and another here. I recommend you read these if you have not already, because there are a lot of other aspects to consider.
Related
I have generated a core-image-minimal image for my Intel board in Yocto.
Looking into tmp/deploy/images folder they are many images.
I flashed *.wic image using dd command on USB and it created two partitions ( Boot and Platform ) and allowed only to perform a live booting without allowing it to install on the hard disk of the board.
I then flashed *.hddimg on the USB using dd command. It only created a "boot" partition which has rootfs.img, syslinux and EFI folder.
Booting using USB provided me an "Install" option, which installed on the board and when I rebooted after installing, it displays "No bootable media found"
Using bootable image there are two partitions in the hard disk. Why it is not booting..
Steps followed:
Created an minimal yocto image using "bitbake core-image-minimal" command
Flashed the USB using the dd command.
sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.hddimg of=/dev/sdb
Clicked on install and typed “sda”
The installation was successful and when I tried to restart by removing the USB Drive, it says “No boot options found. Please install bootable media and restart."
What is the mistake I am doing here.
Which image to choose and when..
There was not much info about online, so I asked this question in the intel community and here is the response of that:
Generally a .wic image is intended to be installed directly to its final destination, whereas an hddimg is for evaluation and installation elsewhere.
By default meta-intel .wic images only have an EFI bootloader, and will not boot via legacy BIOS.
An hddimg will have both an EFI bootloader and the syslinux binaries that let it boot from legacy BIOS.
On startup with your installer USB image do you get a light gray screen with four options? If so it is booting via legacy BIOS.
I downloaded RetroPie for my RaspberryPi 3 from this link and have been trying to get my 3.5" LCD to work. I downloaded the driver from here as described, but whenever I try and extract it with the "tar xzvf LCD_show_v6_1_3.tar.gz", the file for the Osoyoo LCD I have, around 50 lines are executed and then the Pi crashes. When I restart it, it goes into a kernel panic every time. I've reinstalled my OS multiple times. I cannot download the raspbian distro with the driver because I have been unable to install RetroPie on top of it and have been unable to display it on the LCD.
Install instructions and product:
Please respond if you know how to solve this problem or what you recommend.
Turns out I was not using enough power. The usb cable I used was a spare rather than official cable for the Pi. Not enough voltage to complete the tasks.
My aim: Trying to
Build a minimal Qt based GUI system with a single window and sensor connected on USB
demonstrate this using Qemu and later on embedded board with atom
to build it from scratch
Use buildroot to build the rootfilesystem
My experience Have experience in Linux kernel development for device drivers, qemu, Buildroot, USB but has no experience on GUI and framebuffers.
My attempts:Build kernel and rootfile system
with buildroot using the command make qemu_x86_defconfig
Framebuffer support on Linux kernel is enabled along with the following CONFIG_FB, CONFIG_FRAMEBUFFER_CONSOLE, and CONFIG_LOGO (all the options below this are also enabled)
As the first milestone I expected to see the TUX logo when I run the image with the command
qemu-system-i386 -M pc -kernel output/images/bzImage -drive file=output/images/rootfs.ext2 -append root=/dev/sda -vga std but i donot.
Am I making a mistake at the Qemu command or the framebuffer is not enabled?
P.S. A similar question Qt application GUI -- automatic start -- linux. But i am not planning to use the X window as suggested by most users.
I missed the cirrus graphics board driver. Qemu emulates Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non standard modes for i386.
So the steps are:
Download buildroot
make clean
make qemu_x86_defconfig
make linux-menuconfig to configure kernel and in Device drivers->Graphics support->Support for frame buffer devices enable Cirrus Logic support
Save the configuration and run make
Once make is complete run the command in board/qemu/x86/readme.txt
Where did you see that Buildroot has a i386_defconfig? You seem to be confusing kernel defconfigs and Buildroot defconfigs. I would recommend you to start with:
make clean
make qemu_x86_defconfig
make
and then read board/qemu/x86/readme.txt to see how to run the generated system.
I recently purchased a PICAN CAN-Bus Board for Raspberry Pi. I am new to linux and am having issues copying over the pre-compiled kernel image. These are the instruction it says to follow (below).
The quickest way to try this board out is to use pre-compiled kernel image.
Download the image from http://lnxpps.de/rpie/ and copy over to your Pi.
# cp can-test/kernel.img /boot
# cp -a can-test /home/pi
I have downloaded the pre-compiled kernel image to a USB thumb drive. Plugged it into my raspberry pi. Shows up mounted /media/USB DISK. How do I get terminal to point to the USB drive and copy over theses files?
Any help would be greatly appreciated.
Try this:
cp /media/USB\ DISK/can-test/kernel.img /boot
cp -a /media/USB\ DISK/can-test /home/pi
I work on a cross-platform project, and recently added support for the Raspberry Pi. The project, to make sure it is available at as wide as possible audience, has a premake, a cmake and an autotools build system. I have set up cross-compilation for the RPi, and everything works great.
Recently, I also set up a Raspberry Pi VM (Until I get a real RPi) trying to build the library. From Linux, I run './configure --host=arm-raspberry-linux-gnueabihf', and configure takes it from there. On the RPi however (Rasbian 7), the default host found by config.guess is 'armv61-unknown-linux-gnueabihf'. For that reason, even natively on the Pi, I have to run './configure --host=arm-raspberry-linux-gnueabihf'. So, my question sums up to this:
Currently, I currently have something like this in my configure script:
case "$host" in
armv61-unknown-linux-gnueabihf)
if [[ -f /usr/bin/rpi-update ]]; then
on_raspberry=yes
fi
;;
## other hosts here
esac
So, my question sums up to this:
Is 'armv61-unknown-linux-gnueabihf' only reported on the Raspberry Pi? If not, how can configure make sure that it is really on RPi? Is checking for rpi-update sufficient? Do different distros (Arch Linux, Pidora, ...) also have rpi-update?
Are there any other possible host triplets like this that are reported by different versions of the Pi?
Thanks in advance
Is 'armv61-unknown-linux-gnueabihf' only reported on the Raspberry Pi?
Other platforms could use that as well.
If not, how can configure make sure that it is really on RPi?
It can't really (e.g. running it on a RPi VM). configure is just a shell script.
Is checking for rpi-update sufficient?
See above.
Do different distros (Arch Linux, Pidora, ...) also have rpi-update?
Current Pidora and Arch images don't have /usr/bin/rpi-update. Neither does old Rasbpian images at least as far back as 10 Aug 2012.
Are there any other possible host triplets like this that are reported by different versions of the Pi?
There are 3 triplets for the RPi cross compilers, so it would not be surprising if there were others.
EDIT: so basically what is wanted is a way for configure to detect when it's building on a Raspberry Pi. Easy as pie:
configure.ac
# need to detect build...
AC_CANONICAL_BUILD
...
AC_MSG_CHECKING([if build is on Raspberry Pi])
# The test for 'BCM2708' might be sufficient,
# but the presence of Serial is definitely part of
# the Pi firmware for codec licensing.
# See this thread
# <http://www.raspberrypi.org/phpBB3/viewtopic.phpf=29&t=28304&p=252357#p251536>.
AS_CASE("$build",
[arm*-*-linux*],
[on_rpi=`awk -v r=0 '/^Hardware#<:# \t#:>#+:#<:# \t#:>#+BCM2708/ { ++r;} /^Serial#<:# \t#:>#+:/ { ++r; } END { print ((r > 1) ? "yes" : "no");}' /proc/cpuinfo`],
[on_rpi="no"])
AC_MSG_RESULT($on_rpi)
Detects on Raspbian, Pidora, should work on Arch. Arch doesn't seem to include a compiler in its current install image, so configure failed when I tried it. All detected build as armv6l-unknown-linux-gnueabihf when running ./configure. I have not tried this on any kind of RPi emulator or VM.
BCM2708 in /proc/cpuinfo might be unique for RPi.
From File /proc/cpuinfo
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2708
Revision : 000d
Serial : 00000000db690cb4