Remote Proc fails to load FreeRTOS Elf - elf

I am using this port of FreeRTOS and I am loading it onto the Cortex-M3 within an OMAP4430. This works fine using the remote proc framework and I am able to use RPMsg to communicate with it.
Sometimes, however, rproc fails to load the elf and gives the following error:
rproc remoteproc1: bad phdr da 0x0 mem 0x10310
rproc remoteproc1: Failed to load program segments: -22
rproc remoteproc1: rproc_boot() failed -22
This seems to happen when the size of the elf file gets too large: this happens when the size is 377331 bytes but does not happen when I simply remove a bunch of print statements and bring the size down to 342563 bytes.
I have tracked the error message down to this piece of code: http://lxr.free-electrons.com/source/drivers/remoteproc/remoteproc_elf_loader.c?v=3.9#L188. It seems that rproc_da_to_va is unable to find a segment in memory large enough to fit the ELF.
How can I make sure that there is enough memory for the size of my ELF? Can I tell the kernel that I specifically want a certain region preallocated for this kind of thing? Is there some way to ensure that this part of my ELF remains small?
Thanks!

Make sure that the FreeRTOS configuration constants configTEXT_SIZE and configDATA_SIZE agree with the amounts demanded by your linker script. For example, if your linker script contains
MEMORY
{
TEXT (rwx) : ORIGIN = 0x00000000, LENGTH = 1M
DATA (rwx) : ORIGIN = 0x80000000, LENGTH = 1M
}
then you should set configTEXT_SIZE and configDATA_SIZE to 0x100000.

Related

In u-boot compile, linker script's sdram start and length are set by CONFIG_SPL_BSS_START_ADDR and CONFIG_SPL_BSS_MAX_SIZE values, why?

