I am trying to restore an Allwinner A13 based OEM board to working condition, because the original SD card died and there is currently no way to get an original backup image.
Only thing I have so far is the linux rootfs and a partition table it wants to use (The original sizes and filesystems are too unknown to me, so I used what i deemed purposeful).
I have created the partition table, put the rootfs into its partition and set up the toolchain to compile the u-boot + spl.
The board itself only has one Micro SD slot, and this card contains the u-boot + SPL on its first megabyte after the partition table.
The spl and u-boot layout I use:
sector (512b) start size usage
---------------------------------------
0-15 (16) 0kb 8kb MBR+GPT
16-79 (64) 8kb 32kb SPL
80-2047 (1968) 40kb 984kb u-boot
2048 (----) 1024kb (----) partitions
The partition table:
1 MBR 512MB FAT "mmcblk0p1" drive for recovery firmware dumps
2 MBR 512MB FAT "mmcblk0p2" boot volume. perhaps for u-boot environment
3 MBR GPT Container
4 GPT
5 GPT
6 GPT 2048MB ext2 "mmcblk0p6" rootfs
7 GPT 4096MB ext2 "mmcblk0p7" file system for user data
8 GPT 1024MB ext2 "mmcblk0p8" squash image and/or backup are stored here
The rootfs partition contains a folder named boot with these files inside, so I assume the SPL / u-boot eventually wants to boot from there:
/boot/script.bin 32KB
/boot/devicetree.dtb 38KB
/boot/uImage 5200KB
The SPL dies with the following error message on the serial (it doesn't even find the u-boot, the result is the same with only the SPL part dd-ed on the card):
U-Boot SPL 2020.07-rc4-STT-LMT-00022-gbe79009f3b (Jun 12 2020 - 23:40:45 +0000)
DRAM: 256 MiB
CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC2
MMC Device 1 not found
spl: could not find mmc device 1. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
How can I successfully have this boot the os on the rootfs?
Related
In windows 10, I'm trying to install ubuntu with USB. For making bootable USB, I'm using rufus.
However, there occurs an authentication problem even though I logged in Windows with an administrator account.
Here's the log from rufus.
Will reuse 'ldlinux.sys' and 'ldlinux.bss' from './rufus_files/rufus_files/syslinux-6.03/20171017/' for Syslinux installation
Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE1 for exclusive write access
Requesting lock...
ABORTED: Cannot use an image that is located on the target drive!
\\?\Volume{d0782feb-cabc-11e8-b19e-806e6f6e6963}\ was already mounted as D:\
Re-mounted volume as 'D:' after error
Found USB 2.0 device 'Generic Flash Disk USB Device' (058F:6387)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x1F76D35D
Drive has an unknown Master Boot Record
Partition 1:
Type: NTFS (0x07)
Size: 7.5 GB (8048869376 bytes)
Start Sector: 8192, Boot: No
Found USB 2.0 device 'Generic Flash Disk USB Device' (058F:6387)
1 device found
Disk type: Removable, Disk size: 8 GB, Sector size: 512 bytes
Cylinders: 979, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x1F76D35D
Drive has an unknown Master Boot Record
Partition 1:
Type: NTFS (0x07)
Size: 7.5 GB (8048869376 bytes)
Start Sector: 8192, Boot: No
It seems like there's some problem during locking.
How can I solve this?
ABORTED: Cannot use an image that is located on the target drive!
The line above means that you are trying to write the drive on which your ISO resides. This is the equivalent to sawing the branch you are sitting on!
Of course, Rufus cannot erase a drive if the image you want to apply resides on that drive.
Please remember that Rufus always repartitions and reformats a drive, so you cannot use anything from that drive, especially not an ISO.
The solution: Move your .iso file somewhere else that isn't the USB drive you are trying to use with Rufus.
after formatting your USB and installing windows, you have one problem after formatting your USB!
USB can't detect in mp3 player, mobile phones, and car.
solve problem =>
open Rufus
choose "MBR partition scheme for BIOS or UEFI" in the partition scheme.
unchoose "create a bootable disk usage"
unchoose "Create extended label and icon files"
click "START" for formatting your USB.
I am dealing with android boot.img which is a combination of compressed kernel, ramdisk, and dtb. I see from the serial console log from uboot about the booting process and here's the part that triggers my curiosity
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
CPU: Temperature 27 C
Reset cause: POR
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
check_and_clean: reg 0, flag_set 0
Fastboot: Normal
flash target is MMC:1
Net: FEC [PRIME]
Normal Boot
Hit any key to stop autoboot: 3 2 1 0
boota mmc1
kernel # 14008000 (7272352)
ramdisk # 15000000 (869937)
fdt # 14f00000 (44072)
## Booting Android Image at 0x12000000 ...
Kernel load addr 0x14008000 size 7102 KiB
Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1920x1080M#60,bpp=32 video=mxcfb1:off video=mxcfb:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consolebalank=0 androidboot.hardware=freescale cma=384M
## Flattened Device Tree blob at 14f00000
Booting using the fdt blob at 0x14f00000
Loading Kernel Image ... OK
Using Device Tree in place at 14f00000, end 14f0dc27
switch to ldo_bypass mode!
Starting kernel ...
The kernel's address is 14008000, ramdisk 15000000, fdt 14f00000.
I have found out that these values are saved in the boot.img header and when I manually mess with this values, the image will not boot even though the actual contents are not modified.
Why is this address so critical? Why does it have to be these values? why not other values?
One of my own guess is:
these load address values are hardcoded inside the kernel so if I change it in the boot.img header it will cause side-effects. To elaborate my own theory, loading the kernel to the 'modified' load addr won't be a problem. But when actually executing the lines, it will cause severe problems because these codes are fixed to work with the proper 'load addr'.
Is my theory wrong? If so, I'd be grateful if you could correct me.
After the U-boot finished, it needs to handover the further execution to kernel so that kernel takes care for all further processes. Plus Kernel have some set of routines which are essential to initialize the board.
These set of routines have a entry point start_kernel(). Before this some other routines are also called to execute start_kernel. That can be identified by this linker script and this init.S.
To maintain execution in this procedure kernel need to be started from a particular address, moreover its data segments and other memories are also attached with that so to load and run all these in a proper manner, exact memory location need to be provided.
With this kernel needs the device tree blob for probing the devices attached to it and the rootfs to bring up the user space, here to load the device tree and rootfs exact offsets are needed so that any data should not be missed or corrupted. Every single byte is important for all these execution.
So to safely bootup all these values are being stored in bootloader's configuration.
I've been playing around modifying the MBR of an old USB stick, booting from it, testing the various BIOS functions, etc...
But I don't seem to understand - What does the BIOS look for when deciding which device to boot from?
The obvious 2 requirements are:
Changing the BIOS boot order so it tries to boot from the USB when it is connected.
Have the MBR singature - 0x55aa at offset 0x1fe.
For some reason, my laptop only boots from the USB for some of the MBRs I wrote, and for others it boots from the main HD, ignoring the USB. Of course all are signed with 0x55aa.
Why does it happen? What else does the BIOS look for?
After a valid MBR is found (via the signature you mentioned), the BIOS checks the first byte of each of the MBR's 16-byte partition records. 0x80 means the partition is bootable (or "active"), 0x00 otherwise.
If a bootable partition is found, the code in the first sector of that partition -- the Volume Boot Record -- is loaded. The VBR contains the OS bootstrapping code.
Some implementations may also validate checksums and other flags.
What is the role of ZTEXTADDR in Linux kernel ?
From lxr.linux.no, it's an address in RAM that holds address of zImage as sequence below?
A.
uImage (DataFlash/NAND) ---load_to_RAM--->
uImage (# boot_addr) ---decompress_uImage-->
zImage (# ZTEXTADDR) --- decompress_zImage--->
uncompressed image (# ZRELADDR).
or just:
B.
uImage (DataFlash/NAND) ---load_to_RAM--->
uImage (# boot_addr) ---decompress_uImage-->
uncompressed image (# ZRELADDR)
no using ZTEXTADDR in new kernel version for booting process ?
The Linux ARM decompression boot loader is capable of relocating itself when running from RAM. The relocation portion is PC-relative and so it can be loaded at any address. However, if your main image starts from FLASH/ROM, the code can not be relocated; while moving an image in RAM is a simple memmove(), it is much more involved for NOR flash and can be impossible for ROM.
In this case, a compressed boot linker script is used with the ZTEXTADDR as the location of the decompression code. In your diagram, you have a u-boot, which will load the uImage. There is no reason to execute this directly from Flash/ROM. u-boot can copy the image to RAM and there is no need for the ZTEXTADDR value and it should be left as zero.
If your image boots directly from Flash/ROM, without a boot loader then ZTEXTADDR is useful,
zImage (in flash) --> decompress vmlinux.bin to RAM --> run kernel
The zImage may need to be annotated with some chip setup for this to work and would need ATAGS or device trees linked. For this reason, there are many machine variants in boot/compressed; This is not maintainable and these type of files are discouraged. Typically another bootloader loads the image to RAM and the zImage can move itself to whatever destination it needs; I think that is your situation and you should set ZTEXTADDR to zero and forget about it.
I am working on Freescale board imx50evk. I have built the uboot.bin and uImage using LTIB (linux target image builder). At the U-Boot prompt I enter the bootm addr command, and then it hangs after showing the message "Loading Kernel..."
> MX50_RDP U-Boot > boot
MMC read: dev # 0, block # 2048, count 6290 partition # 0 ...
6290 blocks read: OK
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.35.8
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1323688 Bytes = 1.3 MB
Load Address: a0008000
Entry Point: a0008000
Verifying Checksum ... OK
Loading Kernel Image ...
You need to verify that your board really has RAM at 0xa0008000, which is the kernel "load address". U-Boot is probably trying to copy the image to that region of memory when it appears to hang.
[By your comment, I'll assume that you have verified that main memory does not exist at physical address 0xAXXXXXXX.]
The uImage file that you are using was made from the zImage file using the mkimage utility.
You probably have to manually edit the line that looks like
zreladdr-y := 0xa0008000
in arch/arm/mach-XXX/Makefile.boot for your board. The convention is that this address should be the base of physical RAM plus an offset of 0x8000 (32K). Then adjust the other values in the file. Delete the zImage file and perform another make for the kernel.
While building 3.20 development kernels for rockchip's rk3288 I found using LZO image compression made the device hang at 'Starting the kernel.' I assume it's because of a version miss-match between the build hosts LZO and the deployed decompression code, so it could probably happen with any of the compression algorithms. In my case switch to gzip fixed it.
This is only my assumption for why changing the compression algorithm gave a bootable kernel. Please correct me if I'm wrong.