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
Related
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.
I have built an image for the TQ Systems STKa8x Evaluation board with an i.MX8 QuadMax using the yocto project. The resulting image does not boot on the device. Can anyone help me interpret the warnings and errors occuring in the serial console output when trying to boot?
I think the the machine configuration might be wrong? The device hardware is ok, becaus the device boots using the included sd card.
Did you flash your Yocto image in your emmc or SDcard ? Here it seams that there is no partition table in your emmc which is normally embedded inside Linux image. It is more likely that the flash did not succeed.
Plus you can see warning from u-boot that he cannot load the device tree. Check your repository build/tmp/deploy/image/machine/*.dtb
You should also check if your linux image and device tree is flashed in the correct address.
Solved: The problem was caused by the SD card. I have used this SD card https://de.transcend-info.com/embedded/product/embedded-memory-cards/usd230i. Using another one solved my problem.
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 trying to understand how a kernel boots. I am currently trying to port a new kernel to hTC Incredible S VIVO (s710e) device, but I cannot get it to boot. So, I looked into the device's original kernel, and looked through some documentation, and found out that the device uses ATAGs. Now, I have several questions that I cannot find a clear answer for:
What are ATAGs?
What are they used for?
How does the kernel boot using ATAGs?
Do ATAGs play a vital role in booting a kernel?
ATAGS are ARM tags. They are used to carry information such as memory size from boot code to kernel. Some references (which in turn lead to other references): booting standards, customized ATAG.
This reference arm/Booting explains theory, but does not much tell a user what to do.
On my target I use the following in my U-Boot config: CONFIG_CMDLINE_TAG, CONFIG_SETUP_MEMORY_TAGS, and these in my kernel config: CONFIG_ATAGS=y, CONFIG_USE_OF is not set. Not sure if that is sufficient for you but it gives you clues to search on, good luck.
ATAGS are not only arm-related, at all. Look into other archs head.S. They are special parameters to be passed to the kernel through some registers and pointers.
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?