I'm booting kernel on my board with u-boot ramdisk image which is 39.8 MB. It boots successfully. When I try another u-boot image which has 74.7 MB size, load adress of ramdisk changing and its giving
'Loading Ramdisk to ff8c0000, end 03fffd63... Bad Trap at PC:7fef8cb0'
and board hangs with ' ###ERROR ### Please RESET the board ###'
Commands I use for booting with tftp:
tftp 30000000 uImage.bin
tftp 32000000 DTB.dtb
tftp 40000000 rootfs.ext2.gz.u-boot
bootm 30000000 40000000 32000000
I also tried different tftp adresses.
Scenario remains same.
How can I solve this situation?
Edit: Full Console log:
=> bootm 30000000 40000000 32000000 WARNING: adjusting available memory to 30000000
Booting kernel from Legacy Image at 30000000 ...
Image Name: Linux-4.19.26+gc0c2141
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 7140198 Bytes = 6.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading init Ramdisk from Legacy Image at 40000000 ...
Image Name: core-image-x11-t1042d4rdb-64b-20
Image Type: PowerPC Linux RAMDisk Image (uncompressed)
Data Size: 74710371 Bytes = 71.2 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Flattened Device Tree blob at 32000000
Booting using the fdt blob at 0x32000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to ff8c0000, end 03fffd63 ... Bad trap at PC:
7fef8cb0, SR: 0
NIP: 7FEF8CB0 XER: 20000000 LR: 7FF16C60 REGS: 7faedae0 TRAP: 0d00
DAR: FFFFEFFC
MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00000003 7FAEDBD0 7FAEDE98 FF8C0000 4073F038 0473FD60 FFFFF000
5E2AE23B GPR08: DE633873 00000020 00000001 7FAEDBE0 7FFCB808 08200800
7FAF52E8 00000000 GPR16: 00000000 00000000 306CF3A6 30000000 00000001
30000040 00000000 7FF957A8 GPR24: 7FAF533C 7FFCB6FC 7FFCB718 40000040
04000000 7FFCB6F8 7FF78540 0473FD63 Call backtrace: 7FFCB6F8 7FF176CC
7FF0D9D4 7FEFA26C 7FF1B088 7FF0BC44 7FF0BE08 7FF0C3B8 7FF1A664
7FF09CDC 7FF0CCC4 7FF4FF3C 7FF0D1D0 7FEF1040 Exception in kernel pc
7fef8cb0 signal 0
ERROR ### Please RESET the board ###
You are loading the kernel image at 0x30000000. Afterwards you are loading the device tree at 0x30000000.
0x32000000 - 0x30000000 = 0x2000000 = 33554432
So when loading the device tree you are overwriting the kernel image.
If the area between 0x3f000000 and 0x40000000 is not used otherwise, choosing 0x3f000000 for the device tree should solve your problem.
What I understood so far is, the adress in
'Bad trap at PC: 7fef8cb0'
7fef8cb0 nearly equals 1,998995945 GB and start adress of Ramdisk seems ff8c0000 which nearly equals 3,992919922 GB.
Why U-boot is arranged so many memory for a ~70 MB ramdisk image ?
Related
I have a memory crash dump, and I can list processes with !process 0 0
What I want to do is find the Image Base Address of calc.exe and get its contents from the memory. Potentially saving it into a file.
what do I need to do to achieve that?
Edit: the type of dump I have is "automatic dump" but I would like to know the technique for other types such as full core dump
a dump can be of several types
what is the type of dump is it user mode or kernel mode ?
it is mindump of full dump ?
in many cases the pages may not be present either being paged out or intentionally discarded init section of modules
anyway
if user mode try !vadump or !address to locate the module of interest find its start address and end address and try dumping in page size increments (0x1000 bytes )using .writemem
in kmode use !vad
and follow both commands by lm or !dh to get the module information in both user mode and kernelmode
here is an user mode dump !address info
F:\caldump>cdb -c "!address calculator;q" -z calc.dmp | awk "/Reading/,/quit/"
0:023> cdb: Reading initial command '!address calculator;q'
Usage: Image
Base Address: 00007ff7`04a30000
End Address: 00007ff7`04a31000
Region Size: 00000000`00001000 ( 4.000 kB)
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
Type: 01000000 MEM_IMAGE
Allocation Base: 00007ff7`04a30000
Allocation Protect: 00000080 PAGE_EXECUTE_WRITECOPY
Image Path: C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1906.55.0_x64__8wekyb3d8bbwe\Calculator.exe
Module Name: Calculator
Loaded Image Name:
Mapped Image Name:
More info: lmv m Calculator
More info: !lmi Calculator
More info: ln 0x7ff704a30000
More info: !dh 0x7ff704a30000
Since !process 0 0 works then it's a kernel dump. Try inspecting the peb
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-peb
UPDATE:
So the question is as follows: My build setup generates an archive/lib (binary output), which I would like to extract some data from, for compression in my case, but that really is not the point.
My instincts tells me, that since a linker can extract constant data from an archive/lib, It should be possible/easy for me to "dump" the binary "contents" of a symbol contained in an archive/lib to e.g. a file....
So that's my question: How to dump binary contents of a symbol in an archive/lib (in ELF format)?
UPDATE:
I am building an application based on lvgl.
To allow texts I'm using the online tool provided by the lvgl maintainer to convert TrueType fonts into C-code (const data) which is linked into the application for rendering texts.
But the resulting data-set for the fonts is getting too large for my available flash memory, but I have a big chunk of un-used RAM. So, I would like to use heatshrink to compress the data, and un-compress to RAM at runtime.
This requires, that my build setup can extract the binary data, compress it, and link to flash, so that my run-time code can de-compress it.
I guessed, that I could stuff all the generated font-data into a "lib", extract the binary data, compress it, and link as a "blob" into the application.
But I'm failing to extract the data to compress from the library
E.g. my font-data declaration looks as follows:
/*Store the image of the letters (glyph)*/
static const uint8_t _glyph_bitmap[] =
{ /* const Byte values follow (e.g. 0x00) */ };
static const lv_font_glyph_dsc_t _glyph_dsc[] =
{ /* struct initialization follows */ }
lv_font_t myfont
{ /* struct initialization follows */ }
So I would need to access the myfont, and the declarations it is referencing in binary form.
I have a tool, which creates c-code representing some binary data, to allow the data to be compiled & linked into a final executable (ARM platform, GNU toolchain, custom hardware).
I am running out of flash, but have RAM to spare. So i'm considering compressing some large constant-data sections in a library, and decompress these to RAM as needed.
So I can compile the c-code, and stuff that into an archive. But so far i've had no luck trying to extract the binary data of the constant-data for compression using e.g. objdump or objcopy. But something tells me, that this is possible (and maybe easy even). But how? I've tried to "google" the problem, but came up empty-handed.
Eureka! I figured it out!
While I fully acknowledge and appreciate the advice given in comments / other answers, it still bothered me that I speculated it should be relatively easy to "play the linker" and extract blobs of hardcoded data from e.g an object-file.
Well, it turns out to be relatively easy (for elf format objects anyways) just as expected by using readelf
To dump a symbol, I used two steps:
Figure out the symbol index, by looking at the symbols in the object:
$ readelf --syms company_logo.o
Symbol table '.symtab' contains 17 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS company_logo.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 2
4: 00000000 0 SECTION LOCAL DEFAULT 3
5: 00000000 0 SECTION LOCAL DEFAULT 4
6: 00000000 0 NOTYPE LOCAL DEFAULT 4 $d
7: 00000000 0 SECTION LOCAL DEFAULT 6
8: 00000000 0 SECTION LOCAL DEFAULT 7
9: 00000000 0 SECTION LOCAL DEFAULT 9
10: 00000000 0 SECTION LOCAL DEFAULT 10
11: 00000000 0 SECTION LOCAL DEFAULT 12
12: 00000000 0 SECTION LOCAL DEFAULT 13
13: 00000000 0 SECTION LOCAL DEFAULT 14
14: 00000000 0 SECTION LOCAL DEFAULT 15
15: 00000000 12 OBJECT GLOBAL DEFAULT 4 company_logo
16: 00000000 21879 OBJECT GLOBAL DEFAULT 6 company_logo_map
Dump the contents of the symbol.
Now company_logo_mapwas my target, so use its index 6, as follows:
`readelf --hex-dump=6 company_logo.o`
` `
`Hex dump of section '.rodata.company_logo_map':`
` 0x00000000 00000000 00000000 00000000 00000000 ................`
` 0x00000010 00000000 00000000 00000000 00000000 ................`
` 0x00000020 00000000 00000000 00000000 00000000 ................`
` 0x00000030 00000000 00000000 00000000 00000000 ................`
` ... lots more data here`
Rather than extract data from the compiled binary, why not extract it from the generated C code, compress it, and generate equivalent C code with the compressed data?
This approach would probably simplify many aspects of implementation, debugging, and testing.
At first, I didn't add any kernel parameter and then got MTD device
/proc/mtd:
dev: size erasesize name
mtd0: 01000000 00010000 "spi1.0"
then, I added setenv mtdids "mtdids=spi1.0", and
setenv mtdparts "mtdparts=spi1.0:2m(U-Boot)ro,-(RootFS)ro" to kernel command line, at the meantime, I turned on
"Command line partition table parsing",
"ARM Firmware Suite partition parsing"
of Device Drivers ---> Memory Technology Device (MTD) support through Kconfig.
Finally, I got,
dev: size erasesize name
mtd0: 00100000 00010000 "u-boot"
mtd1: 00400000 00010000 "kernel"
mtd2: 00a00000 00010000 "rootfs"
But this is still not what I want.
Do I have something missing?
Thanks for help,
you can work with it but after creating the partitions you must create an ubifs file system for the each partitions, then only the board will work with the MTD.
I'm including my rootfs (CONFIG_INITRAMFS_SOURCE) into my kernel, so the kernel has now a size of 17Mb:
$ ls -la uImage
-rw-r--r-- 1 kkr kkr 17669274 Dec 1 18:59 uImage
$ d2h 17669274
0x10D9C9A
Since it's compressed, it would occupied uncompressed 39Mb:
$ dd if=uImage of=uImage-x.gz bs=64 skip=1
$ file uImage-x.gz
uImage-x.gz: gzip compressed data, max compression, from Unix
$ gunzip uImage-x.gz
$ ls -la uImage-x
-rw-r--r-- 1 kkr kkr 39852288 Dec 1 19:18 uImage-x
$ d2h 39852288
0x2601900
Why cannot I start my kernel via uBoot with this commands?
=> setenv bootargs console=$consoledev,$baudrate $othbootargs
=> tftp 0x3000000 $bootfile
Speed: 100, half duplex
Using eTSEC1 device
TFTP from server 192.168.32.3; our IP address is 192.168.32.32
Filename 'uImage-powerpc'.
Load address: 0x3000000
Loading: #####################################################
done
Bytes transferred = 17669274 (10d9c9a hex)
=> tftp 0x2700000 $fdtfile;
Speed: 100, half duplex
Using eTSEC1 device
TFTP from server 192.168.32.3; our IP address is 192.168.32.32
Filename 'sat_92107.100.00C_p2020.dtb'.
Load address: 0x2700000
Loading: ##
done
Bytes transferred = 15164 (3b3c hex)
=> bootm 0x3000000 - 0x2700000
## Booting kernel from Legacy Image at 03000000 ...
Image Name: Linux-4.0.0-AOA00.01-00662-g07ae
Created: 2015-12-01 17:59:21 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 17669210 Bytes = 16.9 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02700000
Booting using the fdt blob at 0x02700000
Uncompressing Kernel Image ... OK
ERROR: Failed to allocate 0x6b3c bytes below 0x1000000.
device tree - allocation error
Since the kernel itself needs 0x10d9c9a bytes (compressed) or 0x2601900 bytes (uncompressed) there is no chance to place the devicetree below 0x1000000. Is this value (16Mb) configurable? Does my extracted kernel have be less than 16Mb otherwise?
Yes, this value is configurable in U-Boot by setting the environment variables bootm_low and bootm_size to hexadecimal values. In your case, it's 0x0 and 0x20000000, respectively.
See section "Environment Variables" of the big README file in the U-Boot source tree.
I'm using old Linux-2.6.10 with ramdisk for MIPS arch. I was needed to enlarge my initrd for debug purposes. So, I did this. But with big initrd (~2.1MB) my board restarts faultly.
MY-BOARD # run bootnet
Using Board Eth. device
TFTP from server 192.168.1.10; our IP address is 192.168.1.1
Filename 'uImage'.
Load address: 0x80800000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
done
Bytes transferred = 3247396 (318d24 hex)
## Booting image at 80800000 ...
Image Name: Linux-2.6.10 with ramdisk
Created: 2014-01-13 8:27:39 UTC
Image Type: MIPS Linux Kernel Image (gzip compressed)
Data Size: 3247332 Bytes = 3.1 MB
Load Address: 80100000
Entry Point: 8057b000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Error: Boot failed!
My u-boot environment:
Type "printenv" to view boot options.
Hit any key to stop autoboot: 0
MY-BOARD # printenv
bootargs=console=ttyS0,115200 nofpu mem=30M root=/dev/ram0 rw
bootcmd=cp.b 0xad040000 0x80800000 0x400000; bootm 0x80800000
bootdelay=3
baudrate=115200
ethaddr=00:06:0D:00:00:00
ipaddr=192.168.1.1
serverip=192.168.1.10
preboot=echo; echo Type "printenv" to view boot options.; echo;
netmask=255.255.255.0
u-bootfile=u-boot.bin
prog-ub=run load-ub update-ub
load-ub=tftp 80504000 $(u-bootfile)
update-ub=protect off 1:0-4; cp.b AD000000 80500000 4000; cp.b AD03F000 8053F000 1000; erase 0xAD000000 0xAD03ffff; cp.b 80500000 AD000000 0x40000
imget=tftp 0x80800000 $(imname); erase 0xad000000 0xad7e0000; cp.b 0x80800000 0xad000000 $(filesize)
progkn=tftp 0x80800000 uImage; erase 0xad040000 0xad43ffff; cp.b 0x80800000 0xad040000 $(filesize)
progjffs=tftp 0x80800000 jffs; erase 0xad240000 0xad53ffff; cp.b 0x80800000
0xad240000 $(filesize)
bootnet=tftp 0x80800000 uImage; bootm 0x80800000
stdin=serial
stdout=serial
stderr=serial
ethact=Board Eth.
Environment size: 980/4092 bytes
MY-BOARD #
Does somebody know or remember how to fix this? I also use old U-Boot 1.1.2. U-Boot reaches "Starting kernel ..." and jump to the kernel entry point, theKernel() function. There is restart then ("Error: Boot failed!").
The kernel so old that it hasn't early_printk to debug itself. Imho, U-Boot is ok, and I miss some initrd option (I made all visible kernel .config). With small embedded initrd image (~700kB) Linux boot smoothly. In both cases initrd has the same size (8192K).
p.s.: I am sorry for imperfect English.