system/freebsd-src
system/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src synced 2024-07-22 18:56:38 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
freebsd-src/stand/uboot/copy.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

165 lines
5.3 KiB
C
Raw Normal View History

MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
/*-
* Copyright (c) 1998 Michael Smith <msmith@freebsd.org>
* Copyright (c) 2007 Semihalf, Rafal Jaworowski <raj@semihalf.com>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
#include <sys/param.h>
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
#include <stand.h>
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
#include <stdint.h>
#include "api_public.h"
#include "glue.h"
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
#include "libuboot.h"
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
/*
* MD primitives supporting placement of module data
*/
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
#ifdef __arm__
#define KERN_ALIGN (2 * 1024 * 1024)
#else
#define KERN_ALIGN PAGE_SIZE
#endif
/*
* Avoid low memory, u-boot puts things like args and dtb blobs there.
*/
#define KERN_MINADDR max(KERN_ALIGN, (1024 * 1024))
extern void _start(void); /* ubldr entry point address. */
/*
* This is called for every object loaded (kernel, module, dtb file, etc). The
* expected return value is the next address at or after the given addr which is
* appropriate for loading the given object described by type and data. On each
* call the addr is the next address following the previously loaded object.
*
* The first call is for loading the kernel, and the addr argument will be zero,
* and we search for a big block of ram to load the kernel and modules.
*
* On subsequent calls the addr will be non-zero, and we just round it up so
* that each object begins on a page boundary.
*/
uint64_t
uboot_loadaddr(u_int type, void *data, uint64_t addr)
{
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
struct sys_info *si;
Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614
2016-01-02 18:16:24 +00:00
uint64_t sblock, eblock, subldr, eubldr;
uint64_t biggest_block, this_block;
uint64_t biggest_size, this_size;
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
int i;
Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614
2016-01-02 18:16:24 +00:00
char *envstr;
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
if (addr == 0) {
/*
* If the loader_kernaddr environment variable is set, blindly
* honor it. It had better be right. We force interpretation
* of the value in base-16 regardless of any leading 0x prefix,
* because that's the U-Boot convention.
*/
envstr = ub_env_get("loader_kernaddr");
if (envstr != NULL)
return (strtoul(envstr, NULL, 16));
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
/*
* Find addr/size of largest DRAM block. Carve our own address
* range out of the block, because loading the kernel over the
* top ourself is a poor memory-conservation strategy. Avoid
* memory at beginning of the first block of physical ram,
* since u-boot likes to pass args and data there. Assume that
* u-boot has moved itself to the very top of ram and
* optimistically assume that we won't run into it up there.
*/
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
if ((si = ub_get_sys_info()) == NULL)
panic("could not retrieve system info");
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
biggest_block = 0;
biggest_size = 0;
Go back to using uintptr_t, because code that actually compiles is infinitely less buggy than code that is theoretically correct in some alternate universe. The uintfptr_t type is apparently a freebsd invention, and exists only when compiling the kernel. It's a little hard to say for sure, since it doesn't seem to be documented anywhere except in email advice to unsuspecting and overly-trusting souls, who then get to wear the pointy hat for blindly following advice without investigating or testing it first.
2016-01-13 00:22:12 +00:00
subldr = rounddown2((uintptr_t)_start, KERN_ALIGN);
Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614
2016-01-02 18:16:24 +00:00
eubldr = roundup2((uint64_t)uboot_heap_end, KERN_ALIGN);
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
for (i = 0; i < si->mr_no; i++) {
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
if (si->mr[i].flags != MR_ATTR_DRAM)
continue;
Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614
2016-01-02 18:16:24 +00:00
sblock = roundup2((uint64_t)si->mr[i].start,
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
KERN_ALIGN);
Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614
2016-01-02 18:16:24 +00:00
eblock = rounddown2((uint64_t)si->mr[i].start +
si->mr[i].size, KERN_ALIGN);
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
if (biggest_size == 0)
sblock += KERN_MINADDR;
if (subldr >= sblock && subldr < eblock) {
if (subldr - sblock > eblock - eubldr) {
this_block = sblock;
this_size = subldr - sblock;
} else {
this_block = eubldr;
this_size = eblock - eubldr;
}
Fix bug in the ubldr introduced in the rev.283035. The new code fails to properly consider memory regions when the loader is located below of those regions or engulfs their lower limit. This results in "not enough RAM to load kernel" panic, which is totally bogus. On top of that, there are some variables that can be left unitialized in those cases, which might cause it fail with memory access violation instead of panic while trying to load kernel to a wrong or non-existing address of memory. Augment the code to properly deal with the loader being below or at the lower bound of the memory region in question. Also, don't leave ununitialized variables behind. Reviewed by: ian
2015-06-19 17:00:36 +00:00
} else if (subldr < sblock && eubldr < eblock) {
/* Loader is below or engulfs the sblock */
this_block = (eubldr < sblock) ? sblock : eubldr;
this_size = eblock - this_block;
} else {
this_block = 0;
this_size = 0;
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
}
if (biggest_size < this_size) {
biggest_block = this_block;
biggest_size = this_size;
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
}
}
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
if (biggest_size == 0)
The libstand's panic() appends its own '\n' to the message, so that users of the API don't need to supply one. MFC after: 2 weeks
2018-11-29 18:37:48 +00:00
panic("Not enough DRAM to load kernel");
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
#if 0
Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614
2016-01-02 18:16:24 +00:00
printf("Loading kernel into region 0x%08jx-0x%08jx (%ju MiB)\n",
(uintmax_t)biggest_block,
(uintmax_t)biggest_block + biggest_size - 1,
(uintmax_t)biggest_size / 1024 / 1024);
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
#endif
return (biggest_block);
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
}
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
return roundup2(addr, PAGE_SIZE);
Determine kernel load address dynamically from u-boot memory map. The generic ELF loading code maps the kernel into low memory by subtracting KERN_BASE. So the copyin/copyout/readin functions are always called with low addresses. This code finds the largest DRAM block from the U-Boot memory map and adds that base to the addresses. In particular, this fixes ubldr on AM3358, which has DRAM mapped to 0x80000000 at power-on.
2012-05-20 18:07:35 +00:00
}
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
ssize_t
uboot_copyin(const void *src, vm_offset_t dest, const size_t len)
{
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
bcopy(src, (void *)dest, len);
style(9) & style.Makefile(9) Reviewed by: raj
2008-03-13 17:54:21 +00:00
return (len);
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
}
ssize_t
uboot_copyout(const vm_offset_t src, void *dest, const size_t len)
{
An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that. Previously, ubldr would use the virtual addresses in the elf headers by masking off the high bits and assuming the result was a physical address where the kernel should be loaded. That would sometimes discard significant bits of the physical address, but the effects of that were undone by archsw copy code that would find a large block of memory and apply an offset to the source/dest copy addresses. The result was that things were loaded at a different physical address than requested by the higher code layers, but that worked because other adjustments were applied later (such as when jumping to the entry point). Very confusing, and somewhat fragile. Now the archsw copy routines are just simple copies, and instead archsw.arch_loadaddr is implemented to choose a load address. The new routine uses some of the code from the old offset-translation routine to find the largest block of ram, but it excludes ubldr itself from that range, and also excludes If ubldr splits the largest block of ram in two, the kernel is loaded into the bottom of whichever resulting block is larger. As part of eliminating ubldr itself from the ram ranges, export the heap start/end addresses in a pair of new global variables. This change means that the virtual addresses in the arm kernel elf headers now have no meaning at all, except for the entry point address. There is an implicit assumption that the entry point is in the first text page, and that the address in the the header can be turned into an offset by masking it with PAGE_MASK. In the future we can link all arm kernels at a virtual address of 0xC0000000 with no need to use any low-order part of the address to influence where in ram the kernel gets loaded.
2015-05-17 19:59:05 +00:00
bcopy((void *)src, dest, len);
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
return (len);
}
ssize_t
veloader use vectx API for kernel and modules The vectx API, computes the hash for verifying a file as it is read. This avoids the overhead of reading files twice - once to verify, then again to load. For doing an install via loader, avoiding the need to rewind large files is critical. This API is only used for modules, kernel and mdimage as these are the biggest files read by the loader. The reduction in boot time depends on how expensive the I/O is on any given platform. On a fast VM we see 6% improvement. For install via loader the first file to be verified is likely to be the kernel, so some of the prep work (finding manifest etc) done by verify_file() needs to be factored so it can be reused for vectx_open(). For missing or unrecognized fingerprint entries, we fail in vectx_open() unless verifying is disabled. Otherwise fingerprint check happens in vectx_close() and since this API is only used for files which must be verified (VE_MUST) we panic if we get an incorrect hash. Reviewed by: imp,tsoome MFC after: 1 week Sponsored by: Juniper Networks Differential Revision: https://reviews.freebsd.org//D23827
2020-03-08 17:42:42 +00:00
uboot_readin(readin_handle_t fd, vm_offset_t dest, const size_t len)
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
{
veloader use vectx API for kernel and modules The vectx API, computes the hash for verifying a file as it is read. This avoids the overhead of reading files twice - once to verify, then again to load. For doing an install via loader, avoiding the need to rewind large files is critical. This API is only used for modules, kernel and mdimage as these are the biggest files read by the loader. The reduction in boot time depends on how expensive the I/O is on any given platform. On a fast VM we see 6% improvement. For install via loader the first file to be verified is likely to be the kernel, so some of the prep work (finding manifest etc) done by verify_file() needs to be factored so it can be reused for vectx_open(). For missing or unrecognized fingerprint entries, we fail in vectx_open() unless verifying is disabled. Otherwise fingerprint check happens in vectx_close() and since this API is only used for files which must be verified (VE_MUST) we panic if we get an incorrect hash. Reviewed by: imp,tsoome MFC after: 1 week Sponsored by: Juniper Networks Differential Revision: https://reviews.freebsd.org//D23827
2020-03-08 17:42:42 +00:00
return (VECTX_READ(fd, (void *)dest, len));
MFp4 (e500): Add support for U-Boot. This uses the U-Boot API as developed by Rafal and which is (will be) part of U-Boot 1.3.2 and later. Credits to: raj@
2008-02-16 22:13:11 +00:00
}
Reference in a new issue Copy permalink