Re: [U-Boot] [PATCH 2/3] cmd: fpga: Add support to load secure bitstreams
On 29.5.2018 16:22, Siva Durga Prasad Paladugu wrote:
> This patch adds support to load secure bitstreams(authenticated or
> encrypted or both). As of now, this feature is added and tested only
> for xilinx bitstreams and the secure bitstream was generated using
> xilinx bootgen tool, but the command is defined in more generic way.
>
> Command example to load authenticated and device key
> encrypted bitstream is as follows
> "fpga loads 0 10 200 0 1"
>
> Signed-off-by: Siva Durga Prasad Paladugu
> ---
> cmd/Kconfig | 7 ++
> cmd/fpga.c | 62
> -
> drivers/fpga/fpga.c | 29 +
> include/fpga.h | 11 ++
> 4 files changed, 108 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 38406fc..9b9eb94 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -697,6 +697,13 @@ config CMD_FPGA_LOADP
> Supports loading an FPGA device from a bitstream buffer containing
> a partial bitstream.
>
> +config CMD_FPGA_LOAD_SECURE
> + bool "fpga loads - loads secure bitstreams (Xilinx only)"
> + depends on CMD_FPGA
> + help
> + Enables the fpga loads command which is used to load secure
> + (authenticated or encrypted or both) bitstreams on to FPGA.
> +
> config CMD_FPGAD
> bool "fpgad - dump FPGA registers"
> help
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index 0981826..ad716a0 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
> @@ -27,6 +27,7 @@ enum {
> FPGA_LOADP,
> FPGA_LOADBP,
> FPGA_LOADFS,
> + FPGA_LOADS,
> };
>
> /* -
> */
> @@ -54,6 +55,11 @@ int do_fpga(cmd_tbl_t *cmdtp, int flag, int argc, char
> *const argv[])
> fpga_fs_info fpga_fsinfo;
> fpga_fsinfo.fstype = FS_TYPE_ANY;
> #endif
> +#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
> + struct fpga_secure_info fpga_sec_info;
> +
> + memset(_sec_info, 0, sizeof(fpga_sec_info));
> +#endif
>
> if (devstr)
> dev = (int) simple_strtoul(devstr, NULL, 16);
> @@ -80,6 +86,19 @@ int do_fpga(cmd_tbl_t *cmdtp, int flag, int argc, char
> *const argv[])
> argc = 5;
> break;
> #endif
> +#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
> + case FPGA_LOADS:
> + if (argc < 7)
> + return CMD_RET_USAGE;
> + if (argc == 8)
> + fpga_sec_info.userkey_addr = (u8 *)(uintptr_t)
> + simple_strtoull(argv[7],
> + NULL, 16);
> + fpga_sec_info.encflag = (u8)simple_strtoul(argv[6], NULL, 16);
> + fpga_sec_info.authflag = (u8)simple_strtoul(argv[5], NULL, 16);
> + argc = 5;
> + break;
> +#endif
> default:
> break;
> }
> @@ -150,6 +169,22 @@ int do_fpga(cmd_tbl_t *cmdtp, int flag, int argc, char
> *const argv[])
> if (!fpga_fsinfo.interface || !fpga_fsinfo.dev_part ||
> !fpga_fsinfo.filename)
> wrong_parms = 1;
> + break;
> +#endif
> +#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
> + case FPGA_LOADS:
> + if (fpga_sec_info.authflag >= FPGA_NO_ENC_OR_NO_AUTH &&
> + fpga_sec_info.encflag >= FPGA_NO_ENC_OR_NO_AUTH) {
> + puts("ERR: use for NonSecure bitstream\n");
> + wrong_parms = 1;
> + }
> +
> + if (fpga_sec_info.encflag == FPGA_ENC_USR_KEY &&
> + !fpga_sec_info.userkey_addr) {
> + wrong_parms = 1;
> + puts("ERR:User key not provided\n");
> + }
> + break;
I have created some patches on the top of this series to clean this file
more. And There is no reason to put this checking here. You can simply
put it to code above and instead of wrong_parms just return CMD_RET_USAGE.
M
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] inappropriate PCI configuration on arm64 qemu?
Simon,
On Wed, May 30, 2018 at 01:18:30PM -0600, Simon Glass wrote:
> +Tuomas
>
> Hi Akashi,
>
> On 28 May 2018 at 01:59, AKASHI Takahiro wrote:
> > When I tried to add a SD card to qemu's virt machine (2.10.0) as,
> > --
> > -device sdhci-pci \
> > -device sd-card,drive=my_sd \
> > -drive if=none,id=my_sd,format=raw,file=/path/my/sd.img
> > --
> > u-boot doesn't configure a SDHCI controller properly and an attached
> > device is never detected.
> >
> > Digging into the code, I found
> > * reading BAR5 in dm_pciauto_setup_device() shows BAR5 is a 32-bit address,
> > * pciauto_region_allocate() allocates a 64-bit address (0x80.ABCD.)
> > to BAR5 as res->bus_lower is 0x80..
> > * Upper 32-bit value is not written back to BAR5 because of !found_mem64
> > (BAR5 is the last one and no succeeding BAR anyway.)
> >
> > On the other hand,
> > * Qemu defines two PCI memory regions for MMIO:
> > (from qemu's hw/arm/virt.c)
> > --
> > [VIRT_PCIE_MMIO] = { 0x1000, 0x2eff },
> > [VIRT_PCIE_PIO] = { 0x3eff, 0x0001 },
> > [VIRT_PCIE_ECAM] = { 0x3f00, 0x0100 },
> > [VIRT_MEM] ={ 0x4000, RAMLIMIT_BYTES },
> > /* Second PCIe window, 512GB wide at the 512GB boundary */
> > [VIRT_PCIE_MMIO_HIGH] = { 0x80ULL, 0x80ULL },
> > --
> > * A PCI card is configured in decode_regions() so that
> > 'hose' has only one entry per each type of memory regions.
> > This behavior was introduced by Simon's patch:
> > --
> > commit 9526d83ac5a
> > Author: Simon Glass
> > Date: Thu Nov 19 20:26:58 2015 -0700
> >
> > dm: pci: Support decoding ranges with duplicate entries
> > --
> > * As a result, MMIO region (0x1000.-0x2eff.) is overwritten
> > and MMIO_HIGH is the only one available at runtime.
> >
> > I believe that this behavior is the root cause of my issue, and
> > by reverting the patch mentioned above, everything works fine.
> >
> > While I understand a concern mentioned in the commit message,
> > there should be a better way to manage the case.
>
> There was a series that changed things in this area. Can you take a look?
>
>PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set
Ah, I didn't know that, but it seems to me that it is still insufficient.
This hack won't work on 32-bit PCI card. I found another patch from Tuomas:
---
commit d71975ae6e0
Author: Tuomas Tynkkynen
Date: Mon May 14 19:38:13 2018 +0300
PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only
resources
---
This approach looks too conservative if 32-bit window is also available,
in addition to 64-bit space, as in the case of qemu-arm.
I'd like to propose supporting at least two type of PCI memory regions,
low mem (normal case) and high mem.
Attached is my experimental implementation for this although I might have
made any mistake as I'm not very much familiar with PCI specification.
(When you try to apply this, please revert the commit above.)
Thanks,
-Takahiro AKASHI
> Regards,
> Simon
---8<---
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 1cd1e409e3e..40282c616a4 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -867,13 +867,7 @@ static int decode_regions(struct pci_controller *hose,
ofnode parent_node,
continue;
}
- pos = -1;
- for (i = 0; i < hose->region_count; i++) {
- if (hose->regions[i].flags == type)
- pos = i;
- }
- if (pos == -1)
- pos = hose->region_count++;
+ pos = hose->region_count++;
debug(" - type=%d, pos=%d\n", type, pos);
pci_set_region(hose->regions + pos, pci_addr, addr, size, type);
}
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index d1feb503a0a..01423879552 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -19,6 +19,7 @@
void dm_pciauto_setup_device(struct udevice *dev, int bars_num,
struct pci_region *mem,
+struct pci_region *himem,
struct pci_region *prefetch, struct pci_region *io,
bool enum_only)
{
@@ -29,7 +30,7 @@ void dm_pciauto_setup_device(struct udevice *dev, int
bars_num,
u8 header_type;
int rom_addr;
pci_addr_t bar_value;
- struct pci_region *bar_res = NULL;
+ struct pci_region *bar_res = NULL, *bar_res32 = NULL;
int found_mem64 = 0;
u16 class;
@@ -88,7 +89,12 @@ void dm_pciauto_setup_device(struct udevice *dev, int
bars_num,
[U-Boot] [PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit
Add ability to set environment bootlimit from Kconfig
Signed-off-by: Alex Kiernan
---
Changes in v2: None
drivers/bootcount/Kconfig | 8
include/env_default.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index d335ed14b9..9a0bd516d9 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -72,6 +72,14 @@ config BOOTCOUNT_AT91
endchoice
+config BOOTCOUNT_BOOTLIMIT
+ int "Maximum number of reboot cycles allowed"
+ default 0
+ help
+ Set the Maximum number of reboot cycles allowed without the boot
+ counter being cleared.
+ If set to 0 do not set a boot limit in the environment.
+
config BOOTCOUNT_ALEN
int "I2C address length"
default 1
diff --git a/include/env_default.h b/include/env_default.h
index 54d8124793..748076288e 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -104,6 +104,9 @@ const uchar default_environment[] = {
"soc=" CONFIG_SYS_SOC "\0"
#endif
#endif
+#if defined(CONFIG_BOOTCOUNT_BOOTLIMIT) && (CONFIG_BOOTCOUNT_BOOTLIMIT > 0)
+ "bootlimit="__stringify(CONFIG_BOOTCOUNT_BOOTLIMIT)"\0"
+#endif
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] Migrate bootlimit to Kconfig
Migrate boards which set bootlimit in the environment to Kconfig. We exclude gurnard_defconfig which includes a bootlimit=, but doesn't set CONFIG_BOOTCOUNT_LIMIT, so we'd fail to include a bootlimit setting if we migrated it. display5_defconfig and display5_factory_defconfig share a SYS_CONFIG_NAME, but only display5_defconfig enables CONFIG_BOOTCOUNT_LIMIT, so we fail to set bootlimit= in display5_factory_defconfig. This is okay because the display5_factory_defconfig doesn't need to have it set, as it is only meant to prepare the board in the factory. Signed-off-by: Alex Kiernan --- Changes in v2: - include display5 in the migration to Kconfig configs/brppt1_mmc_defconfig | 1 + configs/brppt1_nand_defconfig | 1 + configs/brppt1_spi_defconfig | 1 + configs/calimain_defconfig | 1 + configs/display5_defconfig | 1 + configs/draco_defconfig| 1 + configs/etamin_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge4_defconfig | 1 + configs/kmcoge5ne_defconfig| 1 + configs/kmcoge5un_defconfig| 1 + configs/kmeter1_defconfig | 1 + configs/kmlion1_defconfig | 1 + configs/kmnusa_defconfig | 1 + configs/kmopti2_defconfig | 1 + configs/kmsugp1_defconfig | 1 + configs/kmsupx5_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/kmtegr1_defconfig | 1 + configs/kmtepr2_defconfig | 1 + configs/kmvect1_defconfig | 1 + configs/mgcoge3un_defconfig| 1 + configs/mx53ppd_defconfig | 1 + configs/portl2_defconfig | 1 + configs/pxm2_defconfig | 1 + configs/rastaban_defconfig | 1 + configs/rut_defconfig | 1 + configs/suvd3_defconfig| 1 + configs/thuban_defconfig | 1 + configs/tuge1_defconfig| 1 + configs/tuxx1_defconfig| 1 + include/configs/brppt1.h | 2 -- include/configs/calimain.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 1 - include/configs/km/keymile-common.h| 1 - include/configs/mx53ppd.h | 1 - include/configs/siemens-am33x-common.h | 1 - 41 files changed, 34 insertions(+), 8 deletions(-) diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig index 5511f2c78e..76d91d4d11 100644 --- a/configs/brppt1_mmc_defconfig +++ b/configs/brppt1_mmc_defconfig @@ -50,6 +50,7 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y CONFIG_NETCONSOLE=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=1 CONFIG_MMC_OMAP_HS=y CONFIG_DRIVER_TI_CPSW=y CONFIG_SYS_NS16550=y diff --git a/configs/brppt1_nand_defconfig b/configs/brppt1_nand_defconfig index e00f409d7b..311050c64c 100644 --- a/configs/brppt1_nand_defconfig +++ b/configs/brppt1_nand_defconfig @@ -51,6 +51,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:128k(MLO),128k(MLO.backup),128k(d CONFIG_ENV_IS_IN_NAND=y CONFIG_NETCONSOLE=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=1 # CONFIG_MMC is not set CONFIG_NAND=y CONFIG_DRIVER_TI_CPSW=y diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig index 8d4f1c1252..977ae73514 100644 --- a/configs/brppt1_spi_defconfig +++ b/configs/brppt1_spi_defconfig @@ -57,6 +57,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NETCONSOLE=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=1 CONFIG_MMC_OMAP_HS=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/calimain_defconfig b/configs/calimain_defconfig index 7908cfcc34..55782463ae 100644 --- a/configs/calimain_defconfig +++ b/configs/calimain_defconfig @@ -22,6 +22,7 @@ CONFIG_CMD_PING=y CONFIG_CMD_DIAG=y CONFIG_ENV_IS_IN_FLASH=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_ADDR=0x01C23000 # CONFIG_MMC is not set CONFIG_MTD_NOR_FLASH=y diff --git a/configs/display5_defconfig b/configs/display5_defconfig index db8212ca7c..3b8de0a854 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -55,6 +55,7 @@ CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_FSL_ESDHC=y CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_SYS_BOOTCOUNT_ADDR=0x020CC068 CONFIG_SPI_FLASH=y diff --git a/configs/draco_defconfig b/configs/draco_defconfig index 9ddb3d278d..0548b2c19b 100644 --- a/configs/draco_defconfig +++ b/configs/draco_defconfig @@ -56,6 +56,7 @@ CONFIG_OF_EMBED=y CONFIG_ENV_IS_IN_NAND=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y +CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_DFU_NAND=y CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y
[U-Boot] [PATCH v2 0/2] Add bootlimit to Kconfig
This patch series adds the bootlimit environment variable to Kconfig and migrates users to it. Changes in v2: - include display5 in the migration to Kconfig Alex Kiernan (2): Add BOOTCOUNT_BOOTLIMIT to set reboot limit Migrate bootlimit to Kconfig configs/brppt1_mmc_defconfig | 1 + configs/brppt1_nand_defconfig | 1 + configs/brppt1_spi_defconfig | 1 + configs/calimain_defconfig | 1 + configs/display5_defconfig | 1 + configs/draco_defconfig| 1 + configs/etamin_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge4_defconfig | 1 + configs/kmcoge5ne_defconfig| 1 + configs/kmcoge5un_defconfig| 1 + configs/kmeter1_defconfig | 1 + configs/kmlion1_defconfig | 1 + configs/kmnusa_defconfig | 1 + configs/kmopti2_defconfig | 1 + configs/kmsugp1_defconfig | 1 + configs/kmsupx5_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/kmtegr1_defconfig | 1 + configs/kmtepr2_defconfig | 1 + configs/kmvect1_defconfig | 1 + configs/mgcoge3un_defconfig| 1 + configs/mx53ppd_defconfig | 1 + configs/portl2_defconfig | 1 + configs/pxm2_defconfig | 1 + configs/rastaban_defconfig | 1 + configs/rut_defconfig | 1 + configs/suvd3_defconfig| 1 + configs/thuban_defconfig | 1 + configs/tuge1_defconfig| 1 + configs/tuxx1_defconfig| 1 + drivers/bootcount/Kconfig | 8 include/configs/brppt1.h | 2 -- include/configs/calimain.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 1 - include/configs/km/keymile-common.h| 1 - include/configs/mx53ppd.h | 1 - include/configs/siemens-am33x-common.h | 1 - include/env_default.h | 3 +++ 43 files changed, 45 insertions(+), 8 deletions(-) -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] buildman: Add support for environment delta in summary
When summarising the builds, add the -U option to emit delta lines for
the default environment built into U-Boot at each commit.
Signed-off-by: Alex Kiernan
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2:
- update buildman README to cover -U option
tools/buildman/README | 28 +
tools/buildman/builder.py | 128 +-
tools/buildman/cmdline.py | 2 +
tools/buildman/control.py | 3 +-
4 files changed, 145 insertions(+), 16 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index 6c43c546f8..76601902cb 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -1008,6 +1008,34 @@ variables. This avoids lots of useless output when
converting a CONFIG
option to Kconfig. To disable this behaviour, use --squash-config-y.
+Checking the environment
+
+
+When converting CONFIG options which manipulate the default environment,
+a common requirement is to check that the default environment has not
+changed due to the conversion. Buildman supports this with the -U option,
+used after a build. This shows differences in the default environment
+between one commit and the next.
+
+For example:
+
+$ buildman -b squash brppt1 -sU
+boards.cfg is up to date. Nothing to do.
+Summary of 2 commits for 3 boards (3 threads, 3 jobs per thread)
+01: Migrate bootlimit to Kconfig
+02: Squashed commit of the following:
+ c brppt1_mmc: altbootcmd=mmc dev 1; run mmcboot0; -> mmc dev 1; run mmcboot0
+ c brppt1_spi: altbootcmd=mmc dev 1; run mmcboot0; -> mmc dev 1; run mmcboot0
+ + brppt1_nand: altbootcmd=run usbscript
+ - brppt1_nand: altbootcmd=run usbscript
+(no errors to report)
+
+This shows that commit 2 modified the value of 'altbootcmd' for 'brppt1_mmc'
+and 'brppt1_spi', removing a trailing semicolon. 'brppt1_nand' gained an a
+value for 'altbootcmd', but lost one for ' altbootcmd'.
+
+The -U option uses the u-boot.env files which are produced by a build.
+
Other options
=
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 2ccdee02a3..a5a2ffdfdf 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -127,6 +127,15 @@ class Config:
val = val ^ hash(key) & hash(value)
return val
+class Environment:
+"""Holds information about environment variables for a board."""
+def __init__(self, target):
+self.target = target
+self.environment = {}
+
+def Add(self, key, value):
+self.environment[key] = value
+
class Builder:
"""Class for building U-Boot for a particular commit.
@@ -199,13 +208,17 @@ class Builder:
value is itself a dictionary:
key: config name
value: config value
+environment: Dictionary keyed by environment variable, Each
+ value is the value of environment variable.
"""
-def __init__(self, rc, err_lines, sizes, func_sizes, config):
+def __init__(self, rc, err_lines, sizes, func_sizes, config,
+ environment):
self.rc = rc
self.err_lines = err_lines
self.sizes = sizes
self.func_sizes = func_sizes
self.config = config
+self.environment = environment
def __init__(self, toolchains, base_dir, git_dir, num_threads, num_jobs,
gnu_make='make', checkout=True, show_unknown=True, step=1,
@@ -310,7 +323,8 @@ class Builder:
def SetDisplayOptions(self, show_errors=False, show_sizes=False,
show_detail=False, show_bloat=False,
- list_error_boards=False, show_config=False):
+ list_error_boards=False, show_config=False,
+ show_environment=False):
"""Setup display options for the builder.
show_errors: True to show summarised error/warning info
@@ -319,6 +333,7 @@ class Builder:
show_bloat: Show detail for each function
list_error_boards: Show the boards which caused each error/warning
show_config: Show config deltas
+show_environment: Show environment deltas
"""
self._show_errors = show_errors
self._show_sizes = show_sizes
@@ -326,6 +341,7 @@ class Builder:
self._show_bloat = show_bloat
self._list_error_boards = list_error_boards
self._show_config = show_config
+self._show_environment = show_environment
def _AddTimestamp(self):
"""Add a new timestamp to the list and record the build period.
@@ -609,8 +625,33 @@ class Builder:
config[key] = value
return config
+def _ProcessEnvironment(self, fname):
+"""Read in a uboot.env file
+
+This function reads in environment variables from a file.
+
+Args:
+fname: Filename to read
+
+
[U-Boot] [PATCH v3 1/2] buildman: Extract environment as part of each build
As we're building the boards, extract the default U-Boot environment to
uboot.env so we can interrogate it later.
Signed-off-by: Alex Kiernan
Reviewed-by: Simon Glass
---
Changes in v3:
- update tests for our usage of objcopy
Changes in v2:
- capture stderr/stdout so when the build fails we don't produce spurious
output as part of the build
tools/buildman/builderthread.py | 10 ++
tools/buildman/func_test.py | 5 +
2 files changed, 15 insertions(+)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 0efe80d945..c84ba6acf1 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -351,6 +351,16 @@ class BuilderThread(threading.Thread):
lines.append(size_result.stdout.splitlines()[1] + ' ' +
rodata_size)
+# Extract the environment from U-Boot and dump it out
+cmd = ['%sobjcopy' % self.toolchain.cross, '-O', 'binary',
+ '-j', '.rodata.default_environment',
+ 'env/built-in.o', 'uboot.env']
+command.RunPipe([cmd], capture=True,
+capture_stderr=True, cwd=result.out_dir,
+raise_on_error=False, env=env)
+ubootenv = os.path.join(result.out_dir, 'uboot.env')
+self.CopyFiles(result.out_dir, build_dir, '', ['uboot.env'])
+
# Write out the image sizes file. This is similar to the output
# of binutil's 'size' utility, but it omits the header line and
# adds an additional hex value at the end of each line for the
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index 9206fb299d..363db9d8ce 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -327,6 +327,9 @@ class TestFunctional(unittest.TestCase):
def _HandleCommandObjdump(self, args):
return command.CommandResult(return_code=0)
+def _HandleCommandObjcopy(self, args):
+return command.CommandResult(return_code=0)
+
def _HandleCommandSize(self, args):
return command.CommandResult(return_code=0)
@@ -359,6 +362,8 @@ class TestFunctional(unittest.TestCase):
return self._HandleCommandNm(args)
elif cmd.endswith('objdump'):
return self._HandleCommandObjdump(args)
+elif cmd.endswith('objcopy'):
+return self._HandleCommandObjcopy(args)
elif cmd.endswith( 'size'):
return self._HandleCommandSize(args)
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] buildman: Extract environment as part of each build
On Wed, May 30, 2018 at 8:18 PM Simon Glass wrote: > > On 30 May 2018 at 04:07, Alex Kiernan wrote: > > On Tue, May 29, 2018 at 5:24 PM Alex Kiernan wrote: > > > >> As we're building the boards, extract the default U-Boot environment to > >> uboot.env so we can interrogate it later. > > > >> Signed-off-by: Alex Kiernan > >> --- > > > >> Changes in v2: > >> - capture stderr/stdout so when the build fails we don't produce spurious > >>output as part of the build > > > >> tools/buildman/builderthread.py | 10 ++ > >> 1 file changed, 10 insertions(+) > > Reviewed-by: Simon Glass > > > > >> diff --git a/tools/buildman/builderthread.py > > b/tools/buildman/builderthread.py > >> index 0efe80d945..c84ba6acf1 100644 > >> --- a/tools/buildman/builderthread.py > >> +++ b/tools/buildman/builderthread.py > >> @@ -351,6 +351,16 @@ class BuilderThread(threading.Thread): > >> lines.append(size_result.stdout.splitlines()[1] + ' > > ' + > >>rodata_size) > > > >> +# Extract the environment from U-Boot and dump it out > >> +cmd = ['%sobjcopy' % self.toolchain.cross, '-O', 'binary', > >> + '-j', '.rodata.default_environment', > >> + 'env/built-in.o', 'uboot.env'] > >> +command.RunPipe([cmd], capture=True, > >> +capture_stderr=True, cwd=result.out_dir, > >> +raise_on_error=False, env=env) > >> +ubootenv = os.path.join(result.out_dir, 'uboot.env') > >> +self.CopyFiles(result.out_dir, build_dir, '', ['uboot.env']) > >> + > >> # Write out the image sizes file. This is similar to the > > output > >> # of binutil's 'size' utility, but it omits the header line > > and > >> # adds an additional hex value at the end of each line for > > the > > > > This is failing in Travis: > > > > https://travis-ci.org/akiernan/u-boot/jobs/385534243#L899 > > > For the patman failure, you could try this patch: > > http://patchwork.ozlabs.org/patch/914202/ > Thanks, that fixed half of it, the other was I needed to capture objcopy during functional tests; I really need to work out why make tests gives me out of the box failures so I can use it all the time. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] cmd: fpga: Reorder the arguments parsing code
Hi,
> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: Wednesday, May 30, 2018 8:37 PM
> To: Siva Durga Prasad Paladugu ; u-
> b...@lists.denx.de
> Cc: michal.si...@xilinx.com
> Subject: Re: [PATCH 1/3] cmd: fpga: Reorder the arguments parsing code
>
> On 29.5.2018 16:22, Siva Durga Prasad Paladugu wrote:
> > This patch modifies the arguments parsing code by parsing based on
> > requested operation for fpga loadfs and then parses the most
> > common/basic args for other fpga load commands. This makes it easy for
> > new command extensions or additions especially the commands with
> more
> > args.
> >
> > Signed-off-by: Siva Durga Prasad Paladugu
> >
> > ---
> > cmd/fpga.c | 31 +++
> > 1 file changed, 19 insertions(+), 12 deletions(-)
> >
> > diff --git a/cmd/fpga.c b/cmd/fpga.c
> > index 14ad4e5..0981826 100644
> > --- a/cmd/fpga.c
> > +++ b/cmd/fpga.c
> > @@ -60,15 +60,31 @@ int do_fpga(cmd_tbl_t *cmdtp, int flag, int argc,
> char *const argv[])
> > if (datastr)
> > fpga_data = (void *)simple_strtoul(datastr, NULL, 16);
> >
> > - switch (argc) {
> > + if (argc > 9 && argc < 3) {
>
> && is completely broken here.
> Also there is an option to use fpga and fpgadata variable and 2 args are
> valid too.
:-) Yes, thanks for catching it. Will correct and send next version.
Thanks,
Siva
>
> Thanks,
> Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] sunxi: fix eMMC stability issues on A64
eMMC seems to require new clocking mode and calibration on A64, otherwise it is pretty unstable on some boards (e.g. Pinebook) with some eMMCs. v2: - improve comment about calibration for eMMC on A64 - simplify ifdef-s around configuring delays v3: - fix fallout due to ifdef simplification in v2 Vasily Khoruzhick (2): sunxi-mmc: use new mode on A64 mmc: sunxi: run calibration on A64 arch/arm/include/asm/arch-sunxi/mmc.h | 6 +- arch/arm/mach-sunxi/Kconfig | 1 + drivers/mmc/sunxi_mmc.c | 15 +-- 3 files changed, 19 insertions(+), 3 deletions(-) -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] sunxi-mmc: use new mode on A64
That is necessary for using automatic calibration on A64 eMMC.
Signed-off-by: Vasily khoruzhick
---
arch/arm/mach-sunxi/Kconfig | 1 +
drivers/mmc/sunxi_mmc.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 66fb094ac5..8a35033d1f 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -257,6 +257,7 @@ config MACH_SUN50I
select SUNXI_GEN_SUN6I
select SUN6I_PRCM
select SUNXI_HIGH_SRAM
+ select MMC_SUNXI_HAS_NEW_MODE
select SUPPORT_SPL
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_32BIT
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index fe6d82c7b4..3bffb1b02e 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -165,10 +165,10 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv,
unsigned int hz)
}
if (new_mode) {
-#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
+#if defined(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && !defined(CONFIG_MACH_SUN50I)
val = CCM_MMC_CTRL_MODE_SEL_NEW;
- setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
#endif
+ setbits_le32(>reg->ntsr, SUNXI_MMC_NTSR_MODE_SEL_NEW);
} else {
val = CCM_MMC_CTRL_OCLK_DLY(oclk_dly) |
CCM_MMC_CTRL_SCLK_DLY(sclk_dly);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] mmc: sunxi: run calibration on A64
Along with using new mode it fixes eMMC instability on Pinebook
Signed-off-by: Vasily Khoruzhick
---
arch/arm/include/asm/arch-sunxi/mmc.h | 6 +-
drivers/mmc/sunxi_mmc.c | 11 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 1574b8e8fe..d6664a01f2 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -46,7 +46,9 @@ struct sunxi_mmc {
u32 cbda; /* 0x94 */
u32 res2[26];
#ifdef CONFIG_SUNXI_GEN_SUN6I
- u32 res3[64];
+ u32 res3[17];
+ u32 samp_dl;
+ u32 res4[46];
#endif
u32 fifo; /* 0x100 / 0x200 FIFO access address */
};
@@ -130,5 +132,7 @@ struct sunxi_mmc {
#define SUNXI_MMC_COMMON_CLK_GATE (1 << 16)
#define SUNXI_MMC_COMMON_RESET (1 << 18)
+#define SUNXI_MMC_CAL_DL_SW_EN (0x1 << 7)
+
struct mmc *sunxi_mmc_init(int sdc_no);
#endif /* _SUNXI_MMC_H */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 3bffb1b02e..bbfcf37b6c 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -223,6 +223,17 @@ static int mmc_config_clock(struct sunxi_mmc_priv *priv,
struct mmc *mmc)
rval &= ~SUNXI_MMC_CLK_DIVIDER_MASK;
writel(rval, >reg->clkcr);
+#ifdef CONFIG_MACH_SUN50I
+ /* A64 needs to run calibration on eMMC controller and we
+* have to set delay of zero before starting calibration.
+* Allwinner BSP driver sets a delay only in the case of
+* using HS400 which is not supported by mainline U-Boot or
+* Linux at the moment
+*/
+ if (priv->mmc_no == 2)
+ writel(SUNXI_MMC_CAL_DL_SW_EN, >reg->samp_dl);
+#endif
+
/* Re-enable Clock */
rval |= SUNXI_MMC_CLK_ENABLE;
writel(rval, >reg->clkcr);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] sunxi-mmc: use new mode on A64
On Tue, May 29, 2018 at 8:20 AM, Vasily Khoruzhick wrote: > On Mon, May 28, 2018 at 10:04 PM, Jagan Teki wrote: >> On Mon, May 28, 2018 at 11:13 PM, Vasily Khoruzhick >> wrote: >>> You need both patches in order for it to work. >>> >>> I tested these patches on Pinebook and Pine64 LTS, both were able to >>> boot from eMMC. What board are you using? >> >> Did you test BPI-M64? Here is the another board [1] where it failed > > I don't have BPI-M64. Could you enable debug in drivers/mmc/mmc.c to > check why it fails to select a mode? I found the issue. Will send v3 in a minute. > >> [1] https://patchwork.ozlabs.org/patch/921421/ >> >> Jagan. >> >> -- >> Jagan Teki >> Free Software Engineer | www.openedev.com >> U-Boot, Linux | Upstream Maintainer >> Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/3] mmc: dwmmc: socfpga: Add reset ctrl to driver
On Fri, May 25, 2018 at 7:16 PM, Tom Rini wrote:
> On Fri, May 25, 2018 at 10:45:53AM +0800, Ley Foon Tan wrote:
>> On Thu, May 24, 2018 at 8:39 PM, Tom Rini wrote:
>> > On Tue, May 08, 2018 at 11:19:24AM +0800, Ley Foon Tan wrote:
>> >
>> >> Add code to reset all reset signals as in mmc 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.
>> >>
>> >> Signed-off-by: Ley Foon Tan
>> >> Reviewed-by: Simon Glass
>> >> ---
>> >> drivers/mmc/socfpga_dw_mmc.c | 17 +
>> >> 1 files changed, 17 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
>> >> index fa0e449..eb7e64e 100644
>> >> --- a/drivers/mmc/socfpga_dw_mmc.c
>> >> +++ b/drivers/mmc/socfpga_dw_mmc.c
>> >> @@ -13,6 +13,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >>
>> >> DECLARE_GLOBAL_DATA_PTR;
>> >>
>> >> @@ -33,6 +34,20 @@ struct dwmci_socfpga_priv_data {
>> >> unsigned intsmplsel;
>> >> };
>> >>
>> >> +static void socfpga_dwmci_reset(struct udevice *dev)
>> >> +{
>> >> + struct reset_ctl_bulk reset_bulk;
>> >> + int ret;
>> >> +
>> >> + ret = reset_get_bulk(dev, _bulk);
>> >> + if (ret) {
>> >> + dev_warn(dev, "Can't get reset: %d\n", ret);
>> >> + return;
>> >> + }
>> >> +
>> >> + reset_deassert_bulk(_bulk);
>> >> +}
>> >
>> > The driver doesn't depend on DM_RESET and this code hunk doesn't either
>> > so it fails to build on a number of platforms. This type of comment
>> > applies to the whole series, and may be fixed differently in different
>> > cases (it might be OK to enforce DM_RESET for this driver, but not for
>> > the ns16550 driver).
>> >
>> > --
>> > Tom
>> >
>> include/reset.h has the DM_RESET wrapper, so it will not cause the
>> compilation error if the CONFIG_DM_RESET is disabled.
>>
>> I have tried compile the uboot with CONFIG_DM_RESET disabled,
>> compilation is fine.
>
> This whole series causes a good percent of the world to fail to link, so
> something is off about the wrappers or use of them. See:
> https://travis-ci.org/trini/u-boot/jobs/382783645
>
This build is happened in SPL build, when CONF_DM_RESET is enabled,
but CONFIG_SPL_RESET_SUPPORT is disabled.
So, adding #ifdef CONFIG_DM_RESET checking in these peripherals also
can't resolve the compilation error.
Two possible fix below, or you have better suggestion.
(1) select SPL_RESET_SUPPORT when DM_RESET is enabled.
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 33c39b7..b43cd89 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -3,6 +3,7 @@ menu "Reset Controller Support"
config DM_RESET
bool "Enable reset controllers using Driver Model"
depends on DM && OF_CONTROL
+ select SPL_RESET_SUPPORT
help
(2) Add CONFIG_SPL_RESET_SUPPORT checking in reset.h file
diff --git a/include/reset.h b/include/reset.h
index 201bafc..0ac0a47 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -77,7 +77,8 @@ struct reset_ctl_bulk {
unsigned int count;
};
-#ifdef CONFIG_DM_RESET
+#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_DM_RESET)) ||\
+(defined(CONFIG_SPL_RESET_SUPPORT) && defined(CONFIG_DM_RESET))
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Wed, May 30, 2018 at 11:38:37PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > thanks, > Jagan. > > The following changes since commit 31dd8efeb661c8db9175a09cf2bab090906a: > > usb: composite convert __set_bit to generic_set_bit (2018-05-15 21:44:05 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-spi.git master > > for you to fetch changes up to a2569f12f0efaad2b1e0754a19f373275562f91e: > > sf: Add Macronix MX25U25635F ID (2018-05-29 10:05:52 +0530) > 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] Uboot send pull request
On Wed, May 30, 2018 at 04:33:14PM +0800, ub...@andestech.com wrote: > Hi Tom, > > Please pull the following patch from u-boot-riscv into your tree. > Thanks! > > The following changes since commit c3c863880479edeb5b08226e622d13c91326e4a7: > > add FIT data-position & data-offset property support (2018-05-26 18:19:19 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-riscv.git > > for you to fetch changes up to 6ffea11b89099d72029bc644f7664736ee7ca667: > > travis.yml: Support RISC-V 64-bit (2018-05-30 16:21:30 +0800) > 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] x86: Add 64-bit setjmp/longjmp implementation
Add setjmp/longjmp functions for x86_64,
based on existing 32-bit implementation.
Signed-off-by: Ivan Gorinov
---
arch/x86/cpu/x86_64/setjmp.S | 56 +++
arch/x86/cpu/x86_64/setjmp.c | 19 ---
arch/x86/include/asm/setjmp.h | 17 +
3 files changed, 73 insertions(+), 19 deletions(-)
create mode 100644 arch/x86/cpu/x86_64/setjmp.S
delete mode 100644 arch/x86/cpu/x86_64/setjmp.c
diff --git a/arch/x86/cpu/x86_64/setjmp.S b/arch/x86/cpu/x86_64/setjmp.S
new file mode 100644
index 000..e10ee49
--- /dev/null
+++ b/arch/x86/cpu/x86_64/setjmp.S
@@ -0,0 +1,56 @@
+/*
+ * Based on arch/x86/cpu/i386/setjmp.S by H. Peter Anvin
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+/*
+ * The jmp_buf is assumed to contain the following, in order:
+ *
+ * %rsp
+ * %rbp
+ * %rbx
+ * %r12
+ * %r13
+ * %r14
+ * %r15
+ */
+
+.text
+.align 8
+.globl setjmp
+.type setjmp, @function
+
+setjmp:
+ pop %rcx
+ movq%rcx, (%rdi)/* Return address */
+ movq%rsp, 8 (%rdi) /* Post-return %rsp! */
+ movq%rbp, 16 (%rdi)
+ movq%rbx, 24 (%rdi)
+ movq%r12, 32 (%rdi)
+ movq%r13, 40 (%rdi)
+ movq%r14, 48 (%rdi)
+ movq%r15, 56 (%rdi)
+ xorq%rax, %rax /* Return value */
+ jmpq*%rcx
+
+/* Provide function size if needed */
+.size setjmp, .-setjmp
+
+.align 8
+.globl longjmp
+.type longjmp, @function
+
+longjmp:
+ movq32 (%rdi), %r12
+ movq40 (%rdi), %r13
+ movq48 (%rdi), %r14
+ movq56 (%rdi), %r15
+ movq16 (%rdi), %rbp
+ movq24 (%rdi), %rbx
+ movq8 (%rdi), %rsp
+ movq(%rdi), %rcx
+ movq%rsi, %rdi
+ jmpq*%rcx
+
+ .size longjmp, .-longjmp
diff --git a/arch/x86/cpu/x86_64/setjmp.c b/arch/x86/cpu/x86_64/setjmp.c
deleted file mode 100644
index 5d4a74a..000
--- a/arch/x86/cpu/x86_64/setjmp.c
+++ /dev/null
@@ -1,19 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2016 Google, Inc
- */
-
-#include
-#include
-
-int setjmp(struct jmp_buf_data *jmp_buf)
-{
- printf("WARNING: setjmp() is not supported\n");
-
- return 0;
-}
-
-void longjmp(struct jmp_buf_data *jmp_buf, int val)
-{
- printf("WARNING: longjmp() is not supported\n");
-}
diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h
index f25975f..49c36c1 100644
--- a/arch/x86/include/asm/setjmp.h
+++ b/arch/x86/include/asm/setjmp.h
@@ -8,6 +8,21 @@
#ifndef __setjmp_h
#define __setjmp_h
+#ifdef CONFIG_X86_64
+
+struct jmp_buf_data {
+ unsigned long __rip;
+ unsigned long __rsp;
+ unsigned long __rbp;
+ unsigned long __rbx;
+ unsigned long __r12;
+ unsigned long __r13;
+ unsigned long __r14;
+ unsigned long __r15;
+};
+
+#else
+
struct jmp_buf_data {
unsigned int __ebx;
unsigned int __esp;
@@ -17,6 +32,8 @@ struct jmp_buf_data {
unsigned int __eip;
};
+#endif
+
int setjmp(struct jmp_buf_data *jmp_buf);
void longjmp(struct jmp_buf_data *jmp_buf, int val);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] x86: use EFI calling convention for efi_main on x86_64
Save efi_main() arguments in the startup code on x86_64;
use EFI calling convention for _relocate() on x86_64;
remove unused _relocate() arguments;
consistently use EFI calling convention for efi_main() everywhere.
Signed-off-by: Ivan Gorinov
---
arch/x86/lib/crt0_x86_64_efi.S | 21 ++---
arch/x86/lib/reloc_x86_64_efi.c | 3 +--
lib/efi/efi_app.c | 3 ++-
lib/efi/efi_stub.c | 3 ++-
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/lib/crt0_x86_64_efi.S b/arch/x86/lib/crt0_x86_64_efi.S
index 989799f..3abb5e3 100644
--- a/arch/x86/lib/crt0_x86_64_efi.S
+++ b/arch/x86/lib/crt0_x86_64_efi.S
@@ -3,7 +3,7 @@
* crt0-efi-x86_64.S - x86_64 EFI startup code.
* Copyright (C) 1999 Hewlett-Packard Co.
* Contributed by David Mosberger .
- * Copyright (C) 2005 Intel Co.
+ * Copyright (C) 2005 Intel Corporation
* Contributed by Fenghua Yu .
*
* All rights reserved.
@@ -14,26 +14,25 @@
.globl _start
_start:
subq $8, %rsp
+
pushq %rcx
pushq %rdx
-0:
- lea image_base(%rip), %rdi
- lea _DYNAMIC(%rip), %rsi
+ lea image_base(%rip), %rcx
+ lea _DYNAMIC(%rip), %rdx
- popq %rcx
- popq %rdx
- pushq %rcx
- pushq %rdx
call _relocate
- popq %rdi
- popq %rsi
+ popq %rdx
+ popq %rcx
+
+ testq %rax, %rax
+ jnz _exit
call efi_main
+_exit:
addq $8, %rsp
-.exit:
ret
/*
diff --git a/arch/x86/lib/reloc_x86_64_efi.c b/arch/x86/lib/reloc_x86_64_efi.c
index 34c5b2e..59d6f8d 100644
--- a/arch/x86/lib/reloc_x86_64_efi.c
+++ b/arch/x86/lib/reloc_x86_64_efi.c
@@ -14,8 +14,7 @@
#include
#include
-efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image,
- struct efi_system_table *systab)
+efi_status_t EFIAPI _relocate(long ldbase, Elf64_Dyn *dyn)
{
long relsz = 0, relent = 0;
Elf64_Rel *rel = 0;
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index c828093..3eb8eeb 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -96,7 +96,8 @@ static void free_memory(struct efi_priv *priv)
* U-Boot. If it returns, EFI will continue. Another way to get back to EFI
* is via reset_cpu().
*/
-efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
+efi_status_t EFIAPI efi_main(efi_handle_t image,
+struct efi_system_table *sys_table)
{
struct efi_priv local_priv, *priv = _priv;
efi_status_t ret;
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index 3138739..399d16b 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -268,7 +268,8 @@ static void add_entry_addr(struct efi_priv *priv, enum
efi_entry_t type,
* This function is called by our EFI start-up code. It handles running
* U-Boot. If it returns, EFI will continue.
*/
-efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
+efi_status_t EFIAPI efi_main(efi_handle_t image,
+struct efi_system_table *sys_table)
{
struct efi_priv local_priv, *priv = _priv;
struct efi_boot_services *boot = sys_table->boottime;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] watchdog: driver support for layerscape
On 05/23/2018 12:52 AM, Xiaoliang Yang wrote: > Support watchdog driver for layerscape. If you want to use it, > please define CONFIG_IMX_WATCHDOG, CONFIG_HW_WATCHDOG, > define CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout. > > Signed-off-by: Xiaoliang Yang > --- > arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 10 ++ > drivers/watchdog/Makefile |2 +- > drivers/watchdog/imx_watchdog.c| 11 +++ > 3 files changed, 22 insertions(+), 1 deletions(-) > I see compiling error. For example ls2080ardb. Please make sure you test all boards. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fit signature: Add fallback of required keys
Validation of fit image configuration signatures does not seem to do a
"fall-back" mechanism as mentioned in doc/uImage.FIT/signature.txt.
The current constraints seem to only allow the following:
- skipping keys not marked "required" (not attempting to validate
with them at all)
- checking a key marked required, but if it does not pass the validation
entirely fails (no fall-back)
This patch keeps the non-required mechanism, however changes the
required key logic to check all keys until a key that can validate the
configuration is found. If none is found, an error is raised as before
and boot is halted.
Signed-off-by: Sam Voss
---
common/image-sig.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c
index 455f2b9629..be1c7bd808 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -446,6 +446,7 @@ int fit_config_verify_required_sigs(const void *fit, int
conf_noffset,
return 0;
}
+ /* Loop until either a valid key is found or we run out of keys */
fdt_for_each_subnode(noffset, sig_blob, sig_node) {
const char *required;
int ret;
@@ -455,14 +456,20 @@ int fit_config_verify_required_sigs(const void *fit, int
conf_noffset,
continue;
ret = fit_config_verify_sig(fit, conf_noffset, sig_blob,
noffset);
- if (ret) {
- printf("Failed to verify required signature '%s'\n",
- fit_get_name(sig_blob, noffset, NULL));
- return ret;
+
+ if (!ret) { // key verified successfully
+ return 0;
}
+
+ printf("Failed to verify required signature with key '%s'\n",
+ fit_get_name(sig_blob, noffset, NULL), ret);
}
- return 0;
+ printf("No keys were able to verify required signature '%s'\n",
+ sig_node);
+
+ return -1;
+
}
int fit_config_verify(const void *fit, int conf_noffset)
--
2.14.2.746.g8fb8a94
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/6] iotrace: move record definitons to header file
The header definitions are needed for reading
record information in cmd/iotrace.c
Signed-off-by: Ramon Fried
Reviewed-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
common/iotrace.c | 27 ---
include/iotrace.h | 28
2 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/common/iotrace.c b/common/iotrace.c
index 2f03a6082e..83691b1dba 100644
--- a/common/iotrace.c
+++ b/common/iotrace.c
@@ -11,33 +11,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* Support up to the machine word length for now */
-typedef ulong iovalue_t;
-
-enum iotrace_flags {
- IOT_8 = 0,
- IOT_16,
- IOT_32,
-
- IOT_READ = 0 << 3,
- IOT_WRITE = 1 << 3,
-};
-
-/**
- * struct iotrace_record - Holds a single I/O trace record
- *
- * @flags: I/O access type
- * @timestamp: Timestamp of access
- * @addr: Address of access
- * @value: Value written or read
- */
-struct iotrace_record {
- enum iotrace_flags flags;
- u64 timestamp;
- phys_addr_t addr;
- iovalue_t value;
-};
-
/**
* struct iotrace - current trace status and checksum
*
diff --git a/include/iotrace.h b/include/iotrace.h
index 1efb117343..b6e006ced0 100644
--- a/include/iotrace.h
+++ b/include/iotrace.h
@@ -7,6 +7,34 @@
#define __IOTRACE_H
#include
+#include
+
+/* Support up to the machine word length for now */
+typedef ulong iovalue_t;
+
+enum iotrace_flags {
+ IOT_8 = 0,
+ IOT_16,
+ IOT_32,
+
+ IOT_READ = 0 << 3,
+ IOT_WRITE = 1 << 3,
+};
+
+/**
+ * struct iotrace_record - Holds a single I/O trace record
+ *
+ * @flags: I/O access type
+ * @timestamp: Timestamp of access
+ * @addr: Address of access
+ * @value: Value written or read
+ */
+struct iotrace_record {
+ enum iotrace_flags flags;
+ u64 timestamp;
+ phys_addr_t addr;
+ iovalue_t value;
+};
/*
* This file is designed to be included in arch//include/asm/io.h.
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/6] cmd: iotrace: add dump trace command
Add dump trace command which dump all trace
buffer content in a much more readable fashion
than md.
Signed-off-by: Ramon Fried
Reviewed-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
cmd/iotrace.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/cmd/iotrace.c b/cmd/iotrace.c
index 601b8c8e32..f50a3c3a1a 100644
--- a/cmd/iotrace.c
+++ b/cmd/iotrace.c
@@ -24,6 +24,36 @@ static void do_print_stats(void)
printf("CRC32: %08lx\n", (ulong)iotrace_get_checksum());
}
+static void do_print_trace(void)
+{
+ ulong start, size, offset, count;
+
+ struct iotrace_record *cur_record;
+
+ iotrace_get_buffer(, , , );
+
+ if (!start || !size || !count)
+ return;
+
+ printf("Timestamp Value Address\n");
+
+ cur_record = (struct iotrace_record *)start;
+ for (int i = 0; i < count; i++) {
+ if (cur_record->flags & IOT_WRITE)
+ printf("%08llu: 0x%08lx --> 0x%08lx\n",
+ cur_record->timestamp,
+ cur_record->value,
+ cur_record->addr);
+ else
+ printf("%08llu: 0x%08lx <-- 0x%08lx\n",
+ cur_record->timestamp,
+ cur_record->value,
+ cur_record->addr);
+
+ cur_record++;
+ }
+}
+
static int do_set_buffer(int argc, char * const argv[])
{
ulong addr = 0, size = 0;
@@ -76,6 +106,9 @@ int do_iotrace(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
case 's':
do_print_stats();
break;
+ case 'd':
+ do_print_trace();
+ break;
default:
return CMD_RET_USAGE;
}
@@ -90,5 +123,6 @@ U_BOOT_CMD(
"iotrace buffer- set iotrace buffer\n"
"iotrace limit - set iotrace region limit\n"
"iotrace pause- pause tracing\n"
- "iotrace resume - resume tracing"
+ "iotrace resume - resume tracing\n"
+ "iotrace dump - dump iotrace buffer"
);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 6/6] iotrace: fix behaviour when buffer is full
Don't continue updating the offset when buffer is full.
When the buffer size exhausts and there's no space left to write
warn the user and update only the needed size and not both the
offset and needed size.
Add needed buffer size information in the iotrace command.
Signed-off-by: Ramon Fried
---
Changes in v4: None
Changes in v3:
- fixed wrong usage of WARN_ONCE
Changes in v2:
- introduced needed_size to notify the user about the needed buffer size.
Changes in v1: None
cmd/iotrace.c | 11 ++-
common/iotrace.c | 13 +++--
include/iotrace.h | 5 +++--
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/cmd/iotrace.c b/cmd/iotrace.c
index f50a3c3a1a..fc77f63de6 100644
--- a/cmd/iotrace.c
+++ b/cmd/iotrace.c
@@ -9,12 +9,13 @@
static void do_print_stats(void)
{
- ulong start, size, offset, count;
+ ulong start, size, needed_size, offset, count;
printf("iotrace is %sabled\n", iotrace_get_enabled() ? "en" : "dis");
- iotrace_get_buffer(, , , );
+ iotrace_get_buffer(, , _size, , );
printf("Start: %08lx\n", start);
- printf("Size: %08lx\n", size);
+ printf("Actual Size: %08lx\n", size);
+ printf("Needed Size: %08lx\n", needed_size);
iotrace_get_region(, );
printf("Region: %08lx\n", start);
printf("Size: %08lx\n", size);
@@ -26,11 +27,11 @@ static void do_print_stats(void)
static void do_print_trace(void)
{
- ulong start, size, offset, count;
+ ulong start, size, needed_size, offset, count;
struct iotrace_record *cur_record;
- iotrace_get_buffer(, , , );
+ iotrace_get_buffer(, , _size, , );
if (!start || !size || !count)
return;
diff --git a/common/iotrace.c b/common/iotrace.c
index 83691b1dba..49bee3c92a 100644
--- a/common/iotrace.c
+++ b/common/iotrace.c
@@ -15,7 +15,8 @@ DECLARE_GLOBAL_DATA_PTR;
* struct iotrace - current trace status and checksum
*
* @start: Start address of iotrace buffer
- * @size: Size of iotrace buffer in bytes
+ * @size: Actual size of iotrace buffer in bytes
+ * @needed_size: Needed of iotrace buffer in bytes
* @offset:Current write offset into iotrace buffer
* @region_start: Address of IO region to trace
* @region_size: Size of region to trace. if 0 will trace all address space
@@ -25,6 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
static struct iotrace {
ulong start;
ulong size;
+ ulong needed_size;
ulong offset;
ulong region_start;
ulong region_size;
@@ -55,7 +57,12 @@ static void add_record(int flags, const void *ptr, ulong
value)
rec = (struct iotrace_record *)map_sysmem(
iotrace.start + iotrace.offset,
sizeof(value));
+ } else {
+ WARN_ONCE(1, "WARNING: iotrace buffer exhausted, please check
needed length using \"iotrace stats\"\n");
+ iotrace.needed_size += sizeof(struct iotrace_record);
+ return;
}
+
rec->timestamp = timer_get_us();
rec->flags = flags;
rec->addr = map_to_sysmem(ptr);
@@ -65,6 +72,7 @@ static void add_record(int flags, const void *ptr, ulong
value)
iotrace.crc32 = crc32(iotrace.crc32, (unsigned char *)rec,
sizeof(*rec));
+ iotrace.needed_size += sizeof(struct iotrace_record);
iotrace.offset += sizeof(struct iotrace_record);
}
@@ -162,10 +170,11 @@ void iotrace_set_buffer(ulong start, ulong size)
iotrace.crc32 = 0;
}
-void iotrace_get_buffer(ulong *start, ulong *size, ulong *offset, ulong *count)
+void iotrace_get_buffer(ulong *start, ulong *size, ulong *needed_size, ulong
*offset, ulong *count)
{
*start = iotrace.start;
*size = iotrace.size;
+ *needed_size = iotrace.needed_size;
*offset = iotrace.offset;
*count = iotrace.offset / sizeof(struct iotrace_record);
}
diff --git a/include/iotrace.h b/include/iotrace.h
index b6e006ced0..ad7092e97d 100644
--- a/include/iotrace.h
+++ b/include/iotrace.h
@@ -146,11 +146,12 @@ void iotrace_set_buffer(ulong start, ulong size);
* iotrace_get_buffer() - Get buffer information
*
* @start: Returns start address of buffer
- * @size: Returns size of buffer in bytes
+ * @size: Returns actual size of buffer in bytes
+ * @needed_size: Returns needed size of buffer in bytes
* @offset: Returns the byte offset where the next output trace record will
* @count: Returns the number of trace records recorded
* be written (or would be if the buffer was large enough)
*/
-void iotrace_get_buffer(ulong *start, ulong *size, ulong *offset, ulong
*count);
+void iotrace_get_buffer(ulong *start, ulong *size, ulong *needed_size, ulong
*offset, ulong *count);
#endif /* __IOTRACE_H */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH v4 2/6] iotrace: add IO region limit
When dealing with a lot of IO regions, sometimes
it makes sense only to trace a specific one.
This patch adds support for region limits.
If region is not set, the iotrace works the same as it was.
If region is set, the iotrace only logs io operation that falls
in the defined region.
Signed-off-by: Ramon Fried
Reviewed-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1: None
common/iotrace.c | 27 +++
include/iotrace.h | 24
2 files changed, 51 insertions(+)
diff --git a/common/iotrace.c b/common/iotrace.c
index b16b0d612d..f39885663a 100644
--- a/common/iotrace.c
+++ b/common/iotrace.c
@@ -42,6 +42,8 @@ struct iotrace_record {
* @start: Start address of iotrace buffer
* @size: Size of iotrace buffer in bytes
* @offset:Current write offset into iotrace buffer
+ * @region_start: Address of IO region to trace
+ * @region_size: Size of region to trace. if 0 will trace all address space
* @crc32: Current value of CRC chceksum of trace records
* @enabled: true if enabled, false if disabled
*/
@@ -49,6 +51,8 @@ static struct iotrace {
ulong start;
ulong size;
ulong offset;
+ ulong region_start;
+ ulong region_size;
u32 crc32;
bool enabled;
} iotrace;
@@ -66,6 +70,11 @@ static void add_record(int flags, const void *ptr, ulong
value)
if (!(gd->flags & GD_FLG_RELOC) || !iotrace.enabled)
return;
+ if (iotrace.region_size)
+ if ((ulong)ptr < iotrace.region_start ||
+ (ulong)ptr > iotrace.region_start + iotrace.region_size)
+ return;
+
/* Store it if there is room */
if (iotrace.offset + sizeof(*rec) < iotrace.size) {
rec = (struct iotrace_record *)map_sysmem(
@@ -142,6 +151,24 @@ u32 iotrace_get_checksum(void)
return iotrace.crc32;
}
+void iotrace_set_region(ulong start, ulong size)
+{
+ iotrace.region_start = start;
+ iotrace.region_size = size;
+}
+
+void iotrace_reset_region(void)
+{
+ iotrace.region_start = 0;
+ iotrace.region_size = 0;
+}
+
+void iotrace_get_region(ulong *start, ulong *size)
+{
+ *start = iotrace.region_start;
+ *size = iotrace.region_size;
+}
+
void iotrace_set_enabled(int enable)
{
iotrace.enabled = enable;
diff --git a/include/iotrace.h b/include/iotrace.h
index 9fe5733f87..1efb117343 100644
--- a/include/iotrace.h
+++ b/include/iotrace.h
@@ -58,6 +58,30 @@ void iotrace_reset_checksum(void);
*/
u32 iotrace_get_checksum(void);
+/**
+ * iotrace_set_region() - Set whether iotrace is limited to a specific
+ * io region.
+ *
+ * Defines the address and size of the limited region.
+ *
+ * @start: address of the beginning of the region
+ * @size: size of the region in bytes.
+ */
+void iotrace_set_region(ulong start, ulong size);
+
+/**
+ * iotrace_reset_region() - Reset the region limit
+ */
+void iotrace_reset_region(void);
+
+/**
+ * iotrace_get_region() - Get region information
+ *
+ * @start: Returns start address of region
+ * @size: Returns size of region in bytes
+ */
+void iotrace_get_region(ulong *start, ulong *size);
+
/**
* iotrace_set_enabled() - Set whether iotracing is enabled or not
*
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/6] common: iotrace: add timestamp to iotrace records
Add timestamp to each iotrace record to aid in debugging
of IO timing access bugs.
Signed-off-by: Ramon Fried
Reviewed-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1:
- Change timestamp function to get_ticks()
common/iotrace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/iotrace.c b/common/iotrace.c
index f39885663a..2f03a6082e 100644
--- a/common/iotrace.c
+++ b/common/iotrace.c
@@ -27,11 +27,13 @@ enum iotrace_flags {
* struct iotrace_record - Holds a single I/O trace record
*
* @flags: I/O access type
+ * @timestamp: Timestamp of access
* @addr: Address of access
* @value: Value written or read
*/
struct iotrace_record {
enum iotrace_flags flags;
+ u64 timestamp;
phys_addr_t addr;
iovalue_t value;
};
@@ -81,7 +83,7 @@ static void add_record(int flags, const void *ptr, ulong
value)
iotrace.start + iotrace.offset,
sizeof(value));
}
-
+ rec->timestamp = timer_get_us();
rec->flags = flags;
rec->addr = map_to_sysmem(ptr);
rec->value = value;
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/6] Iotrace improvements
These set of patches add few improvements to iotrace. * Region limiting - allows setting an address and size where only io operations that falls into that address are logged. * Timestamping - Timestamp every iotrace record with current timestamp * dumping - iotrace dump command for dumping all records from buffer in a readable fashion. In terms of backwards compatibility, the timestamp is not backward compatible as it changes the iotrace record. so if one developed an offline parsing tool it will be broken. I though of adding #ifdef specific for that, but eventually I didn't. Changes in v4: - Resend complete patchset with patman Changes in v3: - fixed wrong usage of WARN_ONCE Changes in v2: - introduced needed_size to notify the user about the needed buffer size. Changes in v1: - Change timestamp function to get_ticks() Ramon Fried (6): cmd: iotrace: add set region command iotrace: add IO region limit common: iotrace: add timestamp to iotrace records iotrace: move record definitons to header file cmd: iotrace: add dump trace command iotrace: fix behaviour when buffer is full cmd/iotrace.c | 63 ++--- common/iotrace.c | 65 +++ include/iotrace.h | 57 +++-- 3 files changed, 153 insertions(+), 32 deletions(-) -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/6] cmd: iotrace: add set region command
Signed-off-by: Ramon Fried
Reviewed-by: Simon Glass
---
Changes in v4:
- Resend complete patchset with patman
Changes in v3: None
Changes in v2: None
Changes in v1: None
cmd/iotrace.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/cmd/iotrace.c b/cmd/iotrace.c
index e496787e0d..601b8c8e32 100644
--- a/cmd/iotrace.c
+++ b/cmd/iotrace.c
@@ -15,6 +15,9 @@ static void do_print_stats(void)
iotrace_get_buffer(, , , );
printf("Start: %08lx\n", start);
printf("Size: %08lx\n", size);
+ iotrace_get_region(, );
+ printf("Region: %08lx\n", start);
+ printf("Size: %08lx\n", size);
printf("Offset: %08lx\n", offset);
printf("Output: %08lx\n", start + offset);
printf("Count: %08lx\n", count);
@@ -37,6 +40,22 @@ static int do_set_buffer(int argc, char * const argv[])
return 0;
}
+static int do_set_region(int argc, char * const argv[])
+{
+ ulong addr = 0, size = 0;
+
+ if (argc == 2) {
+ addr = simple_strtoul(*argv++, NULL, 16);
+ size = simple_strtoul(*argv++, NULL, 16);
+ } else if (argc != 0) {
+ return CMD_RET_USAGE;
+ }
+
+ iotrace_set_region(addr, size);
+
+ return 0;
+}
+
int do_iotrace(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
const char *cmd = argc < 2 ? NULL : argv[1];
@@ -46,6 +65,8 @@ int do_iotrace(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
switch (*cmd) {
case 'b':
return do_set_buffer(argc - 2, argv + 2);
+ case 'l':
+ return do_set_region(argc - 2, argv + 2);
case 'p':
iotrace_set_enabled(0);
break;
@@ -67,6 +88,7 @@ U_BOOT_CMD(
"iotrace utility commands",
"stats- display iotrace stats\n"
"iotrace buffer- set iotrace buffer\n"
+ "iotrace limit - set iotrace region limit\n"
"iotrace pause- pause tracing\n"
"iotrace resume - resume tracing"
);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] drivers; add DM_NO_OF Kconfig option
Hi Tom and Simon, thanks for the support. On Mon, May 28, 2018 at 08:59:21PM -0400, Tom Rini wrote: > On Sun, May 27, 2018 at 07:45:12PM -0600, Simon Glass wrote: > > +Tom > > > > Hi Angelo, > > > > On 27 May 2018 at 01:22, Angelo Dureghello wrote: > > > Hi Simon, > > > > > > On Sat, May 26, 2018 at 04:18:57PM -0600, Simon Glass wrote: > > >> Hi Angelo, > > >> > > >> On 3 May 2018 at 16:01, Angelo Dureghello wrote: > > >> > To be able to build spi driver with DM support, a new config > > >> > option has been introduced (DM_NO_OF) since m68k architecture > > >> > does not support fdt. > > >> > > > >> > --- > > >> > Changes from v1: > > >> > - split into 2 patches > > >> > > > >> > Signed-off-by: Angelo Dureghello > > >> > --- > > >> > arch/Kconfig | 1 + > > >> > drivers/core/Kconfig | 4 > > >> > drivers/spi/spi-uclass.c | 12 +++- > > >> > 3 files changed, 12 insertions(+), 5 deletions(-) > > >> > > > >> > > >> Is it possible to use SPL_OF_PLATDATA instead? > > >> > > > I have seen that setting, but my understanding is that > > > SPL_OF_PLATDATA ws made for a different purpose, and also, i > > > tried to use it, but cannot select it from menuconfig. > > > > > >> How come m68k cannot use device tree? > > >> > > > There was never any devicetree implementation, probably becouse it > > > is missing on Linux too. > > > > It is a real shame that we can't do better than that. > > > > I've added Tom in for comment as I'm not sure what is best here. > > Yeah, I think as sandbox shows, if/when we don't have to worry about > also Linux dts files, it's not a lot of work to populate up what's > required for just U-Boot, so long as we have the run-time space. And if > not, that's what OF_PLATDATA is for. > About SPL_OF_PLATDATA, do you think i can change it to a more generic OF_PLATDATA, or GENERIC_OF_PLATDATA not dependant from SPL (i am not using SPL) ? I also need to add "select SUPPORT_OF_CONTROL" for m68k arch. Let me know if the above is ok, otherwise i start to work for the devicetree option. > -- > Tom Regards, Angelo ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] Iotrace improvements
Ok, I'll check it out. Thanks! On Wed, May 30, 2018, 10:18 PM Simon Glass wrote: > Hi Ramon, > > On 28 May 2018 at 05:03, Ramon Fried wrote: > > These set of patches add few improvements to iotrace. > > * Region limiting - allows setting an address and size where only > > io operations that falls into > that address are > > logged. > > * Timestamping - Timestamp every iotrace record with current timestamp > > * dumping - iotrace dump command for dumping all records from buffer > > in a readable fashion. > > > > In terms of backwards compatibility, the timestamp is not backward > > compatible as it changes the iotrace record. so if one developed an > > offline parsing tool it will be broken. > > I though of adding #ifdef specific for that, but eventually I didn't. > > > > v2: > > * fixed printf format > > * added a fix when the buffer is full > > v3: > > * changed the "buffer full" scenario as > > recommended by Simon Glass. > > This fix is dependand on a sperate patch that introduces > > WARN_ONCE definition in bug.h ( > https://patchwork.ozlabs.org/patch/921391/) > > > > Ramon Fried (6): > > cmd: iotrace: add set region command > > iotrace: add IO region limit > > common: iotrace: add timestamp to iotrace records > > iotrace: move record definitons to header file > > cmd: iotrace: add dump trace command > > iotrace: fix behaviour when buffer is full > > > > cmd/iotrace.c | 63 ++--- > > common/iotrace.c | 65 +++ > > include/iotrace.h | 57 +++-- > > 3 files changed, 153 insertions(+), 32 deletions(-) > > It looks like your patch series is a bit broken as the version number > doesn't appear on the patches (e.g. 1/6), only on this cover letter. > > Can you fix that? You can use patman which will do all this automatically. > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] inappropriate PCI configuration on arm64 qemu?
+Tuomas
Hi Akashi,
On 28 May 2018 at 01:59, AKASHI Takahiro wrote:
> When I tried to add a SD card to qemu's virt machine (2.10.0) as,
> --
> -device sdhci-pci \
> -device sd-card,drive=my_sd \
> -drive if=none,id=my_sd,format=raw,file=/path/my/sd.img
> --
> u-boot doesn't configure a SDHCI controller properly and an attached
> device is never detected.
>
> Digging into the code, I found
> * reading BAR5 in dm_pciauto_setup_device() shows BAR5 is a 32-bit address,
> * pciauto_region_allocate() allocates a 64-bit address (0x80.ABCD.)
> to BAR5 as res->bus_lower is 0x80..
> * Upper 32-bit value is not written back to BAR5 because of !found_mem64
> (BAR5 is the last one and no succeeding BAR anyway.)
>
> On the other hand,
> * Qemu defines two PCI memory regions for MMIO:
> (from qemu's hw/arm/virt.c)
> --
> [VIRT_PCIE_MMIO] = { 0x1000, 0x2eff },
> [VIRT_PCIE_PIO] = { 0x3eff, 0x0001 },
> [VIRT_PCIE_ECAM] = { 0x3f00, 0x0100 },
> [VIRT_MEM] ={ 0x4000, RAMLIMIT_BYTES },
> /* Second PCIe window, 512GB wide at the 512GB boundary */
> [VIRT_PCIE_MMIO_HIGH] = { 0x80ULL, 0x80ULL },
> --
> * A PCI card is configured in decode_regions() so that
> 'hose' has only one entry per each type of memory regions.
> This behavior was introduced by Simon's patch:
> --
> commit 9526d83ac5a
> Author: Simon Glass
> Date: Thu Nov 19 20:26:58 2015 -0700
>
> dm: pci: Support decoding ranges with duplicate entries
> --
> * As a result, MMIO region (0x1000.-0x2eff.) is overwritten
> and MMIO_HIGH is the only one available at runtime.
>
> I believe that this behavior is the root cause of my issue, and
> by reverting the patch mentioned above, everything works fine.
>
> While I understand a concern mentioned in the commit message,
> there should be a better way to manage the case.
There was a series that changed things in this area. Can you take a look?
PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] malloc: Use malloc simple before malloc is fully initialized in memalign()
Hi Masahiro, On 28 May 2018 at 23:16, Masahiro Yamada wrote: > 2018-05-26 11:06 GMT+09:00 Simon Glass : >> +Masahiro >> >> On 25 May 2018 at 02:50, Ley Foon Tan wrote: >>> >>> On Fri, May 25, 2018 at 11:33 AM, Simon Glass wrote: >>> > Hi, >>> > >>> > On 24 May 2018 at 21:24, Ley Foon Tan wrote: >>> >> >>> >> On Thu, May 24, 2018 at 12:33 AM, Simon Glass wrote: >>> >> > Hi, >>> >> > >>> >> > On 23 May 2018 at 00:32, Ley Foon Tan wrote: >>> >> >> On Sat, May 19, 2018 at 10:37 PM, Simon Glass >>> >> >> wrote: >>> >> >>> Hi Ley, >>> >> >>> >>> >> >>> On 18 May 2018 at 04:03, Ley Foon Tan wrote: >>> >> Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT >>> >> flag and use >>> >> malloc_simple if GD_FLG_FULL_MALLOC_INIT is unset. Adjust the >>> >> malloc bytes >>> >> to align with the requested alignment. >>> >> >>> >> The original memalign() function will access mchunkptr struct to >>> >> adjust the >>> >> alignment if there is misalignment happen, but mchunkptr struct is >>> >> not being >>> >> initialized before full malloc is initialized. This cause the >>> >> system crash. >>> >> >>> >> Signed-off-by: Ley Foon Tan >>> >> --- >>> >> common/dlmalloc.c |7 +++ >>> >> 1 files changed, 7 insertions(+), 0 deletions(-) >>> >> >>> >> diff --git a/common/dlmalloc.c b/common/dlmalloc.c >>> >> index b395eef..edaad29 100644 >>> >> --- a/common/dlmalloc.c >>> >> +++ b/common/dlmalloc.c >>> >> @@ -1891,6 +1891,13 @@ Void_t* mEMALIGn(alignment, bytes) size_t >>> >> alignment; size_t bytes; >>> >> >>> >> if ((long)bytes < 0) return NULL; >>> >> >>> >> +#if CONFIG_VAL(SYS_MALLOC_F_LEN) >>> >> >>> >>> >> >>> How about: >>> >> >>> >>> >> >>> if (IS_ENABLED(CONFIG_SYS_MALLOC_F)) >>> >> >> >>> >> >> I think this is the reason it uses #if CONFIG_VAL(SYS_MALLOC_F_LEN), >>> >> >> same for malloc(). >>> >> >> >>> >> >> "spl: make SPL and normal u-boot stage use independent >>> >> >> SYS_MALLOC_F_LEN" >>> >> >> >>> >> >> http://git.denx.de/?p=u-boot.git;a=commit;h=f1896c45cb2f7d8dbed27e784a6459a129fc0762 >>> >> > >>> >> > So how about >>> >> > >>> >> > if (CONFIG_IS_ENABLED(SYS_MALLOC_F_LEN) >>> >> > >>> >> > Or you could use #if if you need to >>> >> >>> >> Tested both #if (CONFIG_IS_ENABLED(SYS_MALLOC_F_LEN)) and if >>> >> (CONFIG_IS_ENABLED(SYS_MALLOC_F_LEN)), both are not working. >>> > >>> > Sorry I mean >>> > >>> > CONFIG_IS_ENABLED(SYS_MALLOC_F) >>> > >>> > That tells you whether the feature is enabled in U-Boot or SPL. >>> >>> #if CONFIG_IS_ENABLED(SYS_MALLOC_F) if not working in SPL build. >>> CONFIG_IS_ENABLED() expects config with "y" or "m", but SPL config is >>> with "1". >> >> That seems very strange, since it defeats the purpose of the macro. >> >> Masahiro, do you know what going on here? > > > CONFIG_IS_ENABLED(SYS_MALLOC_F) evaluates > SYS_MALLOC_F, or SPL_SYS_MALLOC_F > depending on which image is being built. > > > I see SPL_SYS_MALLOC_F_LEN in Kconfig, > but do not see SPL_SYS_MALLOC_F at all. OK, well that explains the problem, thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 35/41] dm: core: device: enable power domain in probe
On 28 May 2018 at 06:25, Peng Fan wrote: > Enable power domain associated with the device when probe. > > Signed-off-by: Peng Fan > Cc: Simon Glass > --- > drivers/core/device.c | 7 +++ > 1 file changed, 7 insertions(+) > How is this feature tested at present? Can you add something to the power-domain test? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 34/41] power-domain: add dummy functions when CONFIG_POWER_DOMAIN not defined
On 28 May 2018 at 06:25, Peng Fan wrote: > Add dummy functions when CONFIG_POWER_DOMAIN not defined. > > Signed-off-by: Peng Fan > Cc: Simon Glass > --- > include/power-domain.h | 37 + > 1 file changed, 37 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 36/41] drivers: regulator: fixed: add off-on-delay-us
On 28 May 2018 at 06:25, Peng Fan wrote: > Add off-on-delay-us for fixed regulator. > > Signed-off-by: Peng Fan > Cc: Simon Glass > --- > drivers/power/regulator/fixed.c | 6 ++ > 1 file changed, 6 insertions(+) Reviewed-by: Simon Glass Can you also please add the DT binding file for this? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 33/41] power: Add PD device lookup interface to power domain uclass
Hi Peng, On 28 May 2018 at 06:25, Peng Fan wrote: > Add power_domain_lookup_name interface to power domain uclass to find > a power domain device by its DTB node name, not using its associated > client device. > > Through this interface, we can operate the power domain devices directly. > This is needed for non-DM drivers. > > Signed-off-by: Ye Li > Signed-off-by: Peng Fan > Cc: Simon Glass > --- > drivers/power/domain/power-domain-uclass.c | 42 > ++ > include/power-domain.h | 15 +++ > 2 files changed, 57 insertions(+) > Please add a test to test/dm/power-domain.c for your newe function. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] regmap: Separate memory-based operations
Hi Alexey, On 29 May 2018 at 13:16, Alexey Brodkin wrote: > Hi Simon, > > On Fri, 2018-05-25 at 20:07 -0600, Simon Glass wrote: >> Hi Alexey, >> >> On 25 May 2018 at 03:45, Alexey Brodkin wrote: >> > Hi Simon, >> > >> > On Thu, 2018-05-24 at 20:42 -0600, Simon Glass wrote: >> > > Hi Alexey, > > [snip] > >> > > When we want to use a particular I2C bus via regmap, we could bind the >> > > I2C -> regmap driver as a child of the I2C bus driver. >> > >> > I guess that will require us to do corresponding changes in Device Tree >> > descriptions, right? And that will deviate those .dts-es from their kernel >> > counterparts [if they exist for a particular board]. >> >> Actually I don't think so. You can have a helper function that you >> call to bind the regmap to an I2C device, for example. That can be >> called from code, without needing any DT changes. > > So this helper function will be regmap_init_i2c(), right? > >> My objection is mostly to using function pointers to call what look >> like driver functions. The design of DM in U-Boot is supposed to >> support child drivers for exactly this purpose. So we should try to >> use it, unless we hit some terrible design flaw. > > Ok that makes sense. As you proposed we'll have new UCLASS like > UCLASS_SIMPLE_REG and within that class we'll have drivers that access > registers via memory, i2c, spi etc... that's quite clear. > > But what is not very obvious for me is that part about binding with > "master" devices. Could you please sketch something so I may get a better > picture? Yes that sounds right. Basically this interface defines the operations in your UCLASS_SIMPLE_REG uclass: + int (*reg_read)(struct regmap *map, uint reg, uint *val); + int (*reg_write)(struct regmap *map, uint reg, uint val); Then you have different drivers that implement that uclass as you say (i2c, spi). The I2C simple_reg driver will require an I2C device to work with. This can be its parent device. To bind the device you'll need to call a function like: int simple_reg_i2c_bind(struct udevice *i2c_dev, struct udevice **devp) which calls device_bind(), or similar, to bind a new device as a child of i2c_dev, with uclass UCLASS_SIMPLE_REG. Then the device can be probed, The I2C simple_reg driver can implement the reg_read() method by calling dm_i2c_read() on its parent. You can put simple_reg_i2c_bind() in the regmap code perhaps, or maybe there is a better place for it. You should make sure there is a sandbox test which creates a device and checks that it can read and write a few registers. Does that explain it? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] buildman: Extract environment as part of each build
On 30 May 2018 at 04:07, Alex Kiernan wrote: > On Tue, May 29, 2018 at 5:24 PM Alex Kiernan wrote: > >> As we're building the boards, extract the default U-Boot environment to >> uboot.env so we can interrogate it later. > >> Signed-off-by: Alex Kiernan >> --- > >> Changes in v2: >> - capture stderr/stdout so when the build fails we don't produce spurious >>output as part of the build > >> tools/buildman/builderthread.py | 10 ++ >> 1 file changed, 10 insertions(+) Reviewed-by: Simon Glass > >> diff --git a/tools/buildman/builderthread.py > b/tools/buildman/builderthread.py >> index 0efe80d945..c84ba6acf1 100644 >> --- a/tools/buildman/builderthread.py >> +++ b/tools/buildman/builderthread.py >> @@ -351,6 +351,16 @@ class BuilderThread(threading.Thread): >> lines.append(size_result.stdout.splitlines()[1] + ' > ' + >>rodata_size) > >> +# Extract the environment from U-Boot and dump it out >> +cmd = ['%sobjcopy' % self.toolchain.cross, '-O', 'binary', >> + '-j', '.rodata.default_environment', >> + 'env/built-in.o', 'uboot.env'] >> +command.RunPipe([cmd], capture=True, >> +capture_stderr=True, cwd=result.out_dir, >> +raise_on_error=False, env=env) >> +ubootenv = os.path.join(result.out_dir, 'uboot.env') >> +self.CopyFiles(result.out_dir, build_dir, '', ['uboot.env']) >> + >> # Write out the image sizes file. This is similar to the > output >> # of binutil's 'size' utility, but it omits the header line > and >> # adds an additional hex value at the end of each line for > the > > This is failing in Travis: > > https://travis-ci.org/akiernan/u-boot/jobs/385534243#L899 For the patman failure, you could try this patch: http://patchwork.ozlabs.org/patch/914202/ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 38/41] log: include command header file
On 28 May 2018 at 06:25, Peng Fan wrote: > cmd_tbl_t is defined in command.h, so include it in log.h > > Signed-off-by: Peng Fan > Cc: Simon Glass > --- > include/log.h | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass Better I think to get rid of the cmd_tbl_t typedef and forward-declare the struct in log.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] Iotrace improvements
Hi Ramon, On 28 May 2018 at 05:03, Ramon Fried wrote: > These set of patches add few improvements to iotrace. > * Region limiting - allows setting an address and size where only > io operations that falls into that > address are > logged. > * Timestamping - Timestamp every iotrace record with current timestamp > * dumping - iotrace dump command for dumping all records from buffer > in a readable fashion. > > In terms of backwards compatibility, the timestamp is not backward > compatible as it changes the iotrace record. so if one developed an > offline parsing tool it will be broken. > I though of adding #ifdef specific for that, but eventually I didn't. > > v2: > * fixed printf format > * added a fix when the buffer is full > v3: > * changed the "buffer full" scenario as > recommended by Simon Glass. > This fix is dependand on a sperate patch that introduces > WARN_ONCE definition in bug.h > (https://patchwork.ozlabs.org/patch/921391/) > > Ramon Fried (6): > cmd: iotrace: add set region command > iotrace: add IO region limit > common: iotrace: add timestamp to iotrace records > iotrace: move record definitons to header file > cmd: iotrace: add dump trace command > iotrace: fix behaviour when buffer is full > > cmd/iotrace.c | 63 ++--- > common/iotrace.c | 65 +++ > include/iotrace.h | 57 +++-- > 3 files changed, 153 insertions(+), 32 deletions(-) It looks like your patch series is a bit broken as the version number doesn't appear on the patches (e.g. 1/6), only on this cover letter. Can you fix that? You can use patman which will do all this automatically. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] misc: docs: Fix comments in misc.h
Hi Mario, On 28 May 2018 at 07:01, Mario Six wrote: > Hi Simon, > > On Fri, May 25, 2018 at 4:41 AM, Simon Glass wrote: >> +Marex >> >> Hi Mario, >> >> On 23 May 2018 at 08:07, Mario Six wrote: >>> The comments in misc.h are not in kernel-doc format. Correct the format. >>> >>> Signed-off-by: Mario Six >>> >>> --- >>> >>> v2 -> v3: >>> New in v3 >>> >>> --- >>> include/misc.h | 66 >>> +++--- >>> 1 file changed, 35 insertions(+), 31 deletions(-) >>> >> >> Not another format?! I have been following what I thought was docbook >> format as proposed by Marek a few years ago. >> > > Well, others seem to think different. Michal pointed out in [1] that the > comments were very close to kerneldoc, but not quiet, and proposed to change > the format to make them comply. This seems reasonable, since the kerneldoc > utility is in the tree after all. > > As for the docbook format: That was imported from the Linux kernel, and the > kernel guys subsequently abandoned the docbook format in favor of Sphinx-based > documentation. So, you could argue that the docbook format is obsolete (also, > from what I see there were only ever two docbook documents written in U-Boot, > so the success was limited). > > But that's actually a good question: Is there a preferred or even mandatory > doc > format in use? If that's the case, it would certainly be nice if it was > documented somewhere (or even if there was an automated linter akin to > kerneldoc, for example). > > [1] http://patchwork.ozlabs.org/patch/905733/#1902178 OK how about adding it to the README then? Also the DocBook scripts need to be updated I think. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks, Jagan. The following changes since commit 31dd8efeb661c8db9175a09cf2bab090906a: usb: composite convert __set_bit to generic_set_bit (2018-05-15 21:44:05 -0400) are available in the Git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to a2569f12f0efaad2b1e0754a19f373275562f91e: sf: Add Macronix MX25U25635F ID (2018-05-29 10:05:52 +0530) Ashish Kumar (1): sf: Default page size Spansion flash "S25FS512S" is 256b Christophe Kerello (3): spi: stm32_qspi: Align reg-names with kernel 4.12 RC1 spi: stm32_qspi: Add st, stm32f469-qspi compatible string spi: stm32_qspi: Add chip select management Heinrich Schuchardt (3): spi: atcspi200: avoid NULL dereference spi: lpc32xx: simplify logical expression spi: fsl_qspi: remove superfluous assignment Kimmo Rautkoski (1): sf: Add support for ISSI is25wp Marek Vasut (2): sf: Add Winbond W25Q256 ID sf: Add Macronix MX25U25635F ID Patrice Chotard (6): spi: stm32_qspi: Remove CONFIG_CLK flag spi: stm32_qspi: Sort include files alphabetically spi: stm32_qspi: Use dev_read_xxx API spi: stm32_qspi: Add reset support ARM: dts: stm32: Add quadspi reset for stm32f746 ARM: dts: stm32: Update qspi bindings for stm32f746 Patrick Delaunay (1): spi: stm32_qspi: Solve issue detected by checkpatch arch/arm/dts/stm32f746.dtsi | 3 +- drivers/mtd/spi/spi_flash.c | 11 ++--- drivers/mtd/spi/spi_flash_ids.c | 6 +++ drivers/spi/atcspi200_spi.c | 6 ++- drivers/spi/fsl_qspi.c | 2 +- drivers/spi/lpc32xx_ssp.c | 2 +- drivers/spi/stm32_qspi.c| 91 +++-- 7 files changed, 80 insertions(+), 41 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: enable cpu-specific functions for x86_64 target
On Sat, May 26, 2018 at 06:53:40PM -0600, Simon Glass wrote:
> Hi Ivan,
>
> On 25 May 2018 at 16:00, Ivan Gorinov wrote:
> > Add __weak prefix to the following functions to allow override:
> > misc_init_r(), checkcpu(), print_cpuinfo().
> >
> > Signed-off-by: Ivan Gorinov
> > ---
> > arch/x86/cpu/x86_64/cpu.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
> > index 18b3e94..6f14efc 100644
> > --- a/arch/x86/cpu/x86_64/cpu.c
> > +++ b/arch/x86/cpu/x86_64/cpu.c
> > @@ -59,17 +59,17 @@ int x86_mp_init(void)
> > return 0;
> > }
> >
> > -int misc_init_r(void)
> > +__weak int misc_init_r(void)
> > {
> > return 0;
> > }
> >
> > -int checkcpu(void)
> > +__weak int checkcpu(void)
> > {
> > return 0;
> > }
> >
> > -int print_cpuinfo(void)
> > +__weak int print_cpuinfo(void)
> > {
> > return 0;
> > }
> > --
> > 2.7.4
> >
>
> We should do with with a different CPU driver I think. What exactly is
> the problem?
When I change a Minnowboard configuration (baytrail) to run in 64-bit mode,
there are two conflicting definitions of misc_init_r():
arch/x86/cpu/x86_64/cpu.c
board/intel/minnowmax/minnowmax.c
On other CPU models, functions checkcpu() and print_cpuinfo() conflict with
model-specific definitions for Tangier, Ivy Bridge, Broadwell, Quark.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Fw: Changing the App to fix a driver problem?
Subject: Re: [U-Boot] [PATCH 2/2] net: ping,arp: Fix cache alignment    issues Message-ID: <099414db-a264-a3ac-8aae-fb8aa0d96...@denx.de> Content-Type: text/plain; charset=utf-8; format=flowed On 28.05.2018 08:33, Baruch Siach wrote: > From: Jon Nettleton > > Both ping_receive and arp_receive would transmit a received packet > back out using its original point. This causes problems with > certain network cards that add a custom header to the packet. > Specifically the mvneta driver for the Armada series boards has > a 2 byte Marvell header that is bypassed and passed along to > the system, but that 2 byte offset now causes a misalignment if > it is attempted to be sent back out. > > Rather than changing the driver to memcpy all the received packets > to cache aligned buffers we instead change the two offending > network commands to copy the packet into a cache aligned net_tx_packet > before sending it back out. > > This fixes occasional messages like: > >  CACHE: Misaligned operation at range [3fc01082, 3fc010c2] > ___ This is not a good idea. I believe it should be implemented in the driver. Putting it in in the app code leads to confusionas to its purpose. Duncan Hare 714 931 7952 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 5/5] board: toradex: add Colibri iMX6ULL support
From: Stefan Agner
Add support for the Colibri iMX6ULL module which comes with
on-board raw NAND.
Signed-off-by: Stefan Agner
---
arch/arm/dts/imx6ull-colibri.dts | 550 ++
arch/arm/mach-imx/mx6/Kconfig | 8 +
board/toradex/colibri-imx6ull/Kconfig | 29 +
board/toradex/colibri-imx6ull/MAINTAINERS | 10 +
board/toradex/colibri-imx6ull/Makefile| 4 +
.../toradex/colibri-imx6ull/colibri-imx6ull.c | 408 +
board/toradex/colibri-imx6ull/imximage.cfg| 106
configs/colibri-imx6ull_defconfig | 76 +++
include/configs/colibri-imx6ull.h | 199 +++
9 files changed, 1390 insertions(+)
create mode 100644 arch/arm/dts/imx6ull-colibri.dts
create mode 100644 board/toradex/colibri-imx6ull/Kconfig
create mode 100644 board/toradex/colibri-imx6ull/MAINTAINERS
create mode 100644 board/toradex/colibri-imx6ull/Makefile
create mode 100644 board/toradex/colibri-imx6ull/colibri-imx6ull.c
create mode 100644 board/toradex/colibri-imx6ull/imximage.cfg
create mode 100644 configs/colibri-imx6ull_defconfig
create mode 100644 include/configs/colibri-imx6ull.h
diff --git a/arch/arm/dts/imx6ull-colibri.dts b/arch/arm/dts/imx6ull-colibri.dts
new file mode 100644
index 00..95c67be438
--- /dev/null
+++ b/arch/arm/dts/imx6ull-colibri.dts
@@ -0,0 +1,550 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018 Toradex AG
+ */
+
+/dts-v1/;
+#include
+#include "imx6ull.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX6ULL";
+ compatible = "toradex,imx6ull-colibri", "fsl,imx6ull";
+
+ chosen {
+ stdout-path =
+ };
+
+ reg_module_3v3: regulator-module-3v3 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-name = "+V3.3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_module_3v3_avdd: regulator-module-3v3-avdd {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-name = "+V3.3_AVDD_AUDIO";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_sd1_vmmc: regulator-sd1-vmmc {
+ compatible = "regulator-gpio";
+ gpio = < 9 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_snvs_reg_sd>;
+ regulator-always-on;
+ regulator-name = "+V3.3_1.8_SD";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ states = <180 0x1 330 0x0>;
+ vin-supply = <_module_3v3>;
+ };
+};
+
+ {
+ num-channels = <10>;
+ vref-supply = <_module_3v3_avdd>;
+};
+
+/* Colibri SPI */
+ {
+ cs-gpios = < 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_ecspi1 _ecspi1_cs>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_enet2>;
+ phy-mode = "rmii";
+ phy-handle = <>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ max-speed = <100>;
+ reg = <2>;
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpmi_nand>;
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <_i2c1>;
+ pinctrl-1 = <_i2c1_gpio>;
+ sda-gpios = < 29 GPIO_ACTIVE_LOW>;
+ scl-gpios = < 28 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <_i2c2>;
+ pinctrl-1 = <_i2c2_gpio>;
+ sda-gpios = < 31 GPIO_ACTIVE_LOW>;
+ scl-gpios = < 30 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ ad7879@2c {
+ compatible = "adi,ad7879-1";
+ pinctrl-names = "default";
+ pinctrl-0 = <_snvs_ad7879_int>;
+ reg = <0x2c>;
+ interrupt-parent = <>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-max-pressure = <4096>;
+ adi,resistance-plate-x = <120>;
+ adi,first-conversion-delay = /bits/ 8 <3>;
+ adi,acquisition-time = /bits/ 8 <1>;
+ adi,median-filter-size = /bits/ 8 <2>;
+ adi,averaging = /bits/ 8 <1>;
+ adi,conversion-interval = /bits/ 8 <255>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lcdif_dat
+_lcdif_ctrl>;
+};
+
+ {
+
[U-Boot] [PATCH v1 1/5] mtd: nand: mxs_nand: add device tree support for i.MX 6
From: Stefan Agner
Support i.MX 6 NAND GPMI driver data from device tree.
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/mxs_nand_dt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand_dt.c b/drivers/mtd/nand/mxs_nand_dt.c
index c7355371ac..f2663d1023 100644
--- a/drivers/mtd/nand/mxs_nand_dt.c
+++ b/drivers/mtd/nand/mxs_nand_dt.c
@@ -21,11 +21,19 @@ struct mxs_nand_dt_data {
unsigned int max_ecc_strength_supported;
};
+static const struct mxs_nand_dt_data mxs_nand_imx6q_data = {
+ .max_ecc_strength_supported = 40,
+};
+
static const struct mxs_nand_dt_data mxs_nand_imx7d_data = {
.max_ecc_strength_supported = 62,
};
static const struct udevice_id mxs_nand_dt_ids[] = {
+ {
+ .compatible = "fsl,imx6q-gpmi-nand",
+ .data = (unsigned long)_nand_imx6q_data,
+ },
{
.compatible = "fsl,imx7d-gpmi-nand",
.data = (unsigned long)_nand_imx7d_data,
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 4/5] board: toradex: add new and upcoming SKUs
From: Stefan Agner
Signed-off-by: Stefan Agner
---
board/toradex/common/tdx-cfg-block.c | 7 +++
board/toradex/common/tdx-cfg-block.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index f6231ff2f9..57edb6c5c9 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -91,6 +91,13 @@ const char * const toradex_modules[] = {
[33] = "Colibri iMX7 Dual 512MB",
[34] = "Apalis TK1 2GB",
[35] = "Apalis iMX6 Dual 1GB IT",
+ [36] = "Colibri iMX6ULL 256MB",
+ [37] = "Apalis iMX8 QuadMax 4GB Wi-Fi / Bluetooth",
+ [38] = "Colibri iMX8X",
+ [39] = "Colibri iMX7 Dual 1GB (eMMC)",
+ [40] = "Colibri iMX6ULL 512MB Wi-Fi / Bluetooth IT",
+ [41] = "Colibri iMX7 Dual 512MB EPDC",
+ [42] = "Apalis TK1 4GB",
};
#ifdef CONFIG_TDX_CFG_BLOCK_IS_IN_MMC
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index 29b933c307..da60e789a7 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -54,6 +54,13 @@ enum {
COLIBRI_IMX7D,
APALIS_TK1_2GB,
APALIS_IMX6D_IT,
+ COLIBRI_IMX6ULL,
+ APALIS_IMX8QM, /* 37 */
+ COLIBRI_IMX8X,
+ COLIBRI_IMX7D_EMMC,
+ COLIBRI_IMX6ULL_WIFI_BT_IT, /* 40 */
+ COLIBRI_IMX7D_EPDC,
+ APALIS_TK1_4GB,
};
extern const char * const toradex_modules[];
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/5] imx: add macro to detect whether USB has been initialized
From: Stefan Agner
This macro allows to detect whether the boot ROM initialized USB
already (serial downloader). This is helpful to reliably detect
if the system has been recovered via USB serial downloader.
Signed-off-by: Stefan Agner
Acked-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 431439218d..4f01b20aed 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -996,5 +996,12 @@ struct pwm_regs {
u32 pr;
u32 cnr;
};
+
+/*
+ * If ROM fail back to USB recover mode, USBPH0_PWD will be clear to use USB
+ * If boot from the other mode, USB0_PWD will keep reset value
+ */
+#defineis_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) & (1<<20)))
+
#endif /* __ASSEMBLER__*/
#endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/5] board: toradex: add Colibri iMX6ULL support
From: Stefan Agner This patchset adds Toradex Colibri iMX6ULL support. It makes use of the device tree support for the MXS NAND driver and hence depends on: https://patchwork.ozlabs.org/cover/897263/ https://patchwork.ozlabs.org/cover/901995/ -- Stefan Stefan Agner (5): mtd: nand: mxs_nand: add device tree support for i.MX 6 imx: add macro to detect whether USB has been initialized ARM: dts: imx6ull: use same compatible string as Linux is using board: toradex: add new and upcoming SKUs board: toradex: add Colibri iMX6ULL support arch/arm/dts/imx6ull-colibri.dts | 550 ++ arch/arm/dts/imx6ull.dtsi | 2 +- arch/arm/include/asm/arch-mx6/imx-regs.h | 7 + arch/arm/mach-imx/mx6/Kconfig | 8 + board/toradex/colibri-imx6ull/Kconfig | 29 + board/toradex/colibri-imx6ull/MAINTAINERS | 10 + board/toradex/colibri-imx6ull/Makefile| 4 + .../toradex/colibri-imx6ull/colibri-imx6ull.c | 408 + board/toradex/colibri-imx6ull/imximage.cfg| 106 board/toradex/common/tdx-cfg-block.c | 7 + board/toradex/common/tdx-cfg-block.h | 7 + configs/colibri-imx6ull_defconfig | 76 +++ drivers/mtd/nand/mxs_nand_dt.c| 8 + include/configs/colibri-imx6ull.h | 199 +++ 14 files changed, 1420 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/imx6ull-colibri.dts create mode 100644 board/toradex/colibri-imx6ull/Kconfig create mode 100644 board/toradex/colibri-imx6ull/MAINTAINERS create mode 100644 board/toradex/colibri-imx6ull/Makefile create mode 100644 board/toradex/colibri-imx6ull/colibri-imx6ull.c create mode 100644 board/toradex/colibri-imx6ull/imximage.cfg create mode 100644 configs/colibri-imx6ull_defconfig create mode 100644 include/configs/colibri-imx6ull.h -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/5] ARM: dts: imx6ull: use same compatible string as Linux is using
From: Stefan Agner
The GPMI NAND IP seems to be the same as used in i.MX 6Quad. Use
the fsl,imx6q-gpmi-nand compatible string like Linux devices trees
are.
Signed-off-by: Stefan Agner
---
arch/arm/dts/imx6ull.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6ull.dtsi b/arch/arm/dts/imx6ull.dtsi
index f8ec649460..97236d86ea 100644
--- a/arch/arm/dts/imx6ull.dtsi
+++ b/arch/arm/dts/imx6ull.dtsi
@@ -190,7 +190,7 @@
};
gpmi: gpmi-nand@01806000{
- compatible = "fsl,imx6ull-gpmi-nand", "fsl,
imx6ul-gpmi-nand";
+ compatible = "fsl,imx6q-gpmi-nand";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x01806000 0x2000>, <0x01808000 0x4000>;
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: build u-boot before running its generator
On 05/30/2018 03:14 PM, Mian Yousaf Kaukab wrote: SPL_FIT_GENERATOR may need to access u-boot binaries for generating u-boot.its file. For example arch/arm/mach-rockchip/make_fit_atf.py requires u-boot elf. Add u-boot-nodtb.bin as dependency for U_BOOT_ITS so that u-boot binaries are available when SPL_FIT_GENERATOR is run with parallel make. Suggested-by: Petr Tesarik Signed-off-by: Mian Yousaf Kaukab --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index d08fb6a54d..54557d62b8 100644 --- a/Makefile +++ b/Makefile @@ -1060,7 +1060,7 @@ U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) else ifneq ($(CONFIG_SPL_FIT_GENERATOR),"") U_BOOT_ITS := u-boot.its -$(U_BOOT_ITS): FORCE +$(U_BOOT_ITS): u-boot-nodtb.bin FORCE spl is not being built even after adding this. $(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \ $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@ endif BR, Yousaf ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: sunxi: Add support for Pengpod 1000 tablet
This is initial support for the Pengpod 1000 tablet. The display is
not currently working but the UART works fine and allows access to the
u-boot console. Memory timing is fine and Linux boots from SD card
and runs OK.
Signed-off-by: Bob Ham
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/sun4i-a10-pengpod-1000.dts | 246
configs/PengPod_1000_defconfig | 22 +++
3 files changed, 269 insertions(+)
create mode 100644 arch/arm/dts/sun4i-a10-pengpod-1000.dts
create mode 100644 configs/PengPod_1000_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a0349a8975..49dcf22984 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -265,6 +265,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
+ sun4i-a10-pengpod-1000.dtb \
sun4i-a10-pov-protab2-ips9.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
diff --git a/arch/arm/dts/sun4i-a10-pengpod-1000.dts
b/arch/arm/dts/sun4i-a10-pengpod-1000.dts
new file mode 100644
index 00..3cfd2e1f92
--- /dev/null
+++ b/arch/arm/dts/sun4i-a10-pengpod-1000.dts
@@ -0,0 +1,246 @@
+/*
+ * Copyright 2015 Hans de Goede
+ * Copyright 2017 Robert Ham
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PengPod 1000";
+ compatible = "pengpod,1000", "allwinner,sun4i-a10";
+
+ aliases {
+ serial0 =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <_en_pin_pengpod1000>;
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ cpu-supply = <_dcdc2>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+
+ mma7660: accelerometer@4c {
+ compatible = "fsl,mma7660";
+ reg = <0x4c>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+
+ ft5406ee8: touchscreen@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <>;
+
[U-Boot] [PATCH v2] ARC: Improve relocation fix-ups
We used to have the one and only linker script for all ARC boards
and so we relied on a particular order of symbols there.
Because of that we used __ivt_end as the marker of the end of all the
code which won't be true any longer if we move .ivt section to any other
place. That said we'd better check for each section separately.
A couple of other improvements:
1. There's no point to include the marker of section end in interested
range because its address is beyond the section, i.e. we should
compare with "<" but not "<=".
2. .ivt section for ARCv2 cores is just an array of 32-bit ints and
they are not swapped even on little-endia cores while in case of
ARCompact cores .ivt contains valid code so swapping is required.
3. Just in case add check for ARC600 which is also ARCompact
and its .ivt is normal code.
Signed-off-by: Alexey Brodkin
---
Changes v1 -> v2:
* Fixed build failure for ARcompact, see
https://travis-ci.org/abrodkin/u-boot/jobs/385682085
arch/arc/lib/relocate.c | 76 +
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git a/arch/arc/lib/relocate.c b/arch/arc/lib/relocate.c
index a3b7428d8519..4ffba84eeb3e 100644
--- a/arch/arc/lib/relocate.c
+++ b/arch/arc/lib/relocate.c
@@ -8,7 +8,9 @@
#include
extern ulong __image_copy_start;
+extern ulong __ivt_start;
extern ulong __ivt_end;
+extern ulong __text_end;
DECLARE_GLOBAL_DATA_PTR;
@@ -48,7 +50,7 @@ int do_elf_reloc_fixups(void)
debug("Section .rela.dyn is located at %08x-%08x\n",
(unsigned int)re_src, (unsigned int)re_end);
- Elf32_Addr *offset_ptr_rom, *last_offset = NULL;
+ Elf32_Addr *offset_ptr_rom;
Elf32_Addr *offset_ptr_ram;
do {
@@ -57,15 +59,28 @@ int do_elf_reloc_fixups(void)
/* Check that the location of the relocation is in .text */
if (offset_ptr_rom >= (Elf32_Addr *)&__image_copy_start &&
- offset_ptr_rom > last_offset) {
- unsigned int val;
+ offset_ptr_rom < (Elf32_Addr *)&__image_copy_end) {
+ unsigned int val, do_swap = 0;
/* Switch to the in-RAM version */
offset_ptr_ram = (Elf32_Addr *)((ulong)offset_ptr_rom +
gd->reloc_off);
- debug("Patching value @ %08x (relocated to %08x)\n",
+#ifdef __LITTLE_ENDIAN__
+ /* If location in ".text" section swap value */
+ if (((u32)offset_ptr_rom >= (u32)&__text_start &&
+(u32)offset_ptr_rom <= (u32)&__text_end)
+#if defined(__ARC700__) || defined(__ARC600__)
+ || ((u32)offset_ptr_rom >= (u32)&__ivt_start &&
+ (u32)offset_ptr_rom <= (u32)&__ivt_end)
+#endif
+ )
+ do_swap = 1;
+#endif
+
+ debug("Patching value @ %08x (relocated to %08x)%s\n",
(unsigned int)offset_ptr_rom,
- (unsigned int)offset_ptr_ram);
+ (unsigned int)offset_ptr_ram,
+ do_swap ? ", middle-endian encoded" : "");
/*
* Use "memcpy" because target location might be
@@ -75,28 +90,45 @@ int do_elf_reloc_fixups(void)
*/
memcpy(, offset_ptr_ram, sizeof(int));
-#ifdef __LITTLE_ENDIAN__
- /* If location in ".text" section swap value */
- if ((unsigned int)offset_ptr_rom <
- (unsigned int)&__ivt_end)
+ if (do_swap)
val = (val << 16) | (val >> 16);
-#endif
/* Check that the target points into executable */
- if (val >= (unsigned int)&__image_copy_start && val <=
- (unsigned int)&__image_copy_end) {
- val += gd->reloc_off;
-#ifdef __LITTLE_ENDIAN__
- /* If location in ".text" section swap value */
- if ((unsigned int)offset_ptr_rom <
- (unsigned int)&__ivt_end)
- val = (val << 16) | (val >> 16);
-#endif
- memcpy(offset_ptr_ram, , sizeof(int));
+ if (val < (unsigned int)&__image_copy_start ||
+ val > (unsigned int)&__image_copy_end) {
+ /* TODO: Use panic() instead of debug()
+*
+* For some reason GCC might generate
+* fake relocation even for LD/SC of constant
+
[U-Boot] [PATCH] ARC: Use elf32-bigarc in case of -EB
As it is stated in LD manual [1] the second entry in OUTPUT_FORMAT
corresponds to "-EB" command-line option which for us is "elf32-bigarc".
[1] https://sourceware.org/binutils/docs/ld/Format-Commands.html#Format-Commands
Signed-off-by: Alexey Brodkin
---
arch/arc/cpu/u-boot.lds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/cpu/u-boot.lds b/arch/arc/cpu/u-boot.lds
index ff8239b66b40..e12145c76849 100644
--- a/arch/arc/cpu/u-boot.lds
+++ b/arch/arc/cpu/u-boot.lds
@@ -5,7 +5,7 @@
#include
-OUTPUT_FORMAT("elf32-littlearc", "elf32-littlearc", "elf32-littlearc")
+OUTPUT_FORMAT("elf32-littlearc", "elf32-bigarc", "elf32-littlearc")
OUTPUT_ARCH(arc)
ENTRY(_start)
SECTIONS
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] cmd: fpga: Reorder the arguments parsing code
On 29.5.2018 16:22, Siva Durga Prasad Paladugu wrote:
> This patch modifies the arguments parsing code by parsing
> based on requested operation for fpga loadfs and then
> parses the most common/basic args for other fpga load
> commands. This makes it easy for new command extensions
> or additions especially the commands with more args.
>
> Signed-off-by: Siva Durga Prasad Paladugu
> ---
> cmd/fpga.c | 31 +++
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index 14ad4e5..0981826 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
> @@ -60,15 +60,31 @@ int do_fpga(cmd_tbl_t *cmdtp, int flag, int argc, char
> *const argv[])
> if (datastr)
> fpga_data = (void *)simple_strtoul(datastr, NULL, 16);
>
> - switch (argc) {
> + if (argc > 9 && argc < 3) {
&& is completely broken here.
Also there is an option to use fpga and fpgadata variable and 2 args are
valid too.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] mtd: nand: mxs_nand: add minimal ECC support
Hi Stefano,
On 30.04.2018 10:08, Stefan Agner wrote:
> On 27.04.2018 09:31, Stefano Babic wrote:
>> Hi Stefan,
>>
>> On 11/04/2018 18:04, Stefan Agner wrote:
>>> From: Stefan Agner
>>>
>>> Add support for minimum ECC strength supported by the NAND chip.
>>> This aligns with the behavior when using the fsl,use-minimum-ecc
>>> device tree property in Linux.
>>>
>>> Signed-off-by: Stefan Agner
>>> ---
>>>
>>> Changes in v3: None
>>> Changes in v2: None
>>>
>>> drivers/mtd/nand/Kconfig| 8 +
>>> drivers/mtd/nand/mxs_nand.c | 71 +
>>> 2 files changed, 65 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>>> index 4db259fcb2..c039b9cc60 100644
>>> --- a/drivers/mtd/nand/Kconfig
>>> +++ b/drivers/mtd/nand/Kconfig
>>> @@ -152,6 +152,14 @@ config NAND_MXS
>>> This enables NAND driver for the NAND flash controller on the
>>> MXS processors.
>>>
>>> +if NAND_MXS
>>> +
>>> +config NAND_MXS_USE_MINIMUM_ECC
>>> + bool "Use minimum ECC strength supported by the controller"
>>> + default false
>>> +
>>> +endif
>>> +
>>> config NAND_ZYNQ
>>> bool "Support for Zynq Nand controller"
>>> select SYS_NAND_SELF_INIT
>>> diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
>>> index 2696b543ef..8305bf2302 100644
>>> --- a/drivers/mtd/nand/mxs_nand.c
>>> +++ b/drivers/mtd/nand/mxs_nand.c
>>> @@ -211,11 +211,52 @@ static inline int mxs_nand_calc_mark_offset(struct
>>> bch_geometry *geo,
>>> return 0;
>>> }
>>>
>>> +static inline unsigned int mxs_nand_max_ecc_strength_supported(void)
>>> +{
>>> + /* Refer to Chapter 17 for i.MX6DQ, Chapter 18 for i.MX6SX */
>>> + if (is_mx6sx() || is_mx7())
>>> + return 62;
>>> + else
>>> + return 40;
>>> +}
>>> +
>>> +static inline int mxs_nand_calc_ecc_layout_by_info(struct bch_geometry
>>> *geo,
>>> + struct mtd_info *mtd)
>>> +{
>>> + struct nand_chip *chip = mtd_to_nand(mtd);
>>> +
>>> + if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
>>> + return -ENOTSUPP;
>>> +
>>> + switch (chip->ecc_step_ds) {
>>> + case SZ_512:
>>> + geo->gf_len = 13;
>>> + break;
>>> + case SZ_1K:
>>> + geo->gf_len = 14;
>>> + break;
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> +
>>> + geo->ecc_chunk_size = chip->ecc_step_ds;
>>> + geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
>>> +
>>> + /* Keep the C >= O */
>>> + if (geo->ecc_chunk_size < mtd->oobsize)
>>> + return -EINVAL;
>>> +
>>> + if (geo->ecc_strength > mxs_nand_max_ecc_strength_supported())
>>> + return -EINVAL;
>>> +
>>> + geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static inline int mxs_nand_calc_ecc_layout(struct bch_geometry *geo,
>>>struct mtd_info *mtd)
>>> {
>>> - unsigned int max_ecc_strength_supported;
>>> -
>>> /* The default for the length of Galois Field. */
>>> geo->gf_len = 13;
>>>
>>> @@ -235,12 +276,6 @@ static inline int mxs_nand_calc_ecc_layout(struct
>>> bch_geometry *geo,
>>>
>>> geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size;
>>>
>>> - /* Refer to Chapter 17 for i.MX6DQ, Chapter 18 for i.MX6SX */
>>> - if (is_mx6sx() || is_mx7())
>>> - max_ecc_strength_supported = 62;
>>> - else
>>> - max_ecc_strength_supported = 40;
>>> -
>>> /*
>>> * Determine the ECC layout with the formula:
>>> * ECC bits per chunk = (total page spare data bits) /
>>> @@ -252,10 +287,8 @@ static inline int mxs_nand_calc_ecc_layout(struct
>>> bch_geometry *geo,
>>> geo->ecc_strength = ((mtd->oobsize - MXS_NAND_METADATA_SIZE) * 8)
>>> / (geo->gf_len * geo->ecc_chunk_count);
>>>
>>> - geo->ecc_strength = min(round_down(geo->ecc_strength, 2),
>>> max_ecc_strength_supported);
>>> -
>>> - if (mxs_nand_calc_mark_offset(geo, mtd->writesize) < 0)
>>> - return -EINVAL;
>>> + geo->ecc_strength = min(round_down(geo->ecc_strength, 2),
>>> + mxs_nand_max_ecc_strength_supported());
>>>
>>> return 0;
>>> }
>>> @@ -1006,9 +1039,19 @@ static int mxs_nand_setup_ecc(struct mtd_info *mtd)
>>> struct bch_geometry *geo = _info->bch_geometry;
>>> struct mxs_bch_regs *bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
>>> uint32_t tmp;
>>> + int ret = -ENOTSUPP;
>>>
>>> - if (mxs_nand_calc_ecc_layout(geo, mtd))
>>> - return -EINVAL;
>>> +#ifdef CONFIG_NAND_MXS_USE_MINIMUM_ECC
>>> + ret = mxs_nand_calc_ecc_layout_by_info(geo, mtd);
>>> +#endif
>>> +
>>> + if (ret == -ENOTSUPP)
>>> + ret = mxs_nand_calc_ecc_layout(geo, mtd);
>>> +
>>> + if (ret)
>>> + return ret;
>>> +
>>> + mxs_nand_calc_mark_offset(geo, mtd->writesize);
>>>
>>> /* Configure BCH and
[U-Boot] [PATCH] Makefile: build u-boot before running its generator
SPL_FIT_GENERATOR may need to access u-boot binaries for generating u-boot.its file. For example arch/arm/mach-rockchip/make_fit_atf.py requires u-boot elf. Add u-boot-nodtb.bin as dependency for U_BOOT_ITS so that u-boot binaries are available when SPL_FIT_GENERATOR is run with parallel make. Suggested-by: Petr Tesarik Signed-off-by: Mian Yousaf Kaukab --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index d08fb6a54d..54557d62b8 100644 --- a/Makefile +++ b/Makefile @@ -1060,7 +1060,7 @@ U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) else ifneq ($(CONFIG_SPL_FIT_GENERATOR),"") U_BOOT_ITS := u-boot.its -$(U_BOOT_ITS): FORCE +$(U_BOOT_ITS): u-boot-nodtb.bin FORCE $(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \ $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@ endif -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 30.05.2018 13:27, Marek Vasut wrote: On 05/30/2018 01:25 PM, Jagan Teki wrote: On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt wrote: On 30.05.2018 07:10, Jagan Teki wrote: On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt wrote: Hi Jagan, On 21.05.2018 17:09, Jagan Teki wrote: Hi Simon, On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt wrote: On 14.05.2018 09:47, Simon Goldschmidt wrote: On 14.05.2018 09:22, Jagan Teki wrote: On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt wrote: + Marek for the socfpga platform, see below On 07.12.2017 06:49, Jagan Teki wrote: On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon wrote: + Lukasz (as a reviewer of my patch[1]) On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: This is the patch[1] for 4-byte addressing, but I would wonder how can proceed operations with 4-byte if we disable during probe. [1] http://git.denx.de/?p=u-boot- spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca OK, so your patch does something different than what I did. I was trying to keep the change to U-Boot as small as possible, only fixing this issue I was seeing: After a soft-reboot where the SPI chip was not reset, it is left in 4-byte addressing mode (linux uses this mode, obviously). Remember that 4-byte mode is not a permanent setting, so we can enter and leave it any time we like by issuing a command. U-Boot uses the Bank Address Register (BAR) for spi flash chips with more than 16 MByte, so it impclitly assumes that the chip is in 3-byte address mode. As I see it, your patch is worth a discussion named "should we use 4-byte addressing mode on spi flash chips?". I do think this is a better alternative than writing BAR! But this change probably needs discussion and testing. OK, will review your patch. Any update here? The last input on this is about five months old! This is the last patch I need to run my socfpga board from qspi. I added Marek to the discussion as at least the SoCrates board does not have a reset connected to the qspi chip and needs this as well. Note that the system boot rom does not have a problem with the chip being in 4-byte mode but SPL fails to load U-Boot from qspi. Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted. Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte opcodes (which is why I'm seeing this bug after all). OK, this is not the latest kernel, but it's LTS, so I think U-Boot should handle this Kernel. What happens in Linux (4.9) is that depending on the flash size, 4-byte mode is *always* enabled. And it stays enabled after soft reboot. So consequently, we have to *always* disable it in U-Boot. In newer versions, they still use 4-byte mode if the flash chip does not support 4-byte opcodes. I suppose that would fix it for me, too, but I'm stuck with LTS for now. Do you need any more information here? I'd really love to get this into 2018.07, finally. As I said before, this is the last patch missing for socfpga cyclone5 running from qspi. The point I'm not clear is we don't have 4-byte addressing (we are using Bank addressing for > 16MiB) so how come we disable 4-byte addressing for the sake of other software blocks enabled it? It's like a hack to me. I understand your point. However, there *are* SPI chips without a reset line. And if linux brings them into 4-byte address mode and then the system gets a warm reset e.g. by the watchdog, where do you suggest to set the chip back to 3-byte address mode? What are those chips? For example the EPCQ256N mounted on the EBV Socrates board (Cyclone V SoC), see this doc, pinout is in chapter 1.11.2: https://www.altera.com/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf what if we have 4-byte addressing mode in U-Boot, we completely operate these into 3-byte mode by disabling 4-byte mode? Ehrm, we don't have 4-byte addressing mode in U-Boot. That's the problem. If we would, we would surely execute the opcode I have added and explicitly set the device into 4-byte mode. That would solve the problem. I'm not sure I understand this, how should 4-byte addressing solve the problem? you claimed in patch that bootrom would need 3-byte addressing during warm reset ie what the problem is all about right? what if u-boot operates in 4-bytes and trigger watchdog, should rom boots from 4-byte addressing. IMO his board needs a SPI NOR reset, otherwise he will always have reliability problems with booting. There will always be cornercases where the CPU reboots and SPI NOR is left in some crappy state and the machine will just hang. If you screw up the reset routing, your hardware is DOOMED and there's no fixing it in software. That said, the 3byte addressing mode in U-Boot is crap too and should've been fixed since forever by importing the Linux SPI NOR stack. So isn't that
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 30.05.2018 13:25, Jagan Teki wrote: On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt wrote: On 30.05.2018 07:10, Jagan Teki wrote: On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt wrote: Hi Jagan, On 21.05.2018 17:09, Jagan Teki wrote: Hi Simon, On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt wrote: On 14.05.2018 09:47, Simon Goldschmidt wrote: On 14.05.2018 09:22, Jagan Teki wrote: On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt wrote: + Marek for the socfpga platform, see below On 07.12.2017 06:49, Jagan Teki wrote: On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon wrote: + Lukasz (as a reviewer of my patch[1]) On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: This is the patch[1] for 4-byte addressing, but I would wonder how can proceed operations with 4-byte if we disable during probe. [1] http://git.denx.de/?p=u-boot- spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca OK, so your patch does something different than what I did. I was trying to keep the change to U-Boot as small as possible, only fixing this issue I was seeing: After a soft-reboot where the SPI chip was not reset, it is left in 4-byte addressing mode (linux uses this mode, obviously). Remember that 4-byte mode is not a permanent setting, so we can enter and leave it any time we like by issuing a command. U-Boot uses the Bank Address Register (BAR) for spi flash chips with more than 16 MByte, so it impclitly assumes that the chip is in 3-byte address mode. As I see it, your patch is worth a discussion named "should we use 4-byte addressing mode on spi flash chips?". I do think this is a better alternative than writing BAR! But this change probably needs discussion and testing. OK, will review your patch. Any update here? The last input on this is about five months old! This is the last patch I need to run my socfpga board from qspi. I added Marek to the discussion as at least the SoCrates board does not have a reset connected to the qspi chip and needs this as well. Note that the system boot rom does not have a problem with the chip being in 4-byte mode but SPL fails to load U-Boot from qspi. Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted. Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte opcodes (which is why I'm seeing this bug after all). OK, this is not the latest kernel, but it's LTS, so I think U-Boot should handle this Kernel. What happens in Linux (4.9) is that depending on the flash size, 4-byte mode is *always* enabled. And it stays enabled after soft reboot. So consequently, we have to *always* disable it in U-Boot. In newer versions, they still use 4-byte mode if the flash chip does not support 4-byte opcodes. I suppose that would fix it for me, too, but I'm stuck with LTS for now. Do you need any more information here? I'd really love to get this into 2018.07, finally. As I said before, this is the last patch missing for socfpga cyclone5 running from qspi. The point I'm not clear is we don't have 4-byte addressing (we are using Bank addressing for > 16MiB) so how come we disable 4-byte addressing for the sake of other software blocks enabled it? It's like a hack to me. I understand your point. However, there *are* SPI chips without a reset line. And if linux brings them into 4-byte address mode and then the system gets a warm reset e.g. by the watchdog, where do you suggest to set the chip back to 3-byte address mode? What are those chips? For example the EPCQ256N mounted on the EBV Socrates board (Cyclone V SoC), see this doc, pinout is in chapter 1.11.2: https://www.altera.com/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf what if we have 4-byte addressing mode in U-Boot, we completely operate these into 3-byte mode by disabling 4-byte mode? Ehrm, we don't have 4-byte addressing mode in U-Boot. That's the problem. If we would, we would surely execute the opcode I have added and explicitly set the device into 4-byte mode. That would solve the problem. I'm not sure I understand this, how should 4-byte addressing solve the problem? you claimed in patch that bootrom would need 3-byte addressing during warm reset ie what the problem is all about right? It's not the boot rom which needs 3-byte mode but it's SPL (and U-Boot). Maybe I expressed myself unclear. Let me explain again: 1) Cold reset, qspi chip is in 3-byte addressing mode 2) Boot rom loads SPL from qspi (don't know in which mode that happens) 3) SPL & U-Boot use the chip in 3-byte mode 4) Linux 4.9 is booted, switches the chip into 4-byte mode (Note that newer versions seem to use 4-byte opcodes and don't touch the mode) 5) Soft reboot, qspi does not get a reset (I know this is not good but for now it's just like that. 6) SPL is not loaded from qspi again since the boot rom uses the version
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 05/30/2018 01:25 PM, Jagan Teki wrote: > On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt > wrote: >> >> >> On 30.05.2018 07:10, Jagan Teki wrote: >>> >>> On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt >>> wrote: Hi Jagan, On 21.05.2018 17:09, Jagan Teki wrote: > > > Hi Simon, > > On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt > wrote: >> >> >> >> On 14.05.2018 09:47, Simon Goldschmidt wrote: >>> >>> >>> >>> >>> >>> On 14.05.2018 09:22, Jagan Teki wrote: On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt wrote: > > > > + Marek for the socfpga platform, see below > > On 07.12.2017 06:49, Jagan Teki wrote: >> >> >> >> >> On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon >> wrote: >>> >>> >>> >>> >>> + Lukasz (as a reviewer of my patch[1]) >>> >>> On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: This is the patch[1] for 4-byte addressing, but I would wonder how can proceed operations with 4-byte if we disable during probe. [1] http://git.denx.de/?p=u-boot- spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca >>> >>> >>> >>> >>> >>> OK, so your patch does something different than what I did. >>> >>> I was trying to keep the change to U-Boot as small as possible, >>> only >>> fixing this issue I was seeing: >>> >>> After a soft-reboot where the SPI chip was not reset, it is left >>> in >>> 4-byte addressing mode (linux uses this mode, obviously). Remember >>> that 4-byte mode is not a permanent setting, so we can enter and >>> leave it any time we like by issuing a command. >>> >>> U-Boot uses the Bank Address Register (BAR) for spi flash chips >>> with >>> more than 16 MByte, so it impclitly assumes that the chip is in >>> 3-byte address mode. As I see it, your patch is worth a discussion >>> named "should we use 4-byte addressing mode on spi flash chips?". >>> I do think this is a better alternative than writing BAR! But this >>> change probably needs discussion and testing. >> >> >> >> >> >> OK, will review your patch. > > > > > > Any update here? The last input on this is about five months old! > This > is > the last patch I need to run my socfpga board from qspi. > > I added Marek to the discussion as at least the SoCrates board does > not > have > a reset connected to the qspi chip and needs this as well. Note that > the > system boot rom does not have a problem with the chip being in > 4-byte > mode > but SPL fails to load U-Boot from qspi. Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted. >>> >>> >>> >>> >>> Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function >>> 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte >>> opcodes >>> (which is why I'm seeing this bug after all). OK, this is not the >>> latest >>> kernel, but it's LTS, so I think U-Boot should handle this Kernel. >>> >>> What happens in Linux (4.9) is that depending on the flash size, >>> 4-byte >>> mode is *always* enabled. And it stays enabled after soft reboot. So >>> consequently, we have to *always* disable it in U-Boot. >>> >>> In newer versions, they still use 4-byte mode if the flash chip does >>> not >>> support 4-byte opcodes. I suppose that would fix it for me, too, but >>> I'm >>> stuck with LTS for now. >> >> >> >> >> Do you need any more information here? I'd really love to get this into >> 2018.07, finally. As I said before, this is the last patch missing for >> socfpga cyclone5 running from qspi. > > > > The point I'm not clear is we don't have 4-byte addressing (we are > using Bank addressing for > 16MiB) so how come we disable 4-byte > addressing for the sake of other software blocks enabled it? It's like > a hack to me. I understand your point. However, there *are* SPI chips without a reset line. And if linux brings them into 4-byte address mode and then the system gets a warm reset e.g. by the watchdog, where do you suggest to set the chip back to 3-byte address mode? >>> >>>
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt wrote: > > > On 30.05.2018 07:10, Jagan Teki wrote: >> >> On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt >> wrote: >>> >>> >>> Hi Jagan, >>> >>> >>> On 21.05.2018 17:09, Jagan Teki wrote: Hi Simon, On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt wrote: > > > > On 14.05.2018 09:47, Simon Goldschmidt wrote: >> >> >> >> >> >> On 14.05.2018 09:22, Jagan Teki wrote: >>> >>> >>> >>> On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt >>> wrote: + Marek for the socfpga platform, see below On 07.12.2017 06:49, Jagan Teki wrote: > > > > > On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon > wrote: >> >> >> >> >> + Lukasz (as a reviewer of my patch[1]) >> >> On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: >>> >>> >>> >>> >>> This is the patch[1] for 4-byte addressing, but I would wonder >>> how >>> can >>> proceed >>> operations with 4-byte if we disable during probe. >>> >>> [1] http://git.denx.de/?p=u-boot- >>> spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca >> >> >> >> >> >> OK, so your patch does something different than what I did. >> >> I was trying to keep the change to U-Boot as small as possible, >> only >> fixing this issue I was seeing: >> >> After a soft-reboot where the SPI chip was not reset, it is left >> in >> 4-byte addressing mode (linux uses this mode, obviously). Remember >> that 4-byte mode is not a permanent setting, so we can enter and >> leave it any time we like by issuing a command. >> >> U-Boot uses the Bank Address Register (BAR) for spi flash chips >> with >> more than 16 MByte, so it impclitly assumes that the chip is in >> 3-byte address mode. As I see it, your patch is worth a discussion >> named "should we use 4-byte addressing mode on spi flash chips?". >> I do think this is a better alternative than writing BAR! But this >> change probably needs discussion and testing. > > > > > > OK, will review your patch. Any update here? The last input on this is about five months old! This is the last patch I need to run my socfpga board from qspi. I added Marek to the discussion as at least the SoCrates board does not have a reset connected to the qspi chip and needs this as well. Note that the system boot rom does not have a problem with the chip being in 4-byte mode but SPL fails to load U-Boot from qspi. >>> >>> >>> >>> >>> Does Linux do this stuff? say my flash in 4-byte and flashed SPL and >>> rebooted. >> >> >> >> >> Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function >> 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte >> opcodes >> (which is why I'm seeing this bug after all). OK, this is not the >> latest >> kernel, but it's LTS, so I think U-Boot should handle this Kernel. >> >> What happens in Linux (4.9) is that depending on the flash size, >> 4-byte >> mode is *always* enabled. And it stays enabled after soft reboot. So >> consequently, we have to *always* disable it in U-Boot. >> >> In newer versions, they still use 4-byte mode if the flash chip does >> not >> support 4-byte opcodes. I suppose that would fix it for me, too, but >> I'm >> stuck with LTS for now. > > > > > Do you need any more information here? I'd really love to get this into > 2018.07, finally. As I said before, this is the last patch missing for > socfpga cyclone5 running from qspi. The point I'm not clear is we don't have 4-byte addressing (we are using Bank addressing for > 16MiB) so how come we disable 4-byte addressing for the sake of other software blocks enabled it? It's like a hack to me. >>> >>> >>> >>> I understand your point. However, there *are* SPI chips without a reset >>> line. And if linux brings them into 4-byte address mode and then the system >>> gets a warm reset e.g. by the watchdog, where do you suggest to set the chip >>> back to 3-byte address mode? >> >> >> What are those chips? > > > For example the EPCQ256N mounted on the EBV Socrates board (Cyclone V SoC), > see this doc, pinout is in chapter 1.11.2: >
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 05/30/2018 01:18 PM, Simon Goldschmidt wrote: > > > On 30.05.2018 11:56, Marek Vasut wrote: >> On 05/30/2018 07:10 AM, Jagan Teki wrote: >>> On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt >>> wrote: Hi Jagan, On 21.05.2018 17:09, Jagan Teki wrote: > > Hi Simon, > > On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt > wrote: >> >> >> On 14.05.2018 09:47, Simon Goldschmidt wrote: >>> >>> >>> >>> >>> On 14.05.2018 09:22, Jagan Teki wrote: On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt wrote: > > > + Marek for the socfpga platform, see below > > On 07.12.2017 06:49, Jagan Teki wrote: >> >> >> >> On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon >> wrote: >>> >>> >>> >>> + Lukasz (as a reviewer of my patch[1]) >>> >>> On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: This is the patch[1] for 4-byte addressing, but I would wonder how can proceed operations with 4-byte if we disable during probe. [1] http://git.denx.de/?p=u-boot- spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca >>> >>> >>> >>> >>> OK, so your patch does something different than what I did. >>> >>> I was trying to keep the change to U-Boot as small as >>> possible, only >>> fixing this issue I was seeing: >>> >>> After a soft-reboot where the SPI chip was not reset, it is >>> left in >>> 4-byte addressing mode (linux uses this mode, obviously). >>> Remember >>> that 4-byte mode is not a permanent setting, so we can enter and >>> leave it any time we like by issuing a command. >>> >>> U-Boot uses the Bank Address Register (BAR) for spi flash >>> chips with >>> more than 16 MByte, so it impclitly assumes that the chip is in >>> 3-byte address mode. As I see it, your patch is worth a >>> discussion >>> named "should we use 4-byte addressing mode on spi flash >>> chips?". >>> I do think this is a better alternative than writing BAR! But >>> this >>> change probably needs discussion and testing. >> >> >> >> >> OK, will review your patch. > > > > > Any update here? The last input on this is about five months > old! This > is > the last patch I need to run my socfpga board from qspi. > > I added Marek to the discussion as at least the SoCrates board > does not > have > a reset connected to the qspi chip and needs this as well. Note > that the > system boot rom does not have a problem with the chip being in > 4-byte > mode > but SPL fails to load U-Boot from qspi. Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted. >>> >>> >>> >>> Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function >>> 'set_4byte'. I'm using 4.9 where they don't have support for 4 >>> byte opcodes >>> (which is why I'm seeing this bug after all). OK, this is not the >>> latest >>> kernel, but it's LTS, so I think U-Boot should handle this Kernel. >>> >>> What happens in Linux (4.9) is that depending on the flash size, >>> 4-byte >>> mode is *always* enabled. And it stays enabled after soft reboot. So >>> consequently, we have to *always* disable it in U-Boot. >>> >>> In newer versions, they still use 4-byte mode if the flash chip >>> does not >>> support 4-byte opcodes. I suppose that would fix it for me, too, >>> but I'm >>> stuck with LTS for now. >> >> >> >> Do you need any more information here? I'd really love to get this >> into >> 2018.07, finally. As I said before, this is the last patch missing >> for >> socfpga cyclone5 running from qspi. > > > The point I'm not clear is we don't have 4-byte addressing (we are > using Bank addressing for > 16MiB) so how come we disable 4-byte > addressing for the sake of other software blocks enabled it? It's like > a hack to me. I understand your point. However, there *are* SPI chips without a reset line. And if linux brings them into 4-byte address mode and then the system gets a warm reset e.g. by the watchdog, where do you suggest to set the chip back to 3-byte address mode? >>> >>> What are those chips? >> >> Very select few actually have a reset line, which lures HW designers to
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 30.05.2018 11:56, Marek Vasut wrote: On 05/30/2018 07:10 AM, Jagan Teki wrote: On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt wrote: Hi Jagan, On 21.05.2018 17:09, Jagan Teki wrote: Hi Simon, On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt wrote: On 14.05.2018 09:47, Simon Goldschmidt wrote: On 14.05.2018 09:22, Jagan Teki wrote: On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt wrote: + Marek for the socfpga platform, see below On 07.12.2017 06:49, Jagan Teki wrote: On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon wrote: + Lukasz (as a reviewer of my patch[1]) On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: This is the patch[1] for 4-byte addressing, but I would wonder how can proceed operations with 4-byte if we disable during probe. [1] http://git.denx.de/?p=u-boot- spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca OK, so your patch does something different than what I did. I was trying to keep the change to U-Boot as small as possible, only fixing this issue I was seeing: After a soft-reboot where the SPI chip was not reset, it is left in 4-byte addressing mode (linux uses this mode, obviously). Remember that 4-byte mode is not a permanent setting, so we can enter and leave it any time we like by issuing a command. U-Boot uses the Bank Address Register (BAR) for spi flash chips with more than 16 MByte, so it impclitly assumes that the chip is in 3-byte address mode. As I see it, your patch is worth a discussion named "should we use 4-byte addressing mode on spi flash chips?". I do think this is a better alternative than writing BAR! But this change probably needs discussion and testing. OK, will review your patch. Any update here? The last input on this is about five months old! This is the last patch I need to run my socfpga board from qspi. I added Marek to the discussion as at least the SoCrates board does not have a reset connected to the qspi chip and needs this as well. Note that the system boot rom does not have a problem with the chip being in 4-byte mode but SPL fails to load U-Boot from qspi. Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted. Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte opcodes (which is why I'm seeing this bug after all). OK, this is not the latest kernel, but it's LTS, so I think U-Boot should handle this Kernel. What happens in Linux (4.9) is that depending on the flash size, 4-byte mode is *always* enabled. And it stays enabled after soft reboot. So consequently, we have to *always* disable it in U-Boot. In newer versions, they still use 4-byte mode if the flash chip does not support 4-byte opcodes. I suppose that would fix it for me, too, but I'm stuck with LTS for now. Do you need any more information here? I'd really love to get this into 2018.07, finally. As I said before, this is the last patch missing for socfpga cyclone5 running from qspi. The point I'm not clear is we don't have 4-byte addressing (we are using Bank addressing for > 16MiB) so how come we disable 4-byte addressing for the sake of other software blocks enabled it? It's like a hack to me. I understand your point. However, there *are* SPI chips without a reset line. And if linux brings them into 4-byte address mode and then the system gets a warm reset e.g. by the watchdog, where do you suggest to set the chip back to 3-byte address mode? What are those chips? Very select few actually have a reset line, which lures HW designers to believe reseting SPI NOR is optional, which in turn is BS. what if we have 4-byte addressing mode in U-Boot, we completely operate these into 3-byte mode by disabling 4-byte mode? If you operate large chip in 3B addressing mode, you lose a lot of performance. This should be fixed in U-Boot too. Can you elaborate on the performance loss? Of course I'd also prefer using 4-byte addressing mode or even 4-byte opcodes in U-Boot. However, I'm not sure I'll get the time to implement this. Especially when knowing that there is a big patch to change all this is in the queue... (whatever the status of this is) Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 05/30/2018 07:10 AM, Jagan Teki wrote: > On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt > wrote: >> >> Hi Jagan, >> >> >> On 21.05.2018 17:09, Jagan Teki wrote: >>> >>> Hi Simon, >>> >>> On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt >>> wrote: On 14.05.2018 09:47, Simon Goldschmidt wrote: > > > > > On 14.05.2018 09:22, Jagan Teki wrote: >> >> >> On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt >> wrote: >>> >>> >>> + Marek for the socfpga platform, see below >>> >>> On 07.12.2017 06:49, Jagan Teki wrote: On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon wrote: > > > > + Lukasz (as a reviewer of my patch[1]) > > On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: >> >> >> >> This is the patch[1] for 4-byte addressing, but I would wonder how >> can >> proceed >> operations with 4-byte if we disable during probe. >> >> [1] http://git.denx.de/?p=u-boot- >> spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca > > > > > OK, so your patch does something different than what I did. > > I was trying to keep the change to U-Boot as small as possible, only > fixing this issue I was seeing: > > After a soft-reboot where the SPI chip was not reset, it is left in > 4-byte addressing mode (linux uses this mode, obviously). Remember > that 4-byte mode is not a permanent setting, so we can enter and > leave it any time we like by issuing a command. > > U-Boot uses the Bank Address Register (BAR) for spi flash chips with > more than 16 MByte, so it impclitly assumes that the chip is in > 3-byte address mode. As I see it, your patch is worth a discussion > named "should we use 4-byte addressing mode on spi flash chips?". > I do think this is a better alternative than writing BAR! But this > change probably needs discussion and testing. OK, will review your patch. >>> >>> >>> >>> >>> Any update here? The last input on this is about five months old! This >>> is >>> the last patch I need to run my socfpga board from qspi. >>> >>> I added Marek to the discussion as at least the SoCrates board does not >>> have >>> a reset connected to the qspi chip and needs this as well. Note that the >>> system boot rom does not have a problem with the chip being in 4-byte >>> mode >>> but SPL fails to load U-Boot from qspi. >> >> >> >> Does Linux do this stuff? say my flash in 4-byte and flashed SPL and >> rebooted. > > > > Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function > 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte > opcodes > (which is why I'm seeing this bug after all). OK, this is not the latest > kernel, but it's LTS, so I think U-Boot should handle this Kernel. > > What happens in Linux (4.9) is that depending on the flash size, 4-byte > mode is *always* enabled. And it stays enabled after soft reboot. So > consequently, we have to *always* disable it in U-Boot. > > In newer versions, they still use 4-byte mode if the flash chip does not > support 4-byte opcodes. I suppose that would fix it for me, too, but I'm > stuck with LTS for now. Do you need any more information here? I'd really love to get this into 2018.07, finally. As I said before, this is the last patch missing for socfpga cyclone5 running from qspi. >>> >>> >>> The point I'm not clear is we don't have 4-byte addressing (we are >>> using Bank addressing for > 16MiB) so how come we disable 4-byte >>> addressing for the sake of other software blocks enabled it? It's like >>> a hack to me. >> >> >> I understand your point. However, there *are* SPI chips without a reset >> line. And if linux brings them into 4-byte address mode and then the system >> gets a warm reset e.g. by the watchdog, where do you suggest to set the chip >> back to 3-byte address mode? > > What are those chips? Very select few actually have a reset line, which lures HW designers to believe reseting SPI NOR is optional, which in turn is BS. > what if we have 4-byte addressing mode in > U-Boot, we completely operate these into 3-byte mode by disabling > 4-byte mode? If you operate large chip in 3B addressing mode, you lose a lot of performance. This should be fixed in U-Boot too. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (30.05.2018)
On 05/30/2018 09:47 AM, Lukasz Majewski wrote: > Dear Marek, > > Please find a PR for DFU. > > The following changes since commit > c3c863880479edeb5b08226e622d13c91326e4a7: > > add FIT data-position & data-offset property support (2018-05-26 > 18:19:19 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-dfu.git > > for you to fetch changes up to c6e8522697a46aa847e9eac997541c205125f23d: > > fastboot: Update fastboot documentation (2018-05-29 17:54:04 +0200) Applied, 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] net: mvgbe: extract common code for SMI wait
On 30.05.2018 12:49, Chris Packham wrote: Combine repeated code from smi_reg_read/smi_reg_write into a common function smi_wait_ready. Signed-off-by: Chris Packham Looks good, thanks. Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: mvgbe: extract common code for SMI wait
Combine repeated code from smi_reg_read/smi_reg_write into a common
function smi_wait_ready.
Signed-off-by: Chris Packham
---
drivers/net/mvgbe.c | 48 ++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index 4e1aff6e3a86..ca91897fdd14 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -40,10 +40,26 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)->smi)
#if defined(CONFIG_PHYLIB) || defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+static int smi_wait_ready(struct mvgbe_device *dmvgbe)
+{
+ u32 timeout = MVGBE_PHY_SMI_TIMEOUT;
+ u32 smi_reg;
+
+ do {
+ smi_reg = MVGBE_REG_RD(MVGBE_SMI_REG);
+ if (timeout-- == 0) {
+ printf("Error: SMI busy timeout\n");
+ return -EFAULT;
+ }
+ } while (smi_reg & MVGBE_PHY_SMI_BUSY_MASK);
+
+ return 0;
+}
+
/*
* smi_reg_read - miiphy_read callback function.
*
- * Returns 16bit phy register value, or 0x on error
+ * Returns 16bit phy register value, or -EFAULT on error
*/
static int smi_reg_read(struct mii_dev *bus, int phy_adr, int devad,
int reg_ofs)
@@ -74,16 +90,9 @@ static int smi_reg_read(struct mii_dev *bus, int phy_adr,
int devad,
return -EFAULT;
}
- timeout = MVGBE_PHY_SMI_TIMEOUT;
/* wait till the SMI is not busy */
- do {
- /* read smi register */
- smi_reg = MVGBE_REG_RD(MVGBE_SMI_REG);
- if (timeout-- == 0) {
- printf("Err..(%s) SMI busy timeout\n", __func__);
- return -EFAULT;
- }
- } while (smi_reg & MVGBE_PHY_SMI_BUSY_MASK);
+ if (smi_wait_ready(dmvgbe) < 0)
+ return -EFAULT;
/* fill the phy address and regiser offset and read opcode */
smi_reg = (phy_adr << MVGBE_PHY_SMI_DEV_ADDR_OFFS)
@@ -119,10 +128,9 @@ static int smi_reg_read(struct mii_dev *bus, int phy_adr,
int devad,
}
/*
- * smi_reg_write - imiiphy_write callback function.
+ * smi_reg_write - miiphy_write callback function.
*
- * Returns 0 if write succeed, -EINVAL on bad parameters
- * -ETIME on timeout
+ * Returns 0 if write succeed, -EFAULT on error
*/
static int smi_reg_write(struct mii_dev *bus, int phy_adr, int devad,
int reg_ofs, u16 data)
@@ -131,7 +139,6 @@ static int smi_reg_write(struct mii_dev *bus, int phy_adr,
int devad,
struct mvgbe_device *dmvgbe = to_mvgbe(dev);
struct mvgbe_registers *regs = dmvgbe->regs;
u32 smi_reg;
- u32 timeout;
/* Phyadr write request*/
if (phy_adr == MV_PHY_ADR_REQUEST &&
@@ -147,19 +154,12 @@ static int smi_reg_write(struct mii_dev *bus, int
phy_adr, int devad,
}
if (reg_ofs > PHYREG_MASK) {
printf("Err..(%s) Invalid register offset\n", __func__);
- return -EINVAL;
+ return -EFAULT;
}
/* wait till the SMI is not busy */
- timeout = MVGBE_PHY_SMI_TIMEOUT;
- do {
- /* read smi register */
- smi_reg = MVGBE_REG_RD(MVGBE_SMI_REG);
- if (timeout-- == 0) {
- printf("Err..(%s) SMI busy timeout\n", __func__);
- return -ETIME;
- }
- } while (smi_reg & MVGBE_PHY_SMI_BUSY_MASK);
+ if (smi_wait_ready(dmvgbe) < 0)
+ return -EFAULT;
/* fill the phy addr and reg offset and write opcode and data */
smi_reg = (data << MVGBE_PHY_SMI_DATA_OFFS);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] buildman: Extract environment as part of each build
On Tue, May 29, 2018 at 5:24 PM Alex Kiernan wrote: > As we're building the boards, extract the default U-Boot environment to > uboot.env so we can interrogate it later. > Signed-off-by: Alex Kiernan > --- > Changes in v2: > - capture stderr/stdout so when the build fails we don't produce spurious >output as part of the build > tools/buildman/builderthread.py | 10 ++ > 1 file changed, 10 insertions(+) > diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py > index 0efe80d945..c84ba6acf1 100644 > --- a/tools/buildman/builderthread.py > +++ b/tools/buildman/builderthread.py > @@ -351,6 +351,16 @@ class BuilderThread(threading.Thread): > lines.append(size_result.stdout.splitlines()[1] + ' ' + >rodata_size) > +# Extract the environment from U-Boot and dump it out > +cmd = ['%sobjcopy' % self.toolchain.cross, '-O', 'binary', > + '-j', '.rodata.default_environment', > + 'env/built-in.o', 'uboot.env'] > +command.RunPipe([cmd], capture=True, > +capture_stderr=True, cwd=result.out_dir, > +raise_on_error=False, env=env) > +ubootenv = os.path.join(result.out_dir, 'uboot.env') > +self.CopyFiles(result.out_dir, build_dir, '', ['uboot.env']) > + > # Write out the image sizes file. This is similar to the output > # of binutil's 'size' utility, but it omits the header line and > # adds an additional hex value at the end of each line for the This is failing in Travis: https://travis-ci.org/akiernan/u-boot/jobs/385534243#L899 -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] travis.yml: Support RISC-V 64-bit
From: Rick Chen
Fix riscv: ax25-ae350 build fail problem
https://travis-ci.org/trini/u-boot/jobs/385147373
...
Building current source for 1 boards (1 thread, 2 jobs per thread)
riscv: + ax25-ae350
+arch/riscv/cpu/ax25/start.S: Assembler messages:
+arch/riscv/cpu/ax25/start.S:48: Error: unrecognized opcode `sd a2,0(t0)'
+arch/riscv/cpu/ax25/start.S:112: Error: unrecognized opcode `ld t5,0(t0)'
...
After apply the commit
configs: ax25-ae350: Set 64-bit as default configuration
Toolchain shall be also setuped with 64-bit in .travis.yml.
Signed-off-by: Rick Chen
Signed-off-by: Rick Chen
Reviewed-by: Chih-Mao Chen
Cc: Greentime Hu
---
.travis.yml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 937f028..7e90bc9 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -87,9 +87,9 @@ before_script:
fi
- if [[ "${TOOLCHAIN}" == "powerpc" ]]; then ./tools/buildman/buildman
--fetch-arch powerpc; fi
- if [[ "${TOOLCHAIN}" == "riscv" ]]; then
-wget
https://github.com/PkmX/riscv-prebuilt-toolchains/releases/download/20180111/riscv32-unknown-elf-toolchain.tar.gz
&&
-tar -C /tmp -xf riscv32-unknown-elf-toolchain.tar.gz &&
-echo -e "\n[toolchain-prefix]\nriscv =
/tmp/riscv32-unknown-elf/bin/riscv32-unknown-elf-" >> ~/.buildman;
+ wget
https://github.com/andestech/prebuilt/releases/download/20180530/riscv64-unknown-linux-gnu.tar.gz
&&
+tar -C /tmp -xf riscv64-unknown-linux-gnu.tar.gz &&
+echo -e "\n[toolchain-prefix]\nriscv =
/tmp/riscv64-unknown-linux-gnu/bin/riscv64-unknown-linux-gnu-" >> ~/.buildman;
fi
- if [[ "${QEMU_TARGET}" != "" ]]; then
git clone git://git.qemu.org/qemu.git /tmp/qemu;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ARM: kirkwood: remove automatic I2C config if DM_I2C is enabled
On 30.05.2018 10:14, Chris Packham wrote: The mach/config.h file would helpfully define CONFIG_SYS_I2C and CONFIG_SYS_I2C_MVTWSI if CONFIG_CMD_I2C was defined by the board. This conflicts with the way DM_I2C works. As a transitional measure don't automatically define these if CONFIG_DM_I2C is defined. It should be possible to remove this once all kirkwood boards are migrated to DM. Signed-off-by: Chris Packham --- Changes in v2: None Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Uboot send pull request
Hi Tom,
Please pull the following patch from u-boot-riscv into your tree.
Thanks!
The following changes since commit c3c863880479edeb5b08226e622d13c91326e4a7:
add FIT data-position & data-offset property support (2018-05-26 18:19:19
-0400)
are available in the Git repository at:
git://git.denx.de/u-boot-riscv.git
for you to fetch changes up to 6ffea11b89099d72029bc644f7664736ee7ca667:
travis.yml: Support RISC-V 64-bit (2018-05-30 16:21:30 +0800)
Alexander Graf (7):
riscv: Add setjmp/longjmp code
riscv: Enable function sections
riscv: Add EFI application infrastructure
riscv: Add board_quiesce_devices stub
efi_loader: Use EFI_CACHELINE_SIZE in the image loader too
distro: Extend with RISC-V defines
riscv: nx25: Enable distro boot
Rick Chen (16):
efi_loader: Enable RISC-V support
SPDX: Convert single license tags to Linux Kernel style
riscv: cpu: nx25: Rename as ax25
board: nx25-ae250: Rename as ax25-ae350
configs: nx25-ae250:Rename as ax25-ae350
doc: ae250: Rename as ae350
configs: ax25-ae350: Set 64-bit as default configuration
spi: atcspi200: Fix compiler warning
net: ftmac100: Fix compiler warning
riscv: dts: Sync DT with Linux Kernel
mmc: ftsdc010_mci: Sync compatible with DT mmc node
configs: ax25-ae350: Support cfi flash
riscv: dts: Support cfi flash
board: ax25-ae350: Support cfi flash
mtd: ftsmc020: Drop unsed code
travis.yml: Support RISC-V 64-bit
.travis.yml | 6 ++--
arch/riscv/Kconfig | 6 ++--
arch/riscv/config.mk | 7 +++-
arch/riscv/cpu/{nx25 => ax25}/Makefile | 0
arch/riscv/cpu/{nx25 => ax25}/cpu.c | 2 +-
arch/riscv/cpu/{nx25 => ax25}/start.S| 0
arch/riscv/cpu/{nx25 => ax25}/u-boot.lds | 18
+-
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/ae250.dts | 97
---
arch/riscv/dts/ae350.dts | 149
++
arch/riscv/include/asm/mach-types.h | 10
+++---
arch/riscv/include/asm/setjmp.h | 25
++
arch/riscv/include/asm/u-boot-riscv.h| 1 +
arch/riscv/lib/Makefile | 12
+++
arch/riscv/lib/bootm.c | 4 +++
arch/riscv/lib/crt0_riscv_efi.S | 151
arch/riscv/lib/elf_riscv32_efi.lds | 71
++
arch/riscv/lib/elf_riscv64_efi.lds | 71
++
arch/riscv/lib/reloc_riscv_efi.c | 98
arch/riscv/lib/setjmp.S | 65
+++
board/AndesTech/{nx25-ae250 => ax25-ae350}/Kconfig | 10
+++---
board/AndesTech/ax25-ae350/MAINTAINERS | 6
board/AndesTech/{nx25-ae250 => ax25-ae350}/Makefile | 2 +-
board/AndesTech/{nx25-ae250/nx25-ae250.c => ax25-ae350/ax25-ae350.c} | 36
++-
board/AndesTech/nx25-ae250/MAINTAINERS | 6
cmd/Kconfig | 2 +-
configs/{nx25-ae250_defconfig => ax25-ae350_defconfig} | 11
--
doc/{README.NX25 => README.AX25} | 2 +-
doc/{README.ae250 => README.ae350} | 34
+-
drivers/mmc/ftsdc010_mci.c | 2 +-
drivers/mtd/Makefile | 1 -
drivers/mtd/ftsmc020.c | 37
drivers/net/ftmac100.c | 14
drivers/spi/atcspi200_spi.c | 6 ++--
include/config_distro_bootcmd.h | 11
++
include/configs/{nx25-ae250.h => ax25-ae350.h} | 55
+
include/efi_loader.h
[U-Boot] [PATCH v2 2/2] ARM: add SBx81LIFKW board
This is a series of line cards for Allied Telesis's SBx8100 chassis
switch. The CPU block is common to the SBx81GS24a, SBx81XS6, SBx81XS16
and SBx81GT40 cards collectively referred to as SBx81LIFKW in u-boot.
Reviewed-by: Stefan Roese
Signed-off-by: Chris Packham
---
This is the board I've been using for testing the device tree support
for kirkwood. The Ethernet arrangement is a bit complicated and doesn't
currently work on u-boot#master but I can test SPI and I2C.
Changes in v2:
- remove unnecessary platform.S
arch/arm/dts/kirkwood-atl-sbx81lifkw.dts| 133 ++
arch/arm/mach-kirkwood/Kconfig | 4 +
board/alliedtelesis/SBx81LIFKW/Kconfig | 12 ++
board/alliedtelesis/SBx81LIFKW/MAINTAINERS | 7 +
board/alliedtelesis/SBx81LIFKW/Makefile | 7 +
board/alliedtelesis/SBx81LIFKW/kwbimage.cfg | 47 +
board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c | 187
configs/SBx81LIFKW_defconfig| 33
include/configs/SBx81LIFKW.h| 124 +
9 files changed, 554 insertions(+)
create mode 100644 arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
create mode 100644 board/alliedtelesis/SBx81LIFKW/Kconfig
create mode 100644 board/alliedtelesis/SBx81LIFKW/MAINTAINERS
create mode 100644 board/alliedtelesis/SBx81LIFKW/Makefile
create mode 100644 board/alliedtelesis/SBx81LIFKW/kwbimage.cfg
create mode 100644 board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
create mode 100644 configs/SBx81LIFKW_defconfig
create mode 100644 include/configs/SBx81LIFKW.h
diff --git a/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
b/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
new file mode 100644
index ..e5b1efa1415a
--- /dev/null
+++ b/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+
+/ {
+ model = "Allied Telesis SBx81LIFKW Board";
+ compatible = "atl,SBx81LIFKW", "marvell,kirkwood-88f6281",
+"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0800>; /* 128 MB */
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ stdout-path =
+ };
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ spi0 =
+ };
+
+ dsa {
+ compatible = "marvell,dsa";
+ #address-cells = <2>;
+ #size-cells = <0>;
+ dsa,ethernet = <>;
+ dsa,mii-bus = <>;
+ status = "okay";
+
+ switch@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1 0>;
+
+ port@0 {
+ reg = <0>;
+ label = "internal0";
+ };
+ port@1 {
+ reg = <1>;
+ label = "internal1";
+ };
+ port@8 {
+ reg = <8>;
+ label = "internal8";
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ port@9 {
+ reg = <9>;
+ label = "internal9";
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ port@10 {
+ reg = <10>;
+ label = "cpu";
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p128", "jedec,spi-nor", "spi-flash";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ mode = <0>;
+
+ partition@u-boot {
+ reg = <0x 0x00c0>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x00c0 0x0004>;
+ label = "u-boot-env";
+ };
+ partition@unused {
+ reg = <0x0010 0x00f0>;
+ label = "unused";
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ eeprom@52 {
+ compatible = "atmel,24c04";
+
[U-Boot] [PATCH v2 1/2] ARM: kirkwood: remove automatic I2C config if DM_I2C is enabled
The mach/config.h file would helpfully define CONFIG_SYS_I2C and CONFIG_SYS_I2C_MVTWSI if CONFIG_CMD_I2C was defined by the board. This conflicts with the way DM_I2C works. As a transitional measure don't automatically define these if CONFIG_DM_I2C is defined. It should be possible to remove this once all kirkwood boards are migrated to DM. Signed-off-by: Chris Packham --- Changes in v2: None arch/arm/mach-kirkwood/include/mach/config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-kirkwood/include/mach/config.h b/arch/arm/mach-kirkwood/include/mach/config.h index 98639114dbdd..3482944c11de 100644 --- a/arch/arm/mach-kirkwood/include/mach/config.h +++ b/arch/arm/mach-kirkwood/include/mach/config.h @@ -116,7 +116,7 @@ /* * I2C related stuff */ -#ifdef CONFIG_CMD_I2C +#if defined(CONFIG_CMD_I2C) && !defined(CONFIG_DM_I2C) #ifndef CONFIG_SYS_I2C_SOFT #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
On 30.05.2018 07:10, Jagan Teki wrote: On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt wrote: Hi Jagan, On 21.05.2018 17:09, Jagan Teki wrote: Hi Simon, On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt wrote: On 14.05.2018 09:47, Simon Goldschmidt wrote: On 14.05.2018 09:22, Jagan Teki wrote: On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt wrote: + Marek for the socfpga platform, see below On 07.12.2017 06:49, Jagan Teki wrote: On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon wrote: + Lukasz (as a reviewer of my patch[1]) On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: This is the patch[1] for 4-byte addressing, but I would wonder how can proceed operations with 4-byte if we disable during probe. [1] http://git.denx.de/?p=u-boot- spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca OK, so your patch does something different than what I did. I was trying to keep the change to U-Boot as small as possible, only fixing this issue I was seeing: After a soft-reboot where the SPI chip was not reset, it is left in 4-byte addressing mode (linux uses this mode, obviously). Remember that 4-byte mode is not a permanent setting, so we can enter and leave it any time we like by issuing a command. U-Boot uses the Bank Address Register (BAR) for spi flash chips with more than 16 MByte, so it impclitly assumes that the chip is in 3-byte address mode. As I see it, your patch is worth a discussion named "should we use 4-byte addressing mode on spi flash chips?". I do think this is a better alternative than writing BAR! But this change probably needs discussion and testing. OK, will review your patch. Any update here? The last input on this is about five months old! This is the last patch I need to run my socfpga board from qspi. I added Marek to the discussion as at least the SoCrates board does not have a reset connected to the qspi chip and needs this as well. Note that the system boot rom does not have a problem with the chip being in 4-byte mode but SPL fails to load U-Boot from qspi. Does Linux do this stuff? say my flash in 4-byte and flashed SPL and rebooted. Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte opcodes (which is why I'm seeing this bug after all). OK, this is not the latest kernel, but it's LTS, so I think U-Boot should handle this Kernel. What happens in Linux (4.9) is that depending on the flash size, 4-byte mode is *always* enabled. And it stays enabled after soft reboot. So consequently, we have to *always* disable it in U-Boot. In newer versions, they still use 4-byte mode if the flash chip does not support 4-byte opcodes. I suppose that would fix it for me, too, but I'm stuck with LTS for now. Do you need any more information here? I'd really love to get this into 2018.07, finally. As I said before, this is the last patch missing for socfpga cyclone5 running from qspi. The point I'm not clear is we don't have 4-byte addressing (we are using Bank addressing for > 16MiB) so how come we disable 4-byte addressing for the sake of other software blocks enabled it? It's like a hack to me. I understand your point. However, there *are* SPI chips without a reset line. And if linux brings them into 4-byte address mode and then the system gets a warm reset e.g. by the watchdog, where do you suggest to set the chip back to 3-byte address mode? What are those chips? For example the EPCQ256N mounted on the EBV Socrates board (Cyclone V SoC), see this doc, pinout is in chapter 1.11.2: https://www.altera.com/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf what if we have 4-byte addressing mode in U-Boot, we completely operate these into 3-byte mode by disabling 4-byte mode? Ehrm, we don't have 4-byte addressing mode in U-Boot. That's the problem. If we would, we would surely execute the opcode I have added and explicitly set the device into 4-byte mode. That would solve the problem. The opcode I have added does *NOT* disable 4-byte mode but just leaves it. You can re-enter it at any time. You can see this opcode as setting a flag inside the chip that tells it how many addressing bytes it expects. Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu (30.05.2018)
Dear Marek, Please find a PR for DFU. The following changes since commit c3c863880479edeb5b08226e622d13c91326e4a7: add FIT data-position & data-offset property support (2018-05-26 18:19:19 -0400) are available in the git repository at: git://git.denx.de/u-boot-dfu.git for you to fetch changes up to c6e8522697a46aa847e9eac997541c205125f23d: fastboot: Update fastboot documentation (2018-05-29 17:54:04 +0200) Alex Kiernan (18): fastboot: Move fastboot to drivers/fastboot fastboot: Refactor fastboot_okay/fail to take response fastboot: Extract fastboot_okay/fail to fb_common.c fastboot: Correct dependencies in FASTBOOT_FLASH fastboot: Add missing newlines fastboot: Remove FIXME for CONFIG_FASTBOOT_...NAME fastboot: Fix parameter types in _fb_nand_write fastboot: Rename fb_set_reboot_flag to fastboot_set_reboot_flag fastboot: Extract common definitions from USB fastboot fastboot: Rename public fb_ functions to fastboot_ ti: fastboot: Move weak overrides to board files fs: Add fs_get_type_name to return current filesystem name fastboot: Migrate FASTBOOT_FLASH_NAND_TRIMFFS to Kconfig mmc: Separate "mmc swrite" from fastboot net: fastboot: Merge AOSP UDP fastboot fastboot: Add support for 'oem format' command usb: fastboot: Convert USB f_fastboot to shared fastboot fastboot: Update fastboot documentation Seung-Woo Kim (1): gadget: f_thor: Fix memory leaks of usb request and its buffer arch/arm/Kconfig | 2 -- arch/arm/mach-omap2/boot-common.c| 10 -- arch/arm/mach-omap2/utils.c | 4 +-- arch/arm/mach-rockchip/rk3128-board.c| 4 +-- arch/arm/mach-rockchip/rk322x-board.c| 4 +-- board/amazon/kc1/kc1.c | 2 +- board/lg/sniper/sniper.c | 2 +- board/ti/am57xx/board.c | 10 ++ board/ti/common/Kconfig | 1 - board/ti/dra7xx/evm.c| 10 ++ cmd/Kconfig | 22 ++-- cmd/fastboot.c | 91 +--- cmd/mmc.c| 14 common/Makefile | 14 configs/A13-OLinuXino_defconfig | 1 + configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + configs/A20-OLinuXino-Lime2_defconfig| 1 + configs/A20-Olimex-SOM204-EVB-eMMC_defconfig | 1 + configs/A20-Olimex-SOM204-EVB_defconfig | 1 + configs/Bananapi_m2m_defconfig | 1 + configs/Cubietruck_defconfig | 1 + configs/Sinlinx_SinA33_defconfig | 1 + configs/am335x_boneblack_defconfig | 7 ++-- configs/am335x_boneblack_vboot_defconfig | 2 +- configs/am335x_evm_defconfig | 2 +- configs/am335x_evm_nor_defconfig | 2 +- configs/am335x_evm_norboot_defconfig | 2 +- configs/am335x_evm_norboot_defconfig | 2 +- configs/am335x_evm_spiboot_defconfig | 2 +- configs/am335x_evm_usbspl_defconfig | 2 +- configs/am57xx_evm_defconfig | 13 +++ configs/am57xx_hs_evm_defconfig | 13 +++ configs/bcm23550_w1d_defconfig | 2 +- configs/bcm28155_ap_defconfig| 2 +- configs/birdland_bav335a_defconfig | 2 +- configs/birdland_bav335b_defconfig | 2 +- configs/cgtqmx6eval_defconfig| 2 +- configs/chromebit_mickey_defconfig | 5 +-- configs/chromebook_jerry_defconfig | 5 +-- configs/chromebook_minnie_defconfig | 5 +-- configs/dra7xx_evm_defconfig | 11 +++--- configs/dra7xx_hs_evm_defconfig | 11 +++--- configs/evb-rk3036_defconfig | 5 +-- configs/evb-rk3128_defconfig | 9 ++--- configs/evb-rk3229_defconfig | 5 +-- configs/evb-rk3288_defconfig | 5 +-- configs/evb-rk3328_defconfig | 7 ++-- configs/fennec-rk3288_defconfig | 5 +-- configs/firefly-rk3288_defconfig | 5 +-- configs/imx6dl_mamoj_defconfig | 2 +- configs/kc1_defconfig| 2 +- configs/kylin-rk3036_defconfig | 5 +-- configs/miqi-rk3288_defconfig| 5 +-- configs/mx6qsabrelite_defconfig | 2 +- configs/mx6sabresd_defconfig | 2 +- configs/nitrogen6dl2g_defconfig
[U-Boot] [PATCH] arm64: zynqmp: Add TTC clocks
From: Rajan Vaja
PS clock(LPD_APB_CLK) is default clock for TTC. Add this clock
entry in TTC nodes.
Signed-off-by: Rajan Vaja
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-clk-ccf.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/zynqmp-clk-ccf.dtsi b/arch/arm/dts/zynqmp-clk-ccf.dtsi
index b18d8d19c304..d969ba0f4b89 100644
--- a/arch/arm/dts/zynqmp-clk-ccf.dtsi
+++ b/arch/arm/dts/zynqmp-clk-ccf.dtsi
@@ -248,6 +248,22 @@
clocks = < 59>, < 31>;
};
+ {
+ clocks = < 31>;
+};
+
+ {
+ clocks = < 31>;
+};
+
+ {
+ clocks = < 31>;
+};
+
+ {
+ clocks = < 31>;
+};
+
{
clocks = < 56>, < 31>;
};
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Disable WP on zcu111
On this board there is SD slot without WP connected.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu111-revA.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/zynqmp-zcu111-revA.dts
b/arch/arm/dts/zynqmp-zcu111-revA.dts
index 4002d7880610..aa9055b7152a 100644
--- a/arch/arm/dts/zynqmp-zcu111-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu111-revA.dts
@@ -500,6 +500,7 @@
{
status = "okay";
no-1-8-v;
+ disable-wp;
xlnx,mio_bank = <1>;
};
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] arm: kirkwood: lsxl: Add SPI driver model support
On 29.05.2018 23:13, Michael Walle wrote: This patch shows how to enable driver model support for the LS-CHLv2 and LS-XHL boards. There are a couple of open questions: - do I need the u-boot,dm-pre-reloc tags in the device tree? This property is only needed for SPL build targets - which Kirkwood currently is not (AFAIK). - should mach/config.h define CONFIG_DM_SEQ_ALIAS? No. It defaults to "y" already. And we should not move options into the config headers anymore but put them into the Kconfig system instead. - how can we split this patch or are there any other pending patches which does the same and I didn't catch these. I see no need to split this patch. There are the patches from Chris moving Kirkwood to device-tree - which you most likely already know. Most of them are applied. This patch is based on the http://git.denx.de/u-boot-marvell.git (master branch) and needs the following patches, which are still pending: https://patchwork.ozlabs.org/patch/909618/ https://patchwork.ozlabs.org/patch/909617/ https://patchwork.ozlabs.org/patch/909973/ Signed-off-by: Michael Walle Tested-by: Michael Walle I think there is no need to add the "Tested-by" tag for the patch author. It should be obvious that you have tested this patch. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] enable CONFIG_DISTRO_DEFAULTS for LS-CHLv2 board
On 29.05.2018 23:13, Michael Walle wrote: Synchronize it with the LS-XHL board. Signed-off-by: Michael Walle Please use a more descriptive patch subject next time, like: arm: kirkwood: enable CONFIG_DISTRO_DEFAULTS for LS-CHLv2 board Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i2c: mvtwsi: disable i2c slave on Armada 38x
On 29.05.2018 19:55, Baruch Siach wrote:
Hi Stefan,
On Tue, May 29, 2018 at 08:11:55AM +0200, Stefan Roese wrote:
On 29.05.2018 06:45, Baruch Siach wrote:
Equivalent code that disables the hidden i2c0 slave already exists in
the Turris Omnia platform specific code. But this hidden i2c0 slave that
interferes the i2c bus is not board specific. Armada 38x SoCs and at
least some Kirkwood variants are affected as well. Add code to disable
this slave to the i2c bus driver to make it work on all affected
hardware.
Use the bind callback because we want this to always run at boot,
regardless of whether U-Boot uses the i2c bus.
Cc: Rabeeh Khoury
Cc: Chris Packham
Reviewed-by: Stefan Roese
Reviewed-by: Heiko Schocher
Signed-off-by: Baruch Siach
---
[snip]
+static int mvtwsi_i2c_bind(struct udevice *bus)
+{
+ struct mvtwsi_registers *twsi = devfdt_get_addr_ptr(bus);
+
+ /* Disable the hidden slave in i2c0 of these platforms */
+ if ((IS_ENABLED(CONFIG_ARMADA_38X) || IS_ENABLED(CONFIG_KIRKWOOD))
We could better use the compatible check here:
if (device_is_compatible(dev, "marvell,mv64xxx-i2c"))
This is not an equivalent check. marvell,mv64xxx-i2c covers other SoCs that
might not be affected.
I only see Marvell Kirkwood and Armada XP / A38x boards using this
compatible property.
Furthermore, this makes a build time test into a run time one. This bloats the
code for platforms like Allwinner that are unlikely to be affected.
Yes, this is a disadvantage.
What is the advantage of device_is_compatible()? Is it feasible to build a
multi-platform U-Boot image?
The main advantage is, that multiple platforms can be supported
in one single image. This is how its done in Linux. I agree, that
this is not so common in U-Boot, e.g. to support Orion and Kirkwood
in one single U-Boot image. So lets keep it this way and apply
this patch version if nobody else objects.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
