- 15 7月, 2016 40 次提交
-
-
-
由 Chen-Yu Tsai 提交于
Now that we have a secure data section for storing variables, there should be no need for platform code to get the stack address. Make psci_get_cpu_stack_top a local function, as it should only be used in armv7/psci.S and only by psci_stack_setup. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Now that we have a secure data section and space to store per-CPU target PC address, switch to it instead of storing the target PC on the stack. Also save clobbered r4-r7 registers on the stack and restore them on return in psci_cpu_on for Tegra, i.MX7, and LS102xA platforms. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Now that we have a data section, add helper functions to save and fetch per-CPU target PC. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
The secure monitor may need to store global or static values within the secure section of memory, such as target PC or CPU power status. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
sunxi and i.mx7 both define the __secure modifier to put functions in the secure section. Move this to a common place. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Both sun6i and sun7i have 64 KB of secure SRAM. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
As the PSCI implementation grows, we might exceed the size of the secure memory that holds the firmware. Add a configurable CONFIG_ARMV7_SECURE_MAX_SIZE so platforms can define how much secure memory is available. The linker then checks the size of the whole secure section against this. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
psci_text_end was used to calculate the PSCI stack address following the secure monitor text. Now that we have an explicit secure stack section, this is no longer used. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Now that we have a secure stack section that guarantees usable memory, allocate the PSCI stacks in that section. Also add a diagram detailing how the stacks are placed in memory. Reserved space for the target PC remains unchanged. This should be moved to global variables within a secure data section in the future. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Until now we've been using memory beyond psci_text_end as stack space for the secure monitor or PSCI implementation, even if space was not allocated for it. This was partially fixed in ("ARM: allocate extra space for PSCI stack in secure section during link phase"). However, calculating stack space from psci_text_end in one place, while allocating the space in another is error prone. This patch adds a separate empty secure stack section, with space for CONFIG_ARMV7_PSCI_NR_CPUS stacks, each 1 KB. There's also __secure_stack_start and __secure_stack_end symbols. The linker script handles calculating the correct VMAs for the stack section. For platforms that relocate/copy the secure monitor before using it, the space is not allocated in the executable, saving space. For platforms that do not define CONFIG_ARMV7_PSCI_NR_CPUS, a whole page of stack space for 4 CPUs is allocated, matching the previous behavior. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
The original PSCI implementation assumed CONFIG_ARMV7_PSCI_NR_CPUS=4. Add this to platforms that have not defined it, using CONFIG_MAX_CPUS if it is defined, or the actual number of cores for the given platform. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Targets that define CONFIG_ARMV7_SECURE_BASE will copy the secure section to another address before execution. Since the secure section in the u-boot image is only storage, there's no reason to page align it and increase the binary image size. Page align the secure section only when CONFIG_ARMV7_SECURE_BASE is not defined. And instead of just aligning the __secure_start symbol, align the whole .__secure_start section. This also makes the section empty, so we need to add KEEP() to the input entry to prevent the section from being garbage collected. Also use ld constant "COMMONPAGESIZE" instead of hardcoded page size. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
sun7i has 2 CPUs. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
This patch finishes the rewrite of sunxi specific PSCI parts into C code. The assembly-only stack setup code has been factored out into a common function for ARMv7. The GIC setup code can be renamed as psci_arch_init. And we can use an empty stub function for psci_text_end. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Chen-Yu Tsai 提交于
Every platform has the same stack setup code in assembly as part of psci_arch_init. Move this out into a common separate function, psci_stack_setup, for all platforms. This will allow us to move the remaining parts of psci_arch_init into C code, or drop it entirely. Also provide a stub no-op psci_arch_init for platforms that don't need their own specific setup code. Signed-off-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Hans de Goede 提交于
The Orange Pi Lite SBC is a small H3 based SBC, with 512MB RAM, micro-sd slot, HDMI out, 2 USB-A connectors, 1 micro-USB connector, sdio attached rtl8189ftv wifi and an ir receiver. The dts file is identical to the one submitted to the upstream kernel. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
由 Hans de Goede 提交于
This enables extra USB controllers which enable use of the 3rd USB port on the new Orange Pi Plus 2E variant. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
由 Hans de Goede 提交于
The Plus variant of the Orange Pi PC has an eMMC, add support for this. Note we are using the same u-boot defconfig / dts for both the regular Orange Pi PC as well as the Orange Pi PC Plus. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
由 Hans de Goede 提交于
Now that we know that the BROM stores a value indicating the boot-source at the beginning of SRAM, use that instead of trying to recreate the BROM's boot probing. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
由 Hans de Goede 提交于
We always define CONFIG_MISC_INIT_R on sunxi and misc_init_r is never called in the spl, so the linker will optimize it and parse_spl_header(), of which it is the only caller, away. On the tests I've done (Orange Pi PC build) the SPL actually becomes 8 bytes smaller with this patch. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
由 Hans de Goede 提交于
Currently we fill ethaddr with a fixed unique address based on the SoCs serial (from the sid) to make sure that boards which use the integrated emac / gmac get a fixed mac rather then a random one. On some boards the wifi does not come with a fixed mac either, so we need to also set eth1addr. This commit changes the ethaddr setting code to check for ethernet%d aliases (as fdt_fixup_ethernet does) and set an ethaddr variable for all present aliases. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
-
-
由 Amit Singh Tomar 提交于
This patch add EMAC driver support for H3/A83T/A64 SoCs. Tested on Pine64(A64-External PHY) and Orangepipc(H3-Internal PHY). BIG Thanks to Andre for providing some of the DT code. Signed-off-by: NAmit Singh Tomar <amittomer25@gmail.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Tobias Doerffel 提交于
With a recent bunch of SD3.0 cards in our A20-based board we experienced data transfer rates of about 250 KiB/s instead of 10 MiB/s with previous cards from the same vendor (both 4 GB/class 10). By increasing status register polling rate from 1 kHz to 1 MHz we were able to reach the original transfer rates again. With the old cards we now even reach about 16 MiB/s. Signed-off-by: NTobias Doerffel <tobias.doerffel@ed-chemnitz.de> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Bernhard Nortmann 提交于
The patch converts one of the "reserved" fields in the sunxi SPL header to a fel_uEnv_length entry. When booting over USB ("FEL mode"), this enables the sunxi-fel utility to pass the string length of uEnv.txt compatible data; at the same time requesting that this data be imported into the U-Boot environment. If parse_spl_header() in the sunxi board.c encounters a non-zero value in this header field, it will therefore call himport_r() to merge the string (lines) passed via FEL into the default settings. Environment vars can be changed this way even before U-Boot will attempt to autoboot - specifically, this also allows overriding "bootcmd". With fel_script_addr set and a zero fel_uEnv_length, U-Boot is safe to assume that data in .scr format (a mkimage-type script) was passed at fel_script_addr, and will handle it using the existing mechanism ("bootcmd_fel"). Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de> Acked-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Siarhei Siamashka 提交于
Allwinner devices support SPI flash as one of the possible bootable media type. The SPI flash chip needs to be connected to SPI0 pins (port C) to make this work. More information is available at: https://linux-sunxi.org/Bootable_SPI_flash This patch adds the initial support for booting from SPI flash. The existing SPI frameworks are not used in order to reduce the SPL code size. Right now the SPL size grows by ~370 bytes when CONFIG_SPL_SPI_SUNXI option is enabled. While there are no popular Allwinner devices with SPI flash at the moment, testing can be done using a SPI flash module (it can be bought for ~2$ on ebay) and jumper wires with the boards, which expose relevant pins on the expansion header. The SPI flash chips themselves are very cheap (some prices are even listed as low as 4 cents) and should not cost much if somebody decides to design a development board with an SPI flash chip soldered on the PCB. Another nice feature of the SPI flash is that it can be safely accessed in a device-independent way (since we know that the boot ROM is already probing these pins during the boot time). And if, for example, Olimex boards opted to use SPI flash instead of EEPROM, then they would have been able to have U-Boot installed in the SPI flash now and boot the rest of the system from the SATA hard drive. Hopefully we may see new interesting Allwinner based development boards in the future, now that the software support for the SPI flash is in a better shape :-) Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option in a board defconfig, then building U-Boot and finally flashing the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with a help of the sunxi-fel tool: sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin The device needs to be switched into FEL (USB recovery) mode first. The most suitable boards for testing are Orange Pi PC and Pine64. Because these boards are cheap, have no built-in NAND/eMMC and expose SPI0 pins on the Raspberry Pi compatible expansion header. The A13-OLinuXino-Micro board also can be used. Signed-off-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Simon Glass 提交于
Revise the content based on the v2 additions. This is kept as a separate patch to avoid confusing those who have already reviewed the v1 series. Signed-off-by: NSimon Glass <sjg@chromium.org> Suggested-by: NTom Rini <trini@konsulko.com>
-
由 Simon Glass 提交于
Add a simple test which checks that the of-platdata system is working correctly. The sequence is as follows: - SPL starts up and probes all the UCLASS_MISC drivers - There are 3 of these in sandbox.dts - Therefore there should be 3 U_BOOT_DEVICE() declarations in dt-platdata.c - These should produce 3 sandbox_spl_test devices - Each device prints out its platform data when probed - This test checks for this output and compares it against expectations Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
When sandbox SPL is enabled we want to start that rather than U-Boot proper, since some tests may rely on running it first. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Some tests want to check the console output from SPL or U-Boot proper. Provide a means to do this. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
At present the SPL and U-Boot consoles both present the same error message when the expected console output does not appear. Add "SPL" to the SPL error message to resolve this ambiguity. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This board can sometimes be used for tests. Handle it the same way as sandbox. Note: I plan to drop the sandbox_spl board at some point and merge its features into sandbox. So this commit may not be necessary. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
As an experiment, move this board over to use of-platdata. This means that its SPL configuration will come from C structures generated at build-time from the device tree, instead of coming from the device tree at run-time. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Add support for of-platdata with rk3288 SDRAM initr. This requires decoding the of-platdata struct and setting up the device from that. Also the driver needs to be renamed to match the string that of-platdata will search for. The platform data is copied from the of-platdata structure to the one used by the driver. This allows the same code to be used with device tree and of-platdata. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
It is more correct to avoid touching the device tree in the probe() method. Update the driver to work this way. Note that only SPL needs to fiddle with the SDRAM registers, so decoding the platform data fully is not necessary in U-Boot proper. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The syscon devices all end up having diffent driver names with of-platdata, since the driver name comes from the first string in the compatible list. Add separate device declarations for each one, and add a bind method to set up driver_data correctly. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This function cannot look at the device tree when of-platdata is used. Update the code to handle this. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
When the boot ROM sets up MMC we don't need to do it again. Remove the MMC setup code entirely. Signed-off-by: NSimon Glass <sjg@chromium.org>
-