I'm trying to configure U-boot to use a DTB that is embedded into the binary. I set CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE when building. The DTB seems to be properly embedded into the binary, since I can find it inside the binary, but eventually it fails on boot with a message:
No matching DT out of these options:
Configuration to load ATF before U-Boot
No matching DT out of these options:
Configuration to load ATF before U-Boot
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
I'm using a fork of Boundary Devices U-boot https://github.com/boundarydevices/u-boot-imx6 branch boundary-v2018.07 on a Nitrogen8M board.
I boot the board using an i.MX8 bootable image created using imx-mkimage, which contains the a53 FIT image with ATF and U-Boot, separate SPL and HDMI/DDR firmwares.
What should I do to make U-boot recognize an embedded DTB, instead of a separate one provided in the FIT image?
Related
I am trying to revise the bootline of VxWorks by running the “bootChange” command in shell.
I can successfully see the change right after i run this command by checking “version” command, but when i really try rebooting the VxWork, the changes wasn't applied.
So i am confused and hope i can get some insight of why such change doesn't work.
By the way there does have a flash as the main storage in my equipment, and i believe the bootrom image which contains the booline was burned in that flash.
And i have checked that the flash wasn't mounted in VxWorks by running “devs” command.
Is your system booting with U-Boot or with a VxWorks Bootrom?
You might confirm which VxWorks version is used.
If you have a bootrom, try the to change the boot line parameter from the bootrom context by using the command "c".
You can also pass the full boot line parameter preceded with "$" to tell to the boron to use this boot line instead.
Note: devs in VxWorks would not display the flash/nvram being used for storing the boot line parameter. You might check the file target.nr, target.ref in the BSP directory.
With QEMU, I can use either use -initrd '${images_dir}/rootfs.cpio for the initrd, or pass the initramfs image directly to -kernel Image.
But if I try the initramfs image with gem5 fs.py --kernel Image it fails with:
fatal: Could not load kernel file
with the exact same initramfs kernel image that QEMU was able to consume.
And I don't see an analogue to -initrd.
The only method that I got to work was to pass an ext2 disk image to --disk-image with the raw vmlinux.
https://www.mail-archive.com/gem5-users#gem5.org/msg15198.html
initrd appears unimplemented on arm and x86 at least, since gem5 must know how to load it and inform the kernel about it's location, and grepping initrdonly shows some ARM hits under:
src/arch/arm/linux/atag.hh
but they are commented out.
Communicating the initrd to the kernel now appears to be simply doable via the DTB chosen node linux,initrd-start and linux,initrd-end properties, so it might be very easy to implement: https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt (and gem5's existing DTB auto generation) + reusing the infrastructure to load arbitrary bytes to a memory location: How to preload memory with given raw bytes in gem5 from the command line in addition to the main ELF executable?
Initramfs doesn't work because gem5 can only boot from vmlinux which is the raw ELF file, and the initramfs images only gets attached by the kernel build to a more final image type like Image or bzImage which QEMU can use to boot, see also: https://unix.stackexchange.com/questions/5518/what-is-the-difference-between-the-following-kernel-makefile-terms-vmlinux-vml/482978#482978
Edit: the following is not needed anymore after the patch mentioned at: How to attach multiple disk images in a simulation with gem5 fs.py? To do this test, I also had to pass a dummy disk image as of gem5 7fa4c946386e7207ad5859e8ade0bbfc14000d91 since the scripts don't handle a missing --disk-image well, you can just dump some random 512 bytes and use them:
dd if=/dev/zero of=dummy.iso bs=512 count=1
I want to load and boot the Image of Vxworks from ZC702 Zynq Platfrom QSPI flash, Can any one either point me to a step by step guide or a document which tells the:
1) Configuration needed to use SPI flash as the booting memory instead of SD card?
2)How to load Vxworks image into SPI flash ?
I have been struggling just to get a zc706 to boot from an SD card. I have found errors in the Windriver documentation but haven't figured out how to make it work though. That said if you have SD card working the VxWorks target.ref file in the BSP folder says:
3.7 Programming on board QSPI FLASH
Rename BOOT.Bin to bootrom.bin, then copy u-boot BOOT.BIN to the root directory
of a SD card. Type the following commands in the U-Boot shell.
mmcinfo;fatload mmc 0 0x8000000 bootrom.bin
sf probe 0
sf erase 0 0x0100000
sf write 0x08000000 0 0x0FFFFF
Note: if the bootrom size exceeds 0x100000 (1M), you should erase
one or more sectors and program more data to flash, for example:
sf erase 0 0x0200000
sf write 0x08000000 0 0x1FFFFF
change the switch settings to boot from qspi flash setting and reset board.
Also see the Xilinx Appnote Using VxWorks BSP with Zynq-7000 AP SoC
If you make headway let me know!
I have tried over at the digi forum, but I'm thinking that here is where all the clever people are :-)
I’m working on a CCWi-i.MX53 JSK. What I’m trying to figure out is - as you might have guessed - to flash a WCE image from an USB stick.
Based on
http://www.digi.com/support/kbase/kbaseresultdetl?id=3305
and
http://www.digi.com/support/forum/40385/mx53-jsk-with-windowc-how-boot-new-wce-from-microsd-using-uboot
my best guess is to either just
dboot wce usb 0:1 fat wce-CCXMX53
or setting the U-Boot command like
setenv bootcmd dboot wce usb 0:1 fat wce-CCXMX53
saveenv
reboot
None of the methods works for me. I’m getting:
Unknown command 'usb' - try 'help'
command usb reset failed
I’m using a freshly formatted FAT32 USB stick with only the wce-CCXMX53 file on it, in either of the J10 USB plugs.
Any help will be greatly appreciated. Thanks in advance!
Sidenote: dboot usage:
CCWMX53 # ? dboot
dboot - Digi modules boot commands
Usage:
dboot <os> [source] [extra-args...]
Description: Boots <os> via <source>
Arguments:
- os: a partition name or one of the reserved names:
linux|android|wce|netos|eboot
- [source]: tftp (default)|flash|nfs|usb|mmc|hsmmc|sata|ram
- [extra-args]: extra arguments depending on 'source'
source=tftp|nfs -> [filename]
- filename: file to transfer (required if using a partition name)
source=usb|mmc|hsmmc|sata -> [device:part filesystem] [filename]
- device:part: number of device and partition
- filesystem: fat|vfat|ext2|ext3
- filename: file to transfer
source=ram -> [image_address] [initrd_address] [initrd_max_size]
- image_address: address of image in RAM (default: linuxloadaddr, netosloadaddr, etc)
- initrd_address: address of initrd image (default: loadaddr_initrd)
- initrd_max_size: max. allowed ramdisk size (in kB) to pass to the kernel (default: kernel default)
If <os> is 'wce' the following bootargs are possible:
cleanhive
I am sorry I don't know dboot/wce. From my bootloader experience, you may play with the following command to read file from your USB stick to memory (without actually booting - losing control):
# fatload usb 1:1 (loadAddress) (bootfilename) # load your file to memory
# md (loadAddress) #dump memory content, which you can compare with your USB file
Booting process primarily comprises step1- reading an executable (OS) file from media(mmc/usb) to memory; step2- prepare environment(registers, parameter data in certain memory location, even rootfs in ramdisk...); step3- jump to the entry of executable file in step1.
I am working on uclinux porting on coldfire board M5272C3. Right now I have kernel running from RAM with romfs as my rootfile system.
I am not clear about few terms what they mean and when to use them....
Please explain me in a simplest possible manner:
Q1: What is initrd? Why we need that?
Q2: What is ramdisk? Why and where we need this?
Q3: what is initramfs? Why and where we use this?
Q4: What is ramfs? Why and where we use this?
Also please refer document/reference book for in depth knowledge of these terms....
Thanks
Phogat
A ramdisk merely refers to an in-memory disk image. It is implemented using the ramfs VFS driver in the kernel. The contents of the ramdisk would be wiped on the next reboot or power-cycle.
I'll give you details about initrd and initramfs next.
In simple terms, both initrd and initramfs refers to an early stage userspace root filesystem (aka rootfs) that will let you run a very minimal filesystem in memory.
The documentation present at Documentation/filesystems/ramfs-rootfs-initramfs.txt part of the linux kernel source tree, which would also give you a length description of what these are.
What is initrd ?
One common case where there is the need for such an early-stage filesystem is to load driver modules for hard disk controllers. If the drivers were present on the hard drive, it becomes a chicken-and-egg problem. Having these drivers as part of this early-stage rootfs helps the kernel load the drivers for any detected hard disk controllers, before it can mount the actual root filesystem from the hard drive. Another solution to this problem would be to have all the driver modules built into the kernel, but you're going to increase the size of the kernel binary this way. This kind of filesystem image is commonly referred to as initrd. It is implemented using either ramfs or tmpfs. It is emulated using a loopback block device.
The bootloader loads the kernel image into a memory address, the initrd image into another memory address, and tells the kernel where to find the initrd, passes the boot arguments to the kernel, and passes control to the kernel to let it continue the boot process.
So how is it different from initramfs then ?
initramfs is an even earlier stage filesystem compared to initrd which is built into the kernel (controlled by the kernel config of course).
As far as I know, both initrd and initramfs are controlled by this single kernel config, but it could have been changed in the recent kernels.
config BLK_DEV_INITRD
I'm not going deep into how to build your own initramfs, but I can tell you it just uses cpio format to store the files and can be configured using usr/Kconfig while building the kernel. Even if you do not specify your own initramfs image, but have turned on support for initramfs, kernel automatically embeds a very simple initramfs containing /dev/console, /root and some other files/directories.
In addition there is also a newer tmpfs filesystem which is commonly used to implement in-memory filesystems. In fact newer kernels implement initrd using tmpfs instead of ramfs.
UPDATE:
Just happened to stumble upon a similar question
This might also be useful