Home
last modified time | relevance | path

Searched refs:address (Results 1 – 8 of 8) sorted by relevance

/DragonStub/apps/lib/libfdt/
H A Dfdt.h32 fdt64_t address; member
H A Dfdt_rw.c155 int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size) in fdt_add_mem_rsv() argument
167 re->address = cpu_to_fdt64(address); in fdt_add_mem_rsv()
H A Dfdt_ro.c175 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size) in fdt_get_mem_rsv() argument
184 *address = fdt64_ld_(&re->address); in fdt_get_mem_rsv()
H A Dlibfdt.h454 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size);
1549 int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t size);
H A Dfdt_sw.c200 re->address = cpu_to_fdt64(addr); in fdt_add_reservemap_entry()
/DragonStub/docs/
H A DREADME.gnuefi169 a 64-bit address space (unlike ELF64, however, this is not a full
171 than 4GB of address space). EFI binaries are plain PE32+ binaries
202 address. EFI does _try_ to load a binary at it's preferred
203 address, but if it can't do so, it will load it at another
204 address and then relocate the binary using the contents of the
208 descriptor, not to the code address of the entry point.
219 In the following sections, we address how the GNU EFI build
279 o The link address (ImageBase) of the binary is (arbitrarily) set to
282 However, a start address of 0 makes debugging a wee bit easier
302 ELF binaries are normally linked for a fixed load address and are thus
[all …]
/DragonStub/
H A DChangeLog106 … These fixes are needed to address the following error and warnings when compiling the library part
811 whatever address the IDT has for #UD, but also addresses like "0x4" and
1210 The address of the structure is passed to the kernel in r28
H A DLICENSE240 address new problems or concerns.