Re: [U-Boot] [PATCH v5 3/8] x86: slimbootloader: Add memory configuration
On Mon, Jul 22, 2019 at 11:33 PM Andy Shevchenko wrote: > > On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden wrote: > > > > Slim Bootloader provides memory map info thru its HOB list pointer. > > Configure memory size and relocation memory from the HOB data, and > > provide e820 entries as well. > > - Get memory size from the memory map info hob > > - Set ram top for U-Boot relocation lower than 4GB > > - Provide e820 entries from the memory map info hob > > > +++ b/arch/x86/cpu/slimbootloader/dram.c > > sdram.c is more common name in the sources AFAICS. Looks we have both sdram.c and dram.c :) [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/8] x86: Add new slimbootloader CPU type
On Mon, Jul 22, 2019 at 11:14 PM Andy Shevchenko wrote: > > On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden wrote: > > > > This slimbootloader cpu type is to enable U-Boot as a payload which > > cpu -> CPU > > > runs on top of Slim Bootloader(https://github.com/slimbootloader). > > The Slim Bootloader is designed with multi-stage architecture for > > the execution from reset vector to OS booting, and supports qemu, > > qemu -> QEMU > > > Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP > > (https://github.com/IntelFsp) for silicon initialization including > > CAR and memory initialization. > > The Slim Bootloader generates new HOB(Hand Off Block) which are > > serial port info, memory map info, performance data info and so on, > > and passes it to a Payload. U-Boot as a payload will use these HOB > > information for basic initialization such as serial console. > > > +config SYS_SLIMBOOTLOADER > > > + bool > > + default y > > def_bool y ? Good catch. I checked other x86 Kconfig files, and seems we should just remove this line, and specify SYS_SLIMBOOTLOADER in the board defconfig file. > > > + imply SYS_NS16550 > > + imply AHCI_PCI > > + imply SCSI > > + imply SCSI_AHCI > > + imply MMC > > + imply MMC_PCI > > + imply MMC_SDHCI > > + imply MMC_SDHCI_SDMA > > + imply USB > > + imply USB_EHCI_HCD > > + imply USB_XHCI_HCD > > + imply USB_STORAGE > > + imply USB_KEYBOARD > > + imply E1000 > > > + imply RTL8169 > > Is it part of SoC? I dunno we have Realtek inside, usually either > Intel or Synopsys. > I think the following should be moved to board/intel/slimbootloader/Kconfig::BOARD_SPECIFIC_OPTIONS: imply USB_STORAGE imply USB_KEYBOARD imply RTL8169 > > -#ifndef CONFIG_HAVE_FSP > > +#if !defined(CONFIG_HAVE_FSP) && !defined(CONFIG_SYS_SLIMBOOTLOADER) > > > -#ifdef CONFIG_HAVE_FSP > > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER) > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] net: fec: add fuse check
> Subject: Re: [U-Boot] [PATCH 4/4] net: fec: add fuse check
>
> On Thu, Jul 18, 2019 at 10:24 PM Peng Fan wrote:
> >
> > Add fuse check for fec. If the fuse indicate the module not work in
> > the SoC, let's fail the initialization.
>
> "indicates the module will not work"
Fix in V2.
>
> >
> > Signed-off-by: Peng Fan
> > ---
> > drivers/net/fec_mxc.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index
> > d7c080943a..602b655455 100644
> > --- a/drivers/net/fec_mxc.c
> > +++ b/drivers/net/fec_mxc.c
> > @@ -1185,6 +1185,13 @@ int fecmxc_initialize_multi(bd_t *bd, int
> > dev_id, int phy_id, uint32_t addr) #endif
> > int ret;
> >
> > + if (IS_ENABLED(CONFIG_IMX_MODULE_FUSE)) {
> > + if (enet_fused(addr)) {
> > + printf("Ethernet@0x%x is fused, disable it\n",
> > + addr);
>
> Please reword this. Something like "SoC fuse indicates Ethernet@0x%x is
> unavailable."
Fix in v2.
>
> > + return -ENODEV;
> > + }
> > + }
> > +
> > #ifdef CONFIG_FEC_MXC_MDIO_BASE
> > /*
> > * The i.MX28 has two ethernet interfaces, but they are not
> equal.
> > @@ -1323,6 +1330,14 @@ static int fecmxc_probe(struct udevice *dev)
> > uint32_t start;
> > int ret;
> >
> > + if (IS_ENABLED(CONFIG_IMX_MODULE_FUSE)) {
> > + if (enet_fused((u32)priv->eth)) {
> > + printf("Ethernet@0x%x is fused, disable it\n",
>
> Same.
Fix in V2.
Thanks,
Peng.
>
> > + (u32)priv->eth);
> > + return -ENODEV;
> > + }
> > + }
> > +
> > if (IS_ENABLED(CONFIG_IMX8)) {
> > ret = clk_get_by_name(dev, "ipg", >ipg_clk);
> > if (ret < 0) {
> > --
> > 2.16.4
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >
> s.denx.de%2Flistinfo%2Fu-bootdata=02%7C01%7Cpeng.fan%40nxp.co
> m%7C
> >
> e6ff4f39e3c4498965d308d70f1dabd6%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C
> >
> 0%7C0%7C636994492429835169sdata=IM0QAmsTXC%2BnpZOqtGW
> XGslK2VD5n7n
> > pehzJ6i1XqIo%3Dreserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: sdhci: don't invert present state bits
The MMC_CAP_CD_ACTIVE_HIGH flag describes the physical card-detect
signal logic level. Applying it to bits in SDHCI_PRESENT_STATE makes no
sense.
Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
Cc: T Karthik Reddy
Cc: Michal Simek
Signed-off-by: Baruch Siach
---
This patch applies on top of http://patchwork.ozlabs.org/patch/1135213/.
---
drivers/mmc/sdhci.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 17a28181fcca..654931a82f54 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -664,7 +664,7 @@ int sdhci_get_cd(struct udevice *dev)
{
struct mmc *mmc = mmc_get_mmc_dev(dev);
struct sdhci_host *host = mmc->priv;
- int value;
+ int __maybe_unused value;
/* If nonremovable, assume that the card is always present. */
if (mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
@@ -682,12 +682,9 @@ int sdhci_get_cd(struct udevice *dev)
return value;
}
#endif
- value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
+
+ return !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
(SDHCI_CARD_PRESENT | SDHCI_CARD_DETECT_PIN_LEVEL));
- if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
- return !value;
- else
- return value;
}
const struct dm_mmc_ops sdhci_ops = {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] doc: bindings: Add binding for register driven MDIO muxes
On Tue, Jul 16, 2019 at 3:22 AM Alex Marginean wrote: > > This binding documents two properties that describe the registers used to > perform MUX selection. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] net: phy: fix switch vendor name
On Tue, Jul 9, 2019 at 6:25 PM Anatolij Gustschin wrote: > > Fix vendor name in MV88E61xx option description. > > Signed-off-by: Anatolij Gustschin Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] net: phy: mv88e61xx: register phy_driver struct for 88E6071
On Tue, Jul 9, 2019 at 6:25 PM Anatolij Gustschin wrote:
>
> Support probing and init for 88E6071 switch.
>
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/net/phy/mv88e61xx.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index 165bc261e4..d827ecc1bc 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -1116,10 +1116,22 @@ static struct phy_driver mv88e609x_driver = {
> .shutdown = _shutdown,
> };
>
> +static struct phy_driver mv88e6071_driver = {
> + .name = "Marvell MV88E6071",
Is it really just the 6071? What about all the other ones mentioned in
the Kconfig?
> + .uid = 0x1410db0,
> + .mask = 0xfff0,
> + .features = PHY_BASIC_FEATURES | SUPPORTED_MII,
> + .probe = mv88e61xx_probe,
> + .config = mv88e61xx_phy_config,
> + .startup = mv88e61xx_phy_startup,
> + .shutdown = _shutdown,
> +};
> +
> int phy_mv88e61xx_init(void)
> {
> phy_register(_driver);
> phy_register(_driver);
> + phy_register(_driver);
>
> return 0;
> }
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] net: phy: mv88E61xx: add config option for mv88E6071 support
On Tue, Jul 9, 2019 at 6:26 PM Anatolij Gustschin wrote: > > MV88E61XX_88E6020_FAMILY option enables support for switch > devices 6250/6220/6020/6070/6071. > > Signed-off-by: Anatolij Gustschin > --- > drivers/net/phy/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig > index 2a3da068c9..097b499ba3 100644 > --- a/drivers/net/phy/Kconfig > +++ b/drivers/net/phy/Kconfig > @@ -50,6 +50,13 @@ config MV88E61XX_SWITCH > > if MV88E61XX_SWITCH > > +config MV88E61XX_88E6020_FAMILY > + bool "Marvell MV88E6020 family support." > + help > + The driver supports 6172/6176/6240/6352 devices in the > + default configuration. Select this option to enable support > + for 6250/6220/6020/6070/6071 switches. Is there a rhyme or reason to the model numbers here? This option seems oddly named, especially since the help doesn't have the model numbers in numerical order. Can you make it a choice instead? E.g... choice prompt "MV88E61XX device selection" default MV88E61XX_88E6172 config MV88E61XX_88E6020 bool "MV88E6020" [ ... ] config MV88E61XX_88E6172 bool "MV88E6172" [ ... ] config MV88E61XX_88E6352 bool "MV88E6352" help The driver supports 6172/6176/6240/6352 devices in the default configuration. Select the device to enable support for (e.g. 6020/6070/6071/6220/6250). endchoice > + > config MV88E61XX_CPU_PORT > int "CPU Port" > > -- > 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] net: phy: mv88E61xx: fix ENERGY_DET init for mv88E6071
On Tue, Jul 9, 2019 at 6:24 PM Anatolij Gustschin wrote:
>
> On mv88E6071 the 'EDet' field offset, width and sense control
> bits are different, adjust the driver to init the PHY control
> register as needed. This fixes not working link detection and
> tftp transfers.
Good grief... kind of obnoxious how much is changed seemingly
arbitrarily. Hmm. Not friendly to software.
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/net/phy/mv88e61xx.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index d38109b797..165bc261e4 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -119,16 +119,12 @@
>
> #define SERDES_REG_CTRL_1_FORCE_LINK BIT(10)
>
> -#define PHY_REG_CTRL1_ENERGY_DET_SHIFT 8
> -#define PHY_REG_CTRL1_ENERGY_DET_WIDTH 2
> -
> /* Field values */
> #define PORT_REG_CTRL_PSTATE_DISABLED 0
> #define PORT_REG_CTRL_PSTATE_FORWARD 3
>
> #define PHY_REG_CTRL1_ENERGY_DET_OFF 0
> #define PHY_REG_CTRL1_ENERGY_DET_SENSE_ONLY2
> -#define PHY_REG_CTRL1_ENERGY_DET_SENSE_XMIT3
>
> /* PHY Status Register */
> #define PHY_REG_STATUS1_SPEED 0xc000
> @@ -194,6 +190,9 @@ struct mv88e61xx_phy_priv {
> u16 port_stat_link_mask;
> u16 port_stat_dup_mask;
> u8 port_stat_speed_width;
> + u8 phy_ctrl1_en_det_shift;
> + u8 phy_ctrl1_en_det_width;
> + u8 phy_ctrl1_en_det_sense_xmit;
> u8 global1;
> u8 global2;
> };
> @@ -841,6 +840,7 @@ static int mv88e61xx_phy_enable(struct phy_device
> *phydev, u8 phy)
>
> static int mv88e61xx_phy_setup(struct phy_device *phydev, u8 phy)
> {
> + struct mv88e61xx_phy_priv *priv = phydev->priv;
> int val;
>
> /*
> @@ -850,9 +850,9 @@ static int mv88e61xx_phy_setup(struct phy_device *phydev,
> u8 phy)
> val = mv88e61xx_phy_read(phydev, phy, PHY_REG_CTRL1);
> if (val < 0)
> return val;
> - val = bitfield_replace(val, PHY_REG_CTRL1_ENERGY_DET_SHIFT,
> - PHY_REG_CTRL1_ENERGY_DET_WIDTH,
> - PHY_REG_CTRL1_ENERGY_DET_SENSE_XMIT);
> + val = bitfield_replace(val, priv->phy_ctrl1_en_det_shift,
> + priv->phy_ctrl1_en_det_width,
> + priv->phy_ctrl1_en_det_sense_xmit);
> val = mv88e61xx_phy_write(phydev, phy, PHY_REG_CTRL1, val);
> if (val < 0)
> return val;
> @@ -964,12 +964,18 @@ static int mv88e61xx_probe(struct phy_device *phydev)
> priv->port_stat_link_mask = BIT(11);
> priv->port_stat_dup_mask = BIT(10);
> priv->port_stat_speed_width = 2;
> + priv->phy_ctrl1_en_det_shift = 8;
> + priv->phy_ctrl1_en_det_width = 2;
> + priv->phy_ctrl1_en_det_sense_xmit = 3;
> break;
> case PORT_SWITCH_ID_6071:
> priv->port_count = 7;
> priv->port_stat_link_mask = BIT(12);
> priv->port_stat_dup_mask = BIT(9);
> priv->port_stat_speed_width = 1;
> + priv->phy_ctrl1_en_det_shift = 14;
> + priv->phy_ctrl1_en_det_width = 1;
> + priv->phy_ctrl1_en_det_sense_xmit = 1;
> break;
> default:
> free(priv);
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 2/4] net: macb: Fix check for little-endian system in gmac_configure_dma()
On Tue, Jul 23, 2019 at 8:55 AM Joe Hershberger wrote:
>
> On Mon, Jul 22, 2019 at 2:54 AM Anup Patel wrote:
> >
> > Instead of depending on CONFIG_SYS_LITTLE_ENDIAN, we check at runtime
> > whether underlying system is little-endian or big-endian. This way
> > we are not dependent on any U-Boot specific OR compiler specific macro
> > to check system endianness.
> >
> > Signed-off-by: Anup Patel
> > Reviewed-by: Bin Meng
> > Reviewed-by: Ramon Fried
> > ---
> > drivers/net/macb.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> > index 3db5597373..27a6c6db2b 100644
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -84,6 +84,8 @@ struct macb_dma_desc {
> > struct macb_device {
> > void*regs;
> >
> > + boolis_big_endian;
> > +
> > const struct macb_config *config;
> >
> > unsigned intrx_tail;
> > @@ -743,11 +745,10 @@ static void gmac_configure_dma(struct macb_device
> > *macb)
> > dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
> > dmacfg &= ~GEM_BIT(ENDIA_PKT);
> >
> > -#ifdef CONFIG_SYS_LITTLE_ENDIAN
> > - dmacfg &= ~GEM_BIT(ENDIA_DESC);
> > -#else
> > + if (macb->is_big_endian)
> > dmacfg |= GEM_BIT(ENDIA_DESC); /* CPU in big endian */
> > -#endif
> > + else
> > + dmacfg &= ~GEM_BIT(ENDIA_DESC);
> >
> > dmacfg &= ~GEM_BIT(ADDR64);
> > gem_writel(macb, DMACFG, dmacfg);
> > @@ -1221,6 +1222,9 @@ static int macb_eth_probe(struct udevice *dev)
> >
> > macb->regs = (void *)pdata->iobase;
> >
> > + macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678) ?
> > + true : false;
>
> You don't need the "? true : false". That's a no-op. Just assign the
> result of the comparison.
Sure, I will update.
>
> > +
> > macb->config = (struct macb_config *)dev_get_driver_data(dev);
> > if (!macb->config)
> > macb->config = _gem_config;
> > --
> > 2.17.1
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Thanks,
Anup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/4] net: macb: Extend MACB driver for SiFive Unleashed board
On Tue, Jul 23, 2019 at 8:54 AM Joe Hershberger wrote:
>
> On Mon, Jul 22, 2019 at 2:45 AM Anup Patel wrote:
> >
> > The SiFive MACB ethernet has a custom TX_CLK_SEL register to select
> > different TX clock for 1000mbps vs 10/100mbps.
> >
> > This patch adds SiFive MACB compatible string and extends the MACB
> > ethernet driver to change TX clock using TX_CLK_SEL register for
> > SiFive MACB.
> >
> > Signed-off-by: Anup Patel
> > Reviewed-by: Bin Meng
> > Reviewed-by: Ramon Fried
> > ---
> > drivers/net/macb.c | 71 +++---
> > 1 file changed, 54 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> > index 92ec05559b..3db5597373 100644
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -83,7 +83,8 @@ struct macb_dma_desc {
> >
> > struct macb_device {
> > void*regs;
> > - unsigned intdma_burst_length;
> > +
> > + const struct macb_config *config;
> >
> > unsigned intrx_tail;
> > unsigned inttx_head;
> > @@ -123,6 +124,8 @@ struct macb_device {
> >
> > struct macb_config {
> > unsigned intdma_burst_length;
> > +
> > + int (*clk_init)(struct udevice *dev, ulong
> > rate);
> > };
> >
> > #ifndef CONFIG_DM_ETH
> > @@ -483,21 +486,38 @@ static int macb_phy_find(struct macb_device *macb,
> > const char *name)
> > * when operation failed.
> > */
> > #ifdef CONFIG_DM_ETH
> > +static int macb_sifive_clk_init(struct udevice *dev, ulong rate)
> > +{
> > + fdt_addr_t addr;
> > + void *gemgxl_regs;
> > +
> > + addr = dev_read_addr_index(dev, 1);
> > + if (addr == FDT_ADDR_T_NONE)
> > + return -ENODEV;
> > +
> > + gemgxl_regs = (void __iomem *)addr;
> > + if (!gemgxl_regs)
> > + return -ENODEV;
> > +
> > + /*
> > +* SiFive GEMGXL TX clock operation mode:
> > +*
> > +* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
> > +* and output clock on GMII output signal GTX_CLK
> > +* 1 = MII mode. Use MII input signal TX_CLK in TX logic
> > +*/
> > + writel(rate != 12500, gemgxl_regs);
> > + return 0;
> > +}
> > +
> > int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
> > {
> > #ifdef CONFIG_CLK
> > + struct macb_device *macb = dev_get_priv(dev);
> > struct clk tx_clk;
> > ulong rate;
> > int ret;
> >
> > - /*
> > -* "tx_clk" is an optional clock source for MACB.
> > -* Ignore if it does not exist in DT.
> > -*/
> > - ret = clk_get_by_name(dev, "tx_clk", _clk);
> > - if (ret)
> > - return 0;
> > -
> > switch (speed) {
> > case _10BASET:
> > rate = 250; /* 2.5 MHz */
> > @@ -513,6 +533,17 @@ int __weak macb_linkspd_cb(struct udevice *dev,
> > unsigned int speed)
> > return 0;
> > }
> >
> > + if (macb->config->clk_init)
> > + return macb->config->clk_init(dev, rate);
> > +
> > + /*
> > +* "tx_clk" is an optional clock source for MACB.
> > +* Ignore if it does not exist in DT.
> > +*/
> > + ret = clk_get_by_name(dev, "tx_clk", _clk);
> > + if (ret)
> > + return 0;
> > +
> > if (tx_clk.dev) {
> > ret = clk_set_rate(_clk, rate);
> > if (ret)
> > @@ -705,8 +736,9 @@ static void gmac_configure_dma(struct macb_device *macb)
> > dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
> > dmacfg |= GEM_BF(RXBS, buffer_size);
> >
> > - if (macb->dma_burst_length)
> > - dmacfg = GEM_BFINS(FBLDO, macb->dma_burst_length, dmacfg);
> > + if (macb->config->dma_burst_length)
> > + dmacfg = GEM_BFINS(FBLDO,
> > + macb->config->dma_burst_length, dmacfg);
> >
> > dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
> > dmacfg &= ~GEM_BIT(ENDIA_PKT);
> > @@ -1173,11 +1205,10 @@ static const struct macb_config default_gem_config
> > = {
> >
> > static int macb_eth_probe(struct udevice *dev)
> > {
> > - const struct macb_config *macb_config;
> > struct eth_pdata *pdata = dev_get_platdata(dev);
> > struct macb_device *macb = dev_get_priv(dev);
> > const char *phy_mode;
> > - __maybe_unused int ret;
> > + int ret;
> >
> > phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "phy-mode",
> >NULL);
> > @@ -1190,11 +1221,10 @@ static int macb_eth_probe(struct udevice *dev)
> >
> > macb->regs = (void *)pdata->iobase;
> >
> > - macb_config = (struct macb_config *)dev_get_driver_data(dev);
> > - if (!macb_config)
> > - macb_config = _gem_config;
> > +
Re: [U-Boot] [PATCH v2 1/6] net: phy: mv88e61xx: rework to enable detection of 88E6071 devices
On Mon, Jul 22, 2019 at 11:00 PM Joe Hershberger wrote:
>
> On Tue, Jul 9, 2019 at 6:23 PM Anatolij Gustschin wrote:
> >
> > Extend the driver to init switch register offsets from variables
> > instead of compile time macros and enable 88E6071 detection.
> > Ethernet transfer (e.g. tftp) does not work yet, so enable the
> > registration of the 'indirect mii' bus for easier PHY register
> > access by 'mii' command.
> >
> > Signed-off-by: Anatolij Gustschin
> > ---
> > drivers/net/phy/mv88e61xx.c | 95 +
> > 1 file changed, 76 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> > index c1e2860329..8f5da9486c 100644
> > --- a/drivers/net/phy/mv88e61xx.c
> > +++ b/drivers/net/phy/mv88e61xx.c
> > @@ -39,15 +39,12 @@
> >
> > #define PHY_AUTONEGOTIATE_TIMEOUT 5000
> >
> > -#define PORT_COUNT 11
> > -#define PORT_MASK ((1 << PORT_COUNT) - 1)
> > +#define PORT_MASK(port_count) ((1 << (port_count)) - 1)
> >
> > /* Device addresses */
> > #define DEVADDR_PHY(p) (p)
> > -#define DEVADDR_PORT(p)(0x10 + (p))
> > +#define DEVADDR_PORT(p)(priv->port_reg_base + (p))
>
> This is an obtuse macro. It should not reference a local variable
> internally. If you want to use priv, pass it as a parameter.
>
> > #define DEVADDR_SERDES 0x0F
> > -#define DEVADDR_GLOBAL_1 0x1B
> > -#define DEVADDR_GLOBAL_2 0x1C
> >
> > /* SMI indirection registers for multichip addressing mode */
> > #define SMI_CMD_REG0x00
> > @@ -188,11 +185,16 @@
> > #define PORT_SWITCH_ID_61760x1760
> > #define PORT_SWITCH_ID_62400x2400
> > #define PORT_SWITCH_ID_63520x3520
> > +#define PORT_SWITCH_ID_60710x0710
> >
> > struct mv88e61xx_phy_priv {
> > struct mii_dev *mdio_bus;
> > int smi_addr;
> > int id;
> > + int port_count;
> > + int port_reg_base;
> > + u8 global1;
> > + u8 global2;
>
> I think this could stand some commenting. global what? Why 2?
>
> > };
> >
> > static inline int smi_cmd(int cmd, int addr, int reg)
> > @@ -329,11 +331,12 @@ static int mv88e61xx_reg_write(struct phy_device
> > *phydev, int dev, int reg,
> >
> > static int mv88e61xx_phy_wait(struct phy_device *phydev)
> > {
> > + struct mv88e61xx_phy_priv *priv = phydev->priv;
> > int val;
> > u32 timeout = 100;
> >
> > do {
> > - val = mv88e61xx_reg_read(phydev, DEVADDR_GLOBAL_2,
> > + val = mv88e61xx_reg_read(phydev, priv->global2,
>
> Probably just use phydev->priv->global2 instead of the local variable.
>
> > GLOBAL2_REG_PHY_CMD);
> > if (val >= 0 && (val & SMI_BUSY) == 0)
> > return 0;
> > @@ -347,13 +350,15 @@ static int mv88e61xx_phy_wait(struct phy_device
> > *phydev)
> > static int mv88e61xx_phy_read_indirect(struct mii_dev *smi_wrapper, int
> > dev,
> > int devad, int reg)
> > {
> > + struct mv88e61xx_phy_priv *priv;
> > struct phy_device *phydev;
> > int res;
> >
> > phydev = (struct phy_device *)smi_wrapper->priv;
> > + priv = phydev->priv;
> >
> > /* Issue command to read */
> > - res = mv88e61xx_reg_write(phydev, DEVADDR_GLOBAL_2,
> > + res = mv88e61xx_reg_write(phydev, priv->global2,
> > GLOBAL2_REG_PHY_CMD,
> > smi_cmd_read(dev, reg));
> >
> > @@ -363,25 +368,27 @@ static int mv88e61xx_phy_read_indirect(struct mii_dev
> > *smi_wrapper, int dev,
> > return res;
> >
> > /* Read retrieved data */
> > - return mv88e61xx_reg_read(phydev, DEVADDR_GLOBAL_2,
> > + return mv88e61xx_reg_read(phydev, priv->global2,
> > GLOBAL2_REG_PHY_DATA);
> > }
> >
> > static int mv88e61xx_phy_write_indirect(struct mii_dev *smi_wrapper, int
> > dev,
> > int devad, int reg, u16 data)
> > {
> > + struct mv88e61xx_phy_priv *priv;
> > struct phy_device *phydev;
> > int res;
> >
> > phydev = (struct phy_device *)smi_wrapper->priv;
> > + priv = phydev->priv;
> >
> > /* Set the data to write */
> > - res = mv88e61xx_reg_write(phydev, DEVADDR_GLOBAL_2,
> > + res = mv88e61xx_reg_write(phydev, priv->global2,
> > GLOBAL2_REG_PHY_DATA, data);
> > if (res < 0)
> > return res;
> > /* Issue the write command */
> > - res = mv88e61xx_reg_write(phydev, DEVADDR_GLOBAL_2,
> > + res = mv88e61xx_reg_write(phydev, priv->global2,
> > GLOBAL2_REG_PHY_CMD,
> >
Re: [U-Boot] [PATCH v2 2/6] net: phy: mv88e61xx: add CPU port parameter init for 88E6071
On Tue, Jul 9, 2019 at 6:25 PM Anatolij Gustschin wrote:
>
> On 88E6071 chip the port status register bit field offsets
> for duplex and link bits differ. Extend the driver to use
> 88E6071 specific offset values. The width of bit fields for
> speed status differ, too. Adapt for proper port speed
> detection on 88E6071.
>
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/net/phy/mv88e61xx.c | 41 +
> 1 file changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index 8f5da9486c..d38109b797 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -85,9 +85,6 @@
> #define GLOBAL1_MON_CTRL_CPUDEST_SHIFT 4
> #define GLOBAL1_MON_CTRL_CPUDEST_WIDTH 4
>
> -#define PORT_REG_STATUS_LINK BIT(11)
> -#define PORT_REG_STATUS_DUPLEX BIT(10)
> -
> #define PORT_REG_STATUS_SPEED_SHIFT8
> #define PORT_REG_STATUS_SPEED_WIDTH2
Surprised this didn't go away.
> #define PORT_REG_STATUS_SPEED_10 0
> @@ -108,6 +105,7 @@
> #define PORT_REG_PHYS_CTRL_DUPLEX_VALUEBIT(3)
> #define PORT_REG_PHYS_CTRL_DUPLEX_FORCEBIT(2)
> #define PORT_REG_PHYS_CTRL_SPD1000 BIT(1)
> +#define PORT_REG_PHYS_CTRL_SPD100 BIT(0)
> #define PORT_REG_PHYS_CTRL_SPD_MASK(BIT(1) | BIT(0))
>
> #define PORT_REG_CTRL_PSTATE_SHIFT 0
> @@ -193,6 +191,9 @@ struct mv88e61xx_phy_priv {
> int id;
> int port_count;
> int port_reg_base;
> + u16 port_stat_link_mask;
> + u16 port_stat_dup_mask;
> + u8 port_stat_speed_width;
> u8 global1;
> u8 global2;
> };
> @@ -638,6 +639,7 @@ static int mv88e61xx_port_set_vlan(struct phy_device
> *phydev, u8 port,
>
> static int mv88e61xx_read_port_config(struct phy_device *phydev, u8 port)
> {
> + struct mv88e61xx_phy_priv *priv = phydev->priv;
> int res;
> int val;
> bool forced = false;
> @@ -645,7 +647,7 @@ static int mv88e61xx_read_port_config(struct phy_device
> *phydev, u8 port)
> val = mv88e61xx_port_read(phydev, port, PORT_REG_STATUS);
> if (val < 0)
> return val;
> - if (!(val & PORT_REG_STATUS_LINK)) {
> + if (!(val & priv->port_stat_link_mask)) {
> /* Temporarily force link to read port configuration */
> u32 timeout = 100;
> forced = true;
> @@ -668,7 +670,7 @@ static int mv88e61xx_read_port_config(struct phy_device
> *phydev, u8 port)
> res = -EIO;
> goto unforce;
> }
> - if (val & PORT_REG_STATUS_LINK)
> + if (val & priv->port_stat_link_mask)
> break;
> } while (--timeout);
>
> @@ -678,13 +680,13 @@ static int mv88e61xx_read_port_config(struct phy_device
> *phydev, u8 port)
> }
> }
>
> - if (val & PORT_REG_STATUS_DUPLEX)
> + if (val & priv->port_stat_dup_mask)
> phydev->duplex = DUPLEX_FULL;
> else
> phydev->duplex = DUPLEX_HALF;
>
> val = bitfield_extract(val, PORT_REG_STATUS_SPEED_SHIFT,
> - PORT_REG_STATUS_SPEED_WIDTH);
> + priv->port_stat_speed_width);
> switch (val) {
> case PORT_REG_STATUS_SPEED_1000:
> phydev->speed = SPEED_1000;
> @@ -717,6 +719,7 @@ unforce:
>
> static int mv88e61xx_fixed_port_setup(struct phy_device *phydev, u8 port)
> {
> + struct mv88e61xx_phy_priv *priv = phydev->priv;
> int val;
>
> val = mv88e61xx_port_read(phydev, port, PORT_REG_PHYS_CTRL);
> @@ -724,13 +727,19 @@ static int mv88e61xx_fixed_port_setup(struct phy_device
> *phydev, u8 port)
> return val;
>
> val &= ~(PORT_REG_PHYS_CTRL_SPD_MASK |
> -PORT_REG_PHYS_CTRL_FC_VALUE);
> - val |= PORT_REG_PHYS_CTRL_PCS_AN_EN |
> - PORT_REG_PHYS_CTRL_PCS_AN_RST |
> - PORT_REG_PHYS_CTRL_FC_FORCE |
> +PORT_REG_PHYS_CTRL_FC_VALUE |
> +PORT_REG_PHYS_CTRL_FC_FORCE);
> + val |= PORT_REG_PHYS_CTRL_FC_FORCE |
>PORT_REG_PHYS_CTRL_DUPLEX_VALUE |
> - PORT_REG_PHYS_CTRL_DUPLEX_FORCE |
> - PORT_REG_PHYS_CTRL_SPD1000;
> + PORT_REG_PHYS_CTRL_DUPLEX_FORCE;
> +
> + if (priv->id == PORT_SWITCH_ID_6071) {
> + val |= PORT_REG_PHYS_CTRL_SPD100;
> + } else {
> + val |= PORT_REG_PHYS_CTRL_PCS_AN_EN |
> + PORT_REG_PHYS_CTRL_PCS_AN_RST |
> + PORT_REG_PHYS_CTRL_SPD1000;
> + }
>
> if (port == CONFIG_MV88E61XX_CPU_PORT)
> val |= PORT_REG_PHYS_CTRL_LINK_VALUE |
> @@ -952,9 +961,15 @@ static int mv88e61xx_probe(struct phy_device *phydev)
>
Re: [U-Boot] [PATCH v2 1/6] net: phy: mv88e61xx: rework to enable detection of 88E6071 devices
On Tue, Jul 9, 2019 at 6:23 PM Anatolij Gustschin wrote:
>
> Extend the driver to init switch register offsets from variables
> instead of compile time macros and enable 88E6071 detection.
> Ethernet transfer (e.g. tftp) does not work yet, so enable the
> registration of the 'indirect mii' bus for easier PHY register
> access by 'mii' command.
>
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/net/phy/mv88e61xx.c | 95 +
> 1 file changed, 76 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index c1e2860329..8f5da9486c 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -39,15 +39,12 @@
>
> #define PHY_AUTONEGOTIATE_TIMEOUT 5000
>
> -#define PORT_COUNT 11
> -#define PORT_MASK ((1 << PORT_COUNT) - 1)
> +#define PORT_MASK(port_count) ((1 << (port_count)) - 1)
>
> /* Device addresses */
> #define DEVADDR_PHY(p) (p)
> -#define DEVADDR_PORT(p)(0x10 + (p))
> +#define DEVADDR_PORT(p)(priv->port_reg_base + (p))
This is an obtuse macro. It should not reference a local variable
internally. If you want to use priv, pass it as a parameter.
> #define DEVADDR_SERDES 0x0F
> -#define DEVADDR_GLOBAL_1 0x1B
> -#define DEVADDR_GLOBAL_2 0x1C
>
> /* SMI indirection registers for multichip addressing mode */
> #define SMI_CMD_REG0x00
> @@ -188,11 +185,16 @@
> #define PORT_SWITCH_ID_61760x1760
> #define PORT_SWITCH_ID_62400x2400
> #define PORT_SWITCH_ID_63520x3520
> +#define PORT_SWITCH_ID_60710x0710
>
> struct mv88e61xx_phy_priv {
> struct mii_dev *mdio_bus;
> int smi_addr;
> int id;
> + int port_count;
> + int port_reg_base;
> + u8 global1;
> + u8 global2;
I think this could stand some commenting. global what? Why 2?
> };
>
> static inline int smi_cmd(int cmd, int addr, int reg)
> @@ -329,11 +331,12 @@ static int mv88e61xx_reg_write(struct phy_device
> *phydev, int dev, int reg,
>
> static int mv88e61xx_phy_wait(struct phy_device *phydev)
> {
> + struct mv88e61xx_phy_priv *priv = phydev->priv;
> int val;
> u32 timeout = 100;
>
> do {
> - val = mv88e61xx_reg_read(phydev, DEVADDR_GLOBAL_2,
> + val = mv88e61xx_reg_read(phydev, priv->global2,
Probably just use phydev->priv->global2 instead of the local variable.
> GLOBAL2_REG_PHY_CMD);
> if (val >= 0 && (val & SMI_BUSY) == 0)
> return 0;
> @@ -347,13 +350,15 @@ static int mv88e61xx_phy_wait(struct phy_device *phydev)
> static int mv88e61xx_phy_read_indirect(struct mii_dev *smi_wrapper, int dev,
> int devad, int reg)
> {
> + struct mv88e61xx_phy_priv *priv;
> struct phy_device *phydev;
> int res;
>
> phydev = (struct phy_device *)smi_wrapper->priv;
> + priv = phydev->priv;
>
> /* Issue command to read */
> - res = mv88e61xx_reg_write(phydev, DEVADDR_GLOBAL_2,
> + res = mv88e61xx_reg_write(phydev, priv->global2,
> GLOBAL2_REG_PHY_CMD,
> smi_cmd_read(dev, reg));
>
> @@ -363,25 +368,27 @@ static int mv88e61xx_phy_read_indirect(struct mii_dev
> *smi_wrapper, int dev,
> return res;
>
> /* Read retrieved data */
> - return mv88e61xx_reg_read(phydev, DEVADDR_GLOBAL_2,
> + return mv88e61xx_reg_read(phydev, priv->global2,
> GLOBAL2_REG_PHY_DATA);
> }
>
> static int mv88e61xx_phy_write_indirect(struct mii_dev *smi_wrapper, int dev,
> int devad, int reg, u16 data)
> {
> + struct mv88e61xx_phy_priv *priv;
> struct phy_device *phydev;
> int res;
>
> phydev = (struct phy_device *)smi_wrapper->priv;
> + priv = phydev->priv;
>
> /* Set the data to write */
> - res = mv88e61xx_reg_write(phydev, DEVADDR_GLOBAL_2,
> + res = mv88e61xx_reg_write(phydev, priv->global2,
> GLOBAL2_REG_PHY_DATA, data);
> if (res < 0)
> return res;
> /* Issue the write command */
> - res = mv88e61xx_reg_write(phydev, DEVADDR_GLOBAL_2,
> + res = mv88e61xx_reg_write(phydev, priv->global2,
> GLOBAL2_REG_PHY_CMD,
> smi_cmd_write(dev, reg));
> if (res < 0)
> @@ -408,12 +415,14 @@ static int mv88e61xx_phy_write(struct phy_device
> *phydev, int phy,
>
> static int mv88e61xx_port_read(struct phy_device *phydev, u8 port, u8 reg)
> {
> + struct mv88e61xx_phy_priv *priv = phydev->priv;
Huh? When casually read, this seems useless.
Re: [U-Boot] [PATCH v3 9/9] Add support for the NXP LS1021A-TSN board
On Thu, Jul 18, 2019 at 4:36 PM Vladimir Oltean wrote: > > From: Jianchao Wang > > The LS1021A-TSN is a development board built by VVDN/Argonboards in > partnership with NXP. > > It features the LS1021A SoC and the first-generation SJA1105T Ethernet > switch for prototyping implementations of a subset of IEEE 802.1 TSN > standards. > > Supported boot media: microSD card (via SPL), QSPI flash. > > Rev. A of the board uses a Spansion S25FL512S_256K serial flash, which > is 64 MB in size and has an erase sector size of 256KB (therefore, > flashing the RCW would erase part of U-Boot). > > Rev. B and C of the board use a Spansion S25FL256S1 serial flash, which > is only 32 MB in size but has an erase sector size of 64KB (therefore > the RCW image can be flashed without erasing U-Boot). > > To avoid the problems above, the U-Boot base address has been selected > at 0x10 (the start of the 5th 256KB erase sector), which works for > all board revisions. Actually 0x4 would have been enough, but > 0x10 is common for all Layerscape devices. > > eTSEC3 is connecting directly to SJA1105 via an RGMII fixed-link, but > SJA1105 is currently not supported by uboot. Therefore, eTSEC3 is > disabled. > > Signed-off-by: Xiaoliang Yang > Signed-off-by: Mingkai Hu > Signed-off-by: Jianchao Wang > Signed-off-by: Changming Huang > Signed-off-by: Vladimir Oltean > > [Vladimir] Code taken from https://github.com/openil/u-boot (which > itself is mostly copied from ls1021a-iot) and adapted with the following > changes: > > - Add a008850 errata workaround > - Converted eTSEC, MMC to DM to avoid all build warnings > - Plugged in distro boot feature, including support for extlinux.conf > - Added defconfig for QSPI boot > - Added the board/freescale/ls1021atsn/README.rst for initial setup > - Increased CONFIG_SYS_MONITOR_LEN so that the SPL malloc pool does not > get overwritten during copying of the u-boot.bin payload from MMC to > DDR. Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] configs: ls1021atwr: Fix distro_bootcmd for QSPI boot
On Thu, Jul 18, 2019 at 4:37 PM Vladimir Oltean wrote: > > Due to a typo, "run qspi_bootcmd" and "env exists secureboot" got > concatenated instead of being separated by a semicolon. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] net: tsec: Change compatible strings to match Linux
On Thu, Jul 18, 2019 at 4:36 PM Vladimir Oltean wrote:
>
> In the case of the tsec network driver, so far there has been no
> mainline user of DM_ETH where the DT bindings get used.
>
> In the case of the mdio bus, it looks like the "fsl,tsec-mdio" string
> was made up for the documentation, but there is no mainline code that
> parses the "compatible" property anyway.
>
> In both cases, there are no DT blobs that contain the old strings.
>
> So change the documentation to "fsl,etsec2" for the Ethernet ports and
> "fsl,etsec2-mdio" for the MDIO buses, which are strings that Linux also
> uses, at least for LS1021A. More compatible strings can be added once
> other (PowerPC) SoCs are migrated to DM_ETH.
>
> The current ls1021a.dtsi doesn't match what was documented for the MDIO
> buses anyway (the "compatible" is "gianfar" currently). This will be
> fixed in the next patch.
>
> Fixes: 69a00875e3db ("doc: dt-bindings: Describe Freescale TSEC ethernet
> controller")
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Bin Meng
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] net: fec: add fuse check
On Thu, Jul 18, 2019 at 10:24 PM Peng Fan wrote:
>
> Add fuse check for fec. If the fuse indicate the module
> not work in the SoC, let's fail the initialization.
"indicates the module will not work"
>
> Signed-off-by: Peng Fan
> ---
> drivers/net/fec_mxc.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index d7c080943a..602b655455 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -1185,6 +1185,13 @@ int fecmxc_initialize_multi(bd_t *bd, int dev_id, int
> phy_id, uint32_t addr)
> #endif
> int ret;
>
> + if (IS_ENABLED(CONFIG_IMX_MODULE_FUSE)) {
> + if (enet_fused(addr)) {
> + printf("Ethernet@0x%x is fused, disable it\n", addr);
Please reword this. Something like "SoC fuse indicates Ethernet@0x%x
is unavailable."
> + return -ENODEV;
> + }
> + }
> +
> #ifdef CONFIG_FEC_MXC_MDIO_BASE
> /*
> * The i.MX28 has two ethernet interfaces, but they are not equal.
> @@ -1323,6 +1330,14 @@ static int fecmxc_probe(struct udevice *dev)
> uint32_t start;
> int ret;
>
> + if (IS_ENABLED(CONFIG_IMX_MODULE_FUSE)) {
> + if (enet_fused((u32)priv->eth)) {
> + printf("Ethernet@0x%x is fused, disable it\n",
Same.
> + (u32)priv->eth);
> + return -ENODEV;
> + }
> + }
> +
> if (IS_ENABLED(CONFIG_IMX8)) {
> ret = clk_get_by_name(dev, "ipg", >ipg_clk);
> if (ret < 0) {
> --
> 2.16.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 2/4] net: macb: Fix check for little-endian system in gmac_configure_dma()
On Mon, Jul 22, 2019 at 2:54 AM Anup Patel wrote:
>
> Instead of depending on CONFIG_SYS_LITTLE_ENDIAN, we check at runtime
> whether underlying system is little-endian or big-endian. This way
> we are not dependent on any U-Boot specific OR compiler specific macro
> to check system endianness.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
> drivers/net/macb.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 3db5597373..27a6c6db2b 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -84,6 +84,8 @@ struct macb_dma_desc {
> struct macb_device {
> void*regs;
>
> + boolis_big_endian;
> +
> const struct macb_config *config;
>
> unsigned intrx_tail;
> @@ -743,11 +745,10 @@ static void gmac_configure_dma(struct macb_device *macb)
> dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
> dmacfg &= ~GEM_BIT(ENDIA_PKT);
>
> -#ifdef CONFIG_SYS_LITTLE_ENDIAN
> - dmacfg &= ~GEM_BIT(ENDIA_DESC);
> -#else
> + if (macb->is_big_endian)
> dmacfg |= GEM_BIT(ENDIA_DESC); /* CPU in big endian */
> -#endif
> + else
> + dmacfg &= ~GEM_BIT(ENDIA_DESC);
>
> dmacfg &= ~GEM_BIT(ADDR64);
> gem_writel(macb, DMACFG, dmacfg);
> @@ -1221,6 +1222,9 @@ static int macb_eth_probe(struct udevice *dev)
>
> macb->regs = (void *)pdata->iobase;
>
> + macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678) ?
> + true : false;
You don't need the "? true : false". That's a no-op. Just assign the
result of the comparison.
> +
> macb->config = (struct macb_config *)dev_get_driver_data(dev);
> if (!macb->config)
> macb->config = _gem_config;
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/16] clk: gate: support sandbox
Introduce io_gate_val for sandbox clk gate test usage
Signed-off-by: Peng Fan
---
drivers/clk/clk-gate.c | 11 +++
include/linux/clk-provider.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index a3a1fdd3b2..70b8794554 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -55,7 +55,11 @@ static void clk_gate_endisable(struct clk *clk, int enable)
if (set)
reg |= BIT(gate->bit_idx);
} else {
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+ reg = gate->io_gate_val;
+#else
reg = readl(gate->reg);
+#endif
if (set)
reg |= BIT(gate->bit_idx);
@@ -86,7 +90,11 @@ int clk_gate_is_enabled(struct clk *clk)
dev_get_clk_ptr(clk->dev) : clk);
u32 reg;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+ reg = gate->io_gate_val;
+#else
reg = readl(gate->reg);
+#endif
/* if a set bit disables this clk, flip it before masking */
if (gate->flags & CLK_GATE_SET_TO_DISABLE)
@@ -128,6 +136,9 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
gate->reg = reg;
gate->bit_idx = bit_idx;
gate->flags = clk_gate_flags;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+ gate->io_gate_val = *(u32 *)reg;
+#endif
clk = >clk;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 32a777d86c..1e8183207d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -75,6 +75,9 @@ struct clk_gate {
void __iomem*reg;
u8 bit_idx;
u8 flags;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+ u32 io_gate_val;
+#endif
};
#define to_clk_gate(_clk) container_of(_clk, struct clk_gate, clk)
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 16/16] configs: sandbox: Enable composite clk
Enable composite clk for sandbox test Signed-off-by: Peng Fan --- configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index f9c9b19b6d..402c6d4e19 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -91,6 +91,7 @@ CONFIG_BOOTCOUNT_LIMIT=y CONFIG_DM_BOOTCOUNT=y CONFIG_DM_BOOTCOUNT_RTC=y CONFIG_CLK=y +CONFIG_CLK_COMPOSITE_CCF=y CONFIG_SANDBOX_CLK_CCF=y CONFIG_CPU=y CONFIG_DM_DEMO=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index 2429ae4621..610457e0aa 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -66,6 +66,7 @@ CONFIG_DEBUG_DEVRES=y CONFIG_ADC=y CONFIG_ADC_SANDBOX=y CONFIG_CLK=y +CONFIG_CLK_COMPOSITE_CCF=y CONFIG_SANDBOX_CLK_CCF=y CONFIG_CPU=y CONFIG_DM_DEMO=y -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/16] dm: clk: ignore default settings when node not valid
When the device not binded with a node, we need ignore
the parents and rate settings.
Cc: Simon Glass
Cc: Jagan Teki
Cc: Philipp Tomsich
Cc: Neil Armstrong
Cc: Andreas Dannenberg
Signed-off-by: Peng Fan
---
drivers/clk/clk-uclass.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 5acf186b01..39c6a97caa 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -283,6 +283,9 @@ int clk_set_defaults(struct udevice *dev)
{
int ret;
+ if (!dev_of_valid(dev))
+ return 0;
+
/* If this not in SPL and pre-reloc state, don't take any action. */
if (!(IS_ENABLED(CONFIG_SPL_BUILD) || (gd->flags & GD_FLG_RELOC)))
return 0;
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/16] clk: imx: gate2 add set rate
Add set rate for imx clk-gate2
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-gate2.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/imx/clk-gate2.c b/drivers/clk/imx/clk-gate2.c
index 571be32088..1b9db6e791 100644
--- a/drivers/clk/imx/clk-gate2.c
+++ b/drivers/clk/imx/clk-gate2.c
@@ -60,7 +60,18 @@ static int clk_gate2_disable(struct clk *clk)
return 0;
}
+static ulong clk_gate2_set_rate(struct clk *clk, ulong rate)
+{
+ struct clk *parent = clk_get_parent(clk);
+
+ if (parent)
+ return clk_set_rate(parent, rate);
+
+ return -ENODEV;
+}
+
static const struct clk_ops clk_gate2_ops = {
+ .set_rate = clk_gate2_set_rate,
.enable = clk_gate2_enable,
.disable = clk_gate2_disable,
.get_rate = clk_generic_get_rate,
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/16] clk: fixed_rate: export clk_fixed_rate
Export the structure for others to use.
Signed-off-by: Peng Fan
---
drivers/clk/clk_fixed_rate.c | 8 +---
include/linux/clk-provider.h | 7 +++
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index 1fdf8c4e54..08cce0d79b 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -6,13 +6,7 @@
#include
#include
#include
-
-struct clk_fixed_rate {
- struct clk clk;
- unsigned long fixed_rate;
-};
-
-#define to_clk_fixed_rate(dev) ((struct clk_fixed_rate *)dev_get_platdata(dev))
+#include
static ulong clk_fixed_rate_get_rate(struct clk *clk)
{
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index b9568502a1..8b790cb666 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -125,6 +125,13 @@ struct clk_fixed_factor {
#define to_clk_fixed_factor(_clk) container_of(_clk, struct clk_fixed_factor,\
clk)
+struct clk_fixed_rate {
+ struct clk clk;
+ unsigned long fixed_rate;
+};
+
+#define to_clk_fixed_rate(dev) ((struct clk_fixed_rate *)dev_get_platdata(dev))
+
int clk_register(struct clk *clk, const char *drv_name, const char *name,
const char *parent_name);
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/4] net: macb: Extend MACB driver for SiFive Unleashed board
On Mon, Jul 22, 2019 at 2:45 AM Anup Patel wrote:
>
> The SiFive MACB ethernet has a custom TX_CLK_SEL register to select
> different TX clock for 1000mbps vs 10/100mbps.
>
> This patch adds SiFive MACB compatible string and extends the MACB
> ethernet driver to change TX clock using TX_CLK_SEL register for
> SiFive MACB.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
> drivers/net/macb.c | 71 +++---
> 1 file changed, 54 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 92ec05559b..3db5597373 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -83,7 +83,8 @@ struct macb_dma_desc {
>
> struct macb_device {
> void*regs;
> - unsigned intdma_burst_length;
> +
> + const struct macb_config *config;
>
> unsigned intrx_tail;
> unsigned inttx_head;
> @@ -123,6 +124,8 @@ struct macb_device {
>
> struct macb_config {
> unsigned intdma_burst_length;
> +
> + int (*clk_init)(struct udevice *dev, ulong rate);
> };
>
> #ifndef CONFIG_DM_ETH
> @@ -483,21 +486,38 @@ static int macb_phy_find(struct macb_device *macb,
> const char *name)
> * when operation failed.
> */
> #ifdef CONFIG_DM_ETH
> +static int macb_sifive_clk_init(struct udevice *dev, ulong rate)
> +{
> + fdt_addr_t addr;
> + void *gemgxl_regs;
> +
> + addr = dev_read_addr_index(dev, 1);
> + if (addr == FDT_ADDR_T_NONE)
> + return -ENODEV;
> +
> + gemgxl_regs = (void __iomem *)addr;
> + if (!gemgxl_regs)
> + return -ENODEV;
> +
> + /*
> +* SiFive GEMGXL TX clock operation mode:
> +*
> +* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
> +* and output clock on GMII output signal GTX_CLK
> +* 1 = MII mode. Use MII input signal TX_CLK in TX logic
> +*/
> + writel(rate != 12500, gemgxl_regs);
> + return 0;
> +}
> +
> int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
> {
> #ifdef CONFIG_CLK
> + struct macb_device *macb = dev_get_priv(dev);
> struct clk tx_clk;
> ulong rate;
> int ret;
>
> - /*
> -* "tx_clk" is an optional clock source for MACB.
> -* Ignore if it does not exist in DT.
> -*/
> - ret = clk_get_by_name(dev, "tx_clk", _clk);
> - if (ret)
> - return 0;
> -
> switch (speed) {
> case _10BASET:
> rate = 250; /* 2.5 MHz */
> @@ -513,6 +533,17 @@ int __weak macb_linkspd_cb(struct udevice *dev, unsigned
> int speed)
> return 0;
> }
>
> + if (macb->config->clk_init)
> + return macb->config->clk_init(dev, rate);
> +
> + /*
> +* "tx_clk" is an optional clock source for MACB.
> +* Ignore if it does not exist in DT.
> +*/
> + ret = clk_get_by_name(dev, "tx_clk", _clk);
> + if (ret)
> + return 0;
> +
> if (tx_clk.dev) {
> ret = clk_set_rate(_clk, rate);
> if (ret)
> @@ -705,8 +736,9 @@ static void gmac_configure_dma(struct macb_device *macb)
> dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
> dmacfg |= GEM_BF(RXBS, buffer_size);
>
> - if (macb->dma_burst_length)
> - dmacfg = GEM_BFINS(FBLDO, macb->dma_burst_length, dmacfg);
> + if (macb->config->dma_burst_length)
> + dmacfg = GEM_BFINS(FBLDO,
> + macb->config->dma_burst_length, dmacfg);
>
> dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
> dmacfg &= ~GEM_BIT(ENDIA_PKT);
> @@ -1173,11 +1205,10 @@ static const struct macb_config default_gem_config = {
>
> static int macb_eth_probe(struct udevice *dev)
> {
> - const struct macb_config *macb_config;
> struct eth_pdata *pdata = dev_get_platdata(dev);
> struct macb_device *macb = dev_get_priv(dev);
> const char *phy_mode;
> - __maybe_unused int ret;
> + int ret;
>
> phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "phy-mode",
>NULL);
> @@ -1190,11 +1221,10 @@ static int macb_eth_probe(struct udevice *dev)
>
> macb->regs = (void *)pdata->iobase;
>
> - macb_config = (struct macb_config *)dev_get_driver_data(dev);
> - if (!macb_config)
> - macb_config = _gem_config;
> + macb->config = (struct macb_config *)dev_get_driver_data(dev);
> + if (!macb->config)
> + macb->config = _gem_config;
>
> - macb->dma_burst_length = macb_config->dma_burst_length;
> #ifdef CONFIG_CLK
> ret = macb_enable_clk(dev);
> if (ret)
> @@ -1259,6 +1289,11 @@ static const struct macb_config
Re: [U-Boot] [PATCH v10 4/4] doc: sifive-fu540: Update README to explicitly load DTB for Linux
On Mon, Jul 22, 2019 at 2:59 AM Anup Patel wrote: > > We should explicitly load DTB from TFTP server or MMC/SD card > for Linux booting. This will allow us: > 1. To use different Linux DTB for SiFive Unleashed board with >expansion board connected. > 2. Avoid re-flashing OpenSBI firmware whenever board connections >change. > > This patch updates reference bootlog in SiFive FU540 README > as-per above. > > Signed-off-by: Anup Patel Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N
> Subject: RE: [U-Boot] [PATCH 00/52] Support i.MX8MM/N > > Hi Lukasz, > > > -Original Message- > > From: Lukasz Majewski [mailto:lu...@denx.de] > > Sent: 2019年7月23日 5:56 > > To: Peng Fan > > Cc: u-boot@lists.denx.de; dl-uboot-imx > > Subject: Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N > > > > On Thu, 18 Jul 2019 09:12:02 +0200 > > Lukasz Majewski wrote: > > > > > Hi Peng, > > > > > > > Hi Lukasz, Stefano, > > > > > > > > > > > > > > > > > > > > Subject: Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N > > > > [] > > > > > > > > > > > > > > The v5 of CCF has been posted ~2 weeks ago (with you on CC) > > > > > > > with a high chance to be pulled by Stefano after the merge > > > > > > > window opens. > > > > > > > > > > > > > > When we accept the "legacy" clock approach we will stuck > > > > > > > with it for a long time. > > > > > > > > > > > > > > What approach is took by the Linux kernel? CCF or any other > > > > > > > one? > > > > > > > > > > > > I am not against CCF. I tried CCF and enabled on i.MX8MM in my > > > > > > last patchset. But I have to add lots of code based on your > > > > > > version, that introduces complexity for now. > > > > > > > > > > You will have to add this complexity anyway after people start > > > > > demanding new clocks for IPs which they need to enable. > > > > > > > > > > Moreover, the CCF v5 was posted 2 weeks ago - wasn't it enough > > > > > time for applying your patches from v4? > > > > > > > > I have converted back to CCF for i.MX8MM/N. Pushed code to > > > > https://github.com/MrVan/u-boot/commits/imx8mmn-ccf > > > > > > > > Since there are 65 patches in my patchset, I not post to maillist. > > > > > > > > Please see whether you have some general comments or not. > > > > > > I will try to provide some comments today. Thanks for the conversion. > > > > Your patches from the github tree up to [1] seems to not touch the > > core clock code and extend only clk-* (gate, mux, etc.) files. > > > > They are similar to what you have posted previously on top of v4. > > > > Two remarks: > > > > - Please extract those CCF related github patches, port them on top of > > master with Stefano's last PR pulled and send to U-Boot mailing list > > (for final review and testing). > > Ok. > > > > > - I think that you can extend the sandbox test code [2] for binded > > clocks [3] - for example to read a clk freq value from such clock. > > Also test if the logic for "hiding" them works. > > The composite clk needs a vendor specific divider ops, then it could get the > freq. However common composite not have that, I have i.MX8M specific > divider ops, but add this to sandbox test seems not good. Just posted out the patchset, please review. Thanks, Peng. > > Thanks, > Peng. > > > > > > > [1] - > > > https://github.com/MrVan/u-boot/commit/1a9b13178be10d0c6c6834808c3 > > 6877b5b2dc49f > > > > [2] - > > > https://github.com/MrVan/u-boot/commit/a89ca577c8c26aa962664dfe1f8e > > 9fec1dd83f65 > > > > [3] - > > > https://github.com/MrVan/u-boot/commit/a088106f1b90b7ef6b7128c2c176 > > 71cd4d376aa9 > > > > > > > > > Then I'll post out to mail list. Hope it could catch this release > > > > cycle. > > > > > > Let's be optimistic. > > > > > > > > > > > Thanks, > > > > Peng. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We might try to switch to CCF again in future, > > > > > > > > > > > > > > I'm a bit skeptical about such statements. It never works > > > > > > > like that > > > > > > > - after it is accepted it would become a "legacy code which > > > > > > > we do need to preserve". > > > > > > > > but we hope > > > > > > > > i.MX8MM/N support could land in upstream soon. It has been > > > > > > > > pending for months. > > > > > > > > > > > > > > Was the CCF the reason for the i.MX8 not being pulled for so > > > > > > > long? > > > > > > > > > > > > I am not saying so. > > > > > > > > > > > > The first version to support i.MX8MM is in 2019-01-28. Then I > > > > > > switch to CCF and posted out new version in 2019-4-30. > > > > > > > > > > Maybe the version posted in 2019-01-28 was just not ready for > > > > > being pulled? > > > > > > > > > > It happens that the community wants to avoid problems > > > > > encountered earlier with other SoCs (like i.MX6, i.MX7), so the > > > > > discussion takes time. > > > > > > > > > > (The similar situation is with other projects too - how many > > > > > release cycles it takes to add new SoC in Linux? Or new port to > > > > > glibc?). > > > > > > we have many 3rd parties want to use mainline U-Boot, not our > > > > > > vendor tree. > > > > > > > > > > There must be a reason that they want the U-Boot mainline. IMHO > > > > > the main reason for it is that people not only from a single > > > > > company want to add the code, so they need to discuss (and get > > > > > the > > > > > agreement) to avoid stepping in each other's toes. > > > > > > > > > > And the discussion/tests takes time ... > > > > > > > > > > > I hope > > > >
[U-Boot] [PATCH 05/16] clk: add clk-gate support
Import clk-gate support from Linux Kernel 5.1-rc5
Signed-off-by: Peng Fan
---
drivers/clk/Makefile | 2 +-
drivers/clk/clk-gate.c | 148 +++
include/linux/clk-provider.h | 18 ++
3 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/clk-gate.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 37dfd281e9..a17ba6deae 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -7,7 +7,7 @@
obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
-obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o clk-gate.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
obj-y += imx/
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
new file mode 100644
index 00..a3a1fdd3b2
--- /dev/null
+++ b/drivers/clk/clk-gate.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2010-2011 Canonical Ltd
+ * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd
+ * Copyright 2019 NXP
+ *
+ * Gated clock implementation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define UBOOT_DM_CLK_GATE "clk_gate"
+
+/**
+ * DOC: basic gatable clock which can gate and ungate it's output
+ *
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional & control gating
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+/*
+ * It works on following logic:
+ *
+ * For enabling clock, enable = 1
+ * set2dis = 1 -> clear bit-> set = 0
+ * set2dis = 0 -> set bit -> set = 1
+ *
+ * For disabling clock, enable = 0
+ * set2dis = 1 -> set bit -> set = 1
+ * set2dis = 0 -> clear bit-> set = 0
+ *
+ * So, result is always: enable xor set2dis.
+ */
+static void clk_gate_endisable(struct clk *clk, int enable)
+{
+ struct clk_gate *gate = to_clk_gate(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
+ int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
+ u32 reg;
+
+ set ^= enable;
+
+ if (gate->flags & CLK_GATE_HIWORD_MASK) {
+ reg = BIT(gate->bit_idx + 16);
+ if (set)
+ reg |= BIT(gate->bit_idx);
+ } else {
+ reg = readl(gate->reg);
+
+ if (set)
+ reg |= BIT(gate->bit_idx);
+ else
+ reg &= ~BIT(gate->bit_idx);
+ }
+
+ writel(reg, gate->reg);
+}
+
+static int clk_gate_enable(struct clk *clk)
+{
+ clk_gate_endisable(clk, 1);
+
+ return 0;
+}
+
+static int clk_gate_disable(struct clk *clk)
+{
+ clk_gate_endisable(clk, 0);
+
+ return 0;
+}
+
+int clk_gate_is_enabled(struct clk *clk)
+{
+ struct clk_gate *gate = to_clk_gate(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
+ u32 reg;
+
+ reg = readl(gate->reg);
+
+ /* if a set bit disables this clk, flip it before masking */
+ if (gate->flags & CLK_GATE_SET_TO_DISABLE)
+ reg ^= BIT(gate->bit_idx);
+
+ reg &= BIT(gate->bit_idx);
+
+ return reg ? 1 : 0;
+}
+
+const struct clk_ops clk_gate_ops = {
+ .enable = clk_gate_enable,
+ .disable = clk_gate_disable,
+ .get_rate = clk_generic_get_rate,
+};
+
+struct clk *clk_register_gate(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 bit_idx,
+ u8 clk_gate_flags, spinlock_t *lock)
+{
+ struct clk_gate *gate;
+ struct clk *clk;
+ int ret;
+
+ if (clk_gate_flags & CLK_GATE_HIWORD_MASK) {
+ if (bit_idx > 15) {
+ pr_err("gate bit exceeds LOWORD field\n");
+ return ERR_PTR(-EINVAL);
+ }
+ }
+
+ /* allocate the gate */
+ gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+ if (!gate)
+ return ERR_PTR(-ENOMEM);
+
+ /* struct clk_gate assignments */
+ gate->reg = reg;
+ gate->bit_idx = bit_idx;
+ gate->flags = clk_gate_flags;
+
+ clk = >clk;
+
+ ret = clk_register(clk, UBOOT_DM_CLK_GATE, name, parent_name);
+ if (ret) {
+ kfree(gate);
+ return ERR_PTR(ret);
+ }
+
+ return clk;
+}
+
+U_BOOT_DRIVER(clk_gate) = {
+ .name = UBOOT_DM_CLK_GATE,
+ .id = UCLASS_CLK,
+ .ops= _gate_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
diff --git a/include/linux/clk-provider.h
[U-Boot] [PATCH 14/16] clk: sandbox: add composite clk
Add composite clk to sandbox driver
Signed-off-by: Peng Fan
---
drivers/clk/clk_sandbox_ccf.c | 80 +++
include/sandbox-clk.h | 1 +
2 files changed, 81 insertions(+)
diff --git a/drivers/clk/clk_sandbox_ccf.c b/drivers/clk/clk_sandbox_ccf.c
index edeb0f2cf3..e126f18d8e 100644
--- a/drivers/clk/clk_sandbox_ccf.c
+++ b/drivers/clk/clk_sandbox_ccf.c
@@ -130,6 +130,80 @@ U_BOOT_DRIVER(sandbox_clk_gate2) = {
.ops= _gate2_ops,
};
+static unsigned long sandbox_clk_composite_divider_recalc_rate(struct clk *clk)
+{
+ struct clk_divider *divider = (struct clk_divider *)to_clk_divider(clk);
+ struct clk_composite *composite = (struct clk_composite *)clk->data;
+ ulong parent_rate = clk_get_parent_rate(>clk);
+ unsigned int val;
+
+ val = divider->io_divider_val;
+ val >>= divider->shift;
+ val &= clk_div_mask(divider->width);
+
+ return divider_recalc_rate(clk, parent_rate, val, divider->table,
+ divider->flags, divider->width);
+}
+
+static const struct clk_ops sandbox_clk_composite_divider_ops = {
+ .get_rate = sandbox_clk_composite_divider_recalc_rate,
+};
+
+struct clk *sandbox_clk_composite(const char *name,
+ const char * const *parent_names,
+ int num_parents, void __iomem *reg,
+ unsigned long flags)
+{
+ struct clk *clk = ERR_PTR(-ENOMEM);
+ struct clk_divider *div = NULL;
+ struct clk_gate *gate = NULL;
+ struct clk_mux *mux = NULL;
+
+ mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+ if (!mux)
+ goto fail;
+
+ mux->reg = reg;
+ mux->shift = 24;
+ mux->mask = 0x7;
+ mux->num_parents = num_parents;
+ mux->flags = flags;
+ mux->parent_names = parent_names;
+
+ div = kzalloc(sizeof(*div), GFP_KERNEL);
+ if (!div)
+ goto fail;
+
+ div->reg = reg;
+ div->shift = 16;
+ div->width = 3;
+ div->flags = CLK_DIVIDER_ROUND_CLOSEST | flags;
+
+ gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+ if (!gate)
+ goto fail;
+
+ gate->reg = reg;
+ gate->bit_idx = 28;
+ gate->flags = flags;
+
+ clk = clk_register_composite(NULL, name,
+parent_names, num_parents,
+>clk, _mux_ops, >clk,
+_clk_composite_divider_ops,
+>clk, _gate_ops, flags);
+ if (IS_ERR(clk))
+ goto fail;
+
+ return clk;
+
+fail:
+ kfree(gate);
+ kfree(div);
+ kfree(mux);
+ return ERR_CAST(clk);
+}
+
/* --- Sandbox Gate --- */
/* The CCF core driver itself */
static const struct udevice_id sandbox_clk_ccf_test_ids[] = {
@@ -138,6 +212,7 @@ static const struct udevice_id sandbox_clk_ccf_test_ids[] =
{
};
static const char *const usdhc_sels[] = { "pll3_60m", "pll3_80m", };
+static const char *const i2c_sels[] = { "pll3_60m", "pll3_80m", };
static int sandbox_clk_ccf_probe(struct udevice *dev)
{
@@ -174,6 +249,11 @@ static int sandbox_clk_ccf_probe(struct udevice *dev)
sandbox_clk_mux("usdhc2_sel", , 17, 1, usdhc_sels,
ARRAY_SIZE(usdhc_sels)));
+ reg = BIT(28) | BIT(24) | BIT(16);
+ clk_dm(SANDBOX_CLK_I2C,
+ sandbox_clk_composite("i2c", i2c_sels, ARRAY_SIZE(i2c_sels),
+, 0));
+
return 0;
}
diff --git a/include/sandbox-clk.h b/include/sandbox-clk.h
index 37c9838f76..f449de1364 100644
--- a/include/sandbox-clk.h
+++ b/include/sandbox-clk.h
@@ -19,6 +19,7 @@ enum {
SANDBOX_CLK_ECSPI1,
SANDBOX_CLK_USDHC1_SEL,
SANDBOX_CLK_USDHC2_SEL,
+ SANDBOX_CLK_I2C,
};
enum sandbox_pllv3_type {
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/16] clk: export mux/divider ops
Export mux/divider ops for composite usage
Signed-off-by: Peng Fan
---
include/linux/clk-provider.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7e44045c16..6c6475ea91 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -96,6 +96,7 @@ struct clk_divider {
#define CLK_DIVIDER_ROUND_CLOSEST BIT(4)
#define CLK_DIVIDER_READ_ONLY BIT(5)
#define CLK_DIVIDER_MAX_AT_ZEROBIT(6)
+extern const struct clk_ops clk_divider_ops;
struct clk_fixed_factor {
struct clk clk;
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/16] clk: imx: import clk heplers
Import some clk helpers from Linux Kernel for i.MX8MM usage
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk.h | 81 +++
1 file changed, 81 insertions(+)
diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index e6d51830e8..1d480d8722 100644
--- a/drivers/clk/imx/clk.h
+++ b/drivers/clk/imx/clk.h
@@ -36,6 +36,23 @@ static inline struct clk *imx_clk_gate2(const char *name,
const char *parent,
shift, 0x3, 0);
}
+static inline struct clk *imx_clk_gate4(const char *name, const char *parent,
+ void __iomem *reg, u8 shift)
+{
+ return clk_register_gate2(NULL, name, parent,
+ CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
+ reg, shift, 0x3, 0);
+}
+
+static inline struct clk *imx_clk_gate4_flags(const char *name,
+ const char *parent, void __iomem *reg, u8 shift,
+ unsigned long flags)
+{
+ return clk_register_gate2(NULL, name, parent,
+ flags | CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
+ reg, shift, 0x3, 0);
+}
+
static inline struct clk *imx_clk_fixed_factor(const char *name,
const char *parent, unsigned int mult, unsigned int div)
{
@@ -50,6 +67,14 @@ static inline struct clk *imx_clk_divider(const char *name,
const char *parent,
reg, shift, width, 0);
}
+static inline struct clk *imx_clk_divider2(const char *name, const char
*parent,
+ void __iomem *reg, u8 shift, u8 width)
+{
+ return clk_register_divider(NULL, name, parent,
+ CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
+ reg, shift, width, 0);
+}
+
struct clk *imx_clk_pfd(const char *name, const char *parent_name,
void __iomem *reg, u8 idx);
@@ -57,6 +82,16 @@ struct clk *imx_clk_fixup_mux(const char *name, void __iomem
*reg,
u8 shift, u8 width, const char * const *parents,
int num_parents, void (*fixup)(u32 *val));
+static inline struct clk *imx_clk_mux_flags(const char *name,
+ void __iomem *reg, u8 shift, u8 width,
+ const char * const *parents, int num_parents,
+ unsigned long flags)
+{
+ return clk_register_mux(NULL, name, parents, num_parents,
+ flags | CLK_SET_RATE_NO_REPARENT, reg, shift,
+ width, 0);
+}
+
static inline struct clk *imx_clk_mux(const char *name, void __iomem *reg,
u8 shift, u8 width, const char * const *parents,
int num_parents)
@@ -66,4 +101,50 @@ static inline struct clk *imx_clk_mux(const char *name,
void __iomem *reg,
width, 0);
}
+static inline struct clk *imx_clk_mux2(const char *name, void __iomem *reg,
+ u8 shift, u8 width, const char * const *parents,
+ int num_parents)
+{
+ return clk_register_mux(NULL, name, parents, num_parents,
+ CLK_SET_RATE_NO_REPARENT | CLK_OPS_PARENT_ENABLE,
+ reg, shift, width, 0);
+}
+
+static inline struct clk *imx_clk_gate(const char *name, const char *parent,
+ void __iomem *reg, u8 shift)
+{
+ return clk_register_gate(NULL, name, parent, CLK_SET_RATE_PARENT, reg,
+ shift, 0, NULL);
+}
+
+static inline struct clk *imx_clk_gate_flags(const char *name, const char
*parent,
+ void __iomem *reg, u8 shift, unsigned long flags)
+{
+ return clk_register_gate(NULL, name, parent, flags |
CLK_SET_RATE_PARENT, reg,
+ shift, 0, NULL);
+}
+
+static inline struct clk *imx_clk_gate3(const char *name, const char *parent,
+ void __iomem *reg, u8 shift)
+{
+ return clk_register_gate(NULL, name, parent,
+ CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE,
+ reg, shift, 0, NULL);
+}
+
+struct clk *imx8m_clk_composite_flags(const char *name,
+ const char * const *parent_names,
+ int num_parents, void __iomem *reg, unsigned long flags);
+
+#define __imx8m_clk_composite(name, parent_names, reg, flags) \
+ imx8m_clk_composite_flags(name, parent_names, \
+ ARRAY_SIZE(parent_names), reg, \
+ flags | CLK_SET_RATE_NO_REPARENT | CLK_OPS_PARENT_ENABLE)
+
+#define imx8m_clk_composite(name, parent_names, reg) \
+ __imx8m_clk_composite(name, parent_names, reg, 0)
+
+#define imx8m_clk_composite_critical(name, parent_names, reg) \
+ __imx8m_clk_composite(name, parent_names, reg, CLK_IS_CRITICAL)
+
#endif /* __MACH_IMX_CLK_H */
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/16] clk-provider: include clk-uclass.h
Because clk-provider use clk_ops, so let's include clk-uclass.h
Signed-off-by: Peng Fan
---
include/linux/clk-provider.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 9c292f555d..32a777d86c 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -8,6 +8,7 @@
*/
#ifndef __LINUX_CLK_PROVIDER_H
#define __LINUX_CLK_PROVIDER_H
+#include
static inline void clk_dm(ulong id, struct clk *clk)
{
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/16] clk: divider set rate supporrt
Signed-off-by: Peng Fan
---
drivers/clk/clk-divider.c | 88 +++
1 file changed, 88 insertions(+)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 2ed9ed6ab8..822e09b084 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include "clk.h"
@@ -86,8 +87,95 @@ static ulong clk_divider_recalc_rate(struct clk *clk)
divider->flags, divider->width);
}
+static bool _is_valid_table_div(const struct clk_div_table *table,
+ unsigned int div)
+{
+ const struct clk_div_table *clkt;
+
+ for (clkt = table; clkt->div; clkt++)
+ if (clkt->div == div)
+ return true;
+ return false;
+}
+
+static bool _is_valid_div(const struct clk_div_table *table, unsigned int div,
+ unsigned long flags)
+{
+ if (flags & CLK_DIVIDER_POWER_OF_TWO)
+ return is_power_of_2(div);
+ if (table)
+ return _is_valid_table_div(table, div);
+ return true;
+}
+
+static unsigned int _get_table_val(const struct clk_div_table *table,
+ unsigned int div)
+{
+ const struct clk_div_table *clkt;
+
+ for (clkt = table; clkt->div; clkt++)
+ if (clkt->div == div)
+ return clkt->val;
+ return 0;
+}
+
+static unsigned int _get_val(const struct clk_div_table *table,
+unsigned int div, unsigned long flags, u8 width)
+{
+ if (flags & CLK_DIVIDER_ONE_BASED)
+ return div;
+ if (flags & CLK_DIVIDER_POWER_OF_TWO)
+ return __ffs(div);
+ if (flags & CLK_DIVIDER_MAX_AT_ZERO)
+ return (div == clk_div_mask(width) + 1) ? 0 : div;
+ if (table)
+ return _get_table_val(table, div);
+ return div - 1;
+}
+int divider_get_val(unsigned long rate, unsigned long parent_rate,
+ const struct clk_div_table *table, u8 width,
+ unsigned long flags)
+{
+ unsigned int div, value;
+
+ div = DIV_ROUND_UP_ULL((u64)parent_rate, rate);
+
+ if (!_is_valid_div(table, div, flags))
+ return -EINVAL;
+
+ value = _get_val(table, div, flags, width);
+
+ return min_t(unsigned int, value, clk_div_mask(width));
+}
+
+static ulong clk_divider_set_rate(struct clk *clk, unsigned long rate)
+{
+ struct clk_divider *divider = to_clk_divider(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
+ unsigned long parent_rate = clk_get_parent_rate(clk);
+ int value;
+ u32 val;
+
+ value = divider_get_val(rate, parent_rate, divider->table,
+ divider->width, divider->flags);
+ if (value < 0)
+ return value;
+
+ if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
+ val = clk_div_mask(divider->width) << (divider->shift + 16);
+ } else {
+ val = readl(divider->reg);
+ val &= ~(clk_div_mask(divider->width) << divider->shift);
+ }
+ val |= (u32)value << divider->shift;
+ writel(val, divider->reg);
+
+ return clk_get_rate(clk);
+}
+
const struct clk_ops clk_divider_ops = {
.get_rate = clk_divider_recalc_rate,
+ .set_rate = clk_divider_set_rate,
};
static struct clk *_register_divider(struct device *dev, const char *name,
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/16] clk: add composite clk support
Import clk composite clk support from Linux Kernel 5.1-rc5
Signed-off-by: Peng Fan
---
drivers/clk/Kconfig | 14
drivers/clk/Makefile | 1 +
drivers/clk/clk-composite.c | 160 +++
include/linux/clk-provider.h | 22 ++
4 files changed, 197 insertions(+)
create mode 100644 drivers/clk/clk-composite.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9399bb79e9..0138473ac7 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -53,6 +53,13 @@ config SPL_CLK_CCF
Enable this option if you want to (re-)use the Linux kernel's Common
Clock Framework [CCF] code in U-Boot's SPL.
+config SPL_CLK_COMPOSITE_CCF
+ bool "SPL Common Clock Framework [CCF] composite clk support "
+ depends on SPL_CLK_CCF
+ help
+ Enable this option if you want to (re-)use the Linux kernel's Common
+ Clock Framework [CCF] composite code in U-Boot's SPL.
+
config CLK_CCF
bool "Common Clock Framework [CCF] support "
depends on CLK_IMX6Q || SANDBOX_CLK_CCF
@@ -60,6 +67,13 @@ config CLK_CCF
Enable this option if you want to (re-)use the Linux kernel's Common
Clock Framework [CCF] code in U-Boot's clock driver.
+config CLK_COMPOSITE_CCF
+ bool "Common Clock Framework [CCF] composite clk support "
+ depends on CLK_CCF
+ help
+ Enable this option if you want to (re-)use the Linux kernel's Common
+ Clock Framework [CCF] composite code in U-Boot's clock driver.
+
config CLK_STM32F
bool "Enable clock driver support for STM32F family"
depends on CLK && (STM32F7 || STM32F4)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index a17ba6deae..681372639d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o clk-gate.o
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_COMPOSITE_CCF) += clk-composite.o
obj-y += imx/
obj-y += tegra/
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
new file mode 100644
index 00..a5626c33d1
--- /dev/null
+++ b/drivers/clk/clk-composite.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2013 NVIDIA CORPORATION. All rights reserved.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define UBOOT_DM_CLK_COMPOSITE "clk_composite"
+
+static u8 clk_composite_get_parent(struct clk *clk)
+{
+ struct clk_composite *composite = to_clk_composite(clk_dev_binded(clk) ?
+ (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
+ struct clk *mux = composite->mux;
+
+ return clk_mux_get_parent(mux);
+}
+
+static int clk_composite_set_parent(struct clk *clk, struct clk *parent)
+{
+ struct clk_composite *composite = to_clk_composite(clk_dev_binded(clk) ?
+ (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
+ const struct clk_ops *mux_ops = composite->mux_ops;
+ struct clk *mux = composite->mux;
+
+ return mux_ops->set_parent(mux, parent);
+}
+
+static unsigned long clk_composite_recalc_rate(struct clk *clk)
+{
+ struct clk_composite *composite = to_clk_composite(clk_dev_binded(clk) ?
+ (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
+ const struct clk_ops *rate_ops = composite->rate_ops;
+ struct clk *rate = composite->rate;
+
+ return rate_ops->get_rate(rate);
+}
+
+static ulong clk_composite_set_rate(struct clk *clk, unsigned long rate)
+{
+ struct clk_composite *composite = to_clk_composite(clk_dev_binded(clk) ?
+ (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
+ const struct clk_ops *rate_ops = composite->rate_ops;
+ struct clk *clk_rate = composite->rate;
+
+ return rate_ops->set_rate(clk_rate, rate);
+}
+
+static int clk_composite_enable(struct clk *clk)
+{
+ struct clk_composite *composite = to_clk_composite(clk_dev_binded(clk) ?
+ (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
+ const struct clk_ops *gate_ops = composite->gate_ops;
+ struct clk *gate = composite->gate;
+
+ return gate_ops->enable(gate);
+}
+
+static int clk_composite_disable(struct clk *clk)
+{
+ struct clk_composite *composite = to_clk_composite(clk_dev_binded(clk) ?
+ (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
+ const struct clk_ops *gate_ops = composite->gate_ops;
+ struct clk *gate = composite->gate;
+
+ gate_ops->disable(gate);
+
+ return 0;
+}
+
+struct clk_ops clk_composite_ops = {
+ /* This will be set according to clk_register_composite */
+};
+
+struct clk *clk_register_composite(struct device *dev, const char *name,
+
[U-Boot] [PATCH 15/16] test: dm: clk_ccf: test composite clk
Test composite clk with dm ccf
Signed-off-by: Peng Fan
---
test/dm/clk_ccf.c | 8
1 file changed, 8 insertions(+)
diff --git a/test/dm/clk_ccf.c b/test/dm/clk_ccf.c
index 8d397593a3..bbc4b500e8 100644
--- a/test/dm/clk_ccf.c
+++ b/test/dm/clk_ccf.c
@@ -56,6 +56,14 @@ static int dm_test_clk_ccf(struct unit_test_state *uts)
pclk = clk_get_parent(clk);
ut_asserteq_str("pll3_80m", pclk->dev->name);
+ /* Test the composite of CCF */
+ ret = clk_get_by_id(SANDBOX_CLK_I2C, );
+ ut_assertok(ret);
+ ut_asserteq_str("i2c", clk->dev->name);
+
+ rate = clk_get_rate(clk);
+ ut_asserteq(rate, 6000);
+
return 1;
}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/16] clk: mux: add set parent support
Add set parent support for clk mux
Signed-off-by: Peng Fan
---
drivers/clk/clk-mux.c| 70 ++--
include/linux/clk-provider.h | 2 ++
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 81d1e7ebee..5acc0b8cbd 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -60,7 +60,24 @@ int clk_mux_val_to_index(struct clk *clk, u32 *table,
unsigned int flags,
return val;
}
-static u8 clk_mux_get_parent(struct clk *clk)
+unsigned int clk_mux_index_to_val(u32 *table, unsigned int flags, u8 index)
+{
+ unsigned int val = index;
+
+ if (table) {
+ val = table[index];
+ } else {
+ if (flags & CLK_MUX_INDEX_BIT)
+ val = 1 << index;
+
+ if (flags & CLK_MUX_INDEX_ONE)
+ val++;
+ }
+
+ return val;
+}
+
+u8 clk_mux_get_parent(struct clk *clk)
{
struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
dev_get_clk_ptr(clk->dev) : clk);
@@ -77,8 +94,57 @@ static u8 clk_mux_get_parent(struct clk *clk)
return clk_mux_val_to_index(clk, mux->table, mux->flags, val);
}
+static int clk_fetch_parent_index(struct clk *clk,
+ struct clk *parent)
+{
+ struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
+
+ int i;
+
+ if (!parent)
+ return -EINVAL;
+
+ for (i = 0; i < mux->num_parents; i++) {
+ if (!strcmp(parent->dev->name, mux->parent_names[i]))
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int clk_mux_set_parent(struct clk *clk, struct clk *parent)
+{
+ struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
+ int index;
+ u32 val;
+ u32 reg;
+
+ index = clk_fetch_parent_index(clk, parent);
+ if (index < 0) {
+ printf("Could not fetch index\n");
+ return index;
+ }
+
+ val = clk_mux_index_to_val(mux->table, mux->flags, index);
+
+ if (mux->flags & CLK_MUX_HIWORD_MASK) {
+ reg = mux->mask << (mux->shift + 16);
+ } else {
+ reg = readl(mux->reg);
+ reg &= ~(mux->mask << mux->shift);
+ }
+ val = val << mux->shift;
+ reg |= val;
+ writel(reg, mux->reg);
+
+ return 0;
+}
+
const struct clk_ops clk_mux_ops = {
- .get_rate = clk_generic_get_rate,
+ .get_rate = clk_generic_get_rate,
+ .set_parent = clk_mux_set_parent,
};
struct clk *clk_hw_register_mux_table(struct device *dev, const char *name,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 43a25e9c6a..7e44045c16 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -66,6 +66,8 @@ struct clk_mux {
};
#define to_clk_mux(_clk) container_of(_clk, struct clk_mux, clk)
+extern const struct clk_ops clk_mux_ops;
+u8 clk_mux_get_parent(struct clk *clk);
struct clk_div_table {
unsigned intval;
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/16] clk: use clk_dev_binded
Preparing to support composite clk.
Signed-off-by: Peng Fan
---
drivers/clk/clk-divider.c | 4 ++--
drivers/clk/clk-mux.c | 6 --
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 6921c76a48..2ed9ed6ab8 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -69,8 +69,8 @@ unsigned long divider_recalc_rate(struct clk *hw, unsigned
long parent_rate,
static ulong clk_divider_recalc_rate(struct clk *clk)
{
- struct clk_divider *divider =
- to_clk_divider(dev_get_clk_ptr(clk->dev));
+ struct clk_divider *divider = to_clk_divider(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
unsigned int val;
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 3c075aa09e..81d1e7ebee 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -35,7 +35,8 @@
int clk_mux_val_to_index(struct clk *clk, u32 *table, unsigned int flags,
unsigned int val)
{
- struct clk_mux *mux = to_clk_mux(clk);
+ struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
int num_parents = mux->num_parents;
if (table) {
@@ -61,7 +62,8 @@ int clk_mux_val_to_index(struct clk *clk, u32 *table,
unsigned int flags,
static u8 clk_mux_get_parent(struct clk *clk)
{
- struct clk_mux *mux = to_clk_mux(clk);
+ struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
+ dev_get_clk_ptr(clk->dev) : clk);
u32 val;
#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/16] clk: introduce clk_dev_binded
When support Clock Common Framework, U-Boot use dev for
clk tree information, there is no clk->parent. When
support composite clk, it contains mux/gate/divider,
but the mux/gate/divider is not binded with device.
So we could not use dev_get_uclass_priv to get the correct
clk_mux/gate/divider. So add clk_dev_binded to let
choose the correct method.
Signed-off-by: Peng Fan
---
drivers/clk/clk.c | 8
include/clk.h | 9 +
2 files changed, 17 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7d748c9fc7..39b3087067 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -55,3 +55,11 @@ const char *clk_hw_get_name(const struct clk *hw)
{
return hw->dev->name;
}
+
+bool clk_dev_binded(struct clk *clk)
+{
+ if (clk->dev && (clk->dev->flags & DM_FLAG_BOUND))
+ return true;
+
+ return false;
+}
diff --git a/include/clk.h b/include/clk.h
index f8f56d9cf0..2ebc905e04 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -356,4 +356,13 @@ static inline bool clk_valid(struct clk *clk)
* @return zero on success, or -ENOENT on error
*/
int clk_get_by_id(ulong id, struct clk **clkp);
+
+/**
+ * clk_dev_binded() - Check whether the clk has a device binded
+ *
+ * @clkA pointer to the clk
+ *
+ * @return true on binded, or false on no
+ */
+bool clk_dev_binded(struct clk *clk);
#endif
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 3/4] riscv: sifive: fu540: Sync-up config header with RISC-V QEMU support
On Mon, Jul 22, 2019 at 2:50 AM Anup Patel wrote: > > We typically use same set of distro images (yocto, debian, fedora, etc.) > on both QEMU RISC-V virt machine and SiFive Unleashed board. > > With growing kernel and ramdisk images, we need to re-adjust default > U-Boot environment variables. The config header for QEMU RISC-V virt > machine has been already updated to handle bigger kernel and ramdisk > images hence this patch updates SiFive FU540 config header accordingly. > > Signed-off-by: Anup Patel Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 7/9] riscv: sifive: fu540: Setup ethaddr env variable using OTP
On Mon, Jul 22, 2019 at 12:46 PM Joey Hewitt wrote: > > On 7/10/19 10:28 PM, Anup Patel wrote: [ ... ] > >> Please take a look at the DM-enabled SiFive OTP driver submitted by Joey > >> Hewitt at https://github.com/sifive/HiFive_U- > >> Boot/commit/6d842765de142b61f847852da7a9ce0d081d770c > >> > >> This Joey's version also sets the ‘serial#’ environment variable, while > >> this > >> patch only sets ‘ethaddr' > > > > I am not sure if "serial#" environment variable is a standard U-Boot > > way of advertising serial number of underlying Host. > > > > Where is this used? > > > > Regards, > > Anup > > > > The serial# var is inserted into the device tree. > https://github.com/u-boot/u-boot/blob/0de815356474912ef5bef9a69f0327a5a93bb2c2/common/fdt_support.c#L199 > > See also > https://github.com/torvalds/linux/commit/13dd92bb4599b5655cafe1f2c0365396a096b94a > > I don't recall if it had any particularly special meaning on the kernels > I tested with, but it seems to be standard and could be useful to userspace. You can find the so-called "built in" variables here: https://gitlab.denx.de/u-boot/u-boot/blob/master/include/env_flags.h It is fairly common for a board.c to set the serial# variable. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N
Hi Lukasz, > -Original Message- > From: Lukasz Majewski [mailto:lu...@denx.de] > Sent: 2019年7月23日 5:56 > To: Peng Fan > Cc: u-boot@lists.denx.de; dl-uboot-imx > Subject: Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N > > On Thu, 18 Jul 2019 09:12:02 +0200 > Lukasz Majewski wrote: > > > Hi Peng, > > > > > Hi Lukasz, Stefano, > > > > > > > > > > > > > > > > > Subject: Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N > > > [] > > > > > > > > > > > > The v5 of CCF has been posted ~2 weeks ago (with you on CC) > > > > > > with a high chance to be pulled by Stefano after the merge > > > > > > window opens. > > > > > > > > > > > > When we accept the "legacy" clock approach we will stuck with > > > > > > it for a long time. > > > > > > > > > > > > What approach is took by the Linux kernel? CCF or any other > > > > > > one? > > > > > > > > > > I am not against CCF. I tried CCF and enabled on i.MX8MM in my > > > > > last patchset. But I have to add lots of code based on your > > > > > version, that introduces complexity for now. > > > > > > > > You will have to add this complexity anyway after people start > > > > demanding new clocks for IPs which they need to enable. > > > > > > > > Moreover, the CCF v5 was posted 2 weeks ago - wasn't it enough > > > > time for applying your patches from v4? > > > > > > I have converted back to CCF for i.MX8MM/N. Pushed code to > > > https://github.com/MrVan/u-boot/commits/imx8mmn-ccf > > > > > > Since there are 65 patches in my patchset, I not post to maillist. > > > > > > Please see whether you have some general comments or not. > > > > I will try to provide some comments today. Thanks for the conversion. > > Your patches from the github tree up to [1] seems to not touch the core clock > code and extend only clk-* (gate, mux, etc.) files. > > They are similar to what you have posted previously on top of v4. > > Two remarks: > > - Please extract those CCF related github patches, port them on top of > master with Stefano's last PR pulled and send to U-Boot mailing list > (for final review and testing). Ok. > > - I think that you can extend the sandbox test code [2] for binded > clocks [3] - for example to read a clk freq value from such clock. > Also test if the logic for "hiding" them works. The composite clk needs a vendor specific divider ops, then it could get the freq. However common composite not have that, I have i.MX8M specific divider ops, but add this to sandbox test seems not good. Thanks, Peng. > > > [1] - > https://github.com/MrVan/u-boot/commit/1a9b13178be10d0c6c6834808c3 > 6877b5b2dc49f > > [2] - > https://github.com/MrVan/u-boot/commit/a89ca577c8c26aa962664dfe1f8e > 9fec1dd83f65 > > [3] - > https://github.com/MrVan/u-boot/commit/a088106f1b90b7ef6b7128c2c176 > 71cd4d376aa9 > > > > > > Then I'll post out to mail list. Hope it could catch this release > > > cycle. > > > > Let's be optimistic. > > > > > > > > Thanks, > > > Peng. > > > > > > > > > > > > > > > > > > > > > > > > > We might try to switch to CCF again in future, > > > > > > > > > > > > I'm a bit skeptical about such statements. It never works like > > > > > > that > > > > > > - after it is accepted it would become a "legacy code which we > > > > > > do need to preserve". > > > > > > > but we hope > > > > > > > i.MX8MM/N support could land in upstream soon. It has been > > > > > > > pending for months. > > > > > > > > > > > > Was the CCF the reason for the i.MX8 not being pulled for so > > > > > > long? > > > > > > > > > > I am not saying so. > > > > > > > > > > The first version to support i.MX8MM is in 2019-01-28. Then I > > > > > switch to CCF and posted out new version in 2019-4-30. > > > > > > > > Maybe the version posted in 2019-01-28 was just not ready for > > > > being pulled? > > > > > > > > It happens that the community wants to avoid problems encountered > > > > earlier with other SoCs (like i.MX6, i.MX7), so the discussion > > > > takes time. > > > > > > > > (The similar situation is with other projects too - how many > > > > release cycles it takes to add new SoC in Linux? Or new port to > > > > glibc?). > > > > > we have many 3rd parties want to use mainline U-Boot, not our > > > > > vendor tree. > > > > > > > > There must be a reason that they want the U-Boot mainline. IMHO > > > > the main reason for it is that people not only from a single > > > > company want to add the code, so they need to discuss (and get the > > > > agreement) to avoid stepping in each other's toes. > > > > > > > > And the discussion/tests takes time ... > > > > > > > > > I hope > > > > > i.MX8MM/N could land in the coming merge window, > > > > > > > > This depends solely on the code quality I think. > > > > > > > > > introducing more to CCF add risk. > > > > > > > > Risk for not being accepted? > > > > > > > > I do see however other risk - the i.MX8 will gain one-off clock > > > > support code instead of adopting the CCF just from the outset. > > > > > > > > > > > > > > > > > >
Re: [U-Boot] [PATCH 2/2] riscv: Access CSRs using CSR numbers
Hi Lukas
> > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de]
> > Sent: Thursday, July 18, 2019 4:53 PM
> > To: Rick Jian-Zhi Chen(陳建志); u-boot@lists.denx.de; bmeng...@gmail.com;
> > anup.pa...@wdc.com
> > Subject: Re: [PATCH 2/2] riscv: Access CSRs using CSR numbers
> >
> > Hi Bin,
> >
> > On Wed, 2019-07-10 at 23:43 -0700, Bin Meng wrote:
> > > We should prefer accessing CSRs using their CSR numbers
> > > because:
> > > 1. It compiles fine with older toolchains.
> > > 2. We can use latest CSR names in #define macro names of CSR
> > >numbers as-per RISC-V spec.
> > > 3. We can access newly added CSRs even if toolchain does not
> > >recognize newly added CSRs by name.
> > >
> > > This commit is inspired from Linux kernel commit a3182c91ef4e
> > > ("RISC-V: Access CSRs using CSR numbers").
> > >
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > arch/riscv/cpu/cpu.c | 9 +-
> > > arch/riscv/cpu/start.S| 3 +-
> > > arch/riscv/include/asm/csr.h | 12 ++
> > > arch/riscv/include/asm/encoding.h | 238
> > > +-
> > > 4 files changed, 19 insertions(+), 243 deletions(-)
> > >
> > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c index
> > > e9a8b43..5ca1857 100644
> > > --- a/arch/riscv/cpu/cpu.c
> > > +++ b/arch/riscv/cpu/cpu.c
> > > @@ -7,7 +7,6 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > #include
> > >
> > > @@ -48,7 +47,7 @@ static inline bool supports_extension(char ext)
> > > return false;
> > > #else /* !CONFIG_CPU */
> > > #ifdef CONFIG_RISCV_MMODE
> > > - return csr_read(misa) & (1 << (ext - 'a'));
> > > + return csr_read(CSR_MISA) & (1 << (ext - 'a'));
> > > #else /* !CONFIG_RISCV_MMODE */
> > > #warning "There is no way to determine the available extensions in
> > > S-mode."
> > > #warning "Please convert your board to use the RISC-V CPU driver."
> > > @@ -82,7 +81,7 @@ int arch_cpu_init_dm(void)
> > > /* Enable FPU */
> > > if (supports_extension('d') || supports_extension('f')) {
> > > csr_set(MODE_PREFIX(status), MSTATUS_FS);
> > > - csr_write(fcsr, 0);
> > > + csr_write(CSR_FCSR, 0);
> > > }
> > >
> > > if (CONFIG_IS_ENABLED(RISCV_MMODE)) { @@ -90,11 +89,11 @@ int
> > > arch_cpu_init_dm(void)
> > > * Enable perf counters for cycle, time,
> > > * and instret counters only
> > > */
> > > - csr_write(mcounteren, GENMASK(2, 0));
> > > + csr_write(CSR_MCOUNTEREN, GENMASK(2, 0));
> > >
> > > /* Disable paging */
> > > if (supports_extension('s'))
> > > - csr_write(satp, 0);
> > > + csr_write(CSR_SATP, 0);
> > > }
> > >
> > > return 0;
> > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > 60ac8c6..e06db40 100644
> > > --- a/arch/riscv/cpu/start.S
> > > +++ b/arch/riscv/cpu/start.S
> > > @@ -13,7 +13,6 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > #include
> > >
> > > @@ -41,7 +40,7 @@ secondary_harts_relocation_error:
> > > .globl _start
> > > _start:
> > > #ifdef CONFIG_RISCV_MMODE
> > > - csrra0, mhartid
> > > + csrra0, CSR_MHARTID
> > > #endif
> > >
> > > /* save hart id and dtb pointer */
> > > diff --git a/arch/riscv/include/asm/csr.h
> > > b/arch/riscv/include/asm/csr.h index 1a6bcfc..d152074 100644
> > > --- a/arch/riscv/include/asm/csr.h
> > > +++ b/arch/riscv/include/asm/csr.h
> > > @@ -75,6 +75,7 @@
> > > #define SIE_STIE (_AC(0x1, UL) << IRQ_S_TIMER)
> > > #define SIE_SEIE (_AC(0x1, UL) << IRQ_S_EXT)
> > >
> > > +#define CSR_FCSR 0x003
> > > #define CSR_CYCLE 0xc00
> > > #define CSR_TIME 0xc01
> > > #define CSR_INSTRET0xc02
> > > @@ -88,9 +89,20 @@
> > > #define CSR_STVAL 0x143
> > > #define CSR_SIP0x144
> > > #define CSR_SATP 0x180
> > > +#define CSR_MSTATUS0x300
> > > +#define CSR_MISA 0x301
> > > +#define CSR_MIE0x304
> > > +#define CSR_MTVEC 0x305
> > > +#define CSR_MCOUNTEREN 0x306
> > > +#define CSR_MSCRATCH 0x340
> > > +#define CSR_MEPC 0x341
> > > +#define CSR_MCAUSE 0x342
> > > +#define CSR_MTVAL 0x343
> > > +#define CSR_MIP0x344
> > > #define CSR_CYCLEH 0xc80
> > > #define CSR_TIMEH 0xc81
> > > #define CSR_INSTRETH 0xc82
> > > +#define CSR_MHARTID0xf14
> > >
> > > #ifndef __ASSEMBLY__
> > >
> > > diff --git a/arch/riscv/include/asm/encoding.h
> > > b/arch/riscv/include/asm/encoding.h
> > > index 772668c..c450eb9 100644
> > > --- a/arch/riscv/include/asm/encoding.h
> > > +++ b/arch/riscv/include/asm/encoding.h
> > > @@ -7,6 +7,8 @@
> > > #ifndef RISCV_CSR_ENCODING_H
>
[U-Boot] [PATCH] armv8: ls1028ardb: enable DisplayPort Power support
Enable DP_PWR signal to power the DP to HDMI converter cable.
Signed-off-by: Wen He
---
include/configs/ls1028a_common.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index 41ce4a054c..25fc548c99 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -135,6 +135,7 @@
"$kernelheader_size && esbc_validate ${kernelheader_addr_r}; "\
" bootm $load_addr#$board\0" \
"xspi_hdploadcmd=echo Trying load HDP firmware from FlexSPI...;" \
+ "i2c mw 0x66 0x54 0x0;" \
"sf probe 0:0 && sf read $load_addr 0x94 0x3 " \
"&& hdp load $load_addr 0x2000\0" \
"sd_bootcmd=echo Trying load from SD ...;" \
@@ -145,6 +146,7 @@
" && esbc_validate ${kernelheader_addr_r};" \
"bootm $load_addr#$board\0" \
"sd_hdploadcmd=echo Trying load HDP firmware from SD..;"\
+ "i2c mw 0x66 0x54 0x0;" \
"mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
"&& hdp load $load_addr 0x2000\0" \
"emmc_bootcmd=echo Trying load from EMMC ..;" \
@@ -155,6 +157,7 @@
" && esbc_validate ${kernelheader_addr_r};" \
"bootm $load_addr#$board\0" \
"emmc_hdploadcmd=echo Trying load HDP firmware from EMMC..;" \
+ "i2c mw 0x66 0x54 0x0;" \
"mmc dev 1;mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
"&& hdp load $load_addr 0x2000\0"
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] doc: bindings: add mdio.txt describing generic MDIO properties
On Wed, Jul 17, 2019 at 10:11 AM Alex Marginean wrote: > > Adds a binding document for mdio. A notable deviation from corresponding > Linux binding is the introduction of device-name optional property, which > can be used to name MDIO buses. Two reset optional properties described > by Linux binding are also not present as they don't seem to be used in > U-Boot at this time. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses
On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean wrote: > > Implicitly Marvell MDIO driver uses DT node names for devices, but in this > case that is not unique. Set MDIO device names for master/slave to > cpm/cps. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] drivers: net: add marvell MDIO driver
On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean wrote: > > This patch adds a separate driver for the MDIO interface of the > Marvell Ethernet controllers based on driver model. There are two > reasons to have a separate driver rather than including it inside > the MAC driver itself: > *) The MDIO interface is shared by all Ethernet ports, so a driver > must guarantee non-concurrent accesses to this MDIO interface. The > most logical way is to have a separate driver that handles this > single MDIO interface, used by all Ethernet ports. > *) The MDIO interface is the same between the existing mv643xx_eth > driver and the new mvneta/mvpp2 driver. Even though it is for now > only used by the mvneta/mvpp2 driver, it will in the future be > used by the mv643xx_eth driver as well. > > This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE > 802.3 Clause 45. > > This patch also adds device tree binding for marvell MDIO driver. > > Signed-off-by: Ken Ma > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: mdio-uclass: name MDIO according to device-name property if preset
On Wed, Jul 17, 2019 at 10:11 AM Alex Marginean wrote: > > Use the optional property device-name to name the MDIO bus. This works > around limitations with using the DT node name on devices such as > Armada-8040, which integrates two cp100 cores, both featuring MDIOs at the > same relative offsets and with the same DT node names. > The concept was originally proposed by Marvell as a custom property called > mdio-name specific to Marvell driver. This patch uses the more generic > property device-name and moves this into MDIO class code so other can use > it as well. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] NXP LS1021A-TSN Board
On Thu, Jul 18, 2019 at 4:33 PM Vladimir Oltean wrote: > > This patchset adds initial support for the NXP LS1021A-TSN board, > an evaluation platform built in partnership with VVDN/Argonboards > for some IEEE 802.1 TSN features. > > It features a cleaned-up U-Boot board support taken from OpenIL, > as well as an eTSEC migration to DM_ETH. I picked up Bin Meng's > patch that converts the LS1021A-TWR (different board, same SoC): > https://lists.denx.de/pipermail/u-boot/2018-May/330096.html > verified it on the LS1021A-TSN board I am submitting, and made a > few adjustments where necessary. > > TODO items: > - Make the eTSEC driver support fixed-link interfaces (necessary > for the enet2 <-> sja1105 internal port) > - Add driver for SJA1105 switch > - Potentially migrate the eTSEC MDIO bus driver to DM_MDIO and > expose the TBI PHY to mdio commands (useful for debugging), > once https://lists.denx.de/pipermail/u-boot/2019-June/371563.html > is merged. This series is merged at this point... are you wanting to do that migration now or do it sometime later? > > Bin Meng (1): > arm: ls1021atwr: Convert to use driver model TSEC driver > > Jianchao Wang (1): > Add support for the NXP LS1021A-TSN board > > Vladimir Oltean (7): > net: tsec: Refactor the readout of the tbi-handle property > net: tsec: Fix offset of MDIO registers for DM_ETH > net: tsec: Reverse Christmas tree notation > net: tsec: Make errors visible > net: tsec: Common handling of MAC station address for DM_ETH > net: tsec: Change compatible strings to match Linux > configs: ls1021atwr: Fix distro_bootcmd for QSPI boot > > arch/arm/Kconfig | 14 + > arch/arm/cpu/armv7/ls102xa/cpu.c | 2 +- > arch/arm/cpu/armv7/ls102xa/fdt.c | 10 + > arch/arm/dts/Makefile | 2 +- > arch/arm/dts/ls1021a-tsn.dts | 77 ++ > arch/arm/dts/ls1021a-twr.dtsi | 32 +++ > arch/arm/dts/ls1021a.dtsi | 30 +- > board/freescale/ls1021atsn/Kconfig| 18 ++ > board/freescale/ls1021atsn/MAINTAINERS| 8 + > board/freescale/ls1021atsn/Makefile | 3 + > board/freescale/ls1021atsn/README.rst | 97 +++ > board/freescale/ls1021atsn/ls1021atsn.c | 260 ++ > board/freescale/ls1021atsn/ls102xa_pbi.cfg| 15 + > board/freescale/ls1021atsn/ls102xa_rcw_sd.cfg | 8 + > board/freescale/ls1021atwr/ls1021atwr.c | 38 --- > configs/ls1021atsn_qspi_defconfig | 79 ++ > configs/ls1021atsn_sdcard_defconfig | 91 ++ > configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 2 + > configs/ls1021atwr_nor_defconfig | 2 + > configs/ls1021atwr_nor_lpuart_defconfig | 2 + > configs/ls1021atwr_qspi_defconfig | 2 + > ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 2 + > configs/ls1021atwr_sdcard_ifc_defconfig | 2 + > configs/ls1021atwr_sdcard_qspi_defconfig | 2 + > doc/device-tree-bindings/net/fsl-tsec-phy.txt | 4 +- > drivers/net/tsec.c| 59 ++-- > include/configs/ls1021atsn.h | 250 + > include/configs/ls1021atwr.h | 30 +- > include/tsec.h| 4 +- > 29 files changed, 1038 insertions(+), 107 deletions(-) > create mode 100644 arch/arm/dts/ls1021a-tsn.dts > create mode 100644 board/freescale/ls1021atsn/Kconfig > create mode 100644 board/freescale/ls1021atsn/MAINTAINERS > create mode 100644 board/freescale/ls1021atsn/Makefile > create mode 100644 board/freescale/ls1021atsn/README.rst > create mode 100644 board/freescale/ls1021atsn/ls1021atsn.c > create mode 100644 board/freescale/ls1021atsn/ls102xa_pbi.cfg > create mode 100644 board/freescale/ls1021atsn/ls102xa_rcw_sd.cfg > create mode 100644 configs/ls1021atsn_qspi_defconfig > create mode 100644 configs/ls1021atsn_sdcard_defconfig > create mode 100644 include/configs/ls1021atsn.h > > -- > 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: sun8i_emac: Test the correct phy
On Fri, Jul 19, 2019 at 3:27 PM Emmanuel Vadot wrote: > > H3/H5 can either use the internal phy or an external one. > Before getting clock and resets for the internal phy, > test that we are using it because otherwise it break emac > when using an external phy. > > Tested-on: OrangePi PC2 (H5) > Fixes: 2348453c41 (net: sun8i_emac: Add EPHY CLK and RESET support) > Signed-off-by: Emmanuel Vadot Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/3] net: introduce packet capture support
On Thu, Jul 18, 2019 at 1:44 PM Ramon Fried wrote:
>
> Add support for capturing ethernet packets and storing
> them in memory in PCAP(2.4) format, later to be analyzed by
> any PCAP viewer software (IE. Wireshark)
>
> This feature greatly assist debugging network issues such
> as detecting dropped packets, packet corruption etc.
>
> Signed-off-by: Ramon Fried
> Reviewed-by: Alex Marginean
> Tested-by: Alex Marginean
>
> ---
>
> Changes in v4:
> * Move implementation to pcap.c/pcap.h
> * Display error message when memory is exhausted.
> * Populate $pcapsize environment variable with actual capture
> size.
> * move outgoing pcap_post to eth_send()
>
> Changes in v3:
> * Change to implementation to command based.
> * Added counters for incoming/outgoing packets.
> * Support clearing the capture for multiple captures.
> * Added documentation (separate patch).
>
> Changes in v2:
> Fix type assignmnet to header.ts_sec
[ ... ]
> diff --git a/net/pcap.c b/net/pcap.c
> new file mode 100644
> index 00..4036d8a3fa
> --- /dev/null
> +++ b/net/pcap.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 Ramon Fried
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define LINKTYPE_ETHERNET 1
> +
> +static bool initialized;
> +static bool running;
> +static bool buffer_full;
> +static void *buf;
> +static unsigned int max_size;
> +static unsigned int pos;
> +
> +static unsigned long incoming_count;
> +static unsigned long outgoing_count;
> +
> +struct pcap_header {
> + u32 magic;
> + u16 version_major;
> + u16 version_minor;
> + s32 thiszone;
> + u32 sigfigs;
> + u32 snaplen;
> + u32 network;
> +};
> +
> +struct pcap_packet_header {
> + u32 ts_sec;
> + u32 ts_usec;
> + u32 incl_len;
> + u32 orig_len;
> +};
> +
> +static struct pcap_header file_header = {
> + .magic = 0xa1b2c3d4,
> + .version_major = 2,
> + .version_minor = 4,
> + .snaplen = 65535,
> + .network = LINKTYPE_ETHERNET,
> +};
> +
> +int pcap_init(phys_addr_t paddr, unsigned long size)
> +{
> + buf = map_physmem(paddr, size, 0);
Since this is mapping to physmem, and apparently from your
documentation, you need to use the physical memory when writing to a
file or tftp send, how is the mapping typically handled? Maybe we
should be writing to a variable like "pcapaddr" so it can be used in
the write as part of a script.
> + if (!buf) {
> + printf("Failed mapping PCAP memory\n");
> + return -ENOMEM;
> + }
> +
> + printf("PCAP capture initialized: addr: 0x%lx max length: %lu\n",
> + (unsigned long)buf, size);
> +
> + memcpy(buf, _header, sizeof(file_header));
> + pos = sizeof(file_header);
> + max_size = size;
> + initialized = true;
> + running = false;
> + buffer_full = false;
> + incoming_count = 0;
> + outgoing_count = 0;
> + return 0;
> +}
> +
> +int pcap_start_stop(bool start)
> +{
> + if (!initialized) {
> + printf("error: pcap was not initialized\n");
> + return -ENODEV;
> + }
> +
> + running = start;
> +
> + return 0;
> +}
> +
> +int pcap_clear(void)
> +{
> + if (!initialized) {
> + printf("error: pcap was not initialized\n");
> + return -ENODEV;
> + }
> +
> + pos = sizeof(file_header);
> + incoming_count = 0;
> + outgoing_count = 0;
> + buffer_full = false;
> +
> + printf("pcap capture cleared\n");
> + return 0;
> +}
> +
> +int pcap_post(const void *packet, size_t len, bool outgoing)
> +{
> + struct pcap_packet_header header;
> + u64 cur_time = timer_get_us();
> +
> + if (!initialized || !running || !buf)
> + return -ENODEV;
> +
> + if (buffer_full)
> + return -ENOMEM;
> +
> + if ((pos + len + sizeof(header)) >= max_size) {
> + buffer_full = true;
> + printf("\n!!! Buffer is full, consider increasing buffer size
> !!!\n");
> + return -ENOMEM;
> + }
> +
> + header.ts_sec = cur_time / 100;
> + header.ts_usec = cur_time % 100;
> + header.incl_len = len;
> + header.orig_len = len;
> +
> + memcpy(buf + pos, , sizeof(header));
> + pos += sizeof(header);
> + memcpy(buf + pos, packet, len);
> + pos += len;
> +
> + if (outgoing)
> + outgoing_count++;
> + else
> + incoming_count++;
> +
> + env_set_hex("pcapsize", pos);
> +
> + return 0;
> +}
> +
> +int pcap_print_status(void)
> +{
> + if (!initialized) {
> + printf("pcap was not initialized\n");
> + return -ENODEV;
> + }
> + printf("PCAP status:\n");
> + printf("\tInitialized addr: 0x%lx\tmax length: %u\n",
> +
Re: [U-Boot] [PATCH v4 3/3] configs: sandbox: enable PCAP capture cmd
On Thu, Jul 18, 2019 at 1:44 PM Ramon Fried wrote: > > Enable CONFIG_CMD_PCAP for testing PCAP capture. > > Signed-off-by: Ramon Fried Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: net: fsl_enetc: add support for SGMII 2500
On Mon, Jul 15, 2019 at 3:49 AM Alex Marginean wrote: > > SGMII 2500 as supported on NXP SoCs requires AN to be disabled, handle > this case in the enetc sgmii init code. > > Signed-off-by: Alex Marginean In the future, please make sure to mention any dependencies on outstanding patches. Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: designware: use 'phy_connect' instead of open coded
On Mon, Jul 15, 2019 at 2:53 PM Simon Goldschmidt wrote: > > Using 'phy_connect' instead of 'phy_find_by_mask' and 'phy_connect_dev' > both deduplicates code and adds support for 'fixed-link'. > > Signed-off-by: Simon Goldschmidt Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] configs: ls1028a: enable networking options in rdb, qds defconfig
On Wed, Jul 3, 2019 at 4:14 AM Alex Marginean wrote: > > Enables ethernet, MDIO, PHY drivers for LS1028A RDB and QDS. > > Signed-off-by: Alex Marginean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/6] arm: dts: ls1028a updates for network interfaces
On Wed, Jul 3, 2019 at 4:12 AM Alex Marginean wrote: > > Defines LS1028A RDB SGMII port, QDS RGMII port. > > Signed-off-by: Alex Marginean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/6] drivers: net: apply serdes configuration for ENETC Ethernet interfaces
On Wed, Jul 3, 2019 at 4:13 AM Alex Marginean wrote: > > Ethernet interfaces using serial protocols go through the serdes block > integrated in the SoC. This is accessed over dedicated internal MDIOs > which are part of the Ethernet PCI functions. Set up serdes at _start, > along with other protocol specific port/MAC configuration. > MDIO code is shared with enetc_mdio, read/write functions are exported > from fsl_enetc_mdio for this reason. > > Signed-off-by: Alex Marginean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
El 22/7/19 a las 12:15, Peter Robinson escribió: On Mon, Jul 22, 2019 at 2:36 PM Tom Rini wrote: On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt wrote: In GRUB before 2.04 a bug existed which did not allow booting some ARM32 boards if U-Boot did not disable caches, cf. https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html In ExitBootServices() we were disabling the caches by calling cleanup_before_linux(). This workaround is not needed anymore. Do we want to remove this straight away? A lot of distributions will take time to move to grub 2.04 because it's been a long time between grub releases so they'll have quite a patch delta to re-align to the new release. Fedora for example will rebase to grub 2.04 in Fedora 32 which will start development end of August but won't be released until next year. As described below this code does not remove any functionality that was active in U-Boot v2019.04 or v2019.07. I can see nothing in https://fedoraproject.org/wiki/Updates_Policy stopping GRUB 2.04 from being made available for stable Fedora releases. The maintainers believe that it's too intrusive to land now and they want maximum testing time before it gets to stable users, funnily enough people don't like it when their machines cease to boot. Why should anybody's machines cease to boot? If Fedora does not role out a new U-Boot they are fine. If Fedora roles out a new U-Boot they should role out a matching GRUB and they are fine too. The venturous who build their own U-Boot should know how to role back their system if needed. You've clearly never maintained a distribution across 1000s of device types and 100s of thousands of users. We will be shipping Fedora 31 with U-Boot 2019.10 and the current version of grub that the maintainers wish to support, if that requires me to revert a number of your changes I will, which will be an inconvenience and probably take more time than I have spare but I will survive. I find it strange you fix one OS only to break another. How will this work for users that want to boot a newly released device which has recently added U-Boot support to an already released stable OS? If you wish to actively break currently working use cases that's your prerogative that is your choice but I find breaking currently working use cases without a reasonable window to migrate dependencies actively hostile which has tended to not be the way U-Boot has worked in the past for such things as DM, so breaking a interface to the way OSes boot IMO is even worse. OK, we have a problem here. A better example than DM would be the various work-arounds we have (or carried for ages) to allow using newer U-Boot with various old and broken kernels. So no, we need to keep this work-around for a long while. What's the EOL date for any Linux distribution that uses this broken grub? The first U-Boot release post that EOL date is when we can drop this particular bit of work-around code. Well Fedora 31 would be EOL around Nov/Dec 2020, and while I know the CentOS team uses the Fedora U-Boot but I believe they boot their arm-32 instances with extlinux to date. I can't speak for any of the other distros in this regard. Well, that is true for CentOS7, but for CentOS8 the plan is to boot using EFI also. Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot Pablo. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Remote code execution vulnerabilities in U-Boot's NFS and other IP parsing code
Hello,
Find attached more information about 13 vulnerabilities we found at
U-Boot and its NFS and networking code. Also, find attached a proposed
quick patch that should serve as a first initial one and should
probably go through iterations of code review.
Please note, these vulnerabilities are not patched yet at the source
repository. Tom Rini (U-boot's master custodian) requested the
attached report to be published at this mailing list. At this time,
and because of this email, we consider these vulnerabilities public.
For reference, MITRE has issued CVEs for the vulnerabilities:
CVE-2019-14192, CVE-2019-14193, CVE-2019-14194, CVE-2019-14195,
CVE-2019-14196, CVE-2019-14197, CVE-2019-14198, CVE-2019-14199,
CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and
CVE-2019-14204
Best regards,
--
Fermin
Semmle Security Research Team
Semmle security advisory: U-Boot, 13 vulnerabilities leading to potential
remote code execution
Date: 5/23/2019
Status: Developers contacted, patch proposed and waiting for CVEs
Author(s): Fermin J. Serna, Pavel Avgustinov and Kevin Backhouse
CVE(s) assigned: CVE-2019-14192, CVE-2019-14193, CVE-2019-14194,
CVE-2019-14195, CVE-2019-14196, CVE-2019-14197, CVE-2019-14198, CVE-2019-14199,
CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and
CVE-2019-14204
1.- Overview:
Das U-Boot [1] (commonly known as “universal boot loader”) is a popular primary
bootloader widely used in embedded devices to fetch from different sources and
run the next stage code, commonly but not limited to a Linux Kernel. It is
commonly used by IoT devices but also Kindle and ARM ChromeOS devices.
U-Boot supports fetching the next stage code from different file partition
formats (ext4 as an example) but also from the network (TFTP and NFS). Please
note, U-boot supports verified boot [2] where the image fetched is checked for
tampering, mitigating the risks of using insecure cleartext protocols such as
TFTP and NFS, so any vulnerability before the signature check could mean a
device jailbreak.
The first vulnerability was found via source code review and we used Semmle’s
LGTM.com and QL to find the others. We used the following query [3] that gave us
a very manageable list of 9 results to follow up manually.
We ended up identifying 7 different memcpy-ish call sites with attacked
controlled source buffer and unchecked lengths. Additionally, after some code
review we found 5 new additional stack based buffer overflows and an extra read
out of bounds vulnerability.
2. - Technical description:
2.1. - Unbound memcpy with unvalidated length at nfs_readlink_reply (x2)
The problem exists at the nfs_readlink_reply [4] function that parses an nfs
reply coming from the network. It parses 4 bytes and without any further
validations it uses them as length for a memcpy in two different locations.
static int nfs_readlink_reply(uchar *pkt, unsigned len)
{
[...]
/* new path length */
rlen = ntohl(rpc_pkt.u.reply.data[1 + nfsv3_data_offset]);
if (*((char *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset])) != '/') {
int pathlen;
strcat(nfs_path, "/");
pathlen = strlen(nfs_path);
memcpy(nfs_path + pathlen,
(uchar *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset]),
rlen);
nfs_path[pathlen + rlen] = 0;
} else {
memcpy(nfs_path,
(uchar *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset]),
rlen);
nfs_path[rlen] = 0;
}
return 0;
}
The destination buffer nfs_path [5] is a global one that can hold up to 2048
bytes.
2.2. - Unbound memcpy with a failed length check at nfs_lookup_reply
The problem exists at the nfs_lookup_reply [6] function that again parses an
nfs reply coming from the network. It parses 4 bytes and uses them as length for
a memcpy in two different locations.
A length check happens to make sure it is not bigger than the allocated buffer.
Unfortunately this check can be bypassed with a negative value that would lead
later to a large buffer overflow.
filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
if (filefh3_length > NFS3_FHSIZE)
filefh3_length = NFS3_FHSIZE;
memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
The destination buffer nfs_path [7] is a global one that can hold up to 64
bytes.
2.3.- Unbound memcpy with a failed length check at nfs_read_reply/store_block
(x2)
The problem exists at the nfs_read_reply [8] function when reading a file and
storing it into other medium (flash or physical memory) for later processing.
Again, the data and length is fully controlled by the attacker and never
validated.
static int nfs_read_reply(uchar *pkt, unsigned len)
{
[...]
if (supported_nfs_versions & NFSV2_FLAG)
Re: [U-Boot] [PATCH v4 3/6] drivers: net: add NXP ENETC MDIO driver
On Wed, Jul 3, 2019 at 4:15 AM Alex Marginean wrote: > > Adds a driver for the MDIO interface currently integrated in LS1028A SoC. > This MDIO interface is shared by multiple ethernet interfaces and is > presented as a stand-alone PCI function on the SoC ECAM. > Ethernet has a functional dependency on MDIO, for simplicity there is a > single config option for both. > > Signed-off-by: Alex Marginean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] drivers: net: add NXP ENETC ethernet driver
On Wed, Jul 3, 2019 at 4:13 AM Alex Marginean wrote: > > Adds a driver for NXP ENETC ethernet controller currently integrated in > LS1028A. ENETC is a fairly straight-forward BD ring device and interfaces > are presented as PCI EPs on the SoC ECAM. > > Signed-off-by: Catalin Horghidan > Signed-off-by: Alex Marginean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/6] include: configs: ls1028a: set SYS_RX_ETH_BUFFER to 8
On Wed, Jul 3, 2019 at 4:14 AM Alex Marginean wrote: > > LS1028A ethernet interfaces work with at least 8 BDs, set number of buffers > to match that. > > Signed-off-by: Alex Marginean > Reviewed-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: davinci_emac: convert to using the driver model
On Mon, Jun 24, 2019 at 9:22 AM Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > Now that we removed all legacy boards selecting TI_EMAC we can > completely convert the driver code to using the driver model. > This patch also updates all remaining users of davinci_emac. > > Signed-off-by: Bartosz Golaszewski Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Mon, Jul 22, 2019 at 09:29:21PM +0200, Mark Kettenis wrote: > > Date: Mon, 22 Jul 2019 09:36:38 -0400 > > From: Tom Rini > > > > On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > > > > >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > > > > >>> wrote: > > > > > > > > In GRUB before 2.04 a bug existed which did not allow booting some > > > > ARM32 > > > > boards if U-Boot did not disable caches, cf. > > > > https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > > > > > > > > In ExitBootServices() we were disabling the caches by calling > > > > cleanup_before_linux(). This workaround is not needed anymore. > > > > >>> > > > > >>> Do we want to remove this straight away? A lot of distributions will > > > > >>> take time to move to grub 2.04 because it's been a long time between > > > > >>> grub releases so they'll have quite a patch delta to re-align to the > > > > >>> new release. Fedora for example will rebase to grub 2.04 in Fedora > > > > >>> 32 > > > > >>> which will start development end of August but won't be released > > > > >>> until > > > > >>> next year. > > > > >> > > > > >> As described below this code does not remove any functionality that > > > > >> was > > > > >> active in U-Boot v2019.04 or v2019.07. > > > > >> > > > > >> I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > > > > >> stopping GRUB 2.04 from being made available for stable Fedora > > > > >> releases. > > > > > > > > > > The maintainers believe that it's too intrusive to land now and they > > > > > want maximum testing time before it gets to stable users, funnily > > > > > enough people don't like it when their machines cease to boot. > > > > > > > > Why should anybody's machines cease to boot? > > > > > > > > If Fedora does not role out a new U-Boot they are fine. If Fedora roles > > > > out a new U-Boot they should role out a matching GRUB and they are fine > > > > too. > > > > > > > > The venturous who build their own U-Boot should know how to role back > > > > their system if needed. > > > > > > You've clearly never maintained a distribution across 1000s of device > > > types and 100s of thousands of users. > > > > > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > > > version of grub that the maintainers wish to support, if that requires > > > me to revert a number of your changes I will, which will be an > > > inconvenience and probably take more time than I have spare but I will > > > survive. I find it strange you fix one OS only to break another. How > > > will this work for users that want to boot a newly released device > > > which has recently added U-Boot support to an already released stable > > > OS? > > > > > > If you wish to actively break currently working use cases that's your > > > prerogative that is your choice but I find breaking currently working > > > use cases without a reasonable window to migrate dependencies actively > > > hostile which has tended to not be the way U-Boot has worked in the > > > past for such things as DM, so breaking a interface to the way OSes > > > boot IMO is even worse. > > > > OK, we have a problem here. A better example than DM would be the > > various work-arounds we have (or carried for ages) to allow using newer > > U-Boot with various old and broken kernels. So no, we need to keep this > > work-around for a long while. What's the EOL date for any Linux > > distribution that uses this broken grub? The first U-Boot release post > > that EOL date is when we can drop this particular bit of work-around > > code. > > Hi Tom, > > Things are a bit more complicated. The breakage was introduced in > 2019.04 as part of some efi_loader refacoring. Further refactoring in > 2019.07 makes a simple revert impossible. > > I committed code to the OpenBSD/armv7 bootloader today that disables > the architecturally defined caches and MMU. However, that isn't > enough to fix the breakage on all boards as some board configurations > enable the non-architectural L2 cache. I believe that even with grub > 2.04 bootling a Linux kernel is broken on boards with such an L2 cache > as well. > > If the L2 cache issue is addressed, OpenBSD will be fine. OpenBSD 6.5 > shipped with a U-Boot 2019.01 package, and OpenBSD 6.6 will have the > fixed bootloader. > > I'm not sure how to fix the L2 cache issue though. I see two options: > > 1. Enable CONFIG_SYS_L2CACHE_OFF on all 32-bit ARM boards if the EFI >loader is enabled. Some board maintainers could object though >since this probably makes U-Boot a bit slower. And it would be bad >if that would lead them towards disabling the EFI loader. > > 2. Disable the L2 cache whenever the EFI loader is first entered. I'm >not sure if this is possible while keeping the caches enabled. Thanks for explaining the background issues here, I was unaware. Would it be possible to introduce a work-around in
Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N
On Thu, 18 Jul 2019 09:12:02 +0200 Lukasz Majewski wrote: > Hi Peng, > > > Hi Lukasz, Stefano, > > > > > > > > > > > > > > Subject: Re: [U-Boot] [PATCH 00/52] Support i.MX8MM/N > > [] > > > > > > > > > > The v5 of CCF has been posted ~2 weeks ago (with you on CC) > > > > > with a high chance to be pulled by Stefano after the merge > > > > > window opens. > > > > > > > > > > When we accept the "legacy" clock approach we will stuck with > > > > > it for a long time. > > > > > > > > > > What approach is took by the Linux kernel? CCF or any other > > > > > one? > > > > > > > > I am not against CCF. I tried CCF and enabled on i.MX8MM in my > > > > last patchset. But I have to add lots of code based on your > > > > version, that introduces complexity for now. > > > > > > You will have to add this complexity anyway after people start > > > demanding new clocks for IPs which they need to enable. > > > > > > Moreover, the CCF v5 was posted 2 weeks ago - wasn't it enough > > > time for applying your patches from v4? > > > > I have converted back to CCF for i.MX8MM/N. Pushed code > > to https://github.com/MrVan/u-boot/commits/imx8mmn-ccf > > > > Since there are 65 patches in my patchset, I not post to maillist. > > > > Please see whether you have some general comments or not. > > I will try to provide some comments today. Thanks for the conversion. Your patches from the github tree up to [1] seems to not touch the core clock code and extend only clk-* (gate, mux, etc.) files. They are similar to what you have posted previously on top of v4. Two remarks: - Please extract those CCF related github patches, port them on top of master with Stefano's last PR pulled and send to U-Boot mailing list (for final review and testing). - I think that you can extend the sandbox test code [2] for binded clocks [3] - for example to read a clk freq value from such clock. Also test if the logic for "hiding" them works. [1] - https://github.com/MrVan/u-boot/commit/1a9b13178be10d0c6c6834808c36877b5b2dc49f [2] - https://github.com/MrVan/u-boot/commit/a89ca577c8c26aa962664dfe1f8e9fec1dd83f65 [3] - https://github.com/MrVan/u-boot/commit/a088106f1b90b7ef6b7128c2c17671cd4d376aa9 > > > Then I'll post out to mail list. Hope it could catch this release > > cycle. > > Let's be optimistic. > > > > > Thanks, > > Peng. > > > > > > > > > > > > > > > > > > > > We might try to switch to CCF again in future, > > > > > > > > > > I'm a bit skeptical about such statements. It never works like > > > > > that > > > > > - after it is accepted it would become a "legacy code which we > > > > > do need to preserve". > > > > > > but we hope > > > > > > i.MX8MM/N support could land in upstream soon. It has been > > > > > > pending for months. > > > > > > > > > > Was the CCF the reason for the i.MX8 not being pulled for so > > > > > long? > > > > > > > > I am not saying so. > > > > > > > > The first version to support i.MX8MM is in 2019-01-28. Then I > > > > switch to CCF and posted out new version in 2019-4-30. > > > > > > Maybe the version posted in 2019-01-28 was just not ready for > > > being pulled? > > > > > > It happens that the community wants to avoid problems encountered > > > earlier with other SoCs (like i.MX6, i.MX7), so the discussion > > > takes time. > > > > > > (The similar situation is with other projects too - how many > > > release cycles it takes to add new SoC in Linux? Or new port to > > > glibc?). > > > > we have many 3rd parties want to use mainline U-Boot, not our > > > > vendor tree. > > > > > > There must be a reason that they want the U-Boot mainline. IMHO > > > the main reason for it is that people not only from a single > > > company want to add the code, so they need to discuss (and get the > > > agreement) to avoid stepping in each other's toes. > > > > > > And the discussion/tests takes time ... > > > > > > > I hope > > > > i.MX8MM/N could land in the coming merge window, > > > > > > This depends solely on the code quality I think. > > > > > > > introducing more to CCF add risk. > > > > > > Risk for not being accepted? > > > > > > I do see however other risk - the i.MX8 will gain one-off clock > > > support code instead of adopting the CCF just from the outset. > > > > > > > > > > > > > > Thanks, > > > > Peng. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Peng. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bai Ping (1): > > > > > > > > imx8mq: Update the ddrc QoS setting for B1 chip > > > > > > > > > > > > > > > > Jacky Bai (2): > > > > > > > > driver: ddr: Refine the ddr init driver on imx8m > > > > > > > > ddr: imx8m: Fix the ddr init hang on imx8mq > > > > > > > > > > > > > > > > Peng Fan (47): > > > > > > > > linux: compat: guard PAGE_SIZE > > > > > > > > dm: clk: ignore default settings when node not valid > > > > > > > > pinctrl:
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
El 22/7/19 a las 12:15, Peter Robinson escribió: On Mon, Jul 22, 2019 at 2:36 PM Tom Rini wrote: On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt wrote: In GRUB before 2.04 a bug existed which did not allow booting some ARM32 boards if U-Boot did not disable caches, cf. https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html In ExitBootServices() we were disabling the caches by calling cleanup_before_linux(). This workaround is not needed anymore. Do we want to remove this straight away? A lot of distributions will take time to move to grub 2.04 because it's been a long time between grub releases so they'll have quite a patch delta to re-align to the new release. Fedora for example will rebase to grub 2.04 in Fedora 32 which will start development end of August but won't be released until next year. As described below this code does not remove any functionality that was active in U-Boot v2019.04 or v2019.07. I can see nothing in https://fedoraproject.org/wiki/Updates_Policy stopping GRUB 2.04 from being made available for stable Fedora releases. The maintainers believe that it's too intrusive to land now and they want maximum testing time before it gets to stable users, funnily enough people don't like it when their machines cease to boot. Why should anybody's machines cease to boot? If Fedora does not role out a new U-Boot they are fine. If Fedora roles out a new U-Boot they should role out a matching GRUB and they are fine too. The venturous who build their own U-Boot should know how to role back their system if needed. You've clearly never maintained a distribution across 1000s of device types and 100s of thousands of users. We will be shipping Fedora 31 with U-Boot 2019.10 and the current version of grub that the maintainers wish to support, if that requires me to revert a number of your changes I will, which will be an inconvenience and probably take more time than I have spare but I will survive. I find it strange you fix one OS only to break another. How will this work for users that want to boot a newly released device which has recently added U-Boot support to an already released stable OS? If you wish to actively break currently working use cases that's your prerogative that is your choice but I find breaking currently working use cases without a reasonable window to migrate dependencies actively hostile which has tended to not be the way U-Boot has worked in the past for such things as DM, so breaking a interface to the way OSes boot IMO is even worse. OK, we have a problem here. A better example than DM would be the various work-arounds we have (or carried for ages) to allow using newer U-Boot with various old and broken kernels. So no, we need to keep this work-around for a long while. What's the EOL date for any Linux distribution that uses this broken grub? The first U-Boot release post that EOL date is when we can drop this particular bit of work-around code. Well Fedora 31 would be EOL around Nov/Dec 2020, and while I know the CentOS team uses the Fedora U-Boot but I believe they boot their arm-32 instances with extlinux to date. I can't speak for any of the other distros in this regard. Well, that is true for CentOS7, but for CentOS8 the plan is to boot using EFI also. Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot Pablo. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Lukasz, On Mon, Jul 22, 2019 at 5:52 PM Lukasz Majewski wrote: > This patch seems to be already applied to master branch of U-Boot: > SHA1: 2c72ead7387404eba16c556d2f204c52c36c27f9 Excellent! Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Fabio, Stefano, > Hi Lukasz and Stefano, > > On Tue, Jun 11, 2019 at 10:53 AM Lukasz Majewski > wrote: > > > > Hi Fabio, Stefano, > > > > > Hi Stefano, > > > > > > On Tue, Jun 11, 2019 at 10:11 AM Stefano Babic > > > wrote: > > > > I have no comments, but from the discussion I felt there are > > > > still some issues and I left it over. > > > > > > Lukasz reported an issue initially, but after adjusting the VID / > > > PID he managed to get it to work. > > > > > > Lukasz, please confirm. > > > > I can confirm that I made it working on v2019-rc3 (on display5) > > after adjusting VID/PID with NXP's 'uuu' utility to recovery i.MX6Q > > board. > > Do you think this one could be applied? This patch seems to be already applied to master branch of U-Boot: SHA1: 2c72ead7387404eba16c556d2f204c52c36c27f9 > > Without it, I can not load a fit image via USB on imx6sabresd. > > Thanks Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpi5j2DlcpMS.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
> Date: Mon, 22 Jul 2019 09:36:38 -0400 > From: Tom Rini > > On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > > > >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > > > >>> wrote: > > > > > > In GRUB before 2.04 a bug existed which did not allow booting some > > > ARM32 > > > boards if U-Boot did not disable caches, cf. > > > https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > > > > > > In ExitBootServices() we were disabling the caches by calling > > > cleanup_before_linux(). This workaround is not needed anymore. > > > >>> > > > >>> Do we want to remove this straight away? A lot of distributions will > > > >>> take time to move to grub 2.04 because it's been a long time between > > > >>> grub releases so they'll have quite a patch delta to re-align to the > > > >>> new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > > > >>> which will start development end of August but won't be released until > > > >>> next year. > > > >> > > > >> As described below this code does not remove any functionality that was > > > >> active in U-Boot v2019.04 or v2019.07. > > > >> > > > >> I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > > > >> stopping GRUB 2.04 from being made available for stable Fedora > > > >> releases. > > > > > > > > The maintainers believe that it's too intrusive to land now and they > > > > want maximum testing time before it gets to stable users, funnily > > > > enough people don't like it when their machines cease to boot. > > > > > > Why should anybody's machines cease to boot? > > > > > > If Fedora does not role out a new U-Boot they are fine. If Fedora roles > > > out a new U-Boot they should role out a matching GRUB and they are fine > > > too. > > > > > > The venturous who build their own U-Boot should know how to role back > > > their system if needed. > > > > You've clearly never maintained a distribution across 1000s of device > > types and 100s of thousands of users. > > > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > > version of grub that the maintainers wish to support, if that requires > > me to revert a number of your changes I will, which will be an > > inconvenience and probably take more time than I have spare but I will > > survive. I find it strange you fix one OS only to break another. How > > will this work for users that want to boot a newly released device > > which has recently added U-Boot support to an already released stable > > OS? > > > > If you wish to actively break currently working use cases that's your > > prerogative that is your choice but I find breaking currently working > > use cases without a reasonable window to migrate dependencies actively > > hostile which has tended to not be the way U-Boot has worked in the > > past for such things as DM, so breaking a interface to the way OSes > > boot IMO is even worse. > > OK, we have a problem here. A better example than DM would be the > various work-arounds we have (or carried for ages) to allow using newer > U-Boot with various old and broken kernels. So no, we need to keep this > work-around for a long while. What's the EOL date for any Linux > distribution that uses this broken grub? The first U-Boot release post > that EOL date is when we can drop this particular bit of work-around > code. Hi Tom, Things are a bit more complicated. The breakage was introduced in 2019.04 as part of some efi_loader refacoring. Further refactoring in 2019.07 makes a simple revert impossible. I committed code to the OpenBSD/armv7 bootloader today that disables the architecturally defined caches and MMU. However, that isn't enough to fix the breakage on all boards as some board configurations enable the non-architectural L2 cache. I believe that even with grub 2.04 bootling a Linux kernel is broken on boards with such an L2 cache as well. If the L2 cache issue is addressed, OpenBSD will be fine. OpenBSD 6.5 shipped with a U-Boot 2019.01 package, and OpenBSD 6.6 will have the fixed bootloader. I'm not sure how to fix the L2 cache issue though. I see two options: 1. Enable CONFIG_SYS_L2CACHE_OFF on all 32-bit ARM boards if the EFI loader is enabled. Some board maintainers could object though since this probably makes U-Boot a bit slower. And it would be bad if that would lead them towards disabling the EFI loader. 2. Disable the L2 cache whenever the EFI loader is first entered. I'm not sure if this is possible while keeping the caches enabled. Cheers, Mark ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Mon, Jul 22, 2019 at 09:07:40PM +0200, Heinrich Schuchardt wrote: > On 7/22/19 9:02 PM, Tom Rini wrote: > >On Mon, Jul 22, 2019 at 08:51:41PM +0200, Heinrich Schuchardt wrote: > >>On 7/22/19 3:36 PM, Tom Rini wrote: > >>>On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > wrote: > > > >In GRUB before 2.04 a bug existed which did not allow booting some > >ARM32 > >boards if U-Boot did not disable caches, cf. > >https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > > > >In ExitBootServices() we were disabling the caches by calling > >cleanup_before_linux(). This workaround is not needed anymore. > > Do we want to remove this straight away? A lot of distributions will > take time to move to grub 2.04 because it's been a long time between > grub releases so they'll have quite a patch delta to re-align to the > new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > which will start development end of August but won't be released until > next year. > >>> > >>>As described below this code does not remove any functionality that was > >>>active in U-Boot v2019.04 or v2019.07. > >>> > >>>I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > >>>stopping GRUB 2.04 from being made available for stable Fedora > >>>releases. > >> > >>The maintainers believe that it's too intrusive to land now and they > >>want maximum testing time before it gets to stable users, funnily > >>enough people don't like it when their machines cease to boot. > > > >Why should anybody's machines cease to boot? > > > >If Fedora does not role out a new U-Boot they are fine. If Fedora roles > >out a new U-Boot they should role out a matching GRUB and they are fine > >too. > > > >The venturous who build their own U-Boot should know how to role back > >their system if needed. > > You've clearly never maintained a distribution across 1000s of device > types and 100s of thousands of users. > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > version of grub that the maintainers wish to support, if that requires > me to revert a number of your changes I will, which will be an > inconvenience and probably take more time than I have spare but I will > survive. I find it strange you fix one OS only to break another. How > will this work for users that want to boot a newly released device > which has recently added U-Boot support to an already released stable > OS? > > If you wish to actively break currently working use cases that's your > prerogative that is your choice but I find breaking currently working > use cases without a reasonable window to migrate dependencies actively > hostile which has tended to not be the way U-Boot has worked in the > past for such things as DM, so breaking a interface to the way OSes > boot IMO is even worse. > >>> > >>>OK, we have a problem here. A better example than DM would be the > >>>various work-arounds we have (or carried for ages) to allow using newer > >>>U-Boot with various old and broken kernels. So no, we need to keep this > >>>work-around for a long while. What's the EOL date for any Linux > >>>distribution that uses this broken grub? The first U-Boot release post > >>>that EOL date is when we can drop this particular bit of work-around > >>>code. > >> > >>The current behavior contradicts the UEFI spec. Our target is to > >>implement a UEFI compliant firmware. > > > >Our target is to be both compliant and functional, and functional wins. > > > >>If OpenBSD does not change their broken boot loader will we never > >>correct U-Boot? That would not make sense to me. > > > >I'm sorry, I don't see the connection. It's not "GRUB won't change to > >be compliant" it's "GRUB changed things but it's going to take a long > >while for that to be deployed out". > > > >>Old distros tend not to to update their U-Boot release. E.g. Debian > >>Stretch is still on U-Boot v2016.11. So why would you care about its EOL? > > > >Because I want to make it really hard for people to end up in a "does > >not boot now" mode. > > > >>I could agree if you suggested that we should re-enable the workaround > >>until the major distros use a compatible GRUB in their stable release > >>like Debian Buster does. > >> > >>Let's be proactive and analyze if anything is missing in Fedora Rawhide > >>GRUB. If yes, we should contact the maintainer and clarify which > >>adjustments are possible until the Fedora 31 release. > > > >I don't want it to be "just latest stable has it". I want it to be > >"supported releases have it". > > RHEL distros are supported for 10 years. Are you serious? RHEL doesn't support
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On 7/22/19 9:02 PM, Tom Rini wrote: On Mon, Jul 22, 2019 at 08:51:41PM +0200, Heinrich Schuchardt wrote: On 7/22/19 3:36 PM, Tom Rini wrote: On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt wrote: In GRUB before 2.04 a bug existed which did not allow booting some ARM32 boards if U-Boot did not disable caches, cf. https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html In ExitBootServices() we were disabling the caches by calling cleanup_before_linux(). This workaround is not needed anymore. Do we want to remove this straight away? A lot of distributions will take time to move to grub 2.04 because it's been a long time between grub releases so they'll have quite a patch delta to re-align to the new release. Fedora for example will rebase to grub 2.04 in Fedora 32 which will start development end of August but won't be released until next year. As described below this code does not remove any functionality that was active in U-Boot v2019.04 or v2019.07. I can see nothing in https://fedoraproject.org/wiki/Updates_Policy stopping GRUB 2.04 from being made available for stable Fedora releases. The maintainers believe that it's too intrusive to land now and they want maximum testing time before it gets to stable users, funnily enough people don't like it when their machines cease to boot. Why should anybody's machines cease to boot? If Fedora does not role out a new U-Boot they are fine. If Fedora roles out a new U-Boot they should role out a matching GRUB and they are fine too. The venturous who build their own U-Boot should know how to role back their system if needed. You've clearly never maintained a distribution across 1000s of device types and 100s of thousands of users. We will be shipping Fedora 31 with U-Boot 2019.10 and the current version of grub that the maintainers wish to support, if that requires me to revert a number of your changes I will, which will be an inconvenience and probably take more time than I have spare but I will survive. I find it strange you fix one OS only to break another. How will this work for users that want to boot a newly released device which has recently added U-Boot support to an already released stable OS? If you wish to actively break currently working use cases that's your prerogative that is your choice but I find breaking currently working use cases without a reasonable window to migrate dependencies actively hostile which has tended to not be the way U-Boot has worked in the past for such things as DM, so breaking a interface to the way OSes boot IMO is even worse. OK, we have a problem here. A better example than DM would be the various work-arounds we have (or carried for ages) to allow using newer U-Boot with various old and broken kernels. So no, we need to keep this work-around for a long while. What's the EOL date for any Linux distribution that uses this broken grub? The first U-Boot release post that EOL date is when we can drop this particular bit of work-around code. The current behavior contradicts the UEFI spec. Our target is to implement a UEFI compliant firmware. Our target is to be both compliant and functional, and functional wins. If OpenBSD does not change their broken boot loader will we never correct U-Boot? That would not make sense to me. I'm sorry, I don't see the connection. It's not "GRUB won't change to be compliant" it's "GRUB changed things but it's going to take a long while for that to be deployed out". Old distros tend not to to update their U-Boot release. E.g. Debian Stretch is still on U-Boot v2016.11. So why would you care about its EOL? Because I want to make it really hard for people to end up in a "does not boot now" mode. I could agree if you suggested that we should re-enable the workaround until the major distros use a compatible GRUB in their stable release like Debian Buster does. Let's be proactive and analyze if anything is missing in Fedora Rawhide GRUB. If yes, we should contact the maintainer and clarify which adjustments are possible until the Fedora 31 release. I don't want it to be "just latest stable has it". I want it to be "supported releases have it". RHEL distros are supported for 10 years. Are you serious? Best regards Heinrich Why? It's the user-friendly behavior. You will find people that upgrade their U-Boot because they're trying something but still have an older distro. Or people that are bringing up a new board and testing it out with an older distro. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Mon, Jul 22, 2019 at 08:51:41PM +0200, Heinrich Schuchardt wrote: > On 7/22/19 3:36 PM, Tom Rini wrote: > >On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > >>On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > >> wrote: > >>> > >>>In GRUB before 2.04 a bug existed which did not allow booting some > >>>ARM32 > >>>boards if U-Boot did not disable caches, cf. > >>>https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > >>> > >>>In ExitBootServices() we were disabling the caches by calling > >>>cleanup_before_linux(). This workaround is not needed anymore. > >> > >>Do we want to remove this straight away? A lot of distributions will > >>take time to move to grub 2.04 because it's been a long time between > >>grub releases so they'll have quite a patch delta to re-align to the > >>new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > >>which will start development end of August but won't be released until > >>next year. > > > >As described below this code does not remove any functionality that was > >active in U-Boot v2019.04 or v2019.07. > > > >I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > >stopping GRUB 2.04 from being made available for stable Fedora releases. > > The maintainers believe that it's too intrusive to land now and they > want maximum testing time before it gets to stable users, funnily > enough people don't like it when their machines cease to boot. > >>> > >>>Why should anybody's machines cease to boot? > >>> > >>>If Fedora does not role out a new U-Boot they are fine. If Fedora roles > >>>out a new U-Boot they should role out a matching GRUB and they are fine > >>>too. > >>> > >>>The venturous who build their own U-Boot should know how to role back > >>>their system if needed. > >> > >>You've clearly never maintained a distribution across 1000s of device > >>types and 100s of thousands of users. > >> > >>We will be shipping Fedora 31 with U-Boot 2019.10 and the current > >>version of grub that the maintainers wish to support, if that requires > >>me to revert a number of your changes I will, which will be an > >>inconvenience and probably take more time than I have spare but I will > >>survive. I find it strange you fix one OS only to break another. How > >>will this work for users that want to boot a newly released device > >>which has recently added U-Boot support to an already released stable > >>OS? > >> > >>If you wish to actively break currently working use cases that's your > >>prerogative that is your choice but I find breaking currently working > >>use cases without a reasonable window to migrate dependencies actively > >>hostile which has tended to not be the way U-Boot has worked in the > >>past for such things as DM, so breaking a interface to the way OSes > >>boot IMO is even worse. > > > >OK, we have a problem here. A better example than DM would be the > >various work-arounds we have (or carried for ages) to allow using newer > >U-Boot with various old and broken kernels. So no, we need to keep this > >work-around for a long while. What's the EOL date for any Linux > >distribution that uses this broken grub? The first U-Boot release post > >that EOL date is when we can drop this particular bit of work-around > >code. > > The current behavior contradicts the UEFI spec. Our target is to > implement a UEFI compliant firmware. Our target is to be both compliant and functional, and functional wins. > If OpenBSD does not change their broken boot loader will we never > correct U-Boot? That would not make sense to me. I'm sorry, I don't see the connection. It's not "GRUB won't change to be compliant" it's "GRUB changed things but it's going to take a long while for that to be deployed out". > Old distros tend not to to update their U-Boot release. E.g. Debian > Stretch is still on U-Boot v2016.11. So why would you care about its EOL? Because I want to make it really hard for people to end up in a "does not boot now" mode. > I could agree if you suggested that we should re-enable the workaround > until the major distros use a compatible GRUB in their stable release > like Debian Buster does. > > Let's be proactive and analyze if anything is missing in Fedora Rawhide > GRUB. If yes, we should contact the maintainer and clarify which > adjustments are possible until the Fedora 31 release. I don't want it to be "just latest stable has it". I want it to be "supported releases have it". Why? It's the user-friendly behavior. You will find people that upgrade their U-Boot because they're trying something but still have an older distro. Or people that are bringing up a new board and testing it out with an older distro. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
> From: Heinrich Schuchardt > Date: Sat, 20 Jul 2019 13:23:13 +0200 > > On 7/20/19 1:59 AM, Jonathan Gray wrote: > > On Fri, Jul 19, 2019 at 08:25:45PM +0200, Heinrich Schuchardt wrote: > >> In GRUB before 2.04 a bug existed which did not allow booting some ARM32 > >> boards if U-Boot did not disable caches, cf. > >> https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > >> > >> In ExitBootServices() we were disabling the caches by calling > >> cleanup_before_linux(). This workaround is not needed anymore. > > > > It is required for at least OpenBSD, FreeBSD and NetBSD. > > Which are all now forced to carry patches to be able to use U-Boot. > > Please, compare function run_loadfile() in files > sys/arch/arm64/stand/efiboot/exec.c and > sys/arch/armv7/stand/efiboot/exec.c of openbsd/src. > > On arm64 after loading the kernel you flush the data and instruction > caches. On armv7 you don't. As the UEFI spec requires caches to be > switched on this is bound to fail. You should be good if you flush > caches like you do on arm64. > > You can find the relevant code for GRUB in > grub-core/kern/arm/cache.S and > grub-core/kern/arm/cache.c > > After GRUB loads the Linux kernel it calls > grub_arch_sync_caches ((void *) linux_addr, linux_size); > in function linux_boot(). Thanks for the pointer. I added code to OpenBSD's BOOTARM.EFI to disable the caches and MMU such that the kernel ends up being started in the same state as before. That still leaves us with the L2 cache issue though. A U-Boot with CONFIG_SYS_L2CACHE_OFF set works, whereas without it doesn't. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On 7/22/19 3:36 PM, Tom Rini wrote: On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt wrote: In GRUB before 2.04 a bug existed which did not allow booting some ARM32 boards if U-Boot did not disable caches, cf. https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html In ExitBootServices() we were disabling the caches by calling cleanup_before_linux(). This workaround is not needed anymore. Do we want to remove this straight away? A lot of distributions will take time to move to grub 2.04 because it's been a long time between grub releases so they'll have quite a patch delta to re-align to the new release. Fedora for example will rebase to grub 2.04 in Fedora 32 which will start development end of August but won't be released until next year. As described below this code does not remove any functionality that was active in U-Boot v2019.04 or v2019.07. I can see nothing in https://fedoraproject.org/wiki/Updates_Policy stopping GRUB 2.04 from being made available for stable Fedora releases. The maintainers believe that it's too intrusive to land now and they want maximum testing time before it gets to stable users, funnily enough people don't like it when their machines cease to boot. Why should anybody's machines cease to boot? If Fedora does not role out a new U-Boot they are fine. If Fedora roles out a new U-Boot they should role out a matching GRUB and they are fine too. The venturous who build their own U-Boot should know how to role back their system if needed. You've clearly never maintained a distribution across 1000s of device types and 100s of thousands of users. We will be shipping Fedora 31 with U-Boot 2019.10 and the current version of grub that the maintainers wish to support, if that requires me to revert a number of your changes I will, which will be an inconvenience and probably take more time than I have spare but I will survive. I find it strange you fix one OS only to break another. How will this work for users that want to boot a newly released device which has recently added U-Boot support to an already released stable OS? If you wish to actively break currently working use cases that's your prerogative that is your choice but I find breaking currently working use cases without a reasonable window to migrate dependencies actively hostile which has tended to not be the way U-Boot has worked in the past for such things as DM, so breaking a interface to the way OSes boot IMO is even worse. OK, we have a problem here. A better example than DM would be the various work-arounds we have (or carried for ages) to allow using newer U-Boot with various old and broken kernels. So no, we need to keep this work-around for a long while. What's the EOL date for any Linux distribution that uses this broken grub? The first U-Boot release post that EOL date is when we can drop this particular bit of work-around code. The current behavior contradicts the UEFI spec. Our target is to implement a UEFI compliant firmware. If OpenBSD does not change their broken boot loader will we never correct U-Boot? That would not make sense to me. Old distros tend not to to update their U-Boot release. E.g. Debian Stretch is still on U-Boot v2016.11. So why would you care about its EOL? I could agree if you suggested that we should re-enable the workaround until the major distros use a compatible GRUB in their stable release like Debian Buster does. Let's be proactive and analyze if anything is missing in Fedora Rawhide GRUB. If yes, we should contact the maintainer and clarify which adjustments are possible until the Fedora 31 release. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Lukasz and Stefano, On Tue, Jun 11, 2019 at 10:53 AM Lukasz Majewski wrote: > > Hi Fabio, Stefano, > > > Hi Stefano, > > > > On Tue, Jun 11, 2019 at 10:11 AM Stefano Babic wrote: > > > > > I have no comments, but from the discussion I felt there are still > > > some issues and I left it over. > > > > Lukasz reported an issue initially, but after adjusting the VID / PID > > he managed to get it to work. > > > > Lukasz, please confirm. > > I can confirm that I made it working on v2019-rc3 (on display5) after > adjusting VID/PID with NXP's 'uuu' utility to recovery i.MX6Q board. Do you think this one could be applied? Without it, I can not load a fit image via USB on imx6sabresd. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] board: amlogic: add support for Odroid-N2
Hi Neil, On Mon, 22 Jul 2019 at 16:00, Neil Armstrong wrote: > > ODROID-N2 is a single board computer manufactured by Hardkernel Co. Ltd > with the following specifications: > > - Amlogic S922X ARM Cortex-A53 dual-core + Cortex-A73 quad-core SoC > - 4GB DDR4 SDRAM > - Gigabit Ethernet > - HDMI 2.1 4K/60Hz display > - 40-pin GPIO header > - 4 x USB 3.0 Host, 1 x USB OTG > - eMMC, microSD > - Infrared receiver > > The board directory is W400, the name of the Amlogic Reference Design > of Amlogic G12B with Gigabit boards, which will be used for similar > boards. > > Signed-off-by: Neil Armstrong > --- > board/amlogic/w400/MAINTAINERS | 6 ++ > board/amlogic/w400/Makefile | 6 ++ > board/amlogic/w400/README.odroid-n2 | 130 > board/amlogic/w400/README.w400 | 130 > board/amlogic/w400/w400.c | 18 > configs/odroid-n2_defconfig | 56 > 6 files changed, 346 insertions(+) > create mode 100644 board/amlogic/w400/MAINTAINERS > create mode 100644 board/amlogic/w400/Makefile > create mode 100644 board/amlogic/w400/README.odroid-n2 > create mode 100644 board/amlogic/w400/README.w400 > create mode 100644 board/amlogic/w400/w400.c > create mode 100644 configs/odroid-n2_defconfig > > diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS > new file mode 100644 > index 00..6e68fa73f7 > --- /dev/null > +++ b/board/amlogic/w400/MAINTAINERS > @@ -0,0 +1,6 @@ > +W400 > +M: Neil Armstrong > +S: Maintained > +L: u-boot-amlo...@groups.io > +F: board/amlogic/w400/ > +F: configs/odroid-n2_defconfig > diff --git a/board/amlogic/w400/Makefile b/board/amlogic/w400/Makefile > new file mode 100644 > index 00..fac4a73afa > --- /dev/null > +++ b/board/amlogic/w400/Makefile > @@ -0,0 +1,6 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# > +# (C) Copyright 2019 BayLibre, SAS > +# Author: Neil Armstrong > + > +obj-y := w400.o > diff --git a/board/amlogic/w400/README.odroid-n2 > b/board/amlogic/w400/README.odroid-n2 > new file mode 100644 > index 00..90070a988d > --- /dev/null > +++ b/board/amlogic/w400/README.odroid-n2 > @@ -0,0 +1,130 @@ > +U-Boot for ODROID-N2 > + > + > +ODROID-N2 is a single board computer manufactured by Hardkernel > +Co. Ltd with the following specifications: > + > + - Amlogic S922X ARM Cortex-A53 dual-core + Cortex-A73 quad-core SoC > + - 4GB DDR4 SDRAM > + - Gigabit Ethernet > + - HDMI 2.1 4K/60Hz display > + - 40-pin GPIO header > + - 4 x USB 3.0 Host, 1 x USB OTG > + - eMMC, microSD > + - Infrared receiver > + > +Schematics are available on the manufacturer website. > + > +Currently the u-boot port supports the following devices: > + - serial > + - eMMC, microSD > + - Ethernet > + - I2C > + - Regulators > + - Reset controller > + - Clock controller > + - ADC > + > +u-boot compilation > +== > + > + > export ARCH=arm > + > export CROSS_COMPILE=aarch64-none-elf- > + > make odroid-n2_defconfig > + > make > + > +Image creation > +== > + > +Amlogic doesn't provide sources for the firmware and for tools needed > +to create the bootloader image, so it is necessary to obtain them from > +the git tree published by the board vendor: > + > + > wget > https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz > + > wget > https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz > + > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz > + > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz > + > export > PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH > + Should we checkout odroidn2-v2015.01 from Hardkernel repository. > + > DIR=odroid-c2 > + > git clone --depth 1 \ > + https://github.com/hardkernel/u-boot.git -b odroidc2-v2015.01 \ > + $DIR > + > + > cd odroid-c2 > + > make odroidn2_defconfig > + > make > + > export UBOOTDIR=$PWD > + > + Go back to mainline U-Boot source tree then : > + > mkdir fip > + > + > wget > https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/blx_fix_g12a.sh > -O fip/blx_fix.sh > + > cp $UBOOTDIR/build/scp_task/bl301.bin fip/ > + > cp $UBOOTDIR/build/board/hardkernel/odroidn2/firmware/acs.bin fip/ > + > cp $UBOOTDIR/fip/g12b/bl2.bin fip/ > + > cp $UBOOTDIR/fip/g12b/bl30.bin fip/ > + > cp $UBOOTDIR/fip/g12b/bl31.img fip/ > + > cp $UBOOTDIR/fip/g12b/ddr3_1d.fw fip/ > + > cp $UBOOTDIR/fip/g12b/ddr4_1d.fw fip/ > + > cp $UBOOTDIR/fip/g12b/ddr4_2d.fw fip/ > + > cp $UBOOTDIR/fip/g12b/diag_lpddr4.fw fip/ > + > cp $UBOOTDIR/fip/g12b/lpddr4_1d.fw fip/ > + > cp $UBOOTDIR/fip/g12b/lpddr4_2d.fw fip/ > + > cp $UBOOTDIR/fip/g12b/piei.fw fip/ > + > cp $UBOOTDIR/fip/g12b/aml_ddr.fw fip/ > + > cp u-boot.bin
Re: [U-Boot] [PATCH v5 0/8] x86: Add basic Slim Bootloader payload support
On Mon, Jul 22, 2019 at 9:27 AM Bin Meng wrote: > On Mon, Jul 22, 2019 at 1:13 PM Park, Aiden wrote: > > > -Original Message- > > Any update on this series? I hope this will be merged soon. Thanks. > > Yes, I plan to merge this series for v2019.10 release. > > But I want to wait for Andy's comments before that in case he has some > comments that need to be addressed. Thanks! Just finished my review round, thanks for patience, and sorry for the delay. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Move setup_led() in SPL to U-Boot proper?
Hi, On Sat, 20 Jul 2019 at 23:53, Kever Yang wrote: > > Hi Simon, > > I'm trying to clean up board support file for Rockchip platform now. > > There is a setup_led() in SPL, and seems that only rk3288-firefly and > rk3188-rock > > are using it, is it possible to move this led setup in U-Boot proper? From what I can tell this is only used in SPL, to light an LED as a sign of life. So moving it to U-Boot proper will remove this feature. What is your goal? > > Other than rockchip platform, only stm32 is using > "u-boot,boot-led", and > > they init led very late at board_quiesce_devices() in bootm. > > > Thanks, > > - Kever > > > Regards, SImon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] x86: slimbootloader: Add memory configuration
On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden wrote:
>
> Slim Bootloader provides memory map info thru its HOB list pointer.
> Configure memory size and relocation memory from the HOB data, and
> provide e820 entries as well.
> - Get memory size from the memory map info hob
> - Set ram top for U-Boot relocation lower than 4GB
> - Provide e820 entries from the memory map info hob
> +++ b/arch/x86/cpu/slimbootloader/dram.c
sdram.c is more common name in the sources AFAICS.
> +ulong board_get_usable_ram_top(ulong total_size)
> +{
> + struct memory_map_info *data = NULL;
> + int i = 0;
> + phys_addr_t addr_start = 0;
> + phys_addr_t addr_end = 0;
Unnecessary assignments (check entire series for them).
> + data = (struct memory_map_info *)get_memory_map_info();
Casting from / to void * is redundant. Check entire series.
> + if (!data)
> + panic("memory map info hob not found\n");
> + /**
> +* sorted memory map entries from Slim Bootloader based on physical
> +* start memory address, from low to high. So do reversed search to
> +* get highest usable, suitable size, 4KB aligned available memory
> +* under 4GB.
> +*/
> + for (i = data->count - 1; i >= 0; i--) {
Hmm... Maybe
i = data->count;
while (i--) {
...
}
Easier to read.
> + if (data->entry[i].type != E820_RAM)
> + continue;
> +
> + addr_start = data->entry[i].addr;
> + addr_end = addr_start + data->entry[i].size;
> +
> + if (addr_start > SZ_4G)
> + continue;
> +
> + if (addr_end > SZ_4G)
> + addr_end = SZ_4G;
> +
> + if (addr_end < total_size)
> + continue;
> +
> + /* to relocate u-boot at 4K aligned memory */
u-boot -> U-Boot
> + addr_end = rounddown(addr_end - total_size, SZ_4K);
> + if (addr_end >= addr_start) {
> + ram_top = (ulong)addr_end + total_size;
> + break;
> + }
> + }
> +
> + if (!ram_top)
> + panic("failed to find available memory for relocation!");
> +
> + return ram_top;
> +}
> +
> +/**
> + * The memory initialization has already been done in previous Slim
> Bootloader
> + * stage thru FSP-M. Instead, this sets the ram_size from the memory map info
> + * hob.
> + */
> +int dram_init(void)
> +{
> + struct memory_map_info *data = NULL;
> + int i = 0;
> + phys_size_t ram_size = 0;
> +
> + data = (struct memory_map_info *)get_memory_map_info();
> + if (!data)
> + panic("memory map info hob not found\n");
> +
> + /**
> +* sorted memory map entries from Slim Bootloader based on physical
> +* start memory address, from low to high. So do reversed search to
> +* simply get highest usable memory address as ram size
> +*/
> + for (i = data->count - 1; i >= 0; i--) {
> + if (data->entry[i].type != E820_RAM)
> + continue;
Second time?
Perhaps you may do rather macro:
#define for_each_map_info_entry_reversed(...) \
for () \
if (!cond) {} else
> +
> + /* simply use the highest usable memory address as ram size */
ram -> RAM
> + ram_size = data->entry[i].addr + data->entry[i].size;
> + break;
> + }
> +
> + if (!ram_size)
> + panic("failed to detect memory size");
> +
> + gd->ram_size = ram_size;
> + return 0;
> +}
> +int dram_init_banksize(void)
> +{
> + /* simply use a single bank to have whole size for now */
> + if (CONFIG_NR_DRAM_BANKS) {
if (!foo) might be slightly better if ever this code gets modified.
> + gd->bd->bi_dram[0].start = 0;
> + gd->bd->bi_dram[0].size = gd->ram_size;
> + }
> + return 0;
> +}
> +#define LOADER_MEMORY_MAP_INFO_GUID \
> + { \
> + 0xa1ff7424, 0x7a1a, 0x478e, \
> + { 0xa9, 0xe4, 0x92, 0xf3, 0x57, 0xd1, 0x28, 0x32 } \
> + }
EFI_GUID() ?
> +/**
> + * A single entry of memory map information
> + *
> + * @addr: start address of a memory map entry
> + * @size: size of a memory map entry
> + * @type: usable:1, reserved:2, acpi:3, nvs:4, unusable:5
> + * @flag: only used in Slim Bootloader
> + * @rsvd: padding for alignment
> + */
> +struct memory_map_entry {
> + phys_addr_t addr;
> + phys_size_t size;
This is comes from hardware, isn't it? Probably better to use fixed width typo
> + u8 type;
> + u8 flag;
> + u8 rsvd[6];
> +} __packed;
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: sdhci: fix chip detect gpio property name
The standard property name for chip-detect gpio is "cd-gpios". All
in-tree DT files use only this name.
Fixes: 451931ea700 ("mmc: sdhci: Read cd-gpio from devicetree")
Cc: T Karthik Reddy
Cc: Michal Simek
Signed-off-by: Baruch Siach
---
drivers/mmc/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 0a0770cc2035..2779bca93f08 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -623,7 +623,7 @@ static int sdhci_init(struct mmc *mmc)
#if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
struct udevice *dev = mmc->dev;
- gpio_request_by_name(dev, "cd-gpio", 0,
+ gpio_request_by_name(dev, "cd-gpios", 0,
>cd_gpio, GPIOD_IS_IN);
#endif
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmd: sdhci: fix non GPIO card detect
Some SD cards do not assert the SDHCI_CARD_PRESENT bit. Only the
SDHCI_CARD_DETECT_PIN_LEVEL is enabled. Consider that enough for card
detect indication.
This fixes SD card access from SPL, since DM_GPIO is not available in
SPL code.
Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
Cc: T Karthik Reddy
Cc: Michal Simek
Signed-off-by: Baruch Siach
---
drivers/mmc/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 2779bca93f08..17a28181fcca 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -683,7 +683,7 @@ int sdhci_get_cd(struct udevice *dev)
}
#endif
value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
- SDHCI_CARD_PRESENT);
+ (SDHCI_CARD_PRESENT | SDHCI_CARD_DETECT_PIN_LEVEL));
if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
return !value;
else
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Mon, Jul 22, 2019 at 2:36 PM Tom Rini wrote: > > On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > > > >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > > > >>> wrote: > > > > > > In GRUB before 2.04 a bug existed which did not allow booting some > > > ARM32 > > > boards if U-Boot did not disable caches, cf. > > > https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > > > > > > In ExitBootServices() we were disabling the caches by calling > > > cleanup_before_linux(). This workaround is not needed anymore. > > > >>> > > > >>> Do we want to remove this straight away? A lot of distributions will > > > >>> take time to move to grub 2.04 because it's been a long time between > > > >>> grub releases so they'll have quite a patch delta to re-align to the > > > >>> new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > > > >>> which will start development end of August but won't be released until > > > >>> next year. > > > >> > > > >> As described below this code does not remove any functionality that was > > > >> active in U-Boot v2019.04 or v2019.07. > > > >> > > > >> I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > > > >> stopping GRUB 2.04 from being made available for stable Fedora > > > >> releases. > > > > > > > > The maintainers believe that it's too intrusive to land now and they > > > > want maximum testing time before it gets to stable users, funnily > > > > enough people don't like it when their machines cease to boot. > > > > > > Why should anybody's machines cease to boot? > > > > > > If Fedora does not role out a new U-Boot they are fine. If Fedora roles > > > out a new U-Boot they should role out a matching GRUB and they are fine > > > too. > > > > > > The venturous who build their own U-Boot should know how to role back > > > their system if needed. > > > > You've clearly never maintained a distribution across 1000s of device > > types and 100s of thousands of users. > > > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > > version of grub that the maintainers wish to support, if that requires > > me to revert a number of your changes I will, which will be an > > inconvenience and probably take more time than I have spare but I will > > survive. I find it strange you fix one OS only to break another. How > > will this work for users that want to boot a newly released device > > which has recently added U-Boot support to an already released stable > > OS? > > > > If you wish to actively break currently working use cases that's your > > prerogative that is your choice but I find breaking currently working > > use cases without a reasonable window to migrate dependencies actively > > hostile which has tended to not be the way U-Boot has worked in the > > past for such things as DM, so breaking a interface to the way OSes > > boot IMO is even worse. > > OK, we have a problem here. A better example than DM would be the > various work-arounds we have (or carried for ages) to allow using newer > U-Boot with various old and broken kernels. So no, we need to keep this > work-around for a long while. What's the EOL date for any Linux > distribution that uses this broken grub? The first U-Boot release post > that EOL date is when we can drop this particular bit of work-around > code. Well Fedora 31 would be EOL around Nov/Dec 2020, and while I know the CentOS team uses the Fedora U-Boot but I believe they boot their arm-32 instances with extlinux to date. I can't speak for any of the other distros in this regard. Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 4/4] doc: sifive-fu540: Update README to explicitly load DTB for Linux
On Mon, Jul 22, 2019 at 3:38 PM Anup Patel wrote: > > We should explicitly load DTB from TFTP server or MMC/SD card > for Linux booting. This will allow us: > 1. To use different Linux DTB for SiFive Unleashed board with >expansion board connected. > 2. Avoid re-flashing OpenSBI firmware whenever board connections >change. > > This patch updates reference bootlog in SiFive FU540 README > as-per above. > > Signed-off-by: Anup Patel > --- > doc/README.sifive-fu540 | 317 > 1 file changed, 191 insertions(+), 126 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: mv_sdhci: fix uninitialized pointer deref on probe
Since commit 3d296365e4e8 ("mmc: sdhci: Add support for
sdhci-caps-mask") sdhci_setup_cfg() expects a valid sdhci_host mmc
field. Move the mmc field initialization before sdhci_setup_cfg()
call to avoid crash on mmc pointer dereference.
Fixes: 3d296365e4e8 ("mmc: sdhci: Add support for sdhci-caps-mask")
Cc: Faiz Abbas
Signed-off-by: Baruch Siach
---
drivers/mmc/mv_sdhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index bf26d2e4e265..f5f3e4324719 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -114,6 +114,9 @@ static int mv_sdhci_probe(struct udevice *dev)
host->name = MVSDH_NAME;
host->ioaddr = (void *)devfdt_get_addr(dev);
host->quirks = SDHCI_QUIRK_32BIT_DMA_ADDR | SDHCI_QUIRK_WAIT_SEND_CMD;
+ host->mmc = >mmc;
+ host->mmc->dev = dev;
+ host->mmc->priv = host;
ret = sdhci_setup_cfg(>cfg, host, 0, 0);
if (ret)
@@ -124,9 +127,6 @@ static int mv_sdhci_probe(struct udevice *dev)
sdhci_mvebu_mbus_config(host->ioaddr);
}
- host->mmc = >mmc;
- host->mmc->dev = dev;
- host->mmc->priv = host;
upriv->mmc = host->mmc;
return sdhci_probe(dev);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: dts: add support for Odroid-N2
Hi Neil,
On Mon, 22 Jul 2019 at 15:50, Neil Armstrong wrote:
>
> Import HardKernel Odroid-N2 DT from Linux 5.3-rc1, commit 5f9e832c1370
> ("Linus 5.3-rc1") based on an Amlogic G12B S922X SoC.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/meson-g12b-odroid-n2.dts | 386 ++
> arch/arm/dts/meson-g12b.dtsi | 82
> .../dt-bindings/sound/meson-g12a-tohdmitx.h | 13 +
> 4 files changed, 483 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/meson-g12b-odroid-n2.dts
> create mode 100644 arch/arm/dts/meson-g12b.dtsi
> create mode 100644 include/dt-bindings/sound/meson-g12a-tohdmitx.h
>
I am getting following error while building this on mainline u-boot.
CHK include/config/uboot.release
UPD include/config/uboot.release
CHK include/generated/version_autogenerated.h
UPD include/generated/version_autogenerated.h
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
CHK include/generated/generic-asm-offsets.h
CHK include/generated/asm-offsets.h
HOSTCC tools/mkenvimage.o
HOSTLD tools/mkenvimage
HOSTCC tools/dumpimage.o
HOSTLD tools/dumpimage
HOSTCC tools/mkimage.o
HOSTLD tools/mkimage
CC arch/arm/cpu/armv8/fwcall.o
LD arch/arm/cpu/armv8/built-in.o
CC cmd/version.o
LD cmd/built-in.o
CC common/main.o
LD common/built-in.o
CC lib/efi_loader/helloworld.o
CC lib/efi_loader/efi_reloc.o
CC lib/efi_loader/efi_freestanding.o
LD lib/efi_loader/helloworld_efi.so
OBJCOPY lib/efi_loader/helloworld.efi
CC lib/smbios.o
CC lib/display_options.o
LD lib/built-in.o
LD u-boot
OBJCOPY u-boot.srec
OBJCOPY u-boot-nodtb.bin
start=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_start | cut -f 1
-d ' '); end=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_end | cut
-f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x0100 $start
$end
DTC arch/arm/dts/meson-g12b-odroid-n2.dtb
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:226.1-5 Label or
path arb not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:244.1-12 Label
or path clkc_audio not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:248.1-10 Label
or path ext_mdio not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:264.1-8 Label or
path ethmac not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:273.1-9 Label or
path frddr_a not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:277.1-9 Label or
path frddr_b not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:281.1-9 Label or
path frddr_c not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:313.1-4 Label or
path ir not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:320.1-11 Label
or path sd_emmc_b not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:338.1-11 Label
or path sd_emmc_c not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:356.1-9 Label or
path tdmif_b not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:360.1-10 Label
or path tdmout_b not found
Error: arch/arm/dts/.meson-g12b-odroid-n2.dtb.pre.tmp:364.1-10 Label
or path tohdmitx not found
FATAL ERROR: Syntax error parsing input tree
make[2]: *** [scripts/Makefile.lib:308:
arch/arm/dts/meson-g12b-odroid-n2.dtb] Error 1
make[1]: *** [dts/Makefile:38: arch-dtbs] Error 2
make: *** [Makefile:1045: dts/dt.dtb] Error 2
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f5535078c7..2baa368215 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -135,7 +135,8 @@ dtb-$(CONFIG_ARCH_MESON) += \
> meson-gxl-s905x-khadas-vim.dtb \
> meson-gxm-khadas-vim2.dtb \
> meson-axg-s400.dtb \
> - meson-g12a-u200.dtb
> + meson-g12a-u200.dtb \
> + meson-g12b-odroid-n2.dtb
> dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
> tegra20-medcom-wide.dtb \
> tegra20-paz00.dtb \
> diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dts
> b/arch/arm/dts/meson-g12b-odroid-n2.dts
> new file mode 100644
> index 00..81780ffcc7
> --- /dev/null
> +++ b/arch/arm/dts/meson-g12b-odroid-n2.dts
> @@ -0,0 +1,386 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-g12b.dtsi"
> +#include
> +#include
> +#include
> +
> +/ {
> + compatible = "hardkernel,odroid-n2", "amlogic,g12b";
> + model = "Hardkernel ODROID-N2";
> +
> + aliases {
> + serial0 = _AO;
> + ethernet0 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x4000>;
> +
[U-Boot] [RFC PATCH 05/11] spl: support booting via RISC-V OpenSBI
RISC-V OpenSBI is an open-source implementation of the RISC-V Supervisor
Binary Interface (SBI) specification. It is required by Linux and U-Boot
running in supervisor mode. This patch adds support for booting via the
OpenSBI FW_DYNAMIC firmware.
In this configuration, U-Boot SPL starts in machine mode. After loading
OpenSBI and U-Boot proper, it will start OpenSBI. All necessary
parameters are generated by U-Boot SPL and passed to OpenSBI. U-Boot
proper is started in supervisor mode by OpenSBI. Support for OpenSBI is
enabled with CONFIG_SPL_OPENSBI. An additional configuration entry,
CONFIG_SPL_OPENSBI_LOAD_ADDR, is used to specify the load address of the
OpenSBI firmware binary. It is not used directly in U-Boot and instead
is intended to make the value available to scripts such as FIT
configuration generators.
The header file include/opensbi.h is based on header files from the
OpenSBI project. They are recent, as of commit bae54f764570 ("firmware:
Add fw_dynamic firmware").
Signed-off-by: Lukas Auer
---
common/image.c | 1 +
common/spl/Kconfig | 17
common/spl/Makefile | 1 +
common/spl/spl.c | 6 +++
common/spl/spl_opensbi.c | 85
include/image.h | 1 +
include/opensbi.h| 40 +++
include/spl.h| 5 +++
8 files changed, 156 insertions(+)
create mode 100644 common/spl/spl_opensbi.c
create mode 100644 include/opensbi.h
diff --git a/common/image.c b/common/image.c
index 9f9538fac2..7c7353a989 100644
--- a/common/image.c
+++ b/common/image.c
@@ -125,6 +125,7 @@ static const table_entry_t uimage_os[] = {
#if defined(CONFIG_BOOTM_OPENRTOS) || defined(USE_HOSTCC)
{ IH_OS_OPENRTOS, "openrtos", "OpenRTOS", },
#endif
+ { IH_OS_OPENSBI, "opensbi", "RISC-V OpenSBI", },
{ -1, "", "", },
};
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 5978fb2934..9043f7b7ec 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1112,6 +1112,23 @@ config SPL_OPTEE
OP-TEE is an open source Trusted OS which is loaded by SPL.
More detail at: https://github.com/OP-TEE/optee_os
+config SPL_OPENSBI
+ bool "Support RISC-V OpenSBI"
+ depends on RISCV && SPL_RISCV_MMODE && RISCV_SMODE
+ help
+ OpenSBI is an open-source implementation of the RISC-V Supervisor
Binary
+ Interface (SBI) specification. U-Boot supports the OpenSBI FW_DYNAMIC
+ firmware. It is loaded and started by U-Boot SPL.
+
+ More details are available at https://github.com/riscv/opensbi and
+ https://github.com/riscv/riscv-sbi-doc
+
+config SPL_OPENSBI_LOAD_ADDR
+ hex "OpenSBI load address"
+ depends on SPL_OPENSBI
+ help
+ Load address of the OpenSBI binary.
+
config TPL
bool
depends on SUPPORT_TPL
diff --git a/common/spl/Makefile b/common/spl/Makefile
index d28de692dd..5ce6f4ae48 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o
obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o
obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o
obj-$(CONFIG_$(SPL_TPL_)OPTEE) += spl_optee.o
+obj-$(CONFIG_$(SPL_TPL_)OPENSBI) += spl_opensbi.o
obj-$(CONFIG_$(SPL_TPL_)USB_STORAGE) += spl_usb.o
obj-$(CONFIG_$(SPL_TPL_)FS_FAT) += spl_fat.o
obj-$(CONFIG_$(SPL_TPL_)FS_EXT4) += spl_ext.o
diff --git a/common/spl/spl.c b/common/spl/spl.c
index d5e3f680f4..1ed4741bdc 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -659,6 +659,12 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
(void *)spl_image.entry_point);
break;
#endif
+#if CONFIG_IS_ENABLED(OPENSBI)
+ case IH_OS_OPENSBI:
+ debug("Jumping to U-Boot via RISC-V OpenSBI\n");
+ spl_invoke_opensbi(_image);
+ break;
+#endif
#ifdef CONFIG_SPL_OS_BOOT
case IH_OS_LINUX:
debug("Jumping to Linux\n");
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
new file mode 100644
index 00..a6b4480ed2
--- /dev/null
+++ b/common/spl/spl_opensbi.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer
+ *
+ * Based on common/spl/spl_atf.c
+ */
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct fw_dynamic_info opensbi_info;
+
+static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
+{
+ int fit_images_node, node;
+ const char *fit_os;
+
+ fit_images_node = fdt_path_offset(blob, "/fit-images");
+ if (fit_images_node < 0)
+ return -ENODEV;
+
+ fdt_for_each_subnode(node, blob, fit_images_node) {
+ fit_os = fdt_getprop(blob, node, FIT_OS_PROP, NULL);
+ if (!fit_os)
+
[U-Boot] Pull request: u-boot-rockchip/tags/rockchip-for-v2019.07-2
Hi Tom, Please pull some fix up for rockchip platform: - rk3399 sdhci driver fixup - TPL BANNER fixup The Travis build is not complete when I send this mail, but it should be OK for the fixes are simple. Travis: https://travis-ci.org/keveryang/u-boot/builds/562114389 Thanks, - Kever The following changes since commit 8b1ceb0ac1aa1746c6751d698ce7a012a236fa65: rockchip: Remove obsolete references to pyelftools (2019-07-20 23:59:44 +0800) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/rockchip-for-v2019.07-2 for you to fetch changes up to 89e39172301f15b29f663baf704bf2163a0cfa46: rockchip: TPL banner should depend on CONFIG_TPL_BANNER_PRINT (2019-07-22 21:52:59 +0800) Chris Webb (2): rockchip: Fix TPL build without CONFIG_TPL_SERIAL_SUPPORT rockchip: TPL banner should depend on CONFIG_TPL_BANNER_PRINT Kever Yang (1): rockchip: sdhci: Fix sdhci mmc driver probe abort arch/arm/mach-rockchip/tpl.c | 4 +++- drivers/mmc/rockchip_sdhci.c | 8 2 files changed, 7 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/8] board: intel: Add new slimbootloader board
On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden wrote:
>
> Add slimbootloader board to run U-boot as a Slim Bootloader payload
> - Add new board/intel/slimbootloader directory with minimum codes
> - Add slimbootloader configuration files
> - Add README in board/intel/slimbootloader
> board/intel/slimbootloader/README | 133
Shouldn't become reST one?
> +Stitch IFWI:
> + Refer to
> https://slimbootloader.github.io/supported-hardware/apollo-lake-crb.html#stitching.
> + > python Platform/ApollolakeBoardPkg/Script/StitchLoader.py -i IFWI> -s Outputs/apl/Stitch_Components.zip -o
It reminds me that DnX protocol.
> +Flash IFWI:
> + Use DediProg to flash IFWI.
> + Now, you should reach at U-Boot serial console.
Can't it be done via DFU?
> +int board_early_init_r(void)
> +{
> + /*
> +* Make sure PCI bus is enumerated so that peripherals on the PCI bus
> +* can be discovered by their drivers
> +*/
> + pci_init();
I'm not sure this is how U-Boot is designed with DM.
At least my expectations that bus gets initialized followed by the
certain driver in a lazy way.
Isn't it the case? Bin?
> +
> + return 0;
> +}
> +++ b/board/intel/slimbootloader/start.S
> @@ -0,0 +1,9 @@
> +/* board early initialization */
> +.globl early_board_init
> +early_board_init:
> + jmp early_board_init_ret
Do you need this stub at all? How other CPUs work without it?
> +++ b/include/configs/slimbootloader.h
> @@ -0,0 +1,59 @@
> +#undef CONFIG_NFSBOOTCOMMAND
> +#undef CONFIG_RAMBOOTCOMMAND
> +#undef CONFIG_EXTRA_ENV_SETTINGS
> +#undef CONFIG_BOOTCOMMAND
Do we really need all these in the header?
Can't some at least be done via configuration?
> +#ifdef CONFIG_SYS_NS16550_MEM32
> +#undef CONFIG_SYS_NS16550_PORT_MAPPED
> +#endif
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/8] x86: slimbootloader: Add serial driver
On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden wrote:
>
> Slim Bootloader provides serial port info thru its HOB list pointer.
> All these HOBs are eligible for Slim Bootloader based board only.
> - Get serial port information from the serial port info hob
> - Leverage ns16550 driver with slimbootloader specific platform data
> + /*
> +* The serial_info->type provides port io or mmio access type info,
> +* but the access type will be controlled by
> +* CONFIG_SYS_NS16550_PORT_MAPPED or CONFIG_SYS_NS16550_MEM32.
> +*
> +* TBD: ns16550 access type configuration in runtime.
> +* ex) plat->access_type = serial_info->type
> +*/
io -> IO
mmio -> MMIO
> + plat->base = serial_info->base;
> + /* ns16550 uses reg_shift, then covert stride to shift */
> + plat->reg_shift = (serial_info->stride >> 1);
Too many parenthesis.
> + plat->clock = serial_info->clk;
> +
> + return 0;
> +}
> +/**
> + * A GUID to get SerialPort info hob which is provided by Slim Bootloader
> + */
> +#define LOADER_SERIAL_PORT_INFO_GUID \
> + { \
> + 0x6c6872fe, 0x56a9, 0x4403, \
> + { 0xbb, 0x98, 0x95, 0x8d, 0x62, 0xde, 0x87, 0xf1 } \
> + }
EFI_GUID()
> +struct serial_port_info {
serial is not this platform namespace, choose more particular one, please.
> + u8 rev;
> + u8 rsvd[3];
> + u32 type;
> + u32 base;
> + u32 baud;
> + u32 stride;
> + u32 clk;
> + u32 rsvd1;
> +} __packed;
Does __packed service for anything here?
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu (22.07.2019)
Dear Marek, Repo: g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git Branch: master The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2: Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400) are available in the git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git for you to fetch changes up to 27d8f3bee67d560b818864167832d6df1feefc91: fastboot: Remove "bootloader-version" variable (2019-07-22 12:48:47 +0200) Marek Szyprowski (1): thor: fix crash after usb initialization failure Ralph Siemsen (1): usb: gadget: f_dfu.c: fix memory leak Sam Protsenko (4): fastboot: Remove "slot-suffixes" variable env: ti: Improve "fastboot reboot bootloader" handling fastboot: getvar: Add "is-userspace" variable fastboot: Remove "bootloader-version" variable cmd/thordown.c| 6 +- doc/android/fastboot.txt | 6 +++--- drivers/fastboot/fb_getvar.c | 27 --- drivers/usb/gadget/f_dfu.c| 1 + include/environment/ti/boot.h | 4 +++- 5 files changed, 24 insertions(+), 20 deletions(-) Travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpC3F3h93ErK.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 00/11] SPL support for RISC-V
This series adds support for SPL to RISC-V U-Boot. Images can be booted via OpenSBI (FW_DYNAMIC firmware) or by directly jumping to them. In the former case, OpenSBI and U-Boot proper are bundled as a FIT image and made available to U-Boot SPL. Currently, only the QEMU board enables U-Boot SPL with a dedicated configuration. It uses RAM as SPL boot device. On many RISC-V CPUs, the device tree is provided to U-Boot by the first stage bootloader. This requires changes to U-Boot SPL (patches 1, 2 and 3), which modify the behavior on other boards as well. To get feedback on this, I am therefore sending this series as RFC first. To test this series, OpenSBI has to be compiled first. The fw_dynamic.bin binary must be copied into the U-Boot root directory. Alternatively, the location of the binary can be specified with the OPENSBI environment variable. U-Boot can then be build as normal using the configuration qemu-riscv64_spl_defconfig for 64-bit builds or qemu-riscv32_spl_defconfig for 32-bit builds. The outputs from the build process are the U-Boot SPL binary (spl/u-boot-spl.bin) and the U-Boot FIT image (u-boot.itb) containing U-Boot proper and OpenSBI. U-Boot can be run in QEMU with the following command. qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \ -device loader,file=u-boot.itb,addr=0x8020 Lukas Auer (11): fdtdec: make CONFIG_OF_PRIOR_STAGE available in SPL Makefile: support building SPL FIT images without device trees spl: fit: use U-Boot device tree when FIT image has no device tree riscv: add run mode configuration for SPL spl: support booting via RISC-V OpenSBI riscv: add SPL support riscv: support SPL stack and global data relocation riscv: add a generic FIT generator script riscv: set default FIT generator script and build target for SPL builds riscv: qemu: add SPL configuration doc: update QEMU RISC-V documentation Kconfig | 4 +- Makefile| 8 +- arch/Kconfig| 6 ++ arch/riscv/Kconfig | 36 +++-- arch/riscv/cpu/ax25/Kconfig | 6 +- arch/riscv/cpu/cpu.c| 6 +- arch/riscv/cpu/generic/Kconfig | 5 +- arch/riscv/cpu/start.S | 62 ++- arch/riscv/cpu/u-boot-spl.lds | 82 +++ arch/riscv/include/asm/encoding.h | 2 +- arch/riscv/include/asm/spl.h| 31 arch/riscv/lib/Makefile | 8 +- arch/riscv/lib/mkimage_fit_opensbi.sh | 100 arch/riscv/lib/spl.c| 48 board/emulation/qemu-riscv/Kconfig | 10 +++ board/emulation/qemu-riscv/MAINTAINERS | 2 + board/emulation/qemu-riscv/qemu-riscv.c | 17 common/image.c | 1 + common/spl/Kconfig | 17 common/spl/Makefile | 1 + common/spl/spl.c| 8 +- common/spl/spl_fit.c| 37 ++--- common/spl/spl_opensbi.c| 85 configs/qemu-riscv32_spl_defconfig | 11 +++ configs/qemu-riscv64_spl_defconfig | 12 +++ doc/README.qemu-riscv | 56 - include/configs/qemu-riscv.h| 14 include/fdtdec.h| 2 +- include/image.h | 1 + include/opensbi.h | 40 ++ include/spl.h | 5 ++ lib/fdtdec.c| 6 +- 32 files changed, 687 insertions(+), 42 deletions(-) create mode 100644 arch/riscv/cpu/u-boot-spl.lds create mode 100644 arch/riscv/include/asm/spl.h create mode 100755 arch/riscv/lib/mkimage_fit_opensbi.sh create mode 100644 arch/riscv/lib/spl.c create mode 100644 common/spl/spl_opensbi.c create mode 100644 configs/qemu-riscv32_spl_defconfig create mode 100644 configs/qemu-riscv64_spl_defconfig create mode 100644 include/opensbi.h -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 0/5] add i.MX8 container loading support
Dear Peng Fan, In message you wrote: > > Subject: Re: [U-Boot] [PATCH V3 0/5] add i.MX8 container loading support > > > > On 22.07.19 04:12, Peng Fan wrote: > > > V3: > > > Drops patch 1/5 from V2, add 8QM support, nothing else changed. > > > Stefano, > > > This patchset was pending in patchwork for more that one month, > > > please consider to apply. > > > > I'm not the one to judge here and I don't know the rules for U-Boot, but > > only > > because they have been pending for a long time, doesn't make the patches > > more suitable for upstream. Even more so, if no one has reviewed them yet. > > Since it was there long time, I just thought no one has comments. If you don't get _any_ feedback for a long time this usually means the stuff is too difficult to digest by most of the readers (aka TLDR symtom). Adding better documentation (README, commit messaes, etc.) may help... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only way to get rid of a temptation is to yield to it. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 5/8] x86: slimbootloader: Set TSC information for timer driver
On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden wrote:
>
> Slim Bootloader provides TSC clock information in its performance
> info hob. For now, TSC clock information is only used for timer driver
> from the performance info hob.
> - Get TSC frequency from performance info hob
> - Set tsc_base and clock_rate for timer driver
So why do we need this at all? We have a common TSC driver that works
for all x86.
> +#define LOADER_PERFORMANCE_INFO_GUID \
> + { \
> + 0x868204be, 0x23d0, 0x4ff9, \
> + { 0xac, 0x34, 0xb9, 0x95, 0xac, 0x04, 0xb1, 0xb9 } \
> + }
Use EFI_GUID(), please.
> +struct performance_info {
Same, you better to make less generic names for data structs.
> +} __packed;
Same question. If it's aligned naturally by 32-bit boundaries, Why do
you need __packed?
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Sun, Jul 21, 2019 at 8:42 PM Heinrich Schuchardt wrote: > > On 7/21/19 11:46 AM, Peter Robinson wrote: > > On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > > wrote: > >> > >> In GRUB before 2.04 a bug existed which did not allow booting some > >> ARM32 > >> boards if U-Boot did not disable caches, cf. > >> https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > >> > >> In ExitBootServices() we were disabling the caches by calling > >> cleanup_before_linux(). This workaround is not needed anymore. > > > > Do we want to remove this straight away? A lot of distributions will > > take time to move to grub 2.04 because it's been a long time between > > grub releases so they'll have quite a patch delta to re-align to the > > new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > > which will start development end of August but won't be released until > > next year. > > As described below this code does not remove any functionality that was > active in U-Boot v2019.04 or v2019.07. > > I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > stopping GRUB 2.04 from being made available for stable Fedora releases. > >>> > >>> The maintainers believe that it's too intrusive to land now and they > >>> want maximum testing time before it gets to stable users, funnily > >>> enough people don't like it when their machines cease to boot. > >> > >> Why should anybody's machines cease to boot? > >> > >> If Fedora does not role out a new U-Boot they are fine. If Fedora roles > >> out a new U-Boot they should role out a matching GRUB and they are fine > >> too. > >> > >> The venturous who build their own U-Boot should know how to role back > >> their system if needed. > > > > You've clearly never maintained a distribution across 1000s of device > > types and 100s of thousands of users. > > > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > > version of grub that the maintainers wish to support, if that requires > > You do not give any clue which version of GRUB will be shipped with > Fedora 31. Could you, please, clarify this. A link to the Fedora repo > would be helpful. Thanks. It's 2.02 and a whole of lot of patches, like the rest of the world seems to ship. The git repo is here: https://github.com/rhboot/grub2/tree/fedora-31 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/8] x86: Add basic Slim Bootloader payload support
On Wed, Jul 17, 2019 at 7:40 AM Park, Aiden wrote: > > This patch is to enable U-Boot as a payload which runs on top of Slim > Bootloader(https://github.com/slimbootloader/slimbootloader) boot firmware > for x86 platforms. > > The Slim Bootloader is designed with multi-stage architecture for the > execution from reset vector to OS hand-off, and supports qemu, Apollolake, > Whiskeylake and Coffeelake platforms consuming Intel > FSP(https://github.com/IntelFsp/FSP) for silicon initialization including CAR > and memory initialization. > As multi-stage architecture, the Slim Bootloader adopts payload concept which > is responsible for OS load from media devices and boot OS and it supports > 32-bit PE32, EFI FV, ELF and RAW format payloads. > The Slim Bootloader generate HOB(Hand Off Block) list pointer, which has > debug serial port info, memory map info, performance data info and etc., and > passes it to a payload. U-Boot configures serial port, dram, pci, tsc and > others with the information from the HOB. > The comments are per individual patches, but some of them have remarks to be applied to entire series (usually it's a rule of thumb to check entire series for similarities even if got only comment for one place). Not commented patches, after addressing global remarks, are subject to have mine Reviewed-by: Andy Shevchenko > The compiled U-Boot supports usb, sata and sd/mmc boot which have been > verified on qemu and other supported platforms. > > Changes in v5: > * Remove X86_LOAD_FROM_32_BIT from slimbootloader_defconfig > > Changes in v4: > * Use arch/x86/cpu/start.S with CONFIG_SYS_SLIMBOOTLOADER condition > * Update U-boot or u-boot to U-Boot in commit message > * Add static keyword in static function > > Changes in v3: > * Add a brief description about Slim Bootloader in 1st patch > * Add a common HOB library to be used by both FSP and Slim Bootloader > * Move board/slimbootloader/slimbootloader to board/intel/slimbootloader > * Add more description board/intel/slimbootloader/README > * Fix comments from the code review > > Changes in v2: > * Split a single patch to 8 patches > * Add more comment for each structure and functions > > Aiden Park (8): > x86: Add new slimbootloader CPU type > x86: Add a common hob library > x86: slimbootloader: Add memory configuration > x86: slimbootloader: Add serial driver > x86: slimbootloader: Set TSC information for timer driver > x86: slimbootloader: Add a slimbootloader device tree > board: intel: Add new slimbootloader board > x86: Skip setting up MTRRs in slimbootloader > > arch/x86/Kconfig | 1 + > arch/x86/cpu/Makefile | 1 + > arch/x86/cpu/slimbootloader/Kconfig | 26 ++ > arch/x86/cpu/slimbootloader/Makefile | 5 + > arch/x86/cpu/slimbootloader/car.S | 14 + > arch/x86/cpu/slimbootloader/dram.c| 151 +++ > arch/x86/cpu/slimbootloader/serial.c | 69 + > arch/x86/cpu/slimbootloader/slimbootloader.c | 55 > arch/x86/cpu/start.S | 6 +- > arch/x86/dts/Makefile | 1 + > arch/x86/dts/slimbootloader.dts | 27 ++ > .../asm/arch-slimbootloader/slimbootloader.h | 121 + > arch/x86/include/asm/fsp/fsp_hob.h| 183 + > arch/x86/include/asm/fsp/fsp_support.h| 37 +-- > arch/x86/include/asm/fsp/fsp_types.h | 8 - > arch/x86/include/asm/global_data.h| 2 +- > arch/x86/include/asm/hob.h| 250 ++ > arch/x86/lib/Makefile | 3 +- > arch/x86/lib/asm-offsets.c| 2 +- > arch/x86/lib/fsp/fsp_support.c| 78 +- > arch/x86/lib/hob.c| 104 > arch/x86/lib/init_helpers.c | 3 +- > board/intel/Kconfig | 14 + > board/intel/slimbootloader/Kconfig| 51 > board/intel/slimbootloader/Makefile | 5 + > board/intel/slimbootloader/README | 133 ++ > board/intel/slimbootloader/slimbootloader.c | 17 ++ > board/intel/slimbootloader/start.S| 9 + > configs/slimbootloader_defconfig | 21 ++ > include/configs/slimbootloader.h | 59 + > 30 files changed, 1149 insertions(+), 307 deletions(-) > create mode 100644 arch/x86/cpu/slimbootloader/Kconfig > create mode 100644 arch/x86/cpu/slimbootloader/Makefile > create mode 100644 arch/x86/cpu/slimbootloader/car.S > create mode 100644 arch/x86/cpu/slimbootloader/dram.c > create mode 100644 arch/x86/cpu/slimbootloader/serial.c > create mode 100644 arch/x86/cpu/slimbootloader/slimbootloader.c > create mode 100644 arch/x86/dts/slimbootloader.dts > create mode 100644 arch/x86/include/asm/arch-slimbootloader/slimbootloader.h > create mode 100644
Re: [U-Boot] [PATCH] rtc: ds3232/ds3231: Add support to generate 32KHz output for driver module
Dear Chuanhua Han,
In message <20190722075642.1456-1-chuanhua@nxp.com> you wrote:
> This patch add an implementation of the rtc_enable_32khz_output() that
> uses the driver model i2c APIs.
>
> Signed-off-by: Chuanhua Han
> ---
> drivers/rtc/ds3231.c | 17 +
> include/rtc.h| 1 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/rtc/ds3231.c b/drivers/rtc/ds3231.c
> index 79b026a..2f7bbc2 100644
> --- a/drivers/rtc/ds3231.c
> +++ b/drivers/rtc/ds3231.c
> @@ -251,6 +251,23 @@ static int ds3231_probe(struct udevice *dev)
> return 0;
> }
>
> +void rtc_enable_32khz_output(void)
> +{
> + int ret;
> + struct udevice *dev;
> +
> +#ifdef CONFIG_DS3231_BUS_NUM
> + ret = i2c_get_chip_for_busnum(CONFIG_DS3231_BUS_NUM,
> + CONFIG_SYS_I2C_RTC_ADDR, 1, );
> +#else
> + ret = i2c_get_chip_for_busnum(0, CONFIG_SYS_I2C_RTC_ADDR, 1, );
> +#endif
> + if (!ret)
> + dm_i2c_reg_write(dev, RTC_STAT_REG_ADDR,
> + RTC_STAT_BIT_BB32KHZ |
> + RTC_STAT_BIT_EN32KHZ);
> +}
> +
You add this code unconditonally, so it increases code size for all
users. But I guess only a tiny fraction will ever need this.
Please add some appropiate CONFIG_ option so this code compiles only
in that cases where it is really needed.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Above all else -- sky.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, Build is here: https://travis-ci.org/sglass68/u-boot/builds/561552377 The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2: Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-22jul19 for you to fetch changes up to 857ad7985ff63989c3c7feff56c2dc353d7d7c9a: dm: device: make power domain calls optional (2019-07-20 19:50:44 -0600) Minor driver-model fixes and tweaks A few device-tree fixes Binman support for extracting files from an image Anatolij Gustschin (1): dm: device: make power domain calls optional Baruch Siach (2): dm: uclass: fix comment copy/paste error buildman: fix invocation examples typos Bin Meng (4): dm: timer: Skip device that does not have a valid ofnode in pre_probe() dm: core: Call clk_set_defaults() during probe() only for a valid ofnode dm: core: Set correct "status" value for a node dm: Fix parameter description of dev_read_name() Marek Vasut (1): common: fdt_support: Add missing cpu_to_fdt32() to fdt_pci_dma_ranges() Masahiro Yamada (1): fdt: make fdt_get_base_address() return OF_BAD_ADDR when "reg" not found Sekhar Nori (1): clk: initialize clk->data when using default xlate Simon Glass (68): x86: Add ifwitool for Intel Integrated Firmware Image cbfs: Add an enum and comment for the magic number cbfs: Rename checksum to attributes_offset tools: Drop duplicate raise_on_error argument binman: Fix comment in bsection.GetEntries() binman: Correct two typos in function names in ftest binman: Add coverage tools info for Python 3 patman: Add a way to set the search path for tools binman: Add a --toolpath option to set the tool search path binman: Add missing comments to bsection binman: Add missing comments toentry binman: Tidy up help for --indir binman: Use a better error for missing Intel descriptor binman: Detect skipped tests binman: Add a function to create a sample ELF file binman: Add a function to decode an ELF file binman: Ensure that coverage has access to site packages binman: Assume Intel descriptor is at the start of the image binman: Don't assume there is an ME region binman: Update entry.SetOffsetSize to be optional binman: Allow text directly in the node patman: Add functions to compress and decompress data binman: Use the tools.Decompress method binman: Drop unnecessary debug handling binman: Use tools compression function for blob handling binman: Correct comment in u_boot_spl_elf binman: Support ELF files for TPL binman: Fix up the _DoTestFile() function -u argument binman: Allow verbosity control when running tests binman: Allow preserving test directories binman: Pass the toolpath to tests patman: Add a function to write ifwitool binman: Add a utility library for coreboot CBFS binman: Add support for CBFS entries binman: Add support for Intel IFWI entries binman: Pad empty areas of the CBFS with files binman: Add support for fixed-offset files in CBFS binman: Simplify the entry test binman: Update future features binman: Update help for new features binman: Add a convenience functions for real-DTB tests binman: Add an FDT map binman: Add an image header binman: Convert to use ArgumentParser binman: Move compression into the Entry base class binman: Drop an unused arg in Entry.Lookup() binman: Allow easy importing of entry modules binman: Fix up ProcessUpdateContents error and comments binman: Call ProcessUpdateContents() consistently binman: Add a return value to ProcessContentsUpdate() binman: Add a control for post-pack entry expansion binman: Allow entries to expand after packing binman: Allow device-tree entries to be compressed binman: Provide the actual data address for cbfs files binman: Use the cbfs memlen field only for uncompressed length binman: Support FDT update for CBFS binman: Detect bad CBFS file types binman: Allow listing the entries in an image binman: Support locating an FDT map binman: Support locating an image header binman: Support reading an image into an Image object binman: Convert Image to a subclass of Entry binman: Support listing an image binman: Allow for logging information to be displayed binman: Allow reading an entry from an image binman: Support reading from CBFS entries binman: Add an 'extract' command binman: Add a test for nested and aligned sections .travis.yml
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > > >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt > > >>> wrote: > > > > In GRUB before 2.04 a bug existed which did not allow booting some > > ARM32 > > boards if U-Boot did not disable caches, cf. > > https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > > > > In ExitBootServices() we were disabling the caches by calling > > cleanup_before_linux(). This workaround is not needed anymore. > > >>> > > >>> Do we want to remove this straight away? A lot of distributions will > > >>> take time to move to grub 2.04 because it's been a long time between > > >>> grub releases so they'll have quite a patch delta to re-align to the > > >>> new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > > >>> which will start development end of August but won't be released until > > >>> next year. > > >> > > >> As described below this code does not remove any functionality that was > > >> active in U-Boot v2019.04 or v2019.07. > > >> > > >> I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > > >> stopping GRUB 2.04 from being made available for stable Fedora releases. > > > > > > The maintainers believe that it's too intrusive to land now and they > > > want maximum testing time before it gets to stable users, funnily > > > enough people don't like it when their machines cease to boot. > > > > Why should anybody's machines cease to boot? > > > > If Fedora does not role out a new U-Boot they are fine. If Fedora roles > > out a new U-Boot they should role out a matching GRUB and they are fine too. > > > > The venturous who build their own U-Boot should know how to role back > > their system if needed. > > You've clearly never maintained a distribution across 1000s of device > types and 100s of thousands of users. > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > version of grub that the maintainers wish to support, if that requires > me to revert a number of your changes I will, which will be an > inconvenience and probably take more time than I have spare but I will > survive. I find it strange you fix one OS only to break another. How > will this work for users that want to boot a newly released device > which has recently added U-Boot support to an already released stable > OS? > > If you wish to actively break currently working use cases that's your > prerogative that is your choice but I find breaking currently working > use cases without a reasonable window to migrate dependencies actively > hostile which has tended to not be the way U-Boot has worked in the > past for such things as DM, so breaking a interface to the way OSes > boot IMO is even worse. OK, we have a problem here. A better example than DM would be the various work-arounds we have (or carried for ages) to allow using newer U-Boot with various old and broken kernels. So no, we need to keep this work-around for a long while. What's the EOL date for any Linux distribution that uses this broken grub? The first U-Boot release post that EOL date is when we can drop this particular bit of work-around code. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 3/4] riscv: sifive: fu540: Sync-up config header with RISC-V QEMU support
On Mon, Jul 22, 2019 at 3:38 PM Anup Patel wrote: > > We typically use same set of distro images (yocto, debian, fedora, etc.) > on both QEMU RISC-V virt machine and SiFive Unleashed board. > > With growing kernel and ramdisk images, we need to re-adjust default > U-Boot environment variables. The config header for QEMU RISC-V virt > machine has been already updated to handle bigger kernel and ramdisk > images hence this patch updates SiFive FU540 config header accordingly. > > Signed-off-by: Anup Patel > --- > include/configs/sifive-fu540.h | 18 +++--- > 1 file changed, 11 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/8] x86: Add new slimbootloader CPU type
On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden wrote: > > This slimbootloader cpu type is to enable U-Boot as a payload which cpu -> CPU > runs on top of Slim Bootloader(https://github.com/slimbootloader). > The Slim Bootloader is designed with multi-stage architecture for > the execution from reset vector to OS booting, and supports qemu, qemu -> QEMU > Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP > (https://github.com/IntelFsp) for silicon initialization including > CAR and memory initialization. > The Slim Bootloader generates new HOB(Hand Off Block) which are > serial port info, memory map info, performance data info and so on, > and passes it to a Payload. U-Boot as a payload will use these HOB > information for basic initialization such as serial console. > +config SYS_SLIMBOOTLOADER > + bool > + default y def_bool y ? > + imply SYS_NS16550 > + imply AHCI_PCI > + imply SCSI > + imply SCSI_AHCI > + imply MMC > + imply MMC_PCI > + imply MMC_SDHCI > + imply MMC_SDHCI_SDMA > + imply USB > + imply USB_EHCI_HCD > + imply USB_XHCI_HCD > + imply USB_STORAGE > + imply USB_KEYBOARD > + imply E1000 > + imply RTL8169 Is it part of SoC? I dunno we have Realtek inside, usually either Intel or Synopsys. > -#ifndef CONFIG_HAVE_FSP > +#if !defined(CONFIG_HAVE_FSP) && !defined(CONFIG_SYS_SLIMBOOTLOADER) > -#ifdef CONFIG_HAVE_FSP > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER) Hmm... Maybe reasonable to have an additional option to tell something CONFIG_WE_HAVE_HOB_BUT_FSP. > /* Store the HOB list if we have one */ > test%esi, %esi > jz skip_hob > movl%esi, GD_HOB_LIST(%edx) > > +#ifdef CONFIG_HAVE_FSP > +#endif > +#ifndef __SLIMBOOTLOADER_ARCH_H__ > +#define __SLIMBOOTLOADER_ARCH_H__ > + > +#include Is it going to be expanded later? Otherwise I do not really see a point. > +#endif > -#ifdef CONFIG_HAVE_FSP > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER) > -#ifdef CONFIG_HAVE_FSP > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER) Same as above. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 7/9] riscv: sifive: fu540: Setup ethaddr env variable using OTP
On 7/10/19 10:28 PM, Anup Patel wrote:
-Original Message-
From: Troy Benjegerdes
Sent: Wednesday, July 10, 2019 10:45 PM
To: Anup Patel ; Sagar Karandikar
; Joey Hewitt
Cc: Rick Chen ; Bin Meng ;
Lukas Auer ; Simon Glass
; Ramon Fried ; Joe
Hershberger ; Palmer Dabbelt
; Paul Walmsley ; Atish
Patra ; Alistair Francis ;
U-Boot Mailing List
Subject: Re: [PATCH v7 7/9] riscv: sifive: fu540: Setup ethaddr env variable
using OTP
On Jun 23, 2019, at 11:03 PM, Anup Patel wrote:
This patch extends SiFive FU540 board support to setup ethaddr env
variable based on board serialnum read from OTP.
Signed-off-by: Anup Patel
---
board/sifive/fu540/fu540.c | 122
+
configs/sifive_fu540_defconfig | 1 +
2 files changed, 123 insertions(+)
diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
index 5adc4a3d4a..11daf1a75a 100644
--- a/board/sifive/fu540/fu540.c
+++ b/board/sifive/fu540/fu540.c
@@ -8,6 +8,128 @@
#include
#include
+#include
+#include
+
+#ifdef CONFIG_MISC_INIT_R
+
+#define FU540_OTP_BASE_ADDR0x1007
+
+struct fu540_otp_regs {
+ u32 pa; /* Address input */
+ u32 paio; /* Program address input */
+ u32 pas;/* Program redundancy cell selection input */
+ u32 pce;/* OTP Macro enable input */
+ u32 pclk; /* Clock input */
+ u32 pdin; /* Write data input */
+ u32 pdout; /* Read data output */
+ u32 pdstb; /* Deep standby mode enable input (active low) */
+ u32 pprog; /* Program mode enable input */
+ u32 ptc;/* Test column enable input */
+ u32 ptm;/* Test mode enable input */
+ u32 ptm_rep;/* Repair function test mode enable input */
+ u32 ptr;/* Test row enable input */
+ u32 ptrim; /* Repair function enable input */
+ u32 pwe;/* Write enable input (defines program cycle) */
+} __packed;
+
+#define BYTES_PER_FUSE 4
+#define NUM_FUSES 0x1000
+
+static int fu540_otp_read(int offset, void *buf, int size) {
+ struct fu540_otp_regs *regs = (void __iomem
*)FU540_OTP_BASE_ADDR;
+ unsigned int i;
+ int fuseidx = offset / BYTES_PER_FUSE;
+ int fusecount = size / BYTES_PER_FUSE;
+ u32 fusebuf[fusecount];
+
+ /* check bounds */
+ if (offset < 0 || size < 0)
+ return -EINVAL;
+ if (fuseidx >= NUM_FUSES)
+ return -EINVAL;
+ if ((fuseidx + fusecount) > NUM_FUSES)
+ return -EINVAL;
+
+ /* init OTP */
+ writel(0x01, >pdstb); /* wake up from stand-by */
+ writel(0x01, >ptrim); /* enable repair function */
+ writel(0x01, >pce); /* enable input */
+
+ /* read all requested fuses */
+ for (i = 0; i < fusecount; i++, fuseidx++) {
+ writel(fuseidx, >pa);
+
+ /* cycle clock to read */
+ writel(0x01, >pclk);
+ mdelay(1);
+ writel(0x00, >pclk);
+ mdelay(1);
+
+ /* read the value */
+ fusebuf[i] = readl(>pdout);
+ }
+
+ /* shut down */
+ writel(0, >pce);
+ writel(0, >ptrim);
+ writel(0, >pdstb);
+
+ /* copy out */
+ memcpy(buf, fusebuf, size);
+
+ return 0;
+}
+
+static u32 fu540_read_serialnum(void) {
+ int ret;
+ u32 serial[2] = {0};
+
+ for (int i = 0xfe * 4; i > 0; i -= 8) {
+ ret = fu540_otp_read(i, serial, sizeof(serial));
+ if (ret) {
+ printf("%s: error reading from OTP\n", __func__);
+ break;
+ }
+ if (serial[0] == ~serial[1])
+ return serial[0];
+ }
+
+ return 0;
+}
Please take a look at the DM-enabled SiFive OTP driver submitted by Joey
Hewitt at https://github.com/sifive/HiFive_U-
Boot/commit/6d842765de142b61f847852da7a9ce0d081d770c
This Joey's version also sets the ‘serial#’ environment variable, while this
patch only sets ‘ethaddr'
I am not sure if "serial#" environment variable is a standard U-Boot
way of advertising serial number of underlying Host.
Where is this used?
Regards,
Anup
The serial# var is inserted into the device tree.
https://github.com/u-boot/u-boot/blob/0de815356474912ef5bef9a69f0327a5a93bb2c2/common/fdt_support.c#L199
See also
https://github.com/torvalds/linux/commit/13dd92bb4599b5655cafe1f2c0365396a096b94a
I don't recall if it had any particularly special meaning on the kernels
I tested with, but it seems to be standard and could be useful to userspace.
-Joey
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
