Currently, I have a ARM device that uses U-boot to load android OS. I wish to replace android with linux. So what I've done is loaded a copy of linux compiled for ARM devices onto a sd-card, boot into the U-boot bootloader. The problem now is what memory location do I tell U-boot to boot up the vmlinuz linux kernel?
How do I find this out? Or pointing out some resources would be great as well.
Thanks.
The following is the current boot up sequence from connecting to the serial port
Reg Version: v1.1.0
Reg Time: 2014-10-115:15:35
Reg Name: hi3719cdmo1a_hi3719cv100_ddr3_1gbyte_16bitx2_2layers_emmc.reg
Fastboot 3.3.0 (zengzhiliang#server180) (Nov 21 2014 - 13:41:16)
Fastboot: Version 3.3.0
Build Date: Nov 21 2014, 13:41:29
CPU: Hi3719Cv100
Boot Media: eMMC
DDR Size: 1GB
Check nand flash controller v610. found
Special NAND id table Version 1.36
Nand ID: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
No NAND device found!!!
Check spi flash controller v350. found
Can't find a valid spi flash chip.
Can't find a valid spi flash chip.
MMC/SD controller initialization.
MMC/SD Card:
MID: 0xfe
Read Block: 512 Bytes
Write Block: 512 Bytes
Chip Size: 3656M Bytes (High Capacity)
Name: "P1XXX"
Chip Type: MMC
Version: 4.0
Speed: 25000000Hz
Bus Width: 8bit
Boot Addr: 0 Bytes
*** Warning - bad CRC or eMMC, using default environment
Boot Env on eMMC
Env Offset: 0x00100000
Env Size: 0x00010000
Env Range: 0x00010000
SDK Version: HiSTBAndroidV500R001C01CP0002_v2014070614
[Android_Main,34] begin
[sw_set_gpio,85] ok
[sw_ptable_init,66] begin
partition addr : [0x200000]
[swfastboot_flash_read,31]BaseAddress:0x200000, DataSize:0x100000, offset:0x0, b ytes:0xa10
[sw_ptable_check,176]cksum [0x6c94], ptable->checksum[0x6c94]
[sw_ptable_init,79] data at 0x200000 is ok
0 fastboot 0x00000000 0x00200000
1 partition 0x00200000 0x00200000
2 recovery 0x00400000 0x01000000
3 deviceinfo 0x01400000 0x00200000
4 baseparam 0x01600000 0x00800000
5 pqparam 0x01E00000 0x00800000
6 logo 0x02600000 0x00800000
7 fastplay 0x02E00000 0x02800000
8 boot 0x05600000 0x01000000
9 misc 0x06600000 0x00200000
10 system 0x06800000 0x27000000
11 cache 0x2D800000 0x19000000
12 backup 0x46800000 0x19000000
13 swdb 0x5F800000 0x03000000
14 userdata 0x62800000 0x80000000
ptable info:2M(fastboot),2M(partition),16M(recovery),2M(deviceinfo),8M(baseparam ),8M(pqparam),8M(logo),40M(fastplay),16M(boot),2M(misc),624M(system),400M(cache) ,400M(backup),48M(swdb),2048M(userdata)
[sw_ptable_init,104] ok
[sw_devinfo_init,25] begin
deviceinfo addr : [0x01400000]
[swfastboot_flash_read,31]BaseAddress:0x1400000, DataSize:0x100000, offset:0x0, bytes:0x514
[sw_devinfo_check,166] start...
[sw_devinfo_check,184] ok,checksum:0x9aad
[sw_devinfo_init,44] data at 0x1400000 is ok
[0] count:[4] name:[serialno] value:[xxxxxxxxxxxxxxxx]
[1] count:[4] name:[mac] value:[00:03:63:f4:33:12]
[2] count:[4] name:[standard] value:[1080i_50Hz]
[3] count:[4] name:[secureline] value:[20100]
[sw_devinfo_init,71] ok
[swfastboot_flash_read,31]BaseAddress:0x6600000, DataSize:0x100000, offset:0x0, bytes:0x10000
boot normal!!!
[swfastboot_flash_read,31]BaseAddress:0x5602000, DataSize:0x100000, offset:0x0, bytes:0x2000
use boot cmdline,disable serial, cmdline:[mem=1G console=NULL,115200 blkdevparts =mmcblk0:]
bootargs:[mem=1G console=NULL,115200 blkdevparts=mmcblk0:2M(fastboot),2M(partiti on),16M(recovery),2M(deviceinfo),8M(baseparam),8M(pqparam),8M(logo),40M(fastplay ),16M(boot),2M(misc),624M(system),400M(cache),400M(backup),48M(swdb),2048M(userd ata) androidboot.mac=00:03:63:f4:33:12 androidboot.standard=1080i_50Hz androidbo ot.serialno=xxxxxxxxxxxxxxx]
authenticat kernel begin
CA_GetFlashImgInfoByAddr,683: Img has already be encrypted
CA_GetFlashImgInfoByAddr,689: Magic number check right
CA_FlashAuthenticateByAddr,898: CA_FlashAuthenticateByAddr 0x5600000 successe d
offset = 0x5600000 KernelImgInDDRAddress = 0x4002000bootimg now: bootm 4002000
[Android_Main,52] ok
stDispParam.enFormat = 6
sw_EdidAll[0] = 10
sw_EdidAll[1] = 5
sw_EdidAll[2] = 9
sw_EdidAll[3] = 8
sw_EdidAll[4] = 7
sw_EdidAll[5] = 6
sw_EdidAll[6] = 5
sw_EdidAll[7] = 1
sw_EdidAll[8] = 0
sw_EdidAll[9] = 101
use baseparam format [6]
Reserve Memory
Start Addr: 0xFFFF000
Bound Addr: 0x8D3B000
Free Addr: 0xF2FA000
Alloc Block: Addr Size
0xF2FA000 8192
0xF2FD000 2764800
0xF5A1000 3686400
0xF926000 1658880
0xFABC000 3686400
0xFE41000 12288
0xFE45000 1048576
0xFF46000 212992
0xFF7B000 8192
0xFF7E000 524288
Press Ctrl+C to stop autoboot
Found Initrd at 0x04E00000 (Size 535422 Bytes), align at 2048 Bytes
## Booting kernel from Legacy Image at 04002800 ...
Image Name: Linux-3.10.0_s40
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 8925824 Bytes = 8.5 MiB
Load Address: 02000000
Entry Point: 02000000
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
So what I've done is loaded a copy of linux compiled for ARM devices onto a sd-card ...
Unlike x86, there is no one build of a Linux kernel that executes on all "ARM devices".
Older ARM Linux kernels (i.e. pre-Device Tree) were configured and built specifically for each SoC/board variation.
Modern ARM Linux kernels can be built for one or more SoCs, and the kernel is booted with a Device Tree blob to describe the board in use.
You haven't provided any details to indicate if the kernel you have is sufficient to boot your "ARM device".
The problem now is what memory location do I tell U-boot to boot up the vmlinuz linux kernel?
ARM Linux should boot using a zImage file, not a vmlinuz file.
What is the start address of physical RAM on your device?
The convention is that the ARM Linux kernel will execute at the base of physical RAM plus an offset of 0x8000 (32K). See this answer for more details.
The zImage file is self-extracting, and can be loaded (by U-Boot from your SD card) to any suitable memory address above the kernel's load/execute address (while leaving room for the DT blob and not clobber U-Boot).
Or pointing out some resources would be great as well.
Try Russel King's Booting ARM Linux and Vincent Sanders' Booting ARM Linux.
Related
I am not sure whether the following situation is normal.
I have the following command to boot to kernel from uboot:
set mtdids nand0=pxa3xx_nand-0
set mtdparts mtdparts=pxa3xx_nand-0:0x600000(boot)ro,0x400000(kernel),-(rootfs)
usb start
fatload usb 0:1 0x201000000 ubifs.img
nand erase.part rootfs; ubi part rootfs; ubi create nand_rootfs
ubi write 0x201000000 nand_rootfs $filesize
fatload usb 0:1 0x206000000 Image;
fatload usb 0:1 0x201000000 dtb.dtb;
set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=2 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;
booti 0x206000000 - 0x201000000;
As you can see, since the Image and dtb are not stored internally, I have to plug in a USB to boot my device with this method. To get rid of using USB every time, I modified the cmds as follows:
set mtdparts mtdparts=pxa3xx_nand-0:0x600000(boot)ro,0x3200000(kernel),0x100000(dtb),0x100000(dtb_spare),0x5C80000(rootfs),-(rootfsubi); //I will explain why I made that many partitions
set kernelsize 0x2916808;
set dtbsize 0x1f15;
set ubifsimgsize 0x2cc0ff0;
nand erase.chip;usb start;
fatload usb 0:1 0x210000000 ubifs.img;
ubi part rootfs; ubi create nand_rootfs;
ubi write 0x210000000 nand_rootfs $ubifsimgsize;
nand write 0x210000000 rootfsubi $ubifsimgsize; // will be explained below
fatload usb 0:1 0x206000000 Image;
fatload usb 0:1 0x201000000 dtb.dtb;
nand write 0x206000000 kernel $kernelsize;
nand write 0x201000000 dtb $dtbsize;nand write 0x201000000 dtb_spare $dtbsize;
setenv boot_device 'nand read 0x206000000 kernel $kernelsize;nand read 0x201000000 dtb $dtbsize;set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=3 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;booti 0x206000000 - 0x201000000;'
set boot_cmd run boot_device;
set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=2 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;
saveenv
booti 0x206000000 - 0x201000000;
The first time boot using the above command was always successful. My problem happened when I reboot to uboot from kernel.
The "nand write" ubifs img appears because the ubi volume was gone but every time I boot to uboot from kernel. This command was meant to do the ubi device and volume process again without using USB.
Moreover, when the first time booted to the kernel, and reboot to enter uboot again, I discovered with the commands md address, ubi read and nand read that, the memory in the partition changed into UBI something. Please take a look at the picture below
Picture: Auto-changes to ubi something(?)
Basically all partition except the first 0x400000 bytes of kernel and boot behave as above when booted to uboot from kernel.
I did not find anything relevant online. I wonder if this is something normal when using ubi or ubifs to boot to kernel. Please let me know if you have any hints or clues about how to achieve booting to kernel without external USB.
Post the mtd part here if it matters:
uboot>> mtd
device nand0 <pxa3xx_nand-0>, # parts = 6
#: name size offset mask_flags
0: boot 0x00600000 0x00000000 1
1: kernel 0x03200000 0x00600000 0
2: dtb 0x00100000 0x03800000 0
3: dtb_spare 0x00100000 0x03900000 0
4: rootfs 0x05c80000 0x03a00000 0
5: rootfsubi 0x06980000 0x09680000 0
active partition: nand0,0 - (boot) 0x00600000 # 0x00000000
defaults:
mtdids :
mtdparts:
In a particular scenario I'm using NOR + NAND configuration with U-Boot on NOR and ubi image(kernel+fs) on NAND.
For the first time, U-boot(2016) can read the UBI image and loads the kernel successfully without any error as follows.
ubi0: attaching mtd2
ubi0: attached mtd2 (name "mtd=0", size 32 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 191496598
ubi0: available PEBs: 134, total reserved PEBs: 122, PEBs reserved for bad PEB handling: 20
Read 0 bytes from volume kernel to 84000000
No size specified -> Using max size (2793472)
## Loading kernel from FIT Image at 84000000 ...
But when try rebooting, the very next time I endup with UBI error as follows.
ubi0: attaching mtd2
ubi0: scanning is finished
UBI error: cannot attach mtd2
UBI init error 22
It seems like when UBI is read for the first time, U-Boot does some stamping or changes in the UBI header or something but I couldn't clearly find what causes this problem and which part of the u-boot code should I look into.
Make sure the UBI configuration is the same for Kernel and uboot. Run ubinfo in both environment and check each info one-by-one.
A possible error is the PEB number, Kernel will reserve 2% (20/1024) blocks, but uboot only reserves 1% (CONFIG_MTD_UBI_BEB_RESERVE 1)
Also make sure you have the same NAND-ECC scheme for both Kernel e U-Boot.
I have some toubles with mmc write on beagleboard black.
Here is the problem :
U-Boot# usb start
(Re)start USB...
USB0: scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
U-Boot# fatload usb 0 ${loadaddr} ${rootfs_file}
reading rootfs.ext4
18742272 bytes read in 12384 ms (1.4 MiB/s)
U-Boot# mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
U-Boot# mmc part
Partition Map for MMC device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 63 1028097 00000000-01 0c Boot
2 1028160 1028160 00000000-02 83
3 2056320 1686825 00000000-03 83
U-Boot# mmc dev 1 2
switch to partitions #2, OK
mmc1(part 2) is current device
U-Boot# mmc write $loadaddr 0x0 0x20000
MMC write: dev # 1, block # 0, count 131072 ... MMC: block number 0xffff exceeds max(0x800)
0 blocks written: ERROR
So why ? Partition 2 is supposed to be 64MB
moreover
U-Boot# mmc info
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC02
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.41
High Capacity: No
Capacity: 1 MiB <=== ??? WHY ???
Bus Width: 4-bit
Thanks for your replys
Fred
AFAIK "mmc write" performs raw writes to the MMC device. It does not perform write via the filesystem. There is no "write" support to most of the filesystem access commands. Only ext4 seems to have "write" operation (but I have not personally tested this). The "mmc write" you performed probably overwrote the MMC partition table.
I'm trying to get a stand-alone application for U-Boot running.
Target is a LEGO EV3 brick - it has an TI OMAP (ARM9) CPU.
The output of U-Boot before hanging is:
U-Boot > fatload mmc 0:1 c0007FC0 uimage
reading uimage
384 bytes read
U-Boot > bootm
## Booting kernel from Legacy Image at c0007fc0 ...
Image Name: ITK EV3 sample OS
Image Type: ARM Linux Standalone Program (uncompressed)
Data Size: 320 Bytes = 0.3 kB
Load Address: c0008000
Entry Point: c0008000
Loading Standalone Program ... OK
OK
I tried the following commands to be located at address 0xC0008000 in "uimage":
mov pc, lr (ARM code)
bx lr (ARM code)
bx lr (Thumb code)
These commands should simply return (depending on ARM or Thumb mode being active). However all three commands result in U-Boot hanging so no more output is done after the last "OK".
Why does U-Boot hang?
I found out the answer myself:
In the version of u-boot used on the EV3 brick there is a bug: The starting address that is already converted to little-endian is converted twice so the result is - of course - wrong.
By storing the number little endian in the file the output of u-boot will be wrong:
Image Type: ARM Linux Standalone Program (uncompressed)
Data Size: 320 Bytes = 0.3 kB
Load Address: c0008000
Entry Point: 008000c0 <--- actually 0xC0008000!!!
Loading Standalone Program ... OK
OK
U-Boot >
however booting will work. This bug only affects stand-alone programs and not Linux kernels.
My problem is that the program will possibly be published so it must work with both buggy and bug-fixed u-boot versions.
Therefore I think about loading the program to an address like
0xC00101C0
which is stored little and big endian the same way.
I've been trying to build and boot OpenEmbedded-Core on the evaluation kit for Freescale's ARM i.MX28, using the Freescale ARM layer for OpenEmbedded-Core. Unfortunately, I can't find a basic "Getting Started" guide (though there is a Yocto getting-started guide). Unfortunately, I haven't been able to "get started", to the point of successfully booting to a basic command prompt on the board's debug serial port.
Here is what I've been able to piece together, and as far as I've managed to get so far.
Fetch sources
mkdir -p oe-core/freescale-arm
cd oe-core/freescale-arm
git clone git://git.openembedded.org/openembedded-core oe-core
git clone git://github.com/Freescale/meta-fsl-arm.git
cd oe-core
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.openembedded.org/bitbake bitbake
Set up environment
. ./oe-init-build-env
That puts us in a new sub-directory build and sets certain environment variables.
Edit configuration
Edit the conf/bblayers.conf and local.conf files:
conf/bblayers.conf should have the meta-fls-arm and meta-oe layers added for BBLAYERS. E.g.:
BBLAYERS ?= " \
/home/craigm/oe-core/freescale-arm/oe-core/meta \
/home/craigm/oe-core/freescale-arm/oe-core/meta-openembedded/meta-oe \
${TOPDIR}/../../meta-fsl-arm \
"
In conf/local.conf, I set:
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "imx28evk"
Build
bitbake core-image-minimal
I ran this build overnight, and it has completed successfully for me. Output files were in ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images.
There are two boot options that I'd like to try, as described below. Boot from SD card is simpler, but takes quite a long time (~30 min) to write the image to the SD card. Booting from TFTP + NFS is faster, but requires more set-up.
Boot from SD Card
Write image to SD card:
sudo dd if=tmp-eglibc/deploy/images/core-image-minimal-imx28evk.sdcard of=/dev/sdc
It took something like 30 minutes (3.5 GB file). Then I put it in the board's SD card slot 0, and powered-up. It got as far as loading the kernel, then stopped:
U-Boot 2012.04.01-00059-g4e6e824 (Aug 23 2012 - 18:08:54)
Freescale i.MX28 family at 454 MHz
BOOT: SSP SD/MMC #0, 3V3
DRAM: 128 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
Hit any key to stop autoboot: 0
reading boot.scr
** Unable to read "boot.scr" from mmc 0:2 **
reading uImage
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Boot from TFTP + NFS
First, I tried to write U-Boot onto an SD card:
sudo dd if=tmp-eglibc/deploy/images/u-boot-imx28evk.mxsboot-sdcard of=/dev/sdc
Then I put it in the board's SD card slot 0, and powered-up. But all I got in the debug serial port was:
0x8020a01d
So, I decided to use Freescale's distribution of U-Boot for i.MX28 (from their LTIB distribution) onto an SD card. I set suitable U-Boot parameters for NFS booting with parameters from DHCP.
setenv bootargs console=ttyAMA0,115200n8
setenv bootargs_nfs setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=,v3,tcp fec_mac=${ethaddr}
saveenv
I connected to a DD-WRT router with the following DNSmasq settings:
dhcp-boot=,,192.168.250.106
dhcp-option=17,"192.168.250.106:/home/craigm/rootfs"
On my host PC, I set up a TFTP server to serve the uImage file from ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images/.
I also set up a root NFS server to serve the root file system. I edited /etc/exports to serve /home/craigm/rootfs. I extracted the root file system:
bitbake meta-ide-support
rm -Rf ~/rootfs
runqemu-extract-sdk tmp-eglibc/deploy/images/core-image-minimal-imx28evk.tar.bz2 ~/rootfs
Then I put the U-Boot SD card in the board's SD card slot 0, and powered-up. It got as far as this, then stopped:
...
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:03:33 UTC (213)
eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
Sending DHCP requests .
PHY: 0:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.142
IP-Config: Complete:
device=eth0, addr=192.168.250.142, mask=255.255.255.0, gw=192.168.250.1,
host=192.168.250.142, domain=, nis-domain=(none),
bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs
Looking up port of RPC 100003/3 on 192.168.250.106
Looking up port of RPC 100005/3 on 192.168.250.106
VFS: Mounted root (nfs filesystem) on device 0:15.
Freeing init memory: 160K
I'm not sure if it's running without a serial console, or some other problem. I can ping it on 192.168.250.142, but I can't Telnet or SSH to it.
Questions
Is there any sort of "getting started" guide for OpenEmbedded-Core on Freescale's i.MX28?
Is the Freescale ARM layer really intended for use with OpenEmbedded-Core, Yocto, or what? I don't really understand how those projects relate.
Has anyone else had success booting a minimal image of OpenEmbedded-Core on Freescale's i.MX28? If so, how did your procedure differ from mine?
I'm not sure at this stage whether the problem is just a non-functional serial console, or some other sort of issue. It's hard to diagnose these problems that prevent even getting a basic system running. Any pointers on how to diagnose at this point?
Why would the U-Boot be broken so it can't even boot?
From the boot message it looks like U-boot is working fine. U-boot is not broken.
The following boot message
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
By the above log u-boot has done its job.
"Booting the kernel" is the point where bootloader given the control to the kernel.
I guess the problem might be in kernel image or in memory.
To eliminate the problem of memory, try to check the manual and try to read and write in the RAM using the board's reference manual.
From the boot log RAM looks like has no problem. It has been initialized.
DRAM: 128 MiB
Check if the following message is not causing any problem.
* Warning - bad CRC, using default environment
Check if all the devices have been initialized and nothing is skipped after the bad crc warning.