summaryrefslogtreecommitdiff
path: root/src/arch
AgeCommit message (Collapse)Author
2013-07-11Unify PCI configuration cyclesKyösti Mälkki
Split PCI IO configuration and MMIO configuration cycles to separate files. Modern hardware does not use IO cycles for PCI configuration after initial setup in bootblock. Note that the pci_mmio_ and pcie_ functions were different in masking the alignment for register address. PCI standard requires that 16-bit and 32-bit configuration register writes do not cross boundaries. Change-Id: Ie6441283e1a033b4b395e972c18c31277f973897 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3554 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-11Set PCI bus operations at buildtime for ramstageKyösti Mälkki
PCI bus operations are static through the ramstage, and should be initialized from the very beginning. For all the replaced instances, there is no MMCONF_SUPPORT nor MMCONF_SUPPORT_DEFAULT selected for the northbridge, so these continue to use PCI IO config access. Change-Id: I658abd4a02aa70ad4c9273568eb5560c6e572fb1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3607 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10usbdebug: Move ehci_debug_info allocationKyösti Mälkki
Move ehci_debug_info allocation from console to lib, as console code was only built for ramstage. Implement dbgp_ehci_info() to return the EHCI context. Alread alias this as dbgp_console_input() and _output() to return the console stream context later on. Change-Id: Id6cc07d62953f0466df61eeb159e22b0e3287d4e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3625 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Don't try to use CBMEM console in bootblockStefan Reinauer
Otherwise we have to worry about hand off between bootblock and romstage. Too much complexity Change-Id: I89bf8a229dba7e1330accadf9a732d831ebc4827 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3694 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: Drop duplicate call to bootblock_cpu_init()Stefan Reinauer
This is already called in ARMv7 bootblock_simple.c so we don't want to do it twice Change-Id: I80cb41035b8a77787e04f2ea58a1cd372cea97d8 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3692 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Don't leave alignment checking on after the exception test.Gabe Black
Currently, the exception handling code on ARM turns on alignment checks as an easy way to generate an exception for testing purposes. It was leaving it on which disabled unaligned accesses for other, unlreated code running later. This change adjusts the code so the original value of the alignment bit is restored after the test exception. Change-Id: Id8d035a05175f9fb13de547ab4aa5496d681d30c Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3690 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10arm: Fix memory barrier usage in IO operationHung-Te Lin
The dmb should be executed before reading operations, and before/after writing operations. Change-Id: I572136a2f9a07eb2c38a112f5deeb2de0c0fd46c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3682 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10armv7a: Enable native memcpy / memsetStefan Reinauer
The code has been there for quite a while but was never enabled. Change-Id: I4ec3dcbb3c03805ac5c75872614e5d394df667cf Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3675 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Tell the linker memset and memcpy are functions.Gabe Black
The memset and memcpy functions are assembled as ARM code, likely because that's the default of the assembler. Without special annotation, the assembler and linker don't know that those symbols are functions which need special handling so that ARM/thumb issues are handled properly. This change adds that annotation which gets those functions working in Coreboot which is compiled as thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the annotation since it just works out in ARM mode, but it's the safe thing to do in case we change that in the future. We should explicitly select ARM vs. thumb when assembling assembly files to be consistent across builds and toolchains. Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3672 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Separate the early console (romstage) from the bootblock console.Gabe Black
It might be that you want an early console in romstage before RAM is up, but you can't or don't want to support the console all the way back in the bootblock. By making the console in those two different environments configurable seperately that becomes possible. On the 5250 console output as early as the bootblock works, but on the 5420 it only starts working in the ROM stage after clocks have been initialized. Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3671 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10arch: clean up Kconfig and MakefileStefan Reinauer
remove some unused code Change-Id: I41602fb391c1910c588a4f9dcc7c2edefe8ab5bc Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3669 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10armv7: Reserve space BL1 and checksum header by specifying bootblock offset.Hung-Te Lin
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be different (ex, Exynos 5250 may use a new BL1 with variable length checksum header). To support that better, define the real base address (and ROM offset) of boot block, and then we can post-processing ROM image file by filling data / checksum and any other information. Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3664 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10cpu: Add CPU microcode file to cbfs with 16-byte alignmentAaron Durbin
On x86 there is a 16-byte alignment requirement for the addresses containing the CPU microcode. The cbfs files containing the microcode are used in memory-mapped fashion when loading new mircocode. Therefore, the data payload's address/offset of a cbfs file in flash dictates the resulting alignment. Fix this by processing the CPU microcode cbfs file separately as it uses $(CBFSTOOL) to find the proper location within the provided rom image. Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3663 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Drop ELF remains from boot codeStefan Reinauer
This stuff is not used, so let's drop it. Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3660 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: flatten arch/armv7 source treeStefan Reinauer
With only 19 source files it doesn't make a whole lot of sense to create sub directories in arch/armv7, especially since the files were distributed somewhat randomly. Change-Id: I029c7848e915edf1737e1c401c034837c95d179d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3659 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Fix up page table/cachability management.Gabe Black
When modifying the page tables, use writel to ensure the writes happen, flush the page tables themselves to ensure they're visible to the MMU if it doesn't look at the caches, and invalidate the right TLB entries. The first two changes are probably safer but may not be strictly necessary. The third change is necessary because we were invalidating the TLB using i which was in megabytes but using an instruction that expects an address in bytes. One symptom of this problem was that the framebuffer, which was supposed to be marked uncacheable, was only being partially updated since some of the updates were still in the cache. With this change the graphics show up correctly. Change-Id: I5475df29690371459b0d37a304eebc62f81dd76b Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3653 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10arch: Fix spellingMartin Roth
Change-Id: Ifea10f0180c0c4b684030a168402a95fadf1a9db Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3727 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Fix the way the space for the page tables is allocated.Gabe Black
The page tables need to be aligned to a 16KB boundary and are 16KB in size. The CBMEM allocator only guarantees 512 byte alignment, so to make sure things are where they're supposed to be, the code was allocating extra space and then adjusting the pointer upwards. Unfortunately, it was adding the size of the table to the pointer first, then aligning it. Since it allocated twice the space of the table, this had the effect of moving past the first table size region of bytes, and then aligning upwards, pushing the end of the table out of the space allocated for it. You can get away with this if you push things you don't care about off the end, and it happened to be the case that we were allocating a color map we weren't using at the start of the next part of cbmem. Change-Id: I6b196fc573801b02f27f2e667acbf06163266651 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3651 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: Clean up console codeStefan Reinauer
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock - Don't initialize console twice in the bootblock - remove printk in memory init that would mess up the UART - unconditionally run console_init() in romstage, as it is also unconditionally run in the bootblock. Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3647 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: De-uboot-ify Exynos5250 codeStefan Reinauer
When starting the Exynos5250 port, a lot of unneeded u-boot code was imported. This is an attempt to get rid of a lot of unneeded code before the port is used as a basis for further ARM ports. There is a lot more that can be done, including cleaning up the 5250's Kconfig file. Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3642 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Wield battle axe at ARM portStefan Reinauer
This patch unfortunately incorporates a number of changes, all of which are making future ARM ports easier. - drop cruft that came in with u-boot - move serial console from mainboard Kconfig to Exynos Kconfig - factor out non-board specific wakeup code - move generic bootblock code from mainboard to Exynos - actually call arch_cpu_init() - remove dead code - fix up copyright messages - remove snow_ prefix from a lot of code to reduce the noise when creating a new mainboard based on that code. Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3640 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Drop some duplicates of PCI-e config functionsKyösti Mälkki
These are not specific to Intel. Further work needs to be done to combine these with MMCONF_SUPPORT in arch/io.h. Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3502 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Fix MMCONF_SUPPORT_DEFAULT for ramstageKyösti Mälkki
Define at one place whether to use IO 0xcf8/0xcfc or MMIO via MMCONF_BASE_ADDRESS for PCI configuration access funtions in ramstage. The implementation of pci_default_config() always returned with pci_cf8_conf1. This means any PCI configuration access that did not target bus 0 used PCI IO config operations, if PCI MMIO config was not explicitly requested. Change-Id: I3b04f570fe88d022cd60dde8bb98e76bd00fe612 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3606 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-06-10ARM: Put the ROM stage into the image before other bits.Gabe Black
On ARM, there's frequently some firmware built into the SOC which runs first and which loads other firmware like Coreboot from some other media. To prevent the bootblock from having to know how to find and load the ROM stage from what may be a complicated source (sd card, netbooting, etc.), we can put the ROM stage immediately after the bootblock and ensure that they're both loaded at the same time. This change adjusts the Makefile.inc for ARM so that the ROM stage is put into the image before any other files so that we know it comes first. This changes the behavior of the CONFIG_UPDATE_IMAGE config option used by abuild, although it's not entirely clear whether that's still used. Change-Id: I832386243788156db5f5abbc9760a4e2026cf2cd Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3420 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2013-06-06qemu: add x86 cpuGerd Hoffmann
This patch adds a qemu x86 cpu chip. It has no initialization function as this isn't needed on virtual hardware. A virtual machine can have pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu -cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu which is (almost) identical to the one on the host machine. So I've added X86_VENDOR_ANY as wildcard match for the cpu_table. Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-on: http://review.coreboot.org/3344 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-04Move the MARK_GRAPHICS_MEM_WRCOMB to x86 architectureRonald G. Minnich
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer since it was defined in sandybridge. It is really more of an x86 thing however, and we now have three systems that can use it. I considered making this more general, since it technically can apply to PTE-based systems like ARM, and maybe we should. But the 'WRCOMB' moniker is usually closely tied to the x86. Change-Id: I3eb6eb2113843643348a5e18e78c53d113899ff8 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3349 Tested-by: build bot (Jenkins)
2013-06-02Provide sane Kconfig default for cmos.default.Denis 'GNUtoo' Carikli
Without that fix we have with CONFIG_USE_OPTION_TABLE: OPTION cmos_layout.bin build/util/nvramtool/nvramtool -y /home/gnutoo/x86/coreboot-alix/src/mainboard/pcengines/alix1c/cmos.layout -L build/cmos_layout.bin make: *** No rule to make target `nvramtool', needed by `build/coreboot.pre1'. Stop. rm build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c That log was captured with make V=1 but the error also appear with make. Tested on the PC Engines ALIX.1C with the following commit (Change-Id: Ia87b090) [1]: PC Engines ALIX.1C: Add CMOS defaults. [1] http://review.coreboot.org/#/c/3323/ Change-Id: I548005a58f430ed7b6da5249a24bbdcae440a1e9 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3223 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2013-05-20Drop llshellStefan Reinauer
This feature has not been used and was never fully integrated. In the progress of cleaning up coreboot, let's drop it. Change-Id: Ib40acdba30aef00a4a162f2b1009bf8b7db58bbb Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3251 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-16x86: add cache-as-ram migration optionAaron Durbin
There are some boards that do a significant amount of work after cache-as-ram is torn down but before ramstage is loaded. For example, using vboot to verify the ramstage is one such operation. However, there are pieces of code that are executed that reference global variables that are linked in the cache-as-ram region. If those variables are referenced after cache-as-ram is torn down then the values observed will most likely be incorrect. Therefore provide a Kconfig option to select cache-as-ram migration to memory using cbmem. This option is named CAR_MIGRATION. When enabled, the address of cache-as-ram variables may be obtained dynamically. Additionally, when cache-as-ram migration occurs the cache-as-ram data region for global variables is copied into cbmem. There are also automatic callbacks for other modules to perform their own migration, if necessary. Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3232 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-14x86: add thread supportAaron Durbin
Thread support is added for the x86 architecture. Both the local apic and the tsc udelay() functions have a call to thread_yield_microseconds() so as to provide an opportunity to run pending threads. Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3207 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-14coreboot: add thread cooperative multitaskingAaron Durbin
The cooperative multitasking support allows the boot state machine to be ran cooperatively with other threads of work. The main thread still continues to run the boot state machine (src/lib/hardwaremain.c). All callbacks from the state machine are still ran synchronously from within the main thread's context. Without any other code added the only change to the boot sequence when cooperative multitasking is enabled is the queueing of an idlle thread. The idle thread is responsible for ensuring progress is made by calling timer callbacks. The main thread can yield to any other threads in the system. That means that anyone that spins up a thread must ensure no shared resources are used from 2 or more execution contexts. The support is originally intentioned to allow for long work itesm with busy loops to occur in parallel during a boot. Note that the intention on when to yield a thread will be on calls to udelay(). Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3206 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-10Drop prototype guarding for romccStefan Reinauer
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1] made romcc not choke on function prototypes anymore. This allows us to get rid of a lot of ifdefs guarding __ROMCC__ . [1] http://review.coreboot.org/2424 Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3216 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-08Drop CONFIG_AP_CODE_IN_CARStefan Reinauer
This option has not been enabled on any board and was considered obsolete last time it was touched. If we need the functionality, let's fix this in a generic way instead of a K8 specific way. This was mostly a speedup hack back in the day. Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3211 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-08copy_and_run: drop boot_complete parameterStefan Reinauer
Since this parameter is not used anymore, drop it from all calls to copy_and_run() Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3213 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-08hardwaremain: drop boot_complete parameterStefan Reinauer
it has been unused since 9 years or so, hence drop it. Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3212 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-07x86 I/O APIC: Dump I/O APIC regs in `ioapic.c`Paul Menzel
Some southbridges have code in their `lpc.c` files to dump the I/O APIC registers. printk(BIOS_SPEW, "Dumping IOAPIC registers\n"); for (i=0; i<3; i++) { *ioapic_index = i; printk(BIOS_SPEW, " reg 0x%04x:", i); reg32 = *ioapic_data; printk(BIOS_SPEW, " 0x%08x\n", reg32); } Add similar code to `src/arch/x86/lib/ioapic.c` so all boards using the function `set_ioapic_id()` get the debug feature and the other boards can be more easily adapted in follow-up patches. Change-Id: Ic59c4c2213ed97bdf3798b3dc6e7cecc30e135d8 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3184 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-05-07x86 I/O APIC: Make functions `io_apic_{read,write}()` publicPaul Menzel
Some LPC initialiation can save some lines of code when being able to use the functions `io_apic_read()` and `io_apic_write()`. As these two functions are now public, remove them from the generic driver as otherwise we get a build errors like the following. […] Building roda/rk9; i386: ok, using i386-elf-gcc Using payload /srv/jenkins/payloads/seabios/bios.bin.elf Creating config file... (blobs, ccache) ok; Compiling image on 4 cpus in parallel .. FAILED after 12s! Log excerpt: coreboot-builds/roda_rk9/arch/x86/lib/ramstage.o: In function `io_apic_write': /srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/arch/x86/lib/ioapic.c:32: multiple definition of `io_apic_write' coreboot-builds/roda_rk9/drivers/generic/ioapic/ramstage.o:/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/drivers/generic/ioapic/ioapic.c:22: first defined here collect2: error: ld returned 1 exit status make: *** [coreboot-builds/roda_rk9/generated/coreboot_ram.o] Error 1 make: *** Waiting for unfinished jobs.... […] Change-Id: Id600007573ff011576967339cc66e6c883a2ed5a Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3180 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-05-01armv7: invalidate TLB entries as they are added/modifiedDavid Hendricks
The old approach was to invalidate the entire TLB every time we set up a table entry. This worked because we didn't turn the MMU on until after we had set everything up. This patch uses the TLBIMVAA wrapper to invalidate each entry as it's added/modified. Change-Id: I27654a543a2015574d910e15d48b3d3845fdb6d1 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3166 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-01ARMV7: add a function to disable MMU entriesRonald G. Minnich
It is useful to be able to lock out certain address ranges, NULL being the most important example. void mmu_disable_range(unsigned long start_mb, unsigned long size_mb) will allow us to lock out selected virtual addresses on MiB boundaries. As in other ARM mmu functions, the addresses and quantities are in units of MiB. Change-Id: If516ce955ee2d12c5a409f25acbb5a4b424f699b Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3160 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-05-01armv7: add wrapper for tlbimvaaDavid Hendricks
This adds an inline wrapper for the TLBIMVAA instruction (invalidate unified TLB by MVA, all address space identifiers). Change-Id: Ibcd289ecedaba8586ade26e36c177ff1fcaf91d3 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3161 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-01x86: use boot state callbacks to disable rom cacheAaron Durbin
On x86 systems there is a concept of cachings the ROM. However, the typical policy is that the boot cpu is the only one with it enabled. In order to ensure the MTRRs are the same across cores the rom cache needs to be disabled prior to OS resume or boot handoff. Therefore, utilize the boot state callbacks to schedule the disabling of the ROM cache at the ramstage exit points. Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3138 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coverage: use boot state callbacksAaron Durbin
Utilize the static boot state callback scheduling to initialize and tear down the coverage infrastructure at the appropriate points. The coverage initialization is performed at BS_PRE_DEVICE which is the earliest point a callback can be called. The tear down occurs at the 2 exit points of ramstage: OS resume and payload boot. Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3135 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01acpi: split resume check and actual resume codeAaron Durbin
It's helpful to provide a distinct state that affirmatively describes that OS resume will occur. The previous code included the check and the actual resuming in one function. Because of this grouping one had to annotate the innards of the ACPI resume path to perform specific actions before OS resume. By providing a distinct state in the boot state machine the necessary actions can be scheduled accordingly without modifying the ACPI code. Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3134 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: schedule static callbacksAaron Durbin
Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-26armv7: invoke intermediate build rulesDavid Hendricks
This adds $$(INTERMEDIATE) as a pre-requisite for coreboot.rom on armv7. It is modeled after the $(obj)/coreboot.rom rule for x86. Change-Id: I483a88035fa2288829b6e042e51ef932c8c4f23c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2095 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-18spkmodem consoleVladimir Serbinenko
Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/2987 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-17armv7/exynos5250: Deprecate sdelay in favor of udelayDavid Hendricks
This gets rid of the clock-tick based sdelay in favor of udelay(). udelay() is more consistent and easier to work with, and this allows us to carry one less variation of timers (and headers and sources...). Every 1 unit in the sdelay() argument was assumed to cause a delay of 2 clock ticks (@1.7GHz). So the conversion factor is roughly: sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6) = udelay((N * 2) / (1.7 * 10^3)) The sdelay() periods used were: sdelay(100) --> udelay(1) sdelay(0x10000) --> udelay(78) (rounded up to udelay(100)) There was one instance of sdelay(10000), which looked like sort of a typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should approximate to about 12us, so we'll stick with that for now and leave a note. Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3079 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-13Exynos5250: add a microsecond timerRonald G. Minnich
Add a microsecond timer, its declaration, the function to start it, and its usage. To start it, one calls timer_start(). From that point on, one can call timer_us() to find microseconds since the timer was started. We show its use in the bootblock. You want it started very early. Finally, the delay.h change having been (ironically) delayed, we create time.h and have it hold one declaration, for the timer_us() and timer_start() prototype. We feel that these two functions should become the hardware specific functions, allowing us to finally move udelay() into src/lib where it belongs. Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3073 Tested-by: build bot (Jenkins)
2013-04-11ARM: Unmask aborts very early in the bootblock.Gabe Black
It's better to recognize aborts when they occur than to mask them to discover them later without knowing where they actually came from. Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3065 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-10armv7: replace read/write macros with inlinesDavid Hendricks
This enables type checking for safety as to help prevent errors like http://review.coreboot.org/#/c/3038/ . Now compilation fails if the wrong type is passed into readb/readw/readl/writeb/writew/writel or other macros in io.h. This also deprecates readw/writew. The previous definition was 16-bits which is incorrect since wordsize on ARMv7 is 32-bits and there was only 1 instance of writew (#if 0'd anyway). Going forward we should always use read{8,16,32} and write{8,16,32} where N specifies the exact length rather than relying on ambiguous definition of wordsize. Since many macros relied on __raw_*, which were basically the same (minus data memory barrier instructions), this patch also gets rid of __raw_*. There were parts of the code which ended up using these macros consecutively, for example: setbits_le32(&regs->ch_cfg, SPI_CH_RST); clrbits_le32(&regs->ch_cfg, SPI_CH_RST); In such cases the safe versions of readl() and writel() should be used anyway. Note: This also fixes two dubious casts as to avoid breaking compilation. Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3045 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08armv7: specify condition code for msr instructionDavid Hendricks
This adds condition codes when using the msr instruction. Although described as "optional" in the Cortex-A series programmer's guide, our experience with using the msr instruction in the payload suggests that the condition code is not optional and that this only worked in coreboot (and u-boot) because the processor comes up in SVC32 mode. (credit to Gabe Black for finding this, I'm only uploading the patch) Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I0aa4715ae415e1ccc5719b7b55adcd527cc1597b Reviewed-on: http://review.coreboot.org/3037 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-03Add PXE ROM selection to Kconfig menuSiyuan Wang
Adding a pxe rom manually is inconvenient. With this patch, PXE ROM can be added automatically by selecting PXE_ROM in Kconfig. I have tested this patch on AMD Parmer and Thatcher with iPXE. iPXE would be a boot device in Seabios when pressing F12. iPXE works well with coreboot and Seabios. Change-Id: I2c4fc73fd9ae6c979f0af2290d410935f600e2c8 Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3013 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01lynxpoint: Move ACPI NVS into separate CBMEM tableDuncan Laurie
The ACPI NVS region was setup in place and there was a CBMEM table that pointed to it. In order to be able to use NVS earlier the CBMEM region is allocated for NVS itself during the LPC device init and the ACPI tables point to it in CBMEM. The current cbmem region is renamed to ACPI_GNVS_PTR to indicate that it is really a pointer to the GNVS and does not actually contain the GNVS. Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2970 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01boot: add disable_cache_rom() functionAaron Durbin
On certain architectures such as x86 the bootstrap processor does most of the work. When CACHE_ROM is employed it's appropriate to ensure that the caching enablement of the ROM is disabled so that the caching settings are symmetric before booting the payload or OS. Tested this on an x86 machine that turned on ROM caching. Linux did not complain about asymmetric MTRR settings nor did the ROM show up as cached in the MTRR settings. Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-30x86: Drop BOARD_HAS_FADTKyösti Mälkki
There is a wildcard rule to include mainboard/fadt.c. Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2940 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-30armv7: change some unsigned ints to uint32_tDavid Hendricks
Use register-sized types in case the inline assembler doesn't do so automatically. Change-Id: I3202ba972ef2548323fe557f45dc4b0b1cf6c818 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2983 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: remove loop from dcache_mmu_disable()David Hendricks
dcache_mmu_disable() no longer needs to have its own iterative loop to select each cache level of cache since dcache_clean_invalidate_all() does that now. Change-Id: I5ca273f98943981b943c1c1622f4574d7133fb50 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2967 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: update sync barrier usage in dcache_op_set_way()David Hendricks
This moves the dsb() before the loop to sync any outstanding memory accesses, and adds an isb() after the loop to ensure all outstanding instructions are completed. Change-Id: I1a11b39f104ae780370cfd2db3badcf4e91dc017 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2929 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29armv7: set cache level explicitly for dcache/unified cache caseDavid Hendricks
This adds a missing CSSELR write in the case of a dcache or unified cache being invalidated by armv7_invalidate_caches(), ensuring that all levels of dcache/unified cache are invalidated as expected when the function is called. Change-Id: Ie90184bf8a8181afa3afe0786897455b30b7f022 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2947 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: invalidate TLB after changing translation table entriesDavid Hendricks
This adds a call to tlb_invalidate_all() after configuring a range of memory. Change-Id: I558402e7e54b6bf9e0b013f153d9b84c0873a6cf Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2946 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: iterate thru all levels when doing dcache opsDavid Hendricks
This makes dcache maintenance functions operate on all levels of cache instead of just the current one. Change-Id: I2708fc7ba6da6740dbdfd733d937e7c943012d62 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2945 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: add functions for reading/writing L2CTLRDavid Hendricks
This adds simple accessor functions for reading/writing L2CTLR. Change-Id: I2768d00d5bb2c43e84741ccead81e529dac9254d Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2948 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29armv7: use stdint.h in cache and MMU filesDavid Hendricks
This makes it easier to copy + paste code into libpayload since libpayload since both coreboot and libpayload have stdint.h and it defines the types needed. Change-Id: Ifa55f04a9bdddd17bc1a2679321a6744c75f25a8 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2944 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29armv7: added paranoia for cache libraryDavid Hendricks
This adds some paranoia to cache manipulation routines: - "memory" is added to the clobber list for functions which clean and/or invalidate dcache or TLB entries. - Remove unneeded clobber list for read_sctlr() Change-Id: Iaa82ef78bfdad4119f097c3b6db8219f29f832bc Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2928 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-28armv7: clean+invalidate all cache levels when disabling MMUDavid Hendricks
This iterates thru all cache levels and cleans + invalidates all data and unified caches before disabling dcache and MMU. Change-Id: I8a671b4c90d7b88b8d0a95947bfa17f912cebaa2 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2930 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-28armv7: cosmetic changes to dcache_op_mva()David Hendricks
This is just a cosmetic change to dcache_op_mva() to (hopefully) make it a easier to follow and more difficult to screw up. Change-Id: Ia348b2d58f2f2bf5c3cafabcfba06bc411937dba Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2927 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-28armv7: fix a bad variable assignmentDavid Hendricks
'<' was used when '<<' is needed. Oops! Change-Id: I8451f76888e86219df16b50739cd2c8db80dcb14 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2941 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-28armv7: pass incremented value to dccimvacDavid Hendricks
This passes the correct value into dccimvac. Change-Id: I6098440ea48a9b6429380d5913fce6d36e3afb41 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2926 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-26armv7: fixes for dcache_op_by_mva()David Hendricks
This fixes a couple issues with dcache_op_by_mva(): - Add missing data and instruction sync barriers. - Removes unneded -1 from loop terminating condition. Change-Id: I098388614397c1e53079c017d56b1cf3ef273676 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2913 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26ARMv7: Drop ROMSTAGE_BASE from Makefile.incStefan Reinauer
It's not used (instead ARM puts it in Kconfig) Change-Id: Ia22a7ac756bec4cb6fee00a4d946a020ea6290aa Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2916 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-03-26x86: dynamic cbmem: fix acpi reservationsAaron Durbin
If a configuration was not using RELOCTABLE_RAMSTAGE, but it was using HAVE_ACPI_RESUME then the ACPI memory was not being marked as reserved to the OS. The reason is that memory is marked as reserved during write_coreboot_table(). These reservations were being added to cbmem after the call to write_coreboot_table(). In the non-dynamic cbmem case this sequence is fine because cbmem area is a fixed size and is already reserved. For the dynamic cbmem case that no longer holds by the nature of the dynamic cbmem. Change-Id: I9aa44205205bfef75a9e7d9f02cf5c93d7c457b2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2897 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-26ARMv7: Drop XIP relocation code for romstageStefan Reinauer
It was never used, because we pushed romstage_null into the CBFS instead of romstage_xip. It's not surprising this worked, but it was a crude hack. Get rid of all the intermediate objects that are not needed. This could probably be further simplified to use the default cbfs mechanism in our build system instead of having a specific rule for romstage, but that's for another day. Change-Id: I492ca2015ec81e13499fcd8dd331371f46a31c78 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2912 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-26armv7: add new dcache and MMU setup functionsDavid Hendricks
This adds new MMU setup code. Most notably, this version uses cbmem_add() to determine the translation table base address, which in turn is necessary to ensure payloads which wipe memory can tell which regions to wipe out. TODOs: - Finish cleaning up references to old cache/MMU stuff - Add L2 setup (from exynos_cache.c) - Set up ranges dynamically rather than in ramstage's main(). Change-Id: Iba5295a801e8058a3694e4ec5b94bbe9a69d3ee6 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2877 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-23x86: mark .textfirst as allocatable and executableAaron Durbin
When the linking of ramstage was changed to use an intermeidate object with all ramstage objects in it the .textfirst section was introduced to keep the entry point at 0. However, the section was not marked allocatable or executable. Nor was it marked as @progbits. That didn't cause an issue on its own since .textfirst was directly called out in the linker script. However, the rmodule infrastructure relies on all the relocation entries being included in the rmodule. Without the proper section attributes the .rel.textfirst section entries were not being included in the final ramstage rmodule. Change-Id: I54e7055a19bee6c86e269eba047d9a560702afde Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2885 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23relocatable ramstage: fix linkingAaron Durbin
The ramstage is now linked using an intermediate object that is created from the complete list of ramstage object files. The rmodule code was developed when ramstage was linked using an archive file. Because of the fact that the rmodule headers are not referenced from any other object the link could start by specifying the rmodule header object for ramstage. That, however, is not the case as all ramstage objects are included in the intermediate linked object. Therefore, the ramstage_module_header.ramstage.o object file needs to be removed from the object list for the ramstage rmodule. Change-Id: I6a79b6f8dd1dbfe40fdc7753297243c3c9b45fae Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2884 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23x86: expose console_tx_flush in romstageAaron Durbin
The vboot module relied on being able to flush the console after it called vtxprintf() from its log wrapper function. Expose the console_tx_flush() function in romstage so the vboot module can ensure messages are flushed. Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2882 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22Unify coreboot table generationStefan Reinauer
coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-22coreboot: add vboot_handoff to coreboot tablesAaron Durbin
The vboot_handoff structure contians the VbInitParams as well as the shared vboot data. In order for the boot loader to find it, the structure address and size needs to be obtained from the coreboot tables. Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2857 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22romstage: add support for vboot firmware selectionAaron Durbin
This patch implements support for vboot firmware selection. The vboot support is comprised of the following pieces: 1. vboot_loader.c - this file contains the entry point, vboot_verify_firmware(), for romstage to call in order to perform vboot selection. The loader sets up all the data for the wrapper to use. 2. vboot_wrapper.c - this file contains the implementation calling the vboot API. It calls VbInit() and VbSelectFirmware() with the data supplied by the loader. The vboot wrapper is compiled and linked as an rmodule and placed in cbfs as 'fallback/vboot'. It's loaded into memory and relocated just like the way ramstage would be. After being loaded the loader calls into wrapper. When the wrapper sees that a given piece of firmware has been selected it parses firmware component information for a predetermined number of components. Vboot result information is passed to downstream users by way of the vboot_handoff structure. This structure lives in cbmem and contains the shared data, selected firmware, VbInitParams, and parsed firwmare components. During ramstage there are only 2 changes: 1. Copy the shared vboot data from vboot_handoff to the chromeos acpi table. 2. If a firmware selection was made in romstage the boot loader component is used for the payload. Noteable Information: - no vboot path for S3. - assumes that all RW firmware contains a book keeping header for the components that comprise the signed firmware area. - As sanity check there is a limit to the number of firmware components contained in a signed firmware area. That's so that an errant value doesn't cause the size calculation to erroneously read memory it shouldn't. - RO normal path isn't supported. It's assumed that firmware will always load the verified RW on all boots but recovery. - If vboot requests memory to be cleared it is assumed that the boot loader will take care of that by looking at the out flags in VbInitParams. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2854 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: Unify arch/io.h and arch/romcc_io.hStefan Reinauer
Here's the great news: From now on you don't have to worry about hitting the right io.h include anymore. Just forget about romcc_io.h and use io.h instead. This cleanup has a number of advantages, like you don't have to guard device/ includes for SMM and pre RAM anymore. This allows to get rid of a number of ifdefs and will generally make the code more readable and understandable. Potentially in the future some of the code in the io.h __PRE_RAM__ path should move to device.h or other device/ includes instead, but that's another incremental change. Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2872 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21cbmem: dynamic cbmem supportAaron Durbin
This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21rmodule: add string functions to rmodules classAaron Durbin
The standard string functions memcmp(), memset(), and memcpy() are needed by most programs. The rmodules class provides a way to build objects for the rmodules class. Those programs most likely need the string functions. Therefore provide those standard functions to be used by any generic rmodule program. Change-Id: I2737633f03894d54229c7fa7250c818bf78ee4b7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2821 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-21coreboot: introduce romstage_handoff structureAaron Durbin
The romstage_handoff structure is intended to be a way for romstage and ramstage to communicate with one another instead of using sideband signals such as stuffing magic values in pci config or memory scratch space. Initially this structure just contains a single region that indicates to ramstage that it should reserve a memory region used by the romstage. Ramstage looks for a romstage_handoff structure in cbmem with an id of CBMEM_ID_ROMSTAGE_INFO. If found, it will honor reserving the region defined in the romstage_handoff structure. Change-Id: I9274ea5124e9bd6584f6977d8280b7e9292251f0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2791 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: prepare for relocationAaron Durbin
The current ramstage code contains uses of symbols that cause issues when the ramstage is relocatable. There are 2 scenarios resolved by this patch: 1. Absolute symbols that are actually sizes/limits. The symbols are problematic when relocating a program because there is no way to distinguish a symbol that shouldn't be relocated and one that can. The only way to handle these symbols is to write a program to post process the relocations and keep a whitelist of ones that shouldn't be relocated. I don't believe that is a route that should be taken so fix the users of these sizes/limits encoded as absolute symbols to calculate the size at runtime or dereference a variable in memory containing the size/limit. 2. Absoulte symbols that were relocated to a fixed address. These absolute symbols are generated by assembly files to be placed at a fixed location. Again, these symbols are problematic because one can't distinguish a symbol that can't be relocated. The symbols are again resolved at runtime to allow for proper relocation. For the symbols defining a size either use 2 symbols and calculate the difference or provide a variable in memory containing the size. Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2789 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-21armv7: add function for dcache_clean_by_mva()David Hendricks
This adds a function for using the DCCMVAC instruction (dcache clean by MVA at point of coherency (main memory)). We already have the inline defined, it's just not used by anything. Change-Id: Ia0641566a8881335bed8da2963e1db8321d74267 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2871 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: add a helper function for dcache ops by MVADavid Hendricks
This adds a helper function for dcache ops by MVA which will perform the specified operation on a given memory range. This will make it more trivial to add other data cache maintenance routines. Change-Id: I01d746d5fd2f4138257ca9cab9e9d738e73f8633 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2870 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: cosmetic changes to new cache codeDavid Hendricks
This clarifies and/or fixes formatting of some comments and alphabetizes some function prototypes and inlines. It also corrects references to "modified virtual address" (MVA). Change-Id: Ibcdda4febf915cc4a1996a5bbb4ffecbcb50a324 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2869 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: remove old isb() and dsb() macrosDavid Hendricks
This removes some old macros that we no longer use. Change-Id: I9d87beb5c2deca228cdf89a98e54b2779be0f0ea Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2868 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: move armv7_invalidate_caches() to cache.cDavid Hendricks
This just moves cache maintenance stuff from the armv7 bootblock code to cache.c Change-Id: I0b3ab58a1d8a3fe3d9568e02e156a36b6f33ca0b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2867 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-20x86: don't clear bss in ramstage entryAaron Durbin
The cbfs stage loading routine already zeros out the full memory region that a stage will be loaded. Therefore, it is unnecessary to to clear the bss again after once ramstage starts. Change-Id: Icc7021329dbf59bef948a41606f56746f21b507f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2865 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20ARM: remove assembly code dump when stages.o is builtRonald G. Minnich
For diagnostic purposes we had been dumping the assembly code when stages.o was built. We've past the need to do this and it's confusing to watch. Change-Id: Ib84cb73ed9dad3454efcb2be90d990ce88575229 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2555 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-20ARM: Fix the ldscripts so that exit/enter stage work correctly.Ronald G. Minnich
Remove the spurious creation of a start symbol, and use the stage_entry symbol directly. Change-Id: Ia62d5c056ac8b20c8ffdb78bff3d306065b6c45f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2560 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-20x86: provide more C standard environmentAaron Durbin
There are some external libraries that are built within coreboot's environment that expect a more common C standard environment. That includes things like inttypes.h and UINTx_MAX macros. This provides the minimal amount of #defines and files to build vboot_reference. Change-Id: I95b1f38368747af7b63eaca3650239bb8119bb13 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2859 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19armv7/exynos/snow: new cache maintenance APIDavid Hendricks
This adds a new API for cache maintenance operations. The idea is to be more explicit about operations that are going on so it's easier to manage branch predictor, cache, and TLB cleans and invalidations. Also, this adds some operations that were missing but required early on, such as branch predictor invalidation. Instruction and sync barriers were wrong earlier as well since the imported API assumed we compield with -march=armv5 (which we don't) and was missing wrappers for the native ARMv7 ISB/DSB/DMB instructions. For now, this is a start and it gives us something we can easily use in libpayload for doing things like cleaning and invalidating dcache when doing DMA transfers. TODO: - Set cache policy explicitly before re-enabling. Right now it's left at default. - Finish deprecating old cache maintenance API. - We do an extra icache/dcache flush when going from bootblock to romstage. Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2729 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19rmodule: add ramstage supportAaron Durbin
Coreboot's ramstage defines certain sections/symbols in its fixed static linker script. It uses these sections/symbols for locating the drivers as well as its own program information. Add these sections and symbols to the rmodule linker script so that ramstage can be linked as an rmodule. These sections and symbols are a noop for other rmodule-linked programs, but they are vital to the ramstage. Also add a comment in coreboot_ram.ld to mirror any changes made there to the rmodule linker script. Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2786 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19x86: remove stack definition in linker scriptAaron Durbin
In order to prepare the ramstage to be linked by the rmodule linker the stack needs to be self-contained within the ramstage objects. The reasoning is that the rmodule linker provides a way to define a heap, but it doesn't currently have a region for the stack. The downside to this is that memory footprint of the ramstage can change when compared before this change. The size difference stems from the link ordering of the objects as the stack is now defined within c_start.S. The size fluctuation ranges from 0 to CONFIG_STACK_SIZE - 1 because of the previous behavior or aligning to CONFIG_STACK_SIZE. It should be noted that such an alignment is unnecessary for 32-bit x86 as the alignment requirement for the stacks are 4 byte alignment. Also the memory footprint is still dominated by CONFIG_RAMTOP and CONFIG_RAMBASE. Change-Id: I63a4ddd249104bc27aff2ab6b39fc6db12b54028 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2785 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19cbfstool locate: Rename -a align switch to -P for page sizeHung-Te Lin
cbfstool usage change: The "-a" parameter for "cbfstool locate" is switched to "-P/--page-size". The "locate" command was used to find a place to store ELF stage image in one memory page. Its argument "-a (alignment)" was actually specifying the page size instead of doing memory address alignment. This can be confusing when people are trying to put a blob in aligned location (ex, microcode needs to be aligned in 0x10), and see this: cbfstool coreboot.rom locate -f test.bin -n test -a 0x40000 # output: 0x44, which does not look like aligned to 0x40000. To prevent confusion, it's now switched to "-P/--page-size". Verified by building i386/axus/tc320 (with page limitation 0x40000): cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000 # output: 0x44 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731 Reviewed-on: http://review.coreboot.org/2730 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 07:32:31 +0000