summaryrefslogtreecommitdiff
path: root/board/raspberrypi/rpi/rpi.c
Commit message (Collapse)AuthorAgeLines
* bcm2835: Reserve the spin table in efi memory mapAlexander Graf2016-11-28-0/+6
| | | | | | | | Firmware provides a spin table on the raspberry pi. This table shouldn't get overwritten by payloads, so we need to mark it as reserved. Signed-off-by: Alexander Graf <agraf@suse.de> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: bcm283x: use OF_CONTROL for bcm283xFabian Vogt2016-11-28-37/+0
| | | | | | | | This patch removes use of U_BOOT_DEVICE in board/raspberrypi/rpi/rpi.c, enables OF_CONTROL in the config and adjusts the rpi_*defconfig configs. Signed-off-by: Fabian Vogt <fvogt@suse.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* board: rpi: move uart deactivation to board_initFabian Vogt2016-11-28-14/+26
| | | | | | | | | | | When using OF_CONTROL, the disabled value of the mini UART platdata gets reset after board_early_init_f. So move detection and disabling to board_init and remove board_early_init_f. This uses the first device using the mini uart driver, as this method works reliably with different device trees or even no device tree at all. Signed-off-by: Fabian Vogt <fvogt@suse.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* rpi: passthrough of the firmware provided FDT blobCédric Schieli2016-11-21-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Raspberry firmware used to pass a FDT blob at a fixed address (0x100), but this is not true anymore. The address now depends on both the memory size and the blob size [1]. If one wants to passthrough this FDT blob to the kernel, the most reliable way is to save its address from the r2/x0 register in the U-Boot entry point and expose it in a environment variable for further processing. This patch just does this: - save the provided address in the global variable fw_dtb_pointer - expose it in ${fdt_addr} if it points to a a valid FDT blob There are many different ways to use it. One can, for example, use the following script which will extract from the tree the command line built by the firmware, then hand over the blob to a previously loaded kernel: fdt addr ${fdt_addr} fdt get value bootargs /chosen bootargs bootz ${kernel_addr_r} - ${fdt_addr} Alternatively, users relying on sysboot/pxe can simply omit any FDT statement in their extlinux.conf file, U-Boot will automagically pick ${fdt_addr} and pass it to the kernel. [1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018 Signed-off-by: Cédric Schieli <cschieli@gmail.com> Acked-by: Stephen Warren <swarren@nvidia.com>
* serial: bcm283x_mu: Detect disabled serial deviceAlexander Graf2016-09-06-1/+33
| | | | | | | | | | | | | | | | | | | | On the raspberry pi, you can disable the serial port to gain dynamic frequency scaling which can get handy at times. However, in such a configuration the serial controller gets its rx queue filled up with zero bytes which then happily get transmitted on to whoever calls getc() today. This patch adds detection logic for that case by checking whether the RX pin is mapped to GPIO15 and disables the mini uart if it is not mapped properly. That way we can leave the driver enabled in the tree and can determine during runtime whether serial is usable or not, having a single binary that allows for uart and non-uart operation. Signed-off-by: Alexander Graf <agraf@suse.de> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* armv8: mmu: Add support of non-identical mappingYork Sun2016-07-15-2/+4
| | | | | | | Introduce virtual and physical addresses in the mapping table. This change have no impact on existing boards because they all use idential mapping. Signed-off-by: York Sun <york.sun@nxp.com>
* ARM: add Raspberry Pi 3 64-bit configStephen Warren2016-04-11-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On all Pis so far, the VC FW provides a short stub to set up the ARM CPU before entering the kernel (a/k/a U-Boot for us). This feature is not currently supported by the VC FW when booting in 64-bit mode. However, this feature will likely appear in the near future, and this U-Boot port assumes that such a feature is in place. Without that feature, or a temporary workaround described below, U-Boot will not boot. Once the VC FW does provide the ARM stub, u-boot.bin built for rpi_3 can be used drectly as kernel7.img, in the same way as any other RPi port. The following config.txt is required: # Fix mini UART input frequency, and setup/enable up the UART. # Without this option, U-Boot will not boot, even if you don't care # about the serial console. This option will always be required for # all RPi3 use-cases, unless the PL011 UART is used, which is not # yet supported by rpi_3* builds of U-Boot. enable_uart=1 # Boot in AArch64 (64-bit) mode. # It is possible that a future VC FW will remove the need for this # option, instead auto-setting 32-/64-bit mode based on the "kernel" # filename present on the SD card. arm_control=0x200 Prior to the VC FW providing the ARM boot stub, you can use the following steps to build an equivalent stub into the U-Boot binary: git clone https://github.com/swarren/rpi-3-aarch64-demo.git \ ../rpi-3-aarch64-demo (cd ../rpi-3-aarch64-demo && ./build.sh) Build U-Boot for rpi_3 in the usual way cat ../rpi-3-aarch64-demo/armstub64.bin u-boot.bin > u-boot.bin.stubbed Use u-boot.bin.stubbed as kernel7.img on the Pi SD card. In this case, the following additional entries are required in config.txt: # Tell the FW to load the kernel image at address 0, the reset vector. kernel_old=1 Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* rpi: BCM2837 and Raspberry Pi 3 32-bit supportStephen Warren2016-04-01-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with the CPU complex swapped out for a quad-core ARMv8. This can operate in 32- or 64-bit mode. 32-bit mode is the current default selected by the VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of U-Boot for the Raspberry Pi 3. >From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a change in usage of the SoC UARTs. On all previous Pis, the PL011 was the only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a UART to connect to the SoC. By default, the PL011 is used for this purpose since it has larger FIFOs than the other "mini" UART. However, this can be configured via the VideoCore firmware's config.txt file. This patch hard-codes use of the mini UART in the RPi 3 port. If your system uses the PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot port instead. A future change might determine which UART to use at run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed together. The mini UART has some limitations. One externally visible issue in the BCM2837 integration is that the UART divides the SoC's "core clock" to generate the baud rate. The core clock is typically variable, and under control of the VideoCore firmware for thermal management reasons. If the VC FW does modify the core clock rate, UART communication will be corrupted since the baud rate will vary from the expected value. This was not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To work around this, the VideoCore firmware can be told not to modify the SoC core clock. However, the only way this can happen and be thermally safe is to limit the core clock to a low/minimum frequency. This leaves performance on the table for use-cases that don't care about a UART console. Consequently, use of the mini UART console must be explicitly requested by entering the following line into config.txt: enable_uart=1 A recent version of the VC firmware is required to ensure that the mini UART is fully and correctly initialized by the VC FW; at least firmware.git 046effa13ebc "firmware: arm_loader: emmc clock depends on core clock See: https://github.com/raspberrypi/firmware/issues/572". Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* rpi: add Raspberry Pi 3 board IDStephen Warren2016-04-01-0/+5
| | | | | | | | | | | | | | | | | | | | | | This allows U-Boot to known the name of the board. The existing rpi_2_defconfig can operate correctly on the Raspberry Pi 3 in 32-bit mode /if/ you have configured the firmware to use the PL011 UART as the console UART (the default is the mini UART). This requires two things: a) config.txt should contain dtoverlay=pi3-miniuart-bt b) You should run the following to tell the VC FW to process DT when booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD card as the kernel image: path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img This works as of firmware.git commit 046effa13ebc "firmware: arm_loader: emmc clock depends on core clock See: https://github.com/raspberrypi/firmware/issues/572". Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* rpi: use constant "unknown board" DT filenameStephen Warren2016-04-01-5/+1
| | | | | | | | | | | To simplify support for new SoCs, just use a constant filename for the unknown case. In practice this case shouldn't be hit anyway, so the filename isn't relevant, and certainly doesn't need to differentiate between SoCs. If a user has an as-yet-unknown board, they can override this value in the environment anyway. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: bcm283x: don't always define CONFIG_BCM2835Stephen Warren2016-03-27-1/+1
| | | | | | | | | | | | | Currently, CONFIG_BCM2835 is defined for all BCM283x builds and _BCM2836 is defined when building for that SoC. That means there isn't a single define that means "exactly BCM2835". This will complicate future patches where BCM2835-vs-anything-else needs to be determined simply. Modify the code to define one or the other of CONFIG_BCM2835/BCM2836 so future patches are simpler. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* serial: pl01x: Add support for devices with the rate pre-configured.Eric Anholt2016-03-22-1/+1
| | | | | | | | | | | | | For Raspberry Pi, we had the input clock rate to the pl011 fixed in the rpi.c file, but it may be changed by firmware due to user changes to config.txt. Since the firmware always sets up the uart (default 115200 output unless the user changes it), we can just skip our own uart init to simplify the boot process and more reliably get serial output. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: set board serial number in environmentLubomir Rintel2016-02-24-0/+33
| | | | | | | | | Gets propagated into the device tree and then into /proc/cpuinfo where users often expect it. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Tested-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: set ethaddr as wellLubomir Rintel2016-02-08-0/+3
| | | | | | | | | Let's set "ethaddr" when we get the ethernet address too, so that fdt_fixup_ethernet() sets the address in the device tree and the Linux driver can pick it up. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: fix up Model B entriesLubomir Rintel2016-02-08-10/+10
| | | | | | | | | | | | | The P5 header was not present on "Model B" any board prior to Revision 2.0, there's no need for a separate device tree. Also, it looks like "rev2" is incorrectly used to only cover the 512MiB memory models; there also were 256MiB 2.0 boards. I don't have all of the boards to check this, I'm following this table: http://elinux.org/RPi_HardwareHistory#Board_Revision_History Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
* rpi: link to another model number info sourceStephen Warren2016-02-08-0/+5
| | | | | | | | | | This source has been blessed by Dom Cobley at the RPi Foundation, so seems like the best source to refer to. It's a superset of and consistent with the other sources. Cc: Lubomir Rintel <lkundrak@v3.sk> Cc: Eric Anholt <eric@anholt.net> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: add support for Raspberry Pi ZeroStephen Warren2015-12-05-0/+5
| | | | | | | For U-Boot's purposes, at present all we care about is ensuring there's a model table entry. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: fix revision scheme parsingStephen Warren2015-12-05-34/+53
| | | | | | | | | | The RPi has two different schemes for encoding board revision values. When adding RPi 2 support, I thought that the conflicting type field values were to be interpreted based on bcm2835-vs-bcm2836. In fact, the scheme bit determines the encoding. The RPi Zero uses the bcm2835 yet uses the new encoding scheme. Fix the code to cater for this correctly. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: get rid of BCM2835_BOARD_REV_* macrosStephen Warren2015-12-05-19/+23
| | | | | | | | | | | | | | There are two numbering schemes for the RPi revision values; old and new scheme. The values within each scheme overlap. Hence, it doesn't make sense to have absolute/global names for the revision IDs. Get rid of the names and just use the raw revision/type values to set up the array of per-revision data. This change makes most sense when coupled with the next change. However, it's split out so that the mechanical cut/paste is separate from the logic changes for easier review and problem bisection. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG supportGuillaume GARDET2015-10-24-0/+13
| | | | | | | | | | | | Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support and enable it to set 'board_rev' and 'board_name' envs. 'board_rev' can be used in scripts to determine what board we are running on and 'board_name' for pretty printing. Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> Cc: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: add another revision of Raspberry Pi A+Lubomir Rintel2015-10-19-0/+5
| | | | | | | | Seen this one in the wild. Is labelled "Raspberry Pi Model A+ V1.1, (C) Raspberry Pi 2014". A standard A+ board, much like the one with version 0x12, didn't notice any differencies. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
* Move ALLOC_CACHE_ALIGN_BUFFER() to the new memalign.h headerSimon Glass2015-09-11-0/+1
| | | | | | | Now that we have a new header file for cache-aligned allocation, we should move the stack-based allocation macro there also. Signed-off-by: Simon Glass <sjg@chromium.org>
* ARM: bcm283x: Allocate all mailbox buffers cacheline alignedAlexander Stein2015-08-12-5/+5
| | | | | | | | | | The mailbox buffer is required to be at least 16 bytes aligned, but for cache invalidation and/or flush it needs to be cacheline aligned. Use ALLOC_CACHE_ALIGN_BUFFER for all mailbox buffer allocations. Signed-off-by: Alexander Stein <alexanders83@web.de> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: add a couple more revision IDsStephen Warren2015-04-13-0/+10
| | | | | | | | | | | | According to Gordon Henderson's WiringPi library, there are some more Pi revision IDs out there. Add support for them. http://git.drogon.net/?p=wiringPi;a=blob_plain;f=wiringPi/wiringPi.c;hb=5edd177112c99416f68ba3e8c6c4db6ed942e796 At least ID 0x13 is out in the wild: Reported-by: Chee-Yang Chau <cychau@gmail.com> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: fix RPi1 board rev detection for warranty bitStephen Warren2015-03-24-0/+7
| | | | | | | | | Apparently the firmware's board rev response includes both the board revision and some other data even on the RPi1. In particular, the "warranty bit" is bit 24. We need to mask that out when looking up the board ID. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* rpi: add support for Raspberry Pi 2 model BStephen Warren2015-02-21-2/+26
| | | | | | | | USB doesn't seem to work yet; the controller detects the on-board Hub/ Ethernet device but can't read the descriptors from it. I haven't investigated yet. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* bcm2835/rpi: add SPDX license tags for some filesStephen Warren2015-02-21-11/+1
| | | | Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* lcd: dt: extract simplefb supportNikita Kiryanov2015-02-10-0/+1
| | | | | | | | | | | | | | | | | We now have api functions that can support compiling simplefb code as its own module. Since this code is not part of the display functionality, extract it to its own file. Raspberry Pi is updated to accommodate the changes. Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Bo Shen <voice.shen@atmel.com> Tested-by: Josh Wu <josh.wu@atmel.com> Cc: Simon Glass <sjg@chromium.org> Cc: Anatolij Gustschin <agust@denx.de> Cc: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: consolidate board rev error checkingStephen Warren2014-12-29-7/+9
| | | | | | | | | Create a fake model table entry with default values, so we can error check the board rev value once when querying it from the firmware, rather than error-checking for invalid board rev values every time the model table is used. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: support model A+Stephen Warren2014-12-29-2/+12
| | | | | | | Add a board rev entry for the new model A+, and augment the board rev error handling code to be a bit more verbose. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: only set usbethaddr on relevant systemsStephen Warren2014-12-29-0/+17
| | | | | | | | | Model A and CM RPis don't have an on-board USB Ethernet device. Hence, there's no point setting $usbethaddr based on the device fuses. Use the model detection code to gate this. Note that the fuses are actually programmed even on those devices though. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* dm: rpi: Move serial to driver modelSimon Glass2014-12-11-0/+12
| | | | | | | | Adjust the configuration to use the driver model version of the pl01x serial driver. Add the required platform data. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
* ARM: rpi: rename rpi_b to rpiStephen Warren2014-12-08-0/+283
The U-Boot port runs on a variety of RPi models, not just the B. So, rename the port to something slightly more generic. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-09 14:58:33 +0000