FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2014-07-07T00:27:09Z 2014-07-07T00:27:09Z Marcel Moolenaar marcel@FreeBSD.org 2014-07-07T00:27:09Z urn:sha1:e7d939bda22b07be6b68ba38835c9167212fd56e This includes: o All directories named *ia64* o All files named *ia64* o All ia64-specific code guarded by __ia64__ o All ia64-specific makefile logic o Mention of ia64 in comments and documentation This excludes: o Everything under contrib/ o Everything under crypto/ o sys/xen/interface o sys/sys/elf_common.h Discussed at: BSDcan 2011-04-03T23:49:20Z Marcel Moolenaar marcel@FreeBSD.org 2011-04-03T23:49:20Z urn:sha1:76ceb3c6eea5df0ccf978161d04d4394af7a59ba boundaries. For good measure, align all other objects to cache lines boundaries. Use the new arch_loadseg I/F to keep track of kernel text and data so that we can wire as much of it as is possible. It is the responsibility of the kernel to link critical (read IVT related) code and data at the front of the respective segment so that it's covered by TRs before the kernel has a chance to add more translations. Use a better way of determining whether we're loading a legacy kernel or not. We can't check for the presence of the PBVM page table, because we may have unloaded that kernel and loaded an older (legacy) kernel after that. Simply use the latest load address for it. 2011-03-21T18:20:53Z Marcel Moolenaar marcel@FreeBSD.org 2011-03-21T18:20:53Z urn:sha1:0355a8b24b5a7de4e76ca7805d328d26f4a85e95 services or PAL procedures. The new implementation is based on specific functions that are known to be called in certain scenarios only. This in particular fixes the PAL call to obtain information about translation registers. In general, the new implementation does not bank on virtual addresses being direct-mapped and will work when the kernel uses PBVM. When new scenarios need to be supported, new functions are added if the existing functions cannot be changed to handle the new scenario. If a single generic implementation is possible, it will become clear in due time. While here, change bootinfo to a pointer type in anticipation of future development. 2011-03-16T03:53:18Z Marcel Moolenaar marcel@FreeBSD.org 2011-03-16T03:53:18Z urn:sha1:18d9407a9f4239117fa030904e991cd5c842cbdd Add support for Pre-Boot Virtual Memory (PBVM) to the loader. PBVM allows us to link the kernel at a fixed virtual address without having to make any assumptions about the physical memory layout. On the SGI Altix 350 for example, there's no usuable physical memory below 192GB. Also, the PBVM allows us to control better where we're going to physically load the kernel and its modules so that we can make sure we load the kernel in memory that's close to the BSP. The PBVM is managed by a simple page table. The minimum size of the page table is 4KB (EFI page size) and the maximum is currently set to 1MB. A page in the PBVM is 64KB, as that's the maximum alignment one can specify in a linker script. The bottom line is that PBVM is between 64KB and 8GB in size. The loader maps the PBVM page table at a fixed virtual address and using a single translations. The PBVM itself is also mapped using a single translation for a maximum of 32MB. While here, increase the heap in the EFI loader from 512KB to 2MB and set the stage for supporting relocatable modules. 2011-03-12T02:00:28Z Marcel Moolenaar marcel@FreeBSD.org 2011-03-12T02:00:28Z urn:sha1:7bd6af277deb67a802884e58c52840e3885d87a3 o The bootinfo structure is now a virtual pointer. o Replace VM_MAX_ADDRESS with VM_MAXUSER_ADDRESS and redefine VM_MAX_ADDRESS as the maximum address possible (~0UL). o Since we're not using direct-mapped translations, switching to physical addressing is less trivial. Reserve the boot stack for running in physical mode and special-case the EFI call, as we're still on the boot stack. o Region 4 belongs to the kernel now, not process space. 2011-03-11T21:54:45Z Marcel Moolenaar marcel@FreeBSD.org 2011-03-11T21:54:45Z urn:sha1:9706a84ba064bee7dfd8df02dc676291c7a41a74 2005-01-06T22:18:23Z Warner Losh imp@FreeBSD.org 2005-01-06T22:18:23Z urn:sha1:86cb007f9f53a618310e56ff967339221197b416 2004-11-28T04:34:17Z Marcel Moolenaar marcel@FreeBSD.org 2004-11-28T04:34:17Z urn:sha1:c0678028d7d7e83f7033d390d6fc65f3f6ca8b84 o Remove a bogus comment that relates to alpha. o s/u_int64_t/uint64_t/g o Add bi_spare2 to make the internal padding explicit. o Move BOOTINFO_MAGIC after the field it applies to. 2002-12-08T20:32:56Z Marcel Moolenaar marcel@FreeBSD.org 2002-12-08T20:32:56Z urn:sha1:7b54e1ca532f3f2d06c7cab5d60b1ba024b7810b The HCDP table is one (non-proprietary) way for the platform to inform the OS about headless operation. This field would normally hold the address as can be found by scanning the EFI system table, which we also pass to the kernel. The apparent duplication allows us to synthesize a HCDP table in the loader by whatever means we can think of, including relocating the platform table into pre- mapped address space. In short: it gives us more freedom. Approved by: re (blanket) 2001-11-19T07:07:09Z Peter Wemm peter@FreeBSD.org 2001-11-19T07:07:09Z urn:sha1:1ccc5e6c4e240631692253c518e93a5bf32b67a4 Interface provided by EFI (Floating Point SoftWare Assist).