summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* rockchip: rk3399: Enable DISPLAY_CPUINFOJagan Teki2020-01-3024-24/+0
| | | | | | | | RK3288, RK3399 are now support cpu-info, so enable DISPLAY_CPUINFO by default. Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
* rockchip: Add cpu-infoJagan Teki2020-01-302-0/+17
| | | | | | | | | | Add cpu information for rockchip soc. This would help to print the SoC family number, with associated temparature, clock and reason for reset etc. Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
* rockpro-rk3399: Enable SPI FlashJagan Teki2020-01-302-0/+6
| | | | | | | Enable winbond SPI flash for ROC-PC-RK3399 board. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* roc-pc-rk3399: Enable SPI FlashJagan Teki2020-01-302-0/+6
| | | | | | | Enable winbond SPI flash for ROC-PC-RK3399 board. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* rockchip: dts: Sync ROC-RK3399-PC changes from LinuxJagan Teki2020-01-302-670/+816
| | | | | | | | | | | Sync the ROC-RK3399-PC device tree changes from Linux with below commit details: commit <c36308abe4110e4db362d5e2ae3797834a7b1192> ("arm64: dts: rockchip: Enable MTD Flash on rk3399-roc-pc") Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* env: Enable SPI flash env for rockchipJagan Teki2020-01-301-0/+3
| | | | | | | | | | | | | Most of the SPI flash devices in rockchip are 16MiB size. So, keeping U-Boot proper offset start from 128MiB with 1MiB size and then start env of 8KiB would be a compatible location between all variants of flash sizes. This patch add env start from 0x14000 with a size of 8KiB. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* env: kconfig: Restrict rockchip env for MMCJagan Teki2020-01-301-2/+3
| | | | | | | | | | | Rockchip do support SPI flash as well, so there is a possibility of using flash environment for those use cases. So, restrict the current env offset, size for MMC. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* rk3399: Check MMC env while defining itJagan Teki2020-01-301-1/+3
| | | | | | | | | | | | rk3399 do support SPI flash as well, so there is a possibility of using flash environment for those usecases. So define env device for MMC only when it is used by specific configuration. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* ram: rk3399: don't assume phy_io_config() uses real regsThomas Hebb2020-01-301-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the RK3399 DRAM driver, the function set_ds_odt() supports operating in two different modes, selected by the ctl_phy_reg argument: when true, the function reads and writes directly from the DRAM registers, accessed through "chan->pctl->denali_*"; when false, the function reads and writes from an array, accessed through "params->pctl_regs.denali_*", which is written to DRAM registers at a later time. However, phy_config_io(), which is called by set_ds_odt() to do a subset of its register operations, operates directly on DRAM registers at all times. This means that it reads incorrect values (and writes new values prematurely) when ctl_phy_reg in set_ds_odt() is false. Fix this by passing in the address of the registers to work with. This prevents an "Invalid DRV value" error in the SPL debug log and (presumably) results in a more correct end state. See the following logs from a RK3399 NanoPi M4 board (4GB LPDDR3): Before: sdram_init() Starting SDRAM initialization... phy_io_config() Invalid DRV value. phy_io_config() Invalid DRV value. sdram_init() sdram_init: data trained for rank 2, ch 0 phy_io_config() Invalid DRV value. phy_io_config() Invalid DRV value. sdram_init() sdram_init: data trained for rank 2, ch 1 Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride sdram_init() Finish SDRAM initialization... After: sdram_init() Starting SDRAM initialization... sdram_init() sdram_init: data trained for rank 2, ch 0 sdram_init() sdram_init: data trained for rank 2, ch 1 Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride 256B stride sdram_init() Finish SDRAM initialization... Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
* Merge tag 'for-v2020.04' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2cTom Rini2020-01-2925-164/+454
|\ | | | | | | | | | | | | | | | | | | | | i2c changes for 2020.04 - updates the Designware I2C driver - get timings from device tree - handle units in nanoseconds - make sure that the requested bus speed is not exceeded - few smaller clean-ups - adds enums for i2c speed and update drivers which use them - global_data: remove unused mxc_i2c specific field
| * i2c: designware_i2c: Do more in the probe() methodSimon Glass2020-01-271-8/+8
| | | | | | | | | | | | | | Move some of the code currently in the ofdata_to_platdata() method to probe() so that it is not executed when generating ACPI tables. Signed-off-by: Simon Glass <sjg@chromium.org>
| * i2c: designware_i2c: Separate out the speed calculationSimon Glass2020-01-272-33/+48
| | | | | | | | | | | | | | | | | | | | | | We want to be able to calculate the speed separately from actually setting the speed, so we can generate the required ACPI tables. Split out the calculation into its own function. Drop the double underscore on __dw_i2c_set_bus_speed while we are here. That is reserved for compiler internals. Signed-off-by: Simon Glass <sjg@chromium.org>
| * i2c: designware_i2c: Move dw_i2c_speed_config to headerSimon Glass2020-01-272-17/+17
| | | | | | | | | | | | | | | | | | This is used to store the speed information for a bus. We want to provide this to ACPI so that it can tell the kernel. Move this struct to the header file so it can be accessed by the ACPI i2c implementation being added later. Signed-off-by: Simon Glass <sjg@chromium.org>
| * i2c: designware_i2c: Add support for fast-plus speedSimon Glass2020-01-272-2/+12
| | | | | | | | | | | | Fast-plus runs at 1MHz and is used by some devices. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org>
| * i2c: Update drivers to use enum for speedSimon Glass2020-01-2714-26/+32
| | | | | | | | | | | | | | | | | | Convert the obvious uses of i2c bus speeds to use the enum. Use livetree access for code changes. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: stm32: Update to use standard enums for speedSimon Glass2020-01-271-27/+16
| | | | | | | | | | | | | | | | | | Update this driver to use the new standard enums for speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: omap: Update to use standard enums for speedSimon Glass2020-01-272-5/+1
| | | | | | | | | | | | | | | | | | Update this driver to use the new standard enums for speed. Note: This driver needs to move to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: kona_i2c: Update to use standard enums for speedSimon Glass2020-01-271-17/+11
| | | | | | | | | | | | | | | | | | Update this driver to use the new standard enums for speed. Note: This driver needs to move to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Update to use standard enums for speedSimon Glass2020-01-272-18/+5
| | | | | | | | | | | | | | Update this driver to use the new standard enums for speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: ast_i2c: Update to use standard enums for speedSimon Glass2020-01-272-3/+1
| | | | | | | | | | | | | | Update this driver to use the new standard enums for speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: Add enums for i2c speed and address sizeSimon Glass2020-01-271-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | Some drivers define their own speed enums and use their own constants for speed. It makes sense to have a unified defition of the different speeds. Since many controllers have to do different things for fast/high speed, it is a good idea to have an enum for the mode. Add these as well as an enum for the address mode. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Add spike supressionSimon Glass2020-01-273-1/+13
| | | | | | | | | | | | | | | | Some versions of this peripheral include a spike-suppression phase of the bus. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Rewrite timing calculationSimon Glass2020-01-271-22/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present the driver can end up with timing parameters which are slightly faster than those expected. It is possible to optimise the parameters to get the best possible result. Create a new function to handle the timing calculation. This uses a table of defaults for each speed mode rather than writing it in code. The function works by calculating the 'period' of each bit on the bus in terms of the input clock to the controller (IC_CLK). It makes sure that the constraints are met and that the different components of that period add up correctly. This code was taken from coreboot which has ended up with this same driver, but now in a much-different form. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Put hold config in a structSimon Glass2020-01-271-27/+55
| | | | | | | | | | | | | | | | | | Create a struct to hold the three timing parameters. This will make it easier to move these calculations into a separate function in a later patch. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Drop scl_sda_cfg parameterSimon Glass2020-01-271-6/+8
| | | | | | | | | | | | | | | | | | | | | | Instead of passing this parameter into __dw_i2c_set_bus_speed(), pass in the driver's private data, from which the function can obtain that information. This allows the function to have access to the full state of the driver. Signed-off-by: Sicomp_param1mon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
| * i2c: designware_i2c: Read device-tree propertiesSimon Glass2020-01-273-3/+22
| | | | | | | | | | | | | | | | The i2c controller defines a few timing properties. Read these in and store them for use by the driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Bring in the binding fileSimon Glass2020-01-271-0/+73
| | | | | | | | | | | | | | Bring in this file from Linux v5.4. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Use an accurate bus clock instead of MHzSimon Glass2020-01-272-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present the driver uses an approximation for the bus clock, e.g. 166MHz instead of 166 2/3 MHz. This can result in small errors in the resulting I2C speed, perhaps 0.5% or so. Adjust the existing code to start from the accurate figure, even if later rounding reduces this accuracy. Update the bus speed code to work in KHz instead of MHz, which removes most of the error. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Use an enum for selected speed modeSimon Glass2020-01-272-4/+8
| | | | | | | | | | | | | | | | | | Group these #defines into an enum to make it easier to understand the relationship between them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Rename 'max' speed to 'high' speedSimon Glass2020-01-272-9/+9
| | | | | | | | | | | | | | | | | | | | Some SoCs support a higher speed than what is currently called 'max' in this driver. Rename it to 'high' speed, which is the official name of the 3.4MHz speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Include clk.h in the header fileSimon Glass2020-01-272-1/+2
| | | | | | | | | | | | | | | | | | | | | | We use struct clk here so really should include this header file to avoid build errors. Also switch the order of clk.h in the C file to match the required code style. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Don't allow changing IC_CLKSimon Glass2020-01-271-2/+0
| | | | | | | | | | | | | | | | If a different input clock is required then the correct way to do this is with a clock driver. Don't allow boards to override IC_CLK. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
| * i2c: designware_i2c: Add more registersSimon Glass2020-01-271-1/+13
| | | | | | | | | | | | | | | | | | | | Some versions of this peripherals provide more control of the bus behaviour. Add definitions for these registers. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
| * global_data: remove unused mxc_i2c specific fieldBaruch Siach2020-01-271-3/+0
| | | | | | | | | | | | | | | | | | The srdata field is unused since commit 71204e95ce13228 ("i2c: mxc: refactor i2c driver and support dm"). Cc: Peng Fan <peng.fan@nxp.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Peng Fan <peng.fan@nxp.com>
* | Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-samsungTom Rini2020-01-2810-14/+51
|\ \ | | | | | | | | | - Various exynos fixes
| * | arm: exynos: odroid: Change autoboot script to use ${mmcbootdev}Marek Szyprowski2020-01-281-4/+4
| | | | | | | | | | | | | | | | | | | | | This fixes the default boot command for the SD-card boot case. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | arm: exynos: Read default MMC device from XOM[7:5] pinsMarek Szyprowski2020-01-284-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | XOM pins provide information for iROM bootloader about the boot device. Those pins are mapped to lower bits of OP_MODE register (0x10000008), which is common for all Exynos SoC variants. Set the default MMC device id to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for the eMMC). Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)Marek Szyprowski2020-01-232-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use MMC0 for eMMC and MMC2 for SD-card as other Exynos-based boards do. This allows to use common code to get MMC device id based on the XOM[7:5] pins. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2Marek Szyprowski2020-01-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Card detect line for SD-card on Odroid U3/X2 boards are active low, so add cd-inverted property to indicate this, as u-boot's GPIO driver doesn't support specifying line polarity. This restores S5P_SDHCI driver operation on Odroid U3/X2 boards. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | mmc: s5p_sdhci: Read generic MMC properties from DTMarek Szyprowski2020-01-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Read generic MMC properties from device-tree. This allows to specify for example cd-inverted property and let MMC core to properly handle such case. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | arm: exynos: Use proper PMIC device namesMarek Szyprowski2020-01-232-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 4213609cc7 ("drivers: core: use strcmp when find device by name") one has to provide full name to get requested object. Fix the code used to detect enable power regulators on the supported Exynos boards to use proper PMIC device device name then. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | arm: exynos: Use proper ADC device nameMarek Szyprowski2020-01-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 4213609cc7 ("drivers: core: use strcmp when find device by name") one has to provide full name to get requested object. Fix the code used to detect Odroid board revision to use proper ADC device name then. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
| * | arm: dts: exynos: Extend board descriptionMarek Szyprowski2020-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | u-boot uses the same DTS for the all Odroid XU3-based boards, so list them in the model description to let user know that those boards are supported. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
* | | Prepare v2020.04-rc1Tom Rini2020-01-281-2/+2
| | | | | | | | | | | | Signed-off-by: Tom Rini <trini@konsulko.com>
* | | Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-spiTom Rini2020-01-2716-239/+1290
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - spi cs accessing slaves (Bin Meng) - spi prevent overriding established bus (Marcin Wojtas) - support speed in spi command (Marek Vasut) - add W25N01GV spinand (Robert Marko) - move cadence_qspi to use spi-mem (Vignesh Raghavendra) - add octal mode (Vignesh Raghavendra)
| * | | spi: cadence-qspi: Add compatible for TI AM654Vignesh Raghavendra2020-01-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TI's AM654 SoC has a Cadence OSPI IP. Add a new compatible string for the same. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
| * | | spi: cadence-qspi: Add support for Cadence Octal SPI controllerVignesh Raghavendra2020-01-272-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cadence OSPI is similar to QSPI IP except that it supports Octal IO (8 IO lines) flashes. Add support for Cadence OSPI IP with existing driver using new compatible Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
| * | | mtd: spi-nor-core: Add octal mode supportVignesh Raghavendra2020-01-276-2/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Octal flash devices. Octal flash devices use 8 IO lines for data transfer. Currently only 1-1-8 Octal Read mode is supported. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
| * | | spi: cadence-qspi: Add direct mode supportVignesh Raghavendra2020-01-273-33/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Direct Access Controller mode of Cadence QSPI. This allows MMIO access to SPI NOR flash providing better read performance. Direct mode is only exercised if AHB window size is greater than 8MB. Support for flash address remapping is also not supported at the moment and can be added in future. For better performance, driver uses DMA to copy data from flash in direct mode using dma_memcpy(). Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
| * | | spi: cadence_qspi: Move to spi-mem frameworkVignesh Raghavendra2020-01-273-178/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current Cadence QSPI driver has few limitations. It assumes all read operations to be in Quad mode and thus does not support SFDP parsing. Also, adding support for new mode such as Octal mode would not be possible with current configuration. Therefore move the driver over to spi-mem framework. This has added advantage that driver can be used to support SPI NAND memories too. Hence, move driver over to new spi-mem APIs. Please note that this gets rid of mode bit setting done when CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to that config option. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
generated by cgit (git 2.34.1) at 2024-07-01 21:24:31 +0000