Re: [PATCH] clk: Add more information to debug messages
On Fri, 20 Mar 2020 01:53:16 -0400
Sean Anderson wrote:
> Some of the debug messages in the clock subsystem can be made more
> informative by adding the clock name or adding the explicit error.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/clk/clk-uclass.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 71878474eb..d44df05680 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -237,8 +237,8 @@ static int clk_set_default_parents(struct udevice
> *dev, int stage) continue;
>
> if (ret < 0) {
> - debug("%s: failed to reparent clock %d for
> %s\n",
> - __func__, index, dev_read_name(dev));
> + debug("%s: failed to reparent clock %d for
> %s (err = %d)\n",
> + __func__, index, dev_read_name(dev),
> ret); return ret;
> }
> }
> @@ -295,8 +295,8 @@ static int clk_set_default_rates(struct udevice
> *dev, int stage) ret = clk_set_rate(, rates[index]);
>
> if (ret < 0) {
> - debug("%s: failed to set rate on clock index
> %d (%ld) for %s\n",
> - __func__, index, clk.id,
> dev_read_name(dev));
> + debug("%s: failed to set rate on clock index
> %d (%ld) for %s (err = %d)\n",
> + __func__, index, clk.id,
> dev_read_name(dev), ret); break;
> }
> }
> @@ -436,7 +436,7 @@ ulong clk_get_rate(struct clk *clk)
> {
> const struct clk_ops *ops;
>
> - debug("%s(clk=%p)\n", __func__, clk);
> + debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> if (!clk_valid(clk))
> return 0;
> ops = clk_dev_ops(clk->dev);
> @@ -452,7 +452,7 @@ struct clk *clk_get_parent(struct clk *clk)
> struct udevice *pdev;
> struct clk *pclk;
>
> - debug("%s(clk=%p)\n", __func__, clk);
> + debug("%s(clk=%p) \"%s\"\n", __func__, clk, clk->dev->name);
> if (!clk_valid(clk))
> return NULL;
>
> @@ -469,7 +469,7 @@ long long clk_get_parent_rate(struct clk *clk)
> const struct clk_ops *ops;
> struct clk *pclk;
>
> - debug("%s(clk=%p)\n", __func__, clk);
> + debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> if (!clk_valid(clk))
> return 0;
>
> @@ -492,7 +492,8 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
> {
> const struct clk_ops *ops;
>
> - debug("%s(clk=%p, rate=%lu)\n", __func__, clk, rate);
> + debug("%s(clk=%p \"%s\", rate=%lu)\n", __func__, clk,
> clk->dev->name,
> + rate);
> if (!clk_valid(clk))
> return 0;
> ops = clk_dev_ops(clk->dev);
> @@ -507,7 +508,8 @@ int clk_set_parent(struct clk *clk, struct clk
> *parent) {
> const struct clk_ops *ops;
>
> - debug("%s(clk=%p, parent=%p)\n", __func__, clk, parent);
> + debug("%s(clk=%p \"%s\", parent=%p \"%s\")\n", __func__, clk,
> + clk->dev->name, parent, parent->dev->name);
> if (!clk_valid(clk))
> return 0;
> ops = clk_dev_ops(clk->dev);
> @@ -524,7 +526,7 @@ int clk_enable(struct clk *clk)
> struct clk *clkp = NULL;
> int ret;
>
> - debug("%s(clk=%p)\n", __func__, clk);
> + debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> if (!clk_valid(clk))
> return 0;
> ops = clk_dev_ops(clk->dev);
> @@ -584,7 +586,7 @@ int clk_disable(struct clk *clk)
> struct clk *clkp = NULL;
> int ret;
>
> - debug("%s(clk=%p)\n", __func__, clk);
> + debug("%s(clk=%p) \"%s\"\n", __func__, clk, clk->dev->name);
> if (!clk_valid(clk))
> return 0;
> ops = clk_dev_ops(clk->dev);
Acked-by: Lukasz Majewski
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpIvjPr7ygOX.pgp
Description: OpenPGP digital signature
Re: [PATCH] mtd: spi-nor-core: call WATCHDOG_RESET() in spi_nor_ready()
On 19/03/20 7:20 pm, Rasmus Villemoes wrote: > On 19/03/2020 14.23, Vignesh Raghavendra wrote: >> > >>> For the read side, it seems that just replacing the UINT_MAX in the two >>> copies of spi_nor_read_data with some smaller constant should suffice. >>> But I don't know if I should make that smaller constant a CONFIG_* >>> option or just pick something like 256K. Thoughts? >> >> Breaking reads into smaller units unconditionally will cause performance >> regressions. But I would like to avoid adding new CONFIG option as well. > > Hm, but how much are we talking about? I can't imagine WATCHDOG_RESET() > taking much more than 10us - especially the rate-limited one that has an > early return just based on reading the current time will be practically > free to call. For me, reading 256K takes about 200ms, which I assume is > a rather typical value. Even if I'm off by an order of magnitude on both > numbers, we're talking about adding an extra 100us for every 20ms, i.e. > 0.5%. And that's extremely pessimistic. > 256K for 200ms is <2 MB/s which is pretty slow IMO. QSPI and OSPIs flashes are capable of up to 400MB/s read throughput. Some of the drivers that support such faster flashes use DMA to achieve this and therefore have higher setup overhead per read request. Most SPI drivers are not optimized and reconfigure registers for every read requests which adds to the overhead. Splitting of transfers into 256K unconditionally would degrade performance for such platforms (irrespective of whether or not watchdog is present). >> How about resetting the watchdog in the SPI driver's read >> implementation? > > I'd prefer something done in the generic layer, not something specific > to this SOC (because next month I'll have another customer with another > board based on some ARM SOC that also decided to put on an aggressive > gpio watchdog, and next month yet another...). > So, there should at least be a config option at the minimum. OR determine the length of transfer possible before watchdog timeout happens by looking at bus frequency and watchdog timeout value. > Or setting max_read_size (in struct spi_slave) to >> smaller value in the SPI controller driver to force fragmentation of reads? > > Even if one forces fragmentation in that way, the generic layer would > still need to grow a WATCHDOG_RESET() call in the read loop, no? It also > seems to be an abuse of max_read_size. > I agree that read loop should call WATCHDOG_RESET() Regards Vignesh
Re: [PATCH v3 0/3] Add command to display or save Linux PStore dumps
Dear Heinrich, In message you wrote: > > > To me this sounds very much like what you are adding here (plus a > > few features more). Does it make sense to unify such code? > > It seems you are relating to > https://lore.kernel.org/lkml/844oyrqvvb@sauna.l.org/t/ No, I'm not. I was talking of my own code from many, many years ago. > ramoops in Linux is exactly doing what was suggested in 2009. You can > find the Documentation/admin-guide/ramoops.rst We had this in U-Boot long before that time. It was a key requirement when we added POST support in 2002. > git grep -GHrn 'shared log' finds nothing in U-Boot. So if any part of > the old implementation in U-Boot exists, could you, please, point us to > the coding. The shared log buffer support was added by commit 56f94be3ef63: commit 56f94be3ef63732384063e110277ed89701b6471 (tag: LABEL_2002_11_05_1735) Author: Wolfgang Denk Date: Tue Nov 5 16:35:14 2002 + * Add support for log buffer which can be passed to Linux kernel's syslog mechanism; used especially for POST results. * Patch by Klaus Heydeck, 31 Oct 2002: Add initial support for kup4k board The code was mainly in common/cmd_log.c, but this got heahily rewritten and is now in cmd/log.c ; apparently this got lost (like the original copyright, sic!) when Simon modified / rewrote this driver. For history, try: git log --follow -- common/cmd_log.c > If the original design never made it into Linux and there is an > established Linux interface since 2011, I would plead to eliminate any > remaining non-compliant coding from U-Boot should it exist. I understand what Linus has is one-way, only focussing on crash dump, i. e. it does not allow to pass information from U-Boot to Linux? Also, my understanding is that the changes needed in Linux are pretty small. Maybe Heiko can comment on that... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ken Dodd’s dad’s dog’s dead.
[PATCH] configs: ls1012afrwy: fix wrong env of board
Fix wrong environment variable of board for ls1012afrwy Signed-off-by: Biwen Li --- include/configs/ls1012afrwy.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h index 8ed4defa21..aa57320ac2 100644 --- a/include/configs/ls1012afrwy.h +++ b/include/configs/ls1012afrwy.h @@ -8,6 +8,9 @@ #include "ls1012a_common.h" +#undef CONFIG_SYS_BOARD +#define CONFIG_SYS_BOARD "ls1012afrwy" + /* Board Rev*/ #define BOARD_REV_A_B 0x0 #define BOARD_REV_C0x0008 -- 2.17.1
Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
On Tue, Mar 17, 2020 at 4:01 AM Simon Goldschmidt wrote: > > Am 16.03.2020 um 20:55 schrieb Dalon L Westergreen: > > > > > > On Mon, 2020-03-16 at 20:06 +0100, Marek Vasut wrote: > >> On 3/16/20 8:04 PM, Simon Goldschmidt wrote: > >>> Am 16.03.2020 um 19:04 schrieb Dalon L Westergreen: > > On Thu, 2020-03-12 at 16:57 +0100, Marek Vasut wrote: > > On 3/12/20 4:54 PM, Dalon L Westergreen wrote: > > [...] > > > > (thanks for fixing your mailer :)) > > > >>> The problem was that this was causing weird sporadic hangs > >>> on > >>> Gen5, > >>> which is why it was removed. So until there is an > >>> explanation for > >>> those > >>> hangs, I'm not really OK with this. > >> > >> These sporadic hangs you saw were on devices without an FPGA > >> image > >> directly > >> accessing the SDRAM ports, right? > > > > Yes > > > >>> Maybe the application of static config should happen in SPL, > >>> before > >>> the > >>> DRAM is running, or something like that ? > >> > >> Thinking this further, limiting it to applying in SPL is not a > >> good > >> idea > >> since > >> that prevents us from implementing different FPGA > >> images/configs by > >> loading a > >> config later in the boot (i.e. in U-Boot from a FIT-image). > > > > Well, but later we have SDRAM running and we cannot make it go > > idle, > > can > > we? > > > >> > >> Unfortunately the sdram cfg apply must occur AFTER the fpga is > >> configured. This > >> is because the FPGA drives configuration bits, around the interfaces > >> datawidth > >> for example, that are used in setting up the dram interface. I > >> believe the > >> intent is for the command to only run when the ridge enable function > >> is > >> called. > > > > So that's one part of the fix -- only run this apply_static_cfg if the > > bitstream uses the F2S bridge. > > actually, the restriction is to apply this only if the FPGA is > configured, > whether the bridge is used is irrelevant. you can further restrict this > to only when the bridge is used, but to me that means devicetree entries > or something to determine whether it is used. > >>> > >>> In my opinion, we need an FPGA-specific devicetree (or something > >>> similar) to describe the FPGA image, anyway. > >> > >> Like a DTO ? > > > > DTOs are how i suggest solving this in linux, so i would assume a dto would > > be best here too. > > Yes. That DTO should be beside the FPGA image, either in a FIT image or > just loaded separately. It should contain pin settings, bridge settings etc. > > However, to ensure the bus is idle, we still would have to limit > applying that config bit to before RAM is set up, so quite early in SPL, > right? I cannot see how that would work, given the limit of 64K. Plus > it's kind of a bad boot flow to configure the FPGA before even starting > U-Boot... There is usecase user may want to program fpga image in Uboot command prompt. It will have problem too. socfpga_sdram_apply_static_cfg() is written in assembly code and the code is fit to one cacheline size (32 bytes). This at least make sure CPU no access to SDRAM when run apply static cfg code in uboot. Frankly, this can't prevent external master access to SDRAM. Marek, I found code in drivers/fpga/socfpga_gen5.c:socfpga_load() write to SDR_CTRLGRP_FPGAPORTRST_ADDRESS register, but doesn't write to call to socfpga_sdram_apply_static_cfg() function. This means FPGA port is not put into reset before program fpga image. Suspect this might reason it cause sporadic hangs. Stay safe everyone. Regards Ley Foon
Re: [PATCH 1/1] vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader.
On 02/03/2020 14:15, Kristian Amlie wrote:
On 02/03/2020 14:01, Tom Rini wrote:
On Mon, Mar 02, 2020 at 11:22:27AM +0100, Kristian Amlie wrote:
On 28/02/2020 16:32, Tom Rini wrote:
On Tue, Feb 25, 2020 at 06:22:16PM +0100, Kristian Amlie wrote:
EFI was disabled in f95b8a4b5f64f because of the missing DTB file,
and indeed, the DTB file is required to load recent versions of GRUB
(2.04) correctly.
Signed-off-by: Kristian Amlie
---
configs/vexpress_ca9x4_defconfig | 2 +-
include/configs/vexpress_common.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
index 2119df6b10..6bd1f253b6 100644
--- a/configs/vexpress_ca9x4_defconfig
+++ b/configs/vexpress_ca9x4_defconfig
@@ -34,4 +34,4 @@ CONFIG_SMC911X_32_BIT=y
CONFIG_BAUDRATE=38400
CONFIG_CONS_INDEX=0
CONFIG_OF_LIBFDT=y
-# CONFIG_EFI_LOADER is not set
+CONFIG_DEFAULT_FDT_FILE="vexpress-v2p-ca9.dtb"
diff --git a/include/configs/vexpress_common.h
b/include/configs/vexpress_common.h
index 7f215a6707..e73658a9e6 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -207,7 +207,8 @@
"devtmpfs.mount=0 vmalloc=256M\0" \
"bootflash=run flashargs; " \
"cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk}; " \
- "bootm ${kernel_addr} ${ramdisk_addr_r}\0"
+ "bootm ${kernel_addr} ${ramdisk_addr_r}\0" \
+ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0"
/* FLASH and environment organization */
#define PHYS_FLASH_SIZE 0x0400 /* 64MB */
Did you test build all of the vexpress platforms? There's a common file
for the 5 different ones. Thanks!
The two boards vexpress_aemv8a_juno_defconfig and
vexpress_aemv8a_semi_defconfig don't compile at all, even without the
patch. The other three compile just fine both with and without the patch.
Don't compile where / how? All 5 compile with their defconfigs today.
Thanks!
Oh, those are 64-bit boards, sorry I missed that part. All five are
compiling fine then, both with and without the patch!
Anything I can do to help this along?
--
Kristian
signature.asc
Description: OpenPGP digital signature
[PATCH] docs: Fix conf.py for Sphinx 2.0
From: Jonathan Corbet
commit 3bc8088464712fdcb078eefb68837ccfcc413c88 upstream.
Our version check in Documentation/conf.py never envisioned a world where
Sphinx moved beyond 1.x. Now that the unthinkable has happened, fix our
version check to handle higher version numbers correctly.
Signed-off-by: Jonathan Corbet
[rebase for u-boot]
Signed-off-by: Sean Anderson
---
doc/conf.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/conf.py b/doc/conf.py
index 0772fb6f0c..8bb27ad9e2 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -37,7 +37,7 @@ needs_sphinx = '1.3'
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
'kfigure']
# The name of the math extension changed on Sphinx 1.4
-if major == 1 and minor > 3:
+if (major == 1 and minor > 3) or (major > 1):
extensions.append("sphinx.ext.imgmath")
else:
extensions.append("sphinx.ext.pngmath")
--
2.25.1
RE: [PATCH 11/12] board: fsl: ls2080a: Initialize the GIC redistributor tables
Hi Bin,
Thanks a lot for your comments!
> -Original Message-
> From: Bin Meng
> Sent: 2020年3月19日 19:57
> To: Z.q. Hou
> Cc: U-Boot Mailing List ; Priyanka Jain
>
> Subject: Re: [PATCH 11/12] board: fsl: ls2080a: Initialize the GIC
> redistributor
> tables
>
> On Thu, Mar 19, 2020 at 1:44 PM Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > Fixup kernel DT to reserve memory for GIC redistributor tables, and
> > initialize the redistributor configuration and pending tables using
> > the reserved memory.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > board/freescale/ls2080aqds/ls2080aqds.c | 14 ++
> > board/freescale/ls2080ardb/ls2080ardb.c | 14 ++
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
> > b/board/freescale/ls2080aqds/ls2080aqds.c
> > index 4034bdee28..fd63e6bc76 100644
> > --- a/board/freescale/ls2080aqds/ls2080aqds.c
> > +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> > @@ -3,6 +3,7 @@
> > * Copyright 2015 Freescale Semiconductor
> > */
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -12,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -21,12 +23,14 @@
> > #include
> > #include
> > #include
> > +#include
> >
> >
> > #include "../common/qixis.h"
> > #include "ls2080aqds_qixis.h"
> > #include "../common/vid.h"
> >
> > +#define GIC_LPI_SIZE 0x20
> > #define PIN_MUX_SEL_SDHC 0x00
> > #define PIN_MUX_SEL_DSPI 0x0a
> > #define SCFG_QSPICLKCTRL_DIV_20(5 << 27)
> > @@ -323,6 +327,8 @@ int ft_board_setup(void *blob, bd_t *bd) {
> > u64 base[CONFIG_NR_DRAM_BANKS];
> > u64 size[CONFIG_NR_DRAM_BANKS];
> > + u64 gic_lpi_base;
> > + int ret;
> >
> > ft_cpu_setup(blob, bd);
> >
> > @@ -333,6 +339,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> > size[1] = gd->bd->bi_dram[1].size;
> >
> > #ifdef CONFIG_RESV_RAM
> > +#ifdef CONFIG_GIC_V3_ITS
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE,
> SZ_64K);
> > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
> GIC_LPI_SIZE);
> > + if (!ret) {
> > + if (gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > + debug("%s: failed to init gic-lpi-tables\n",
> __func__);
> > + }
>
> Is this board-specific fix-up, or LS2080 specific? If latter, we should put
> it in
> the LS2080 SoC codes.
It's a SoC level fixup, I'll refine the series in v2.
Thanks,
Zhiqiang
>
> > +#endif
> > /* reduce size if reserved memory is within this bank */
> > if (gd->arch.resv_ram >= base[0] &&
> > gd->arch.resv_ram < base[0] + size[0]) diff --git
> > a/board/freescale/ls2080ardb/ls2080ardb.c
> > b/board/freescale/ls2080ardb/ls2080ardb.c
> > index 282aaf47fb..45e645f8de 100644
> > --- a/board/freescale/ls2080ardb/ls2080ardb.c
> > +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> > @@ -4,6 +4,7 @@
> > * Copyright 2017 NXP
> > */
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -14,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -23,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #ifdef CONFIG_FSL_QIXIS
> > #include "../common/qixis.h"
> > @@ -30,6 +33,7 @@
> > #endif
> > #include "../common/vid.h"
> >
> > +#define GIC_LPI_SIZE 0x20
> > #define PIN_MUX_SEL_SDHC 0x00
> > #define PIN_MUX_SEL_DSPI 0x0a
> >
> > @@ -421,6 +425,8 @@ int ft_board_setup(void *blob, bd_t *bd)
> > u64 mc_memory_base = 0;
> > u64 mc_memory_size = 0;
> > u16 total_memory_banks;
> > + u64 gic_lpi_base;
> > + int ret;
> >
> > ft_cpu_setup(blob, bd);
> >
> > @@ -441,6 +447,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> > size[1] = gd->bd->bi_dram[1].size;
> >
> > #ifdef CONFIG_RESV_RAM
> > +#ifdef CONFIG_GIC_V3_ITS
> > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE,
> SZ_64K);
> > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
> GIC_LPI_SIZE);
> > + if (!ret) {
> > + if (gic_lpi_tables_init(gic_lpi_base, cpu_numcores()))
> > + debug("%s: failed to init gic-lpi-tables\n",
> __func__);
> > + }
>
> ditto
>
> > +#endif
> > /* reduce size if reserved memory is within this bank */
> > if (gd->arch.resv_ram >= base[0] &&
> > gd->arch.resv_ram < base[0] + size[0])
> > --
>
>
> Regards,
> Bin
Re: [PATCH v3 0/3] Add command to display or save Linux PStore dumps
Hello Wolfgang, Heinrich, Am 20.03.2020 um 09:08 schrieb Wolfgang Denk: Dear Heinrich, In message you wrote: To me this sounds very much like what you are adding here (plus a few features more). Does it make sense to unify such code? It seems you are relating to https://lore.kernel.org/lkml/844oyrqvvb@sauna.l.org/t/ No, I'm not. I was talking of my own code from many, many years ago. ramoops in Linux is exactly doing what was suggested in 2009. You can find the Documentation/admin-guide/ramoops.rst We had this in U-Boot long before that time. It was a key requirement when we added POST support in 2002. git grep -GHrn 'shared log' finds nothing in U-Boot. So if any part of the old implementation in U-Boot exists, could you, please, point us to the coding. The shared log buffer support was added by commit 56f94be3ef63: commit 56f94be3ef63732384063e110277ed89701b6471 (tag: LABEL_2002_11_05_1735) Author: Wolfgang Denk Date: Tue Nov 5 16:35:14 2002 + * Add support for log buffer which can be passed to Linux kernel's syslog mechanism; used especially for POST results. * Patch by Klaus Heydeck, 31 Oct 2002: Add initial support for kup4k board The code was mainly in common/cmd_log.c, but this got heahily rewritten and is now in cmd/log.c ; apparently this got lost (like the original copyright, sic!) when Simon modified / rewrote this driver. For history, try: git log --follow -- common/cmd_log.c If the original design never made it into Linux and there is an established Linux interface since 2011, I would plead to eliminate any remaining non-compliant coding from U-Boot should it exist. I understand what Linus has is one-way, only focussing on crash dump, i. e. it does not allow to pass information from U-Boot to Linux? Also, my understanding is that the changes needed in Linux are pretty small. Maybe Heiko can comment on that... Since 2002 the logbuffer support in linux changed, so the old patch does not work anymore. First there is now the struct "printk_log" [1] Unfortunately the size of it is dependend on linux configuration. Each log entry is prepended from such a struct, just missing the possibility to detect if entry is valid (as linux was the only user of it, this was not needed). There is already a possibilty to set a log buffer length through kernel commandline parameter "log_buf_len" [2]. If this is passed, kernel already uses a new area (currently memblock_alloced) for log buffer storage! So added now the following to linux logbuffer handling: Pass the persistent logbuffer address and length through a kernel commandline parameter and use it instead memblock_alloc() Add a magic field in [1] which I use to detect if there are valid entries and where is the end of logbuffer entries in the new logbuffer area (Not that easy as there was may a wrap around, but also this is detectable) -> start and end in the new log area is now known. Now copy the new logbuffer messages from __log_buf with the already existing functions in linux kernel to the end of the new logbuffer area ... and you have old linux bootlogs and the new ones after a reboot. aditionally changes in U-Boot: - enable PRAM to reserve RAM at the end of RAM for logbuffer so U-Boot does not use this memory space. Already in U-Boot. - add common/log_buffer.c log backend, which uses the functions from kernel for analysing/writing content of the logbuffer area. "log rec" U-Boot command appends now also U-Boot log messages to the logbuffer area. - add "log show" command, with which you can show current content of logbuffer area And now U-Boot log messages also shown in linux bootlog ... bye Heiko [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c#n368 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c#n1114 -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v3] lib: Improve _parse_integer_fixup_radix base 16 detection
Base autodetection is failing for this case:
if test 257 -gt 3ae; then echo first; else echo second; fi
It is because base for 3ae is recognized by _parse_integer_fixup_radix() as
10. The code detects the first char which is not between 'a'/'A' or 'f'/'F'
to change base from dec to hex.
Signed-off-by: Michal Simek
Signed-off-by: Shiril Tichkule
---
Changes in v3:
- Fix commit message to be accurate based on code.
- Use tolower instead of two ranges
- Use do while loop - all reported by Andy
- Remove Tom's reviewed-by tag because code has changed
Changes in v2:
- Fix end of string to be \0 instead of \n
- Detect hex by checking chars between a-f to avoid cases like number
follow by ;
lib/strto.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/lib/strto.c b/lib/strto.c
index 55ff9f7437d5..1ac2b09c725c 100644
--- a/lib/strto.c
+++ b/lib/strto.c
@@ -22,9 +22,22 @@ static const char *_parse_integer_fixup_radix(const char *s,
unsigned int *base)
*base = 16;
else
*base = 8;
- } else
+ } else {
+ int i = 0;
+ char var;
+
*base = 10;
+
+ do {
+ var = tolower(s[i++]);
+ if (var >= 'a' && var <= 'f') {
+ *base = 16;
+ break;
+ }
+ } while (var);
+ }
}
+
if (*base == 16 && s[0] == '0' && tolower(s[1]) == 'x')
s += 2;
return s;
--
2.25.1
[PATCH 2/2] arm64: zynqmp: Move timeout for clock propagation below psu_init
Delay required for clock propagation is tighly coupled with initialization
done in psu_init(). That's why call it also for u-boot proper with
CONFIG_ZYNQMP_PSU_INIT_ENABLED enabled.
Signed-off-by: Michal Simek
---
arch/arm/mach-zynqmp/spl.c | 3 ---
board/xilinx/zynqmp/zynqmp.c | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index c53945e57f39..68df0a79c4e5 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -19,9 +19,6 @@ void board_init_f(ulong dummy)
{
board_early_init_f();
board_early_init_r();
-
- /* Delay is required for clocks to be propagated */
- udelay(100);
}
static void ps_mode_reset(ulong mode)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 04fd3bd0a443..eb1bc0861e2f 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -326,6 +326,9 @@ int board_early_init_f(void)
ret = psu_init();
if (ret)
return ret;
+
+ /* Delay is required for clocks to be propagated */
+ udelay(100);
#endif
#ifdef CONFIG_DEBUG_UART
--
2.25.1
[PATCH 1/2] arm64: zynqmp: Add support for debug uart also for U-Boot proper
board_early_init_f() is the right location where debug uart can be
configurated (after MIO initialization).
The patch is taking this call from SPL to also make it available for U-Boot
proper.
Signed-off-by: Michal Simek
---
arch/arm/mach-zynqmp/spl.c | 6 --
board/xilinx/zynqmp/zynqmp.c | 15 ---
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index b3830182e250..c53945e57f39 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -6,7 +6,6 @@
*/
#include
-#include
#include
#include
@@ -21,11 +20,6 @@ void board_init_f(ulong dummy)
board_early_init_f();
board_early_init_r();
-#ifdef CONFIG_DEBUG_UART
- /* Uart debug for sure */
- debug_uart_init();
- puts("Debug uart enabled\n"); /* or printch() */
-#endif
/* Delay is required for clocks to be propagated */
udelay(100);
}
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index c6c55caa1ce0..04fd3bd0a443 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -319,13 +320,21 @@ static char *zynqmp_get_silicon_idcode_name(void)
int board_early_init_f(void)
{
- int ret = 0;
-
#if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED)
+ int ret;
+
ret = psu_init();
+ if (ret)
+ return ret;
#endif
- return ret;
+#ifdef CONFIG_DEBUG_UART
+ /* Uart debug for sure */
+ debug_uart_init();
+ puts("Debug uart enabled\n"); /* or printch() */
+#endif
+
+ return 0;
}
static int multi_boot(void)
--
2.25.1
Re: [*** MED SPAM ***]Re: [PATCH] cmd: ubi: add a command to rename volume
Hi Wolfgang, > Dear Philippe, > > In message <1584644739-10258-1-git-send-email-philippe.rey...@softathome.com> > you wrote: >> This commit add the command ubi rename to rename an ubi volume. >> The format of the command is: ubi rename . > > Can we plase make this optional / configurable? Yes, of course, I sent a v2 with an option CMD_UBI_RENAME. > Thanks! > > Wolfgang Denk Regards, Philippe
Re: [PATCH v2 3/8] i2c: i2c-cortina: added CAxxxx I2C support
Hello Alex,
Am 20.03.2020 um 01:57 schrieb Alex Nemirovsky:
From: Arthur Li
Add I2C controller support for Cortina Access CA SoCs
Signed-off-by: Arthur Li
Signed-off-by: Alex Nemirovsky
CC: Heiko Schocher
---
Changes in v3: None
Changes in v2: None
MAINTAINERS | 4 +
drivers/i2c/Kconfig | 7 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-cortina.c | 346 ++
drivers/i2c/i2c-cortina.h | 92
5 files changed, 450 insertions(+)
create mode 100644 drivers/i2c/i2c-cortina.c
create mode 100644 drivers/i2c/i2c-cortina.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bb45d3c..b147faa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -181,6 +181,8 @@ F: drivers/gpio/cortina_gpio.c
F:drivers/watchdog/cortina_wdt.c
F:drivers/serial/serial_cortina.c
F:drivers/mmc/ca_dw_mmc.c
+F: drivers/i2c/i2c-cortina.c
+F: drivers/i2c/i2c-cortina.h
ARM/CZ.NIC TURRIS MOX SUPPORT
M:Marek Behun
@@ -672,6 +674,8 @@ F: drivers/gpio/cortina_gpio.c
F:drivers/watchdog/cortina_wdt.c
F:drivers/serial/serial_cortina.c
F:drivers/mmc/ca_dw_mmc.c
+F: drivers/i2c/i2c-cortina.c
+F: drivers/i2c/i2c-cortina.h
MIPS MSCC
M:Gregory CLEMENT
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 03d2fed..b98a4aa 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -85,6 +85,13 @@ config SYS_I2C_CADENCE
Say yes here to select Cadence I2C Host Controller. This controller is
e.g. used by Xilinx Zynq.
+config SYS_I2C_CA
+ tristate "Cortina-Access I2C Controller"
+ depends on DM_I2C && CORTINA_PLATFORM
+ default n
+ help
+ Say yes here to select Cortina-Access I2C Host Controller.
+
config SYS_I2C_DAVINCI
bool "Davinci I2C Controller"
depends on (ARCH_KEYSTONE || ARCH_DAVINCI)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index f5a471f..5d18cf7 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
+obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
ifdef CONFIG_DM_PCI
diff --git a/drivers/i2c/i2c-cortina.c b/drivers/i2c/i2c-cortina.c
new file mode 100644
index 000..99c63f3
--- /dev/null
+++ b/drivers/i2c/i2c-cortina.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020
+ * Arthur Li, Cortina Access, arthur...@cortina-access.com.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "i2c-cortina.h"
+
+static void set_speed(struct i2c_regs *regs, int i2c_spd)
+{
+ union ca_biw_cfg i2c_cfg;
+
+ i2c_cfg.wrd = readl(>i2c_cfg);
+ i2c_cfg.bf.core_en = 0;
+ writel(i2c_cfg.wrd, >i2c_cfg);
+
+ switch (i2c_spd) {
+ case IC_SPEED_MODE_MAX:
+ i2c_cfg.bf.prer =
+ CORTINA_PER_IO_FREQ / (5 * I2C_MAX_SPEED) - 1;
+ break;
+
+ case IC_SPEED_MODE_STANDARD:
+ i2c_cfg.bf.prer =
+ CORTINA_PER_IO_FREQ / (5 * I2C_STANDARD_SPEED) - 1;
+ break;
+
+ case IC_SPEED_MODE_FAST:
+ default:
+ i2c_cfg.bf.prer =
+ CORTINA_PER_IO_FREQ / (5 * I2C_FAST_SPEED) - 1;
+ break;
+ }
+
+ i2c_cfg.bf.core_en = 1;
+ writel(i2c_cfg.wrd, >i2c_cfg);
+}
+
+static int ca_i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
+{
+ struct ca_i2c *priv = dev_get_priv(bus);
+ int i2c_spd;
+
+ if (speed >= I2C_MAX_SPEED) {
+ i2c_spd = IC_SPEED_MODE_MAX;
+ priv->speed = I2C_MAX_SPEED;
+ } else if (speed >= I2C_FAST_SPEED) {
+ i2c_spd = IC_SPEED_MODE_FAST;
+ priv->speed = I2C_FAST_SPEED;
+ } else {
+ i2c_spd = IC_SPEED_MODE_STANDARD;
+ priv->speed = I2C_STANDARD_SPEED;
+ }
+
+ set_speed(priv->regs, i2c_spd);
+
+ return 0;
+}
+
+static int ca_i2c_get_bus_speed(struct udevice *bus)
+{
+ struct ca_i2c *priv = dev_get_priv(bus);
+
+ return priv->speed;
+}
+
+static void ca_i2c_init(struct i2c_regs *regs)
+{
+ union ca_biw_cfg i2c_cfg;
+
+ i2c_cfg.wrd = readl(>i2c_cfg);
+ i2c_cfg.bf.core_en = 0;
+ i2c_cfg.bf.biw_soft_reset = 1;
+ writel(i2c_cfg.wrd, >i2c_cfg);
+ mdelay(10);
+ i2c_cfg.bf.biw_soft_reset = 0;
+ writel(i2c_cfg.wrd, >i2c_cfg);
+
+ set_speed(regs, IC_SPEED_MODE_STANDARD);
+
+ i2c_cfg.wrd = readl(>i2c_cfg);
+ i2c_cfg.bf.core_en = 1;
+ writel(i2c_cfg.wrd, >i2c_cfg);
+}
+
+static int i2c_wait_complete(struct i2c_regs *regs)
+{
+ union ca_biw_ctrl i2c_ctrl;
+
[PATCH 1/2 v2] armv8: ls1028aqds: add some environments
From: Yuantian Tang
Add sd and emmc bootcmd environments to facilitate
the boot process.
Signed-off-by: Yuantian Tang
---
v2:
- updated some variable slightly.
include/configs/ls1028aqds.h | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/include/configs/ls1028aqds.h b/include/configs/ls1028aqds.h
index b3c1242..5843274 100644
--- a/include/configs/ls1028aqds.h
+++ b/include/configs/ls1028aqds.h
@@ -108,6 +108,7 @@
"load_addr=0xa000\0" \
"kernel_addr_r=0x8100\0" \
"fdt_addr_r=0x9000\0" \
+ "fdt2_addr_r=0x9001\0" \
"ramdisk_addr_r=0xa000\0" \
"kernel_start=0x100\0" \
"kernelheader_start=0x80\0" \
@@ -148,19 +149,35 @@
"${scripthdraddr} ${prefix}${boot_script_hdr} " \
"&& esbc_validate ${scripthdraddr};" \
"source ${scriptaddr}\0" \
- "sd_bootcmd=echo Trying load from SD ..;" \
- "mmcinfo; mmc read $load_addr " \
- "$kernel_addr_sd $kernel_size_sd && " \
+ "xspi_bootcmd=echo Trying load from FlexSPI flash ...;" \
+ "sf probe 0:0 && sf read $load_addr " \
+ "$kernel_start $kernel_size ; env exists secureboot &&" \
+ "sf read $kernelheader_addr_r $kernelheader_start " \
+ "$kernelheader_size && esbc_validate ${kernelheader_addr_r}; "\
+ " bootm $load_addr#$board\0" \
+ "xspi_hdploadcmd=echo Trying load HDP firmware from FlexSPI...;" \
+ "sf probe 0:0 && sf read $load_addr 0x94 0x3 " \
+ "&& hdp load $load_addr 0x2000\0" \
+ "sd_bootcmd=echo Trying load from SD ...;" \
+ "mmc dev 0; mmcinfo; mmc read $load_addr " \
+ "$kernel_addr_sd $kernel_size_sd && " \
"env exists secureboot && mmc read $kernelheader_addr_r " \
- "$kernelhdr_addr_sd $kernelhdr_size_sd " \
- " && esbc_validate ${kernelheader_addr_r};" \
- "bootm $load_addr#$board\0" \
- "emmc_bootcmd=echo Trying load from EMMC ..;" \
- "mmcinfo; mmc dev 1; mmc read $load_addr " \
- "$kernel_addr_sd $kernel_size_sd && " \
+ "$kernelhdr_addr_sd $kernelhdr_size_sd "\
+ " && esbc_validate ${kernelheader_addr_r};" \
+ "bootm $load_addr#$board\0" \
+ "sd_hdploadcmd=echo Trying load HDP firmware from SD..;"\
+ "mmc dev 0;mmcinfo; mmc read $load_addr 0x4a00 0x200 " \
+ "&& hdp load $load_addr 0x2000\0" \
+ "emmc_bootcmd=echo Trying load from EMMC ..;" \
+ "mmc dev 1; mmcinfo; mmc read $load_addr " \
+ "$kernel_addr_sd $kernel_size_sd && " \
"env exists secureboot && mmc read $kernelheader_addr_r " \
- "$kernelhdr_addr_sd $kernelhdr_size_sd " \
+ "$kernelhdr_addr_sd $kernelhdr_size_sd "\
" && esbc_validate ${kernelheader_addr_r};" \
- "bootm $load_addr#$board\0"
+ "bootm $load_addr#$board\0" \
+ "emmc_hdploadcmd=echo Trying load HDP firmware from EMMC..;" \
+ "mmc dev 1;mmcinfo;mmc read $load_addr 0x4a00 0x200 " \
+ "&& hdp load $load_addr 0x2000\0"
+
#endif
#endif /* __LS1028A_QDS_H */
--
2.9.5
[PATCH 2/2] armv8: ls1028a: clean up the environment variables
From: Yuantian Tang
Move the environment variables from command head file to
ls1028ardb specific head file so that they will mess up
with ls1028aqds board.
Also updated some variable slightly.
There is no function change by this patch.
Signed-off-by: Yuantian Tang
---
include/configs/ls1028a_common.h | 87 ---
include/configs/ls1028ardb.h | 89
2 files changed, 89 insertions(+), 87 deletions(-)
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index 05b8cf0..fda98e6 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -73,93 +73,6 @@
func(USB, usb, 0)
#include
-/* Initial environment variables */
-#define CONFIG_EXTRA_ENV_SETTINGS \
- "board=ls1028ardb\0"\
- "hwconfig=fsl_ddr:bank_intlv=auto\0"\
- "ramdisk_addr=0x80\0" \
- "ramdisk_size=0x200\0" \
- "fdt_high=0x\0" \
- "initrd_high=0x\0" \
- "fdt_addr=0x00f0\0" \
- "kernel_addr=0x0100\0" \
- "scriptaddr=0x8000\0" \
- "scripthdraddr=0x8008\0"\
- "fdtheader_addr_r=0x8010\0" \
- "kernelheader_addr_r=0x8020\0" \
- "load_addr=0xa000\0"\
- "kernel_addr_r=0x8100\0"\
- "fdt_addr_r=0x9000\0" \
- "ramdisk_addr_r=0xa000\0" \
- "kernel_start=0x100\0" \
- "kernelheader_start=0x80\0" \
- "kernel_load=0xa000\0" \
- "kernel_size=0x280\0" \
- "kernelheader_size=0x4\0" \
- "kernel_addr_sd=0x8000\0" \
- "kernel_size_sd=0x14000\0" \
- "kernelhdr_addr_sd=0x4000\0"\
- "kernelhdr_size_sd=0x10\0" \
- "console=ttyS0,115200\0"\
- "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"\
- BOOTENV \
- "boot_scripts=ls1028ardb_boot.scr\0"\
- "boot_script_hdr=hdr_ls1028ardb_bs.out\0" \
- "scan_dev_for_boot_part=" \
- "part list ${devtype} ${devnum} devplist; " \
- "env exists devplist || setenv devplist 1; " \
- "for distro_bootpart in ${devplist}; do " \
- "if fstype ${devtype} " \
- "${devnum}:${distro_bootpart} " \
- "bootfstype; then " \
- "run scan_dev_for_boot; "\
- "fi; " \
- "done\0" \
- "scan_dev_for_boot=" \
- "echo Scanning ${devtype} " \
- "${devnum}:${distro_bootpart}...; " \
- "for prefix in ${boot_prefixes}; do " \
- "run scan_dev_for_scripts; " \
- "done;" \
- "\0" \
- "boot_a_script=" \
- "load ${devtype} ${devnum}:${distro_bootpart} " \
- "${scriptaddr} ${prefix}${script}; "\
- "env exists secureboot && load ${devtype} " \
- "${devnum}:${distro_bootpart} " \
- "${scripthdraddr} ${prefix}${boot_script_hdr} " \
- "&& esbc_validate ${scripthdraddr};"\
- "source ${scriptaddr}\0" \
- "xspi_bootcmd=echo Trying load from FlexSPI flash ...;" \
- "sf probe 0:0 && sf read $load_addr " \
- "$kernel_start $kernel_size ; env exists secureboot &&" \
- "sf read $kernelheader_addr_r $kernelheader_start " \
- "$kernelheader_size && esbc_validate ${kernelheader_addr_r}; "\
- " bootm $load_addr#$board\0" \
- "xspi_hdploadcmd=echo Trying load HDP firmware from FlexSPI...;" \
- "sf probe 0:0 && sf read $load_addr 0x94 0x3 " \
- "&& hdp load $load_addr 0x2000\0" \
- "sd_bootcmd=echo Trying load from SD ...;" \
- "mmcinfo; mmc read $load_addr " \
- "$kernel_addr_sd $kernel_size_sd && " \
- "env exists secureboot && mmc read $kernelheader_addr_r " \
- "$kernelhdr_addr_sd $kernelhdr_size_sd "\
- " && esbc_validate ${kernelheader_addr_r};" \
- "bootm $load_addr#$board\0" \
- "sd_hdploadcmd=echo Trying load HDP
[PATCH v3 2/2] allow opting out of WATCHDOG_RESET() from timer interrupt
When using CONFIG_(SPL_)WDT, the watchdog_reset function is a lot more
complicated than just poking a few SOC-specific registers - it
involves accessing all kinds of global data, and if the interrupt
happens at the wrong time (say, in the middle of an WATCHDOG_RESET()
call from ordinary code), that can end up corrupting said global data.
Also, having WATCHDOG_RESET() called automatically from the timer
interrupt runs counter to the idea of a watchdog device - if the board
runs into an infinite loops with interrupts still enabled, the
watchdog will never fire.
Allow the board to opt out of this behaviour by setting
CONFIG_SYS_WATCHDOG_FREQ to 0 - as that setting is currently
nonsensical, it cannot affect any existing boards.
Add documentation for both the existing and extended meaning of
CONFIG_SYS_WATCHDOG_FREQ.
Signed-off-by: Rasmus Villemoes
---
README| 9 +
arch/m68k/lib/time.c | 2 +-
arch/powerpc/lib/interrupts.c | 2 +-
drivers/timer/mpc83xx_timer.c | 2 +-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 8cfa92fac9..79e8da4adc 100644
--- a/README
+++ b/README
@@ -768,6 +768,15 @@ The following options need to be configured:
SoC, then define this variable and provide board
specific code for the "hw_watchdog_reset" function.
+ CONFIG_SYS_WATCHDOG_FREQ
+ Some platforms automatically call WATCHDOG_RESET()
+ from the timer interrupt handler every
+ CONFIG_SYS_WATCHDOG_FREQ interrupts. If not set by the
+ board configuration file, a default of CONFIG_SYS_HZ/2
+ (i.e. 500) is used. Setting CONFIG_SYS_WATCHDOG_FREQ
+ to 0 disables calling WATCHDOG_RESET() from the timer
+ interrupt.
+
- Real-Time Clock:
When CONFIG_CMD_DATE is selected, the type of the RTC
diff --git a/arch/m68k/lib/time.c b/arch/m68k/lib/time.c
index bde1f4c228..038019ff36 100644
--- a/arch/m68k/lib/time.c
+++ b/arch/m68k/lib/time.c
@@ -68,7 +68,7 @@ void dtimer_interrupt(void *not_used)
timestamp++;
#if defined(CONFIG_WATCHDOG) || defined (CONFIG_HW_WATCHDOG)
- if ((timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0) {
+ if (CONFIG_SYS_WATCHDOG_FREQ && (timestamp %
(CONFIG_SYS_WATCHDOG_FREQ)) == 0) {
WATCHDOG_RESET ();
}
#endif/* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
diff --git a/arch/powerpc/lib/interrupts.c b/arch/powerpc/lib/interrupts.c
index 64ee0cc210..23ac5bca1e 100644
--- a/arch/powerpc/lib/interrupts.c
+++ b/arch/powerpc/lib/interrupts.c
@@ -79,7 +79,7 @@ void timer_interrupt(struct pt_regs *regs)
timestamp++;
#if defined(CONFIG_WATCHDOG) || defined (CONFIG_HW_WATCHDOG)
- if ((timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0)
+ if (CONFIG_SYS_WATCHDOG_FREQ && (timestamp %
(CONFIG_SYS_WATCHDOG_FREQ)) == 0)
WATCHDOG_RESET ();
#endif/* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
diff --git a/drivers/timer/mpc83xx_timer.c b/drivers/timer/mpc83xx_timer.c
index da516c9d74..b85f10ad99 100644
--- a/drivers/timer/mpc83xx_timer.c
+++ b/drivers/timer/mpc83xx_timer.c
@@ -171,7 +171,7 @@ void timer_interrupt(struct pt_regs *regs)
priv->timestamp++;
#if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG)
- if ((priv->timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0)
+ if (CONFIG_SYS_WATCHDOG_FREQ && (priv->timestamp %
(CONFIG_SYS_WATCHDOG_FREQ)) == 0)
WATCHDOG_RESET();
#endif/* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
--
2.23.0
[PATCH v3 1/2] timer: mpc83xx_timer: fix build with CONFIG_{HW_, }WATCHDOG
The code, which is likely copied from arch/powerpc/lib/interrupts.c, lacks a fallback definition of CONFIG_SYS_WATCHDOG_FREQ and refers to a non-existing timestamp variable - obviously priv->timestamp is meant. Signed-off-by: Rasmus Villemoes --- drivers/timer/mpc83xx_timer.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/timer/mpc83xx_timer.c b/drivers/timer/mpc83xx_timer.c index 72cb58b693..da516c9d74 100644 --- a/drivers/timer/mpc83xx_timer.c +++ b/drivers/timer/mpc83xx_timer.c @@ -16,6 +16,10 @@ DECLARE_GLOBAL_DATA_PTR; +#ifndef CONFIG_SYS_WATCHDOG_FREQ +#define CONFIG_SYS_WATCHDOG_FREQ (CONFIG_SYS_HZ / 2) +#endif + /** * struct mpc83xx_timer_priv - Private data structure for MPC83xx timer driver * @decrementer_count: Value to which the decrementer register should be re-set @@ -167,7 +171,7 @@ void timer_interrupt(struct pt_regs *regs) priv->timestamp++; #if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG) - if ((timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0) + if ((priv->timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0) WATCHDOG_RESET(); #endif/* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */ -- 2.23.0
[u-boot][PATCH 2/2] spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses
From: Tudor Ambarus
This feature should not be enabled in release but can be useful for
developers who need to monitor register accesses at some specific places.
Helped me identify a bug in u-boot, by comparing the register accesses
from the u-boot driver with the ones from its linux variant.
Signed-off-by: Tudor Ambarus
---
drivers/spi/atmel-quadspi.c | 114 ++--
1 file changed, 96 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index 4099ee87993d..3de367e6a0c8 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -148,6 +148,7 @@ struct atmel_qspi {
void __iomem *mem;
resource_size_t mmap_size;
const struct atmel_qspi_caps *caps;
+ struct udevice *dev;
ulong bus_clk_rate;
u32 mr;
};
@@ -169,6 +170,81 @@ static const struct atmel_qspi_mode atmel_qspi_modes[] = {
{ 4, 4, 4, QSPI_IFR_WIDTH_QUAD_CMD },
};
+#ifdef VERBOSE_DEBUG
+static const char *atmel_qspi_reg_name(u32 offset, char *tmp, size_t sz)
+{
+ switch (offset) {
+ case QSPI_CR:
+ return "CR";
+ case QSPI_MR:
+ return "MR";
+ case QSPI_RD:
+ return "MR";
+ case QSPI_TD:
+ return "TD";
+ case QSPI_SR:
+ return "SR";
+ case QSPI_IER:
+ return "IER";
+ case QSPI_IDR:
+ return "IDR";
+ case QSPI_IMR:
+ return "IMR";
+ case QSPI_SCR:
+ return "SCR";
+ case QSPI_IAR:
+ return "IAR";
+ case QSPI_ICR:
+ return "ICR/WICR";
+ case QSPI_IFR:
+ return "IFR";
+ case QSPI_RICR:
+ return "RICR";
+ case QSPI_SMR:
+ return "SMR";
+ case QSPI_SKR:
+ return "SKR";
+ case QSPI_WPMR:
+ return "WPMR";
+ case QSPI_WPSR:
+ return "WPSR";
+ case QSPI_VERSION:
+ return "VERSION";
+ default:
+ snprintf(tmp, sz, "0x%02x", offset);
+ break;
+ }
+
+ return tmp;
+}
+#endif /* VERBOSE_DEBUG */
+
+static u32 atmel_qspi_read(struct atmel_qspi *aq, u32 offset)
+{
+ u32 value = readl(aq->regs + offset);
+
+#ifdef VERBOSE_DEBUG
+ char tmp[8];
+
+ dev_vdbg(aq->dev, "read 0x%08x from %s\n", value,
+atmel_qspi_reg_name(offset, tmp, sizeof(tmp)));
+#endif /* VERBOSE_DEBUG */
+
+ return value;
+}
+
+static void atmel_qspi_write(u32 value, struct atmel_qspi *aq, u32 offset)
+{
+#ifdef VERBOSE_DEBUG
+ char tmp[8];
+
+ dev_vdbg(aq->dev, "write 0x%08x into %s\n", value,
+atmel_qspi_reg_name(offset, tmp, sizeof(tmp)));
+#endif /* VERBOSE_DEBUG */
+
+ writel(value, aq->regs + offset);
+}
+
static inline bool atmel_qspi_is_compatible(const struct spi_mem_op *op,
const struct atmel_qspi_mode *mode)
{
@@ -289,32 +365,32 @@ static int atmel_qspi_set_cfg(struct atmel_qspi *aq,
* Serial Memory Mode (SMM).
*/
if (aq->mr != QSPI_MR_SMM) {
- writel(QSPI_MR_SMM, aq->regs + QSPI_MR);
+ atmel_qspi_write(QSPI_MR_SMM, aq, QSPI_MR);
aq->mr = QSPI_MR_SMM;
}
/* Clear pending interrupts */
- (void)readl(aq->regs + QSPI_SR);
+ (void)atmel_qspi_read(aq, QSPI_SR);
if (aq->caps->has_ricr) {
if (!op->addr.nbytes && op->data.dir == SPI_MEM_DATA_IN)
ifr |= QSPI_IFR_APBTFRTYP_READ;
/* Set QSPI Instruction Frame registers */
- writel(iar, aq->regs + QSPI_IAR);
+ atmel_qspi_write(iar, aq, QSPI_IAR);
if (op->data.dir == SPI_MEM_DATA_IN)
- writel(icr, aq->regs + QSPI_RICR);
+ atmel_qspi_write(icr, aq, QSPI_RICR);
else
- writel(icr, aq->regs + QSPI_WICR);
- writel(ifr, aq->regs + QSPI_IFR);
+ atmel_qspi_write(icr, aq, QSPI_WICR);
+ atmel_qspi_write(ifr, aq, QSPI_IFR);
} else {
if (op->data.dir == SPI_MEM_DATA_OUT)
ifr |= QSPI_IFR_SAMA5D2_WRITE_TRSFR;
/* Set QSPI Instruction Frame registers */
- writel(iar, aq->regs + QSPI_IAR);
- writel(icr, aq->regs + QSPI_ICR);
- writel(ifr, aq->regs + QSPI_IFR);
+ atmel_qspi_write(iar, aq, QSPI_IAR);
+ atmel_qspi_write(icr, aq, QSPI_ICR);
+ atmel_qspi_write(ifr, aq, QSPI_IFR);
}
return 0;
@@ -342,7 +418,7 @@ static int atmel_qspi_exec_op(struct spi_slave *slave,
/* Skip to the final steps if there is no data */
if (op->data.nbytes) {
/* Dummy read of QSPI_IFR to
[u-boot][PATCH 1/2] spi: atmel-quadspi: fix possible MMIO window size overrun
From: Tudor Ambarus
The sama5d2 QSPI controller memory space is limited to 128MB:
0x9000_0-0x9800_0/0XD000_--0XD800_.
There are nor flashes that are bigger in size than the memory size
supported by the controller: Micron MT25QL02G (256 MB).
Check if the address exceeds the MMIO window size. An improvement
would be to add support for regular SPI mode and fall back to it
when the flash memories overrun the controller's memory space.
Fixes: 24c8ff4684c5 ("spi: Add Atmel QuadSPI driver")
Signed-off-by: Tudor Ambarus
---
drivers/spi/atmel-quadspi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index a09bf884e837..4099ee87993d 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -146,6 +146,7 @@ struct atmel_qspi_caps {
struct atmel_qspi {
void __iomem *regs;
void __iomem *mem;
+ resource_size_t mmap_size;
const struct atmel_qspi_caps *caps;
ulong bus_clk_rate;
u32 mr;
@@ -326,6 +327,14 @@ static int atmel_qspi_exec_op(struct spi_slave *slave,
u32 sr, imr, offset;
int err;
+ /*
+* Check if the address exceeds the MMIO window size. An improvement
+* would be to add support for regular SPI mode and fall back to it
+* when the flash memories overrun the controller's memory space.
+*/
+ if (op->addr.val + op->data.nbytes > aq->mmap_size)
+ return -ENOTSUPP;
+
err = atmel_qspi_set_cfg(aq, op, );
if (err)
return err;
@@ -490,6 +499,8 @@ static int atmel_qspi_probe(struct udevice *dev)
if (IS_ERR(aq->mem))
return PTR_ERR(aq->mem);
+ aq->mmap_size = resource_size();
+
ret = atmel_qspi_enable_clk(dev);
if (ret)
return ret;
--
2.23.0
[u-boot][PATCH] spi: spi-mem: Add SPI_MEM_NO_DATA to the spi_mem_data_dir enum
From: Tudor Ambarus
Commit: 0ebb261a0b2d ("spi: spi-mem: Add SPI_MEM_NO_DATA to the
spi_mem_data_dir enum")
in linux.
When defining spi_mem_op templates we don't necessarily know the size
that will be passed when the template is actually used, and basing the
supports_op() check on op->data.nbytes to know whether there will be
data transferred for a specific operation is not possible.
Add SPI_MEM_NO_DATA to the spi_mem_data_dir enum so that we can base
our checks on op->data.dir instead of op->data.nbytes.
This also fixes a bug identified with the atmel-quaspi driver.
The spi-nor core, when erasing sectors, fills the spi_mem_op template
using SPI_MEM_OP_NO_DATA, which initializes all the data members with
value zero. This is wrong because data.dir is treated as SPI_MEM_DATA_IN,
which translates in our driver to read accesses for erases (RICR), while
the controller expects write accesses (WICR).
Signed-off-by: Tudor Ambarus
---
drivers/spi/spi-mem.c | 2 +-
include/spi-mem.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index e900c997bd7f..ffbe20c5b1e6 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -153,7 +153,7 @@ bool spi_mem_default_supports_op(struct spi_slave *slave,
spi_check_buswidth_req(slave, op->dummy.buswidth, true))
return false;
- if (op->data.nbytes &&
+ if (op->data.dir != SPI_MEM_NO_DATA &&
spi_check_buswidth_req(slave, op->data.buswidth,
op->data.dir == SPI_MEM_DATA_OUT))
return false;
diff --git a/include/spi-mem.h b/include/spi-mem.h
index 36814efa8613..893f7bd73370 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -60,10 +60,12 @@
/**
* enum spi_mem_data_dir - describes the direction of a SPI memory data
*transfer from the controller perspective
+ * @SPI_MEM_NO_DATA: no data transferred
* @SPI_MEM_DATA_IN: data coming from the SPI memory
* @SPI_MEM_DATA_OUT: data sent the SPI memory
*/
enum spi_mem_data_dir {
+ SPI_MEM_NO_DATA,
SPI_MEM_DATA_IN,
SPI_MEM_DATA_OUT,
};
--
2.23.0
Re: [PATCH v2 1/2] spi: call WATCHDOG_RESET() in spi_nor_wait_till_ready_with_timeout()
Dear Vignesh,
In message <20200320101448.10714-1-rasmus.villem...@prevas.dk> Rasmus Villemoes
wrote:
> I have a board for which doing "sf erase 0x10 0x8"
> consistently causes the external watchdog circuit to reset the
> board. Make sure to pet the watchdog during slow operations such as
> erasing or writing large areas of a spi nor flash.
...
> drivers/mtd/spi/spi-nor-core.c | 2 ++
> drivers/mtd/spi/spi-nor-tiny.c | 2 ++
Rasmus' patch triggers a few interesting questions about the SPI NOR
code:
Is there any specific reason why spi-nor-core.c and spi-nor-tiny.c
contain large parts of absolutely identical code?
All the functions
spi_nor_read_write_reg()
spi_nor_read_reg()
spi_nor_write_reg()
spi_nor_read_data()
mtd_to_spi_nor()
spi_nor_convert_opcode()
spi_nor_ready()
spi_nor_wait_till_ready_with_timeout()
spi_nor_wait_till_ready()
macronix_quad_enable()
spansion_read_cr_quad_enable()
spi_nor_set_read_settings()
are absolutely identical;
functions
read_cr()
write_sr()
write_disable()
set_4byte()
spi_nor_read()
write_sr_cr()
are mostly identical, but I wonder if the differences (like
nor->write_reg() versus spi_nor_write_reg()) is indeed intended to
save memory footprint or lack an update to later code?
Function
spi_nor_convert_3to4_read()
spi_nor_set_4byte_opcodes()
looks like it has not been updated/synced for some time.
Function
spi_nor_sr_ready()
spi_nor_fsr_ready()
is lacking error handling in spi-nor-tiny.c; and the rror handling
code in spi-nor-core.c is also mostly duplicated a couple or times.
Function
spi_nor_read_id()
differs in "interesting" ways, i. e. we have
370 info = spi_nor_ids;
371 for (; info->sector_size != 0; info++) {
372 if (info->id_len) {
here, and
894 info = spi_nor_ids;
895 for (; info->name; info++) {
896 if (info->id_len) {
there, while all the rest is idential. Lack of synchronization?
Also the differences in
spi_nor_select_read()
make we wonder...
This extensive code duplication looks really painful and error prone
to me.
Do you have any intentions to clean this up any time soon?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Common sense and a sense of humor are the same thing, moving at
different speeds. A sense of humor is just common sense, dancing.
- Clive James
Re: [PATCH v3 0/3] Add command to display or save Linux PStore dumps
Hi Wolfgang, Heinrich, Heiko, On 20/03/2020 09:08, Wolfgang Denk wrote: Dear Heinrich, In message you wrote: To me this sounds very much like what you are adding here (plus a few features more). Does it make sense to unify such code? It seems you are relating to https://lore.kernel.org/lkml/844oyrqvvb@sauna.l.org/t/ No, I'm not. I was talking of my own code from many, many years ago. ramoops in Linux is exactly doing what was suggested in 2009. You can find the Documentation/admin-guide/ramoops.rst We had this in U-Boot long before that time. It was a key requirement when we added POST support in 2002. git grep -GHrn 'shared log' finds nothing in U-Boot. So if any part of the old implementation in U-Boot exists, could you, please, point us to the coding. The shared log buffer support was added by commit 56f94be3ef63: commit 56f94be3ef63732384063e110277ed89701b6471 (tag: LABEL_2002_11_05_1735) Author: Wolfgang Denk Date: Tue Nov 5 16:35:14 2002 + * Add support for log buffer which can be passed to Linux kernel's syslog mechanism; used especially for POST results. * Patch by Klaus Heydeck, 31 Oct 2002: Add initial support for kup4k board The code was mainly in common/cmd_log.c, but this got heahily rewritten and is now in cmd/log.c ; apparently this got lost (like the original copyright, sic!) when Simon modified / rewrote this driver. For history, try: git log --follow -- common/cmd_log.c If the original design never made it into Linux and there is an established Linux interface since 2011, I would plead to eliminate any remaining non-compliant coding from U-Boot should it exist. I understand what Linus has is one-way, only focussing on crash dump, i. e. it does not allow to pass information from U-Boot to Linux? Yes, currently it is not possible to pass information from U-Boot to Linux. But, PStore does not only store crash dump, but also console, ftrace and user space logs. It may be possible to add a "bootloader" storage space to PStore. Best regards, Frédéric Danis
[PATCH] configs: ls1012afrwy: adjust env kernel_addr_r
Adjust environment kernel_addr_r from 0x9600 to 0x9200 to fix a bug that failed to boot kernel for ls1012afrwy with 512MiB RAM, => tftpboot $kernel_addr_r Image (Image size is 36 MiB) TFTP error: trying to overwrite reserved memory... Signed-off-by: Biwen Li --- include/configs/ls1012afrwy.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h index dde4369c97..2fa76f9748 100644 --- a/include/configs/ls1012afrwy.h +++ b/include/configs/ls1012afrwy.h @@ -63,7 +63,7 @@ "fdtheader_addr_r=0x8010\0" \ "kernelheader_addr_r=0x8020\0" \ "kernelheader_size=0x4\0" \ - "kernel_addr_r=0x9600\0"\ + "kernel_addr_r=0x9200\0"\ "fdt_addr_r=0x9000\0" \ "load_addr=0x9600\0"\ "kernel_size=0x280\0" \ -- 2.17.1
Re: [PATCH v3 0/3] Add command to display or save Linux PStore dumps
Dear Frédéric, In message <03674974-2a2c-3804-ce02-4f3d38ff0...@collabora.com> you wrote: > > > I understand what Linus has is one-way, only focussing on crash > > dump, i. e. it does not allow to pass information from U-Boot to Linux? > > Yes, currently it is not possible to pass information from U-Boot to Linux. > But, PStore does not only store crash dump, but also console, ftrace and > user space logs. > > It may be possible to add a "bootloader" storage space to PStore. This does not make much sense to me. We should not try to push any possible functionality into U-Boot just because we can. U-Boot is a boot loader, and should only contain necessary functionality and things, that are impossible or difficult to solve in other ways. I would much rather see the opposite direction working (again): being able to pass information from U-Boot to Linux kernel and further into Linux user land in a standard way. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Panic, n.: The second time you can't do it the first time.
Re: [PATCH v3 0/3] Add command to display or save Linux PStore dumps
Dear Wolfgang, On 20/03/2020 11:35, Wolfgang Denk wrote: Dear Frédéric, In message <03674974-2a2c-3804-ce02-4f3d38ff0...@collabora.com> you wrote: I understand what Linus has is one-way, only focussing on crash dump, i. e. it does not allow to pass information from U-Boot to Linux? Yes, currently it is not possible to pass information from U-Boot to Linux. But, PStore does not only store crash dump, but also console, ftrace and user space logs. It may be possible to add a "bootloader" storage space to PStore. This does not make much sense to me. We should not try to push any possible functionality into U-Boot just because we can. Yes, I understand it. But, when debugging kernel crashes occurring either early in boot or hard crashes later, it can be helpful to be able to retrieve logs using the U-Boot session. U-Boot is a boot loader, and should only contain necessary functionality and things, that are impossible or difficult to solve in other ways. I would much rather see the opposite direction working (again): being able to pass information from U-Boot to Linux kernel and further into Linux user land in a standard way. Best regards, Wolfgang Denk Best regards, Frédéric Danis
[PATCH v5 1/3] cmd: Add command to display or save Linux PStore dumps
This patch adds a new pstore command allowing to display or save ramoops
logs (oops, panic, console, ftrace and user) generated by a previous
kernel crash.
PStore parameters can be set in U-Boot configuration file, or at run-time
using "pstore set" command. Records size should be the same as the ones
used by kernel, and should be a power of 2.
This command allows:
- to display uncompressed logs
- to save compressed or uncompressed logs, compressed logs are saved as a
compressed stream, it may need some work to be able to decompress it,
e.g. adding a fake header:
"printf "\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x00" |
cat - dmesg-ramoops-0.enc.z | gzip -dc"
- ECC part is not used to check memory corruption
- only 1st FTrace log is displayed or saved
Signed-off-by: Frédéric Danis
Cc: Tom Rini
Cc: Heinrich Schuchardt
Cc: Wolfgang Denk
Cc: Heiko Schocher
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add default value for PStore memory size
- Remove default value of PStore memory address
- Update config entry helps
- Replace calls to debug() by log_debug()
- Update documentation
Changes in v2:
- Fix 64bit mode build warnings
- Add documentation
- Add function description comments
- Replace calls to pr_debug() by debug()
cmd/Kconfig| 71 +++
cmd/Makefile | 1 +
cmd/pstore.c | 505 +
doc/index.rst | 7 +
doc/pstore.rst | 74
5 files changed, 658 insertions(+)
create mode 100644 cmd/pstore.c
create mode 100644 doc/pstore.rst
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6403bc45a5..cd202bf7fb 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1736,6 +1736,77 @@ config CMD_QFW
feature is to allow easy loading of files passed to qemu-system
via -kernel / -initrd
+config CMD_PSTORE
+ bool "pstore"
+ help
+ This provides access to Linux PStore with Rammoops backend. The main
+ feature is to allow to display or save PStore records.
+
+ See doc/pstore.rst for more information.
+
+if CMD_PSTORE
+
+config CMD_PSTORE_MEM_ADDR
+ hex "Memory Address"
+ depends on CMD_PSTORE
+ help
+ Base addr used for PStore ramoops memory, should be identical to
+ ramoops.mem_address parameter used by kernel
+
+config CMD_PSTORE_MEM_SIZE
+ hex "Memory size"
+ depends on CMD_PSTORE
+ default "0x1"
+ help
+ Size of PStore ramoops memory, should be identical to ramoops.mem_size
+ parameter used by kernel, a power of 2 and larger than the sum of the
+ record sizes
+
+config CMD_PSTORE_RECORD_SIZE
+ hex "Dump record size"
+ depends on CMD_PSTORE
+ default "0x1000"
+ help
+ Size of each dump done on oops/panic, should be identical to
+ ramoops.record_size parameter used by kernel and a power of 2
+ Must be non-zero
+
+config CMD_PSTORE_CONSOLE_SIZE
+ hex "Kernel console log size"
+ depends on CMD_PSTORE
+ default "0x1000"
+ help
+ Size of kernel console log, should be identical to
+ ramoops.console_size parameter used by kernel and a power of 2
+ Must be non-zero
+
+config CMD_PSTORE_FTRACE_SIZE
+ hex "FTrace log size"
+ depends on CMD_PSTORE
+ default "0x1000"
+ help
+ Size of ftrace log, should be identical to ramoops.ftrace_size
+ parameter used by kernel and a power of 2
+
+config CMD_PSTORE_PMSG_SIZE
+ hex "User space message log size"
+ depends on CMD_PSTORE
+ default "0x1000"
+ help
+ Size of user space message log, should be identical to
+ ramoops.pmsg_size parameter used by kernel and a power of 2
+
+config CMD_PSTORE_ECC_SIZE
+ int "ECC size"
+ depends on CMD_PSTORE
+ default "0"
+ help
+ if non-zero, the option enables ECC support and specifies ECC buffer
+ size in bytes (1 is a special value, means 16 bytes ECC), should be
+ identical to ramoops.ramoops_ecc parameter used by kernel
+
+endif
+
source "cmd/mvebu/Kconfig"
config CMD_TERMINAL
diff --git a/cmd/Makefile b/cmd/Makefile
index f1dd513a4b..06d7ad7375 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_CMD_PCI) += pci.o
endif
obj-$(CONFIG_CMD_PINMUX) += pinmux.o
obj-$(CONFIG_CMD_PMC) += pmc.o
+obj-$(CONFIG_CMD_PSTORE) += pstore.o
obj-$(CONFIG_CMD_PXE) += pxe.o pxe_utils.o
obj-$(CONFIG_CMD_WOL) += wol.o
obj-$(CONFIG_CMD_QFW) += qfw.o
diff --git a/cmd/pstore.c b/cmd/pstore.c
new file mode 100644
index 00..4e4d70d604
--- /dev/null
+++ b/cmd/pstore.c
@@ -0,0 +1,505 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright © 2019 Collabora Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct persistent_ram_buffer {
+ u32sig;
+ u32start;
+ u32size;
+ u8 data[0];
+};
+
+#define PERSISTENT_RAM_SIG (0x43474244)
[PATCH v5 0/3] Add command to display or save Linux PStore dumps
This serie of patches adds a new pstore command allowing to display or save ramoops logs (oops, panic, console, ftrace and user) generated by a previous kernel crash. PStore parameters can be set in U-Boot configuration file, or at run-time using "pstore set" command. For kernel using Device Tree, the parameters are dynamically added to Device Tree. Records size should be the same as the ones used by kernel, and should be a power of 2. Changes in v5: - Fix test_pstore.py license - Change log level on error messages in fdt_fixup_pstore() - Replace fdt_appendprop_…() by fdt_setprop_…() when adding a new property Changes in v4: - Fix PStore memory address in sandbox defconfig files for tests Changes in v3: - Add default value for PStore memory size - Remove default value of PStore memory address - Update config entry helps - Replace calls to debug() by log_debug() - Update documentation - Replace 1M test file by 3 * 4K files and build pstore memory during test - Add fdt_fixup_pstore() to pass PStore/Ramoops parameters to kernel Changes in v2: - Fix 64bit mode build warnings - Add documentation - Add function description comments - Replace calls to pr_debug() by debug() - Add CONFIG_CMD_PSTORE to sandbox and sandbox64 - Add unit tests Frédéric Danis (3): cmd: Add command to display or save Linux PStore dumps test: Add PStore command tests cmd: Fixup DT to pass PStore Ramoops parameters cmd/Kconfig| 71 +++ cmd/Makefile | 1 + cmd/pstore.c | 543 + common/image-fdt.c | 4 + configs/sandbox64_defconfig| 2 + configs/sandbox_defconfig | 2 + doc/index.rst | 7 + doc/pstore.rst | 76 +++ include/fdt_support.h | 3 + test/py/tests/test_pstore.py | 73 +++ test/py/tests/test_pstore_data_console.hex | Bin 0 -> 4096 bytes test/py/tests/test_pstore_data_panic1.hex | Bin 0 -> 4096 bytes test/py/tests/test_pstore_data_panic2.hex | Bin 0 -> 4096 bytes 13 files changed, 782 insertions(+) create mode 100644 cmd/pstore.c create mode 100644 doc/pstore.rst create mode 100644 test/py/tests/test_pstore.py create mode 100644 test/py/tests/test_pstore_data_console.hex create mode 100644 test/py/tests/test_pstore_data_panic1.hex create mode 100644 test/py/tests/test_pstore_data_panic2.hex -- 2.18.0
Re: [RFC PATCH 6/9] mkimage_fit_atf.sh: produce working binaries by default
Hi Petr, On 18. 03. 20 10:57, Petr Štetiar wrote: > At this moment unusable binaries are produced if bl31.bin file is > missing in order to allow passing of various CI tests. This intention of > broken binaries has to be now explicitly confirmed via new > BUILDBOT_BROKEN_BINARIES config option, so usable binaries are produced > by default from now on. > > Signed-off-by: Petr Štetiar > --- > arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh > b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh > index 1e770ba111d3..5effe05abdee 100755 > --- a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh > +++ b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh > @@ -29,11 +29,15 @@ else > fi > > if [ ! -f $BL31 ]; then > - echo "WARNING: BL31 file $BL31 NOT found, resulting binary is > non-functional" >&2 > - BL31=/dev/null > - # But U-Boot proper could be loaded in EL3 by specifying > - # firmware = "uboot"; > - # instead of "atf" in config node > + if [ "$BUILDBOT_BROKEN_BINARIES" = "y" ]; then > + BL31=/dev/null > + # But U-Boot proper could be loaded in EL3 by specifying > + # firmware = "uboot"; > + # instead of "atf" in config node > + else > + echo "ERROR: BL31 file $BL31 NOT found, resulting binary is > non-functional" >&2 > + exit 1 > + fi > fi > > cat << __HEADER_EOF > I think instead of fixing it on several places we should merge things together and fix this issue there. Take a look at thread where we discussed it with Tom. https://lists.denx.de/pipermail/u-boot/2019-December/393556.html Thanks, Michal
Re: [PATCH v3 1/2] timer: mpc83xx_timer: fix build with CONFIG_{HW_, }WATCHDOG
Dear Rasmus, In message <20200320105248.24518-1-rasmus.villem...@prevas.dk> you wrote: > The code, which is likely copied from arch/powerpc/lib/interrupts.c, > lacks a fallback definition of CONFIG_SYS_WATCHDOG_FREQ and refers to > a non-existing timestamp variable - obviously priv->timestamp is > meant. > > Signed-off-by: Rasmus Villemoes > --- > drivers/timer/mpc83xx_timer.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Could you _please_ get used to add some patch histroy below this line "---", too? I. e. some information so we can see easily what has changed between patch version and and 2, and between version 2 and 3? Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Boss, n.: According to the Oxford English Dictionary, in the Middle Ages the words "boss" and "botch" were largely synonymous, except that boss, in addition to meaning "a supervisor of workers" also meant "an ornamental stud."
Re: [PATCH v2 3/3] cmd: dm: Fixed/Added DM driver listing subcommands
Hi Sean,
On 3/19/20 7:37 PM, Sean Anderson wrote:
diff --git a/test/py/tests/test_dm.py b/test/py/tests/test_dm.py
index f6fbf8ba4c..97203b536e 100644
--- a/test/py/tests/test_dm.py
+++ b/test/py/tests/test_dm.py
@@ -4,14 +4,32 @@
import pytest
@pytest.mark.buildconfigspec('cmd_dm')
-def test_dm_drivers(u_boot_console):
-"""Test that each driver in `dm tree` is also listed in `dm drivers`."""
+def test_dm_compat(u_boot_console):
+"""Test that each driver in `dm tree` is also listed in `dm compat`."""
response = u_boot_console.run_command('dm tree')
driver_index = response.find('Driver')
assert driver_index != -1
drivers = (line[driver_index:].split()[0]
for line in response[:-1].split('\n')[2:])
+response = u_boot_console.run_command('dm compat')
+for driver in drivers:
+assert driver in response
+
Why is the above marked as being added? These lines are present in the
patch which adds the original test.
Well spotted! I had to give it a second look before I grasped what
happened there... My tests were all based on yours, and it turns out
that the last 4 lines of my last test, test_dm_static(), exactly matches
those 4 lines in your original patch. And as I had changed the command
to run in your test from "dm driver" to "dm compat", git decided to just
insert all of my changes in one block in the middle of what was
originally your test. At the bottom of the patch you can still see your
original code:
+@pytest.mark.buildconfigspec('cmd_dm')
+def test_dm_static(u_boot_console):
+"""Test that each driver in `dm static` is also listed in `dm
drivers`."""
+response = u_boot_console.run_command('dm static')
+drivers = (line[:25].rstrip() for line in
response[:-1].split('\n')[2:])
response = u_boot_console.run_command('dm drivers')
for driver in drivers:
assert driver in response
Best regards,
Niel Fourie
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-21 Fax: +49-8142-66989-80 Email: lu...@denx.de
[PATCH v2] cmd: ubi: add a command to rename volume
This commit add the command ubi rename to rename an ubi volume.
The format of the command is: ubi rename .
To enable this command, the option CMD_UBI_RENAME must be selected.
Signed-off-by: Philippe Reynes
---
cmd/Kconfig | 8
cmd/ubi.c | 43 +++
2 files changed, 51 insertions(+)
Changelog:
v2:
- added an option CMD_UBI_RENAME (feedback from Wolfgang)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6403bc4..1564694 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2172,6 +2172,14 @@ config CMD_UBI
It is also strongly encouraged to also enable CONFIG_MTD to get full
partition support.
+config CMD_UBI_RENAME
+ bool "Enable rename"
+ depends on CMD_UBI
+ default n
+ help
+ Enable a "ubi" command to rename ubi volume:
+ ubi rename
+
config CMD_UBIFS
tristate "Enable UBIFS - Unsorted block images filesystem commands"
depends on CMD_UBI
diff --git a/cmd/ubi.c b/cmd/ubi.c
index cecf251..4885661 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -251,6 +251,41 @@ out_err:
return err;
}
+#ifdef CONFIG_CMD_UBI_RENAME
+static int ubi_rename_vol(char *oldname, char *newname)
+{
+ struct ubi_volume *vol;
+ struct ubi_rename_entry rename;
+ struct ubi_volume_desc desc;
+ struct list_head list;
+
+ vol = ubi_find_volume(oldname);
+ if (!vol) {
+ printf("%s: volume %s doesn't exist\n", __func__, oldname);
+ return ENODEV;
+ }
+
+ printf("Rename UBI volume %s to %s\n", oldname, newname);
+
+ if (ubi->ro_mode) {
+ printf("%s: ubi device is in read-only mode\n", __func__);
+ return EROFS;
+ }
+
+ rename.new_name_len = strlen(newname);
+ strcpy(rename.new_name, newname);
+ rename.remove = 0;
+ desc.vol = vol;
+ desc.mode = 0;
+ rename.desc =
+ INIT_LIST_HEAD();
+ INIT_LIST_HEAD();
+ list_add(, );
+
+ return ubi_rename_volumes(ubi, );
+}
+#endif /* CONFIG_CMD_UBI_RENAME */
+
static int ubi_volume_continue_write(char *volume, void *buf, size_t size)
{
int err = 1;
@@ -604,6 +639,11 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return ubi_remove_vol(argv[2]);
}
+#ifdef CONFIG_CMD_UBI_RENAME
+ if (strncmp(argv[1], "rename", 6) == 0)
+ return ubi_rename_vol(argv[2], argv[3]);
+#endif
+
if (strncmp(argv[1], "skipcheck", 9) == 0) {
/* E.g., change skip_check flag */
if (argc == 4) {
@@ -692,6 +732,9 @@ U_BOOT_CMD(
" - Read volume to address with size\n"
"ubi remove[vol] volume"
" - Remove volume\n"
+#ifdef CONFIG_CMD_UBI_RENAME
+ "ubi rename oldname newname\n"
+#endif
"ubi skipcheck volume on/off - Set or clear skip_check flag in volume
header\n"
"[Legends]\n"
" volume: character name\n"
--
2.7.4
[PATCH v5 2/3] test: Add PStore command tests
Add PStore command to sandbox and sandbox64 defconfigs.
Add test checking:
- 'pstore display' of all records
- 'pstore display' only the 2nd dump record
- 'pstore save' of all records
Signed-off-by: Frédéric Danis
Cc: Tom Rini
Cc: Heinrich Schuchardt
Cc: Wolfgang Denk
Cc: Heiko Schocher
---
Changes in v5:
- Fix test_pstore.py license
Changes in v4:
- Fix PStore memory address in sandbox defconfig files for tests
Changes in v3:
- Replace 1M test file by 3 * 4K files and build pstore memory during test
New in v2:
- Add unit tests
configs/sandbox64_defconfig| 2 +
configs/sandbox_defconfig | 2 +
test/py/tests/test_pstore.py | 73 +
test/py/tests/test_pstore_data_console.hex | Bin 0 -> 4096 bytes
test/py/tests/test_pstore_data_panic1.hex | Bin 0 -> 4096 bytes
test/py/tests/test_pstore_data_panic2.hex | Bin 0 -> 4096 bytes
6 files changed, 77 insertions(+)
create mode 100644 test/py/tests/test_pstore.py
create mode 100644 test/py/tests/test_pstore_data_console.hex
create mode 100644 test/py/tests/test_pstore_data_panic1.hex
create mode 100644 test/py/tests/test_pstore_data_panic2.hex
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 71a4d7fccb..f7b3544ae5 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -68,6 +68,8 @@ CONFIG_CMD_CBFS=y
CONFIG_CMD_CRAMFS=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_PSTORE=y
+CONFIG_CMD_PSTORE_MEM_ADDR=0x300
CONFIG_MAC_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_OF_CONTROL=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index f96891ecae..64b878abac 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -77,6 +77,8 @@ CONFIG_CMD_CBFS=y
CONFIG_CMD_CRAMFS=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_PSTORE=y
+CONFIG_CMD_PSTORE_MEM_ADDR=0x300
CONFIG_MAC_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_OF_CONTROL=y
diff --git a/test/py/tests/test_pstore.py b/test/py/tests/test_pstore.py
new file mode 100644
index 00..7388f33506
--- /dev/null
+++ b/test/py/tests/test_pstore.py
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2020, Collabora
+# Author: Frédéric Danis
+
+import pytest
+import u_boot_utils
+import tempfile
+import shutil
+
+PSTORE_ADDR=0x300
+PSTORE_LENGTH=0x10
+PSTORE_PANIC1='test/py/tests/test_pstore_data_panic1.hex'
+PSTORE_PANIC2='test/py/tests/test_pstore_data_panic2.hex'
+PSTORE_CONSOLE='test/py/tests/test_pstore_data_console.hex'
+ADDR=0x0108
+
+def load_pstore(u_boot_console):
+"""Load PStore records from sample files"""
+
+output = u_boot_console.run_command_list([
+'host load hostfs - 0x%x %s' % (PSTORE_ADDR, PSTORE_PANIC1),
+'host load hostfs - 0x%x %s' % (PSTORE_ADDR + 4096, PSTORE_PANIC2),
+'host load hostfs - 0x%x %s' % (PSTORE_ADDR + 253 * 4096,
PSTORE_CONSOLE),
+'pstore set 0x%x 0x%x' % (PSTORE_ADDR, PSTORE_LENGTH)])
+
+def checkfile(u_boot_console, path, filesize, checksum):
+"""Check file against MD5 checksum"""
+
+output = u_boot_console.run_command_list([
+'load hostfs - %x %s' % (ADDR, path),
+'printenv filesize'])
+assert('filesize=%x' % (filesize) in ''.join(output))
+
+output = u_boot_console.run_command_list([
+'md5sum %x $filesize' % ADDR,
+'setenv filesize'])
+assert(checksum in ''.join(output))
+
+@pytest.mark.buildconfigspec('cmd_pstore')
+def test_pstore_display_all_records(u_boot_console):
+"""Test that pstore displays all records."""
+
+u_boot_console.run_command('')
+load_pstore(u_boot_console)
+response = u_boot_console.run_command('pstore display')
+assert(' Dump' in response)
+assert(' Console' in response)
+
+@pytest.mark.buildconfigspec('cmd_pstore')
+def test_pstore_display_one_record(u_boot_console):
+"""Test that pstore displays only one record."""
+
+u_boot_console.run_command('')
+load_pstore(u_boot_console)
+response = u_boot_console.run_command('pstore display dump 1')
+assert('Panic#2 Part1' in response)
+assert(' Console' not in response)
+
+@pytest.mark.buildconfigspec('cmd_pstore')
+def test_pstore_save_records(u_boot_console):
+"""Test that pstore saves all records."""
+
+outdir = tempfile.mkdtemp()
+
+u_boot_console.run_command('')
+load_pstore(u_boot_console)
+u_boot_console.run_command('pstore save hostfs - %s' % (outdir))
+
+checkfile(u_boot_console, '%s/dmesg-ramoops-0' % (outdir), 3798,
'8059335ab4cfa62c77324c491659c503')
+checkfile(u_boot_console, '%s/dmesg-ramoops-1' % (outdir), 4035,
'3ff30df3429d81939c75d0070b5187b9')
+checkfile(u_boot_console, '%s/console-ramoops-0' % (outdir), 4084,
'bb44de4a9b8ebd9b17ae98003287325b')
+
+shutil.rmtree(outdir)
diff --git a/test/py/tests/test_pstore_data_console.hex
b/test/py/tests/test_pstore_data_console.hex
new
[PATCH v5 3/3] cmd: Fixup DT to pass PStore Ramoops parameters
To simplify configuration and keep synchronized the PStore/Ramoops between
U-Boot and the Linux kernel, this commit dynamically adds the Ramoops
parameters defined in the U-Boot session to the Device Tree.
Signed-off-by: Frédéric Danis
Cc: Tom Rini
Cc: Heinrich Schuchardt
Cc: Wolfgang Denk
Cc: Heiko Schocher
---
Changes in v5:
- Change log level on error messages in fdt_fixup_pstore()
- Replace fdt_appendprop_…() by fdt_setprop_…() when adding a new property
Changes in v4: None
New in v3:
- Add fdt_fixup_pstore() to pass PStore/Ramoops parameters to kernel
cmd/pstore.c | 38 ++
common/image-fdt.c| 4
doc/pstore.rst| 2 ++
include/fdt_support.h | 3 +++
4 files changed, 47 insertions(+)
diff --git a/cmd/pstore.c b/cmd/pstore.c
index 4e4d70d604..8507123a44 100644
--- a/cmd/pstore.c
+++ b/cmd/pstore.c
@@ -479,6 +479,44 @@ static int do_pstore(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return c->cmd(cmdtp, flag, argc, argv);
}
+void fdt_fixup_pstore(void *blob)
+{
+ char node[32];
+ int nodeoffset;/* node offset from libfdt */
+
+ nodeoffset = fdt_path_offset(blob, "/");
+ if (nodeoffset < 0) {
+ /* Not found or something else bad happened. */
+ log_err("fdt_path_offset() returned %s\n",
fdt_strerror(nodeoffset));
+ return;
+ }
+
+ nodeoffset = fdt_add_subnode(blob, nodeoffset, "reserved-memory");
+ if (nodeoffset < 0) {
+ log_err("Add 'reserved-memory' node failed: %s\n",
+ fdt_strerror(nodeoffset));
+ return;
+ }
+ fdt_setprop_u32(blob, nodeoffset, "#address-cells", 2);
+ fdt_setprop_u32(blob, nodeoffset, "#size-cells", 2);
+ fdt_setprop_empty(blob, nodeoffset, "ranges");
+
+ sprintf(node, "ramoops@%llx", (unsigned long long)pstore_addr);
+ nodeoffset = fdt_add_subnode(blob, nodeoffset, node);
+ if (nodeoffset < 0) {
+ log_err("Add '%s' node failed: %s\n", node,
fdt_strerror(nodeoffset));
+ return;
+ }
+ fdt_setprop_string(blob, nodeoffset, "compatible", "ramoops");
+ fdt_setprop_u64(blob, nodeoffset, "reg", pstore_addr);
+ fdt_appendprop_u64(blob, nodeoffset, "reg", pstore_length);
+ fdt_setprop_u32(blob, nodeoffset, "record-size", pstore_record_size);
+ fdt_setprop_u32(blob, nodeoffset, "console-size", pstore_console_size);
+ fdt_setprop_u32(blob, nodeoffset, "ftrace-size", pstore_ftrace_size);
+ fdt_setprop_u32(blob, nodeoffset, "pmsg-size", pstore_pmsg_size);
+ fdt_setprop_u32(blob, nodeoffset, "ecc-size", pstore_ecc_size);
+}
+
U_BOOT_CMD(pstore, 10, 0, do_pstore,
"Manage Linux Persistent Storage",
"set [record-size] [console-size] [ftrace-size]
[pmsg_size] [ecc-size]\n"
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 3002948b6b..491d55ad1a 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -547,6 +547,10 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
}
/* Update ethernet nodes */
fdt_fixup_ethernet(blob);
+#if CONFIG_IS_ENABLED(CMD_PSTORE)
+ /* Append PStore configuration */
+ fdt_fixup_pstore(blob);
+#endif
if (IMAGE_OF_BOARD_SETUP) {
fdt_ret = ft_board_setup(blob, gd->bd);
if (fdt_ret) {
diff --git a/doc/pstore.rst b/doc/pstore.rst
index 90a8e1c2cb..0038249976 100644
--- a/doc/pstore.rst
+++ b/doc/pstore.rst
@@ -24,6 +24,8 @@ i.e.::
The same values should be set in U-Boot to be able to retrieve the records.
This values can be set at build time in U-Boot configuration file, or at
runtime.
+U-Boot automatically patches the Device Tree to pass the Ramoops parameters to
+the kernel.
The PStore configuration parameters are:
diff --git a/include/fdt_support.h b/include/fdt_support.h
index ba14acd7f6..7afbdcfe37 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -350,4 +350,7 @@ int fdt_update_ethernet_dt(void *blob);
#ifdef CONFIG_FSL_MC_ENET
void fdt_fixup_board_enet(void *blob);
#endif
+#ifdef CONFIG_CMD_PSTORE
+void fdt_fixup_pstore(void *blob);
+#endif
#endif /* ifndef __FDT_SUPPORT_H */
--
2.18.0
[PATCH v2 2/2] spi: allow calling WATCHDOG_RESET during long reads
Some boards have a watchdog with a short (~1s) timeout and a slowish
nor flash. For example, I'm currently working on a board where doing a
2MB read from the flash will cause the board to reset.
Similar to the various CHUNKSZ, CHUNKSZ_SHA1 etc. defines that are
used to chop hash digest and/or memmove operations into chunks, doing
a WATCHDOG_RESET for each, introduce a CONFIG_SPI_FLASH_READ_CHUNKSZ
config knob. We keep the default of doing the whole read in one go,
but the board config can set a suitable threshold.
Signed-off-by: Rasmus Villemoes
---
drivers/mtd/spi/Kconfig| 12
drivers/mtd/spi/spi-nor-core.c | 4 +++-
drivers/mtd/spi/spi-nor-tiny.c | 4 +++-
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 018e8c597e..9dda0047d2 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -169,6 +169,18 @@ config SPI_FLASH_USE_4K_SECTORS
Please note that some tools/drivers/filesystems may not work with
4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
+config SPI_FLASH_READ_CHUNKSZ
+ int "Chunk size for reading from SPI flash"
+ depends on SPI_FLASH
+ default 0
+ help
+ Some boards have a watchdog with a very short timeout
+ period. Doing large reads from a SPI flash on such a board
+ causes the watchdog to fire and reset the board. Setting
+ this option to a non-zero value will ensure that
+ watchdog_reset() gets called after each read of that many
+ bytes.
+
config SPI_FLASH_DATAFLASH
bool "AT45xxx DataFlash support"
depends on SPI_FLASH && DM_SPI_FLASH
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index c5d98debf0..8c846a4b42 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -82,6 +82,7 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t
from, size_t len,
SPI_MEM_OP_DUMMY(nor->read_dummy, 1),
SPI_MEM_OP_DATA_IN(len, buf, 1));
size_t remaining = len;
+ size_t chunksz = CONFIG_SPI_FLASH_READ_CHUNKSZ ?: UINT_MAX;
int ret;
/* get transfer protocols. */
@@ -94,7 +95,7 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t
from, size_t len,
op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
while (remaining) {
- op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
+ op.data.nbytes = min(remaining, chunksz);
ret = spi_mem_adjust_op_size(nor->spi, );
if (ret)
return ret;
@@ -102,6 +103,7 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor,
loff_t from, size_t len,
ret = spi_mem_exec_op(nor->spi, );
if (ret)
return ret;
+ WATCHDOG_RESET();
op.addr.val += op.data.nbytes;
remaining -= op.data.nbytes;
diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
index d91989567d..e9d490ba52 100644
--- a/drivers/mtd/spi/spi-nor-tiny.c
+++ b/drivers/mtd/spi/spi-nor-tiny.c
@@ -81,6 +81,7 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t
from, size_t len,
SPI_MEM_OP_DUMMY(nor->read_dummy, 1),
SPI_MEM_OP_DATA_IN(len, buf, 1));
size_t remaining = len;
+ size_t chunksz = CONFIG_SPI_FLASH_READ_CHUNKSZ ?: UINT_MAX;
int ret;
/* get transfer protocols. */
@@ -93,7 +94,7 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t
from, size_t len,
op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
while (remaining) {
- op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
+ op.data.nbytes = min(remaining, chunksz);
ret = spi_mem_adjust_op_size(nor->spi, );
if (ret)
return ret;
@@ -101,6 +102,7 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor,
loff_t from, size_t len,
ret = spi_mem_exec_op(nor->spi, );
if (ret)
return ret;
+ WATCHDOG_RESET();
op.addr.val += op.data.nbytes;
remaining -= op.data.nbytes;
--
2.23.0
[PATCH v2 1/2] spi: call WATCHDOG_RESET() in spi_nor_wait_till_ready_with_timeout()
I have a board for which doing "sf erase 0x10 0x8"
consistently causes the external watchdog circuit to reset the
board. Make sure to pet the watchdog during slow operations such as
erasing or writing large areas of a spi nor flash.
Signed-off-by: Rasmus Villemoes
---
drivers/mtd/spi/spi-nor-core.c | 2 ++
drivers/mtd/spi/spi-nor-tiny.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 7b6ad495ac..c5d98debf0 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "sf_internal.h"
@@ -424,6 +425,7 @@ static int spi_nor_wait_till_ready_with_timeout(struct
spi_nor *nor,
unsigned long timebase;
int ret;
+ WATCHDOG_RESET();
timebase = get_timer(0);
while (get_timer(timebase) < timeout) {
diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
index ccc0ab07af..d91989567d 100644
--- a/drivers/mtd/spi/spi-nor-tiny.c
+++ b/drivers/mtd/spi/spi-nor-tiny.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "sf_internal.h"
@@ -324,6 +325,7 @@ static int spi_nor_wait_till_ready_with_timeout(struct
spi_nor *nor,
unsigned long timebase;
int ret;
+ WATCHDOG_RESET();
timebase = get_timer(0);
while (get_timer(timebase) < timeout) {
--
2.23.0
Re: [PATCH v3 0/3] Add command to display or save Linux PStore dumps
Dear Frédéric, In message <9b0b5776-cb47-dfb2-ab77-36c89dc64...@collabora.com> you wrote: > > But, when debugging kernel crashes occurring either early in boot or > hard crashes later, it can be helpful to be able to retrieve logs using > the U-Boot session. Full agreement, and we had such a feature working and in mainline already 17+ years ago. It's sad that people rather reinvent the wheel instead of using existing functionality (or reviving it, if it has been broken over time). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Be wiser than other people if you can, but do not tell them so. -- Philip Earl of Chesterfield
Re: [PATCH] tools: fw_env: use erasesize from MEMGETINFO ioctl
Dear Rasmus, In message <20200320140414.19689-1-rasmus.villem...@prevas.dk> you wrote: > > Having different fw_env.config files for the different revisions is > highly impractical, and the correct information is already available > right at our fingertips. So use the erasesize returned by the > MEMGETINFO ioctl when the fourth column is absent or contains a 0. > > As I'm only testing this on a NOR flash, I'm only changing the logic > for that case, though I think it should be possible for the other > types as well. > > Signed-off-by: Rasmus Villemoes > --- > tools/env/fw_env.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c > index 381739d28d..87c3504315 100644 > --- a/tools/env/fw_env.c > +++ b/tools/env/fw_env.c > @@ -1647,6 +1647,8 @@ static int check_device_config(int dev) > goto err; > } > DEVTYPE(dev) = mtdinfo.type; > + if (DEVESIZE(dev) == 0 && mtdinfo.type == MTD_NORFLASH) > + DEVESIZE(dev) = mtdinfo.erasesize; > if (DEVESIZE(dev) == 0) > /* Assume the erase size is the same as the env-size */ > DEVESIZE(dev) = ENVSIZE(dev); What happens if you - say - have an environment size of 16 KiB and an erase block size of 4 KiB? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson
Re: [PATCH] tools: fw_env: use erasesize from MEMGETINFO ioctl
On 20/03/2020 15.11, Wolfgang Denk wrote: > Dear Rasmus, > > In message <20200320140414.19689-1-rasmus.villem...@prevas.dk> you wrote: >> >> Having different fw_env.config files for the different revisions is >> highly impractical, and the correct information is already available >> right at our fingertips. So use the erasesize returned by the >> MEMGETINFO ioctl when the fourth column is absent or contains a 0. >> >> As I'm only testing this on a NOR flash, I'm only changing the logic >> for that case, though I think it should be possible for the other >> types as well. >> >> Signed-off-by: Rasmus Villemoes >> --- >> tools/env/fw_env.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c >> index 381739d28d..87c3504315 100644 >> --- a/tools/env/fw_env.c >> +++ b/tools/env/fw_env.c >> @@ -1647,6 +1647,8 @@ static int check_device_config(int dev) >> goto err; >> } >> DEVTYPE(dev) = mtdinfo.type; >> +if (DEVESIZE(dev) == 0 && mtdinfo.type == MTD_NORFLASH) >> +DEVESIZE(dev) = mtdinfo.erasesize; >> if (DEVESIZE(dev) == 0) >> /* Assume the erase size is the same as the env-size */ >> DEVESIZE(dev) = ENVSIZE(dev); > > What happens if you - say - have an environment size of 16 KiB and > an erase block size of 4 KiB? The right thing - just as in my test case of an environment of 8K and erase block size of 4K, ENVSECTORS gets computed as 2 (or 4 in your example). And if the environment has a size which is not a multiple of the erase block size, all the same logic as usual applies. It really works just the same as if one explicitly put in an erase block size in fw_env.config of 4K, but as I wrote in the commit log, there are cases where one has to support different flashes with different erase block sizes. Now, if somebody has put in 0 for the erase block size (relying on the env size being used) and a 1 in the ENVSECTORS column, then yes, this will break. I can certainly add an additional check for ENVSECTORS(dev) being 0 in order to apply the mtdinfo.erasesize. Rasmus
[PATCH] tools: fw_env: use erasesize from MEMGETINFO ioctl
We have a board with several revisions. The older ones use a nor flash with 64k erase size, while the newer have a flash with 4k sectors. The environment size is 8k. Currently, we have to put a column containing 0x1 (64k) in fw_env.config in order for it to work on the older boards. But that ends up wasting quite a lot of time on the newer boards that could just erase the 8k occupied by the environment - strace says the 64k erase takes 0.405 seconds. With this patch, as expected, that's about an 8-fold better, at 0.043 seconds. Having different fw_env.config files for the different revisions is highly impractical, and the correct information is already available right at our fingertips. So use the erasesize returned by the MEMGETINFO ioctl when the fourth column is absent or contains a 0. As I'm only testing this on a NOR flash, I'm only changing the logic for that case, though I think it should be possible for the other types as well. Signed-off-by: Rasmus Villemoes --- tools/env/fw_env.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 381739d28d..87c3504315 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1647,6 +1647,8 @@ static int check_device_config(int dev) goto err; } DEVTYPE(dev) = mtdinfo.type; + if (DEVESIZE(dev) == 0 && mtdinfo.type == MTD_NORFLASH) + DEVESIZE(dev) = mtdinfo.erasesize; if (DEVESIZE(dev) == 0) /* Assume the erase size is the same as the env-size */ DEVESIZE(dev) = ENVSIZE(dev); -- 2.23.0
Re: [PATCH] tools: fw_env: use erasesize from MEMGETINFO ioctl
On 20/03/2020 15.27, Rasmus Villemoes wrote:
> On 20/03/2020 15.11, Wolfgang Denk wrote:
>> Dear Rasmus,
>>
>> In message <20200320140414.19689-1-rasmus.villem...@prevas.dk> you wrote:
>>>
>>> Having different fw_env.config files for the different revisions is
>>> highly impractical, and the correct information is already available
>>> right at our fingertips. So use the erasesize returned by the
>>> MEMGETINFO ioctl when the fourth column is absent or contains a 0.
>>>
>>> As I'm only testing this on a NOR flash, I'm only changing the logic
>>> for that case, though I think it should be possible for the other
>>> types as well.
>>>
>>> Signed-off-by: Rasmus Villemoes
>>> ---
>>> tools/env/fw_env.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
>>> index 381739d28d..87c3504315 100644
>>> --- a/tools/env/fw_env.c
>>> +++ b/tools/env/fw_env.c
>>> @@ -1647,6 +1647,8 @@ static int check_device_config(int dev)
>>> goto err;
>>> }
>>> DEVTYPE(dev) = mtdinfo.type;
>>> + if (DEVESIZE(dev) == 0 && mtdinfo.type == MTD_NORFLASH)
>>> + DEVESIZE(dev) = mtdinfo.erasesize;
>>> if (DEVESIZE(dev) == 0)
>>> /* Assume the erase size is the same as the env-size */
>>> DEVESIZE(dev) = ENVSIZE(dev);
>>
>> What happens if you - say - have an environment size of 16 KiB and
>> an erase block size of 4 KiB?
>
> The right thing - just as in my test case of an environment of 8K and
> erase block size of 4K, ENVSECTORS gets computed as 2 (or 4 in your
> example). And if the environment has a size which is not a multiple of
> the erase block size, all the same logic as usual applies.
>
> It really works just the same as if one explicitly put in an erase block
> size in fw_env.config of 4K, but as I wrote in the commit log, there are
> cases where one has to support different flashes with different erase
> block sizes.
>
> Now, if somebody has put in 0 for the erase block size (relying on the
> env size being used) and a 1 in the ENVSECTORS column, then yes, this
> will break.
But, it won't break silently - there's already a check
if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) {
Rasmus
[PATCH] CMD: random: fix return code
As of today 'random' command return 1 (CMD_RET_FAILURE) in case
of successful execution and 0 (CMD_RET_SUCCESS) in case of bad
arguments. Fix that.
NOTE: we remove printing usage information from command body
so it won't print twice.
Signed-off-by: Eugeniy Paltsev
---
cmd/mem.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/cmd/mem.c b/cmd/mem.c
index 6d54f195272..6b4897dfd94 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -1102,10 +1102,8 @@ static int do_random(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
unsigned char *buf8;
unsigned int i;
- if (argc < 3 || argc > 4) {
- printf("usage: %s []\n", argv[0]);
- return 0;
- }
+ if (argc < 3 || argc > 4)
+ return CMD_RET_USAGE;
len = simple_strtoul(argv[2], NULL, 16);
addr = simple_strtoul(argv[1], NULL, 16);
@@ -1132,7 +1130,8 @@ static int do_random(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
unmap_sysmem(start);
printf("%lu bytes filled with random data\n", len);
- return 1;
+
+ return CMD_RET_SUCCESS;
}
#endif
--
2.21.1
[PATCH v7 07/12] arm: actions: add S700 SoC device tree
This patch adds .dtsi file(sync with Linux 5.5-rc6 with hash "b3a987b0264d")
and required binding for S700 SoC that is a 64-bit Quad-core ARM
Cortex-A53 cores.
It also provisions dts file to be built based on selected
platform(CONFIG_MACH_S900/S700).
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* No changes.
Changes since v5:
* Added reviwed-by tag.
Changes since v4:
* Move it to 07/11 from 05/11.
Changes since v3:
* Updated commit message to the Linux tag to
which the dtsi file is synced.
Changes since v2:
* Synced DTS bindings with Linux 5.5.
Changes since v1:
* Moved the u-boot specific changes to s700-u-boot.dtsi, now
s700.dtsi is in complete sync with Linux 4.20.
---
arch/arm/dts/Makefile | 6 +-
arch/arm/dts/s700.dtsi | 248 +
include/dt-bindings/clock/actions,s700-cmu.h | 118
include/dt-bindings/reset/actions,s700-reset.h | 34
4 files changed, 404 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/s700.dtsi
create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h
create mode 100644 include/dt-bindings/reset/actions,s700-reset.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2..308c76b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -64,8 +64,10 @@ dtb-$(CONFIG_KIRKWOOD) += \
kirkwood-pogo_e02.dtb \
kirkwood-sheevaplug.dtb
-dtb-$(CONFIG_ARCH_OWL) += \
- bubblegum_96.dtb
+dtb-$(CONFIG_MACH_S900) += \
+bubblegum_96.dtb
+dtb-$(CONFIG_MACH_S700) += \
+s700-cubieboard7.dtb
dtb-$(CONFIG_ROCKCHIP_PX30) += \
px30-evb.dtb \
diff --git a/arch/arm/dts/s700.dtsi b/arch/arm/dts/s700.dtsi
new file mode 100644
index 000..2006ad5
--- /dev/null
+++ b/arch/arm/dts/s700.dtsi
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "actions,s700";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secmon@1f00 {
+ reg = <0x0 0x1f00 0x0 0x100>;
+ no-map;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <>, <>, <>, <>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ hosc: hosc {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
+
+ losc: losc {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@e00f1000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xe00f1000 0x0 0x1000>,
+ <0x0 0xe00f2000 0x0 0x2000>,
+ <0x0 0xe00f4000 0x0 0x2000>,
+ <0x0 0xe00f6000 0x0 0x2000>;
+ interrupts = ;
+
[PATCH v7 11/12] arm: add Cubieboard7 board support
The Cubieboard is a single board computer containing a
Actions S700 SoC(with 4 ARMv8 Cortex-A53 cores).
This patch adds respective defconfig alongwith .dts(copied
from Linux v5.5-rc6 with hash "b3a987b0264d").
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* Added Reviewed-by tag.
Changes since v5:
* Trimmed of the cubieboard7_defconfig.
Changes since v4:
* No changes.
Changes since v3:
* added reviewed-by: tag.
Changes since v2:
* No changes.
Changes since v1:
* No changes.
---
arch/arm/dts/s700-cubieboard7.dts | 92 +++
configs/cubieboard7_defconfig | 9
2 files changed, 101 insertions(+)
create mode 100644 arch/arm/dts/s700-cubieboard7.dts
create mode 100644 configs/cubieboard7_defconfig
diff --git a/arch/arm/dts/s700-cubieboard7.dts
b/arch/arm/dts/s700-cubieboard7.dts
new file mode 100644
index 000..63e375c
--- /dev/null
+++ b/arch/arm/dts/s700-cubieboard7.dts
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "s700.dtsi"
+
+/ {
+ compatible = "cubietech,cubieboard7", "actions,s700";
+ model = "CubieBoard7";
+
+ aliases {
+ serial3 =
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+
+ memory@1,e000 {
+ device_type = "memory";
+ reg = <0x1 0xe000 0x0 0x0>;
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ i2c0_default: i2c0_default {
+ pinmux {
+ groups = "i2c0_mfp";
+ function = "i2c0";
+ };
+ pinconf {
+ pins = "i2c0_sclk", "i2c0_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c1_default: i2c1_default {
+ pinmux {
+ groups = "i2c1_dummy";
+ function = "i2c1";
+ };
+ pinconf {
+ pins = "i2c1_sclk", "i2c1_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c2_default: i2c2_default {
+ pinmux {
+ groups = "i2c2_dummy";
+ function = "i2c2";
+ };
+ pinconf {
+ pins = "i2c2_sclk", "i2c2_sdata";
+ bias-pull-up;
+ };
+ };
+};
+
+ {
+ clocks = <>;
+};
+
+ {
+ status = "okay";
+};
diff --git a/configs/cubieboard7_defconfig b/configs/cubieboard7_defconfig
new file mode 100644
index 000..d12c293
--- /dev/null
+++ b/configs/cubieboard7_defconfig
@@ -0,0 +1,9 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OWL=y
+CONFIG_MACH_S700=y
+CONFIG_IDENT_STRING="\ncubieboard7"
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyOWL3,115200n8"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DEFAULT_DEVICE_TREE="s700-cubieboard7"
--
2.7.4
[PATCH v7 08/12] arm: dts: actions: s700: add u-boot specific dtsi file
Devices like uart and clk are needed to be enabled before relocation.
this patch adds u-boot.dtsi file that mark these device as dm-pre-reloc.
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* No changes.
Changes since v5:
* Added reviwed-by tag.
Changes since v4:
* Moved it to 08/11 to 06/11.
Changes since v3:
* Replaced dtsi with dts in subject line along with arm:dts:
to the prefix.
Changes since v2:
* Added License.
Changes since v1:
* This is newly added file that was *not* present in v1 and
contains u-boot specific changes.
---
arch/arm/dts/s700-u-boot.dtsi | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 arch/arm/dts/s700-u-boot.dtsi
diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
new file mode 100644
index 000..a527ccc
--- /dev/null
+++ b/arch/arm/dts/s700-u-boot.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Amit Singh Tomar
+ */
+
+/{
+ soc {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.7.4
[PATCH v7 12/12] doc: boards: add Cubieboard7 documentation
This adds build and flash steps for Actions S700 based Cubieboard7 board. Signed-off-by: Amit Singh Tomar --- Changes since v6: * No changes. Changes since v5: * No changes. Changes since v4: * No changes. Changes since v3: * Convert plain text documentation to reStructuredText format. Changes since v2: * No Change. Changes since v1: * No Change. --- doc/board/actions/cubieboard7.rst | 115 ++ doc/board/actions/index.rst | 10 doc/board/index.rst | 1 + 3 files changed, 126 insertions(+) create mode 100644 doc/board/actions/cubieboard7.rst create mode 100644 doc/board/actions/index.rst diff --git a/doc/board/actions/cubieboard7.rst b/doc/board/actions/cubieboard7.rst new file mode 100644 index 000..ce39e6b --- /dev/null +++ b/doc/board/actions/cubieboard7.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2020 Amit Singh Tomar + +ACTIONS + + +About this +-- + +This document describes build and flash steps for Actions S700 SoC based Cubieboard7 +board. + +Cubieboard7 initial configuration +- + +Default Cubieboard7 comes with pre-installed Android where U-Boot is configured with +a bootdelay of 0, entering a prompt by pressing keys does not seem to work. + +Though, one can enter ADFU mode and flash debian image(from host machine) where +getting into u-boot prompt is easy. + +Enter ADFU Mode + + +Before write the firmware, let the development board entering the ADFU mode: insert +one end of the USB cable to the PC, press and hold the ADFU button, and then connect +the other end of the USB cable to the Mini USB port of the development board, release +the ADFU button, after connecting it will enter the ADFU mode. + +Check whether entered ADFU Mode + + +The user needs to run the following command on the PC side to check if the ADFU +device is detected. ID realted to "Actions Semiconductor Co., Ltd" means that +the PC side has been correctly detected ADFU device, the development board +also enter into the ADFU mode. + +.. code-block:: none + + $ lsusb + Bus 001 Device 005: ID 04f2:b2eb Chicony Electronics Co., Ltd + Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] + Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver + Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 003 Device 013: ID 10d6:10d6 Actions Semiconductor Co., Ltd + Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + +Flashing debian image +- + +.. code-block:: none + + $ sudo ./ActionsFWU.py --fw=debian-stretch-desktop-cb7-emmc-v2.0.fw + ActionsFWU.py : 1.0.150828.0830 + libScript.so: 2.3.150825.0951 + libFileSystem.so: 2.3.150825.0952 + libProduction.so: 2.3.150915.1527 + =burn all partition + FW_VER: 3.10.37.180608 + 3% DOWNLOAD ADFUDEC ... + 5% DOWNLOAD BOOT PARA ... + 7% SWITCH ADFUDEC ... + 12% DOWNLOAD BL31 ... + 13% DOWNLOAD BL32 ... + 15% DOWNLOAD VMLINUX ... + 20% DOWNLOAD INITRD ... + 24% DOWNLOAD FDT ... + 27% DOWNLOAD ADFUS ... + 30% SWITCH ADFUS ... + 32% DOWNLOAD MBR ... + 35% DOWNLOAD PARTITIONS ... + WRITE_MBRC_PARTITION + 35% write p0 size = 2048 : ok + WRITE_BOOT_PARTITION + 35% write p1 size = 2048 : ok + WRITE_MISC_PARTITION + 36% write p2 size = 98304 : ok + WRITE_SYSTEM_PARTITION + 94% write p3 size = 4608000 : ok + FORMAT_SWAP_PARTITION + 94% write p4 size = 20480 : ok + 95% TRANSFER OVER ... + Firmware upgrade successfully! + +Debian image can be downloaded from here[1]. + +Once debian image is flashed, one can get into u-boot prompt by pressing any key and from +there run ums command(make sure, usb cable is connected between host and target): + +.. code-block:: none + + owl> ums 0 mmc 1 + +Above command would mount debian image partition on host machine. + +Building U-BOOT proper image + + +.. code-block:: none + + $ make clean + $ export CROSS_COMPILE=aarch64-linux-gnu- + $ make ARCH=arm cubieboard7_defconfig + $ make -j16 + $ mkimage -A arm -T firmware -C none -O u-boot -a 0x1100 -e 0x1100 -d u-boot-dtb.bin u-boot-dtb.img >/dev/null + +u-boot-dtb.img can now be flashed to debian image partition mounted on host machine. + +.. code-block:: none + + $ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1024 seek=3072 + +[1]: https://pan.baidu.com/s/1uawPr0Jao2HgWFLZCLzHAg#list/path=%2FCubieBoard_Download%2FBoard%2FCubieBoard7%2F%E6%96%B9%E7%B3%96%E6%96%B9%E6%A1%88%E5%BC%80%E5%8F%91%E8%B5%84%E6%96%99%2FImage%2FDebian%2FV2.1-test=%2F diff --git a/doc/board/actions/index.rst
[PATCH v7 00/12] Actions S700 SoC support
This adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], It's Quad-core ARMv8 SoC with Cortex-A53 cores. Peripheral like UART seems to be compatible with S900 SoC(basic support for it is alreay present in u-boot). This Series(v7) fixes a serious Bug that breaks S900, it was there since v5.Thanks to Andre for pointing it out. Series(v6)[3] does following changes: * [PATCH v5 06/11] becomes [PATCH v6 03/11] * [PATCH v5 03/11] becomes [PATCH v6 04/11] * Introduce a new patch to move defconfig options to Kconfig which is [PATCH v6 10/12] Series(v5)[4] just re-orders the patches so that U-BOOT(with bubblegum96_defconfig) builds after every patch of the series(suggested by Andre). S700 support is tested[5] on Cubieboard7 board and S900 support is just compiled tested. This patch series can be tested using below tree: https://github.com/Atomar25/u-boot/commits/s700_v7 [1]: http://www.cubietech.com/product-detail/cubieboard7/ [2]: http://www.actions-semi.com/en/productview.aspx?id=225 [3]: http://u-boot.10912.n7.nabble.com/PATCH-v6-00-12-Actions-S700-SoC-support-td403562.html#a403567 [4]: http://u-boot.10912.n7.nabble.com/PATCH-v5-00-11-Actions-S700-SoC-support-td402752.html#a402762 [5]: https://paste.ubuntu.com/p/w2FvzmZBcS/ Amit Singh Tomar (12): arm: actions: Add common framework for Actions Owl Semi SoCs arm: actions: rename sysmap-s900 to sysmap-owl serial: actions: add compatible string arm: dts: sync dts for Action Semi S900 arm: dts: actions: s900: add u-boot specific dtsi file clk: actions: Add common clock driver arm: actions: add S700 SoC device tree arm: dts: actions: s700: add u-boot specific dtsi file arm: add support Actions Semi S700 actions: Move defconfig options to Kconfig arm: add Cubieboard7 board support doc: boards: add Cubieboard7 documentation MAINTAINERS| 2 + arch/arm/Kconfig | 5 +- arch/arm/dts/Makefile | 6 +- arch/arm/dts/s700-cubieboard7.dts | 92 +++ arch/arm/dts/s700-u-boot.dtsi | 18 ++ arch/arm/dts/s700.dtsi | 248 +++ arch/arm/dts/s900-u-boot.dtsi | 17 ++ arch/arm/dts/s900.dtsi | 322 +++-- arch/arm/include/asm/arch-owl/clk_s900.h | 57 - arch/arm/include/asm/arch-owl/regs_s700.h | 56 + arch/arm/mach-owl/Kconfig | 50 ++-- arch/arm/mach-owl/Makefile | 3 +- arch/arm/mach-owl/soc.c| 57 + arch/arm/mach-owl/sysmap-owl.c | 32 +++ arch/arm/mach-owl/sysmap-s900.c| 32 --- board/ucRobotics/bubblegum_96/Kconfig | 15 -- board/ucRobotics/bubblegum_96/MAINTAINERS | 6 - board/ucRobotics/bubblegum_96/Makefile | 3 - board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 - configs/bubblegum_96_defconfig | 12 +- configs/cubieboard7_defconfig | 9 + doc/board/actions/cubieboard7.rst | 115 + doc/board/actions/index.rst| 10 + doc/board/index.rst| 1 + drivers/clk/owl/Kconfig| 8 +- drivers/clk/owl/Makefile | 2 +- drivers/clk/owl/clk_owl.c | 153 drivers/clk/owl/clk_owl.h | 65 + drivers/clk/owl/clk_s900.c | 137 --- drivers/serial/serial_owl.c| 2 +- include/configs/bubblegum_96.h | 40 --- include/configs/owl-common.h | 40 +++ include/configs/s700.h | 13 + include/configs/s900.h | 16 ++ include/dt-bindings/clock/actions,s700-cmu.h | 118 + include/dt-bindings/clock/actions,s900-cmu.h | 129 ++ include/dt-bindings/clock/s900_cmu.h | 77 -- include/dt-bindings/reset/actions,s700-reset.h | 34 +++ include/dt-bindings/reset/actions,s900-reset.h | 65 + 39 files changed, 1638 insertions(+), 486 deletions(-) create mode 100644 arch/arm/dts/s700-cubieboard7.dts create mode 100644 arch/arm/dts/s700-u-boot.dtsi create mode 100644 arch/arm/dts/s700.dtsi create mode 100644 arch/arm/dts/s900-u-boot.dtsi delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h create mode 100644 arch/arm/mach-owl/soc.c create mode 100644 arch/arm/mach-owl/sysmap-owl.c delete mode 100644 arch/arm/mach-owl/sysmap-s900.c delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644 board/ucRobotics/bubblegum_96/Makefile delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c create mode 100644 configs/cubieboard7_defconfig
[PATCH v7 02/12] arm: actions: rename sysmap-s900 to sysmap-owl
Now that memory maps(for both S700 and S900 SoCs) can be managed using
a common file, rename sysmap-s900 to sysmap-owl to reflect the same.
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* No changes.
Changes since v5:
* No changes.
Changes since v4:
* No changes.
Changes since v3:
* Added reviewed-by tag.
Changes since v2:
* Fixed the commit message and header.
Changes since v1:
* compile sysmap-owl.c against CONFIG_ARM64 now.
---
arch/arm/mach-owl/Makefile | 2 +-
arch/arm/mach-owl/sysmap-owl.c | 32
arch/arm/mach-owl/sysmap-s900.c | 32
3 files changed, 33 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/mach-owl/sysmap-owl.c
delete mode 100644 arch/arm/mach-owl/sysmap-s900.c
diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
index 0b181c6..f3a69eb 100644
--- a/arch/arm/mach-owl/Makefile
+++ b/arch/arm/mach-owl/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += soc.o
-obj-y += sysmap-s900.o
+obj-$(CONFIG_ARM64) += sysmap-owl.o
diff --git a/arch/arm/mach-owl/sysmap-owl.c b/arch/arm/mach-owl/sysmap-owl.c
new file mode 100644
index 000..81f6ca2
--- /dev/null
+++ b/arch/arm/mach-owl/sysmap-owl.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Memory map for Actions Semi Owl series SoCs.
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+#include
+#include
+
+static struct mm_region owl_mem_map[] = {
+ {
+ .virt = 0x0UL, /* DDR */
+ .phys = 0x0UL, /* DDR */
+ .size = 0x8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xE000UL, /* Peripheral block */
+ .phys = 0xE000UL, /* Peripheral block */
+ .size = 0x0800UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = owl_mem_map;
diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
deleted file mode 100644
index f78b639..000
--- a/arch/arm/mach-owl/sysmap-s900.c
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Actions Semi S900 Memory map
- *
- * Copyright (C) 2015 Actions Semi Co., Ltd.
- * Copyright (C) 2018 Manivannan Sadhasivam
- */
-
-#include
-#include
-
-static struct mm_region s900_mem_map[] = {
- {
- .virt = 0x0UL, /* DDR */
- .phys = 0x0UL, /* DDR */
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xE000UL, /* Peripheral block */
- .phys = 0xE000UL, /* Peripheral block */
- .size = 0x0800UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- /* List terminator */
- 0,
- }
-};
-
-struct mm_region *mem_map = s900_mem_map;
--
2.7.4
[PATCH v7 03/12] serial: actions: add compatible string
This patch adds "actions,owl-uart" string to the owl uart driver. It
is also defined in Linux kernel.
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* Added Reviewd-by tag.
Changes since v5:
* Moved it to from 06/11 to 03/11.
* Used appropriate commit message.
* Removed the reviwed-by tag.
Changes since v4:
* Moved it to from 09/11 to 06/11.
Changes since v3:
* Used only owl-uart for compatible string.
Changes since v2:
* No changes.
Changes since v1:
* No changes.
---
drivers/serial/serial_owl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
index 7ead73e..539acdc 100644
--- a/drivers/serial/serial_owl.c
+++ b/drivers/serial/serial_owl.c
@@ -121,6 +121,7 @@ static const struct dm_serial_ops owl_serial_ops = {
static const struct udevice_id owl_serial_ids[] = {
{ .compatible = "actions,s900-serial" },
+ { .compatible = "actions,owl-uart" },
{ }
};
--
2.7.4
[PATCH v7 05/12] arm: dts: actions: s900: add u-boot specific dtsi file
Devices like uart and clk are needed to be enabled before relocation.
This patch adds u-boot.dtsi file that mark these device as dm-pre-reloc.
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* No changes.
Changes since v5:
* No changes.
Changes since v4:
* This patch is re-ordered, moved from 08/11 to 04/11.
Changes since v3:
* Replaced dtsi with dts in subject line along with arm:dts:
to the prefix.
* Added reviewed-by tag.
Changes since v2:
* Newly added patch, not there in v2/v1.
---
arch/arm/dts/s900-u-boot.dtsi | 17 +
1 file changed, 17 insertions(+)
create mode 100644 arch/arm/dts/s900-u-boot.dtsi
diff --git a/arch/arm/dts/s900-u-boot.dtsi b/arch/arm/dts/s900-u-boot.dtsi
new file mode 100644
index 000..a95f2cc
--- /dev/null
+++ b/arch/arm/dts/s900-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ */
+
+/{
+ soc {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.7.4
[PATCH v1] x86: acpi: Add I²C timings to Intel Merrifield platform
There is established way to provide I²C timings, or actually counters,
to the OS via ACPI. Fill them for Intel Merrifield platform.
Signed-off-by: Andy Shevchenko
---
.../asm/arch-tangier/acpi/southcluster.asl| 20 +++
1 file changed, 20 insertions(+)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index 95413c1112..aa1793b383 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -250,6 +250,16 @@ Device (PCI0)
Return (STA_VISIBLE)
}
+Name (SSCN, Package ()
+{
+0x02F8, 0x037B, Zero,
+})
+
+Name (FMCN, Package ()
+{
+0x0087, 0x010A, Zero,
+})
+
Name (RBUF, ResourceTemplate()
{
FixedDMA(0x0009, 0x, Width32bit, )
@@ -270,6 +280,16 @@ Device (PCI0)
{
Return (STA_VISIBLE)
}
+
+Name (SSCN, Package ()
+{
+0x02F8, 0x037B, Zero,
+})
+
+Name (FMCN, Package ()
+{
+0x0087, 0x010A, Zero,
+})
}
Device (GPIO)
--
2.25.1
Re: [PATCH] mach-snapdragon: Fix overwriting last digit of serial number
On Mon, Mar 16, 2020 at 05:51:51PM +0100, Jan-Christoph Tebbe wrote: > When generating the MAC address based on the boards serial number > the last digit was overwritten with the null termination. That way > boards with serial numbers close to each other would use the same > MAC address. > > Signed-off-by: Jan-Christoph Tebbe > --- > arch/arm/mach-snapdragon/misc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c > index f6c87866c0..aaa561c2c6 100644 > --- a/arch/arm/mach-snapdragon/misc.c > +++ b/arch/arm/mach-snapdragon/misc.c > @@ -41,7 +41,7 @@ void msm_generate_mac_addr(u8 *mac) > int i; > char sn[9]; > > - snprintf(sn, 8, "%08x", msm_board_serial()); > + snprintf(sn, 9, "%08x", msm_board_serial()); > > /* fill in the mac with serialno, use locally adminstrated pool */ > mac[0] = 0x02; OK, so sn is size 9 and now you're filling the whole thing. Why don't we need to increase sn to size 10? Am I missing something? Thanks! -- Tom signature.asc Description: PGP signature
[PATCH v7 06/12] clk: actions: Add common clock driver
This patch converts S900 clock driver to something common that can
be used for other SoCs, for instance S700(few of clk registers are same).
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* Fixed the bug that breaks S900(missing break in switch statement).
Changes since v5:
* No changes.
Changes since v4:
* This patch is re-ordered, moved from 08/11 to 04/11.
Changes since v3:
* Replaced dtsi with dts in subject line along with arm:dts:
to the prefix.
* Added reviewed-by tag.
Changes since v2:
* Newly added patch, not there in v2/v1.
---
arch/arm/Kconfig | 2 +
arch/arm/include/asm/arch-owl/clk_s900.h | 57 ---
arch/arm/include/asm/arch-owl/regs_s700.h | 56 +++
configs/bubblegum_96_defconfig| 3 -
drivers/clk/owl/Kconfig | 8 +-
drivers/clk/owl/Makefile | 2 +-
drivers/clk/owl/clk_owl.c | 153 ++
drivers/clk/owl/clk_owl.h | 65 +
drivers/clk/owl/clk_s900.c| 137 --
9 files changed, 279 insertions(+), 204 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h
create mode 100644 drivers/clk/owl/clk_owl.c
create mode 100644 drivers/clk/owl/clk_owl.h
delete mode 100644 drivers/clk/owl/clk_s900.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cfdcb6..dba4d8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -876,6 +876,8 @@ config ARCH_OWL
select DM
select DM_SERIAL
select OWL_SERIAL
+ select CLK
+ select CLK_OWL
select OF_CONTROL
imply CMD_DM
diff --git a/arch/arm/include/asm/arch-owl/clk_s900.h
b/arch/arm/include/asm/arch-owl/clk_s900.h
deleted file mode 100644
index 88e88f7..000
--- a/arch/arm/include/asm/arch-owl/clk_s900.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Actions Semi S900 Clock Definitions
- *
- * Copyright (C) 2015 Actions Semi Co., Ltd.
- * Copyright (C) 2018 Manivannan Sadhasivam
- *
- */
-
-#ifndef _OWL_CLK_S900_H_
-#define _OWL_CLK_S900_H_
-
-#include
-
-struct owl_clk_priv {
- phys_addr_t base;
-};
-
-/* BUSCLK register definitions */
-#define CMU_PDBGDIV_8 7
-#define CMU_PDBGDIV_SHIFT 26
-#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
-#define CMU_PERDIV_8 7
-#define CMU_PERDIV_SHIFT 20
-#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
-#define CMU_NOCDIV_2 1
-#define CMU_NOCDIV_SHIFT 19
-#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
-#define CMU_DMMCLK_SRC_APLL2
-#define CMU_DMMCLK_SRC_SHIFT 10
-#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
-#define CMU_APBCLK_DIV BIT(8)
-#define CMU_NOCCLK_SRC BIT(7)
-#define CMU_AHBCLK_DIV BIT(4)
-#define CMU_CORECLK_MASK 3
-#define CMU_CORECLK_CPLL BIT(1)
-#define CMU_CORECLK_HOSC BIT(0)
-
-/* COREPLL register definitions */
-#define CMU_COREPLL_EN BIT(9)
-#define CMU_COREPLL_HOSC_ENBIT(8)
-#define CMU_COREPLL_OUT(1104 / 24)
-
-/* DEVPLL register definitions */
-#define CMU_DEVPLL_CLK BIT(12)
-#define CMU_DEVPLL_EN BIT(8)
-#define CMU_DEVPLL_OUT (660 / 6)
-
-/* UARTCLK register definitions */
-#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
-
-/* DEVCLKEN1 register definitions */
-#define CMU_DEVCLKEN1_UART5BIT(21)
-
-#define PLL_STABILITY_WAIT_US 50
-
-#endif
diff --git a/arch/arm/include/asm/arch-owl/regs_s700.h
b/arch/arm/include/asm/arch-owl/regs_s700.h
new file mode 100644
index 000..2f21c15
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/regs_s700.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S700 Register Definitions
+ *
+ */
+
+#ifndef _OWL_REGS_S700_H_
+#define _OWL_REGS_S700_H_
+
+#define CMU_COREPLL0x
+#define CMU_DEVPLL 0x0004
+#define CMU_DDRPLL 0x0008
+#define CMU_NANDPLL0x000C
+#define CMU_DISPLAYPLL 0x0010
+#define CMU_AUDIOPLL 0x0014
+#define CMU_TVOUTPLL 0x0018
+#define CMU_BUSCLK 0x001C
+#define CMU_SENSORCLK 0x0020
+#define CMU_LCDCLK 0x0024
+#define CMU_DSIPLLCLK 0x0028
+#define CMU_CSICLK 0x002C
+#define CMU_DECLK 0x0030
+#define CMU_SICLK 0x0034
+#define CMU_BUSCLK10x0038
+#define CMU_HDECLK 0x003C
+#define CMU_VDECLK 0x0040
+#define CMU_VCECLK 0x0044
+#define CMU_NANDCCLK 0x004C
+#define CMU_SD0CLK 0x0050
+#define CMU_SD1CLK 0x0054
+#define CMU_SD2CLK 0x0058
+#define CMU_UART0CLK 0x005C
[PATCH v7 09/12] arm: add support Actions Semi S700
This patch adds basic support for Actions Semi based S700 SoC, which is driven by common owl framework. Reviewed-by: Andre Przywara Signed-off-by: Amit Singh Tomar --- Changes since v6: * No changes. Changes since v5: * Added reviewed-by tag. Changes since v4: * Moved it to 09/11 to 04/11. Changes since v3: * Added "SoC" keyword to Actions Semi S700. Changes since v2: * Fixed the commit message. * Checked for the clk->id. * Added a .data member with SoC type. * Removed #ifdefs from few places. Changes since v1: * Moved CLK and CLK_OWL symbols from defconfig to arch/arm/Kconfig. --- arch/arm/mach-owl/Kconfig | 6 ++ include/configs/s700.h| 13 + 2 files changed, 19 insertions(+) create mode 100644 include/configs/s700.h diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig index d0be2b5..1d59d8f 100644 --- a/arch/arm/mach-owl/Kconfig +++ b/arch/arm/mach-owl/Kconfig @@ -8,6 +8,10 @@ config MACH_S900 bool "Actions Semi S900 SoC" select ARM64 +config MACH_S700 +bool "Actions Semi S700 SoC" +select ARM64 + endchoice config SYS_TEXT_BASE @@ -15,8 +19,10 @@ config SYS_TEXT_BASE config SYS_CONFIG_NAME default "s900" if MACH_S900 +default "s700" if MACH_S700 config SYS_SOC default "s900" if MACH_S900 +default "s700" if MACH_S700 endif diff --git a/include/configs/s700.h b/include/configs/s700.h new file mode 100644 index 000..fab0d04 --- /dev/null +++ b/include/configs/s700.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + */ + +#ifndef _CONFIG_S700_H_ +#define _CONFIG_S700_H_ + +/* + * Include common owl configuration where most the settings are + */ +#include + +#endif -- 2.7.4
[PATCH v7 04/12] arm: dts: sync dts for Action Semi S900
Synchronize device tree bindings with v5.5-rc6 tag with commit id
"b3a987b0264d".
Also, it removes older clock binding defined for S900 along with undocumented
compatible string "actions,s900-serial" from serial driver and adapts clock
driver to cater to new bindings.
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v6:
* Added Reviewed-by tag.
Changes since v5:
* Moved it 04/11 from 03/11.
* removed the undocumented compatible string "actions,s900-serial".
* removed the reviewed-by tag.
Changes since v4:
* This patch is re-ordered, moved from 07/11 to 03/11.
* Used the commit-id(12 chars long) in commit message.
Changes since v3:
* Added Reviewed-by: tag.
Changes since v2:
* Newly added patch, not there in v2/v1.
---
arch/arm/dts/s900.dtsi | 322 +++--
drivers/clk/owl/clk_s900.c | 6 +-
drivers/serial/serial_owl.c| 1 -
include/dt-bindings/clock/actions,s900-cmu.h | 129 ++
include/dt-bindings/clock/s900_cmu.h | 77 --
include/dt-bindings/reset/actions,s900-reset.h | 65 +
6 files changed, 498 insertions(+), 102 deletions(-)
create mode 100644 include/dt-bindings/clock/actions,s900-cmu.h
delete mode 100644 include/dt-bindings/clock/s900_cmu.h
create mode 100644 include/dt-bindings/reset/actions,s900-reset.h
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index 2bbb30a..eb35cf7 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -1,17 +1,94 @@
-// SPDX-License-Identifier: GPL-2.0+
-//
-// Device Tree Source for Actions Semi S900 SoC
-//
-// Copyright (C) 2015 Actions Semi Co., Ltd.
-// Copyright (C) 2018 Manivannan Sadhasivam
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
-/dts-v1/;
-#include
+#include
+#include
+#include
+#include
/ {
compatible = "actions,s900";
- #address-cells = <0x2>;
- #size-cells = <0x2>;
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secmon@1f00 {
+ reg = <0x0 0x1f00 0x0 0x100>;
+ no-map;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <>, <>, <>, <>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ hosc: hosc {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
losc: losc {
compatible = "fixed-clock";
@@ -26,28 +103,231 @@
};
soc {
- u-boot,dm-pre-reloc;
compatible = "simple-bus";
- #address-cells = <0x2>;
- #size-cells = <0x2>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
+ gic: interrupt-controller@e00f1000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xe00f1000 0x0 0x1000>,
+ <0x0 0xe00f2000 0x0 0x2000>,
+ <0x0 0xe00f4000 0x0 0x2000>,
+ <0x0 0xe00f6000 0x0 0x2000>;
+ interrupts = ;
+
[PATCH v7 10/12] actions: Move defconfig options to Kconfig
This patch moves some of the config options from bubblegum_96_defconfig to platform specific Kconfig file. Reviewed-by: Andre Przywara Signed-off-by: Amit Singh Tomar --- Changes since v6: * remove unnecessary string from SYS_PROMPT. Changes since v5: * Newly added patch, was not there in earlier versions. --- arch/arm/mach-owl/Kconfig | 15 +++ configs/bubblegum_96_defconfig | 5 - 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig index 1d59d8f..8344081 100644 --- a/arch/arm/mach-owl/Kconfig +++ b/arch/arm/mach-owl/Kconfig @@ -25,4 +25,19 @@ config SYS_SOC default "s900" if MACH_S900 default "s700" if MACH_S700 +config DISTRO_DEFAULTS + default y + +config NR_DRAM_BANKS + default 1 + +config SYS_RELOC_GD_ENV_ADDR + default y + +config SYS_PROMPT + default "U-Boot => " + +config DISPLAY_BOARDINFO + default n + endif diff --git a/configs/bubblegum_96_defconfig b/configs/bubblegum_96_defconfig index e76e9a2..0883167 100644 --- a/configs/bubblegum_96_defconfig +++ b/configs/bubblegum_96_defconfig @@ -1,19 +1,14 @@ CONFIG_ARM=y CONFIG_ARCH_OWL=y CONFIG_ENV_SIZE=0x2000 -CONFIG_NR_DRAM_BANKS=1 CONFIG_MACH_S900=y CONFIG_IDENT_STRING="\nBubblegum-96" -CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=5 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyOWL5,115200n8" # CONFIG_DISPLAY_CPUINFO is not set -# CONFIG_DISPLAY_BOARDINFO is not set -CONFIG_SYS_PROMPT="U-Boot => " CONFIG_CMD_MD5SUM=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIMER=y CONFIG_DEFAULT_DEVICE_TREE="bubblegum_96" -CONFIG_SYS_RELOC_GD_ENV_ADDR=y -- 2.7.4
[PATCH v7 01/12] arm: actions: Add common framework for Actions Owl Semi SoCs
This commit adds common arch support for Actions Semi Owl series SoCs and removes the Bubblegum96 board files. Signed-off-by: Amit Singh Tomar --- Changes since v6: * No change. Changes since v5: * No change. Changes since v4: * No change. Changes since v3: * Corrected the file list entry in MAINTAINERS file. Changes since v2: * Moved the file list details to root MAINTAINERS file. * Updated the commit message as suggested by Mani. * Used the "Owl" keyword to describe SoC family. Changes since v1: * Moved S700 specific changes to patch 4 of 9. * Moved couple of symbols from defconfig to arch/arm/Kconfig and platform owl Kconfig. --- MAINTAINERS | 2 + arch/arm/Kconfig | 3 +- arch/arm/mach-owl/Kconfig| 29 ++ arch/arm/mach-owl/Makefile | 1 + arch/arm/mach-owl/soc.c | 57 board/ucRobotics/bubblegum_96/Kconfig| 15 board/ucRobotics/bubblegum_96/MAINTAINERS| 6 --- board/ucRobotics/bubblegum_96/Makefile | 3 -- board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 configs/bubblegum_96_defconfig | 4 +- include/configs/bubblegum_96.h | 40 --- include/configs/owl-common.h | 40 +++ include/configs/s900.h | 16 13 files changed, 130 insertions(+), 143 deletions(-) create mode 100644 arch/arm/mach-owl/soc.c delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644 board/ucRobotics/bubblegum_96/Makefile delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c delete mode 100644 include/configs/bubblegum_96.h create mode 100644 include/configs/owl-common.h create mode 100644 include/configs/s900.h diff --git a/MAINTAINERS b/MAINTAINERS index 92dda40..e1c03cb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -275,6 +275,8 @@ F: arch/arm/mach-owl/ F: board/ucRobotics/ F: drivers/clk/owl/ F: drivers/serial/serial_owl.c +F: include/configs/owl-common.h +F: configs/bubblegum_96_defconfig ARM RENESAS RMOBILE/R-CAR M: Nobuhiro Iwamatsu diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5d36788..1cfdcb6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -873,9 +873,9 @@ config ARCH_MX5 config ARCH_OWL bool "Actions Semi OWL SoCs" - select ARM64 select DM select DM_SERIAL + select OWL_SERIAL select OF_CONTROL imply CMD_DM @@ -1865,7 +1865,6 @@ source "board/spear/spear600/Kconfig" source "board/spear/x600/Kconfig" source "board/st/stv0991/Kconfig" source "board/tcl/sl50/Kconfig" -source "board/ucRobotics/bubblegum_96/Kconfig" source "board/birdland/bav335x/Kconfig" source "board/toradex/colibri_pxa270/Kconfig" source "board/variscite/dart_6ul/Kconfig" diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig index 199e772..d0be2b5 100644 --- a/arch/arm/mach-owl/Kconfig +++ b/arch/arm/mach-owl/Kconfig @@ -1,27 +1,22 @@ if ARCH_OWL -config SYS_SOC - default "owl" - choice -prompt "Actions Semi OWL SoCs board select" +prompt "Actions Semi Owl SoC Variant" optional -config TARGET_BUBBLEGUM_96 - bool "96Boards Bubblegum-96" - help - Support for 96Boards Bubblegum-96. This board complies with - 96Board Consumer Edition Specification. Features: - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU) - - 2GiB RAM - - 8GiB eMMC, uSD slot - - WiFi, Bluetooth and GPS module - - 2x Host, 1x Device USB port - - HDMI - - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons +config MACH_S900 +bool "Actions Semi S900 SoC" +select ARM64 endchoice -source "board/ucRobotics/bubblegum_96/Kconfig" +config SYS_TEXT_BASE +default 0x1100 + +config SYS_CONFIG_NAME +default "s900" if MACH_S900 + +config SYS_SOC +default "s900" if MACH_S900 endif diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile index 1b43dc2..0b181c6 100644 --- a/arch/arm/mach-owl/Makefile +++ b/arch/arm/mach-owl/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0+ +obj-y += soc.o obj-y += sysmap-s900.o diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c new file mode 100644 index 000..409cbd3 --- /dev/null +++ b/arch/arm/mach-owl/soc.c @@ -0,0 +1,57 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Actions Semi Owl SoCs platform support. + * + * Copyright (C) 2018 Manivannan Sadhasivam + */ + +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +/* + * dram_init - sets uboots idea of
[PATCH v2] x86: acpi: Add I²C timings to Intel Merrifield platform
There is established way to provide I²C timings, or actually counters,
to the OS via ACPI. Fill them for Intel Merrifield platform.
Signed-off-by: Andy Shevchenko
---
v2: added high speed mode counters
.../asm/arch-tangier/acpi/southcluster.asl| 30 +++
1 file changed, 30 insertions(+)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index c622783f44..6ccdc25136 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -240,6 +240,21 @@ Device (PCI0)
Return (STA_VISIBLE)
}
+Name (SSCN, Package ()
+{
+0x02F8, 0x037B, Zero,
+})
+
+Name (FMCN, Package ()
+{
+0x0087, 0x010A, Zero,
+})
+
+Name (HSCN, Package ()
+{
+0x0008, 0x0020, Zero,
+})
+
Name (RBUF, ResourceTemplate()
{
FixedDMA(0x0009, 0x, Width32bit, )
@@ -260,6 +275,21 @@ Device (PCI0)
{
Return (STA_VISIBLE)
}
+
+Name (SSCN, Package ()
+{
+0x02F8, 0x037B, Zero,
+})
+
+Name (FMCN, Package ()
+{
+0x0087, 0x010A, Zero,
+})
+
+Name (HSCN, Package ()
+{
+0x0008, 0x0020, Zero,
+})
}
Device (GPIO)
--
2.25.1
[PATCH 2/2] efi_selftest: check length report by GetNextVariableName()
GetNextVariableName should report the length of the variable including the
final 0x in bytes.
Check this in the unit test.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_variables.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_variables.c
b/lib/efi_selftest/efi_selftest_variables.c
index 5d98c029b8..b7ead340f5 100644
--- a/lib/efi_selftest/efi_selftest_variables.c
+++ b/lib/efi_selftest/efi_selftest_variables.c
@@ -155,8 +155,14 @@ static int execute(void)
return EFI_ST_FAILURE;
}
if (!memcmp(, _vendor0, sizeof(efi_guid_t)) &&
- !efi_st_strcmp_16_8(varname, "efi_st_var0"))
+ !efi_st_strcmp_16_8(varname, "efi_st_var0")) {
flag |= 1;
+ if (len != 24) {
+ efi_st_error("GetNextVariableName report wrong
length %u, expected 24\n",
+(unsigned int)len);
+ return EFI_ST_FAILURE;
+ }
+ }
if (!memcmp(, _vendor1, sizeof(efi_guid_t)) &&
!efi_st_strcmp_16_8(varname, "efi_st_var1"))
flag |= 2;
--
2.25.1
[PATCH 0/2] efi_loader: correct reported length in GetNextVariable()
The runtime service GetNextVariable() returns the length of the next variable including the closing 0x. This length should be in bytes. Comparing the output of EDK2 and U-Boot shows that this is currently not correctly implemented: EDK2: OsIndicationsSupported: 46 PlatformLang: 26 PlatformLangCodes: 36 U-Boot: OsIndicationsSupported: 23 PlatformLang: 13 PlatformLangCodes: 18 Provide correct length in GetNextVariable(). Provide a unit test. Heinrich Schuchardt (2): efi_loader: correct reported length in GetNextVariable() efi_selftest: check length report by GetNextVariableName() lib/efi_loader/efi_variable.c | 2 +- lib/efi_selftest/efi_selftest_variables.c | 8 +++- 2 files changed, 8 insertions(+), 2 deletions(-) -- 2.25.1
Re: ext4: invalid extent block on imx7
On Mon, Mar 16, 2020 at 08:09:53PM +0100, Jan Kiszka wrote: > Hi all, > > => ls mmc 0:1 /usr/lib/linux-image-4.9.11-1.3.0-dirty > CACHE: Misaligned operation at range [bdfff998, bdfffd98] > CACHE: Misaligned operation at range [bdfff998, bdfffd98] > CACHE: Misaligned operation at range [bdfff998, bdfffd98] > CACHE: Misaligned operation at range [bdfff998, bdfffd98] > invalid extent block > > I'm using master (50be9f0e1ccc) on the MCIMX7SABRE, defconfig. > > What could this be? The filesystem is fine from Linux POV. Use tune2fs -l and see if there's any new'ish features enabled that we need some sort of check-and-reject for would be my first guess. -- Tom signature.asc Description: PGP signature
Re: Switching among serial consoles
On Wed, Mar 18, 2020 at 09:48:36AM +0100, Michal Simek wrote: > Hi, > > long time ago I was playing with switching among consoles. > I have two IPs with the same driver where main console is probed and > used which is visible via dm tree. > > serial1 [ + ] serial_zynq | |-- serial@ff00 > serial2 [ ] serial_zynq | |-- serial@ff01 > > then I have also dcc which can be also used as a console > > serial0 [ ] arm_dcc |-- dcc > > Lastly I have enabled netconsole feature. > > I have no problem to switch between serial@ff00 and nc but I can't > switch it to dcc or second instance. > > dhcp > setenv ncip 192.168.0.105 > setenv nc 'setenv stdout nc;setenv stdin nc' > setenv dcc 'setenv stdout dcc;setenv stdin dcc' > setenv serial0 'setenv stdout serial@ff00;setenv stdin serial@ff00' > setenv serial1 'setenv stdout serial@ff01;setenv stdin serial@ff01' > run nc > > and then via netconsole > > run serial0 > > works to get back. > > > Console info is showing only available and registered instances. > > ZynqMP> con > List of available devices: > serial@ff00 0007 IO > serial 0003 IO stdin stdout stderr > nulldev 0003 IO > nc 0003 IO > > It means the question is how to probe second instance of serial_zynq > serial@ff01 and dcc. I expect when probe is done it will show up in > console list and switch is possible. > > I found SERIAL_SEARCH_ALL symbol but it is just search not probe. > > I am quite sure that it was working in past but not sure if this was > before DM but I would like to know how you are doing it/testing it today. I think the answer is we don't have any tests for multiple consoles to start with, so it's not tested. I'd start by grabbing an old platform and bisect'ing back the years to see when it did last work as the first thing. Sorry! -- Tom signature.asc Description: PGP signature
[PATCH 1/2] efi_loader: correct reported length in GetNextVariable()
The runtime service GetNextVariable() returns the length of the next
variable including the closing 0x. This length should be in bytes.
Comparing the output of EDK2 and U-Boot shows that this is currently not
correctly implemented:
EDK2:
OsIndicationsSupported: 46
PlatformLang: 26
PlatformLangCodes: 36
U-Boot:
OsIndicationsSupported: 23
PlatformLang: 13
PlatformLangCodes: 18
Provide correct length in GetNextVariable().
Fixes: d99a87f84b75 ("efi_loader: implement GetNextVariableName()")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index c316bdfec0..04ead34c6f 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -299,7 +299,7 @@ static efi_status_t parse_uboot_variable(char *variable,
p = variable_name;
utf8_utf16_strncpy(, name, name_len);
variable_name[name_len] = 0;
- *variable_name_size = name_len + 1;
+ *variable_name_size = sizeof(u16) * (name_len + 1);
/* guid */
c = *(name - 1);
--
2.25.1
Re: [PATCH] dlmalloc: Add an option to default malloc to init
On Wed, Mar 18, 2020 at 01:14:43PM +0100, marek.bykow...@gmail.com wrote:
> From: Marek Bykowski
>
> If a system wants the malloc to get moved around from one to another
> memory range it should call mem_malloc_init() with the updated memory
> ranges. However setting aside the new memory alone isn't enough.
> It should also bring the bins and static bookkeeping data to init.
>
> One of the use cases could be SPL U-Boot that allocates first to
> the (limited) static memory and then when needs more memory, and
> the DDR memory becomes available, moves the pools around.
>
> Note that defaulting the malloc to init discards all the memory
> previously allocated.
>
> Signed-off-by: Marek Bykowski
> ---
> Kconfig | 14 ++
> common/dlmalloc.c | 41 ++---
> 2 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/Kconfig b/Kconfig
> index 1f0904f704..958553c90a 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -209,6 +209,20 @@ if EXPERT
> When disabling this, please check if malloc calls, maybe
> should be replaced by calloc - if one expects zeroed memory.
>
> +config SYS_MALLOC_DEFAULT_TO_INIT
> + bool "Default malloc to init while reserving the memory for it"
> + default n
> + help
> + It may happen that one needs to move the dynamic allocation
> + from one to another memory range, eg. when moving the malloc
> + from the limited static to a potentially large dynamic (DDR)
> + memory.
> +
> + If so then on top of setting the updated memory aside one
> + needs to bring the malloc init.
> +
> + If such a scenario is sought choose yes.
> +
> config TOOLS_DEBUG
> bool "Enable debug information for tools"
> help
> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
> index 6f12a18d54..8b2796e280 100644
> --- a/common/dlmalloc.c
> +++ b/common/dlmalloc.c
> @@ -280,6 +280,7 @@ nextchunk->
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Unused space (may be 0 bytes long).
> . .
> . |
> +
> nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> `foot:' | Size of chunk, in bytes |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> @@ -574,6 +575,10 @@ static void malloc_bin_reloc(void)
> static inline void malloc_bin_reloc(void) {}
> #endif
>
> +#ifdef CONFIG_SYS_MALLOC_DEFAULT_TO_INIT
> +static void malloc_init(void);
> +#endif
> +
> ulong mem_malloc_start = 0;
> ulong mem_malloc_end = 0;
> ulong mem_malloc_brk = 0;
> @@ -604,6 +609,10 @@ void mem_malloc_init(ulong start, ulong size)
> mem_malloc_end = start + size;
> mem_malloc_brk = start;
>
> +#ifdef CONFIG_SYS_MALLOC_DEFAULT_TO_INIT
> + malloc_init();
> +#endif
> +
> debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
> mem_malloc_end);
> #ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
> @@ -708,7 +717,36 @@ static unsigned int max_n_mmaps = 0;
> static unsigned long max_mmapped_mem = 0;
> #endif
>
> +#ifdef CONFIG_SYS_MALLOC_DEFAULT_TO_INIT
> +static void malloc_init(void)
> +{
> + int i, j;
> +
> + debug("bins (av_ array) are at %p\n", (void *)av_);
> +
> + av_[0] = NULL; av_[1] = NULL;
> + for (i = 2, j = 2; i < NAV * 2 + 2; i += 2, j++) {
> + av_[i] = bin_at(j - 2);
> + av_[i + 1] = bin_at(j - 2);
> +
> + /* Just print the first few bins so that
> + * we can see there are alright.
> + */
> + if (i < 10)
> + debug("av_[%d]=%lx av_[%d]=%lx\n",
> + i, (ulong)av_[i],
> + i + 1, (ulong)av_[i + 1]);
> + }
>
> + /* Init the static bookkeeping as well */
> + sbrk_base = (char *)(-1);
> + max_sbrked_mem = 0;
> + max_total_mem = 0;
> +#ifdef DEBUG
> + memset((void *)_mallinfo, 0, sizeof(struct mallinfo));
> +#endif
> +}
> +#endif
>
> /*
>Debugging support
Can you please showcase using this feature somewhere? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] sunxi: Add Inet 86V Rev 2 support
On Mon, Feb 10, 2020 at 4:05 PM wrote:
>
> From: Alexandre GRIVEAUX
>
> Add Inet 86V Rev 2 support, based upon Inet 86VS.
>
> Missing things:
> - Accelerometer (MXC6225X)
> - Touchpanel (Sitronix SL1536)
> - Nand (29F32G08CBACA)
> - Camera (HCWY0308)
>
> Signed-off-by: Alexandre GRIVEAUX
> ---
> arch/arm/dts/Makefile| 3 ++-
> arch/arm/dts/sun5i-a13-inet-86v-rev2.dts | 17 +++
Is it is copy from Linux, if yes please specific sha1?
> configs/inet86v_rev2_defconfig | 27
> 3 files changed, 46 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/sun5i-a13-inet-86v-rev2.dts
> create mode 100644 configs/inet86v_rev2_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 6915783d9c..7a0f1c0484 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -444,7 +444,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a13-q8-tablet.dtb \
> sun5i-a13-utoo-p66.dtb \
> sun5i-gr8-chip-pro.dtb \
> - sun5i-r8-chip.dtb
> + sun5i-r8-chip.dtb \
> + sun5i-a13-inet-86v-rev2.dtb
> dtb-$(CONFIG_MACH_SUN6I) += \
> sun6i-a31-app4-evb1.dtb \
> sun6i-a31-colombus.dtb \
> diff --git a/arch/arm/dts/sun5i-a13-inet-86v-rev2.dts
> b/arch/arm/dts/sun5i-a13-inet-86v-rev2.dts
> new file mode 100644
> index 00..9b4c5349f0
> --- /dev/null
> +++ b/arch/arm/dts/sun5i-a13-inet-86v-rev2.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 Alexandre Griveaux
> + *
> + * Minimal dts file for the iNet 86V
> + */
> +
> +/dts-v1/;
> +
> +#include "sun5i-a13.dtsi"
> +#include "sun5i-reference-design-tablet.dtsi"
> +
> +/ {
> + model = "iNET 86V Rev 02";
> + compatible = "primux,inet86v-rev2", "allwinner,sun5i-a13";
> +
> +};
> diff --git a/configs/inet86v_rev2_defconfig b/configs/inet86v_rev2_defconfig
> new file mode 100644
> index 00..f8dbd14c0b
> --- /dev/null
> +++ b/configs/inet86v_rev2_defconfig
> @@ -0,0 +1,27 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_MACH_SUN5I=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL=y
> +# CONFIG_MACH_SUN5I=y
> +CONFIG_DRAM_CLK=432
> +CONFIG_MMC0_CD_PIN="PG0"
> +CONFIG_USB0_VBUS_PIN="PG12"
> +CONFIG_USB0_VBUS_DET="PG1"
> +CONFIG_USB0_ID_DET="PG2"
> +CONFIG_AXP_GPIO=y
> +# CONFIG_VIDEO_HDMI is not set
> +CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:45,ri:209,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0"
> +CONFIG_VIDEO_LCD_POWER="AXP0-0"
> +CONFIG_VIDEO_LCD_BL_EN="AXP0-1"
> +CONFIG_VIDEO_LCD_BL_PWM="PB2"
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_USE_PREBOOT=y
> +CONFIG_SPL_I2C_SUPPORT=y
> +# CONFIG_SPL_DOS_PARTITION is not set
> +# CONFIG_SPL_EFI_PARTITION is not set
> +CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-inet-86v-rev2"
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_CONS_INDEX=2
> +CONFIG_USB_MUSB_HOST=y
> +CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
few of the configs now supported via kconfig, so please rebase
u-boot-sunxi/master
Jagan.
[PATCH 1/1] arm: mvebu: dts: Sort Armada series dts alphabetically
From: Josip Kelečić Sort the Armada series dts in the Makefile alphabetically prior to adding new board support. Signed-off-by: Josip Kelečić Reviewed-by: Luka Kovacic Cc: Luka Perkov --- arch/arm/dts/Makefile | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 9c593b2c98..2c269d63a5 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -188,25 +188,25 @@ dtb-$(CONFIG_ARCH_MVEBU) += \ armada-3720-turris-mox.dtb \ armada-3720-uDPU.dtb\ armada-375-db.dtb \ + armada-385-atl-x530.dtb \ + armada-385-atl-x530DP.dtb \ + armada-385-db-88f6820-amc.dtb \ + armada-385-turris-omnia.dtb \ armada-388-clearfog.dtb \ armada-388-gp.dtb \ armada-388-helios4.dtb \ - armada-385-db-88f6820-amc.dtb \ - armada-385-turris-omnia.dtb \ - armada-7040-db.dtb \ + armada-38x-controlcenterdc.dtb \ armada-7040-db-nand.dtb \ + armada-7040-db.dtb \ + armada-8040-clearfog-gt-8k.dtb \ armada-8040-db.dtb \ armada-8040-mcbin.dtb \ - armada-8040-clearfog-gt-8k.dtb \ + armada-xp-crs305-1g-4s.dtb \ + armada-xp-db-xc3-24g4xg.dtb \ armada-xp-gp.dtb\ armada-xp-maxbcm.dtb\ armada-xp-synology-ds414.dtb\ - armada-xp-theadorable.dtb \ - armada-38x-controlcenterdc.dtb \ - armada-385-atl-x530.dtb \ - armada-385-atl-x530DP.dtb \ - armada-xp-db-xc3-24g4xg.dtb \ - armada-xp-crs305-1g-4s.dtb + armada-xp-theadorable.dtb dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \ uniphier-ld11-global.dtb \ -- 2.20.1
[PATCH] mtd: spi: Add Macronix MX25U3235F device
From: Tom Warren
Add Macronix MX25U3235F flash device description.
This is the 4MB part used on Jetson Nano.
Signed-off-by: Tom Warren
---
drivers/mtd/spi/spi-nor-ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 973b6f8..abdf560 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -147,6 +147,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, SECT_4K) },
{ INFO("mx25u2033e", 0xc22532, 0, 64 * 1024, 4, SECT_4K) },
{ INFO("mx25u1635e", 0xc22535, 0, 64 * 1024, 32, SECT_4K) },
+ { INFO("mx25u3235f", 0xc22536, 0, 4 * 1024, 1024, SECT_4K) },
{ INFO("mx25u6435f", 0xc22537, 0, 64 * 1024, 128, SECT_4K) },
{ INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0) },
{ INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0) },
--
1.8.2.1.610.g562af5b
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
[PATCH] qspi: t210: Use dev_read calls for FDT data like base, freq
From: Tom Warren
This Tegra QSPI driver hadn't been brought up to date with how
DM drivers are fetching data from the FDT now, and was pulling
in bogus data for base, max freq, etc. Fixed ofdata_to_platdata
to work the same way it does in the tegra114 SPI driver, using
dev_read_ functions.
Signed-off-by: Tom Warren
---
drivers/spi/tegra210_qspi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/tegra210_qspi.c b/drivers/spi/tegra210_qspi.c
index 4284ea9..466d572 100644
--- a/drivers/spi/tegra210_qspi.c
+++ b/drivers/spi/tegra210_qspi.c
@@ -2,7 +2,7 @@
/*
* NVIDIA Tegra210 QSPI controller driver
*
- * (C) Copyright 2015-2019 NVIDIA Corporation
+ * (C) Copyright 2015-2020 NVIDIA Corporation
*
*/
@@ -97,10 +97,8 @@ struct tegra210_qspi_priv {
static int tegra210_qspi_ofdata_to_platdata(struct udevice *bus)
{
struct tegra_spi_platdata *plat = bus->platdata;
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(bus);
- plat->base = devfdt_get_addr(bus);
+ plat->base = dev_read_addr(bus);
plat->periph_id = clock_decode_periph_id(bus);
if (plat->periph_id == PERIPH_ID_NONE) {
@@ -110,9 +108,9 @@ static int tegra210_qspi_ofdata_to_platdata(struct udevice
*bus)
}
/* Use 500KHz as a suitable default */
- plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
+ plat->frequency = dev_read_u32_default(bus, "spi-max-frequency",
50);
- plat->deactivate_delay_us = fdtdec_get_int(blob, node,
+ plat->deactivate_delay_us = dev_read_u32_default(bus,
"spi-deactivate-delay", 0);
debug("%s: base=%#08lx, periph_id=%d, max-frequency=%d,
deactivate_delay=%d\n",
__func__, plat->base, plat->periph_id, plat->frequency,
--
1.8.2.1.610.g562af5b
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
Re: [PATCH v6 01/12] arm: actions: Add common framework for Actions Owl Semi SoCs
On 18/03/2020 18:25, Amit Singh Tomar wrote: Hi, > This commit adds common arch support for Actions Semi Owl > series SoCs and removes the Bubblegum96 board files. > > Signed-off-by: Amit Singh Tomar > --- > Chanes since v5: > * No change. > Chanes since v4: > * No change. > Changes since v3: > * Corrected the file list entry in MAINTAINERS file. > Changes since v2: > * Moved the file list details to root MAINTAINERS file. > * Updated the commit message as suggested by Mani. > * Used the "Owl" keyword to describe SoC family. > Changes since v1: > * Moved S700 specific changes to patch 4 of 9. > * Moved couple of symbols from defconfig to arch/arm/Kconfig > and platform owl Kconfig. > --- > MAINTAINERS | 2 + > arch/arm/Kconfig | 3 +- > arch/arm/mach-owl/Kconfig| 29 ++ > arch/arm/mach-owl/Makefile | 1 + > arch/arm/mach-owl/soc.c | 57 > > board/ucRobotics/bubblegum_96/Kconfig| 15 > board/ucRobotics/bubblegum_96/MAINTAINERS| 6 --- > board/ucRobotics/bubblegum_96/Makefile | 3 -- > board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 > > configs/bubblegum_96_defconfig | 4 +- > include/configs/bubblegum_96.h | 40 --- > include/configs/owl-common.h | 40 +++ > include/configs/s900.h | 16 > 13 files changed, 130 insertions(+), 143 deletions(-) > create mode 100644 arch/arm/mach-owl/soc.c > delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig > delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS > delete mode 100644 board/ucRobotics/bubblegum_96/Makefile > delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c > delete mode 100644 include/configs/bubblegum_96.h > create mode 100644 include/configs/owl-common.h > create mode 100644 include/configs/s900.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 92dda40..e1c03cb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -275,6 +275,8 @@ F:arch/arm/mach-owl/ > F: board/ucRobotics/ This directory no longer exists after this patch. Please remove it from here as well. > F: drivers/clk/owl/ > F: drivers/serial/serial_owl.c > +F: include/configs/owl-common.h > +F: configs/bubblegum_96_defconfig > > ARM RENESAS RMOBILE/R-CAR > M: Nobuhiro Iwamatsu > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 5d36788..1cfdcb6 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -873,9 +873,9 @@ config ARCH_MX5 > > config ARCH_OWL > bool "Actions Semi OWL SoCs" > - select ARM64 > select DM > select DM_SERIAL > + select OWL_SERIAL > select OF_CONTROL > imply CMD_DM > > @@ -1865,7 +1865,6 @@ source "board/spear/spear600/Kconfig" > source "board/spear/x600/Kconfig" > source "board/st/stv0991/Kconfig" > source "board/tcl/sl50/Kconfig" > -source "board/ucRobotics/bubblegum_96/Kconfig" > source "board/birdland/bav335x/Kconfig" > source "board/toradex/colibri_pxa270/Kconfig" > source "board/variscite/dart_6ul/Kconfig" > diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig > index 199e772..d0be2b5 100644 > --- a/arch/arm/mach-owl/Kconfig > +++ b/arch/arm/mach-owl/Kconfig > @@ -1,27 +1,22 @@ > if ARCH_OWL > > -config SYS_SOC > - default "owl" > - > choice > -prompt "Actions Semi OWL SoCs board select" > +prompt "Actions Semi Owl SoC Variant" > optional > > -config TARGET_BUBBLEGUM_96 > - bool "96Boards Bubblegum-96" > - help > - Support for 96Boards Bubblegum-96. This board complies with > - 96Board Consumer Edition Specification. Features: > - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU) > - - 2GiB RAM > - - 8GiB eMMC, uSD slot > - - WiFi, Bluetooth and GPS module > - - 2x Host, 1x Device USB port > - - HDMI > - - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons > +config MACH_S900 > +bool "Actions Semi S900 SoC" > +select ARM64 > > endchoice > > -source "board/ucRobotics/bubblegum_96/Kconfig" > +config SYS_TEXT_BASE > +default 0x1100 > + > +config SYS_CONFIG_NAME > +default "s900" if MACH_S900 I don't see a reason for a SoC specific include file here, as both this s900.h and the future s700.h are basically empty. It seems much easier to just always default to "owl-common" here and remove s900.h altogether. That also avoids adding the s700.h file later on. Cheers, Andre > + > +config SYS_SOC > +default "s900" if MACH_S900 > > endif > diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile > index 1b43dc2..0b181c6 100644 > ---
