Re: [U-Boot] [PATCH v3] usb: dwc3: convert to livetree
Hi Marek/Michal,
Can you please review and let me know if any comments otherwise, please take it
up.
Thanks,
Siva
> -Original Message-
> From: Siva Durga Prasad Paladugu [mailto:siva.durga.palad...@xilinx.com]
> Sent: Friday, September 07, 2018 4:27 PM
> To: u-boot@lists.denx.de
> Cc: Michal Simek ; ma...@denx.de;
> bmeng...@gmail.com; s...@chromium.org;
> yamada.masah...@socionext.com; Vipul Kumar ; Siva
> Durga Prasad Paladugu
> Subject: [PATCH v3] usb: dwc3: convert to livetree
>
> From: Vipul Kumar
>
> Update the DWC3 USB driver to support a live tree.
>
> Signed-off-by: Vipul Kumar
> Signed-off-by: Siva Durga Prasad Paladugu
>
> Tested-by: Michal Simek
> ---
> Changes in v3:
> - Used ofnode_valid() to check for node validity
> This fixes the below compilation failure
> for stih410-b2260_defconfig
> LD cmd/built-in.o
> drivers/usb/host/dwc3-sti-glue.c: In function ‘sti_dwc3_glue_bind’:
> drivers/usb/host/dwc3-sti-glue.c:160:16: error: invalid operands to binary
> <= (have ‘ofnode {aka union ofnode_union}’ and ‘int’)
> if (dwc3_node <= 0) {
> ^~
> make[1]: *** [drivers/usb/host/dwc3-sti-glue.o] Error 1
>
> Changes in v2:
> - compilation failures for am335x_hs_evm_uart platform during travis ci as
> v1 didn’t made corresponding changes to drivers/usb/musb-new/ti-
> musb.c
> as per live tree conversion.
> Now it is fixed in v2 by moving this driver to support live tree.
> Also fixed dwc3-sti-glue.c to support live tree.
> ---
> drivers/usb/common/common.c | 11 +--
> drivers/usb/dwc3/dwc3-generic.c | 17 +++--
> drivers/usb/host/dwc3-sti-glue.c | 9 -
> drivers/usb/host/xhci-dwc3.c | 3 ++-
> drivers/usb/host/xhci-zynqmp.c | 3 +--
> drivers/usb/musb-new/ti-musb.c | 11 ---
> include/linux/usb/otg.h | 6 --
> 7 files changed, 27 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/usb/common/common.c
> b/drivers/usb/common/common.c index a55def5..3dea79b 100644
> --- a/drivers/usb/common/common.c
> +++ b/drivers/usb/common/common.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -20,13 +21,12 @@ static const char *const usb_dr_modes[] = {
> [USB_DR_MODE_OTG] = "otg",
> };
>
> -enum usb_dr_mode usb_get_dr_mode(int node)
> +enum usb_dr_mode usb_get_dr_mode(ofnode node)
> {
> - const void *fdt = gd->fdt_blob;
> const char *dr_mode;
> int i;
>
> - dr_mode = fdt_getprop(fdt, node, "dr_mode", NULL);
> + dr_mode = ofnode_get_property(node, "dr_mode", NULL);
> if (!dr_mode) {
> pr_err("usb dr_mode not found\n");
> return USB_DR_MODE_UNKNOWN;
> @@ -48,13 +48,12 @@ static const char *const speed_names[] = {
> [USB_SPEED_SUPER] = "super-speed",
> };
>
> -enum usb_device_speed usb_get_maximum_speed(int node)
> +enum usb_device_speed usb_get_maximum_speed(ofnode node)
> {
> - const void *fdt = gd->fdt_blob;
> const char *max_speed;
> int i;
>
> - max_speed = fdt_getprop(fdt, node, "maximum-speed", NULL);
> + max_speed = ofnode_get_property(node, "maximum-speed",
> NULL);
> if (!max_speed) {
> pr_err("usb maximum-speed not found\n");
> return USB_SPEED_UNKNOWN;
> diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-
> generic.c index ca63eac..ef72c8c 100644
> --- a/drivers/usb/dwc3/dwc3-generic.c
> +++ b/drivers/usb/dwc3/dwc3-generic.c
> @@ -61,18 +61,17 @@ static int dwc3_generic_peripheral_remove(struct
> udevice *dev) static int
> dwc3_generic_peripheral_ofdata_to_platdata(struct udevice *dev) {
> struct dwc3 *priv = dev_get_priv(dev);
> - int node = dev_of_offset(dev);
>
> - priv->regs = (void *)devfdt_get_addr(dev);
> + priv->regs = (void *)dev_read_addr(dev);
> priv->regs += DWC3_GLOBALS_REGS_START;
>
> - priv->maximum_speed = usb_get_maximum_speed(node);
> + priv->maximum_speed = usb_get_maximum_speed(dev->node);
> if (priv->maximum_speed == USB_SPEED_UNKNOWN) {
> pr_err("Invalid usb maximum speed\n");
> return -ENODEV;
> }
>
> - priv->dr_mode = usb_get_dr_mode(node);
> + priv->dr_mode = usb_get_dr_mode(dev->node);
> if (priv->dr_mode == USB_DR_MODE_UNKNOWN) {
> pr_err("Invalid usb mode setup\n");
> return -ENODEV;
> @@ -100,13 +99,11 @@ U_BOOT_DRIVER(dwc3_generic_peripheral) = {
>
> static int dwc3_generic_bind(struct udevice *parent) {
> - const void *fdt = gd->fdt_blob;
> - int node;
> + ofnode node;
> int ret;
>
> - for (node = fdt_first_subnode(fdt, dev_of_offset(parent)); node > 0;
> - node = fdt_next_subnode(fdt, node)) {
> - const char *name = fdt_get_name(fdt, node, NULL);
> + dev_for_each_subnode(node, parent) {
> + const char *name = (char *)ofnode_get_name(node);
>
Re: [U-Boot] [PATCH V2] test/py: ignore console read exceptions after test failure
On 09/21/2018 12:55 AM, Stephen Warren wrote: > From: Stephen Warren > > After a test has failed, test/py drains the U-Boot console log to ensure > that any relevant output is captured. At this point, we don't care about > detecting any additional errors, since the test is already known to have > failed, and U-Boot will be restarted. To ensure that the test cleanup code > is not interrupted, and can correctly terminate the log sections for the > failed test, ignore any exception that occurs while reading the U-Boot > console output during this limited period of time. > > Signed-off-by: Stephen Warren > --- > v2: > * Combine the two except cases into one, since one was a superset of the > other. > * Fix TAB-vs-spaces issue in identation. > --- > test/py/u_boot_console_base.py | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py > index a14bad6e8c50..326b2ac51fbf 100644 > --- a/test/py/u_boot_console_base.py > +++ b/test/py/u_boot_console_base.py > @@ -304,7 +304,17 @@ class ConsoleBase(object): > # Wait for something U-Boot will likely never send. This will > # cause the console output to be read and logged. > self.p.expect(['This should never match U-Boot output']) > -except u_boot_spawn.Timeout: > +except: > +# We expect a timeout, since U-Boot won't print what we waited > +# for. Squash it when it happens. > +# > +# Squash any other exception too. This function is only used to > +# drain (and log) the U-Boot console output after a failed test. > +# The U-Boot process will be restarted, or target board reset, > once > +# this function returns. So, we don't care about detecting any > +# additional errors, so they're squashed so that the rest of the > +# post-test-failure cleanup code can continue operation, and > +# correctly terminate any log sections, etc. > pass > finally: > self.p.timeout = orig_timeout > This patch only covers this single usage of the expect(). Expect() is called from many test cases directly. In all these cases we still will not catch OSErrror if the U-Boot binary terminates breaking the pipes. That is why in my patch I put the except statement into the except() method itself. What problem do you see in catching the exception where it is arising? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
On Tue, 2018-07-31 at 08:22 +0200, Michal Simek wrote: > On 30.7.2018 18:05, Simon Glass wrote: > > > > Hi Michal, > > > > On 30 July 2018 at 07:30, Michal Simek > > wrote: > > > > > > On 30.7.2018 15:26, Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On 27 July 2018 at 02:40, Chee, Tien Fong > > > .com> wrote: > > > > > > > > > > > > > > > On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote: > > > > > > > > > > > > On 25.7.2018 18:03, Tom Rini wrote: > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 25 July 2018 at 03:48, Michal Simek > > > > > > > linx.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 25.7.2018 08:31, Chee, Tien Fong wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also that DT binding is quite weird and I don't > > > > > > > > > > > think you > > > > > > > > > > > will get > > > > > > > > > > > ACK > > > > > > > > > > > for this from device tree community at all. I > > > > > > > > > > > think that > > > > > > > > > > > calling via > > > > > > > > > > > platdata and avoid DT nodes would be better way > > > > > > > > > > > to go. > > > > > > > > > > Why do you think DT binding is weird? The DT is > > > > > > > > > > designed > > > > > > > > > > based on Simon > > > > > > > > > > proposal, and i believe following the rules in DTS > > > > > > > > > > spec. > > > > > > > > > > There are some DT benefits with current design, i > > > > > > > > > > think > > > > > > > > > > someone may be > > > > > > > > > > maintainer need to made the final decision on the > > > > > > > > > > design. > > > > > > > > > It is software configuration in file which should > > > > > > > > > mostly > > > > > > > > > describe > > > > > > > > > hardware and state for hardware configuration. > > > > > > > > > > > > > > > > > > Your fs_loader node is purely describe sw > > > > > > > > > configuration which > > > > > > > > > shouldn't > > > > > > > > > be here. > > > > > > > > > You have there run time configuration via variables. > > > > > > > > > I think > > > > > > > > > using only > > > > > > > > > this way is enough. Default variables will match what > > > > > > > > > you would > > > > > > > > > want to > > > > > > > > > add to DT. > > > > > > > > I think DT makes sense in the U-Boot context. > > > > > > > > > > > > > > > > We don't have a user space to handle policy decisions, > > > > > > > > and the > > > > > > > > 'chosen' node is a good place to configure these common > > > > > > > > features. > > > > > > > > > > > > > > > > While you can argue that the partition or filesystem > > > > > > > > where an > > > > > > > > image > > > > > > > > comes from is a software config, it is something that > > > > > > > > has to be > > > > > > > > configured. It has impact on hardware too, since the > > > > > > > > FPGA has to > > > > > > > > get > > > > > > > > its firmware from somewhere. We use the chosen node to > > > > > > > > specify > > > > > > > > the > > > > > > > > UART to use, and this is no different. Again, we don't > > > > > > > > have user- > > > > > > > > space > > > > > > > > config files in U-Boot. > > > > > > > > > > > > > > > > This argument comes up from time to time and I'd really > > > > > > > > like to > > > > > > > > put it > > > > > > > > to bed for U-Boot. I understand that Linux has its own > > > > > > > > approach > > > > > > > > and > > > > > > > > rules, but in some cases they serve U-Boot poorly. > > > > > > > I want to second this as well. So long as we're using > > > > > > > our prefix > > > > > > > and > > > > > > > we've thought through and discussed what we're trying to > > > > > > > do here, > > > > > > > it's > > > > > > > OK to do things that might not be accepted for Linux. > > > > > > > > > > > > > I have not a problem with using chosen node with u-boot > > > > > > prefix > > > > > > properties and my colleague hopefully with finish work > > > > > > about moving > > > > > > u-boot,dm-pre-reloc; to chosen node where it should be > > > > > > (because > > > > > > current > > > > > > solution has also problem with ordering). > > > > > > > > > > > > In this loader case doc is saying that you can rewrite it > > > > > > with > > > > > > variables > > > > > > on the prompt
[U-Boot] Building for ARMv5 - uint64_t alignment issues
Dear all, Most of my u-boot work is on one of two ARMv5 platforms. When u-boot changed to requiring a later gcc, I switched from my old-faithful arago-2011.09 compiler to a newer Linaro release: gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabi And for my work on the da850 this seems to be fine. However I've been doing some work creating a nand driver for an older chip (which I really wish I didn't have to care about, and is never going to see the light of upstream). Short form: inexplicable errors, which I eventually chased down to issues around uint64_t. Some googling turned up this bug (and patch): http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144043.html So I upgraded to the next Linaro release: gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabi This fixed the problem in what I'll call "general" uint64_t usage, but still left the same problem in structs. Specifically size in struct mdt_info. Which I fixed by kludging -mstructure-size-boundary=64 into the build (which AFAIK I shouldn't have to do). I would hope I'm not the only person who can trigger this . . . which means I'm hoping that no-one else has hit this (as far as I can tell from the u-boot list) is that anyone building for ARMv5 is using a different toolchain. So . . . can those of you out there building for any of the v5 boards tell me what toolchain you're currently using? And if you hit/fixed/worked around strd issues? Thanks -- Peter Howard signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v3 patch] net: fman: Support both new and legacy FMan Compatibles
Hi York,
It seems nobody have comments on this patch,
Could you help to take action on it?
Best Regards
Qiang Zhao
> -Original Message-
> From: Zhao Qiang
> Sent: 2018年8月29日 11:47
> To: York Sun ; joe.hershber...@ni.com
> Cc: u-boot@lists.denx.de; Qiang Zhao
> Subject: [v3 patch] net: fman: Support both new and legacy FMan Compatibles
>
> Recently the FMan Port and MAC compatibles were changed.
> This patch aligns the FMan Port and MAC compatibles to the new FMan device
> tree binding document.
> The FMan device tree binding document can be found in the Linux
> kernel:
> version 3.18.0
> commit 297d35fd2a7d3fbd4e5c0f0c1c18213117ba11ba
> ./Documentation/devicetree/bindings/powerpc/fsl/fman.txt
>
> This patch doesn't affect legacy compatibles support.
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2
> - add kernel version and commit id modifing the binding Changes for v3
> - put "fsl,fman-xgec" before "fsl,fman-tgec"
> - because it use the former in latest kernel version
>
> drivers/net/fm/init.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c index
> 147d043..f896e80
> 100644
> --- a/drivers/net/fm/init.c
> +++ b/drivers/net/fm/init.c
> @@ -328,7 +328,8 @@ void fdt_fixup_fman_ethernet(void *blob)
> ft_fixup_port(blob, _info[i],
> "fsl,fman-1g-mac");
> } else {
> - if (ft_fixup_port(blob, _info[i], "fsl,fman-tgec"))
> + if (ft_fixup_port(blob, _info[i], "fsl,fman-xgec") &&
> + ft_fixup_port(blob, _info[i], "fsl,fman-tgec"))
> ft_fixup_port(blob, _info[i],
> "fsl,fman-10g-mac");
> }
> --
> 1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/7] drivers: spi: cf_spi: migrate to DM and DT
This patch converts cf_spi.c to DM and to read driver
platform data from flat devicetree.
---
Changes from v1:
- split into 2 patches
Signed-off-by: Angelo Dureghello
---
drivers/spi/Kconfig | 18 +-
drivers/spi/cf_spi.c| 495
include/dm/platform_data/spi_coldfire.h | 25 ++
3 files changed, 369 insertions(+), 169 deletions(-)
create mode 100644 include/dm/platform_data/spi_coldfire.h
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index dcd719ff0a..974c5bbed8 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -80,6 +80,12 @@ config CADENCE_QSPI
used to access the SPI NOR flash on platforms embedding this
Cadence IP core.
+config CF_SPI
+bool "ColdFire SPI driver"
+help
+ Enable the ColdFire SPI driver. This driver can be used on
+ some m68k SoCs.
+
config DESIGNWARE_SPI
bool "Designware SPI driver"
help
@@ -244,18 +250,18 @@ config ZYNQMP_GQSPI
endif # if DM_SPI
-config SOFT_SPI
- bool "Soft SPI driver"
- help
-Enable Soft SPI driver. This driver is to use GPIO simulate
-the SPI protocol.
-
config CF_SPI
bool "ColdFire SPI driver"
help
Enable the ColdFire SPI driver. This driver can be used on
some m68k SoCs.
+config SOFT_SPI
+ bool "Soft SPI driver"
+ help
+Enable Soft SPI driver. This driver is to use GPIO simulate
+the SPI protocol.
+
config FSL_ESPI
bool "Freescale eSPI driver"
help
diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
index 522631cbbf..11a11f79c4 100644
--- a/drivers/spi/cf_spi.c
+++ b/drivers/spi/cf_spi.c
@@ -6,16 +6,27 @@
*
* Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
* TsiChung Liew (tsi-chung.l...@freescale.com)
+ *
+ * Support for device model:
+ * Copyright (C) 2018 Angelo Dureghello
+ *
*/
#include
+#include
+#include
#include
#include
#include
+#include
-struct cf_spi_slave {
+struct coldfire_spi_priv {
+#ifndef CONFIG_DM_SPI
struct spi_slave slave;
+#endif
+ struct dspi *regs;
uint baudrate;
+ int mode;
int charbit;
};
@@ -38,14 +49,14 @@ DECLARE_GLOBAL_DATA_PTR;
#define SPI_MODE_MOD 0x0020
#define SPI_DBLRATE0x0010
-static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave *slave)
-{
- return container_of(slave, struct cf_spi_slave, slave);
-}
+/* Default values */
+#define MCF_DSPI_DEFAULT_SCK_FREQ 1000
+#define MCF_DSPI_MAX_CHIPSELECTS 4
+#define MCF_DSPI_MODE 0
-static void cfspi_init(void)
+static void __spi_init(struct coldfire_spi_priv *cfspi)
{
- volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
+ struct dspi *dspi = cfspi->regs;
cfspi_port_conf(); /* port configuration */
@@ -56,125 +67,32 @@ static void cfspi_init(void)
/* Default setting in platform configuration */
#ifdef CONFIG_SYS_DSPI_CTAR0
- dspi->ctar[0] = CONFIG_SYS_DSPI_CTAR0;
+ writel(CONFIG_SYS_DSPI_CTAR0, >ctar[0]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR1
- dspi->ctar[1] = CONFIG_SYS_DSPI_CTAR1;
+ writel(CONFIG_SYS_DSPI_CTAR1, >ctar[1]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR2
- dspi->ctar[2] = CONFIG_SYS_DSPI_CTAR2;
+ writel(CONFIG_SYS_DSPI_CTAR2, >ctar[2]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR3
- dspi->ctar[3] = CONFIG_SYS_DSPI_CTAR3;
+ writel(CONFIG_SYS_DSPI_CTAR3, >ctar[3]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR4
- dspi->ctar[4] = CONFIG_SYS_DSPI_CTAR4;
+ writel(CONFIG_SYS_DSPI_CTAR4, >ctar[4]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR5
- dspi->ctar[5] = CONFIG_SYS_DSPI_CTAR5;
+ writel(CONFIG_SYS_DSPI_CTAR5, >ctar[5]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR6
- dspi->ctar[6] = CONFIG_SYS_DSPI_CTAR6;
+ writel(CONFIG_SYS_DSPI_CTAR6, >ctar[6]);
#endif
#ifdef CONFIG_SYS_DSPI_CTAR7
- dspi->ctar[7] = CONFIG_SYS_DSPI_CTAR7;
+ writel(CONFIG_SYS_DSPI_CTAR7, >ctar[7]);
#endif
}
-static void cfspi_tx(u32 ctrl, u16 data)
-{
- volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
-
- while ((dspi->sr & 0xF000) >= 4) ;
-
- dspi->tfr = (ctrl | data);
-}
-
-static u16 cfspi_rx(void)
-{
- volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
-
- while ((dspi->sr & 0x00F0) == 0) ;
-
- return (dspi->rfr & 0x);
-}
-
-static int cfspi_xfer(struct spi_slave *slave, uint bitlen, const void *dout,
- void *din, ulong flags)
-{
- struct cf_spi_slave *cfslave = to_cf_spi_slave(slave);
- u16 *spi_rd16 = NULL, *spi_wr16 = NULL;
- u8 *spi_rd = NULL, *spi_wr = NULL;
- static u32 ctrl = 0;
- uint len = bitlen >> 3;
-
- if (cfslave->charbit == 16) {
- bitlen >>= 1;
- spi_wr16 = (u16 *) dout;
- spi_rd16 = (u16 *) din;
- } else {
- spi_wr =
[U-Boot] [PATCH 4/7] drivers: serial: mcfuart: add Kconfig option
This patch adds missing CONFIG_MCFUART to Kconfig. Signed-off-by: Angelo Dureghello --- drivers/serial/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 5fa27254e3..dcbe999776 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -499,6 +499,13 @@ config MVEBU_A3700_UART Choose this option to add support for UART driver on the Marvell Armada 3700 SoC. The base address is configured via DT. +config MCFUART + bool "Freescale ColdFire UART support" +default n +help + Choose this option to add support for UART driver on the ColFfire + SoC's family. + config MXC_UART bool "IMX serial port support" depends on MX5 || MX6 -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/7] m68k: add basic set of devicetrees
This patch adds a basic group of devicetrees, one for each
cpu, including actually just uart and dspi devices, since
these are the drivers supporting devicetree (support added
in this patch).
Signed-off-by: Angelo Dureghello
---
arch/m68k/dts/mcf5208.dtsi| 36
arch/m68k/dts/mcf5227x.dtsi | 48 ++
arch/m68k/dts/mcf523x.dtsi| 44 ++
arch/m68k/dts/mcf5249.dtsi| 38
arch/m68k/dts/mcf5253.dtsi| 44 ++
arch/m68k/dts/mcf5271.dtsi| 44 ++
arch/m68k/dts/mcf5272.dtsi| 38
arch/m68k/dts/mcf5275.dtsi| 44 ++
arch/m68k/dts/mcf5282.dtsi| 44 ++
arch/m68k/dts/mcf5301x.dtsi | 48 ++
arch/m68k/dts/mcf5307.dtsi| 39 +
arch/m68k/dts/mcf5329.dtsi| 36
arch/m68k/dts/mcf5441x.dtsi | 87 +++
arch/m68k/dts/mcf5445x.dtsi | 48 ++
doc/device-tree-bindings/serial/mcf-uart.txt | 19
doc/device-tree-bindings/spi/spi-mcf-dspi.txt | 22 +
16 files changed, 679 insertions(+)
create mode 100644 arch/m68k/dts/mcf5208.dtsi
create mode 100644 arch/m68k/dts/mcf5227x.dtsi
create mode 100644 arch/m68k/dts/mcf523x.dtsi
create mode 100644 arch/m68k/dts/mcf5249.dtsi
create mode 100644 arch/m68k/dts/mcf5253.dtsi
create mode 100644 arch/m68k/dts/mcf5271.dtsi
create mode 100644 arch/m68k/dts/mcf5272.dtsi
create mode 100644 arch/m68k/dts/mcf5275.dtsi
create mode 100644 arch/m68k/dts/mcf5282.dtsi
create mode 100644 arch/m68k/dts/mcf5301x.dtsi
create mode 100644 arch/m68k/dts/mcf5307.dtsi
create mode 100644 arch/m68k/dts/mcf5329.dtsi
create mode 100644 arch/m68k/dts/mcf5441x.dtsi
create mode 100644 arch/m68k/dts/mcf5445x.dtsi
create mode 100644 doc/device-tree-bindings/serial/mcf-uart.txt
create mode 100644 doc/device-tree-bindings/spi/spi-mcf-dspi.txt
diff --git a/arch/m68k/dts/mcf5208.dtsi b/arch/m68k/dts/mcf5208.dtsi
new file mode 100644
index 00..558d8bf41a
--- /dev/null
+++ b/arch/m68k/dts/mcf5208.dtsi
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Angelo Dureghello
+ */
+
+/ {
+ compatible = "fsl,mcf5208";
+
+ aliases {
+ serial0 =
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uart0: uart@fc06 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc06 0x40>;
+ status = "disabled";
+ };
+
+ uart1: uart@fc064000 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc064000 0x40>;
+ status = "disabled";
+ };
+
+ uart2: uart@fc068000 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc068000 0x40>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/m68k/dts/mcf5227x.dtsi b/arch/m68k/dts/mcf5227x.dtsi
new file mode 100644
index 00..8c95edddb6
--- /dev/null
+++ b/arch/m68k/dts/mcf5227x.dtsi
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Angelo Dureghello
+ */
+
+/ {
+ compatible = "fsl,mcf5227x";
+
+ aliases {
+ serial0 =
+ spi0 =
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uart0: uart@fc06 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc06 0x40>;
+ status = "disabled";
+ };
+
+ uart1: uart@fc064000 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc064000 0x40>;
+ status = "disabled";
+ };
+
+ uart2: uart@fc068000 {
+ compatible = "fsl,mcf-uart";
+ reg = <0xfc068000 0x40>;
+ status = "disabled";
+ };
+
+ dspi0: dspi@fc05c000 {
+ compatible = "fsl,mcf-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xfc05c000 0x100>;
+ spi-max-frequency = <5000>;
+ num-cs = <4>;
+ spi-mode = <0>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/m68k/dts/mcf523x.dtsi b/arch/m68k/dts/mcf523x.dtsi
new file mode 100644
index 00..9e79d472ec
--- /dev/null
+++ b/arch/m68k/dts/mcf523x.dtsi
@@ -0,0 +1,44 @@
+//
[U-Boot] [PATCH 3/7] drivers: serial: mcfuart: add DT support
This patch adds devicetree support to the mcfuart.c driver.
Signed-off-by: Angelo Dureghello
---
drivers/serial/mcfuart.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c
index 1371049de2..5896a19805 100644
--- a/drivers/serial/mcfuart.c
+++ b/drivers/serial/mcfuart.c
@@ -5,6 +5,9 @@
*
* Modified to add device model (DM) support
* (C) Copyright 2015 Angelo Dureghello
+ *
+ * Modified to add fdt support
+ * (C) Copyright 2018 Angelo Dureghello
*/
/*
@@ -212,6 +215,23 @@ static int coldfire_serial_pending(struct udevice *dev,
bool input)
return 0;
}
+static int coldfire_ofdata_to_platdata(struct udevice *dev)
+{
+ struct coldfire_serial_platdata *plat = dev_get_platdata(dev);
+ fdt_addr_t addr_base;
+
+ addr_base = devfdt_get_addr(dev);
+ if (addr_base == FDT_ADDR_T_NONE)
+ return -ENODEV;
+
+ plat->base = (uint32_t)addr_base;
+
+ plat->port = dev->seq;
+ plat->baudrate = gd->baudrate;
+
+ return 0;
+}
+
static const struct dm_serial_ops coldfire_serial_ops = {
.putc = coldfire_serial_putc,
.pending = coldfire_serial_pending,
@@ -219,9 +239,17 @@ static const struct dm_serial_ops coldfire_serial_ops = {
.setbrg = coldfire_serial_setbrg,
};
+static const struct udevice_id coldfire_serial_ids[] = {
+ { .compatible = "fsl,mcf-uart" },
+ { }
+};
+
U_BOOT_DRIVER(serial_coldfire) = {
.name = "serial_coldfire",
.id = UCLASS_SERIAL,
+ .of_match = coldfire_serial_ids,
+ .ofdata_to_platdata = coldfire_ofdata_to_platdata,
+ .platdata_auto_alloc_size = sizeof(struct coldfire_serial_platdata),
.probe = coldfire_serial_probe,
.ops = _serial_ops,
.flags = DM_FLAG_PRE_RELOC,
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/7] m68k: add stmark2 fdt support
This patch adds stmark2 board fdt support to the m68k arch.
Signed-off-by: Angelo Dureghello
---
arch/m68k/dts/Makefile| 12
arch/m68k/dts/stmark2.dts | 34 ++
2 files changed, 46 insertions(+)
create mode 100644 arch/m68k/dts/Makefile
create mode 100644 arch/m68k/dts/stmark2.dts
diff --git a/arch/m68k/dts/Makefile b/arch/m68k/dts/Makefile
new file mode 100644
index 00..9d2e17abf3
--- /dev/null
+++ b/arch/m68k/dts/Makefile
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+dtb-$(CONFIG_TARGET_STMARK2) += stmark2.dtb
+targets += $(dtb-y)
+
+DTC_FLAGS += -R 4 -p 0x1000
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+ @:
+
+clean-files := *.dtb
diff --git a/arch/m68k/dts/stmark2.dts b/arch/m68k/dts/stmark2.dts
new file mode 100644
index 00..fd8ce4fa35
--- /dev/null
+++ b/arch/m68k/dts/stmark2.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Angelo Dureghello
+ */
+
+/dts-v1/;
+/include/ "mcf5441x.dtsi"
+
+/ {
+ model = "Sysam stmark2";
+ compatible = "sysam,stmark2";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
+
+ {
+ spi-mode = <3>;
+ status = "okay";
+
+ flash: is25lp128@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-flash";
+ spi-max-frequency = <6000>;
+ reg = <1>;
+ };
+};
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/7] m68k: architecture changes to support fdt
This patch adds ftd support to the m68k architecture.
Signed-off-by: Angelo Dureghello
---
arch/Kconfig | 1 +
arch/m68k/Kconfig| 2 ++
arch/m68k/cpu/u-boot.lds | 2 ++
3 files changed, 5 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index bf1b4a9afa..d1917f91e1 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -28,6 +28,7 @@ config M68K
select HAVE_PRIVATE_LIBGCC
select SYS_BOOT_GET_CMDLINE
select SYS_BOOT_GET_KBD
+ select SUPPORT_OF_CONTROL
config MICROBLAZE
bool "MicroBlaze architecture"
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 1f6df5c870..60cb9411ed 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -199,6 +199,8 @@ config TARGET_AMCORE
config TARGET_STMARK2
bool "Support stmark2"
select M54418
+ select OF_CONTROL
+ select DM
endchoice
diff --git a/arch/m68k/cpu/u-boot.lds b/arch/m68k/cpu/u-boot.lds
index 96451208e5..e61630db20 100644
--- a/arch/m68k/cpu/u-boot.lds
+++ b/arch/m68k/cpu/u-boot.lds
@@ -75,6 +75,8 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+ _end = .;
+
__bss_start = .;
.bss (NOLOAD) :
{
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] tools: socfpga: fix sfp_verify_header
On 09/21/2018 02:19 AM, Atsushi Nemoto wrote: > Fix sfp_verify_header to return correct version number. > This fixes "Not a sane SOCFPGA preloader" error message with v1 header. > > Signed-off-by: Atsushi Nemoto Applied, thanks. > --- > v2: move the *ver assignment to just before return. > > tools/socfpgaimage.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c > index 390c9bb..72d8b96 100644 > --- a/tools/socfpgaimage.c > +++ b/tools/socfpgaimage.c > @@ -191,6 +191,7 @@ static int sfp_verify_header(const uint8_t *buf, uint8_t > *ver) > if (hdr_csum != sfp_csum) > return -EINVAL; > > + *ver = header_v0.version; > return img_len; > } > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] rockchip: rk3399: Add Ficus EE board support
Add board support for Ficus EE board from Vamrs. This board utilizes
common Rock960 family support.
Following peripherals are tested and known to work:
* Gigabit Ethernet
* USB 2.0
* MMC
Signed-off-by: Ezequiel Garcia
[Reworked based on common Rock960 family support]
Signed-off-by: Manivannan Sadhasivam
---
Changes in v2: None
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-ficus.dts | 78 ++
configs/ficus-rk3399_defconfig | 71 +++
3 files changed, 150 insertions(+)
create mode 100644 arch/arm/dts/rk3399-ficus.dts
create mode 100644 configs/ficus-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9b891826b73..e2bd9822aa2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-minnie.dtb \
rk3288-vyasa.dtb \
rk3328-evb.dtb \
+ rk3399-ficus.dtb \
rk3368-lion.dtb \
rk3368-sheep.dtb \
rk3368-geekbox.dtb \
diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
new file mode 100644
index 000..de934cd61ab
--- /dev/null
+++ b/arch/arm/dts/rk3399-ficus.dts
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * Schematics available at https://dl.vamrs.com/products/ficus/docs/hw
+ */
+
+/dts-v1/;
+#include "rk3399-rock960.dtsi"
+#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
+
+/ {
+ model = "96boards RK3399 Ficus";
+ compatible = "vamrs,ficus", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+};
+
+ {
+ assigned-clocks = < SCLK_RMII_SRC>;
+ assigned-clock-parents = <_gmac>;
+ clock_in_out = "input";
+ phy-supply = <_sys>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ snps,reset-gpio = < RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+ {
+ ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+ gmac {
+ rgmii_sleep_pins: rgmii-sleep-pins {
+ rockchip,pins =
+ <3 15 RK_FUNC_GPIO _output_low>;
+ };
+ };
+
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <1 24 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 27 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_pcie {
+ gpio = < 24 GPIO_ACTIVE_HIGH>;
+};
+
+_host {
+ gpio = < 27 GPIO_ACTIVE_HIGH>;
+};
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
new file mode 100644
index 000..e890bc25238
--- /dev/null
+++ b/configs/ficus-rk3399_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_TARGET_ROCK960_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_STACK_R_ADDR=0x8
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-ficus"
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_RGMII=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_ROCKCHIP_RK3399=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
[U-Boot] [PATCH v2 3/4] rockchip: rk3399: Add Rock960 CE board support
Add board support for Rock960 CE board from Vamrs. This board utilizes
common Rock960 family support.
Following peripherals are tested and known to work:
* USB 2.0
* MMC
This commit also adds DDR configuration for LPDDR3-2GiB-1600MHz which
is being used on the board.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v2:
* Added missing config options for USB/uSD
* Fixed the commit description for DDR speed
arch/arm/dts/Makefile |1 +
arch/arm/dts/rk3399-rock960.dts | 45 +
.../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 +
configs/rock960-rk3399_defconfig | 67 +
4 files changed, 1649 insertions(+)
create mode 100644 arch/arm/dts/rk3399-rock960.dts
create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
create mode 100644 configs/rock960-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ebfa2272627..9b891826b73 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -51,6 +51,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3399-puma-ddr1333.dtb \
rk3399-puma-ddr1600.dtb \
rk3399-puma-ddr1866.dtb \
+ rk3399-rock960.dtb \
rv1108-evb.dtb
dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-nanopi-k2.dtb \
diff --git a/arch/arm/dts/rk3399-rock960.dts b/arch/arm/dts/rk3399-rock960.dts
new file mode 100644
index 000..25c58b42611
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock960.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+#include "rk3399-rock960.dtsi"
+#include "rk3399-sdram-lpddr3-2GB-1600.dtsi"
+
+/ {
+ model = "96boards Rock960";
+ compatible = "vamrs,rock960", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+};
+
+ {
+ ep-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <2 RK_PA5 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <4 RK_PD1 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_pcie {
+ gpio = < 5 GPIO_ACTIVE_HIGH>;
+};
+
+_host {
+ gpio = < 25 GPIO_ACTIVE_HIGH>;
+};
diff --git a/arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
b/arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
new file mode 100644
index 000..d14e833d228
--- /dev/null
+++ b/arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi
@@ -0,0 +1,1536 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2018 Manivannan Sadhasivam
+ */
+
+ {
+ rockchip,sdram-params = <
+ 0x1
+ 0xa
+ 0x3
+ 0x2
+ 0x2
+ 0x0
+ 0xf
+ 0xf
+ 1
+ 0x1d191519
+ 0x14040808
+ 0x0002
+ 0x6226
+ 0x0054
+ 0x
+ 0x1
+ 0xa
+ 0x3
+ 0x2
+ 0x2
+ 0x0
+ 0xf
+ 0xf
+ 1
+ 0x1d191519
+ 0x14040808
+ 0x0002
+ 0x6226
+ 0x0054
+ 0x
+ 800
+ 6
+ 2
+ 9
+ 1
+ 0x0700
+ 0x
+ 0x
+ 0x
+ 0x
+ 0x0050
+ 0x00027100
+ 0x0320
+ 0x1f40
+ 0x0050
+ 0x00027100
+ 0x0320
+ 0x1f40
+ 0x0050
+ 0x00027100
+ 0x0320
+ 0x01001f40
+ 0x
+ 0x0101
+ 0x00020100
+ 0x00a0
+ 0x0190
+ 0x
+ 0x0618
+ 0x00061800
+ 0x04000618
+ 0x33080004
+ 0x280f0622
+ 0x22330800
+ 0x00280f06
+ 0x06223308
+ 0x0600280f
+ 0x0a0a
+ 0x0600dac0
+ 0x0a0a060c
+ 0x0600dac0
+ 0x0a0a060c
+ 0x0600dac0
+ 0x0203000c
+ 0x0f0c0f00
+ 0x040c0f0c
+ 0x14000a0a
+ 0x03030a0a
+ 0x00010003
+ 0x031b1b1b
+ 0x0011
+ 0x
+ 0x0301
+ 0x0c2800a8
+ 0x0c2800a8
+
[U-Boot] [PATCH v2 2/4] rockchip: rk3399: Add common Rock960 family from Vamrs
Rock960 is a family of boards based on Rockchip RK3399 SoC from Vamrs.
It consists of Rock960 (Consumer Edition) and Ficus (Enterprise Edition)
96Boards.
Below are some of the key differences between both Rock960 and Ficus
boards:
1. Different host enable GPIO for USB
2. Different power and reset GPIO for PCI-E
3. No Ethernet port on Rock960
The common board support will be utilized by both boards. The device
tree has been organized in such a way that only the properties which
differ between both boards are placed in the board specific dts and
the reset of the nodes are placed in common dtsi file.
Signed-off-by: Manivannan Sadhasivam
[Added instructions for SD card boot]
Signed-off-by: Ezequiel Garcia
---
Changes in v2: None
arch/arm/dts/rk3399-rock960.dtsi| 506
arch/arm/mach-rockchip/rk3399/Kconfig | 26 +
board/vamrs/rock960_rk3399/Kconfig | 15 +
board/vamrs/rock960_rk3399/MAINTAINERS | 6 +
board/vamrs/rock960_rk3399/Makefile | 6 +
board/vamrs/rock960_rk3399/README | 151 ++
board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 ++
include/configs/rock960_rk3399.h| 15 +
8 files changed, 775 insertions(+)
create mode 100644 arch/arm/dts/rk3399-rock960.dtsi
create mode 100644 board/vamrs/rock960_rk3399/Kconfig
create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
create mode 100644 board/vamrs/rock960_rk3399/Makefile
create mode 100644 board/vamrs/rock960_rk3399/README
create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
create mode 100644 include/configs/rock960_rk3399.h
diff --git a/arch/arm/dts/rk3399-rock960.dtsi b/arch/arm/dts/rk3399-rock960.dtsi
new file mode 100644
index 000..51644d6d02d
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock960.dtsi
@@ -0,0 +1,506 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Linaro Ltd.
+ */
+
+#include
+#include
+#include "rk3399.dtsi"
+
+/ {
+ vcc1v8_s0: vcc1v8-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_s0";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <_sys>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_drv>;
+ regulator-boot-on;
+ regulator-name = "vcc3v3_pcie";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_sys>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <_sys>;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = < 0 25000 0>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <140>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+};
+
+_l0 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l1 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l2 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l3 {
+ cpu-supply = <_cpu_l>;
+};
+
+_b0 {
+ cpu-supply = <_cpu_b>;
+};
+
+_b1 {
+ cpu-supply = <_cpu_b>;
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <40>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ vdd_cpu_b: regulator@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <150>;
+ regulator-ramp-delay = <1000>;
+
[U-Boot] [PATCH v2 1/4] arm: dts: rockchip: add some common pin-settings to rk3399
From: Randy Li
Those pins would be used by many boards.
Commit grabbed from Linux:
commit b41023282d07b61a53e2c9b9508912b1e7ce7b4f
Author: Randy Li
Date: Thu Jun 21 21:32:10 2018 +0800
arm64: dts: rockchip: add some common pin-settings to rk3399
Those pins would be used by many boards.
Signed-off-by: Randy Li
Signed-off-by: Heiko Stuebner
Acked-by: Philipp Tomsich
Signed-off-by: Randy Li
Signed-off-by: Heiko Stuebner
Signed-off-by: Ezequiel Garcia
---
Changes in v2: None
arch/arm/dts/rk3399.dtsi | 55 +++-
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 83c257b1228..8349451b03d 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -1602,19 +1602,49 @@
drive-strength = <12>;
};
+ pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+ bias-disable;
+ drive-strength = <13>;
+ };
+
+ pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+ bias-disable;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+ bias-disable;
+ drive-strength = <20>;
+ };
+
+ pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
+ pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+ bias-pull-up;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+ bias-pull-up;
+ drive-strength = <20>;
+ };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
- pcfg_pull_up_2ma: pcfg-pull-up-2ma {
- bias-pull-up;
- drive-strength = <2>;
+ pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+ bias-pull-down;
+ drive-strength = <8>;
};
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1622,9 +1652,22 @@
drive-strength = <12>;
};
- pcfg_pull_none_13ma: pcfg-pull-none-13ma {
- bias-disable;
- drive-strength = <13>;
+ pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+ bias-pull-down;
+ drive-strength = <18>;
+ };
+
+ pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+ bias-pull-down;
+ drive-strength = <20>;
+ };
+
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ pcfg_output_low: pcfg-output-low {
+ output-low;
};
clock {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] Add Rock960 and Ficus 96Board support
This patchset adds support for Rock960 and Ficus 96Boards from Vamrs. Since both boards share most of the configurations, a common Rock960 family support is added with common support and the actual boards are based on this. The previous version of the patchseries were adding Rock960 [1] and Ficus [2] board support individually, but this series fuses them together based on the common board support as per Linux kernel. [1] https://patchwork.ozlabs.org/cover/963239/ [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html This patchseries has been tested on Rock960 v1.2 board and expecting Ezequiel to do the testing for Ficus. PS: I have explicitly removed the previous Ack's for the Ficus board since there has been a heavy modification done on these patches. Thanks, Mani Manivannan Sadhasivam (4): arm: dts: rockchip: add some common pin-settings to rk3399 rockchip: rk3399: Add common Rock960 family from Vamrs rockchip: rk3399: Add Rock960 CE board support rockchip: rk3399: Add Ficus EE board support arch/arm/dts/Makefile |2 + arch/arm/dts/rk3399-ficus.dts | 78 + arch/arm/dts/rk3399-rock960.dts | 45 + arch/arm/dts/rk3399-rock960.dtsi | 506 ++ .../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 + arch/arm/dts/rk3399.dtsi | 55 +- arch/arm/mach-rockchip/rk3399/Kconfig | 26 + board/vamrs/rock960_rk3399/Kconfig| 15 + board/vamrs/rock960_rk3399/MAINTAINERS|6 + board/vamrs/rock960_rk3399/Makefile |6 + board/vamrs/rock960_rk3399/README | 151 ++ board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 + configs/ficus-rk3399_defconfig| 71 + configs/rock960-rk3399_defconfig | 67 + include/configs/rock960_rk3399.h | 15 + 15 files changed, 2623 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-ficus.dts create mode 100644 arch/arm/dts/rk3399-rock960.dts create mode 100644 arch/arm/dts/rk3399-rock960.dtsi create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi create mode 100644 board/vamrs/rock960_rk3399/Kconfig create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS create mode 100644 board/vamrs/rock960_rk3399/Makefile create mode 100644 board/vamrs/rock960_rk3399/README create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c create mode 100644 configs/ficus-rk3399_defconfig create mode 100644 configs/rock960-rk3399_defconfig create mode 100644 include/configs/rock960_rk3399.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/7] board: stmark2: updates for DM and DT
This patch enables fdt, and enables DM uart and spi. Signed-off-by: Angelo Dureghello --- configs/stmark2_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/stmark2_defconfig b/configs/stmark2_defconfig index 48e851d4a4..7b05b2e20b 100644 --- a/configs/stmark2_defconfig +++ b/configs/stmark2_defconfig @@ -2,6 +2,7 @@ CONFIG_M68K=y CONFIG_SYS_TEXT_BASE=0x47E0 CONFIG_TARGET_STMARK2=y CONFIG_SYS_EXTRA_OPTIONS="CF_SBF,SYS_SERIAL_BOOT,SYS_INPUT_CLKSRC=3000" +CONFIG_DEFAULT_FDT_FILE="stmark2" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y # CONFIG_CMDLINE_EDITING is not set @@ -19,12 +20,17 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi-flash.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi-flash.0:1m(u-boot),7m(kernel),-(rootfs)" +CONFIG_OF_EMBED=y +CONFIG_DEFAULT_DEVICE_TREE="stmark2" CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_NET is not set CONFIG_MTD_DEVICE=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_ISSI=y +CONFIG_DM_SERIAL=y CONFIG_SPI_FLASH_MTD=y CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_DM_SPI_FLASH=y CONFIG_CF_SPI=y CONFIG_REGEX=y -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] pci: Support parsing PCI controller DT subnodes
On 09/20/2018 03:47 AM, Bin Meng wrote: [...] >>> I suspect the best answer is to move the emulator so it is a direct >>> child of the bus. You would need to update sandbox_pci_get_emul() to >>> call device_find_first_child() on 'bus' instead of 'dev'. >> >> Sounds to me _way_ out of scope for this patchset. > > Dynamic binding is already supported on Sandbox. I guess Simon may > have missed the part. Well, where is an example of that ? Because I am not seeing one. >>> >>> I already pointed out in the previous email. In >>> arch/sandbox/dts/test.dts, the 2nd PCI controller has two swap_case >>> devices and the 3rd controller has one. >> >> By "second" you mean pci1: or pci2: ? Because pci1: is second , after >> pci0 . It'd really help if you were clearer in what you refer to. >> > > It's pci1. You can see there is no subnode under pci1 there yet if you > type 'pci 1' from the U-Boot shell you see two PCI devices. I'd really appreciate it if you could be more precise when referring to things. >>> In swap_case.c, U_BOOT_PCI_DEVICE() is there which is also a clear >>> sign that the driver supports dynamic binding. Of course, the driver >>> supports "compatible" too as you noticed. >> >> Are you talking about sandbox,dev-info DT property here ? > > This is the property Sandbox uses to make the dynamic binding work. > You can bypass this. Why would I want to bypass this ? > The key here is that swap_case driver supports > both "compatible" and dynamic binding, so you can write test cases to > cover this newly added ofnode scenario. That's great, and after spending even more time on this (probably days by now), I just keep finding more and more limitations of the virtual PCI subsystem which makes writing this testcase really hard. And none of that really helps fixing the real problem on my real hardware, which really stays broken. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2] test/py: ignore console read exceptions after test failure
From: Stephen Warren After a test has failed, test/py drains the U-Boot console log to ensure that any relevant output is captured. At this point, we don't care about detecting any additional errors, since the test is already known to have failed, and U-Boot will be restarted. To ensure that the test cleanup code is not interrupted, and can correctly terminate the log sections for the failed test, ignore any exception that occurs while reading the U-Boot console output during this limited period of time. Signed-off-by: Stephen Warren --- v2: * Combine the two except cases into one, since one was a superset of the other. * Fix TAB-vs-spaces issue in identation. --- test/py/u_boot_console_base.py | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py index a14bad6e8c50..326b2ac51fbf 100644 --- a/test/py/u_boot_console_base.py +++ b/test/py/u_boot_console_base.py @@ -304,7 +304,17 @@ class ConsoleBase(object): # Wait for something U-Boot will likely never send. This will # cause the console output to be read and logged. self.p.expect(['This should never match U-Boot output']) -except u_boot_spawn.Timeout: +except: +# We expect a timeout, since U-Boot won't print what we waited +# for. Squash it when it happens. +# +# Squash any other exception too. This function is only used to +# drain (and log) the U-Boot console output after a failed test. +# The U-Boot process will be restarted, or target board reset, once +# this function returns. So, we don't care about detecting any +# additional errors, so they're squashed so that the rest of the +# post-test-failure cleanup code can continue operation, and +# correctly terminate any log sections, etc. pass finally: self.p.timeout = orig_timeout -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: ignore console read exceptions after test failure
On 09/20/2018 01:43 PM, Heinrich Schuchardt wrote: On 09/20/2018 09:24 PM, Stephen Warren wrote: From: Stephen Warren After a test has failed, test/py drains the U-Boot console log to ensure that any relevant output is captured. At this point, we don't care about detecting any additional errors, since the test is already known to have failed, and U-Boot will be restarted. To ensure that the test cleanup code is not interrupted, and can correctly terminate the log sections for the failed test, ignore any exception that occurs while reading the U-Boot console output during this limited period of time. Signed-off-by: Stephen Warren --- test/py/u_boot_console_base.py | 11 +++ 1 file changed, 11 insertions(+) diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py index a14bad6e8c50..e337f3a84a96 100644 --- a/test/py/u_boot_console_base.py +++ b/test/py/u_boot_console_base.py @@ -305,6 +305,17 @@ class ConsoleBase(object): # cause the console output to be read and logged. self.p.expect(['This should never match U-Boot output']) except u_boot_spawn.Timeout: + # We expect a timeout, since U-Boot won't print what we waited + # for. Squash the expected timeout exception. +pass This block is redundant. You have a catch-all below with the same processing of the exception. So I would rather drop it. The comment could be integrated below. Timeout exceptions are currently caught in test/py/u_boot_console_base.py:307 Your patch could delete that 'except' as it becomes superfluous now. That was deliberate to emphasize the two cases. But since I realized that I need to re-post the patch to fix a TAB/space mixup, I guess I'll fix it up. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] (no subject)
This patch adds an initial fdt support to the m68k architecture. It has been tested on stmark2 board, with a devicetree and CONFIG_DM_SERIAL=y + CONFIG_DM_SPI=y. - test log - U-Boot 2018.09-00137-g1be43784f1 (Sep 20 2018 - 22:34:42 +0200) CPU: Freescale MCF54415 (Mask:a0 Version:2) CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz INP CLK 30 MHz VCO CLK 480 MHz SPI: ready DRAM: 128 MiB Loading Environment from SPI Flash... SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:uart@fc06 Out: uart@fc06 Err: uart@fc06 Hit any key to stop autoboot: 0 SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB device 0 offset 0x10, size 0x70 SF: 7340032 bytes @ 0x10 Read: OK ## Booting kernel from Legacy Image at 40001000 ... Image Name: mainline kernel Created: 2018-09-14 19:06:13 UTC Image Type: M68K Linux Kernel Image (uncompressed) Data Size:2184848 Bytes = 2.1 MiB Load Address: 40001000 Entry Point: 40001000 Verifying Checksum ... OK Loading Kernel Image ... OK ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: create root node
Currently we assign a lot of protocols to loaded images though
these protocols are not related to them. Instead they should be
installed on a separate handle. Via the device path it is the
parent to the devices like the network adapter.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c| 5 ++
include/efi_loader.h | 9
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_boottime.c| 18
lib/efi_loader/efi_device_path.c | 4 --
lib/efi_loader/efi_root_node.c | 79
6 files changed, 94 insertions(+), 22 deletions(-)
create mode 100644 lib/efi_loader/efi_root_node.c
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c8812b0f5e..5fc054c9da 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -49,6 +49,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
+ /* Initialize root node */
+ ret = efi_root_node_register();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
/* Initialize EFI driver uclass */
ret = efi_driver_init();
if (ret != EFI_SUCCESS)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c5b73b7238..5d522f133e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -20,6 +20,11 @@
/* Maximum number of configuration tables */
#define EFI_MAX_CONFIGURATION_TABLES 16
+/* GUID used by the root node */
+#define U_BOOT_GUID \
+ EFI_GUID(0xe61d73b9, 0xa384, 0x4acc, \
+0xae, 0xab, 0x82, 0xe8, 0x28, 0xf3, 0x62, 0x8b)
+
int __efi_entry_check(void);
int __efi_exit_check(void);
const char *__efi_nesting(void);
@@ -104,6 +109,8 @@ extern const struct efi_unicode_collation_protocol
uint16_t *efi_dp_str(struct efi_device_path *dp);
+/* GUID of the U-Boot root node */
+extern const efi_guid_t efi_u_boot_guid;
/* GUID of the EFI_BLOCK_IO_PROTOCOL */
extern const efi_guid_t efi_block_io_guid;
extern const efi_guid_t efi_global_variable_guid;
@@ -210,6 +217,8 @@ extern struct list_head efi_obj_list;
/* List of all events */
extern struct list_head efi_events;
+/* Called by bootefi to initialize root node */
+efi_status_t efi_root_node_register(void);
/* Called by bootefi to initialize runtime */
efi_status_t efi_initialize_system_table(void);
/* Called by bootefi to make console interface available */
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 7eebbc5b4e..6703435947 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -26,6 +26,7 @@ obj-y += efi_device_path_utilities.o
obj-y += efi_file.o
obj-y += efi_image_loader.o
obj-y += efi_memory.o
+obj-y += efi_root_node.o
obj-y += efi_runtime.o
obj-y += efi_unicode_collation.o
obj-y += efi_variable.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 5d93db8e0c..b4de9961b8 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1514,24 +1514,6 @@ efi_status_t efi_setup_loaded_image(
if (ret != EFI_SUCCESS)
goto failure;
- ret = efi_add_protocol(obj->handle,
- _guid_device_path_to_text_protocol,
- (void *)_device_path_to_text);
- if (ret != EFI_SUCCESS)
- goto failure;
-
- ret = efi_add_protocol(obj->handle,
- _guid_device_path_utilities_protocol,
- (void *)_device_path_utilities);
- if (ret != EFI_SUCCESS)
- goto failure;
-
- ret = efi_add_protocol(obj->handle,
- _guid_unicode_collation_protocol,
- (void *)_unicode_collation_protocol);
- if (ret != EFI_SUCCESS)
- goto failure;
-
return ret;
failure:
printf("ERROR: Failure to install protocols for loaded image\n");
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index b770db84fd..46a24f7882 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -22,10 +22,6 @@ static const struct efi_device_path END = {
.length = sizeof(END),
};
-#define U_BOOT_GUID \
- EFI_GUID(0xe61d73b9, 0xa384, 0x4acc, \
-0xae, 0xab, 0x82, 0xe8, 0x28, 0xf3, 0x62, 0x8b)
-
/* template ROOT node: */
static const struct efi_device_path_vendor ROOT = {
.dp = {
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
new file mode 100644
index 00..b056ba3ee8
--- /dev/null
+++ b/lib/efi_loader/efi_root_node.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Root node for system services
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt
+ */
+
+#include
+#include
+#include
+
+const efi_guid_t efi_u_boot_guid = U_BOOT_GUID;
+
+struct efi_root_dp {
+ struct efi_device_path_vendor vendor;
+ struct efi_device_path end;
+} __packed;
+
+/**
+ *
Re: [U-Boot] [PATCH] test/py: ignore console read exceptions after test failure
On 09/20/2018 09:24 PM, Stephen Warren wrote: > From: Stephen Warren > > After a test has failed, test/py drains the U-Boot console log to ensure > that any relevant output is captured. At this point, we don't care about > detecting any additional errors, since the test is already known to have > failed, and U-Boot will be restarted. To ensure that the test cleanup code > is not interrupted, and can correctly terminate the log sections for the > failed test, ignore any exception that occurs while reading the U-Boot > console output during this limited period of time. > > Signed-off-by: Stephen Warren > --- > test/py/u_boot_console_base.py | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py > index a14bad6e8c50..e337f3a84a96 100644 > --- a/test/py/u_boot_console_base.py > +++ b/test/py/u_boot_console_base.py > @@ -305,6 +305,17 @@ class ConsoleBase(object): > # cause the console output to be read and logged. > self.p.expect(['This should never match U-Boot output']) > except u_boot_spawn.Timeout: > + # We expect a timeout, since U-Boot won't print what we waited > + # for. Squash the expected timeout exception. > +pass This block is redundant. You have a catch-all below with the same processing of the exception. So I would rather drop it. The comment could be integrated below. Timeout exceptions are currently caught in test/py/u_boot_console_base.py:307 Your patch could delete that 'except' as it becomes superfluous now. Otherwise I am fine with this patch. Best regards Heinrich > +except: > + # Squash any other exception too. This function is only used to > + # drain (and log) the U-Boot console output after a failed test. > + # The U-Boot process will be restarted, or target board reset, once > + # this function returns. So, we don't care about detecting any > + # additional errors, so they're squashed so that the rest of the > + # post-test-failure cleanup code can continue operation, and > + # correctly terminate any log sections, etc. > pass > finally: > self.p.timeout = orig_timeout > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test/py: ignore console read exceptions after test failure
From: Stephen Warren After a test has failed, test/py drains the U-Boot console log to ensure that any relevant output is captured. At this point, we don't care about detecting any additional errors, since the test is already known to have failed, and U-Boot will be restarted. To ensure that the test cleanup code is not interrupted, and can correctly terminate the log sections for the failed test, ignore any exception that occurs while reading the U-Boot console output during this limited period of time. Signed-off-by: Stephen Warren --- test/py/u_boot_console_base.py | 11 +++ 1 file changed, 11 insertions(+) diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py index a14bad6e8c50..e337f3a84a96 100644 --- a/test/py/u_boot_console_base.py +++ b/test/py/u_boot_console_base.py @@ -305,6 +305,17 @@ class ConsoleBase(object): # cause the console output to be read and logged. self.p.expect(['This should never match U-Boot output']) except u_boot_spawn.Timeout: + # We expect a timeout, since U-Boot won't print what we waited + # for. Squash the expected timeout exception. +pass +except: + # Squash any other exception too. This function is only used to + # drain (and log) the U-Boot console output after a failed test. + # The U-Boot process will be restarted, or target board reset, once + # this function returns. So, we don't care about detecting any + # additional errors, so they're squashed so that the rest of the + # post-test-failure cleanup code can continue operation, and + # correctly terminate any log sections, etc. pass finally: self.p.timeout = orig_timeout -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, V3, 2/3] ARM: tegra: reserve unmapped RAM so EFI doesn't use it
On 09/01/2018 03:58 AM, Alexander Graf wrote:
From: Stephen Warren
Tegra U-Boot ensures that board_get_usable_ram_top() never returns a value
over 4GB, since some peripherals can't access such addresses. However, on
systems with more than 2GB of RAM, RAM bank 1 does describe this extra
RAM, so that Linux (or whatever OS) can use it, subject to DMA
limitations. Since board_get_usable_ram_top() points at the top of RAM
bank 0, the memory locations describes by RAM bank 1 are not mapped by
U-Boot's MMU configuration, and so cannot be used for anything.
For some completely inexplicable reason, U-Boot's EFI support ignores the
value returned by board_get_usable_ram_top(), and EFI memory allocation
routines will return values above U-Boot's RAM top. This causes U-Boot to
crash when it accesses that RAM, since it isn't mapped by the MMU. One
use-case where this happens is TFTP download of a file on Jetson TX1
(p2371-2180).
This change explicitly tells the EFI code that this extra RAM should not
be used, thus avoiding the crash.
A previous attempt to make EFI honor board_get_usable_ram_top() was
rejected. So, this patch will need to be replicated for any board that
implements board_get_usable_ram_top().
Fixes: aa909462d018 ("efi_loader: efi_allocate_pages is too restrictive")
Signed-off-by: Stephen Warren
Thanks, applied to efi-next
They don't seem to have shown up in u-boot/master though...
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test/py: catch errors occurring when reading the console
On 09/20/2018 12:19 PM, Heinrich Schuchardt wrote: Spawn.exept has a try block without 'except'. When the py test is running it is connected via pipes to the U-Boot process. If the U-Boot process ends prematurely, e.g. due to a segmentation fault, the pipes are broken. Trying to read from a broken pipe results in an OSError. Catch the exception and treat the broken pipe like any other end of output. By returning None expect() indicates that the output does not match. Signed-off-by: Heinrich Schuchardt Reviewed-by: Simon Glass --- I suggest that Alex takes the patch because we need it when working on the efi-next branch. v3 add more comments Adding comments doesn't solve the fundamental problem with this patch. I'll send an alternative patch in a minute. That patch will hide exceptions only during a very specific portion of time, rather than just ignoring all of them. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test/py: catch errors occurring when reading the console
On 09/19/2018 10:45 AM, Heinrich Schuchardt wrote: On 09/19/2018 05:24 PM, Stephen Warren wrote: On 09/18/2018 06:43 PM, Heinrich Schuchardt wrote: On 09/18/2018 07:23 PM, Stephen Warren wrote: On 09/18/2018 11:21 AM, Heinrich Schuchardt wrote: Spawn.exept has a try block without 'except'. If no output is available an OSError may arise. Catch this exception and continue testing. Signed-off-by: Heinrich Schuchardt Reviewed-by: Simon Glass --- I suggest that Alex takes the patch because we need it when working on the efi-next branch. v2 replace TAB by spaces fix typo in subject I'll point out that I still object to this. On 09/18/2018 07:06 PM, Stephen Warren wrote: This doesn't make sense at all. It catches all errors and ignores them. It'll turn any error condition into a timeout (presumably, the expected data being waited for will never appear) rather than dealing with it immediately (due to the thrown exception). Why is this needed? When the py test is running it is connected via pipes to the U-Boot process. If the U-Boot process ends due to a segmentation fault the pipes are broken. Trying to read from a broken pipe results in an OSError. Before this patch this leads to an uncaught error in the Python script. The output that has occured up to this point is lost and not displayed. All further tests for the configuration are not run. Ah. I think that's because Python is throwing an error rather than an exception. I would have assumed that py.test caught errors as well as exceptions, but perhaps not. I think what we should do here is catch errors and translate them into a new thrown exception. That way, everything outside the function would treat this as just another type of exception, and hence still capture/flush the output, mark the test immediately failed rather than having to wait for a timeout, etc. Hello Stephen, the above confuses me. OSError is an exception. What do you mean by error in this context? The method Spawn.expect() is used to compare actual output to expected output. If a pipe is closed, this is obviously the end of the output. Why should we treat it differently to any other end of output? The except OSError statement is right at the end of the method. Why would you expect the method to wait for a timeout? If the OSError excepton is caught, the method returns None and the test is known to have failed. I was describing the fact that not all Python exception types are a subclass of Exception so "except Exception" won't catch some of them. However, that doesn't appear to be relevant here. I'll send an alternative patch in a minute. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] test/py: catch errors occurring when reading the console
Spawn.exept has a try block without 'except'.
When the py test is running it is connected via pipes to the U-Boot
process. If the U-Boot process ends prematurely, e.g. due to a
segmentation fault, the pipes are broken. Trying to read from a broken
pipe results in an OSError. Catch the exception and treat the broken pipe
like any other end of output. By returning None expect() indicates that
the output does not match.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Simon Glass
---
I suggest that Alex takes the patch because we need it when working on
the efi-next branch.
v3
add more comments
v2
replace TAB by spaces
fix type in subject
---
test/py/u_boot_spawn.py | 8
1 file changed, 8 insertions(+)
diff --git a/test/py/u_boot_spawn.py b/test/py/u_boot_spawn.py
index b011a3e3da..adc1d00287 100644
--- a/test/py/u_boot_spawn.py
+++ b/test/py/u_boot_spawn.py
@@ -181,6 +181,14 @@ class Spawn(object):
# unlimited substitutions, but in practice the version of
# Python in Ubuntu 14.04 appears to default to count=2!
self.buf = self.re_vt100.sub('', self.buf, count=100)
+except OSError, EOFError:
+# When the py test is running it is connected via pipes to the
+# U-Boot process. If the U-Boot process ends prematurely, e.g. due
+# to a segmentation fault, the pipes are broken. Trying to read
+# from a broken pipe results in an OSError. Treat the broken pipe
+# like any other end of output. By returning None expect()
+# indicates that the output does not match.
+pass
finally:
if self.logfile_read:
self.logfile_read.flush()
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: remove redundant statement
ascii2unicode() always ends the u16 string with '\0'.
Remove redundant assignment.
Add description for efi_str_to_u16() and ascii2unicode().
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 10 +-
lib/efi_loader/efi_device_path_to_text.c | 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index e5bc7d043e..736879345b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -408,7 +408,15 @@ efi_status_t efi_dp_split_file_path(struct efi_device_path
*full_path,
(((_dp)->type == DEVICE_PATH_TYPE_##_type) && \
((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))
-/* Convert strings from normal C strings to uEFI strings */
+/**
+ * ascii2unicode() - convert ASCII string to UTF-16 string
+ *
+ * A zero terminated ASCII string is converted to a zero terminated UTF-16
+ * string. The output buffer must be preassigned.
+ *
+ * @unicode: preassigned output buffer for UTF-16 string
+ * @ascii: ASCII string to be converted
+ */
static inline void ascii2unicode(u16 *unicode, const char *ascii)
{
while (*ascii)
diff --git a/lib/efi_loader/efi_device_path_to_text.c
b/lib/efi_loader/efi_device_path_to_text.c
index ca8037def2..0082236359 100644
--- a/lib/efi_loader/efi_device_path_to_text.c
+++ b/lib/efi_loader/efi_device_path_to_text.c
@@ -17,6 +17,15 @@
const efi_guid_t efi_guid_device_path_to_text_protocol =
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID;
+/**
+ * efi_str_to_u16() - convert ASCII string to UTF-16
+ *
+ * A u16 buffer is allocated from pool. The ASCII string is copied to the u16
+ * buffer.
+ *
+ * @str: ASCII string
+ * Return: UTF-16 string. NULL if out of memory.
+ */
static u16 *efi_str_to_u16(char *str)
{
efi_uintn_t len;
@@ -29,7 +38,6 @@ static u16 *efi_str_to_u16(char *str)
if (ret != EFI_SUCCESS)
return NULL;
ascii2unicode(out, str);
- out[len - 1] = 0;
return out;
}
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] aspeed: Add SPI support to the ast2500 Eval Board
On 09/20/2018 04:53 PM, Jagan Teki wrote: > On Mon, Sep 10, 2018 at 7:46 PM, Cédric Le Goater wrote: >> Signed-off-by: Cédric Le Goater >> --- >> arch/arm/dts/ast2500-evb.dts | 17 >> arch/arm/dts/ast2500-u-boot.dtsi | 12 ++ >> arch/arm/dts/ast2500.dtsi| 71 >> configs/evb-ast2500_defconfig| 10 + > > Except -u-boot.dtsi is rest of DTS files from Linux? If yes then > attach the sync commit details. Yes they are from Linux but I would not say the DTS files are in sync. They don't even have the same names, the layout is different. I will send v2 with a large resync. This is required anyhow for the Aspeed ftgmac100 ethernet driver I sent in another series. > on that note. > > Reviewed-by: Jagan Teki > Thanks, C. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [Uboot-stm32] [PATCH v1 2/5] cmd: pinmux: Add pinmux command
Hi Michal On 09/20/2018 03:53 PM, Michal Simek wrote: > Hi, > > On 20.9.2018 15:37, Patrice Chotard wrote: >> pinmux command allows to : >> - list all pin-controllers available on platforms >> - select a pin-controller >> - display the muxing of all pins of the current pin-controller >>or all pin-controllers depending of given options >> >> Signed-off-by: Patrice Chotard >> --- >> >> cmd/Kconfig | 8 + >> cmd/Makefile | 3 ++ >> cmd/pinmux.c | 115 >> +++ >> 3 files changed, 126 insertions(+) >> create mode 100644 cmd/pinmux.c >> >> diff --git a/cmd/Kconfig b/cmd/Kconfig >> index 13d4c991bf8b..2c687ceecf49 100644 >> --- a/cmd/Kconfig >> +++ b/cmd/Kconfig >> @@ -937,6 +937,14 @@ config CMD_PCMCIA >>about 1990. These devices are typically removable memory or network >>cards using a standard 68-pin connector. >> >> +config CMD_PINMUX >> +bool "pinmux - show pins muxing" >> +depends on PINCTRL >> +help >> + Parse all available pin-controllers and show pins muxing. This >> + is useful for debug purpoer to check the pin muxing and to know if >> + a pin is configured as a GPIO or as an alternate function. >> + >> config CMD_READ >> bool "read - Read binary data from a partition" >> help >> diff --git a/cmd/Makefile b/cmd/Makefile >> index 3487c80455c4..9e899c44bdef 100644 >> --- a/cmd/Makefile >> +++ b/cmd/Makefile >> @@ -101,6 +101,9 @@ ifdef CONFIG_PCI >> obj-$(CONFIG_CMD_PCI) += pci.o >> endif >> obj-y += pcmcia.o >> +ifdef CONFIG_PINCTRL >> +obj-$(CONFIG_CMD_PINMUX) += pinmux.o >> +endif > > you have dependency already setup in Kconfig that's why no reason to > have it here again. Yes, i will remove it > >> obj-$(CONFIG_CMD_PXE) += pxe.o >> obj-$(CONFIG_CMD_WOL) += wol.o >> obj-$(CONFIG_CMD_QFW) += qfw.o >> diff --git a/cmd/pinmux.c b/cmd/pinmux.c >> new file mode 100644 >> index ..1442d6ef63d2 >> --- /dev/null >> +++ b/cmd/pinmux.c >> @@ -0,0 +1,115 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#ifdef CONFIG_PINCTRL > > and here again. ok Thanks Patrice > > The rest looks quite standard from quick look. > > Thanks, > Michal > ___ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/12] SPI-NAND support
Hi Miquel, On 20.09.2018 16:59, Miquel Raynal wrote: Hi Jagan, Frieder, Jagan Teki wrote on Thu, 20 Sep 2018 20:16:06 +0530: On Thu, Sep 20, 2018 at 7:36 PM, Frieder Schrempf wrote: Hi Jagan, I just wanted to ask about the timeline for the SPI-NAND patches. I remember that Tom wanted to have them in 2018.11. Is this going to happen or is there anything preventing this? Travis[1] for combination of earlier series + this. Will send PR soon I get the results. Miquel, Let me know if anything miss here? [1] https://travis-ci.org/openedev/u-boot-amarula/builds/431062285 You can definitely take the earlier series, they are fine and work on their own. About this one, the four first patches are fine and won't be changed, please keep them: lib: strto: parse all lowercase metric prefixes in ustrtoul[l] lib: strto: fix metric suffix parsing in strtoul[l] cmd: mtdparts: accept spi-nand devices cmd: mtdparts: remove mandatory 'mtdparts=' prefix For the rest, as pointed by Boris, it would break UBI for certain users so I want to make a last version (mostly code moves) next week to fit it. I will resend a v9 only for patches: mtd: uclass: add probe function mtd: uclass: add a generic 'mtdparts' parser mtd: uclass: search for an equivalent MTD name with the mtdids mtd: mtdpart: implement proper partition handling cmd: mtd: add 'mtd' command cmd: mtdparts: try to probe the MTD devices as a fallback cmd: ubi: clean the partition handling cmd: mtdparts: describe as legacy 2018.11 is definitely the target. Ok, good to know and thanks a lot for the effort you are putting into this. Thanks, Frieder Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert CONFIG_DISABLE_CONSOLE to Kconfig
ping Am Mo., 10. Sep. 2018 um 12:43 Uhr schrieb Christian Gmeiner : > > This converts the following to Kconfig: >CONFIG_DISABLE_CONSOLE > > Signed-off-by: Christian Gmeiner > --- > common/Kconfig | 5 + > scripts/config_whitelist.txt | 1 - > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/common/Kconfig b/common/Kconfig > index 3030da4fc9..207cb3ae0b 100644 > --- a/common/Kconfig > +++ b/common/Kconfig > @@ -259,6 +259,11 @@ config CONSOLE_RECORD_IN_SIZE > The buffer is allocated immediately after the malloc() region is > ready. > > +config DISABLE_CONSOLE > + bool "Add functionality to disable console completely" > + help > + Disable console (in & out). > + > config IDENT_STRING > string "Board specific string to be added to uboot version string" > help > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > index fc37099cbe..27fba1e963 100644 > --- a/scripts/config_whitelist.txt > +++ b/scripts/config_whitelist.txt > @@ -366,7 +366,6 @@ CONFIG_DHCP_MIN_EXT_LEN > CONFIG_DIALOG_POWER > CONFIG_DIMM_SLOTS_PER_CTLR > CONFIG_DIRECT_NOR_BOOT > -CONFIG_DISABLE_CONSOLE > CONFIG_DISCONTIGMEM > CONFIG_DISCOVER_PHY > CONFIG_DISPLAY_AER_ > -- > 2.17.1 > -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/spi: fsl_qspi: Remove non-DM stuff
On Fri, Sep 7, 2018 at 9:49 AM, Ashish Kumar wrote: > Convert fsl_qspi.c to complete DM mode. > > Signed-off-by: Ashish Kumar > Tested-by: Rajat Srivastava > Tested-by: Ye Li > --- > > Tested on LS1088ARDB(arm64). > Tested on LS1021ATWR(arm32) by Rajat > Tested on i.mx6 and i.mx7 by Ye Li Reviewed-by: Jagan Teki Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/12] SPI-NAND support
Hi Jagan, Frieder, Jagan Teki wrote on Thu, 20 Sep 2018 20:16:06 +0530: > On Thu, Sep 20, 2018 at 7:36 PM, Frieder Schrempf > wrote: > > Hi Jagan, > > > > I just wanted to ask about the timeline for the SPI-NAND patches. > > I remember that Tom wanted to have them in 2018.11. Is this going to happen > > or is there anything preventing this? > > Travis[1] for combination of earlier series + this. Will send PR soon > I get the results. > > Miquel, Let me know if anything miss here? > > [1] https://travis-ci.org/openedev/u-boot-amarula/builds/431062285 You can definitely take the earlier series, they are fine and work on their own. About this one, the four first patches are fine and won't be changed, please keep them: lib: strto: parse all lowercase metric prefixes in ustrtoul[l] lib: strto: fix metric suffix parsing in strtoul[l] cmd: mtdparts: accept spi-nand devices cmd: mtdparts: remove mandatory 'mtdparts=' prefix For the rest, as pointed by Boris, it would break UBI for certain users so I want to make a last version (mostly code moves) next week to fit it. I will resend a v9 only for patches: mtd: uclass: add probe function mtd: uclass: add a generic 'mtdparts' parser mtd: uclass: search for an equivalent MTD name with the mtdids mtd: mtdpart: implement proper partition handling cmd: mtd: add 'mtd' command cmd: mtdparts: try to probe the MTD devices as a fallback cmd: ubi: clean the partition handling cmd: mtdparts: describe as legacy 2018.11 is definitely the target. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] aspeed: Add SPI support to the ast2500 Eval Board
On Mon, Sep 10, 2018 at 7:46 PM, Cédric Le Goater wrote: > Signed-off-by: Cédric Le Goater > --- > arch/arm/dts/ast2500-evb.dts | 17 > arch/arm/dts/ast2500-u-boot.dtsi | 12 ++ > arch/arm/dts/ast2500.dtsi| 71 > configs/evb-ast2500_defconfig| 10 + Except -u-boot.dtsi is rest of DTS files from Linux? If yes then attach the sync commit details. on that note. Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: designware_spi: Add reset ctrl to driver
On Fri, Sep 7, 2018 at 11:55 AM, Ley Foon Tan wrote: > Add code to reset all reset signals as in SPI DT node. A reset property > is an optional feature, so only print out a warning and do not fail if a > reset property is not present. > > If a reset property is discovered, then use it to deassert, thus > bringing the IP out of reset. > > Release reset when _remove(). > > Signed-off-by: Ley Foon Tan > Acked-by: Marek Vasut > Reviewed-by: Jagan Teki Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fs: cbfs: remove wrong header validation
Coreboot does not contain such a check:
https://github.com/coreboot/coreboot/blob/eeb4e20b2f6d786c92fe3efb30817e90389a2bfe/src/commonlib/cbfs.c#L64
Before this change cbfsinit failed with 'Bad CBFS file'. After this change all
cbfs commands
are working as expected.
Signed-off-by: Christian Gmeiner
---
fs/cbfs/cbfs.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/cbfs/cbfs.c b/fs/cbfs/cbfs.c
index 0dce639b49..2a581f0c18 100644
--- a/fs/cbfs/cbfs.c
+++ b/fs/cbfs/cbfs.c
@@ -96,11 +96,7 @@ static int file_cbfs_next_file(u8 *start, u32 size, u32
align,
}
swap_file_header(, fileHeader);
- if (header.offset < sizeof(struct cbfs_fileheader) ||
- header.offset > header.len) {
- file_cbfs_result = CBFS_BAD_FILE;
- return -1;
- }
+
newNode->next = NULL;
newNode->type = header.type;
newNode->data = start + header.offset;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/12] SPI-NAND support
On Thu, Sep 20, 2018 at 7:36 PM, Frieder Schrempf wrote: > Hi Jagan, > > I just wanted to ask about the timeline for the SPI-NAND patches. > I remember that Tom wanted to have them in 2018.11. Is this going to happen > or is there anything preventing this? Travis[1] for combination of earlier series + this. Will send PR soon I get the results. Miquel, Let me know if anything miss here? [1] https://travis-ci.org/openedev/u-boot-amarula/builds/431062285 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: socfpga: fix sfp_verify_header
On 09/20/2018 10:12 AM, Atsushi Nemoto wrote:
> Fix sfp_verify_header to return correct version number.
> This fixes "Not a sane SOCFPGA preloader" error message with v1 header.
>
> Signed-off-by: Atsushi Nemoto
> ---
> tools/socfpgaimage.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c
> index 390c9bb..fea22b4 100644
> --- a/tools/socfpgaimage.c
> +++ b/tools/socfpgaimage.c
> @@ -174,6 +174,7 @@ static int sfp_verify_header(const uint8_t *buf, uint8_t
> *ver)
> if (le32_to_cpu(header_v0.validation) != VALIDATION_WORD)
> return -1;
>
> + *ver = header_v0.version;
> if (header_v0.version == 0) {
> hdr_csum = le16_to_cpu(header_v0.checksum);
> sfp_csum = sfp_hdr_checksum((uint8_t *)_v0, 0);
>
Hello Nemoto-san,
This *ver assignment should be just before return img_len, so we don't
set the *ver until we did all the checks. Otherwise it's good. Can you
send a V2 ?
Thanks!
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/12] SPI-NAND support
Hi Jagan,
I just wanted to ask about the timeline for the SPI-NAND patches.
I remember that Tom wanted to have them in 2018.11. Is this going to
happen or is there anything preventing this?
Thanks,
Frieder
On 06.09.2018 09:15, Miquel Raynal wrote:
Hello,
I failed the numbering, this is actually the v8. The below changelog is
still right though. I don't plan to resend unless I am explicitly told
to do so.
Sorry for the mistake.
Thanks,
Miquèl
Miquel Raynal wrote on Thu, 6 Sep 2018
09:08:42 +0200:
During the last months, Boris Brezillon shared his work to support
serial flashes within Linux. First, he delivered (and merged) a new
layer called spi-mem. He also initiated in Linux MTD subsystem the move
of all 'raw' NAND related code to a raw/ subdirectory, adding at the
same time a NAND core that would be shared with all NAND devices. Then,
he contributed a generic SPI-NAND driver, making use of this NAND core,
as well as some vendor code to drive a few chips.
On top of this work, I made some cleanups in the MTD layer and added an
'mtd' U-Boot command to handle all sort of MTD devices. This should
become the default command instead of having one per flash flavor
('sf', 'nand', 'spi-nand' ?).
The series has been tested on an Ocelot board PCB123 (VSC7514),
featuring a Macronix SPI NAND chip.
TL;DR: the series contains (stripped version since 23 patches have
already been taken):
- Various fixes
- Support for spi-nand devices in mtdparts.
- Generics mtdparts/mtdids parsers.
- A new 'mtd' command.
- A note to set mtdparts command legacy.
To test your SPI-NAND device with U-Boot, you can test someting like:
setenv mtdparts 'spi-nand0:1m(foo),-(bar)'
setenv mtdids 'spi-nand0=spi0.0' # spi0.0 is Linux MTD name for this device
ubi part bar # create a static UBI volume in the bar partition
mtd list # show the current MTD devices/partitions
Thanks,
Miquèl
Changes since v7:
-
* Added Stefan R-b tags.
* Used tolower() as suggested by Stefan in lib/strto.c.
* Added a mention saying that we continue to abuse the kB suffix in
lib/strto.c by not making a difference between kB and kiB which both
mean "* 1024" for us. This has been added in the commit log.
* Fixed various bugs in the mtd command and in the parsers, they should
be pretty stable now (tested with two MTD devices probed and several
different partition configurations).
* mtdids is not deprecated at all as opposed at what I wrote in
v6. U-Boot still uses its own MTD names (being like nor0
or spi-nand1) and mtdids is still needed to do the glue.
* Removed a useless patch removing a Kconfig entry I added myself since
during a rebase someone else also added this symbol.
Changes since v6:
-
* Squashed Boris' fixes about build issues in Travis.
* Merged Stefan Roese's contributions.
* cmd: mtdparts:
* added fallthrough comments in switch blocks deriving sizes.
* balanced debug messages to compare freed and allocated partitions.
* move mtdparts_init() declaration in mtd/partitions.h to be used in
mtd command as well.
* introduced a "compatibility" function to return what the MTD device
name could be thanks to the mtdids environment variable (which is
useless with the new partitioning logic).
* mtd: mtdpart:
* reworked the way partitions are created/handled.
* cmd: mtd:
* implement a partitioning logic that takes the best out of the MTD
layer without re-inventing the wheel. Partitions are all freed
correctly when the value of mtdparts changes.
* balance get_mtd_device() by put_mtd_device() calls.
* prevent memory leak by reorganizing the code a bit in do_mtd.
* do not reconstruct partition list when a partition is already in use
(complain about that instead).
* add support for the legacy mtdids (not needed anymore if mtdparts
directly uses the MTD device names as in Linux.
* cmd: ubi:
* clean and simplify the partition handling a bit to make use the best
use of the MTD layer as well and keep the code simple.
Changes since v5:
-
* Included Boris fixup about the build issues.
* Added Rb/Ab tags from Jagan on patchs 20/21.
Changes since v4:
-
* Added Jagan's Acked-by tags to every patch related to the
SPI-mem/SPI-NAND addition.
* Rebased on top of master.
Changes since v3:
-
* Fixed the debug messages in spi-mem to print either Rx or Tx data.
* Fixed a Kconfig error that prevented to build mtdparts with plain
defconfig.
* Fixed a compilation error due to the above error that prevented one
file to be compiled.
* Adapted the mtd command to probe MTD partitions also.
* Declared mtd_probe_devices() in a header so mtdparts or UBI could
use it too (to probe all devices and MTD partitions in a clean way).
* As I worked on mtdparts, I found annoying and completely useless the
fact that we need to prefix the environment variable with
"mtdparts=".
Re: [U-Boot] [PATCH v1 2/5] cmd: pinmux: Add pinmux command
Hi, On 20.9.2018 15:37, Patrice Chotard wrote: > pinmux command allows to : > - list all pin-controllers available on platforms > - select a pin-controller > - display the muxing of all pins of the current pin-controller >or all pin-controllers depending of given options > > Signed-off-by: Patrice Chotard > --- > > cmd/Kconfig | 8 + > cmd/Makefile | 3 ++ > cmd/pinmux.c | 115 > +++ > 3 files changed, 126 insertions(+) > create mode 100644 cmd/pinmux.c > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 13d4c991bf8b..2c687ceecf49 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -937,6 +937,14 @@ config CMD_PCMCIA > about 1990. These devices are typically removable memory or network > cards using a standard 68-pin connector. > > +config CMD_PINMUX > + bool "pinmux - show pins muxing" > + depends on PINCTRL > + help > + Parse all available pin-controllers and show pins muxing. This > + is useful for debug purpoer to check the pin muxing and to know if > + a pin is configured as a GPIO or as an alternate function. > + > config CMD_READ > bool "read - Read binary data from a partition" > help > diff --git a/cmd/Makefile b/cmd/Makefile > index 3487c80455c4..9e899c44bdef 100644 > --- a/cmd/Makefile > +++ b/cmd/Makefile > @@ -101,6 +101,9 @@ ifdef CONFIG_PCI > obj-$(CONFIG_CMD_PCI) += pci.o > endif > obj-y += pcmcia.o > +ifdef CONFIG_PINCTRL > +obj-$(CONFIG_CMD_PINMUX) += pinmux.o > +endif you have dependency already setup in Kconfig that's why no reason to have it here again. > obj-$(CONFIG_CMD_PXE) += pxe.o > obj-$(CONFIG_CMD_WOL) += wol.o > obj-$(CONFIG_CMD_QFW) += qfw.o > diff --git a/cmd/pinmux.c b/cmd/pinmux.c > new file mode 100644 > index ..1442d6ef63d2 > --- /dev/null > +++ b/cmd/pinmux.c > @@ -0,0 +1,115 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#ifdef CONFIG_PINCTRL and here again. The rest looks quite standard from quick look. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/5] cmd: pinmux: Add pinmux command
pinmux command allows to :
- list all pin-controllers available on platforms
- select a pin-controller
- display the muxing of all pins of the current pin-controller
or all pin-controllers depending of given options
Signed-off-by: Patrice Chotard
---
cmd/Kconfig | 8 +
cmd/Makefile | 3 ++
cmd/pinmux.c | 115 +++
3 files changed, 126 insertions(+)
create mode 100644 cmd/pinmux.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 13d4c991bf8b..2c687ceecf49 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -937,6 +937,14 @@ config CMD_PCMCIA
about 1990. These devices are typically removable memory or network
cards using a standard 68-pin connector.
+config CMD_PINMUX
+ bool "pinmux - show pins muxing"
+ depends on PINCTRL
+ help
+ Parse all available pin-controllers and show pins muxing. This
+ is useful for debug purpoer to check the pin muxing and to know if
+ a pin is configured as a GPIO or as an alternate function.
+
config CMD_READ
bool "read - Read binary data from a partition"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 3487c80455c4..9e899c44bdef 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -101,6 +101,9 @@ ifdef CONFIG_PCI
obj-$(CONFIG_CMD_PCI) += pci.o
endif
obj-y += pcmcia.o
+ifdef CONFIG_PINCTRL
+obj-$(CONFIG_CMD_PINMUX) += pinmux.o
+endif
obj-$(CONFIG_CMD_PXE) += pxe.o
obj-$(CONFIG_CMD_WOL) += wol.o
obj-$(CONFIG_CMD_QFW) += qfw.o
diff --git a/cmd/pinmux.c b/cmd/pinmux.c
new file mode 100644
index ..1442d6ef63d2
--- /dev/null
+++ b/cmd/pinmux.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_PINCTRL
+
+#define LIMIT_DEVNAME 30
+#define LIMIT_OFNAME 32
+
+static struct udevice *currdev;
+
+static int do_dev(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ const char *name;
+ int ret;
+
+ switch (argc) {
+ case 2:
+ name = argv[1];
+ ret = uclass_get_device_by_name(UCLASS_PINCTRL, name, );
+ if (ret) {
+ printf("Can't get the pin-controller: %s!\n", name);
+ return CMD_RET_FAILURE;
+ }
+ case 1:
+ if (!currdev) {
+ printf("Pin-controller device is not set!\n\n");
+ return CMD_RET_USAGE;
+ }
+
+ printf("dev: %s\n", currdev->name);
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_status(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct udevice *dev;
+ int ret;
+
+ if (currdev && (argc < 2 || strcmp(argv[1], "-a")))
+ return pinctrl_pinmux_show(currdev);
+
+ for (uclass_first_device(UCLASS_PINCTRL, ); dev;
+uclass_next_device()) {
+ /* insert a separator between each pin-controller display */
+ printf("--\n");
+ printf("%s:\n", dev->name);
+ ret = pinctrl_pinmux_show(dev);
+ if (ret)
+ return ret;
+ }
+ return CMD_RET_SUCCESS;
+}
+
+static int do_list(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct udevice *dev;
+ int ret;
+
+ printf("| %-*.*s| %-*.*s| %s\n",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, "Device",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, "Driver",
+ "Parent");
+
+ for (ret = uclass_find_first_device(UCLASS_PINCTRL, ); dev;
+ret = uclass_find_next_device()) {
+ if (ret)
+ continue;
+
+ printf("| %-*.*s| %-*.*s| %s\n",
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev->name,
+ LIMIT_DEVNAME, LIMIT_DEVNAME, dev->driver->name,
+ dev->parent->name);
+ }
+
+ return ret;
+}
+
+static cmd_tbl_t pinmux_subcmd[] = {
+ U_BOOT_CMD_MKENT(dev, 2, 1, do_dev, "", ""),
+ U_BOOT_CMD_MKENT(list, 1, 1, do_list, "", ""),
+ U_BOOT_CMD_MKENT(status, 2, 1, do_status, "", ""),
+};
+
+static int do_pinmux(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ cmd_tbl_t *cmd;
+
+ argc--;
+ argv++;
+
+ cmd = find_cmd_tbl(argv[0], pinmux_subcmd, ARRAY_SIZE(pinmux_subcmd));
+ if (!cmd || argc > cmd->maxargs)
+ return CMD_RET_USAGE;
+
+ return cmd->cmd(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_CMD(pinmux, CONFIG_SYS_MAXARGS, 1, do_pinmux,
+ "show pin-controller muxing",
+ "list - list UCLASS_PINCTRL devices\n"
+ "pinmux dev [pincontroller-name] - select pin-controller device\n"
+ "pinmux status [-a] -
[U-Boot] [PATCH v1 5/5] gpio: stm32f7: Add ops get_function
This patch adds gpio get_function ops support.
This function reports the state of a gpio.
Signed-off-by: Christophe Kerello
Reviewed-by: Simon Glass
Signed-off-by: Patrice Chotard
---
drivers/gpio/stm32f7_gpio.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpio/stm32f7_gpio.c b/drivers/gpio/stm32f7_gpio.c
index 4c0786fff88d..82c8b8d23ae6 100644
--- a/drivers/gpio/stm32f7_gpio.c
+++ b/drivers/gpio/stm32f7_gpio.c
@@ -65,11 +65,31 @@ static int stm32_gpio_set_value(struct udevice *dev,
unsigned offset, int value)
return 0;
}
+static int stm32_gpio_get_function(struct udevice *dev, unsigned int offset)
+{
+ struct stm32_gpio_priv *priv = dev_get_priv(dev);
+ struct stm32_gpio_regs *regs = priv->regs;
+ int bits_index = MODE_BITS(offset);
+ int mask = MODE_BITS_MASK << bits_index;
+ u32 mode;
+
+ mode = (readl(>moder) & mask) >> bits_index;
+ if (mode == STM32_GPIO_MODE_OUT)
+ return GPIOF_OUTPUT;
+ if (mode == STM32_GPIO_MODE_IN)
+ return GPIOF_INPUT;
+ if (mode == STM32_GPIO_MODE_AN)
+ return GPIOF_UNUSED;
+
+ return GPIOF_FUNC;
+}
+
static const struct dm_gpio_ops gpio_stm32_ops = {
.direction_input= stm32_gpio_direction_input,
.direction_output = stm32_gpio_direction_output,
.get_value = stm32_gpio_get_value,
.set_value = stm32_gpio_set_value,
+ .get_function = stm32_gpio_get_function,
};
static int gpio_stm32_probe(struct udevice *dev)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 4/5] pinctrl: stm32: Add pinmux_show() ops
pinmux_show allows to display the muxing of all pins
belonging to pin-controller.
Signed-off-by: Patrice Chotard
---
drivers/pinctrl/pinctrl_stm32.c | 79 +
1 file changed, 79 insertions(+)
diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
index 31285cdd5784..a477035bf420 100644
--- a/drivers/pinctrl/pinctrl_stm32.c
+++ b/drivers/pinctrl/pinctrl_stm32.c
@@ -14,6 +14,16 @@ DECLARE_GLOBAL_DATA_PTR;
#define OTYPE_MSK 1
#define AFR_MASK 0xF
+#define PINMUX_MODE_COUNT 5
+
+static const char * const pinmux_mode[PINMUX_MODE_COUNT] = {
+ "gpio input",
+ "gpio output",
+ "analog",
+ "unknown",
+ "alt function",
+};
+
static int stm32_gpio_config(struct gpio_desc *desc,
const struct stm32_gpio_ctl *ctl)
{
@@ -176,12 +186,81 @@ static int stm32_pinctrl_set_state_simple(struct udevice
*dev,
}
#endif /* PINCTRL_FULL */
+static int stm32_pinctrl_get_af(struct udevice *dev, unsigned int offset)
+{
+ struct stm32_gpio_priv *priv = dev_get_priv(dev);
+ struct stm32_gpio_regs *regs = priv->regs;
+ u32 af;
+ u32 alt_shift = (offset % 8) * 4;
+ u32 alt_index = offset / 8;
+
+ af = (readl(>afr[alt_index]) &
+ GENMASK(alt_shift + 3, alt_shift)) >> alt_shift;
+
+ return af;
+}
+
+static int stm32_pinmux_show(struct udevice *dev)
+{
+ struct udevice *child;
+ struct udevice *dev_gpio;
+ const char *bank_name;
+ const char *label;
+ int offset;
+ int ret;
+ int num_bits;
+ int mode;
+ int af_num;
+
+ /* parse pin-controller sub-nodes, ie gpio bank nodes */
+ list_for_each_entry(child, >child_head, sibling_node) {
+ ret = uclass_get_device_by_name(UCLASS_GPIO, child->name,
+ _gpio);
+
+ if (ret < 0 && ret != -ENODEV) {
+ dev_err(dev, "Failed to find %s device ret = %d\n",
+ child->name, ret);
+ return ret;
+ }
+
+ if (!ret) {
+ bank_name = gpio_get_bank_info(dev_gpio, _bits);
+
+ printf("\nBank %s:\n", bank_name);
+ for (offset = 0; offset < num_bits; offset++) {
+ mode = gpio_get_raw_function(dev_gpio,
+offset, );
+ printf("%s%d: %s", bank_name, offset,
+ pinmux_mode[mode]);
+ switch (mode) {
+ case GPIOF_FUNC:
+ af_num = stm32_pinctrl_get_af(dev_gpio,
+ offset);
+ printf(" %d", af_num);
+ break;
+ case STM32_GPIO_MODE_OUT:
+ case STM32_GPIO_MODE_IN:
+ printf(" %s", label ? label : "");
+ break;
+ }
+ printf("\n");
+ }
+ }
+
+ if (!child)
+ break;
+ }
+
+ return 0;
+}
+
static struct pinctrl_ops stm32_pinctrl_ops = {
#if CONFIG_IS_ENABLED(PINCTRL_FULL)
.set_state = stm32_pinctrl_set_state,
#else /* PINCTRL_FULL */
.set_state_simple = stm32_pinctrl_set_state_simple,
#endif /* PINCTRL_FULL */
+ .pinmux_show= stm32_pinmux_show,
};
static const struct udevice_id stm32_pinctrl_ids[] = {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/5] configs: stm32mp15: Enable CMD_PINMUX
This allows to use the pinmux command to display pins muxing. Signed-off-by: Patrice Chotard --- configs/stm32mp15_basic_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index e134a66fb105..cd8ec387a5f7 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -24,6 +24,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_PINMUX=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y CONFIG_CMD_EXT4_WRITE=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/5] dm: pinctrl: Add pinmux_show() ops
pinmux_show() allows to display the muxing of all pins
belonging to a pin-controller
Signed-off-by: Patrice Chotard
---
drivers/pinctrl/pinctrl-uclass.c | 10 ++
include/dm/pinctrl.h | 29 +
2 files changed, 39 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index c38bb212ed74..24de7cc09d63 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -249,6 +249,16 @@ int pinctrl_get_gpio_mux(struct udevice *dev, int banknum,
int index)
return ops->get_gpio_mux(dev, banknum, index);
}
+int pinctrl_pinmux_show(struct udevice *dev)
+{
+ struct pinctrl_ops *ops = pinctrl_get_ops(dev);
+
+ if (!ops->pinmux_show)
+ return -ENOSYS;
+
+ return ops->pinmux_show(dev);
+}
+
/**
* pinconfig_post_bind() - post binding for PINCTRL uclass
* Recursively bind child nodes as pinconfig devices in case of full pinctrl.
diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
index 80de3f3fed2b..cbae7e1a640b 100644
--- a/include/dm/pinctrl.h
+++ b/include/dm/pinctrl.h
@@ -66,6 +66,7 @@ struct pinconf_param {
* pointing a config node. (necessary for pinctrl_full)
* @set_state_simple: do needed pinctrl operations for a peripherl @periph.
* (necessary for pinctrl_simple)
+ * @pinmux_show: display pin-controller's pin muxing.
*/
struct pinctrl_ops {
int (*get_pins_count)(struct udevice *dev);
@@ -129,6 +130,20 @@ struct pinctrl_ops {
* @return mux value (SoC-specific, e.g. 0 for input, 1 for output)
*/
int (*get_gpio_mux)(struct udevice *dev, int banknum, int index);
+
+ /**
+* pinmux_show() - show pin-controller's pins muxing
+*
+* This allows to display all pin muxing configuration of a
+* pin-controller. It's useful for debug purpose to know if a pin is
+* configured as GPIO or as an alternate function and which one.
+* Typically it is used by a PINCTRL driver with knowledge of the SoC
+* pinctrl setup.
+*
+* @dev:Pinctrl device to use
+* @return 0 if OK, -ve on error
+*/
+ int (*pinmux_show)(struct udevice *dev);
};
#define pinctrl_get_ops(dev) ((struct pinctrl_ops *)(dev)->driver->ops)
@@ -348,4 +363,18 @@ int pinctrl_decode_pin_config(const void *blob, int node);
*/
int pinctrl_get_gpio_mux(struct udevice *dev, int banknum, int index);
+/**
+ * pinctrl_pinmux_show() - display pin-controller pins muxing
+ *
+ * This allows the raw mux value for a GPIO to be obtained. It is
+ * useful for displaying the function being used by that GPIO, such
+ * as with the 'gpio' command. This function is internal to the GPIO
+ * subsystem and should not be used by generic code. Typically it is
+ * used by a GPIO driver with knowledge of the SoC pinctrl setup.
+ *
+ * @dev: Pinctrl device to use
+ * @return 0 if OK, -ve on error
+ */
+int pinctrl_pinmux_show(struct udevice *dev);
+
#endif /* __PINCTRL_H */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/5] Add pinmux command
For debug purpose, it's useful to know the pins muxing to check is a pin is configured as a GPIO or as an alternate function. For this purpose a new command pinmux is implemented. This series adds: _ Add new pinmux_show ops to UCLASS pinctrl - Add new pinmux command - Add get_function() support to stm32 gpio driver - Add pinmux_show() support to stm32 pinctrl driver - Enable CMD_PINMUX flag to stm32mp15 defconfig Patrice Chotard (5): dm: pinctrl: Add pinmux_show() ops cmd: pinmux: Add pinmux command configs: stm32mp15: Enable CMD_PINMUX pinctrl: stm32: Add pinmux_show() ops gpio: stm32f7: Add ops get_function cmd/Kconfig | 8 +++ cmd/Makefile | 3 + cmd/pinmux.c | 115 ++ configs/stm32mp15_basic_defconfig | 1 + drivers/gpio/stm32f7_gpio.c | 20 +++ drivers/pinctrl/pinctrl-uclass.c | 10 drivers/pinctrl/pinctrl_stm32.c | 79 ++ include/dm/pinctrl.h | 29 ++ 8 files changed, 265 insertions(+) create mode 100644 cmd/pinmux.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally
On Thu, Sep 20, 2018 at 11:37:36AM +0800, Bin Meng wrote: > Hi Tom, > > On Mon, Sep 17, 2018 at 1:30 PM Bin Meng wrote: > > > > The -fstrict-aliasing option is implicitly enabled at levels -O2, > > -O3, -Os by GCC. This option allows the compiler to assume the > > strictest aliasing rules applicable to the language being compiled. > > For example, the practice of reading from a different union member > > than the one most recently written to (called "type-punning") is > > common. In this case, "type-punning" only works if the memory is > > accessed through the union type, but might not work by taking the > > address, casting the resulting pointer and dereferencing the result, > > which is an undefined behavior per the "strict aliasing rules". > > > > GCC's -Wstrict-aliasing (included in -Wall) option does not catch > > all cases, but does attempt to catch the more common pitfalls. So > > there are cases that GCC does not report but the codes are violating > > the "strict aliasing rules". > > > > Given lots of codes that may be written to rely on "type-punning", > > and Linux kernel disables it by -fno-strict-aliasing globally, since > > U-Boot currently does this on nds32/riscv/x86 builds only, extend > > this for all architecture builds. > > > > Signed-off-by: Bin Meng > > Reviewed-by: Tom Rini > > Reviewed-by: Simon Glass > > --- > > > > Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > When will this series be applied? Another risc-v series has conflicts > in [PATCH 2/2] and if this is applied in mainline, I can respin my > risc-v series on top of this to save some time for Rick's handle it > himself. I will try and get to this soon, thanks for your patience. -- 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] [PULL] Please pull u-boot-imx
On Wed, Sep 19, 2018 at 05:16:17PM +0200, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx with following changes: > > - changes in pico-* boards > - fix imx6ull pinmux > > Thanks, > Stefano > > > The following changes since commit b57f1895b669e3fbdca486e7c40dfea00f22bb93: > > Merge git://git.denx.de/u-boot-x86 (2018-09-17 08:04:25 -0400) > > are available in the Git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to f7df8932ccaec97c8c422de8adadb3a0491543ed: > > pico-imx7d: Add a new defconfig with PICO-Hobbit selected (2018-09-18 > 16:55:21 +0200) > Applied to u-boot/master, thanks! -- 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] Please pull u-boot-marvell/master
On Wed, Sep 19, 2018 at 05:12:03PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the Marvell U-Boot patches with these changes: > > - Multiples updates to the turris boards / platform > - Changes / enhancements to the Marvell PHY drivers, mainly > to support the turris platform > - Many fixes and enhancements to the pxa3xx NAND driver > - Fixes for the UART boot mode in kwboot > - Misc minor changes to other 32bit and 64bit boards > > Thanks, > Stefan > > > The following changes since commit b57f1895b669e3fbdca486e7c40dfea00f22bb93: > > Merge git://git.denx.de/u-boot-x86 (2018-09-17 08:04:25 -0400) > > are available in the Git repository at: > > git://www.denx.de/git/u-boot-marvell.git > > for you to fetch changes up to e32ac37119394f2d3c579b2cdd549bed59fb583f: > > arm: mvebu: clearfog: enable eMMC boot partitions support (2018-09-19 > 14:00:06 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools: socfpga: fix sfp_verify_header
Fix sfp_verify_header to return correct version number.
This fixes "Not a sane SOCFPGA preloader" error message with v1 header.
Signed-off-by: Atsushi Nemoto
---
tools/socfpgaimage.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c
index 390c9bb..fea22b4 100644
--- a/tools/socfpgaimage.c
+++ b/tools/socfpgaimage.c
@@ -174,6 +174,7 @@ static int sfp_verify_header(const uint8_t *buf, uint8_t
*ver)
if (le32_to_cpu(header_v0.validation) != VALIDATION_WORD)
return -1;
+ *ver = header_v0.version;
if (header_v0.version == 0) {
hdr_csum = le16_to_cpu(header_v0.checksum);
sfp_csum = sfp_hdr_checksum((uint8_t *)_v0, 0);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] build u-boot failed with config CONFIG_ARMV8_PSCI by aarch linux gcc 8.1
Hi All maintainers, Could you please help to have a look whether below issue is valuable? I got u-boot source code from https://github.com/u-boot/u-boot.git, branch is master. I got toolchain from https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/ I built stratix10(socfpga) platform with below commands: export CROSS_COMPILE=xxx/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- export ARCH=arm64 make mrproper make socfpga_stratix10_defconfig make there will be below error: LD u-boot /home/wrsadmin/Project/Native/SDK/Altera-Arria-10/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux-ld.bfd: arch/arm/cpu/armv8/built-in.o: relocation R_AARCH64_ABS32 against `psci_cpu_suspend' can not be used when making a shared object /home/wrsadmin/Project/Native/SDK/Altera-Arria-10/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux-ld.bfd: arch/arm/mach-socfpga/built-in.o: relocation R_AARCH64_ABS32 against `el3_exception_vectors' can not be used when making a shared object arch/arm/mach-socfpga/built-in.o: In function `wfi_loop': smmu_s10.c:(._secure.text+0x758): dangerous relocation: unsupported relocation smmu_s10.c:(._secure.text+0x760): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x8): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x18): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x28): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x38): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x48): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x58): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x68): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x78): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x88): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(._secure_svc_tbl_entries+0x98): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:/home/wrsadmin/Project/Native/SDK/Altera-Arria-10/u-boot-socfpga/arch/arm/mach-socfpga/clock_manager.c:68:(.u_boot_list_2_cmd_2_clocks+0x0): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_clocks+0x10): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_clocks+0x18): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_clocks+0x20): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:/home/wrsadmin/Project/Native/SDK/Altera-Arria-10/u-boot-socfpga/arch/arm/mach-socfpga/misc_s10.c:382:(.u_boot_list_2_cmd_2_bridge+0x0): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_bridge+0x10): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_bridge+0x18): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_bridge+0x20): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.data.mem_map+0x0): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:/home/wrsadmin/Project/Native/SDK/Altera-Arria-10/u-boot-socfpga/arch/arm/mach-socfpga/rsu_s10.c:262:(.u_boot_list_2_cmd_2_rsu+0x0): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_rsu+0x10): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_rsu+0x18): dangerous relocation: unsupported relocation arch/arm/mach-socfpga/built-in.o:(.u_boot_list_2_cmd_2_rsu+0x20): dangerous relocation: unsupported relocation Makefile:1255: recipe for target 'u-boot' failed make: *** [u-boot] Error 1 I found out this build error is caused by enable CONFIG_ARMV8_PSCI. Could you please tell me whether you also encountered this issue before? I try lower version GCC toolchain, it works fine. Thanks, Limeng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] serial: serial_stm32: Enable uart FIFO for STM32F7xx SoCs
Since commit 7b3b74d32127 ("serial: serial_stm32: Enable overrun")
on STM32F7xx based boards, the first lines of serial output are
missing during boot (we no more see the U-Boot release version,
board model and DRAM size).
By enabling the uart FIFO on STM32F7, the complete U-boot log
can be sent correctly.
Signed-off-by: Patrice Chotard
---
drivers/serial/serial_stm32.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/serial/serial_stm32.h b/drivers/serial/serial_stm32.h
index ccafa31219a1..5549f8c5368a 100644
--- a/drivers/serial/serial_stm32.h
+++ b/drivers/serial/serial_stm32.h
@@ -37,7 +37,7 @@ struct stm32_uart_info stm32f4_info = {
struct stm32_uart_info stm32f7_info = {
.uart_enable_bit = 0,
.stm32f4 = false,
- .has_fifo = false,
+ .has_fifo = true,
};
struct stm32_uart_info stm32h7_info = {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] pci: Update documentation to make 'compatible' string optional
On 09/20/2018 03:55 AM, Bin Meng wrote: > Hi Marek, > > On Wed, Sep 19, 2018 at 9:29 PM Marek Vasut wrote: >> >> On 09/18/2018 04:02 PM, Simon Glass wrote: >>> Hi Marek, >> >> Hi, >> >>> On 18 September 2018 at 05:47, Marek Vasut wrote: On 09/14/2018 06:41 AM, Simon Glass wrote: > Hi Marex, It's Marek btw ... > On 11 September 2018 at 14:58, Marek Vasut wrote: >> Reword the documentation to make it clear the compatible string is now >> optional, yet still matching on it takes precedence over PCI IDs and >> PCI classes. >> >> Signed-off-by: Marek Vasut >> Cc: Simon Glass >> Cc: Tom Rini >> --- >> V3: No change >> V2: New patch >> --- >> doc/driver-model/pci-info.txt | 14 +- >> 1 file changed, 9 insertions(+), 5 deletions(-) >> >> diff --git a/doc/driver-model/pci-info.txt >> b/doc/driver-model/pci-info.txt >> index e1701d1fbc..14364c5c75 100644 >> --- a/doc/driver-model/pci-info.txt >> +++ b/doc/driver-model/pci-info.txt >> @@ -34,11 +34,15 @@ under that bus. >> Note that this is all done on a lazy basis, as needed, so until >> something is >> touched on PCI (eg: a call to pci_find_devices()) it will not be probed. >> >> -PCI devices can appear in the flattened device tree. If they do this >> serves to >> -specify the driver to use for the device. In this case they will be >> bound at >> -first. Each PCI device node must have a compatible string list as well >> as a >> - property, as defined by the IEEE Std 1275-1994 PCI bus binding >> document >> -v2.1. Note we must describe PCI devices with the same bus hierarchy as >> the >> +PCI devices can appear in the flattened device tree. If they do, their >> node >> +often contains extra information which cannot be derived from the PCI >> IDs or >> +PCI class of the device. Each PCI device node must have a >> property, as >> +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. >> Compatible >> +string list is optional and generally not needed, since PCI is >> discoverable > > I really don't like 'generally not needed'. How about 'generally not > essential'? Or that you can usually avoid it if desired. Must be a language nuance, but the compatible string is really not needed. I am starting to understand where this mindset of "compat strings are generally needed" comes from, which is the design of the virtual PCI devices in sandbox, but that's not the usual case. >>> >>> Well it's more than that, as I mentioned before. Finding a compatible >>> string in the source code is easier, and if we are matching with a DT >>> node anyway, makes more sense IMO. >> >> It's about as easy as finding PCI ID. >> >> And PCI is a discoverable bus, so using a compatible string is some >> obscure edge-case. >> >>> Anyway since DTs likely come from >>> the newly pleasant Linux we'll just end up with what they have there. >>> This mostly applies for things like x86 which don't use DT in Linux. >>> > I'd like to say that it is optional since U_BOOT_PCI_DEVICE() can be > used to specific the driver based on conditions like the PCI vendor/, > PCI class, etc. If U-Boot does not find a compatible string then it > will search these U_BOOT_PCI_DEVICE() records to find a driver; > assuming it finds one it will then search for the device-tree node > whose reg property matches the bus/device/function of the device, and > attached that node to the device so that it is accessible to the > driver. Can you rephrase it better then ? I can paste it into the docs. >>> >>> How about: >>> >>> The compatible string is optional since U_BOOT_PCI_DEVICE() can be >>> used to specific >> >> specify ? >> >>> the driver based on conditions like the PCI vendor/ >>> PCI class, etc. If U-Boot does not find a compatible string then it >>> will search these U_BOOT_PCI_DEVICE() records to find a driver; >> >> This implies the compatible string is preferred, it is not. >> > > I think Simon was describing the *current* U-Boot implementation, that > "compatible" string is looked up first, then U_BOOT_PCI_DEVICE(). This patch updates the documentation to match reality though. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Remove unused function socfpga_emac_manage_reset()
On 09/20/2018 06:22 PM, Ley Foon Tan wrote:
> Remove code from the reset manager that is never called.
>
> Signed-off-by: Ley Foon Tan
> ---
> .../mach-socfpga/include/mach/reset_manager_s10.h | 2 --
> arch/arm/mach-socfpga/reset_manager_s10.c | 35
> --
> 2 files changed, 37 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> index 6182d5f..31b73ed 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> @@ -108,8 +108,6 @@ struct socfpga_reset_manager {
> #define RSTMGR_GPIO1 RSTMGR_DEFINE(2, 25)
> #define RSTMGR_SDR RSTMGR_DEFINE(3, 6)
>
> -void socfpga_emac_manage_reset(const unsigned int of_reset_id, u32 state);
> -
> /* Create a human-readable reference to SoCFPGA reset. */
> #define SOCFPGA_RESET(_name) RSTMGR_##_name
>
> diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c
> b/arch/arm/mach-socfpga/reset_manager_s10.c
> index 5cc8336..f176c38 100644
> --- a/arch/arm/mach-socfpga/reset_manager_s10.c
> +++ b/arch/arm/mach-socfpga/reset_manager_s10.c
> @@ -93,41 +93,6 @@ void socfpga_bridges_reset(int enable)
> }
> }
>
> -/* of_reset_id: emac reset id
> - * state: 0 - disable reset, !0 - enable reset
> - */
> -void socfpga_emac_manage_reset(const unsigned int of_reset_id, u32 state)
> -{
> - u32 reset_emac;
> - u32 reset_emacocp;
> -
> - /* hardcode this now */
> - switch (of_reset_id) {
> - case EMAC0_RESET:
> - reset_emac = SOCFPGA_RESET(EMAC0);
> - reset_emacocp = SOCFPGA_RESET(EMAC0_OCP);
> - break;
> - case EMAC1_RESET:
> - reset_emac = SOCFPGA_RESET(EMAC1);
> - reset_emacocp = SOCFPGA_RESET(EMAC1_OCP);
> - break;
> - case EMAC2_RESET:
> - reset_emac = SOCFPGA_RESET(EMAC2);
> - reset_emacocp = SOCFPGA_RESET(EMAC2_OCP);
> - break;
> - default:
> - printf("GMAC: Invalid reset ID (%i)!\n", of_reset_id);
> - hang();
> - break;
> - }
> -
> - /* Reset ECC OCP first */
> - socfpga_per_reset(reset_emacocp, state);
> -
> - /* Release the EMAC controller from reset */
> - socfpga_per_reset(reset_emac, state);
> -}
Are you absolutely positive this is correctly handled by the reset
manager driver ? Including the OCP resets ? If so, fine.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/1] ARM: opos6ul: make the board boot again
Hello,
On 09/06/2018 03:57 PM, Stefano Babic wrote:
> On 06/09/2018 09:51, Sébastien Szymanski wrote:
>> Commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for u-boot,
>> dm-spl") removes the u-boot,dm-spl properties from the imx6ul.dtsi file
>> and breaks the OPOS6UL board.
>> Add the u-boot,dm-spl properties into *-u-boot.dts files to make the
>> board boot again.
>>
>> Fixes: commit 9faa43c4b5e5 ("ARM: dts: i.MX6UL: U-Boot specific dts for
>> u-boot, dm-spl")
>> Signed-off-by: Sébastien Szymanski
>> ---
>>
>> Changes for v3:
>> - use the automatic inclusion of -u-boot.dtsi mechanism of U-Boot.
>>
>> Changes for v2:
>> - put u-boot,dm-spl properties into -u-boot.dts files
>>
>> arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi| 28
>> arch/arm/dts/imx6ul-opos6ul.dtsi | 2 --
>> arch/arm/dts/imx6ul-opos6uldev-u-boot.dtsi | 24
>> arch/arm/dts/imx6ul-opos6uldev.dts | 2 --
>> 4 files changed, 52 insertions(+), 4 deletions(-)
>> create mode 100644 arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi
>> create mode 100644 arch/arm/dts/imx6ul-opos6uldev-u-boot.dtsi
>>
[...]
>
> Reviewed-by: Stefano Babic
Is there still something preventing this patch to be applied ?
Best regards,
>
> Best regards,
> Stefano Babic
>
--
Sébastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: Remove unused function socfpga_emac_manage_reset()
Remove code from the reset manager that is never called.
Signed-off-by: Ley Foon Tan
---
.../mach-socfpga/include/mach/reset_manager_s10.h | 2 --
arch/arm/mach-socfpga/reset_manager_s10.c | 35 --
2 files changed, 37 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
index 6182d5f..31b73ed 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
@@ -108,8 +108,6 @@ struct socfpga_reset_manager {
#define RSTMGR_GPIO1 RSTMGR_DEFINE(2, 25)
#define RSTMGR_SDR RSTMGR_DEFINE(3, 6)
-void socfpga_emac_manage_reset(const unsigned int of_reset_id, u32 state);
-
/* Create a human-readable reference to SoCFPGA reset. */
#define SOCFPGA_RESET(_name) RSTMGR_##_name
diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c
b/arch/arm/mach-socfpga/reset_manager_s10.c
index 5cc8336..f176c38 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -93,41 +93,6 @@ void socfpga_bridges_reset(int enable)
}
}
-/* of_reset_id: emac reset id
- * state: 0 - disable reset, !0 - enable reset
- */
-void socfpga_emac_manage_reset(const unsigned int of_reset_id, u32 state)
-{
- u32 reset_emac;
- u32 reset_emacocp;
-
- /* hardcode this now */
- switch (of_reset_id) {
- case EMAC0_RESET:
- reset_emac = SOCFPGA_RESET(EMAC0);
- reset_emacocp = SOCFPGA_RESET(EMAC0_OCP);
- break;
- case EMAC1_RESET:
- reset_emac = SOCFPGA_RESET(EMAC1);
- reset_emacocp = SOCFPGA_RESET(EMAC1_OCP);
- break;
- case EMAC2_RESET:
- reset_emac = SOCFPGA_RESET(EMAC2);
- reset_emacocp = SOCFPGA_RESET(EMAC2_OCP);
- break;
- default:
- printf("GMAC: Invalid reset ID (%i)!\n", of_reset_id);
- hang();
- break;
- }
-
- /* Reset ECC OCP first */
- socfpga_per_reset(reset_emacocp, state);
-
- /* Release the EMAC controller from reset */
- socfpga_per_reset(reset_emac, state);
-}
-
/*
* Release peripherals from reset based on handoff
*/
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: designware_spi: Disable and free clock when remove driver
On Wed, Sep 19, 2018 at 5:22 PM Marek Vasut wrote:
>
> On 09/19/2018 10:27 AM, Ley Foon Tan wrote:
> > Disable and free clock when remove driver.
> >
> > Signed-off-by: Ley Foon Tan
> >
> > ---
> > v2:
> > - Check return value from clk_free() and return 0 when exit function
> > ---
> > drivers/spi/designware_spi.c | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> > index 5cca414..8f0c602 100644
> > --- a/drivers/spi/designware_spi.c
> > +++ b/drivers/spi/designware_spi.c
> > @@ -516,8 +516,22 @@ static int dw_spi_set_mode(struct udevice *bus, uint
> > mode)
> > static int dw_spi_remove(struct udevice *bus)
> > {
> > struct dw_spi_priv *priv = dev_get_priv(bus);
> > + int ret;
> > +
> > + ret = reset_release_bulk(>resets);
> > + if (ret)
> > + return ret;
> >
> > - return reset_release_bulk(>resets);
> > +#if CONFIG_IS_ENABLED(CLK)
> > + ret = clk_disable(>clk);
> > + if (ret)
> > + return ret;
> > +
> > + ret = clk_free(>clk);
> > + if (ret)
> > + return ret;
> > +#endif
> > + return 0;
> > }
> >
> > static const struct dm_spi_ops dw_spi_ops = {
> >
>
> Acked-by: Marek Vasut
>
> btw this doesn't apply to socfpga/master .
>
Jagan,
Can you help to merge this patch?
And also this designware_spi's patch. This patch should apply first.
https://patchwork.ozlabs.org/patch/967210/
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: macb: Clean 64b dma addresses if they are not detected
On 19.9.2018 20:08, Edgar E. Iglesias wrote: > On Wed, Sep 19, 2018 at 06:08:18PM +0200, Michal Simek wrote: >> Clear ADDR64 dma bit in DMACFG register in case that HW_DMA_CAP_64B >> is not detected on 64bit system. >> The issue was observed when bootloader(u-boot) does not check macb >> feature at DCFG6 register (DAW64_OFFSET) and enabling 64bit dma support >> by default. Then macb driver is reading DMACFG register back and only >> adding 64bit dma configuration but not cleaning it out. >> >> This is also align with other features which are also cleared if they are not >> present. > > Hi Michal, > >> >> Signed-off-by: Michal Simek >> --- >> >> drivers/net/ethernet/cadence/macb_main.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/net/ethernet/cadence/macb_main.c >> b/drivers/net/ethernet/cadence/macb_main.c >> index 16e4ef7d7185..79707dff3f13 100644 >> --- a/drivers/net/ethernet/cadence/macb_main.c >> +++ b/drivers/net/ethernet/cadence/macb_main.c >> @@ -2163,6 +2163,8 @@ static void macb_configure_dma(struct macb *bp) >> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT >> if (bp->hw_dma_cap & HW_DMA_CAP_64B) >> dmacfg |= GEM_BIT(ADDR64); >> +else >> +dmacfg &= ~GEM_BIT(ADDR64); >> #endif > > I think you might want to do this clearing outside of the #ifdef. > If CONFIG_ARCH_DMA_ADDR_T_64BIT is not defined, we'd want to make > sure the ADDR64 is cleared. E.g something like: > > dmacfg &= ~GEM_BIT(ADDR64); > #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT > if (bp->hw_dma_cap & HW_DMA_CAP_64B) > dmacfg |= GEM_BIT(ADDR64); > #endif > > > Same thing for the USE_HWSTAMP/PTP flags below. Origin patch, which introduce this read with mask, macfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L); was done in 2011 and from that time this function was extended a little bit. I am even not quite sure if make sense to read this reg and apply setting on the top of it. Nicolas: Isn't it better simply compose that reg from scratch? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
