summaryrefslogtreecommitdiffstats
path: root/sys/boot/fdt/fdt_loader_cmd.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused reg param from fdt_fixup_memorysmh2016-01-141-1/+1
| | | | | | MFC after: 2 weeks X-MFC-With: r293268 Sponsored by: Multiplay
* Fix potential NULL dereference.mav2015-02-251-2/+1
| | | | | Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com> MFC after: 2 weeks
* Do not skip setting the memory 'reg' property if the fdt data alreadyian2015-02-011-11/+0
| | | | | | contains one. Published dts source often includes a minimal default memory definition and expects it to be overridden by the bootloader after determining the actual physical memory in the system.
* loader: implement multiboot support for Xen Dom0royger2015-01-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
* Start to allow platforms other than U-Boot to use the FDT code in loader byandrew2014-11-011-137/+23
| | | | | | | | | moving U-Boot specific code from libfdt.a to a new libuboot_fdt.a. This needs to be a new library for linking to work correctly. Differential Revision: https://reviews.freebsd.org/D1054 Reviewed by: ian, rpaulo (earlier version) MFC after: 1 week
* Move the definitions of the fdt functions from a uboot header to a new fdtandrew2014-11-011-0/+1
| | | | | | | | header. There is nothing in the fdt spec that ties it to U-Boot. While here sort and fix the signature of fdt_setup_fdtp. MFC after: 1 week
* The command name is a constant, use the correct type.andrew2014-10-311-3/+3
| | | | MFC after: 1 week
* Clean up the types of a few strings to make them const when they are neverandrew2014-10-311-6/+7
| | | | written to.
* The U-Boot README says fdt_addr_r is the right env var for fdt dataian2014-10-201-3/+6
| | | | | loaded into ram, but vendors also use fdtaddr and fdt_addr. Check the recommended variable first and fall back to the others.
* "%p" formatting already includes "0x" prefix in printout.hselasky2014-05-211-2/+2
|
* Prevent fdt data loaded from a file from overwriting the kernel environment,ian2014-03-011-1/+1
| | | | | | | | | | | | by having uboot_autoload() do the fdt setup (which may load a file) rather than waiting until we're actually in the process of launching the kernel. As part of making this happen... - Define LOADER_FDT_SUPPORT on the uboot/lib compile command line when MK_FDT is set. - Make fdt_setup_fdtb() public. - Declare public fdt_whatever() functions in a header instead of using scattered extern decls in .c files.
* Add a feature for automatically finding and loading a dtb file by name.ian2014-02-221-3/+43
| | | | | | | | | | | | | | | The name is taken from the u-boot env vars fdtfile or fdt_file. If the name isn't fully-qualified a search is done in module_path locations. The search order for a usable dtb in fdt_setup_fdtp() is now - A dtb loaded with an explicit "load -t dtb" command. - A dtb already loaded into memory somehow[*] and pointed to by fdt_to_load. - A dtb in the memory pointed to by the u-boot env vars fdtaddr or fdt_addr. - A file named by the u-boot env vars fdtfile or fdt_file. - A static dtb compiled into the kernel. * Presumably by some arch-specific command or code.
* Change fdt_setup_fdtp() from "guess then fail" to more probe-like behavior.ian2014-02-221-14/+41
| | | | | | | | | | | | | | The old code basically said it was going to use some particular blob without knowing whether it could successfully do so, then it would invoke the function to do that and return its status. If it failed, you were done, even if other blobs might be available. Now the code attempts to use some particular blob and if that succeeds it says so and returns success, otherwise it moves on to try another potential blob. One specific problem this solves is when u-boot sets an fdtaddr variable to point to some memory address, then doesn't actually load a blob at that address. Now the header check will fail, and the code will move on to the fallback dtb compiled into the kernel (if any).
* Look for both fdtaddr and fdt_addr env var names. Grepping the u-bootian2014-02-221-1/+1
| | | | | | | | | | | | | source shows that board vendors seem to be about evenly split on this. This commit is a trivial change to note that while the previous change was supposed to be whitespace only, this functional change also crept in. The added lines were: /* Board vendors use both fdtaddr and fdt_addr names. Grrrr. */ if (s == NULL) s = ub_env_get("fdt_addr");
* Fix the strange 2-space indentation that appears only in this one function.ian2014-02-221-33/+36
|
* Fix the boot on FDT-enabled systems after r261819.loos2014-02-201-10/+5
| | | | | | | | While here, don't overwrite the error message on interactive use and add the missing '\n' at end of error message for the non interactive use. Tested by: ian, myself Approved by: adrian (mentor, implicit)
* Validate the header of a new dtb before using it. Remove the commentian2014-02-131-2/+7
| | | | that says that should be done.
* Initialize sym_count to 0.kientzle2013-03-301-1/+1
| | | | This fixes a compiler warning introduced in r248121.
* Attach the elf section headers to the loaded kernel as metadata, soian2013-03-101-32/+17
| | | | | | | | | | | they can easily be used by later post-processing. When searching for a compiled-in fdt blob, use the section headers to get the size and location of the .dynsym section to do a symbol search. This fixes a problem where the search could overshoot the symbol table and wander into the string table. Sometimes that was harmless and sometimes it lead to spurious panic messages about an offset bigger than the module size.
* Fix the bug I introduced in r247045.kientzle2013-02-251-28/+30
| | | | | | | | | | | | | | | | After digging through more carefully, it looks like there's no real need to have the DTB in the module directory. So we can simplify a lot: Just copy DTB into local heap for "fdt addr" and U-Boot integration, drop all the extra COPYIN() calls. I've left one final COPYIN() to update the in-kernel DTB for consistency with how this code used to work, but I'm no longer convinced it's appropriate here. I've also remove the mem_load_raw() utility that I added to boot/common/module.c with r247045 since it's no longer necessary.
* "fdt addr" gets run from loader.rc before the kernel is loaded.kientzle2013-02-231-7/+22
| | | | | | | | This was broken by r247045 which tried to copy the FDT into the module directory immediately. Instead, store the address and arrange for the FDT to get copied into the module directory later when the usual FDT initialization runs.
* Fix "fdt addr" to accept literal addresses rather than va offsets.kientzle2013-02-201-18/+40
| | | | | | | | When initializing the fdt, query U-Boot as well. With this change, it is now feasible to have U-Boot load the FDT, ubldr will pull it from U-Boot and hand it to the kernel.
* - Implement "fdt mres" sub-command that prints reserved memory regionsgonzo2012-11-301-56/+206
| | | | | | | | | | | | | | | | | | | - Add "fdt addr" subcommand that lets you specify preloaded blob address - Do not pre-initialize blob for "fdt addr" - Do not try to load dtb every time fdt subcommand is issued, do it only once - Change the way DTB is passed to kernel. With introduction of "fdt addr" actual blob address can be not virtual but physical or reside in area higher then 64Mb. ubldr should create copy of it in kernel area and pass pointer to this newly allocated buffer which is guaranteed to work in kernel after switching on MMU. - Convert memreserv FDT info to "memreserv" property of root node FDT uses /memreserve/ data to notify OS about reserved memory areas. Technically it's not real property, it's just data blob, sequence of <start, size> pairs where both start and size are 64-bit integers. It doesn't fit nicely with OF API we use in kernel, so in order to unify thing ubldr converts this data to "memreserve" property using the same format for addresses and sizes as /memory node.
* Access the device tree blob via copyin/copyout.kientzle2012-05-171-39/+64
| | | | | | | | | | | | | The code previously assumed that copyin/copyout did no address translation and that the device tree blob could be manipulated in-place (with only a few adjustments for the ELF loader offset). This isn't possible on all platforms, so the revised code uses copyout() to copy the device tree blob into a heap-allocated buffer and then updates the device tree with copyout(). This isn't ideal, since it bloats the loader memory usage, but seems the only feasible approach (short of rewriting all of the fdt manipulation routines).
* Don't hang if there is no /cpus node in the device tree.kientzle2012-05-111-0/+2
|
* Improve FDT handling in loader(8) and make it more robust.raj2012-03-221-24/+71
| | | | | | | | | | | o Fix buffer overflows when using a long property body in node paths. o Fix loop end condition when iterating through the symbol table. o Better error handling during node modification, better problem reporting. o Eliminate build time warnings. Submitted by: Lukasz Wojcik Obtained from: Semihalf MFC after: 1 week
* Improve device tree blob (DTB) handling in loader(8).raj2012-03-201-18/+107
| | | | | | | | | | Enable using the statically embedded blob from the kernel, if present. The KLD loaded DTB takes precedence, but they are both recognized and handled in the same way. Submitted by: Lukasz Wojcik Obtained from: Semihalf MFC after: 1 week
* Initial loader(8) support for Flattened Device Tree.raj2010-05-251-0/+1290
o This is disabled by default for now, and can be enabled using WITH_FDT at build time. o Tested with ARM and PowerPC. Reviewed by: imp Sponsored by: The FreeBSD Foundation
OpenPOWER on IntegriCloud