I'm trying to build u-boot for our simple test board. (arm64)
After setting in include/configs/ab21m.h (our board),
#define CONFIG_SPL_BSS_START_ADDR 0x4f00000
#define CONFIG_SPL_BSS_MAX_SIZE SZ_32K
when I compile it, it gives me error while linking u-boot-spl. The error message is like this.
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
UPD include/generated/timestamp_autogenerated.h
CFGCHK u-boot.cfg
CC cmd/version.o
AR cmd/built-in.o
LD u-boot
CC spl/common/spl/spl.o
OBJCOPY u-boot.srec
OBJCOPY u-boot-nodtb.bin
SYM u-boot.sym
RELOC u-boot-nodtb.bin
COPY u-boot.bin
MKIMAGE u-boot.img
LD u-boot.elf
AR spl/common/spl/built-in.o
LD spl/u-boot-spl
aarch64-none-elf-ld.bfd: invalid length for memory region .sdram
make[1]: *** [scripts/Makefile.spl:509: spl/u-boot-spl] Error 1
make: *** [Makefile:1984: spl/u-boot-spl] Error 2
make: *** Waiting for unfinished jobs....
By the way, the linker script for spl starts like this after the build.
MEMORY { .sram : ORIGIN = 0x4000000,
LENGTH = (14*1024*1024) }
MEMORY { .sdram : ORIGIN = 0x4f00000,
LENGTH = SZ_32K }
OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SECTIONS
{
This is strange because this 0x4f00000 and SZ_32K is what I gave for CONFIG_SPL_BSS_START_ADDR and CONFIG_SPL_BSS_MAX_SIZE. I placed this range in the on-chip RAM area some enough space above CONFIG_SPL_TEXT_BASE and below CONFIG_SPL_STACK with enough stack space. (I referenced imx8mm_evk board). What should I correct?
BTW, I found CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_INIT_RAM_ADDR are all set to 0x40000000in imx8mm_evk, which is the DRAM start addrss. But CONFIG_SYS_INIT_RAM_SIZE is set to 0x200000 (2MB) where there is actually 3072MB DDR. Why is this value set to small size?
I asked two qeustions. Any help will be very much appreciated.
So, your first problem is a literal one. You have SZ_32K as the value for CONFIG_SPL_BSS_MAX_SIZE but since you're likely lacking #include <linux/sizes.h> in include/configs/ab21m.h you're not getting that constant evaluated.
As for what this is all doing, and why you should likely use something more like 2MB as seen on other platforms and place it in SDRAM rather than much smaller on-chip memory, if you look at arch/arm/cpu/armv8/u-boot-spl.lds you can see we're defining where the BSS should reside and that's likely larger than 32KB (and you'll get an overflow error when linking, if so).

required size of a configuration file for a HX1K (in "SPI slave" mode)

I am reworking the programmer for the Olimex iCE40HX1K board (targetted towards a STM32F103 ma) where I also would like to implement the "SPI Slave" mode to configure an image directly into RAM without using the serial flash.
Looking at the Lattice "programming and Configuration guide" (page 11), it is noted in table 8 that a EPROM for a ICE40-LP/LX1K must be at least 34112 bytes. (which -I guess- means that the configuration-files can be up to that size).
However, all images I have (sofar) created with the icestorm tools are 32220 octets.
I am a bit puzzled here.
Can somebody explain the difference between these two figures?
Does the HX1K need a configuration-file of 32220 or 34112 bytes?
I don't know how Lattice arrived at this number. A complete HX1K bin file with BRAM initialization but without comment and without multiboot header is 32220 bytes in size. The (optional) multiboot header would add another 160 bytes (32220 + 160 = 32380). The lattice tools usually add about 80 bytes to the comment field (32220 + 80 = 32300). Whatever I do, all numbers I have are more than 1000 short of 34112.
I don't know if there is a maximum length for the comment. Maybe there is and 34112 is the size of a bit stream with a comment of maximum length?
34112 - 32220 = 1892. Maybe someone decided to add 8kB (8192 bytes) just in case, but that person accidentally swapped the first two digits? Idk..
If you don't care about comments or multiboot headers, then iCE40 1K bit-streams have a fixed size, and that size is 32220 bytes.

SCSI read(10) reads out weird values- USB pendrive

I am implementing USB as a host using OHCI to read the files stored in the Flashdrive. To read I implement the read(10) command in SCSI. The Logical Block address being the sector number. The following is an image of the command I send for read(10) to read LBA 0x0000-
http://i.imgur.com/ky4FHlm.png
I read 512bytes(size of one sector or 1 LBA)and the following is the output that i get for LBA 0x0000-
http://imgur.com/jL6OEjE
The bytes in the above image are not present any where on the pendrive, I checked that using HXD. Now, for testing I filled the pendrive to full capacity. If I read any other LBA, other than 0x0000, then I always get 512 bytes of 0x00.
Could anyone please tell me what the problem could be?
Am I supposed to execute some other command before I do a read(10) so that the USB sends me the right data maybe?
From my understanding I have put DPO, FUA and FUA_NV=0 and also RDPROTECT=2

Binary, produced by MSP430GCC, has strange start address for text segment

After compiling an exemplary C program with msp430-gcc (LTS 20120406 unpatched) for the MSPG2211 I got the following output using the readelf command:
section header
program header
The address space of the MSPG2211 microcontroller is structured as follows:
0x0000 - 0x01FF - Peripherals
0x0200 - 0x027F - RAM
0x1000 - 0x10FF - Flash (information memory)
0x1100 - 0xF7FF - ???
0xF800 - 0xFFFF - Flash (code memory + interrupt vectors)
The text section shown in the section header starts at 0xF800 which is the first address of the code memory.
The text segment, including only the text section, is bigger than the text section and starts already at 0xF76C.
As I understood, the loadable segments gets loaded to the shown physical addresses for program execution.
So why the start address of the text segment lies within an undefined memory region?
Some of the names sections (such as .text) contain data that is actually loaded into the MCU.
The ELF program headers, however, contain only metadata; their address does not matter.

Trying to understand crash log output

I'm trying to understand debug output from a crash log. I have the following line from the crashlog:
22 FG 0x00022b94 0x1000 + 138132
I understand how to use atos on 0x00022b94 to get the source code location.
What I would like to know is why the crash log helpfully splits that number into 0x1000 + 138132? I have googled and the googles failed me.
0x1000 is where the __TEXT segment of that binary file (your app or some dylib) is mapped to, and 138132
is the (decimal) offset from that origin. This separation allows program to find the error location in a position-independent way.