Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > Improve code for checking strapping pins which specifies boot mode source. > > Martin, could you test if Clearfog can be still configured into UART > booting mode via HW switches and if it still works correctly? First > patch is reverting UART related commit for Clearfog which I think it not > needed anymore. > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified. UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though. The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: 98 % [. ] Done Finishing transfer [Type Ctrl-\ + c to quit] It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot. > Also could you check if SATA booting is still working correctly? > SATA works correctly. > Tony, should address problems with SPI booting when it is configured to > different configuration. In fourth commit I added all possible boot mode > strapping pin configurations which are recognized by A385 bootrom (and > not the only one described in the HW spec, which is incomplete). > > Stefan, do you have some AXP board with SATA boot source? Because I'm > adding it for completeness in the last sixth patch. > > Pali Rohár (6): > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > arm: mvebu: Convert BOOT_FROM_* constants to function macros > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > arch/arm/mach-mvebu/cpu.c | 20 ++--- > arch/arm/mach-mvebu/include/mach/soc.h | 41 -- > 2 files changed, 35 insertions(+), 26 deletions(-) > > -- > 2.20.1 > >
Re: [PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros
On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote:
> This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one
> macro. And also allows to extend other BOOT_FROM_* macros for other
> variants.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/cpu.c | 16 +---
> arch/arm/mach-mvebu/include/mach/soc.h | 25 -
> 2 files changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> index daa84c03fcdc..cb3f3afad269 100644
> --- a/arch/arm/mach-mvebu/cpu.c
> +++ b/arch/arm/mach-mvebu/cpu.c
> @@ -98,24 +98,26 @@ u32 get_boot_device(void)
> val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
> boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
> debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
> - switch (boot_device) {
> #ifdef BOOT_FROM_NAND
> - case BOOT_FROM_NAND:
> + if (BOOT_FROM_NAND(boot_device))
> return BOOT_DEVICE_NAND;
> #endif
> #ifdef BOOT_FROM_MMC
> - case BOOT_FROM_MMC:
> - case BOOT_FROM_MMC_ALT:
> + if (BOOT_FROM_MMC(boot_device))
> return BOOT_DEVICE_MMC1;
> #endif
> - case BOOT_FROM_UART:
> +#ifdef BOOT_FROM_UART
> + if (BOOT_FROM_UART(boot_device))
> return BOOT_DEVICE_UART;
> +#endif
> #ifdef BOOT_FROM_SATA
> - case BOOT_FROM_SATA:
> + if (BOOT_FROM_SATA(boot_device))
> return BOOT_DEVICE_SATA;
> #endif
> - case BOOT_FROM_SPI:
> +#ifdef BOOT_FROM_SPI
> + if (BOOT_FROM_SPI(boot_device))
> return BOOT_DEVICE_SPI;
> +#endif
> default:
> return BOOT_DEVICE_BOOTROM;
> };
>
This doesn't compile for me: the switch has only partially been converted
so I get:
arch/arm/mach-mvebu/cpu.c: In function 'get_boot_device':
arch/arm/mach-mvebu/cpu.c:118:9: error: 'default' label not within a switch
statement
118 | default:
| ^~~
arch/arm/mach-mvebu/cpu.c: At top level:
arch/arm/mach-mvebu/cpu.c:121:1: error: expected identifier or '(' before
'}' token
121 | }
| ^
Maybe remove the default and closing bracket lines and just return
BOOT_DEVICE_BOOTROM if nothing else worked? That worked for me.
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> b/arch/arm/mach-mvebu/include/mach/soc.h
> index 5fdce8fe4e7e..aa42db36a1ee 100644
> --- a/arch/arm/mach-mvebu/include/mach/soc.h
> +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> @@ -143,8 +143,8 @@
> #define BOOT_DEV_SEL_OFFS 3
> #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_UART 0x30
> -#define BOOT_FROM_SPI 0x38
> +#define BOOT_FROM_UART(x) (x == 0x30)
> +#define BOOT_FROM_SPI(x) (x == 0x38)
>
> #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(20))
> ? \
> 2 : 16600)
> @@ -160,12 +160,11 @@
> #define BOOT_DEV_SEL_OFFS 4
> #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_NAND 0x0A
> -#define BOOT_FROM_SATA 0x2A
> -#define BOOT_FROM_UART 0x28
> -#define BOOT_FROM_SPI 0x32
> -#define BOOT_FROM_MMC 0x30
> -#define BOOT_FROM_MMC_ALT 0x31
> +#define BOOT_FROM_NAND(x) (x == 0x0A)
> +#define BOOT_FROM_SATA(x) (x == 0x2A)
> +#define BOOT_FROM_UART(x) (x == 0x28)
> +#define BOOT_FROM_SPI(x) (x == 0x32)
> +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
>
> #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(15))
> ? \
> 2 : 25000)
> @@ -182,9 +181,9 @@
> #define BOOT_DEV_SEL_OFFS 11
> #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_NAND 0x1
> -#define BOOT_FROM_UART 0x2
> -#define BOOT_FROM_SPI 0x3
> +#define BOOT_FROM_NAND(x) (x == 0x1)
> +#define BOOT_FROM_UART(x) (x == 0x2)
> +#define BOOT_FROM_SPI(x) (x == 0x3)
>
> #define CONFIG_SYS_TCLK2 /* 200MHz */
> #elif defined(CONFIG_ARMADA_XP)
> @@ -204,8 +203,8 @@
> #define BOOT_DEV_SEL_OFFS 5
> #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_UART 0x2
> -#define BOOT_FROM_SPI 0x3
> +#define BOOT_FROM_UART(x) (x == 0x2)
> +#define BOOT_FROM_SPI(x) (x == 0x3)
>
> #define CONFIG_SYS_TCLK25000 /* 250MHz */
> #endif
> --
> 2.20.1
>
>
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote: > Boot configuration stored in EXT_CSC register is completely ignored by > BootROM: > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/ > > Reflect this eMMC booting in documentation and in the code. > > Martin, can you test this patch series if SPL and main U-Boot is loaded > from the same eMMC HW partition? > boot0: u-boot Works fine, no issues. boot0: zeroed boot1: u-boot user: zeroed It succeeds, eventually... == BootROM - 1.73 Booting from MMC BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | | 0| 3 | SATA0 | | 1| 0 | SGMII1 | | 2| 5 | PCIe1 | | 3| 5 | USB3 HOST1 | | 4| 5 | PCIe2 | | 5| 0 | SGMII2 | High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from MMC1 ERROR: Invalid kwbimage v1 mmc_load_image_raw_sector: mmc block read error spl: mmc: wrong boot mode Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... Timeout waiting card ready BootROM: Image checksum verification PASSED U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) Core: 38 devices, 22 uclasses, devicetree: separate MMC: mv_sdh: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment Model: SolidRun Clearfog A1 Board: SolidRun Clearfog Pro Net: Warning: ethernet@7 (eth1) using random MAC address - 12:07:8b:f9:7a:6f eth1: ethernet@7 Warning: ethernet@3 (eth2) using random MAC address - ee:ed:f3:bb:c2:af , eth2: ethernet@3 Warning: ethernet@34000 (eth3) using random MAC address - ae:34:b9:bb:28:c6 , eth3: ethernet@34000 Hit any key to stop autoboot: 0 => == Between "Returning to BootROM" and "Timeout waiting card ready" takes around 315 seconds. That's long enough that I thought it had hung completely and I only noticed it continue because I left it running while working on something else. I tried several things to reduce this timeout, including reverting to the "non-removable" dts for shdci, but nothing seems to affect it. When bootloader is stored on Boot 0, then SPL should take care of > loading and executing main U-Boot. When it is stored on Boot 1 or User > Data then SPL should return back to BootROM and let BootROM to load and > execute main U-Boot. > > Pali Rohár (2): > tools: kwboot: Fix MMC HW boot partitions info > arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition > > arch/arm/mach-mvebu/Kconfig | 1 + > arch/arm/mach-mvebu/spl.c | 13 +++-- > tools/kwboot.c | 6 +++--- > 3 files changed, 11 insertions(+), 9 deletions(-) > > -- > 2.20.1 > >
Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros
On Sunday 05 March 2023 00:06:05 Martin Rowe wrote: > On Sat, 4 Mar 2023 at 11:20, Pali Rohár wrote: > > > On Saturday 04 March 2023 11:50:34 Pali Rohár wrote: > > > Disassembling A385 BootROM binary reveal how BootROM interprets strapping > > > pins for Boot Device Mode. All possible options are: > > > > > > 0x00..0x07 -> Parallel NOR > > > 0x08..0x15 -> Parallel NAND > > > 0x16..0x17 -> Parallel NOR > > > 0x18..0x25 -> Parallel NAND > > > 0x26..0x27 -> SPI NAND > > > 0x28..0x29 -> UART xmodem > > > 0x2a..0x2b -> SATA > > > 0x2c..0x2d -> PCI Express > > > 0x2e..0x2f -> Parallel NOR > > > 0x30..0x31 -> SD / eMMC > > > 0x32..0x39 -> SPI NOR > > > 0x3a..0x3c -> Parallel NOR > > > 0x3d..0x3e -> UART debug console > > > 0x3f -> Invalid > > > > Clearfog has 5-bit DIP switch and seems that it is directly mapped to > > the Boot Device mode with most significant bit of boot mode pulled to > > high (sixth bit not present on the switch) and flipped second, third and > > fifth bits of the boot mode. > > > > Based on documentation Clearfog DIP switch should be set to 11100 for > > SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, > > which is hex 0x2a --> matches A385 SATA boot mode. > > > > The Clearfog schematics indicate the switch is internally pulled to 0x36 / > 110110. 110110 XOR 11100 = 101010 = 0x2a. The math checks out and > corresponds to the documented modes as well as the enumeration I did a few > years ago: > 0 nothing [0x36] > 1 nothing [0x37] > 00010 SPI [0x34] (documented SPI) > 00011 SPI [0x35] > 00100 SPI [0x32] > 00101 SPI [0x33] > 00110 MMC (Card did not respond to voltage select!) [0x30] > 00111 MMC [0x31] (documented SD/eMMC) > 01000 nothing [0x3e] > 01001 UART [0x3f] (documented UART) > 01010 NOR [0x3c] > 01011 nothing [0x3d] > 01100 NOR [0x3a] > 01101 NOR [0x3b] > 01110 nothing [0x38] > 0 nothing [0x39] > 1 nothing [0x26] > 10001 nothing [0x27] > 10010 NAND [0x24] > 10011 NAND [0x25] > 10100 NAND [0x22] > 10101 NAND [0x23] > 10110 NAND [0x20] > 10111 NAND [0x21] > 11000 NOR [0x2e] > 11001 nothing [0x2f] > 11010 PEX0 (00) [0x2c] > 11011 PEX0 (1A) [0x2d] > 11100 nothing [0x2a] (I don't think I had a SATA card attached, but this is > documented SATA) > 11101 nothing [0x2b] > 0 nothing [0x28] > 1 nothing [0x29] > Where "nothing" indicates no BootROM output > > > > Can somebody check if UART debug console boot mode works on Clearfog? > > It is boot mode when BootROM enters into simple debug console with few > > commands. Via kwboot it is possible to enter into this mode (it sends > > magic sequence) but from this information it looks like that it should > > be possible also without magic sequence, just by configuring boot mode. > > > > I didn't know about this before. I tried with the magic sequence and it > works (though it needs the A38x output workaround mentioned here [1]. The > boot mode is the one set by 0x3d / 01 or 0x3e / 10, right? > 0x3d: 01 XOR 110110 = 01011 > 0x3e: 10 XOR 110110 = 01000 > Neither of those gives an interactive serial console, and even if the > output workaround is entered there is never anything that appears in the > console. It doesn't even echo the data I type in. > > [1] https://manpages.debian.org/testing/u-boot-tools/kwboot.1.en.html > Different options for the same boot source use different configuration of the source. E.g. different MPP pins or different ECC NAND schema, ... It is hardcoded in the BootROM but figure it out is kind hard (executable code refers to the data blocks). 0x28 and 0x3d should use UART0, while 0x29 and 0x3e UART1. This explains why 0x30 MMC does not work for you and 0x31 MMC works. There is erratum Ref #: FE-482008 that boot option 0x27 is not supported and erratum Ref #: FE-9360355 that boot option 0x28 is non functional. UART1 as boot source is completely undocumented and I suspect that because there is errata for 0x28 (UART0), UART in normal mode is somehow completely broken in BootROM. You wrote that UART debug console mode does not work, so maybe it just proves brokenness and reason why it is undocumented. I have not fully understood BootROM code, I was just able to decode tables and functions which read strapping pins and decide which boot code calls. Magic sequence for putting into UART debug console is triggered independently of the strapping pins and (my) workaround with rewriting variable stored in L2/SRAM is always needed when on default location is stored valid image. Also sending magic sequence is not simple because if too many bytes are send then magic sequence cause buffer overflow in the BootROM and CPU reset occurs. So if magic sequence is working for you via kwboot then I'm happy as I when I wrote that kwboot code it was too fragile to stabilize it. Anyway, I see that BootROM debug console has undocumented command 't' which listen for a short period for the UART magic pattern -- either xmodem or debug console. So maybe via this
Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros
On Sat, 4 Mar 2023 at 11:20, Pali Rohár wrote: > On Saturday 04 March 2023 11:50:34 Pali Rohár wrote: > > Disassembling A385 BootROM binary reveal how BootROM interprets strapping > > pins for Boot Device Mode. All possible options are: > > > > 0x00..0x07 -> Parallel NOR > > 0x08..0x15 -> Parallel NAND > > 0x16..0x17 -> Parallel NOR > > 0x18..0x25 -> Parallel NAND > > 0x26..0x27 -> SPI NAND > > 0x28..0x29 -> UART xmodem > > 0x2a..0x2b -> SATA > > 0x2c..0x2d -> PCI Express > > 0x2e..0x2f -> Parallel NOR > > 0x30..0x31 -> SD / eMMC > > 0x32..0x39 -> SPI NOR > > 0x3a..0x3c -> Parallel NOR > > 0x3d..0x3e -> UART debug console > > 0x3f -> Invalid > > Clearfog has 5-bit DIP switch and seems that it is directly mapped to > the Boot Device mode with most significant bit of boot mode pulled to > high (sixth bit not present on the switch) and flipped second, third and > fifth bits of the boot mode. > > Based on documentation Clearfog DIP switch should be set to 11100 for > SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, > which is hex 0x2a --> matches A385 SATA boot mode. > The Clearfog schematics indicate the switch is internally pulled to 0x36 / 110110. 110110 XOR 11100 = 101010 = 0x2a. The math checks out and corresponds to the documented modes as well as the enumeration I did a few years ago: 0 nothing [0x36] 1 nothing [0x37] 00010 SPI [0x34] (documented SPI) 00011 SPI [0x35] 00100 SPI [0x32] 00101 SPI [0x33] 00110 MMC (Card did not respond to voltage select!) [0x30] 00111 MMC [0x31] (documented SD/eMMC) 01000 nothing [0x3e] 01001 UART [0x3f] (documented UART) 01010 NOR [0x3c] 01011 nothing [0x3d] 01100 NOR [0x3a] 01101 NOR [0x3b] 01110 nothing [0x38] 0 nothing [0x39] 1 nothing [0x26] 10001 nothing [0x27] 10010 NAND [0x24] 10011 NAND [0x25] 10100 NAND [0x22] 10101 NAND [0x23] 10110 NAND [0x20] 10111 NAND [0x21] 11000 NOR [0x2e] 11001 nothing [0x2f] 11010 PEX0 (00) [0x2c] 11011 PEX0 (1A) [0x2d] 11100 nothing [0x2a] (I don't think I had a SATA card attached, but this is documented SATA) 11101 nothing [0x2b] 0 nothing [0x28] 1 nothing [0x29] Where "nothing" indicates no BootROM output > Can somebody check if UART debug console boot mode works on Clearfog? > It is boot mode when BootROM enters into simple debug console with few > commands. Via kwboot it is possible to enter into this mode (it sends > magic sequence) but from this information it looks like that it should > be possible also without magic sequence, just by configuring boot mode. > I didn't know about this before. I tried with the magic sequence and it works (though it needs the A38x output workaround mentioned here [1]. The boot mode is the one set by 0x3d / 01 or 0x3e / 10, right? 0x3d: 01 XOR 110110 = 01011 0x3e: 10 XOR 110110 = 01000 Neither of those gives an interactive serial console, and even if the output workaround is entered there is never anything that appears in the console. It doesn't even echo the data I type in. [1] https://manpages.debian.org/testing/u-boot-tools/kwboot.1.en.html > > Note that Boot Device Mode Options in A38x Hardware Specifications is > > incomplete. > > > > Signed-off-by: Pali Rohár > > --- > > arch/arm/mach-mvebu/include/mach/soc.h | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h > b/arch/arm/mach-mvebu/include/mach/soc.h > > index aa42db36a1ee..698b70339436 100644 > > --- a/arch/arm/mach-mvebu/include/mach/soc.h > > +++ b/arch/arm/mach-mvebu/include/mach/soc.h > > @@ -160,11 +160,14 @@ > > #define BOOT_DEV_SEL_OFFS4 > > #define BOOT_DEV_SEL_MASK(0x3f << BOOT_DEV_SEL_OFFS) > > > > -#define BOOT_FROM_NAND(x)(x == 0x0A) > > -#define BOOT_FROM_SATA(x)(x == 0x2A) > > -#define BOOT_FROM_UART(x)(x == 0x28) > > -#define BOOT_FROM_SPI(x) (x == 0x32) > > +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || > x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) > > +#define BOOT_FROM_NAND(x)((x >= 0x08 && x <= 0x15) || (x >= 0x18 && > x <= 0x25)) > > +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) > > +#define BOOT_FROM_UART(x)(x == 0x28 || x == 0x29) > > +#define BOOT_FROM_SATA(x)(x == 0x2A || x == 0x2B) > > +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) > > #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) > > +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39) > > > > #define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) > ? \ > >2 : 25000) > > -- > > 2.20.1 > > >
Re: [PATCH 3/6] clk: Fix error handling in clk_get_parent()
On 3/4/23 15:46, Michal Suchánek wrote:
On Sat, Mar 04, 2023 at 01:58:17PM -0600, Samuel Holland wrote:
On 2/20/23 04:39, Michal Suchánek wrote:
On Sun, Feb 19, 2023 at 11:59:36PM -0600, Samuel Holland wrote:
Do not return both NULL and error pointers. The function is only
documented as returning error pointers.
Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
Signed-off-by: Samuel Holland
---
drivers/clk/clk-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 78299dbceb2..5bce976b060 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -490,7 +490,7 @@ struct clk *clk_get_parent(struct clk *clk)
debug("%s(clk=%p)\n", __func__, clk);
if (!clk_valid(clk))
- return NULL;
+ return ERR_PTR(-ENODEV);
pdev = dev_get_parent(clk->dev);
if (!pdev)
Do we really need this?
Who cares about the distinction?
Just returning NULL on any error makes the code so much simpler and
easier to understand.
I'm fine with returning only NULL, or only ERR_PTR(-ENODEV) as done
later in the function, but returning both makes the error handling in
callers more complicated for no benefit. It sounds like you would prefer
I change the later ERR_PTR(-ENODEV) to NULL instead of this change? I
can do that for v2.
I think NULL is easier to check, and so long as there is no meaningful
distinction between ERR_PTR and NULL we should converge towards NULL as
the single error return value.
The only issue I can see is if you have e.g. an I2C clock and you need to
examine the register to determine the parent and the slave doesn't respond.
Is the distinction between "I have no parent" and "I have a parent
but I don't know which" meaningful? Linux uses one return because parents
must be determined at probe time. I'm fine with making this return NULL on
error; this should be uncommon enough that we can recommend dev_err()
reporting in the driver.
--Sean
Re: [PATCH 3/6] clk: Fix error handling in clk_get_parent()
On Sat, Mar 04, 2023 at 01:58:17PM -0600, Samuel Holland wrote:
> On 2/20/23 04:39, Michal Suchánek wrote:
> > On Sun, Feb 19, 2023 at 11:59:36PM -0600, Samuel Holland wrote:
> >> Do not return both NULL and error pointers. The function is only
> >> documented as returning error pointers.
> >>
> >> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> >> Signed-off-by: Samuel Holland
> >> ---
> >>
> >> drivers/clk/clk-uclass.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> >> index 78299dbceb2..5bce976b060 100644
> >> --- a/drivers/clk/clk-uclass.c
> >> +++ b/drivers/clk/clk-uclass.c
> >> @@ -490,7 +490,7 @@ struct clk *clk_get_parent(struct clk *clk)
> >>
> >>debug("%s(clk=%p)\n", __func__, clk);
> >>if (!clk_valid(clk))
> >> - return NULL;
> >> + return ERR_PTR(-ENODEV);
> >>
> >>pdev = dev_get_parent(clk->dev);
> >>if (!pdev)
> >
> > Do we really need this?
> >
> > Who cares about the distinction?
> >
> > Just returning NULL on any error makes the code so much simpler and
> > easier to understand.
>
> I'm fine with returning only NULL, or only ERR_PTR(-ENODEV) as done
> later in the function, but returning both makes the error handling in
> callers more complicated for no benefit. It sounds like you would prefer
> I change the later ERR_PTR(-ENODEV) to NULL instead of this change? I
> can do that for v2.
I think NULL is easier to check, and so long as there is no meaningful
distinction between ERR_PTR and NULL we should converge towards NULL as
the single error return value.
Thanks
Michal
Re: [PATCH 1/6] clk: Handle error pointers in clk_valid()
On Sat, Mar 04, 2023 at 01:54:12PM -0600, Samuel Holland wrote:
> On 2/20/23 13:42, Michal Suchánek wrote:
> > On Mon, Feb 20, 2023 at 10:57:17AM -0500, Sean Anderson wrote:
> >>
> >> On 2/20/23 05:46, Michal Suchánek wrote:
> >>> On Sun, Feb 19, 2023 at 11:59:34PM -0600, Samuel Holland wrote:
> Some clk uclass functions, such as devm_clk_get() and clk_get_parent(),
> return error pointers. clk_valid() should not consider these pointers
> to be valid.
>
> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> Signed-off-by: Samuel Holland
> ---
>
> include/clk.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/clk.h b/include/clk.h
> index d91285235f7..4acb878ec6d 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -671,7 +671,7 @@ static inline bool clk_dev_binded(struct clk *clk)
> */
> static inline bool clk_valid(struct clk *clk)
> {
> -return clk && !!clk->dev;
> +return clk && !IS_ERR(clk) && !!clk->dev;
> }
> int soc_clk_dump(void);
> >>>
> >>> Maybe it would be better to avoid the error pointers instead, there
> >>> should not be that many places where they are returned.
> >>
> >> This not quite the right way to phrase this. Instead, I would ask: where
> >> are places where the return value is not checked correctly? It's perfectly
> >
> > Pretty much everywhere where clk_get_parent is used outside of core code
> > absolutely no error checking is done.
>
> There are 105 uses of ERR_PTR in drivers/clk, mostly in CCF clock
> registration functions. There is also devm_clk_get() with about 30
> callers. Those mostly seem to have reasonable error checking; the error
> pointer ends up as the driver probe function's return value via PTR_ERR.
Yes, there are too many. clk_valid should check both.
Reviewed-by: Michal Suchánek
Thanks
Michal
Re: [PATCH 4/6] clk: Fix rate caching in clk_get_parent_rate()
On 2/20/23 10:11, Sean Anderson wrote:
> On 2/20/23 00:59, Samuel Holland wrote:
>> clk_get_rate() can return an error value. Recompute the rate if the
>> cached value is an error value.
>>
>> Fixes: 4aa78300a025 ("dm: clk: Define clk_get_parent_rate() for clk
>> operations")
>> Signed-off-by: Samuel Holland
>> ---
>>
>> drivers/clk/clk-uclass.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>> index 5bce976b060..9d052e5a814 100644
>> --- a/drivers/clk/clk-uclass.c
>> +++ b/drivers/clk/clk-uclass.c
>> @@ -520,7 +520,8 @@ ulong clk_get_parent_rate(struct clk *clk)
>> return -ENOSYS;
>> /* Read the 'rate' if not already set or if proper flag set*/
>> - if (!pclk->rate || pclk->flags & CLK_GET_RATE_NOCACHE)
>> + if (!pclk->rate || IS_ERR_VALUE(pclk->rate) ||
>> + pclk->flags & CLK_GET_RATE_NOCACHE)
>> pclk->rate = clk_get_rate(pclk);
>> return pclk->rate;
>
> The correct fix here is
>
> /* Read the 'rate' if not already set or if proper flag set*/
> if (!pclk->rate || pclk->flags & CLK_GET_RATE_NOCACHE) {
> rate = clk_get_rate(pclk);
> if (!IS_ERR_VALUE(rate))
> pclk->rate = rate;
> }
>
> return rate;
>
> No point caching errors.
Good point. I will do this for v2.
Regards,
Samuel
Re: [PATCH 3/6] clk: Fix error handling in clk_get_parent()
On 2/20/23 04:39, Michal Suchánek wrote:
> On Sun, Feb 19, 2023 at 11:59:36PM -0600, Samuel Holland wrote:
>> Do not return both NULL and error pointers. The function is only
>> documented as returning error pointers.
>>
>> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
>> Signed-off-by: Samuel Holland
>> ---
>>
>> drivers/clk/clk-uclass.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>> index 78299dbceb2..5bce976b060 100644
>> --- a/drivers/clk/clk-uclass.c
>> +++ b/drivers/clk/clk-uclass.c
>> @@ -490,7 +490,7 @@ struct clk *clk_get_parent(struct clk *clk)
>>
>> debug("%s(clk=%p)\n", __func__, clk);
>> if (!clk_valid(clk))
>> -return NULL;
>> +return ERR_PTR(-ENODEV);
>>
>> pdev = dev_get_parent(clk->dev);
>> if (!pdev)
>
> Do we really need this?
>
> Who cares about the distinction?
>
> Just returning NULL on any error makes the code so much simpler and
> easier to understand.
I'm fine with returning only NULL, or only ERR_PTR(-ENODEV) as done
later in the function, but returning both makes the error handling in
callers more complicated for no benefit. It sounds like you would prefer
I change the later ERR_PTR(-ENODEV) to NULL instead of this change? I
can do that for v2.
Regards,
Samuel
Re: [PATCH 1/6] clk: Handle error pointers in clk_valid()
On 2/20/23 13:42, Michal Suchánek wrote:
> On Mon, Feb 20, 2023 at 10:57:17AM -0500, Sean Anderson wrote:
>>
>> On 2/20/23 05:46, Michal Suchánek wrote:
>>> On Sun, Feb 19, 2023 at 11:59:34PM -0600, Samuel Holland wrote:
Some clk uclass functions, such as devm_clk_get() and clk_get_parent(),
return error pointers. clk_valid() should not consider these pointers
to be valid.
Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
Signed-off-by: Samuel Holland
---
include/clk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/clk.h b/include/clk.h
index d91285235f7..4acb878ec6d 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -671,7 +671,7 @@ static inline bool clk_dev_binded(struct clk *clk)
*/
static inline bool clk_valid(struct clk *clk)
{
- return clk && !!clk->dev;
+ return clk && !IS_ERR(clk) && !!clk->dev;
}
int soc_clk_dump(void);
>>>
>>> Maybe it would be better to avoid the error pointers instead, there
>>> should not be that many places where they are returned.
>>
>> This not quite the right way to phrase this. Instead, I would ask: where
>> are places where the return value is not checked correctly? It's perfectly
>
> Pretty much everywhere where clk_get_parent is used outside of core code
> absolutely no error checking is done.
There are 105 uses of ERR_PTR in drivers/clk, mostly in CCF clock
registration functions. There is also devm_clk_get() with about 30
callers. Those mostly seem to have reasonable error checking; the error
pointer ends up as the driver probe function's return value via PTR_ERR.
>> fine to pass NULL or uninitialized clocks to other clock functions, but it's
>> not OK to ignore errors.
>
> Is there some documentation on what is the distinction, specifically?
>
> If there isn't it's meaningless and NULL can be returned on error
> simplifying the code, thinking about the code, debugging, pretty much
> everything.
What should I do for v2? Keep this patch? Convert clk_get_parent() to
return NULL instead of ERR_PTR, and hope nobody uses clk_valid() on the
pointer returned from devm_clk_get()?
Regards,
Samuel
Re: [PATCH 1/1] api: move API related config options into submenu
On Fri, Mar 03, 2023 at 11:31:22PM +0100, Heinrich Schuchardt wrote: > Kconfig settings that are related to the API for standalone applications > should be in the API sub-menu and not on the top level. > > CONFIG_STANDALONE_LOAD_ADDR is only relevant if standalone example > applications are built. > > Signed-off-by: Heinrich Schuchardt > --- > Kconfig | 8 > api/Kconfig | 11 ++- > 2 files changed, 10 insertions(+), 9 deletions(-) Did you put this through CI? It's possible that some envs don't do "loadaddr=CONFIG_STANDALONE_LOAD_ADDR" and not enable API stuff anymore, but I think that's why I did what I did when migrating. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/44] More tidy-ups of Kconfig options
On Wed, Feb 22, 2023 at 09:33:41AM -0700, Simon Glass wrote: > This series was split out of the old 'split config' splc series. It > contains clean-up patches which do not depend on split config. > > This is available at u-boot-dm/spld-working > > The size changes look pretty good: https://paste.debian.net/1271742/ > > The remaining patches will move into a new 'splg' series (G for Good). > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=341504=* > > Changes in v5: > - Fix reply typo > - Change approach and expand notes after more investigation > - Drop FSL_ISBC_KEY_EXT patch as it changes the size > - Drop PHY_CADENCE_SIERRA patch as it changes the size > > Changes in v4: > - Avoid use of def_bool > - Modify to get rid of def_bool > - Adjust Kconfig ordering > - Just fix the typo > - Reduce and rename commit > - Reduce and rename commit > - Fix 'wanderboard' typo > - Reduce and rename commit > > Changes in v3: > - Add new patch to disable QFW bootmeth in SPL > - Move the option down to the non-SPL part of drivers/Makefile > - Correct 'VPL' typo > - Use a consistent format for the comment > - Fix a transitory build error with sandbox_spl > - Add a new patch to disallow commands in SPL > > Changes in v2: > - Rebase to previous series > > Simon Glass (44): > mtd: Drop unused kb9202_nand driver > mtd: Drop unused CONFIG_ONENAND_U_BOOT > sh4: Drop unused twl6030 driver > moveconfig: Update to detect / correct missing SPL Kconfigs > bootstd: Disable QFW bootmeth in SPL > Correct SPL uses of ARCH_MVEBU > Correct SPL uses of DISPLAY_AER_FULL > Correct SPL uses of MULTIPLEXER > Correct SPL use of PG_WCOM_UBOOT_UPDATE_SUPPORTED > Correct SPL uses of PHY_FIXED > boot: Add Kconfigs for BOOTMETH_VBE_REQUEST > Correct SPL use of DM_RNG > lib: Add a Kconfig for SPL_BZIP2 > moveconfig: Various minor improvements > sandbox: Expand size for VPL image > event: Add Kconfig options for SPL > bootstd: Correct 'VPL' typo > env: Avoid checking ENV_IS_IN when env disabled > env: Allow VPL environment to be nowhere > lib: Add VPL options for SHA1 and SHA256 > x86: Use string functions for all 32-bit builds > lib: Fix build condition for tiny-printf > sandbox: Tidy up RTC options > sandbox: Use the generic VPL option to enable VPL > sandbox: Tidy up I2C options > fixdep: Add support for VPL > fixdep: Refactor to make testing easier > fixdep: Add some tests for parse_config_line() > test: Add SPL versions of the TEST_KCONFIG options > lib: Add an SPL config for LIB_UUID > test: Tidy up sandbox handling in test-main > x86: Fix up use of X86_32BIT_INIT and X86_64 options > Add VPL options for BLOBLIST > rockchip: Avoid checking environment without ENV_SUPPORT > freescale: Drop old pre-DM_ETH code > imx: Use SATA instead of CMD_SATA > net: Add an SPL config for atheros > freescale: Fix odd use of ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE > serial: Support ns16550 driver in TPL > dm: Add a TPL symbol for simple-bus > x86: coral: Add missing TPL options > power: wandboard: Add a missing CONFIG > venice: Simplify conditions for network init > command: Don't allow commands in SPL I've applied almost all of this series. I've left the moveconfig.py stuff for now as I'm not sure it's useful until split config. I've followed up about the X86_32BIT_INIT patch as I do want to see that boot-tested, and I've left the ns16650 TPL patch as both that feel like "split config makes this an issue" rather than an issue we have today and fwiw, the dependencies are wrong in that there's no TPL for omap2 which I didn't reply directly to, I only noticed as reviewing the series locally before merging. -- Tom signature.asc Description: PGP signature
[PATCH u-boot-mvebu] ddr: marvell: a38x: Remove unused file seq_exec.h
DDR code does not use seq_exec.h, so remove it. Signed-off-by: Pali Rohár --- drivers/ddr/marvell/a38x/ddr3_init.h | 1 - drivers/ddr/marvell/a38x/seq_exec.h | 64 2 files changed, 65 deletions(-) delete mode 100644 drivers/ddr/marvell/a38x/seq_exec.h diff --git a/drivers/ddr/marvell/a38x/ddr3_init.h b/drivers/ddr/marvell/a38x/ddr3_init.h index 055516b67e9c..f41a732e9a37 100644 --- a/drivers/ddr/marvell/a38x/ddr3_init.h +++ b/drivers/ddr/marvell/a38x/ddr3_init.h @@ -9,7 +9,6 @@ #include "ddr_ml_wrapper.h" #include "mv_ddr_plat.h" -#include "seq_exec.h" #include "ddr3_logging_def.h" #include "ddr3_training_hw_algo.h" #include "ddr3_training_ip.h" diff --git a/drivers/ddr/marvell/a38x/seq_exec.h b/drivers/ddr/marvell/a38x/seq_exec.h deleted file mode 100644 index fe0cb8f75df2.. -- 2.20.1
Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros
On Saturday 04 March 2023 11:50:34 Pali Rohár wrote: > Disassembling A385 BootROM binary reveal how BootROM interprets strapping > pins for Boot Device Mode. All possible options are: > > 0x00..0x07 -> Parallel NOR > 0x08..0x15 -> Parallel NAND > 0x16..0x17 -> Parallel NOR > 0x18..0x25 -> Parallel NAND > 0x26..0x27 -> SPI NAND > 0x28..0x29 -> UART xmodem > 0x2a..0x2b -> SATA > 0x2c..0x2d -> PCI Express > 0x2e..0x2f -> Parallel NOR > 0x30..0x31 -> SD / eMMC > 0x32..0x39 -> SPI NOR > 0x3a..0x3c -> Parallel NOR > 0x3d..0x3e -> UART debug console > 0x3f -> Invalid Clearfog has 5-bit DIP switch and seems that it is directly mapped to the Boot Device mode with most significant bit of boot mode pulled to high (sixth bit not present on the switch) and flipped second, third and fifth bits of the boot mode. Based on documentation Clearfog DIP switch should be set to 11100 for SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, which is hex 0x2a --> matches A385 SATA boot mode. Can somebody check if UART debug console boot mode works on Clearfog? It is boot mode when BootROM enters into simple debug console with few commands. Via kwboot it is possible to enter into this mode (it sends magic sequence) but from this information it looks like that it should be possible also without magic sequence, just by configuring boot mode. > Note that Boot Device Mode Options in A38x Hardware Specifications is > incomplete. > > Signed-off-by: Pali Rohár > --- > arch/arm/mach-mvebu/include/mach/soc.h | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h > b/arch/arm/mach-mvebu/include/mach/soc.h > index aa42db36a1ee..698b70339436 100644 > --- a/arch/arm/mach-mvebu/include/mach/soc.h > +++ b/arch/arm/mach-mvebu/include/mach/soc.h > @@ -160,11 +160,14 @@ > #define BOOT_DEV_SEL_OFFS4 > #define BOOT_DEV_SEL_MASK(0x3f << BOOT_DEV_SEL_OFFS) > > -#define BOOT_FROM_NAND(x)(x == 0x0A) > -#define BOOT_FROM_SATA(x)(x == 0x2A) > -#define BOOT_FROM_UART(x)(x == 0x28) > -#define BOOT_FROM_SPI(x) (x == 0x32) > +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || x == > 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) > +#define BOOT_FROM_NAND(x)((x >= 0x08 && x <= 0x15) || (x >= 0x18 && x <= > 0x25)) > +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) > +#define BOOT_FROM_UART(x)(x == 0x28 || x == 0x29) > +#define BOOT_FROM_SATA(x)(x == 0x2A || x == 0x2B) > +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) > #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) > +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39) > > #define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ >2 : 25000) > -- > 2.20.1 >
[PATCH RFC u-boot-mvebu 6/6] arm: mvebu: Define all options for AXP BOOT_FROM_* macros
Definitions are according to the MV78460 Hardware Specifications. Signed-off-by: Pali Rohár --- arch/arm/mach-mvebu/include/mach/soc.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 75fe785932c2..49b4c5c7b4d2 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -213,8 +213,12 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS) +#define BOOT_FROM_NOR(x) (x == 0x0) +#define BOOT_FROM_NAND(x) (x == 0x1) #define BOOT_FROM_UART(x) (x == 0x2) #define BOOT_FROM_SPI(x) (x == 0x3) +#define BOOT_FROM_PEX(x) (x == 0x4) +#define BOOT_FROM_SATA(x) (x == 0x5) #define CONFIG_SYS_TCLK25000 /* 250MHz */ #endif -- 2.20.1
[PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are: 0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete. Signed-off-by: Pali Rohár --- arch/arm/mach-mvebu/include/mach/soc.h | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index aa42db36a1ee..698b70339436 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS) -#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) +#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 && x <= 0x25)) +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39) #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 2 : 25000) -- 2.20.1
[PATCH RFC u-boot-mvebu 5/6] arm: mvebu: Define all BOOTROM_ERR_MODE_* macros
A385 BootROM fills into bits [31:28] of register 0x182d0 tracing value, which represents in which state BootROM currently is. BootROM fills one of the possible values: 0x2 (CPU initialization), 0x3 (UART detection), 0x6 (UART booting), 0x8 (PCI Express booting), 0x9 (parallel or SPI NOR booting), 0xA (parallel or SPI NAND booting), 0xB (SATA booting) and 0xE (SD / eMMC booting). Meaning of these values matches TRACE_* macros from Marvell soc_spec.h file: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/soc_spec.h Signed-off-by: Pali Rohár --- arch/arm/mach-mvebu/include/mach/soc.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 698b70339436..75fe785932c2 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -128,7 +128,14 @@ #define BOOTROM_ERR_REG(MVEBU_REGISTER(0x182d0)) #define BOOTROM_ERR_MODE_OFFS 28 #define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS) +#define BOOTROM_ERR_MODE_MAIN 0x2 +#define BOOTROM_ERR_MODE_EXEC 0x3 #define BOOTROM_ERR_MODE_UART 0x6 +#define BOOTROM_ERR_MODE_PEX 0x8 +#define BOOTROM_ERR_MODE_NOR 0x9 +#define BOOTROM_ERR_MODE_NAND 0xA +#define BOOTROM_ERR_MODE_SATA 0xB +#define BOOTROM_ERR_MODE_MMC 0xE #define BOOTROM_ERR_CODE_OFFS 0 #define BOOTROM_ERR_CODE_MASK (0xf << BOOTROM_ERR_CODE_OFFS) -- 2.20.1
[PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one
macro. And also allows to extend other BOOT_FROM_* macros for other
variants.
Signed-off-by: Pali Rohár
---
arch/arm/mach-mvebu/cpu.c | 16 +---
arch/arm/mach-mvebu/include/mach/soc.h | 25 -
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index daa84c03fcdc..cb3f3afad269 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -98,24 +98,26 @@ u32 get_boot_device(void)
val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
- switch (boot_device) {
#ifdef BOOT_FROM_NAND
- case BOOT_FROM_NAND:
+ if (BOOT_FROM_NAND(boot_device))
return BOOT_DEVICE_NAND;
#endif
#ifdef BOOT_FROM_MMC
- case BOOT_FROM_MMC:
- case BOOT_FROM_MMC_ALT:
+ if (BOOT_FROM_MMC(boot_device))
return BOOT_DEVICE_MMC1;
#endif
- case BOOT_FROM_UART:
+#ifdef BOOT_FROM_UART
+ if (BOOT_FROM_UART(boot_device))
return BOOT_DEVICE_UART;
+#endif
#ifdef BOOT_FROM_SATA
- case BOOT_FROM_SATA:
+ if (BOOT_FROM_SATA(boot_device))
return BOOT_DEVICE_SATA;
#endif
- case BOOT_FROM_SPI:
+#ifdef BOOT_FROM_SPI
+ if (BOOT_FROM_SPI(boot_device))
return BOOT_DEVICE_SPI;
+#endif
default:
return BOOT_DEVICE_BOOTROM;
};
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index 5fdce8fe4e7e..aa42db36a1ee 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -143,8 +143,8 @@
#define BOOT_DEV_SEL_OFFS 3
#define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30
-#define BOOT_FROM_SPI 0x38
+#define BOOT_FROM_UART(x) (x == 0x30)
+#define BOOT_FROM_SPI(x) (x == 0x38)
#define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(20)) ? \
2 : 16600)
@@ -160,12 +160,11 @@
#define BOOT_DEV_SEL_OFFS 4
#define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A
-#define BOOT_FROM_SATA 0x2A
-#define BOOT_FROM_UART 0x28
-#define BOOT_FROM_SPI 0x32
-#define BOOT_FROM_MMC 0x30
-#define BOOT_FROM_MMC_ALT 0x31
+#define BOOT_FROM_NAND(x) (x == 0x0A)
+#define BOOT_FROM_SATA(x) (x == 0x2A)
+#define BOOT_FROM_UART(x) (x == 0x28)
+#define BOOT_FROM_SPI(x) (x == 0x32)
+#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(15)) ? \
2 : 25000)
@@ -182,9 +181,9 @@
#define BOOT_DEV_SEL_OFFS 11
#define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1
-#define BOOT_FROM_UART 0x2
-#define BOOT_FROM_SPI 0x3
+#define BOOT_FROM_NAND(x) (x == 0x1)
+#define BOOT_FROM_UART(x) (x == 0x2)
+#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK2 /* 200MHz */
#elif defined(CONFIG_ARMADA_XP)
@@ -204,8 +203,8 @@
#define BOOT_DEV_SEL_OFFS 5
#define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2
-#define BOOT_FROM_SPI 0x3
+#define BOOT_FROM_UART(x) (x == 0x2)
+#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK25000 /* 250MHz */
#endif
--
2.20.1
[PATCH RFC u-boot-mvebu 2/6] arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant
A385 BootROM treats strapping configuration 0x22 as SPI-NAND. So remove incorrect definition 0x22 as SATA. SATA on A385 has configuration 0x2A. Signed-off-by: Pali Rohár --- arch/arm/mach-mvebu/cpu.c | 1 - arch/arm/mach-mvebu/include/mach/soc.h | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index c187bbede722..daa84c03fcdc 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -112,7 +112,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA: - case BOOT_FROM_SATA_ALT: return BOOT_DEVICE_SATA; #endif case BOOT_FROM_SPI: diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index e559d9f9791e..5fdce8fe4e7e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -161,9 +161,8 @@ #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS) #define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x22 +#define BOOT_FROM_SATA 0x2A #define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SATA_ALT 0x2A #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31 -- 2.20.1
[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Improve code for checking strapping pins which specifies boot mode source. Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore. Also could you check if SATA booting is still working correctly? Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete). Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch. Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros arch/arm/mach-mvebu/cpu.c | 20 ++--- arch/arm/mach-mvebu/include/mach/soc.h | 41 -- 2 files changed, 35 insertions(+), 26 deletions(-) -- 2.20.1
[PATCH RFC u-boot-mvebu 1/6] arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant
A385 BootROM treats strapping configuration 0x3f as invalid. When booting
fails (e.g. because of invalid configuration) then BootROM fallbacks to
UART booting.
Detecting BootROM fallback to UART booting is implemented in U-Boot since
commit 2fd4284051e3 ("ARM: mach-mvebu: handle fall-back to UART boot").
So there is no need to define BOOT_FROM_UART_ALT constant and special
handling for it anymore, remove it.
This change effectively revers commit f3a88e2ca17a ("arm: mvebu: fix boot
from UART on ClearFog Base").
Signed-off-by: Pali Rohár
---
arch/arm/mach-mvebu/cpu.c | 3 ---
arch/arm/mach-mvebu/include/mach/soc.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 018a3614d4dd..c187bbede722 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -109,9 +109,6 @@ u32 get_boot_device(void)
return BOOT_DEVICE_MMC1;
#endif
case BOOT_FROM_UART:
-#ifdef BOOT_FROM_UART_ALT
- case BOOT_FROM_UART_ALT:
-#endif
return BOOT_DEVICE_UART;
#ifdef BOOT_FROM_SATA
case BOOT_FROM_SATA:
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index 3b9618852c6d..e559d9f9791e 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -164,7 +164,6 @@
#define BOOT_FROM_SATA 0x22
#define BOOT_FROM_UART 0x28
#define BOOT_FROM_SATA_ALT 0x2A
-#define BOOT_FROM_UART_ALT 0x3f
#define BOOT_FROM_SPI 0x32
#define BOOT_FROM_MMC 0x30
#define BOOT_FROM_MMC_ALT 0x31
--
2.20.1
[PATCH u-boot-mvebu] arm: mvebu: Cleanup get_boot_device() code
Show correct information in debug() output and use correct names for variables.
No functional change.
Signed-off-by: Pali Rohár
---
arch/arm/mach-mvebu/cpu.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 97154aaa2a7e..018a3614d4dd 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -67,6 +67,8 @@ u32 get_boot_device(void)
{
u32 val;
u32 boot_device;
+ u32 boot_err_mode;
+ u32 boot_err_code;
/*
* First check, if UART boot-mode is active. This can only
@@ -74,9 +76,9 @@ u32 get_boot_device(void)
* MSB marks if the UART mode is active.
*/
val = readl(BOOTROM_ERR_REG);
- boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
- debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
- if (boot_device == BOOTROM_ERR_MODE_UART)
+ boot_err_mode = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
+ debug("BOOTROM_ERR_REG=0x%08x boot_err_mode=0x%x\n", val,
boot_err_mode);
+ if (boot_err_mode == BOOTROM_ERR_MODE_UART)
return BOOT_DEVICE_UART;
#ifdef CONFIG_ARMADA_38X
@@ -84,8 +86,9 @@ u32 get_boot_device(void)
* If the bootrom error code contains any other than zeros it's an
* error condition and the bootROM has fallen back to UART boot
*/
- boot_device = (val & BOOTROM_ERR_CODE_MASK) >> BOOTROM_ERR_CODE_OFFS;
- if (boot_device)
+ boot_err_code = (val & BOOTROM_ERR_CODE_MASK) >> BOOTROM_ERR_CODE_OFFS;
+ debug("boot_err_code=0x%x\n", boot_err_code);
+ if (boot_err_code)
return BOOT_DEVICE_UART;
#endif
--
2.20.1
[PATCH RFC u-boot-mvebu 2/2] arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition
Boot configuration stored in EXT_CSC register is completely ignored by
BootROM. So we should skip it too in SPL, to load proper U-Boot from the
same location as from which was loaded SPL by BootROM.
BootROM tries to boot from partitions in this order: Boot 0, Boot 1, User
Data Partition.
In case SPL+U-Boot is stored on Boot 1 or User Data partition then SPL code
skips MMC booting (nothing is valid on Boot 0) and fallback to BootROM
booting which loads proper U-Boot from correct partition (Boot 1 or User
Data).
Implement it via setting CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG and
CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION to fixed values for mvebu.
Fixes: 2f27db2fbd6e ("arm: mvebu: spl: Load proper U-Boot from selected eMMC
boot partition")
Signed-off-by: Pali Rohár
---
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/spl.c | 13 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index ba40c59f4a95..dfc50ec91350 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -336,6 +336,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
imply SPL_LIBDISK_SUPPORT
imply SPL_MMC
select SUPPORT_EMMC_BOOT if SPL_MMC
+ select SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG if SPL_MMC
select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC
select SPL_BOOTROM_SUPPORT
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 6b8c72a71dab..b20eac3dcd38 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -34,8 +34,7 @@
/*
* When loading U-Boot via SPL from eMMC, the kwbimage main header is stored at
- * sector 0 and either on HW boot partition or on data partition. Choice of HW
- * partition depends on what is configured in eMMC EXT_CSC register.
+ * sector 0 of Boot 0 HW partition.
* When loading U-Boot via SPL from SD card, the kwbimage main header is stored
* at sector 1.
* Therefore MBR/GPT partition booting, fixed sector number and fixed eMMC HW
@@ -46,6 +45,7 @@
* Runtime mvebu SPL sector calculation code expects:
* - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0
* - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0
+ * - CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION=1
*/
#ifdef CONFIG_SPL_MMC
#ifdef CONFIG_SYS_MMCSD_FS_BOOT
@@ -54,11 +54,12 @@
#ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
#error CONFIG_SYS_MMCSD_FS_BOOT_PARTITION is unsupported
#endif
-#ifdef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
-#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG is unsupported
+#ifndef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
+#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG must be enabled for
SD/eMMC boot support
#endif
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
-#error CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION is unsupported
+#if !defined(CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION) || \
+CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION != 1
+#error CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION must be set to 1
#endif
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
--
2.20.1
[PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
Boot configuration stored in EXT_CSC register is completely ignored by BootROM: https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/ Reflect this eMMC booting in documentation and in the code. Martin, can you test this patch series if SPL and main U-Boot is loaded from the same eMMC HW partition? When bootloader is stored on Boot 0, then SPL should take care of loading and executing main U-Boot. When it is stored on Boot 1 or User Data then SPL should return back to BootROM and let BootROM to load and execute main U-Boot. Pali Rohár (2): tools: kwboot: Fix MMC HW boot partitions info arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition arch/arm/mach-mvebu/Kconfig | 1 + arch/arm/mach-mvebu/spl.c | 13 +++-- tools/kwboot.c | 6 +++--- 3 files changed, 11 insertions(+), 9 deletions(-) -- 2.20.1
[PATCH RFC u-boot-mvebu 1/2] tools: kwboot: Fix MMC HW boot partitions info
Boot configuration stored in EXT_CSC register is completely ignored by BootROM.
Fixes: fa03279e198d ("tools: kwboot: Add image type documentation")
Signed-off-by: Pali Rohár
---
tools/kwboot.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7c666486f31f..1844d7291fe0 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -106,9 +106,9 @@
* 1024 bytes long sector sizes and also can be changed at runtime.
*
* For MMC-compatible devices, image can be stored at offset 0 or at offset
- * 2 MB. If MMC device supports HW boot partitions then image must be stored
- * on the HW partition as is configured in the EXT_CSC register (it can be
- * either boot or user data).
+ * 2 MB. If MMC device supports HW boot partitions then image is read from
+ * partitions in following order: Boot 0, Boot 1, User Data partition.
+ * Boot configuration stored in EXT_CSC register is completely ignored.
*
* Note that source address for SDIO image is stored in byte unit, like for
* any other images (except SATA). Marvell Functional Specifications for
--
2.20.1
Re: [PATCH] doc: Add documentation for CZ.NIC Turris routers
Ping again? Or silence means no care from CZ.NIC side? On Tuesday 31 January 2023 19:53:23 Pali Rohár wrote: > Gentle ping? Does CZ.NIC care about Turris routers and u-boot support? > > On Monday 07 November 2022 21:28:31 Pali Rohár wrote: > > Hello! Just beware of these two commits which renamed files mentioned in > > patch > > https://source.denx.de/u-boot/u-boot/-/commit/87ac4b4b4ca5f00e2ddcdac41c9dc691ab2aecf1 > > https://source.denx.de/u-boot/u-boot/-/commit/d8fa0a76681af3ecea3941f5c743332dd76c7543 > > So documentation in v2 now needs to be updated to address those renamed > > files. > > > > On Tuesday 01 November 2022 23:10:00 Josef Schlehofer wrote: > > > Hey Pali, > > > > > > Thanks for letting me know about it! > > > > > > I will prepare new version tomorrow and send it as v2. > > > > > > Regards, > > > Josef > > > > > > On 01. 11. 22 23:07, Pali Rohár wrote: > > > > + Lukáš and Josef from CZ.NIC > > > > > > > > On Monday 03 October 2022 22:25:05 Pali Rohár wrote: > > > > > + Štěpán from CZ.NIC. Please look at the Heinrich comments below and > > > > > prepare a new version with fixes... I will let it to you right now. > > > > > > > > > > On Monday 26 September 2022 13:30:02 Heinrich Schuchardt wrote: > > > > > > On 9/23/22 13:36, Pali Rohár wrote: > > > > > > > This patch adds a new documentation for all released CZ.NIC > > > > > > > Turris routers. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > --- > > > > > > >doc/board/CZ.NIC/index.rst | 9 + > > > > > > >doc/board/CZ.NIC/turris.rst | 323 > > > > > > > > > > > > > >doc/board/index.rst | 1 + > > > > > > >3 files changed, 333 insertions(+) > > > > > > >create mode 100644 doc/board/CZ.NIC/index.rst > > > > > > >create mode 100644 doc/board/CZ.NIC/turris.rst > > > > > > > > > > > > > > diff --git a/doc/board/CZ.NIC/index.rst > > > > > > > b/doc/board/CZ.NIC/index.rst > > > > > > > new file mode 100644 > > > > > > > index ..19ec6af2f389 > > > > > > > --- /dev/null > > > > > > > +++ b/doc/board/CZ.NIC/index.rst > > > > > > > @@ -0,0 +1,9 @@ > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > + > > > > > > > +CZ.NIC > > > > > > > +== > > > > > > > + > > > > > > > +.. toctree:: > > > > > > > + :maxdepth: 2 > > > > > > > + > > > > > > > + turris > > > > > > > diff --git a/doc/board/CZ.NIC/turris.rst > > > > > > > b/doc/board/CZ.NIC/turris.rst > > > > > > > new file mode 100644 > > > > > > > index ..b82dea4e0786 > > > > > > > --- /dev/null > > > > > > > +++ b/doc/board/CZ.NIC/turris.rst > > > > > > > @@ -0,0 +1,323 @@ > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > + > > > > > > > +CZ.NIC Turris routers > > > > > > > += > > > > > > > + > > > > > > > +CZ.NIC develops open source Turris routers: Turris 1.0, Turris > > > > > > > 1.1, Turris Omnia, and Turris Mox. This document describes a > > > > > > > U-Boot deployment (compilation, flashing, resetting) on these > > > > > > > routers. > > > > > > > + > > > > > > > +Turris 1.x > > > > > > > +-- > > > > > > > + > > > > > > > +Turris 1.0 and Turris 1.1 boards contain Freescale P2020 CPUs > > > > > > > with two PowerPC e500v2 cores which BootROM (or CPU directly) can > > > > > > > load and boot U-Boot bootloader from various locations. For > > > > > > > Turris 1.x boards, only Flash NOR and SD cards are supported. > > > > > > > P2020 CPU cannot download bootloader via UART like other > > > > > > > platforms. For loading the U-Boot bootloader from Flash NOR > > > > > > > (which is the default) it is needed to put SW1 dip switches on > > > > > > > the board to position 11001010, and for the SD card to position > > > > > > > 01101010 respectively. Note that this controls the source from > > > > > > > which P2020 loads U-Boot, not from which U-Boot loads boot script > > > > > > > or kernel. Boot procedures from SD card and Flash NOR are > > > > > > > different, hence U-Boot binaries need to be compiled differently. > > > > > > > + > > > > > > > +More information about Turris 1.x, including the complete HW > > > > > > > documentation (together with the SW1 dip switch options) and > > > > > > > Altium design files, can be found on: > > > > > > > https://docs.turris.cz/hw/turris-1x/turris-1x/ > > > > > > > + > > > > > > > +Compilation > > > > > > > +^^^ > > > > > > > + > > > > > > > +To compile the Flash NOR version, run:: > > > > > > > + > > > > > > > +$ make CROSS_COMPILE=powerpc-linux-gnuspe- > > > > > > > turris_1x_nor_defconfig > > > > > > > +$ make CROSS_COMPILE=powerpc-linux-gnuspe- > > > > > > > u-boot-with-dtb.bin > > > > > > > + > > > > > > > +It will produce a flashable binary file ``u-boot-with-dtb.bin``. > > > > > > > + > > > > > > > +To compile the SD card version, run:: > > > > > > > + > > > > > > > +$ make CROSS_COMPILE=powerpc-linux-gnuspe- > > > > > > >
