I have got a Board with NXP LS1021A which regularly boot Barebox from a QSPI rom partition.
Unfortunately this bootloader has several compatibility problems with my board, so I would like to use Barebox for booting a u-boot image from another partition on the same QSPI rom. I regularly modified and compiled u-boot for the board, changing the starting address to be compatible with the new partition. This is ok.
Problem is related to u-boot execution as my Barebox has problem with direct “go” command (seems not to be able to se direct addresses of partitioned flash) but I am able to use bootm in the partition.
So I try the command
bootm /dev/flash.uboot-partition
Unfortunately says “no handle for uImage format“. uImage is correctly checked and is fine.
Is there a way to do this?
Thanks in advance
I tried bootm command, I expected u-Boot to be booted.
Related
Once the Uboot loads the Linux kernel image (ZImage) onto the ram, it invokes it (could be using bootz, bootm or some other commands based on the type of the kernel Image) and then the control goes to booting the kernel. Does the uboot will be informed about the kernel boot result?, means, whether the kernel booting went through completely or got stuck in the middle because of errors?.
I looked at do_bootz, do_bootm_states and boot_selected_os api's in the uboot src code to see if there is any way to know about the final kernel boot result, but I couldn't able to figured it out.
Details:
U-boot Version: 2017.03-rc2
api's are available at: cmd/bootz.c and bootm.c files.
If any one in this community knows about it or have an idea about it, please explain to me or point me to the correct path.
Thanks in advance.
Regards
Vamsi Chagari
After bootm, booti, bootz transfer control to the kernel the memory formerly used by U-Boot will be reused by the operating system. As U-Boot is no longer in memory it cannot be informed about the operating system status.
If you use the bootefi command the U-Boot implementation of the UEFI runtime services stays in memory while the operating system is starting. The UEFI services can be called by the operating system. These include services relating to variables. One use of UEFI variables is the definition of the boot sequence.
Unfortunately UEFI variables are not yet completetly implemented in U-Boot (as of version v2018.07). They currently cannot be accessed after exiting boot services.
I am using am335x based custom board. I have only uart port for loading images to memory. I was able to get u-boot working. What are the load addresses for the linux kernel and the dts file. What will be boot command for running the loaded kernel from memory.
The DDR on Am335x starts at address 0x80000000. The ending address depends on the size of your DDR RAM. For a 128MB RAM, you have the last addres at 0x88000000 So you can load your kernel anywhere. Make sure you load the device tree blob toward the end of the RAM and set the following for u-boot
setenv fdt_high 0x88000000
This ensures that fdt is not relocated outside the max address of your ram.
Your basic bootargs will be
console=ttyO0,115200n8 earlyprintk=serial mem=128m
Anything else depends on your rootfs which can be on mmc or sd.
Refer TI AM335x links for loading kernel and dtb images from different places,
below links explains load address as well commands to load and run,
AM335x User's Guide
AMSDK u-boot User's Guide
I am having issues in loading my root fs and after inspecting the Kernel Log it says some thing like
"INITRD: 0x1f8ca000+0x0028ac63 is not a memory region - disabling initrd"
What does this mean?
Background
I am running linux on one core of an ARM Cortex A9 and trying to run another baremetal application on another core. I have changed the device tree to reflect this and i am reserving part of the SDRAM for Linux and part for the bare-metal application. I am using Uboot. Is this something to do with the uboot?
Cheers,
S
As you are NOT dedicating the entire RAM to the Linux kernel on the main core, you will need to ensure that the intrd load address specified in the bootargs is accesible from the main core.
Next, this info is usually passed to the Linux kernel in bootargs passed from u-boot as
initrd=<initrd-start-addr>,<initrd-size>
Modify it according to your custom memory-map
Finally in u-boot, load the initrd at the new proper address you just specified and boot the Linux kernel.
I am working on ARM S3C6410 device now.
The problem is first 256KB of NAND was broken.
I am trying to boot with SD card, uboot works.
What I want to know is as following.
Can I boot kernel from SD card without NAND?
Can I run uboot from SD card, and then boot kernel from non-broken area of NAND?
I am a newbie. I hope guru's help.
yes, many boards use sd-card instead of nand, just modify the bootargs in u-boot. You probably don't even need to change the kernel, just make sure that uboot supports the SD-card for your platform as a boot device
yes. Again, it's only a problem of configuring bootargs correctly. Probably even simpler than point 1
I am trying to successfully build u-boot for my BeagleBoard C5 board. I am using Ubuntu 10.04 and the Crosstool-NG toolchain. I have working images for Xloader (MLO), u-boot.bin, and uImage that I found prebuilt from the AngstromBB project for which the boards boots Angstrom successfully.
I can successfully build the u-boot.bin file by doing the following:
git clone git://git.denx.de/u-boot.git u-boot/
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
I then copy my just built u-boot.bin to replace the working version of u-boot.bin on the SD card and attempt to boot the board but it fails by hanging at:
Reading boot sector
Loading u-boot.bin from mmc
It will just sit there forever! I cannot seem to find any clear instructions on building u-boot for the C5 BeagleBoard other than that it is different then previous versions or requiring something called 'SPL' built with u-boot. Does anybody know how I might succeed in building my own u-boot.bin image for the BeagleBoard C5?
Your first step should be researching the boot sequence of the board. Some processors do not boot directly to u-boot. They launch an application that is stored in Flash or maybe an EEPROM on the board. In the case of your C5, this application is X-Loader (https://gitorious.org/x-loader). You are going to need to understand what this level 1 boot loader does and how exactly it launches u-boot. Generally they will do some basic PSC, DRAM, ... configuration before launching the full boot loader. But where does it look for u-boot? Does X-Loader copy u-boot to RAM and begin execution from there? Or does it it start execution from your MMC? Sometimes there are jumpers that can be set which will control the boot sequence. So X-Loader could boot from NAND, NOR or SD/MMC depending on the setting.
Where did you get your u-boot source code from? Did you download it directly from the denx website or was it provided with your Beagle board?
In general, it is very difficult to debug bringing up a board (even if it's a reference board) without tools. Was a debugger provided with the board or d you have a JTAG debugger of your own that you could use to set hardware breakpoints and step through the code?