I am using custom Linux Kernel built through Yocto. I generated sdimg and try to boot it using an SDCARD and it boots perfectly fine. Here along with the Kernel I also use INITRAMFS files. Using config.txt and cmdline.txt file in partition 1, I tell the kernel to load my INITRAMFS file. This procedure is working fine.
Now, I am trying to net boot my Raspberrypi. For this I have another PC which has DNSMASQ installed and it acts as DNS server. I have all the required files in my /tftpboot directory. When I turn on the client RPI, it gets all the files from the server except my INITRAMFS file. I have added the initramfs file name as shown below in the config.txt, but still it is not being requested by my PI. How to make the RPI request for the INITRAMFS file? It just boots up the kernel7.img and thats it !
//appended the following lines to config.txt
ramfsfile=myramfs.cpio.gz
initramfs myramfs.cpio.gz followkernel
Please note that I am not using u-boot.
I was able to resolve the issue. When we do TFTP booting, the first file requested by Raspberry pi(Rpi) is startx.elf, this will be run on the GPU core. Next file that is requested is config.txt. For some reason, if I append the above 2 lines it doesn't work. I read in one of the raspberry pi forums that if the config.txt file is above some size limit, it will be ignored. So I cleared the config.txt file and added just these lines, and voila! Now my initramfs file is requested by the PI and boots successfully :)
Related
Closed. This question is not about programming or software development. 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 8 days ago.
Improve this question
I have a Raspberry Pi Model 3B+. Currently, I can successfully load this exact kernel8.img file (which is just a raw binary) from this tutorial bare metal following the instructions outlined in the tutorial's README as shown below:
... you can download a raspbian image, dd it to the SD card, mount it and delete the unnecessary .img files. Whichever you prefer. What's important, you'll create kernel8.img with these tutorials which must be copied to the root directory on the SD card, and no other .img files should exists there.
The serial output after the above kernel8.img is running successfully looks something like this:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
EMMC: Sending command 37000000 arg 00000000
EMMC: Sending command 29020000 arg 51FF8000
EMMC: CMD_SEND_OP_COND returned VOLTAGE CCS 0000000040F98000
...
However, I would like to load that kernel8.img file via U-Boot and TFTP so that I don't have to keep plugging/unplugging microSD cards.
I have a functioning TFTP server and I have loaded U-Boot onto the Raspberry Pi successfully.
The physical address the kernel image gets loaded to bare metal is 0x80000 as explained by the tutorial:
Important note, for AArch64 the load address is 0x80000, and not 0x8000 as with AArch32.
The kernel8.img's file-type is also just a raw binary:
$ file kernel8.img
kernel8.img: data
As such, I've run the following two U-Boot commands:
tftp 0x80000 rpi3bp/kernel8.img
go 0x80000
However, as shown below, I'm getting some garbled mess once the binary is running: ��ogK�S��rK.
...
U-Boot> tftp 0x80000 rpi3bp/kernel8.img
lan78xx_eth Waiting for PHY auto negotiation to complete........ done
Using lan78xx_eth device
TFTP from server 192.168.0.198; our IP address is 192.168.0.111
Filename 'rpi3bp/kernel8.img'.
Load address: 0x80000
Loading: ################################################## 6.6 KiB
603.5 KiB/s
done
Bytes transferred = 6808 (1a98 hex)
U-Boot> go 0x80000
## Starting application at 0x00080000 ��ogK�S��rK
According to this SO post (as shown below), the go command is all that is required to get a bare-metal binary running on U-boot.
If you have issues executing your binary when using the go command,
then the problem lies with your program, e.g. taking control of the
processor and initializing its C environment.
However, I know for a fact that the kernel image runs fine bare-metal using the Raspberry Pi's default bootloader. So what could be the issue here and why can't I seem to get that kernel image running via U-Boot?
Edit 1:
Here's some context on how I set up U-Boot on the Raspberry Pi. Currently, the Raspberry Pi's bootloader is booting U-Boot in 64-bit mode. The Raspberry Pi's bootloader is configured via the config.txt file and below is my config.txt file:
enable_uart=1
arm_64bit=1
kernel=u-boot.bin
Documentation on the arm_64bit option is here:
arm_64bit
If set to non-zero, forces the kernel loading system to assume a
64-bit kernel, starts the processors up in 64-bit mode, and sets
kernel8.img to be the kernel image loaded, unless there is an explicit
kernel option defined in which case that is used instead. Defaults to
0 on all platforms.
The issue is related to the fact that U-Boot uses UART1 on the Raspberry Pi and the binary I'm trying to run uses UART0 as explained by #sawdust below:
Per U-Boot's DT, it appears that U-Boot uses UART1 on gpios 14&15. The
standalone uses UART0 on the same gpios. So that explains both (a)
getting output from two programs on same pin, and (b) why removing
uart_init() failed. Since U-Boot sets up UART0 for Bluetooth, perhaps
the standalone does not expect that; hence a goofy baudrate. An
oscilloscope could easily verify that.
I know this to be true because I modified the code in uart.c to use UART1 instead and I can now see sensible serial output now.
However, it is still unclear to me why despite the seemingly valid initialisation of UART0 in this part of the code, UART0 does not seem to output legible characters at the right baud rate.
I created an image for raspberry pi zero 2 w using buildroot,
Also added overlay gpio-ir in config.txt but not able to receive ir signal.
No logs are printed for gpio in dmesg.
No devices are showing in /proc/bus/input/devices
Can anyone help?
I found solution my self.
Actually buildroot is not start gpio-ir-recv module at boot time.
So we need to load module manually at boot time.
We can load module by this command
modprobe gpio-ir-recv
So i have created one service to load module in /etc/init.d
I'm trying to build an image using bitbake for the i.MX8 board.
I'm following these instructions:
https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf
Since I do not have enough space in local HDD, I'm using an external USB HDD (I have other unrelated stuff stored in this HDD).
I have been successfull at executing the imx-setup-release.sh script in that document, with which I built a configuration for the imx8mm-lppddr4-evk machine using the fslc-wayland distro.
However, when I try a command, such as "bitbake core-image-minimal", I get several failed tasks. It seems that the common deminator is the fact that, for some reason, when the path to my build folder is passed (which is within the external HDD), it is considered an invalid argument.
I get messages such as this:
OSError: [Errno 22] Invalid argument: '/media/home_dir/427AD2297AD2198D/imx-yocto-bsp/build_fslc_wayland_imx8mm_lpddr_evk/sstate-cache/95/51/sigtask.1jbsd4s4' -> '/media/home_dir/427AD2297AD2198D/imx-yocto-bsp/build_fslc_wayland_imx8mm_lpddr_evk/sstate-cache/95/51/sstate:core-image-minimal:imx8mm_lpddr4_evk-fslc-linux:1.0:r0:imx8mm_lpddr4_evk:3:955169ece771b852dc433575442e7ed805ac56cbcb1ebd3aa913a632da23a46b_clean.tgz.siginfo'.
It seems that bitbake is having trouble parsing the path to my HDD (that 427AD.../ folder).
What should I do to fix this?
The issue was that my HDD was not formatted with an ext4 format. Once I did that, those errors went away.
I am learning about u-boot and how this works in the Raspberry Pi system.
This is what I understood so far:
The first stage from the RPI cannot or should be modified. In this stage the BootROM simply loads the bootloader from the flash EEPROM.
In the second stage the EEPROM boot loader finds and loads start.elf, whose task is to load the kernel. It first reads "config.txt" which contains a kernel parameter. This is where u-boot is "injected".
kernel=u-boot.bin
U-boot can then in turn load the actual kernel. For a CM4 this would be "kernel7l.img".
I would be super satisfied with this knowledge, but in practice I have (possibly) seen other ways of integrating u-boot. I am here referring, for example, to Yocto recipes for the CM4 (meta-raspberrypi / u-boot). The boot directory of such an image contains: boot.scr, uboot.env, and uImage.
The readable part of boot.scr specifies that uImage will be loaded:
value bootargs /chosen bootargs
fatload mmc 0:1 ${kernel_addr_r} uImage
if test ! -e mmc 0:1 uboot.env; then saveenv; fi;
bootm ${kernel_addr_r} - ${fdt_addr}
config.txt does not contain a kernel parameter.
So here my questions for this boot process:
start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot? boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
is uImage just another name for u-boot.bin?
In this scheme how does u-boot know it must load "kernel7l.img"?
Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?
Thank you very much for your help!
The boot.scr script is read by U-Boot.
fatload mmc 0:1 ${kernel_addr_r} uImage loads a kernel in deprecated U-Boot specific format which can be created with the mkimage command.
The bootm ${kernel_addr_r} - ${fdt_addr} command receives the addresses of uImage and the device tree. The address for the initrd is left out ('-'). bootm starts the kernel and passes the device tree address to it.
Adding kernel=u-boot.bin to config.txt is the correct way to invoke U-Boot on a Raspberry.
Distributions like Suse and Fedora prefer to boot Linux via GRUB on the Raspberry using U-Boot's bootefi command.
So here my questions for this boot process:
start.elf cannot be modified since it is proprietary. How can it load u-boot if there is no kernel parameter in config.txt pointing to a binary u-boot?
The kernel=... parameter in the config.txt is an optional parameter that specifies an alternate (kernel) filename to load by the EEPROM boot program.
The default filename to load from the boot partition depends on the RPI version.
According to RPi documentation, the default kernel filename on the Pi 1, Pi Zero, and Compute Module is kernel.img, on the Pi 2, Pi 3, and Compute Module 3 it is kernel7.img, and on the Pi4 it is kernel7l.img
If "there is no kernel parameter", then inspect the kernelx.img file; what are the contents?
boot.scr is supposed to run before u-boot.bin. Who reads and executes boot.scr?
Incorrect, boot.scr is not "run before u-boot.bin".
The file boot.scr contains script that can be interpreted by U-Boot.
(The executable image for U-Boot is the u-boot.bin file.)
is uImage just another name for u-boot.bin?
No, those are two distinct filenames with completely different uses.
The u-boot.bin file is the executable image for U-Boot.
A uImage file is a kernel image with the U-Boot wrapper for identification and verification. The U-Boot wrapper/header can be used for a variety of objects such a U-Boot script or a standalone executable besides a kernel image.
See Image vs zImage vs uImage
In this scheme how does u-boot know it must load "kernel7l.img"?
U-Boot does not have that directive (in this situation).
According to the boot.scr file that you posted, the booting sequence that U-Boot will perform is to load the uImage from the boot partition.
Are there other ways of integrating u-boot in a RaspberryPi? Is there any documentation which describes these different integration schemes?
As mentioned in your post and the other answer, an explicit kernel=u-boot.bin in the config.txt would be the obvious/preferred method to invoke U-Boot.
Otherwise, IDK. Today's alternative could be tomorrow's deprecated method.
I am trying to create a bootloader following this link the things i did are
create a vfd as per given and formatted it.
used partcopy partcopy Boot1.bin 0 200 -f0
then created a config file for bochs emulator.
while bochs emulator loading it is asking for config file when i provide it, emulator stops saying panic
And i also want to know how to know if partcopy is has copied data into floppy. As i try to open the floppy drive after the copy it says format to use( i presume the problem is partcopy only ) .
how can i fix it??
The problem was in configuration file of the bochs.
romimage: file=BIOS-bochs-legacy, address=0xf0000
vgaromimage: file=VGABIOS-lgpl-latest
keep the rom image and vgaromimage in the same place as configuration file. it will work fine .