- Jan 26, 2023
-
-
Cypress defines two flavors of configuration registers, volatile and non volatile, and both use the same bit fields. Rename the bitfields in the configuration registers so that they can be used for both flavors. Suggested-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by:
Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Reviewed-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by:
Dhruva Gole <d-gole@ti.com> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
CFR5[6] is reserved bit and must be always 1. Set it to comply with flash requirements. While fixing SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN definition, stop using magic numbers and describe the missing bit fields in CFR5 register. This is useful for both readability and future possible addition of Octal STR mode support. Fixes: ea9a22f7 ("mtd: spi-nor-core: Add support for Cypress Semper flash") Suggested-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by:
Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Reviewed-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by:
Dhruva Gole <d-gole@ti.com> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
Introduce Socionext F_OSPI controller driver. This controller is used to communicate with slave devices such as SPI flash memories. It supports 4 slave devices and up to 8-bit wide bus, but supports master mode only. This driver uses spi-mem framework for SPI flash memory access, and can only operate indirect access mode and single data rate mode. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
Use log_warning() instead of printf() to print out driver information Signed-off-by:
Pengfei Fan <fanpengfei1@eswincomputing.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
Fix some typos in spi drivers Signed-off-by:
Pengfei Fan <fanpengfei1@eswincomputing.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com>
-
- Jan 25, 2023
-
-
https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini authored
This contains some fixes, and the first bunch of some clean up patches to get rid of legacy GPIO and PMIC code. Highlight is the DM AXP PMIC driver, which is required to convert some drivers over to use DM regulators, and also is required to get rid of some less optimal PMIC setup code in Trusted Firmware. This isn't enabled by any defconfig yet, but can be enabled manually and works. For the full glory some patches are still missing, and this requires more testing, which would be simpler if the core code is upstream.
-
- Jan 24, 2023
-
-
Tom Rini authored
To quote the author: So far, standard boot does not replicate all the of the functionality of the distro_bootcmd scripts. In particular it lacks some bootdevs and some of the bootmeths are incomplete. Also there is currently no internal mechanism to enumerate buses in order to discover bootdevs, e.g. with USB. This series addresses these shortcomings: - Adds the concept of a 'bootdev hunter' to enumerate buses, etc. in an effort to find bootdevs of a certain priority - Adds bootdevs for SCSI, IDE, NVMe, virtio, SPI flash - Handles PXE and DHCP properly - Supports reading the device tree with EFI and reading scripts from the network It also tidies up label processing, so it is possible to use: bootflow scan mmc2 to scan just one MMC device (with BOOTSTD_FULL). As before this implementation still relies on CONFIG_CMDLINE being enabled, mostly for the network stack. Further work would be required to disentangle that. Quite a few tests are added but there are some gaps: - SPI flash bootdev - EFI FDT loading Note that SATA works via SCSI (CONFIG_SCSI_AHCI) and does not use driver model. Only pogo_v4 seems to be affected. Probably all thats is needed is to call bootdev_setup_sibling_blk() in the Marvell SATA driver. Also, while it would be possible to init MMC in a bootdev hunter, there is no point since U-Boot always inits MMC on startup, if present. With this series it should be possible to migrate boards to standard boot by removing the inclusion of config_distro_bootcmd.h and instead adding a suitable value for boot_targets to the environment, e.g.: boot_targets=mmc1 mmc0 nvme scsi usb pxe dhcp spi Thus it is possible to boot automatically without scripts and boards can use a text-based environment instead of the config.h files. To demonstrate this, rockpro64-rk3399 is migrated to standard boot in this series. Full migration could probably be automated using a script, similar in concept to moveconfig: - obtain the board environment via 'make u-boot-initial-env' - get the value of "boot_targets" - drop config_distro_bootcmd.h from the config.h file - rebuild again to get the environment without distro scripts - write the environment (adding boot_targets) to board.env - remove CONFIG_EXTRA_ENV_SETTINGS from the config.h file
-
- Jan 23, 2023
-
-
Drop the use of scripts and rely on standard boot for all operation. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com>
-
Document the hunters and the new way that iteration works. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add some logging to aid debugging of problems with bootflows. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a way to record the bootdevs used when scanning for bootflows. This is useful for testing. Enable this only with BOOTSTD_FULL and do the same for the progress reporting. Re-enable and update the affected tests now that we have this feature. For bootdev_test_order_default() there is no-longer any support for using the bootdev aliases to specify an ordering, so drop that part of the test. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
This function is not used outside tests. Drop it and rename bootflow_scan_dev() since it is how we start a scan now. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
We want to support scanning a single label, like 'mmc' or 'usb0'. Add this feature by plumbing the label through to the iterator, setting a flag to indicate that only siblings of the initial device should be used. This means that scanning a bootdev by its name is not supported anymore. That feature doesn't seem very useful in practice, so it is no great loss. Add a test for bootdev_find_by_any() while we are here. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
At present we set up the bootdev order at the start, then scan the bootdevs one by one. However this approach cannot be used with hunters, since the bootdevs may not exist until the hunter is used. Nor can we just run all the hunters at the start, since that violate's U-Boot's 'lazy init' requirement. It also increases boot time. So we need to adjust the algorithm to scan by labels instead. As a first step, drop the dev_order[] array in favour of a list of labels. Update the name of bootdev_setup_iter_order() to better reflect what it does. Update some related comments and log messages. Also disable a few tests until a later commit where we can use them. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
This needs to run before any bootdev is used, so add a hunter for it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
The current extension code is designed to be used from commands. We want to add a boot driver which uses it. To help with this, split the code into the command processing and a function which actually does the scan. Really the extension code should be in common/ or use driver model, but this is a start. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a function which moves to the next priority to be processed. This works by storing the current priority in the bootflow iterator. The logic to set this up is included in a subsequent commit. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a function which moves to the next label in a list of labels. This allows processing the boot_targets environment variable. This works using a new label list in the bootflow iterator. The logic to set this up is included in a subsequent commit. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a function to hunt for a bootdev label and find the bootdev produced by the hunter (or already present). Add a few extra flags so that we can distinguish between "mmc1", "mmc" and "1" which all need to be handled differently. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
We need extensions to be set up before we start trying to boot any of the bootdevs. Add a new priority before all the others for tht sort of thing. Also add a 'none' option, so that the first one is not 0. While we are here, comment enum bootdev_prio_t fully and expand the test for the 'bootdev hunt' command. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a way to run the hunter function for a particular priority, so that new bootdevs can be found. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a flag to control whether hunters are used when scanning for bootflows. Enable it by default and tidy up the flag comments a little. Fow now this has no effect, until a future patch enables this feature. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
These are associated with the ethernet boot device but do not match its uclass name, so handle them as special cases. Provide a way to pass flags through with the bootdev so that we know how to process it. The flags are checked by the bootmeths, to ensure that only the selected bootmeth is used. While these both use the network device, they work quite differently. It is common to run only one of these, or to run PXE before DHCP. Provide bootflow flags to control which methods are used. Check these in the two bootmeths so that only the chosen one is used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
At present this bootmeth only supports a block device and the sandbox host filesystem. Add support for obtaining the script from a network device. Also implement the set_bootflow() method so that it is easy for other bootdevs (such as enabling SPI flash to support scripts). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a bootdev for SPI flash so that these devices can be used with standard boot. It only supports loading a script. Add a special case for the label, since we want to use "spi", not "spi_flash". Enable the new bootdev on sandbox. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Most tests don't want these and they can create a lot of noise. Add a way to disable them. Use that in tests, with a flag provided to enable them for tests that need this feature. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Normally the bootmeth driver reads the bootflow from the bootdev, since it knows the correct way to do it. However it is easier for some bootdevs to handle this themselves. For example, reading from SPI flash is quite different from other devices. Add a way for the bootdev to pass a bootflow to the bootmeth, so that this can be supported. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
This is complicated enough to merit its own function, particularly as we are about to add to it. Create a new label_to_uclass() function to decode a label. Also update the code to ignore an empty label or one consisting of just a number. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Mention that this function is also used with a NULL block devices to access files on the host, when using sandbox. Update the comment on struct bootflow also. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
This environment variable is supposed to be set so that the script knows which partition holds the script. Set it before invoking the script. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
With EFI booting the device tree is required but is not actually specified in any way. The normal method is to use a fdtfile environment variable to get the filename, then look for that file on the media. Implement this in the bootmeth. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Some bootmeths provide a way to load a device tree as well as the base OS image. Add a way to store this in the bootflow. Update the 'bootflow info' command to show this information. Note that the device tree is not allocated, but instead is stored at an address provided by an environment variable. This may need to be adjusted at some point, but for now it works well and fits in with the existing distro-boot scripts. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
At present this bootmeth only supports reading from a filesystem. Add support for reading from a network also, using DHCP with autoload. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
These functions return 0 if the check passes, so the names are somewhat confusing. Rename them. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
The controller indicates the number of ports but also has a port map which specifies which ports are actually valid. Make use of this to avoid trying to send commands to an invalid port. This avoids a crash on some controllers. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Add a bootdev for virtio so that these devices can be used with standard boot. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
The test code for virtio is fairly simplistic and does not actually create a block device. Add a way to specify the device type in the device tree. Add a block device so that we can do more testing. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
This device does a check on removal which is better handled in the actual test. Move it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
This has a special meaning in driver model. There is clearly a device, so it does not make sense to return this error code. Fix it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Use a local variable to hold this name, to reduce the amount of code that needs to be read. Signed-off-by:
Simon Glass <sjg@chromium.org>
-