[PATCH v4 3/3] test/dm: fdtdec: Add tests for fdtdec_add_reserved_memory()
From: Bin Meng
This adds a test case to test the functionality of the fdtdec API
fdtdec_add_reserved_memory().
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
(no changes since v3)
Changes in v3:
- correct typo in the comments, and some minor rewording
test/dm/fdtdec.c | 69
1 file changed, 69 insertions(+)
diff --git a/test/dm/fdtdec.c b/test/dm/fdtdec.c
index 999d712..56f6f4f 100644
--- a/test/dm/fdtdec.c
+++ b/test/dm/fdtdec.c
@@ -59,3 +59,72 @@ static int dm_test_fdtdec_set_carveout(struct
unit_test_state *uts)
}
DM_TEST(dm_test_fdtdec_set_carveout,
DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT | DM_TESTF_FLAT_TREE);
+
+static int dm_test_fdtdec_add_reserved_memory(struct unit_test_state *uts)
+{
+ struct fdt_memory resv;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ void *blob;
+ int blob_sz, parent, subnode;
+ uint32_t phandle, phandle1;
+
+ blob_sz = fdt_totalsize(gd->fdt_blob) + 128;
+ blob = malloc(blob_sz);
+ ut_assertnonnull(blob);
+
+ /* Make a writable copy of the fdt blob */
+ ut_assertok(fdt_open_into(gd->fdt_blob, blob, blob_sz));
+
+ /* Insert a memory region in /reserved-memory node */
+ resv.start = 0x1000;
+ resv.end = 0x1fff;
+ ut_assertok(fdtdec_add_reserved_memory(blob, "rsvd_region",
+ , ));
+
+ /* Test /reserve-memory and its subnode should exist */
+ parent = fdt_path_offset(blob, "/reserved-memory");
+ ut_assert(parent > 0);
+ subnode = fdt_path_offset(blob, "/reserved-memory/rsvd_region");
+ ut_assert(subnode > 0);
+
+ /* Test reg property of /reserved-memory/rsvd_region node */
+ addr = fdtdec_get_addr_size_auto_parent(blob, parent, subnode,
+ "reg", 0, , false);
+ ut_assert(addr == resv.start);
+ ut_assert(size == resv.end - resv.start + 1);
+
+ /* Insert another memory region in /reserved-memory node */
+ subnode = fdt_path_offset(blob, "/reserved-memory/rsvd_region1");
+ ut_assert(subnode < 0);
+
+ resv.start = 0x2000;
+ resv.end = 0x2fff;
+ ut_assertok(fdtdec_add_reserved_memory(blob, "rsvd_region1",
+ , ));
+ subnode = fdt_path_offset(blob, "/reserved-memory/rsvd_region1");
+ ut_assert(subnode > 0);
+
+ /* phandles must be different */
+ ut_assert(phandle != phandle1);
+
+ /*
+* Insert a 3rd memory region with the same addr/size as the 1st one,
+* but a new node should not be inserted due to the same addr/size.
+*/
+ resv.start = 0x1000;
+ resv.end = 0x1fff;
+ ut_assertok(fdtdec_add_reserved_memory(blob, "rsvd_region2",
+ , ));
+ subnode = fdt_path_offset(blob, "/reserved-memory/rsvd_region2");
+ ut_assert(subnode < 0);
+
+ /* phandle must be same as the 1st one */
+ ut_assert(phandle == phandle1);
+
+ free(blob);
+
+ return 0;
+}
+DM_TEST(dm_test_fdtdec_add_reserved_memory,
+ DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT | DM_TESTF_FLAT_TREE);
--
2.7.4
[PATCH v4 1/3] test/dm: fdtdec: Add the missing gd declaration
From: Bin Meng
Add DECLARE_GLOBAL_DATA_PTR since it is referenced in the test codes.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v4:
- drop the first 2 patches that are already applied
- rebase against u-boot/next branch
test/dm/fdtdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/test/dm/fdtdec.c b/test/dm/fdtdec.c
index b2f75b5..c2f7b94 100644
--- a/test/dm/fdtdec.c
+++ b/test/dm/fdtdec.c
@@ -9,6 +9,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
static int dm_test_fdtdec_set_carveout(struct unit_test_state *uts)
{
struct fdt_memory resv;
--
2.7.4
[PATCH v4 2/3] test/dm: fdtdec: Corect a typo in dm_test_fdtdec_set_carveout()
From: Bin Meng It should be "writable". Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- (no changes since v1) test/dm/fdtdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/dm/fdtdec.c b/test/dm/fdtdec.c index c2f7b94..999d712 100644 --- a/test/dm/fdtdec.c +++ b/test/dm/fdtdec.c @@ -22,7 +22,7 @@ static int dm_test_fdtdec_set_carveout(struct unit_test_state *uts) blob = malloc(blob_sz); ut_assertnonnull(blob); - /* Make a writtable copy of the fdt blob */ + /* Make a writable copy of the fdt blob */ ut_assertok(fdt_open_into(gd->fdt_blob, blob, blob_sz)); resv.start = 0x1000; -- 2.7.4
[PATCH 4/5] riscv: qemu: Add syscon reboot and poweroff support
From: Bin Meng This adds syscon reboot and poweroff support to QEMU RISC-V. Signed-off-by: Bin Meng --- board/emulation/qemu-riscv/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index ad99b08..617c4aa 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -53,5 +53,9 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply NVME imply SPL_RAM_SUPPORT imply SPL_RAM_DEVICE + imply SYSRESET + imply SYSRESET_SYSCON + imply CMD_POWEROFF + imply SYSRESET_CMD_POWEROFF endif -- 2.7.4
[PATCH 5/5] riscv: sifive: fu540: Add gpio-restart support
From: Bin Meng The HiFive Unleashed board wires GPIO pin#10 to the input of the system reset signal. This adds gpio reboot support. Signed-off-by: Bin Meng --- board/sifive/fu540/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index 86193d7..6f65681 100644 --- a/board/sifive/fu540/Kconfig +++ b/board/sifive/fu540/Kconfig @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply SMP imply MISC imply SIFIVE_OTP + imply SYSRESET + imply SYSRESET_GPIO endif -- 2.7.4
[PATCH 2/5] sysreset: syscon: Support value property
From: Bin Meng
Per the DT binding, and property can have either one
or both, and if is missing, should be used, which is
what current U-Boot sysreset_syscon driver supports.
This adds support to the property to the driver, and
semantics is updated to really be a mask to the value if both exist.
Signed-off-by: Bin Meng
---
drivers/sysreset/sysreset_syscon.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/sysreset/sysreset_syscon.c
b/drivers/sysreset/sysreset_syscon.c
index caf2482..1c47486 100644
--- a/drivers/sysreset/sysreset_syscon.c
+++ b/drivers/sysreset/sysreset_syscon.c
@@ -19,6 +19,7 @@ struct syscon_reboot_priv {
struct regmap *regmap;
unsigned int offset;
unsigned int mask;
+ unsigned int value;
};
static int syscon_reboot_request(struct udevice *dev, enum sysreset_t type)
@@ -29,7 +30,7 @@ static int syscon_reboot_request(struct udevice *dev, enum
sysreset_t type)
if (type != driver_data)
return -EPROTONOSUPPORT;
- regmap_write(priv->regmap, priv->offset, priv->mask);
+ regmap_update_bits(priv->regmap, priv->offset, priv->mask, priv->value);
return -EINPROGRESS;
}
@@ -42,6 +43,7 @@ int syscon_reboot_probe(struct udevice *dev)
{
struct syscon_reboot_priv *priv = dev_get_priv(dev);
int err;
+ int mask_err, value_err;
priv->regmap = syscon_regmap_lookup_by_phandle(dev, "regmap");
if (IS_ERR(priv->regmap)) {
@@ -55,10 +57,20 @@ int syscon_reboot_probe(struct udevice *dev)
return -ENOENT;
}
- err = dev_read_u32(dev, "mask", >mask);
- if (err) {
- pr_err("unable to find mask\n");
- return -ENOENT;
+ mask_err = dev_read_u32(dev, "mask", >mask);
+ value_err = dev_read_u32(dev, "value", >value);
+ if (mask_err && value_err) {
+ pr_err("unable to find mask and value\n");
+ return -EINVAL;
+ }
+
+ if (value_err) {
+ /* support old binding */
+ priv->value = priv->mask;
+ priv->mask = 0x;
+ } else if (mask_err) {
+ /* support value without mask*/
+ priv->mask = 0x;
}
return 0;
--
2.7.4
[PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on
From: Bin Meng SYSRESET uclass driver already provides all the reset APIs, hence exclude our own ad-hoc reset.c implementation. Signed-off-by: Bin Meng --- arch/riscv/lib/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index b5e9324..6c503ff 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -20,7 +20,9 @@ obj-$(CONFIG_SBI) += sbi.o obj-$(CONFIG_SBI_IPI) += sbi_ipi.o endif obj-y += interrupts.o +ifeq ($(CONFIG_$(SPL_)SYSRESET),) obj-y += reset.o +endif obj-y += setjmp.o obj-$(CONFIG_$(SPL_)SMP) += smp.o obj-$(CONFIG_SPL_BUILD)+= spl.o -- 2.7.4
[PATCH 1/5] sysreset: syscon: Don't assume default value for offset and mask property
From: Bin Meng
Per the DT binding, is a required property. Let's abort
the probe if it is missing. For the property, current codes
assume a default value of zero, which is not correct either.
Signed-off-by: Bin Meng
---
drivers/sysreset/sysreset_syscon.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/sysreset/sysreset_syscon.c
b/drivers/sysreset/sysreset_syscon.c
index f64701a..caf2482 100644
--- a/drivers/sysreset/sysreset_syscon.c
+++ b/drivers/sysreset/sysreset_syscon.c
@@ -41,6 +41,7 @@ static struct sysreset_ops syscon_reboot_ops = {
int syscon_reboot_probe(struct udevice *dev)
{
struct syscon_reboot_priv *priv = dev_get_priv(dev);
+ int err;
priv->regmap = syscon_regmap_lookup_by_phandle(dev, "regmap");
if (IS_ERR(priv->regmap)) {
@@ -48,8 +49,17 @@ int syscon_reboot_probe(struct udevice *dev)
return -ENODEV;
}
- priv->offset = dev_read_u32_default(dev, "offset", 0);
- priv->mask = dev_read_u32_default(dev, "mask", 0);
+ err = dev_read_u32(dev, "offset", >offset);
+ if (err) {
+ pr_err("unable to find offset\n");
+ return -ENOENT;
+ }
+
+ err = dev_read_u32(dev, "mask", >mask);
+ if (err) {
+ pr_err("unable to find mask\n");
+ return -ENOENT;
+ }
return 0;
}
--
2.7.4
Re: [U-Boot] Pull request: u-boot-riscv/master
Hi Tom, > On Mon, Jun 22, 2020 at 02:03:52PM +0800, Rick Chen wrote: > > Hi Tom > > > > > From: Tom Rini [mailto:tr...@konsulko.com] > > > Sent: Monday, May 25, 2020 11:40 PM > > > To: Open Source Project uboot > > > Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) > > > Subject: Re: [U-Boot] Pull request: u-boot-riscv/master > > > > > > On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote: > > > > > > > Hi Tom, > > > > > > > > Please pull some riscv updates: > > > > > > > > - Add Sipeed Maix support. > > > > - sifive: fix palmer's email address. > > > > - Move all SMP related SBI calls to SBI_v01. > > > > > > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926 > > > > > > > > Thanks > > > > Rick > > > > > > > > > > > > The following changes since commit > > > > 9c5fef577494769e3ff07952a85f9b7125ef765b: > > > > > > > > Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400) > > > > > > > > are available in the Git repository at: > > > > > > > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > > > > > > > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607: > > > > > > > > riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800) > > > > > > > > > > There's too many generic changes in this PR for this late in the cycle, > > > for things I gather related to the Maix platform. All of the clk and DM > > > changes impact virtually all platforms. Please re-do this PR to drop the > > > Maix platform support for now, and resubmit that for -next, which I will > > > be opening shortly. Everything else however is good for master. > > > > May I ask for your suggestions about this patch series about "riscv: > > Add Sipeed Maix support " ? > > Shall I send a PR include this patch series in early release cycle or > > shall I suggest Sean to re-edit this patch series for less generic > > changes which may bring virtual impacts? > > So I looked over the generic changes again. There's no other way to > support the platform without those type of changes, yes? Yes. Discusstion between Sean and Lukasz about clk as below: https://patchwork.ozlabs.org/project/uboot/patch/da401261-b73f-afae-0702-ada1e7dd8...@gmail.com/#2346363 If so, yes, > lets put it in to -next. Thanks for your reply. Rick > > -- > Tom
[ANN] U-Boot v2020.07-rc5 released
Hey all, It's release day and I've tagged v2020.07-rc5. There's been a few assorted bug fixes to come in, and -next is open. As far as I know, there's only some i.MX regression fixes to come in to fix ethernet in a few cases. Once again, for a changelog, git log --merges v2020.07-rc4..v2020.07-rc5 and as always, I ask for more details in the PRs people send me so I can put them in the merge commit. I'm going to continue with the every-other-week RC schedule and release on July 6th. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH U-BOOT v2 00/30] fs: btrfs: Re-implement btrfs support using the more widely used extent buffer base code
Gentle ping? Any updates? Hopes this won't block the incoming new features too long. Thanks, Qu On 2020/5/25 下午2:32, Qu Wenruo wrote: > The branch can be fetched from github: > https://github.com/adam900710/u-boot/tree/btrfs_rebuild > > The current btrfs code in U-boot is using a creative way to read on-disk > data. > It's pretty simple, involving the least amount of code, but pretty > different from btrfs-progs nor kernel, making it pretty hard to sync > code between different projects. > > This big patchset will rework the btrfs support, to use code mostly from > btrfs-progs, thus all existing btrfs developers will feel at home. > > During the rework, the following new features are added: > - More hash algorithm support > SHA256 and XXHASH support are added. > BLAKE2 needs more backport, will happen in a separate patchset. > > - The ability to read degraded RAID1 > Although we still only support one device btrfs, the new code base > can choose from different copies already. > As long as new device scan interface is provided, multi-device support > is pretty simple. > > - More correct handling of compressed extents with offset > For compressed extent with offset, we should read the whole compressed > extent, decompress them, then copy the referred part. > > There are some more features incoming, with the new code base it would > be much easier to implement: > - Data checksum support > The check would happen in read_extent_data(), btrfs-progs has the > needed facility to locate data csum. > > - BLAKE2 support > Need BLAKE2 library cross ported. > For btrfs it's just several lines of modification. > > - Multi-device support along wit degraded RAID support > We only need an interface to scan one device without opening it. > The infrastructure is already provided in this patchset. > > These new features would be submitted after the patchset get merged, > since the patchset is already large, I don't want to make it more scary. > > Although this patchset look horribly large, most of them are code copy > from btrfs-progs. > E.g extent-cache.[ch], rbtree-utils.[ch], btrfs_btree.h. > And ctree.h has over 1000 lines copied just for various accessors. > > While for disk-io.[ch] and volumes-io.[ch], they have some small > modifications to adapt the interface of U-boot. > E.g. btrfs_device::fd is replace with blkdev_desc and disk_partition_t. > > The new code for U-boot are related to the following functions: > - btrfs_readlink() > - btrfs_lookup_path() > - btrfs_read_extent_inline() > - btrfs_read_extent_reg() > - lookup_data_extent() > - btrfs_file_read() > - btrfs_list_subvols() > > Thus only the following 5 patches need extra review attention: > - Patch 0017 > - Patch 0019 > - Patch 0023 > - Patch 0024 > - Patch 0025~0028 > > Changelog: > v2: > - Implement btrfs_list_subvols() > In v1 it's completely removed thus would cause problem if btrfsolume > command is compiled in. > > - Rebased to latest master > Only minor conflicts due to header changes. > > - Allow next_legnth() to return value > BTRFS_NAME_LEN > > Qu Wenruo (30): > fs: btrfs: Sync btrfs_btree.h from kernel > fs: btrfs: Add More checksum algorithm support to btrfs > fs: btrfs: Cross-port btrfs_read_dev_super() from btrfs-progs > fs: btrfs: Cross-port rbtree-utils from btrfs-progs > fs: btrfs: Cross-port extent-cache.[ch] from btrfs-progs > fs: btrfs: Cross-port extent-io.[ch] from btrfs-progs > fs: btrfs: Cross port structure accessor into ctree.h > fs: btrfs: Cross port volumes.[ch] from btrfs-progs > fs: btrfs: Crossport read_tree_block() from btrfs-progs > fs: btrfs: Rename struct btrfs_path to struct __btrfs_path > fs: btrfs: Rename btrfs_root to __btrfs_root > fs: btrfs: Cross port struct btrfs_root to ctree.h > fs: btrfs: Crossport btrfs_search_slot() from btrfs-progs > fs: btrfs: Crossport btrfs_read_sys_array() and > btrfs_read_chunk_tree() > fs: btrfs: Crossport open_ctree_fs_info() > fs: btrfs: Rename path resolve related functions to avoid name > conflicts > fs: btrfs: Use btrfs_readlink() to implement __btrfs_readlink() > fs: btrfs: inode: Allow next_length() to return value > BTRFS_NAME_LEN > fs: btrfs: Implement btrfs_lookup_path() > fs: btrfs: Use btrfs_iter_dir() to replace btrfs_readdir() > fs: btrfs: Use btrfs_lookup_path() to implement btrfs_exists() and > btrfs_size() > fs: btrfs: Rename btrfs_file_read() and its callees to avoid name > conflicts > fs: btrfs: Introduce btrfs_read_extent_inline() and > btrfs_read_extent_reg() > fs: btrfs: Introduce lookup_data_extent() for later use > fs: btrfs: Implement btrfs_file_read() > fs: btrfs: Introduce function to reolve path in one subvolume > fs: btrfs: Introduce function to resolve the path of one subvolume > fs: btrfs: Imeplement btrfs_list_subvols() using new infrastructure > fs: btrfs: Cleanup the old implementation > MAINTAINERS: Add btrfs mail list >
Re: Please pull u-boot-dm/next
Hi Tom, On Mon, Jun 22, 2020 at 10:02 PM Tom Rini wrote: > > On Mon, Jun 22, 2020 at 10:01:09PM +0800, Bin Meng wrote: > > Hi Tom, > > > > On Mon, Jun 22, 2020 at 9:58 PM Tom Rini wrote: > > > > > > On Mon, Jun 22, 2020 at 09:43:57PM +0800, Bin Meng wrote: > > > > Hi Tom, > > > > > > > > On Mon, Jun 15, 2020 at 12:00 AM Tom Rini wrote: > > > > > > > > > > On Fri, Jun 12, 2020 at 09:17:28PM -0600, Simon Glass wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > This is for -next > > > > > > > > > > > > But I based it on master to avoid pulling in other people's > > > > > > commits. I hope > > > > > > that works OK. > > > > > > > > > > > > > > > > > > The following changes since commit > > > > > > be79009f3b9bbdbce283e67a865121e576d790ea: > > > > > > > > > > > > Merge tag 'u-boot-imx-20200609' of > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-09 > > > > > > 09:17:24 > > > > > > -0400) > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-pull-12jun20 > > > > > > > > > > > > for you to fetch changes up to > > > > > > cea8f2c995b9d87af6ef42f967402e1c8a3506db: > > > > > > > > > > > > doc: driver-model: fix typo in design.rst (2020-06-11 20:52:11 > > > > > > -0600) > > > > > > > > > > > > > > > > Applied to u-boot/master, thanks! > > > > > > > > I did not find my 2 patches are in u-boot/master. Anything wrong? > > > > > > > > Bin Meng (2): > > > > fdtdec: Fix the types of addr and size in > > > > fdtdec_add_reserved_memory() > > > > fdtdec: Honor #address-cells and #size-cells in > > > > fdtdec_add_reserved_memory() > > > > > > Yes, sorry, I hit the wrong keys. This is in -next and not master as > > > Simon noted this is a PR for -next. > > > > Okay, good to know. I was thinking these 2 are bug fixes, and should > > be against this release, not next :) > > Are they regression fixes too? Or just bug fixes? They are bug fixes I think. Regards, Bin
Re: [U-Boot] Pull request: u-boot-riscv/master
On Mon, Jun 22, 2020 at 02:03:52PM +0800, Rick Chen wrote: > Hi Tom > > > From: Tom Rini [mailto:tr...@konsulko.com] > > Sent: Monday, May 25, 2020 11:40 PM > > To: Open Source Project uboot > > Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) > > Subject: Re: [U-Boot] Pull request: u-boot-riscv/master > > > > On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote: > > > > > Hi Tom, > > > > > > Please pull some riscv updates: > > > > > > - Add Sipeed Maix support. > > > - sifive: fix palmer's email address. > > > - Move all SMP related SBI calls to SBI_v01. > > > > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926 > > > > > > Thanks > > > Rick > > > > > > > > > The following changes since commit > > > 9c5fef577494769e3ff07952a85f9b7125ef765b: > > > > > > Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400) > > > > > > are available in the Git repository at: > > > > > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > > > > > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607: > > > > > > riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800) > > > > > > > There's too many generic changes in this PR for this late in the cycle, for > > things I gather related to the Maix platform. All of the clk and DM > > changes impact virtually all platforms. Please re-do this PR to drop the > > Maix platform support for now, and resubmit that for -next, which I will be > > opening shortly. Everything else however is good for master. > > May I ask for your suggestions about this patch series about "riscv: > Add Sipeed Maix support " ? > Shall I send a PR include this patch series in early release cycle or > shall I suggest Sean to re-edit this patch series for less generic > changes which may bring virtual impacts? So I looked over the generic changes again. There's no other way to support the platform without those type of changes, yes? If so, yes, lets put it in to -next. -- Tom signature.asc Description: PGP signature
[PATCH v4 1/3] fastboot: Extend fastboot_set_reboot_flag with reboot reason
Extend fastboot_set_reboot_flag arguments with reboot reason so that
it could handle different reboot cases in future.
Signed-off-by: Roman Kovalivskyi
---
arch/arm/mach-meson/board-common.c | 6 +-
arch/arm/mach-rockchip/board.c | 6 +-
board/amazon/kc1/kc1.c | 6 +-
board/lg/sniper/sniper.c | 6 +-
board/ti/am57xx/board.c| 6 +-
board/ti/dra7xx/evm.c | 6 +-
drivers/fastboot/fb_command.c | 2 +-
drivers/fastboot/fb_common.c | 2 +-
include/fastboot.h | 10 +-
9 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-meson/board-common.c
b/arch/arm/mach-meson/board-common.c
index 19e5bfd3660c..a1f08bb98c6f 100644
--- a/arch/arm/mach-meson/board-common.c
+++ b/arch/arm/mach-meson/board-common.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -153,8 +154,11 @@ int board_late_init(void)
#if CONFIG_IS_ENABLED(FASTBOOT)
static unsigned int reboot_reason = REBOOT_REASON_NORMAL;
-int fastboot_set_reboot_flag()
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
reboot_reason = REBOOT_REASON_BOOTLOADER;
printf("Using reboot reason: 0x%x\n", reboot_reason);
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 430c0cbf41e4..ba4da72b3910 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -152,8 +153,11 @@ int board_usb_init(int index, enum usb_init_type init)
#endif /* CONFIG_USB_GADGET */
#if CONFIG_IS_ENABLED(FASTBOOT)
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
printf("Setting reboot to fastboot flag ...\n");
/* Set boot mode to fastboot */
writel(BOOT_FASTBOOT, CONFIG_ROCKCHIP_BOOT_MODE_REG);
diff --git a/board/amazon/kc1/kc1.c b/board/amazon/kc1/kc1.c
index fb1828ff44da..445980f16e62 100644
--- a/board/amazon/kc1/kc1.c
+++ b/board/amazon/kc1/kc1.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -163,8 +164,11 @@ void get_board_serial(struct tag_serialnr *serialnr)
omap_die_id_get_board_serial(serialnr);
}
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
return omap_reboot_mode_store("b");
}
diff --git a/board/lg/sniper/sniper.c b/board/lg/sniper/sniper.c
index 2825eccc035a..99b832fe601b 100644
--- a/board/lg/sniper/sniper.c
+++ b/board/lg/sniper/sniper.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -175,8 +176,11 @@ void reset_misc(void)
omap_reboot_mode_store(reboot_mode);
}
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
return omap_reboot_mode_store("b");
}
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 8720eb87a55d..49afd3bc927b 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1169,8 +1170,11 @@ int board_fit_config_name_match(const char *name)
#endif
#if CONFIG_IS_ENABLED(FASTBOOT) && !CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
printf("Setting reboot to fastboot flag ...\n");
env_set("dofastboot", "1");
env_save();
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index acf7ff169170..3bc40c721146 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1050,8 +1051,11 @@ int board_fit_config_name_match(const char *name)
#endif
#if CONFIG_IS_ENABLED(FASTBOOT) && !CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
-int fastboot_set_reboot_flag(void)
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
+ if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
+ return -ENOTSUPP;
+
printf("Setting reboot to fastboot flag ...\n");
env_set("dofastboot", "1");
env_save();
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 49f6a61c3745..8ce5d32fb2ba 100644
--- a/drivers/fastboot/fb_command.c
+++
[PATCH v4 3/3] fastboot: Add default fastboot_set_reboot_flag implementation
Default implementation of fastboot_set_reboot_flag function that depends
on "bcb" commands could be used in general case if there are no need to
make any platform-specific implementation, otherwise it could be
disabled via Kconfig option FASTBOOT_USE_BCB_SET_REBOOT_FLAG.
Please note that FASTBOOT_USE_BCB_SET_REBOOT_FLAG is mutually exclusive
with some platforms which already have their own implementation of this
function.
Signed-off-by: Roman Kovalivskyi
---
drivers/fastboot/Kconfig | 12 +
drivers/fastboot/Makefile | 1 +
drivers/fastboot/fb_bcb_impl.c | 48 ++
3 files changed, 61 insertions(+)
create mode 100644 drivers/fastboot/fb_bcb_impl.c
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index d4436dfc9173..4352ba67a713 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -165,6 +165,18 @@ config FASTBOOT_CMD_OEM_FORMAT
relies on the env variable partitions to contain the list of
partitions as required by the gpt command.
+config FASTBOOT_USE_BCB_SET_REBOOT_FLAG
+ bool "Use BCB by fastboot to set boot reason"
+ depends on CMD_BCB && !ARCH_MESON && !ARCH_ROCKCHIP && !TARGET_KC1 && \
+ !TARGET_SNIPER && !TARGET_AM57XX_EVM && !TARGET_DRA7XX_EVM
+ default y
+ help
+ Fastboot could implement setting of reboot reason in a generic fashion
+ via BCB commands. BCB commands are able to write reboot reason into
+ command field of boot control block. In general case it is sufficient
+ implementation if your platform supports BCB commands and doesn't
+ require any specific reboot reason handling.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/Makefile b/drivers/fastboot/Makefile
index 048af5aa8234..2b2c390fe4de 100644
--- a/drivers/fastboot/Makefile
+++ b/drivers/fastboot/Makefile
@@ -5,3 +5,4 @@ obj-y += fb_getvar.o
obj-y += fb_command.o
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fb_mmc.o
obj-$(CONFIG_FASTBOOT_FLASH_NAND) += fb_nand.o
+obj-$(CONFIG_FASTBOOT_USE_BCB_SET_REBOOT_FLAG) += fb_bcb_impl.o
diff --git a/drivers/fastboot/fb_bcb_impl.c b/drivers/fastboot/fb_bcb_impl.c
new file mode 100644
index ..a5ae94e2e357
--- /dev/null
+++ b/drivers/fastboot/fb_bcb_impl.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 GlobalLogic.
+ * Roman Kovalivskyi
+ */
+
+#include
+#include
+
+/**
+ * fastboot_set_reboot_flag() - Set flag to indicate reboot-bootloader
+ *
+ * Set flag which indicates that we should reboot into the bootloader
+ * following the reboot that fastboot executes after this function.
+ *
+ * This function should be overridden in your board file with one
+ * which sets whatever flag your board specific Android bootloader flow
+ * requires in order to re-enter the bootloader.
+ */
+int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
+{
+ static const char * const boot_cmds[] = {
+ "bootonce-bootloader",
+ "boot-fastboot",
+ "boot-recovery"
+ };
+
+ char cmd[32];
+
+ if (reason >= FASTBOOT_REBOOT_REASONS_COUNT)
+ return -EINVAL;
+
+ snprintf(cmd, sizeof(cmd), "bcb load %d misc",
+CONFIG_FASTBOOT_FLASH_MMC_DEV);
+
+ if (run_command(cmd, 0))
+ return -ENODEV;
+
+ snprintf(cmd, sizeof(cmd), "bcb set command %s", boot_cmds[reason]);
+
+ if (run_command(cmd, 0))
+ return -ENOEXEC;
+
+ if (run_command("bcb store", 0))
+ return -EIO;
+
+ return 0;
+}
--
2.17.1
[PATCH v4 2/3] fastboot: Add support for 'reboot fastboot' command
Android 10 adds support for dynamic partitions and in order to support
this userspace fastboot must be used[1]. New tool fastbootd is
included into recovery.
Userspace fastboot works from recovery and is launched if:
1) - Dynamic partitioning is enabled
2) - Boot control block has 'boot-fastboot' value into command field
The bootloader is expected to load and boot into the recovery image
upon seeing boot-fastboot in the BCB command. Recovery then parses the
BCB message and switches to fastbootd mode[2].
Please note that boot script is expected to handle 'boot-fastboot'
command in BCB and load into recovery mode.
Bootloader must support 'reboot fastboot' command which should reboot
device into userspace fastboot to accomodate those changes[3].
Another command that bootloader must support[3] is 'reboot recovery'. This
command should simply reboot device into recovery mode.
[1] - https://source.android.com/devices/bootloader/fastbootd
[2] -
https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery
[3] -
https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader
Signed-off-by: Roman Kovalivskyi
Signed-off-by: Roman Stratiienko
Change-Id: I9d2bdc9a6f6f31ea98572fe155e1cc8341e9af76
---
drivers/fastboot/fb_command.c | 38 +
drivers/usb/gadget/f_fastboot.c | 2 ++
include/fastboot.h | 4
net/fastboot.c | 2 ++
4 files changed, 46 insertions(+)
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 8ce5d32fb2ba..d3c578672dc6 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -37,6 +37,8 @@ static void flash(char *, char *);
static void erase(char *, char *);
#endif
static void reboot_bootloader(char *, char *);
+static void reboot_fastbootd(char *, char *);
+static void reboot_recovery(char *, char *);
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
static void oem_format(char *, char *);
#endif
@@ -79,6 +81,14 @@ static const struct {
.command = "reboot-bootloader",
.dispatch = reboot_bootloader
},
+ [FASTBOOT_COMMAND_REBOOT_FASTBOOTD] = {
+ .command = "reboot-fastboot",
+ .dispatch = reboot_fastbootd
+ },
+ [FASTBOOT_COMMAND_REBOOT_RECOVERY] = {
+ .command = "reboot-recovery",
+ .dispatch = reboot_recovery
+ },
[FASTBOOT_COMMAND_SET_ACTIVE] = {
.command = "set_active",
.dispatch = okay
@@ -313,6 +323,34 @@ static void reboot_bootloader(char *cmd_parameter, char
*response)
fastboot_okay(NULL, response);
}
+/**
+ * reboot_fastbootd() - Sets reboot fastboot flag.
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void reboot_fastbootd(char *cmd_parameter, char *response)
+{
+ if (fastboot_set_reboot_flag(FASTBOOT_REBOOT_REASON_FASTBOOTD))
+ fastboot_fail("Cannot set fastboot flag", response);
+ else
+ fastboot_okay(NULL, response);
+}
+
+/**
+ * reboot_recovery() - Sets reboot recovery flag.
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void reboot_recovery(char *cmd_parameter, char *response)
+{
+ if (fastboot_set_reboot_flag(FASTBOOT_REBOOT_REASON_RECOVERY))
+ fastboot_fail("Cannot set recovery flag", response);
+ else
+ fastboot_okay(NULL, response);
+}
+
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
/**
* oem_format() - Execute the OEM format command
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 384c0f6f6e27..30f7a52087fc 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -455,6 +455,8 @@ static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req)
case FASTBOOT_COMMAND_REBOOT:
case FASTBOOT_COMMAND_REBOOT_BOOTLOADER:
+ case FASTBOOT_COMMAND_REBOOT_FASTBOOTD:
+ case FASTBOOT_COMMAND_REBOOT_RECOVERY:
fastboot_func->in_req->complete = compl_do_reset;
break;
}
diff --git a/include/fastboot.h b/include/fastboot.h
index 14f4c68868d8..b86b508e69fd 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -32,6 +32,8 @@ enum {
FASTBOOT_COMMAND_CONTINUE,
FASTBOOT_COMMAND_REBOOT,
FASTBOOT_COMMAND_REBOOT_BOOTLOADER,
+ FASTBOOT_COMMAND_REBOOT_FASTBOOTD,
+ FASTBOOT_COMMAND_REBOOT_RECOVERY,
FASTBOOT_COMMAND_SET_ACTIVE,
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
FASTBOOT_COMMAND_OEM_FORMAT,
@@ -45,6 +47,8 @@ enum {
*/
enum fastboot_reboot_reason {
FASTBOOT_REBOOT_REASON_BOOTLOADER,
+ FASTBOOT_REBOOT_REASON_FASTBOOTD,
+
[PATCH v4 0/3] Add support for booting into userspace fastboot
Android 10 adds support for dynamic partitions and in order to support them userspace fastboot must be used[1]. New tool called fastbootd is included into recovery image. Userspace fastboot works from recovery and is launched if: 1) - Dynamic partitioning is enabled 2) - Boot control block has 'boot-fastboot' value into command field The bootloader is expected[2] to load and boot into the recovery image upon seeing boot-fastboot in the BCB command. Recovery then parses the BCB message and switches to fastbootd mode. Please note that boot script is expected to handle 'boot-fastboot' command in BCB and load into recovery mode. Bootloader must support[3] 'reboot fastboot' command which should reboot device into userspace fastboot to accomodate those changes. Another command that bootloader must support[3] is 'reboot recovery'. This command should simply reboot device into recovery mode. Changes since v3[6]: * Fixed indentation in Kconfig * Fixed default value for FASTBOOT_USE_BCB_SET_REBOOT_FLAG * Extended help message for FASTBOOT_USE_BCB_SET_REBOOT_FLAG Changes since v2[5]: * Split patch 1 into two separate patches: * Patch 1 extends fastboot_set_reboot_flag arguments with reboot reason * Patch 2 adds new reboot reasons for fastbootd and recovery * Added name for fastboot_rebot_reason enum * Replaced switch inside fastboot_set_reboot_flag with table lookup * Moved fastboot_set_reboot_flag BCB implementation to separate file Changes since v1[4]: * Added missing handling of reboot commands for network protocol * Extended fastboot_set_reboot_flag command to accept reboot reason * Made former fastboot_set_flag function as an optional implementation of fastboot_set_reboot_flag which could be turned on by Kconfig [1] - https://source.android.com/devices/bootloader/fastbootd [2] - https://source.android.com/devices/bootloader/fastbootd#unified_fastboot_and_recovery [3] - https://source.android.com/devices/bootloader/fastbootd#modifications_to_the_bootloader [4] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1590539734.git.roman.kovalivs...@globallogic.com/ [5] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1591254465.git.roman.kovalivs...@globallogic.com/ [6] - http://patchwork.ozlabs.org/project/uboot/cover/cover.1591806433.git.roman.kovalivs...@globallogic.com/ Roman Kovalivskyi (3): fastboot: Extend fastboot_set_reboot_flag with reboot reason fastboot: Add support for 'reboot fastboot' command fastboot: Add default fastboot_set_reboot_flag implementation arch/arm/mach-meson/board-common.c | 6 +++- arch/arm/mach-rockchip/board.c | 6 +++- board/amazon/kc1/kc1.c | 6 +++- board/lg/sniper/sniper.c | 6 +++- board/ti/am57xx/board.c| 6 +++- board/ti/dra7xx/evm.c | 6 +++- drivers/fastboot/Kconfig | 12 drivers/fastboot/Makefile | 1 + drivers/fastboot/fb_bcb_impl.c | 48 ++ drivers/fastboot/fb_command.c | 40 - drivers/fastboot/fb_common.c | 2 +- drivers/usb/gadget/f_fastboot.c| 2 ++ include/fastboot.h | 14 - net/fastboot.c | 2 ++ 14 files changed, 148 insertions(+), 9 deletions(-) create mode 100644 drivers/fastboot/fb_bcb_impl.c -- 2.17.1
Re: [PATCH v2 1/1] efi_loader: prepare for read only OP-TEE variables
On Mon, Jun 22, 2020 at 06:10:27PM +0200, Heinrich Schuchardt wrote:
> We currently have two implementations of UEFI variables:
>
> * variables provided via an OP-TEE module
> * variables stored in the U-Boot environment
>
> Read only variables are up to now only implemented in the U-Boot
> environment implementation.
>
> Provide a common interface for both implementations that allows handling
> read-only variables.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> add missing efi_variable.h
> consider attributes==NULL in efi_variable_get()
> ---
> include/efi_variable.h | 40 +++
> lib/efi_loader/Makefile | 1 +
> lib/efi_loader/efi_variable.c| 171 ---
> lib/efi_loader/efi_variable_common.c | 79 +
> lib/efi_loader/efi_variable_tee.c| 75
> 5 files changed, 188 insertions(+), 178 deletions(-)
> create mode 100644 include/efi_variable.h
> create mode 100644 lib/efi_loader/efi_variable_common.c
>
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> new file mode 100644
> index 00..784dbd9cf4
> --- /dev/null
> +++ b/include/efi_variable.h
I think that all the stuff here should be put in efi_loader.h.
I don't see any benefit of having a separate header.
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2020, Heinrich Schuchardt
> + */
> +
> +#ifndef _EFI_VARIABLE_H
> +#define _EFI_VARIABLE_H
> +
> +#define EFI_VARIABLE_READ_ONLY BIT(31)
This is not part of UEFI specification.
Having the same prefix, EFI_VARIABLE_, as other attributes
can be confusing.
-Takahiro Akashi
> +/**
> + * efi_get_variable() - retrieve value of a UEFI variable
> + *
> + * @variable_name: name of the variable
> + * @vendor: vendor GUID
> + * @attributes: attributes of the variable
> + * @data_size: size of the buffer to which the variable value
> is copied
> + * @data:buffer to which the variable value is copied
> + * Return: status code
> + */
> +efi_status_t efi_get_variable_int(u16 *variable_name, const efi_guid_t
> *vendor,
> + u32 *attributes, efi_uintn_t *data_size,
> + void *data);
> +
> +/**
> + * efi_set_variable() - set value of a UEFI variable
> + *
> + * @variable_name: name of the variable
> + * @vendor: vendor GUID
> + * @attributes: attributes of the variable
> + * @data_size: size of the buffer with the variable value
> + * @data:buffer with the variable value
> + * @ro_check:check the read only read only bit in attributes
> + * Return: status code
> + */
> +efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t
> *vendor,
> + u32 attributes, efi_uintn_t data_size,
> + const void *data, bool ro_check);
> +
> +#endif
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 57c7e66ea0..16b93ef7f0 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -35,6 +35,7 @@ obj-y += efi_root_node.o
> obj-y += efi_runtime.o
> obj-y += efi_setup.o
> obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
> +obj-y += efi_variable_common.o
> ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
> obj-y += efi_variable_tee.o
> else
> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> index e097670e28..85df1427bc 100644
> --- a/lib/efi_loader/efi_variable.c
> +++ b/lib/efi_loader/efi_variable.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -15,7 +16,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
> @@ -30,20 +30,6 @@ static bool efi_secure_boot;
> static int efi_secure_mode;
> static u8 efi_vendor_keys;
>
> -#define READ_ONLY BIT(31)
> -
> -static efi_status_t efi_get_variable_common(u16 *variable_name,
> - const efi_guid_t *vendor,
> - u32 *attributes,
> - efi_uintn_t *data_size, void *data);
> -
> -static efi_status_t efi_set_variable_common(u16 *variable_name,
> - const efi_guid_t *vendor,
> - u32 attributes,
> - efi_uintn_t data_size,
> - const void *data,
> - bool ro_check);
> -
> /*
> * Mapping between EFI variables and u-boot variables:
> *
> @@ -154,7 +140,7 @@ static const char *parse_attr(const char *str, u32
> *attrp, u64 *timep)
> str++;
>
> if ((s = prefix(str, "ro"))) {
> - attr |= READ_ONLY;
> + attr |=
[PATCH] arm64: zynqmp: Support converting pm_cfg_obj.c
To use CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE, a developer must pull down the U-Boot source and run ./tools/zynqmp_pm_cfg_obj_convert.py to convert their pm_cfg_obj.c into U-Boot's PMU loader format, then feed that file back to U-Boot during build. Instead, by doing the conversion in U-Boot during the build, we can simplify the developer's build system. And it ensures that if zynqmp_pm_cfg_obj_convert.py is updated, the pm_cfg_obj will stay in sync with U-Boot. Add a config to set the file format, but leave the default as binary type for backwards compatibility. Signed-off-by: Brandon Maier --- arch/arm/mach-zynqmp/Kconfig | 20 board/xilinx/zynqmp/Makefile | 10 +- board/xilinx/zynqmp/pm_cfg_obj.S | 2 +- 3 files changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig index d82a737a69..d9116870ee 100644 --- a/arch/arm/mach-zynqmp/Kconfig +++ b/arch/arm/mach-zynqmp/Kconfig @@ -65,6 +65,26 @@ config PMUFW_INIT_FILE Include external PMUFW (Platform Management Unit FirmWare) to a Xilinx bootable image (boot.bin). +choice + prompt "PMU firmware configuration format" + default ZYNQMP_SPL_PM_CFG_BIN + help + Format of the file given to ZYNQMP_SPL_PM_CFG_OBJ_FILE. + +config ZYNQMP_SPL_PM_CFG_BIN + bool "pm_cfg_obj.bin" + help + The pm_cfg_obj.c after being preprocessed to a binary blob. + +config ZYNQMP_SPL_PM_CFG_SRC + bool "pm_cfg_obj.c" + help + The source file output from the Xilinx tools. This file is + generated when building the Xilinx SDK BSP. For example at + ./psu_cortexa53_0/libsrc/xilpm_v2_4/src/pm_cfg_obj.c + +endchoice + config ZYNQMP_SPL_PM_CFG_OBJ_FILE string "PMU firmware configuration object to load at runtime by SPL" depends on SPL diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile index 398c6aaa45..05067c43be 100644 --- a/board/xilinx/zynqmp/Makefile +++ b/board/xilinx/zynqmp/Makefile @@ -40,8 +40,16 @@ endif ifdef CONFIG_SPL_BUILD ifneq ($(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE),"") +ZYNQMP_SPL_CFG_OBJ_FILE = $(shell cd $(srctree); readlink -f $(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE)) FORCE +ifdef CONFIG_ZYNQMP_SPL_PM_CFG_BIN +board/xilinx/zynqmp/pm_cfg_obj.bin: $(ZYNQMP_SPL_CFG_OBJ_FILE) + cp $< $@ +else +board/xilinx/zynqmp/pm_cfg_obj.bin: $(ZYNQMP_SPL_CFG_OBJ_FILE) + $(srctree)/tools/zynqmp_pm_cfg_obj_convert.py $< $@ +endif obj-$(CONFIG_SPL_BUILD) += pm_cfg_obj.o -$(obj)/pm_cfg_obj.o: $(shell cd $(srctree); readlink -f $(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE)) FORCE +$(obj)/pm_cfg_obj.o: board/xilinx/zynqmp/pm_cfg_obj.bin endif endif diff --git a/board/xilinx/zynqmp/pm_cfg_obj.S b/board/xilinx/zynqmp/pm_cfg_obj.S index c4ca77e396..77e39017f8 100644 --- a/board/xilinx/zynqmp/pm_cfg_obj.S +++ b/board/xilinx/zynqmp/pm_cfg_obj.S @@ -9,7 +9,7 @@ zynqmp_pm_cfg_obj: .align 4 -.incbin CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE +.incbin "board/xilinx/zynqmp/pm_cfg_obj.bin" zynqmp_pm_cfg_obj_end: -- 2.25.1
[PATCH v1 7/7] verdin-imx8mm: add EEPROM support for carrier board
From: Igor Opaniuk Enable these Kconfig symbols: TDX_CFG_BLOCK_EXTRA=y TDX_HAVE_EEPROM_EXTRA=y Signed-off-by: Igor Opaniuk --- board/toradex/verdin-imx8mm/Kconfig | 6 ++ configs/verdin-imx8mm_defconfig | 1 + 2 files changed, 7 insertions(+) diff --git a/board/toradex/verdin-imx8mm/Kconfig b/board/toradex/verdin-imx8mm/Kconfig index 8a2fe98..149aed6 100644 --- a/board/toradex/verdin-imx8mm/Kconfig +++ b/board/toradex/verdin-imx8mm/Kconfig @@ -12,9 +12,15 @@ config SYS_CONFIG_NAME config TDX_CFG_BLOCK default y +config TDX_CFG_BLOCK_EXTRA + default y + config TDX_HAVE_MMC default y +config TDX_HAVE_EEPROM_EXTRA + default y + config TDX_CFG_BLOCK_DEV default "0" diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig index f5b6e03..74cc8dd 100644 --- a/configs/verdin-imx8mm_defconfig +++ b/configs/verdin-imx8mm_defconfig @@ -74,6 +74,7 @@ CONFIG_MXC_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MXC=y CONFIG_MISC=y +CONFIG_I2C_EEPROM=y CONFIG_DM_MMC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_ESDHC_IMX=y -- 2.7.4
[PATCH v1 6/7] ARM: dts: imx8mm-verdin: eeprom nodes adjustments
From: Igor Opaniuk
Rename EEPROM nodes.
Create aliases for EEPROM to unify their order:
eeprom0 - on-module EEPROM
eeprom1 - carrier-board EEPROM
eeprom2 - MIPI-DSI to HDMI adapter EEPROM
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx8mm-verdin.dts | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
index b86f46e..1c67c08 100644
--- a/arch/arm/dts/imx8mm-verdin.dts
+++ b/arch/arm/dts/imx8mm-verdin.dts
@@ -16,6 +16,12 @@
stdout-path =
};
+ aliases {
+ eeprom0 = _module;
+ eeprom1 = _carrier_board;
+ eeprom2 = _display_adapter;
+ };
+
/* fixed clock dedicated to SPI CAN controller */
clk20m: oscillator {
compatible = "fixed-clock";
@@ -321,8 +327,8 @@
vcc-supply = <_reg>;
};
- eeprom@50 {
- compatible = "st,24c02";
+ eeprom_module: eeprom@50 {
+ compatible = "st,24c02", "atmel,24c02", "i2c-eeprom";
pagesize = <16>;
reg = <0x50>;
};
@@ -377,16 +383,16 @@
status = "okay";
};
- /* EEPROM on MIPI-DSI to HDMI adapter */
- eeprom_50: eeprom@50 {
- compatible = "st,24c02";
+ /* EEPROM on display adapter (MIPI DSI Display Adapter) */
+ eeprom_display_adapter: eeprom@50 {
+ compatible = "st,24c02", "atmel,24c02", "i2c-eeprom";
pagesize = <16>;
reg = <0x50>;
};
- /* EEPROM on Verdin Development board */
- eeprom_57: eeprom@57 {
- compatible = "st,24c02";
+ /* EEPROM on carrier board */
+ eeprom_carrier_board: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02", "i2c-eeprom";
pagesize = <16>;
reg = <0x57>;
};
--
2.7.4
[PATCH v1 0/7] Toradex: EEPROM storage support for Config Block
This series introduces support for EEPROM as a storage for the main Toradex config block and additional config blocks on extra EEPROM chips (on carrier board or video adapters). To enable EEPROM as a storage for the main config block: TDX_HAVE_EEPROM=y. For additional EEPROMs please enable this Kconfig symbol: TDX_CFG_BLOCK_EXTRA=y. Information about existing EEPROM chips is provided via Device Tree using aliases. You can also write configuration for the carrier board using create_carrier subcommand for cfgblock. Example: Verdin iMX8MM # cfgblock create_carrier Supported carrier boards: UNKNOWN CARRIER = [0] Verdin Carrier Board= [1] Choose your carrier board (provide ID): 1 Enter carrier board version (e.g. V1.1B): V1.0A Enter carrier board serial number: 10622780 Also with barcode: Verdin iMX8MM # cfgblock create carrier -y 0156100010622780 Igor Opaniuk (7): toradex: tdx-cfg-block: add EEPROM read/store wrappers toradex: tdx-cfg-block: add carrier boards and display adapters toradex: tdx-cfg-block: add support for EEPROM toradex: tdx-cfg-clock: add migration routine from PID8 toradex: tdx-cfg-block: add carrier board info printing ARM: dts: imx8mm-verdin: eeprom nodes adjustments verdin-imx8mm: add EEPROM support for carrier board arch/arm/dts/imx8mm-verdin.dts | 22 +- board/toradex/common/Kconfig | 18 ++ board/toradex/common/Makefile| 1 + board/toradex/common/tdx-cfg-block.c | 402 +++ board/toradex/common/tdx-cfg-block.h | 16 ++ board/toradex/common/tdx-common.c| 28 +++ board/toradex/common/tdx-eeprom.c| 90 board/toradex/common/tdx-eeprom.h| 14 ++ board/toradex/verdin-imx8mm/Kconfig | 6 + configs/verdin-imx8mm_defconfig | 1 + 10 files changed, 551 insertions(+), 47 deletions(-) create mode 100644 board/toradex/common/tdx-eeprom.c create mode 100644 board/toradex/common/tdx-eeprom.h -- 2.7.4
[PATCH v1 3/7] toradex: tdx-cfg-block: add support for EEPROM
From: Igor Opaniuk
This introduces support for EEPROM as a storage for the main Toradex
config block and additional config blocks on extra EEPROM chips (on
carrier board or video adapters).
To enable EEPROM as a storage for the main config block:
TDX_HAVE_EEPROM=y.
For additional EEPROMs please enable this Kconfig symbol:
TDX_CFG_BLOCK_EXTRA=y.
Information about existing EEPROM chips is provided via Device Tree
using aliases.
You can also write configuration for the carrier board using
create_carrier subcommand for cfgblock. Example:
Verdin iMX8MM # cfgblock create_carrier
Supported carrier boards:
UNKNOWN CARRIER = [0]
Verdin Carrier Board= [1]
Choose your carrier board (provide ID): 1
Enter carrier board version (e.g. V1.1B): V1.0A
Enter carrier board serial number: 10622780
Also with barcode:
Verdin iMX8MM # cfgblock create carrier -y 0156100010622780
Signed-off-by: Igor Opaniuk
---
board/toradex/common/Kconfig | 18 ++
board/toradex/common/tdx-cfg-block.c | 312 ++-
board/toradex/common/tdx-cfg-block.h | 3 +
3 files changed, 294 insertions(+), 39 deletions(-)
diff --git a/board/toradex/common/Kconfig b/board/toradex/common/Kconfig
index 11f4aab..36068d2 100644
--- a/board/toradex/common/Kconfig
+++ b/board/toradex/common/Kconfig
@@ -20,6 +20,12 @@ config TDX_HAVE_NAND
config TDX_HAVE_NOR
bool
+config TDX_HAVE_EEPROM
+ bool
+
+config TDX_HAVE_EEPROM_EXTRA
+ bool
+
if TDX_CFG_BLOCK
config TDX_CFG_BLOCK_IS_IN_MMC
@@ -37,6 +43,11 @@ config TDX_CFG_BLOCK_IS_IN_NOR
depends on TDX_HAVE_NOR
default y
+config TDX_CFG_BLOCK_IS_IN_EEPROM
+ bool
+ depends on TDX_HAVE_EEPROM
+ default y
+
config TDX_CFG_BLOCK_DEV
int "Toradex config block eMMC device ID"
depends on TDX_CFG_BLOCK_IS_IN_MMC
@@ -66,4 +77,11 @@ config TDX_CFG_BLOCK_2ND_ETHADDR
Ethernet carrier boards. This options enables the code to set the
second Ethernet address as environment variable (eth1addr).
+config TDX_CFG_BLOCK_EXTRA
+ bool "Support for additional EEPROMs (carrier board, display adapter)"
+ depends on TDX_HAVE_EEPROM_EXTRA
+ help
+ Enables fetching auxilary config blocks from carrier board/display
+ adapter EEPROMs.
+
endif
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 48d2d0f..9699a50 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -5,6 +5,8 @@
#include
#include "tdx-cfg-block.h"
+#include "tdx-eeprom.h"
+
#include
#include
@@ -37,21 +39,31 @@ DECLARE_GLOBAL_DATA_PTR;
#define TAG_VALID 0xcf01
#define TAG_MAC0x
+#define TAG_CAR_SERIAL 0x0021
#define TAG_HW 0x0008
#define TAG_INVALID0x
#define TAG_FLAG_VALID 0x1
+#define TDX_EEPROM_ID_MODULE 0
+#define TDX_EEPROM_ID_CARRIER 1
+
#if defined(CONFIG_TDX_CFG_BLOCK_IS_IN_MMC)
#define TDX_CFG_BLOCK_MAX_SIZE 512
#elif defined(CONFIG_TDX_CFG_BLOCK_IS_IN_NAND)
#define TDX_CFG_BLOCK_MAX_SIZE 64
#elif defined(CONFIG_TDX_CFG_BLOCK_IS_IN_NOR)
#define TDX_CFG_BLOCK_MAX_SIZE 64
+#elif defined(CONFIG_TDX_CFG_BLOCK_IS_IN_EEPROM)
+#define TDX_CFG_BLOCK_MAX_SIZE 64
#else
#error Toradex config block location not set
#endif
+#ifdef CONFIG_TDX_CFG_BLOCK_EXTRA
+#define TDX_CFG_BLOCK_EXTRA_MAX_SIZE 64
+#endif
+
struct toradex_tag {
u32 len:14;
u32 flags:2;
@@ -62,6 +74,11 @@ bool valid_cfgblock;
struct toradex_hw tdx_hw_tag;
struct toradex_eth_addr tdx_eth_addr;
u32 tdx_serial;
+#ifdef CONFIG_TDX_CFG_BLOCK_EXTRA
+u32 tdx_car_serial;
+bool valid_cfgblock_carrier;
+struct toradex_hw tdx_car_hw_tag;
+#endif
const char * const toradex_modules[] = {
[0] = "UNKNOWN MODULE",
@@ -236,6 +253,20 @@ static int write_tdx_cfg_block_to_nor(unsigned char
*config_block)
}
#endif
+#ifdef CONFIG_TDX_CFG_BLOCK_IS_IN_EEPROM
+static int read_tdx_cfg_block_from_eeprom(unsigned char *config_block)
+{
+ return read_tdx_eeprom_data(TDX_EEPROM_ID_MODULE, 0x0, config_block,
+ TDX_CFG_BLOCK_MAX_SIZE);
+}
+
+static int write_tdx_cfg_block_to_eeprom(unsigned char *config_block)
+{
+ return write_tdx_eeprom_data(TDX_EEPROM_ID_MODULE, 0x0, config_block,
+TDX_CFG_BLOCK_MAX_SIZE);
+}
+#endif
+
int read_tdx_cfg_block(void)
{
int ret = 0;
@@ -259,6 +290,8 @@ int read_tdx_cfg_block(void)
ret = read_tdx_cfg_block_from_nand(config_block);
#elif defined(CONFIG_TDX_CFG_BLOCK_IS_IN_NOR)
ret = read_tdx_cfg_block_from_nor(config_block);
+#elif defined(CONFIG_TDX_CFG_BLOCK_IS_IN_EEPROM)
+ ret = read_tdx_cfg_block_from_eeprom(config_block);
#else
ret = -EINVAL;
#endif
@@ -275,7 +308,12 @@ int read_tdx_cfg_block(void)
valid_cfgblock = true;
offset = 4;
- while
[PATCH v1 5/7] toradex: tdx-cfg-block: add carrier board info printing
From: Igor Opaniuk
Add carrier board info printing during boot time:
U-Boot 2020.07-rc4-02435-g1756e05 (Jun 22 2020 - 22:43:59 +0300)
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz
Carrier: Toradex Verdin Development Board V1.0A, Serial# 10622780
Verdin iMX8MM #
Signed-off-by: Igor Opaniuk
---
board/toradex/common/tdx-common.c | 28
1 file changed, 28 insertions(+)
diff --git a/board/toradex/common/tdx-common.c
b/board/toradex/common/tdx-common.c
index e8de923..7e353b4 100644
--- a/board/toradex/common/tdx-common.c
+++ b/board/toradex/common/tdx-common.c
@@ -19,6 +19,12 @@
static char tdx_serial_str[9];
static char tdx_board_rev_str[6];
+#ifdef CONFIG_TDX_CFG_BLOCK_EXTRA
+static char tdx_car_serial_str[9];
+static char tdx_car_rev_str[6];
+static char *tdx_carrier_board_name;
+#endif
+
#ifdef CONFIG_REVISION_TAG
u32 get_board_rev(void)
{
@@ -88,6 +94,28 @@ int show_board_info(void)
toradex_modules[tdx_hw_tag.prodid],
tdx_board_rev_str,
tdx_serial_str);
+#ifdef CONFIG_TDX_CFG_BLOCK_EXTRA
+ if (read_tdx_cfg_block_carrier()) {
+ printf("MISSING TORADEX CARRIER CONFIG BLOCKS\n");
+ try_migrate_tdx_cfg_block_carrier();
+ } else {
+ tdx_carrier_board_name = (char *)
+ toradex_carrier_boards[tdx_car_hw_tag.prodid];
+
+ sprintf(tdx_car_serial_str, "%08u", tdx_car_serial);
+ sprintf(tdx_car_rev_str, "V%1d.%1d%c",
+ tdx_car_hw_tag.ver_major,
+ tdx_car_hw_tag.ver_minor,
+ (char)tdx_car_hw_tag.ver_assembly +
+ 'A');
+
+ env_set("carrier_serial#", tdx_car_serial_str);
+ printf("Carrier: Toradex %s %s, Serial# %s\n",
+ tdx_carrier_board_name,
+ tdx_car_rev_str,
+ tdx_car_serial_str);
+ }
+#endif
}
/*
--
2.7.4
[PATCH v1 1/7] toradex: tdx-cfg-block: add EEPROM read/store wrappers
From: Igor Opaniuk
These functions wrap functionality for storing config blocks in EEPROM.
Signed-off-by: Igor Opaniuk
---
board/toradex/common/Makefile | 1 +
board/toradex/common/tdx-eeprom.c | 90 +++
board/toradex/common/tdx-eeprom.h | 14 ++
3 files changed, 105 insertions(+)
create mode 100644 board/toradex/common/tdx-eeprom.c
create mode 100644 board/toradex/common/tdx-eeprom.h
diff --git a/board/toradex/common/Makefile b/board/toradex/common/Makefile
index 6b9fccb..7b19b6e 100644
--- a/board/toradex/common/Makefile
+++ b/board/toradex/common/Makefile
@@ -8,4 +8,5 @@ obj- := __dummy__.o
else
obj-$(CONFIG_TDX_CFG_BLOCK) += tdx-cfg-block.o
obj-y += tdx-common.o
+obj-y += tdx-eeprom.o
endif
diff --git a/board/toradex/common/tdx-eeprom.c
b/board/toradex/common/tdx-eeprom.c
new file mode 100644
index 000..fbc267d
--- /dev/null
+++ b/board/toradex/common/tdx-eeprom.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Toradex
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int get_tdx_eeprom(u32 eeprom_id, struct udevice **devp)
+{
+ int ret = 0;
+ int node;
+ ofnode eeprom;
+ char eeprom_str[16];
+ const char *path;
+
+ if (!gd->fdt_blob) {
+ printf("%s: don't have a valid gd->fdt_blob!\n", __func__);
+ return -EFAULT;
+ }
+
+ node = fdt_path_offset(gd->fdt_blob, "/aliases");
+ if (node < 0)
+ return -ENODEV;
+
+ sprintf(eeprom_str, "eeprom%d", eeprom_id);
+
+ path = fdt_getprop(gd->fdt_blob, node, eeprom_str, NULL);
+ if (!path) {
+ printf("%s: no alias for %s\n", __func__, eeprom_str);
+ return -ENODEV;
+ }
+
+ eeprom = ofnode_path(path);
+ if (!ofnode_valid(eeprom)) {
+ printf("%s: invalid hardware path to EEPROM\n", __func__);
+ return -ENODEV;
+ }
+
+ ret = uclass_get_device_by_ofnode(UCLASS_I2C_EEPROM, eeprom, devp);
+ if (ret) {
+ printf("%s: cannot find EEPROM by node\n", __func__);
+ return ret;
+ }
+
+ return ret;
+}
+
+int read_tdx_eeprom_data(u32 eeprom_id, int offset, u8 *buf,
+int size)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = get_tdx_eeprom(eeprom_id, );
+ if (ret)
+ return ret;
+
+ ret = i2c_eeprom_read(dev, 0x0, buf, size);
+ if (ret) {
+ printf("%s: error reading data from EEPROM id: %d!, ret = %d\n",
+ __func__, eeprom_id, ret);
+ return ret;
+ }
+
+ return ret;
+}
+
+int write_tdx_eeprom_data(u32 eeprom_id, int offset, u8 *buf,
+ int size)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = get_tdx_eeprom(eeprom_id, );
+ if (ret)
+ return ret;
+
+ ret = i2c_eeprom_write(dev, 0x0, buf, size);
+ if (ret) {
+ printf("%s: error writing data to EEPROM id: %d, ret = %d\n",
+ __func__, eeprom_id, ret);
+ return ret;
+ }
+
+ return ret;
+}
diff --git a/board/toradex/common/tdx-eeprom.h
b/board/toradex/common/tdx-eeprom.h
new file mode 100644
index 000..a6772d2
--- /dev/null
+++ b/board/toradex/common/tdx-eeprom.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2020 Toradex
+ */
+
+#ifndef _TDX_EEPROM_H
+#define _TDX_EEPROM_H
+
+#include
+
+int read_tdx_eeprom_data(u32 eeprom_id, int offset, uint8_t *buf, int size);
+int write_tdx_eeprom_data(u32 eeprom_id, int offset, uint8_t *buf, int size);
+
+#endif /* _TDX_EEPROM_H */
--
2.7.4
[PATCH v1 2/7] toradex: tdx-cfg-block: add carrier boards and display adapters
From: Igor Opaniuk
Add defines for supported carrier boards and display adapters.
Signed-off-by: Igor Opaniuk
---
board/toradex/common/tdx-cfg-block.c | 12
board/toradex/common/tdx-cfg-block.h | 11 +++
2 files changed, 23 insertions(+)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 75216ec..48d2d0f 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -124,6 +124,18 @@ const char * const toradex_modules[] = {
[57] = "Verdin iMX8M Mini DualLite 1GB",
};
+const char * const toradex_carrier_boards[] = {
+ [0] = "UNKNOWN CARRIER",
+ [155] = "Dahlia",
+ [156] = "Verdin Development Board",
+};
+
+const char * const toradex_display_adapters[] = {
+ [0] = "UNKNOWN ADAPTER",
+ [157] = "Verdin DSI to HDMI Adapter",
+ [159] = "Verdin DSI to LVDS Adapter",
+};
+
#ifdef CONFIG_TDX_CFG_BLOCK_IS_IN_MMC
static int tdx_cfg_block_mmc_storage(u8 *config_block, int write)
{
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index d8f3941..d58be23 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -80,7 +80,18 @@ enum {
VERDIN_IMX8MMDL,
};
+enum {
+ DAHLIA = 155,
+ VERDIN_DEVELOPMENT_BOARD = 156,
+};
+
+enum {
+ VERDIN_DSI_TO_HDMI_ADAPTER = 157,
+ VERDIN_DSI_TO_LVDS_ADAPTER = 159,
+};
+
extern const char * const toradex_modules[];
+extern const char * const toradex_carrier_boards[];
extern bool valid_cfgblock;
extern struct toradex_hw tdx_hw_tag;
extern struct toradex_eth_addr tdx_eth_addr;
--
2.7.4
[PATCH v1 4/7] toradex: tdx-cfg-clock: add migration routine from PID8
From: Igor Opaniuk
Add migration routine from PID8 pre-stored values on EEPROM
(including sane value checks).
Signed-off-by: Igor Opaniuk
---
board/toradex/common/tdx-cfg-block.c | 78
board/toradex/common/tdx-cfg-block.h | 2 +
2 files changed, 80 insertions(+)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 9699a50..9eb1edc 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -649,6 +649,84 @@ out:
return ret;
}
+int check_pid8_sanity(char *pid8)
+{
+ char s_carrierid_verdin[5];
+ char s_carrierid_dahlia[5];
+
+ sprintf(s_carrierid_verdin, "0%d", VERDIN_DEVELOPMENT_BOARD);
+ sprintf(s_carrierid_dahlia, "0%d", DAHLIA);
+
+ /* sane value check, first 4 chars which represent carrier id */
+ if (!strncmp(pid8, s_carrierid_verdin, 4))
+ return 0;
+
+ if (!strncmp(pid8, s_carrierid_dahlia, 4))
+ return 0;
+
+ return -EINVAL;
+}
+
+int try_migrate_tdx_cfg_block_carrier(void)
+{
+ char pid8[8];
+ int offset = 0;
+ int ret = CMD_RET_SUCCESS;
+ size_t size = TDX_CFG_BLOCK_EXTRA_MAX_SIZE;
+ u8 *config_block;
+
+ memset(pid8, 0x0, 8);
+ ret = read_tdx_eeprom_data(TDX_EEPROM_ID_CARRIER, 0x0, (u8 *)pid8, 8);
+ if (ret)
+ return ret;
+
+ if (check_pid8_sanity(pid8))
+ return -EINVAL;
+
+ /* Allocate RAM area for config block */
+ config_block = memalign(ARCH_DMA_MINALIGN, size);
+ if (!config_block) {
+ printf("Not enough malloc space available!\n");
+ return CMD_RET_FAILURE;
+ }
+
+ memset(config_block, 0xff, size);
+ /* we try parse PID8 concatenating zeroed serial number */
+ tdx_car_hw_tag.ver_major = pid8[4] - '0';
+ tdx_car_hw_tag.ver_minor = pid8[5] - '0';
+ tdx_car_hw_tag.ver_assembly = pid8[7] - '0';
+
+ pid8[4] = '\0';
+ tdx_car_hw_tag.prodid = simple_strtoul(pid8, NULL, 10);
+
+ /* Valid Tag */
+ write_tag(config_block, , TAG_VALID, NULL, 0);
+
+ /* Product Tag */
+ write_tag(config_block, , TAG_HW, (u8 *)_car_hw_tag,
+ sizeof(tdx_car_hw_tag));
+
+ /* Serial Tag */
+ write_tag(config_block, , TAG_CAR_SERIAL, (u8 *)_car_serial,
+ sizeof(tdx_car_serial));
+
+ memset(config_block + offset, 0, 32 - offset);
+ ret = write_tdx_eeprom_data(TDX_EEPROM_ID_CARRIER, 0x0, config_block,
+ size);
+ if (ret) {
+ printf("Failed to write Toradex Extra config block: %d\n",
+ ret);
+ ret = CMD_RET_FAILURE;
+ goto out;
+ }
+
+ printf("Successfully migrated to Toradex Config Block from PID8\n");
+
+out:
+ free(config_block);
+ return ret;
+}
+
static int get_cfgblock_carrier_interactive(void)
{
char message[CONFIG_SYS_CBSIZE];
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index e18da33..8f91d9a 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -102,4 +102,6 @@ extern u32 tdx_car_serial;
int read_tdx_cfg_block(void);
int read_tdx_cfg_block_carrier(void);
+int try_migrate_tdx_cfg_block_carrier(void);
+
#endif /* _TDX_CFG_BLOCK_H */
--
2.7.4
Re: Out of bounds access in arch/arm/cpu/armv7/iproc-common/armpll.c
Hi Heinrich, On 2020-06-06 3:51 p.m., Heinrich Schuchardt wrote: Hello Scott, CppCheck gives an error: [arch/arm/cpu/armv7/iproc-common/armpll.c:137]: (error) Array 'armpll_clk_tab[13]' accessed at index 17, which is out of bounds. In the loop at the start of armpll_config() i is determined. The maximum value of i after checking status in line 53 is 12. In line 137 your code accesses armpll_clk_tab[i+4].freqid The patch where you introduced the code dates from 2014. But hopefully you still remember what you intended to do in that line. I have checked with our tree. There is a bug in the code and the +4 could be deleted. But, the file armpll.c should simply be deleted and removed from the Makefile. This was already done years ago in our internal tree. There is no need for uboot to have control over these pll settings. Best regards Heinrich Regards, Scott
Re: [PATCH 2/2] ARM: tegra: Enable PSCI support for Tegra210 and Tegra186
On 6/18/20 5:54 AM, Jon Hunter wrote:
> The PSCI nodes are currently not populated for the Tegra210 and Tegra186
> devices. This prevents the PSCI driver from being able to identify the
> PSCI method used by these devices and causes the probe of the PSCI
> driver to fail.
>
> Since commit 81ea00838c68 ("efi_loader: PSCI reset and shutdown") was
> added, which moves the PSCI EFI system reset handler into the PSCI
> driver, this has prevented the EFI system reset from working for
> Tegra210 and Tegra186. Therefore, populating these nodes is necessary
> to fix the EFI system reset for Tegra210 and Tegra186.
I'm not sure that these platforms have *always* had a PSCI
implementation, so this is a slight assumption. Ideally, the FW should
add this to the DT and pass it to U-Boot... However, since all recentish
FW builds do implement PSCI, and the DT is hard-coded into U-Boot rather
than provided by the earlier FW, this change is probably just fine.
Re: [PATCH v2 9/9] test: sandbox: add test for erase command
On 6/16/20 1:40 AM, Patrick Delaunay wrote: > Add test for the erase command tested on ENV in EXT4. Acked-by: Stephen Warren
Re: [PATCH v2 6/9] test: environment in ext4
On 6/16/20 1:40 AM, Patrick Delaunay wrote:
> Add basic test to persistent environment in ext4:
> save and load in host ext4 file 'uboot.env'.
>
> On first execution an empty EXT4 file system is created in
> persistent data dir: env.ext4.img.
> diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
> +def mk_env_ext4(state_test_env):
> +if os.path.exists(persistent):
> +c.log.action('Disk image file ' + persistent + ' already exists')
> +else:
> +try:
> +check_call('rm -f %s' % persistent, shell=True)
This should be run with the results logged to the overall test log file
so that if there are failures, it's possible to see what they were. Use
util.run_and_log() for this.
Also, this particular command doesn't seem useful, since 4 lines above
the code verified that the file doesn't exist.
> +@pytest.mark.boardspec('sandbox')
> +@pytest.mark.buildconfigspec('cmd_nvedit_info')
> +@pytest.mark.buildconfigspec('cmd_echo')
> +@pytest.mark.buildconfigspec('env_is_in_ext4')
> +def test_env_ext4(state_test_env):
> +
> +c = state_test_env.u_boot_console
Nit: That blank line is a bit odd.
> +fs_img = mk_env_ext4(state_test_env)
> +c.run_command('host bind 0 %s' % fs_img)
> +
> +response = c.run_command('ext4ls host 0:0')
> +assert 'uboot.env' not in response
> +
> +""" env location: ENVL_EXT4 (2)
> +"""
Nit: Wrap the trailing """ onto the same line; no need to force it to be
a multi-line string. Also a comman may be better rather than a
docstring. Same for the other docstring later.
> +call('rm -f %s' % fs_img, shell=True)
This won't happen if the test fails earlier. Should there be a
try/except block or wrapper function with exception handling to resolve
this?
Re: [RESEND PATCH v5 4/4] test: env: add test for env info sub-command
On 6/19/20 6:03 AM, Patrick Delaunay wrote:
> Add a pytest for testing the env info sub-command:
>
> test_env_info: test command with several option that
> can be executed on real hardware device without assumption
>
> test_env_info_sandbox: test the result on sandbox
> with a known ENV configuration: ready & default & persistent
>
> The quiet option '-q' is used for support in shell test;
> for example:
> if env info -p -d -q; then env save; fi
Acked-by: Stephen Warren
> +def test_env_info(state_test_env):
...
> +for l in response.split('\n'):
> +if 'env_valid = ' in l:
> +assert '= invalid' in l or '= valid' in l or '= redundant' in l
> +nb_line += 1
> +elif 'env_ready =' in l or 'env_use_default =' in l:
> +assert '= true' in l or '= false' in l
> +nb_line += 1
> +else:
> +assert true
Those last two lines don't seem terribly useful:-)
Re: [PATCH 1/1] gitlab: show skipped Python tests
On Mon, Jun 22, 2020 at 12:23:35PM -0600, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 22 Jun 2020 at 10:40, Heinrich Schuchardt wrote:
> >
> > On 22.06.20 18:17, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt
> > > wrote:
> > >>
> > >> Call pytest3 with argument -ra to display reason why Python tests are
> > >> skipped.
> > >>
> > >> Signed-off-by: Heinrich Schuchardt
> > >> ---
> > >> .gitlab-ci.yml | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > >> index f2e491c117..f53098ea5f 100644
> > >> --- a/.gitlab-ci.yml
> > >> +++ b/.gitlab-ci.yml
> > >> @@ -46,7 +46,7 @@ stages:
> > >> # "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if
> > >> not
> > >> - export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
> > >>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
> > >> - ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > >> + ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > >> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> > >> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
> > >
> > > Do you have a link showing the current output with this patch?
> >
> > Hello Simon,
> >
> > here is an example output:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
>
> That's what I was afraid of. The skip output is more than the normal
> output, and if we don't intend to fix it, I'd rather not have
> unactionable warnings in the output.
>
> Having said that, we need to enable SPI flash, FPGA and MMC
> environment tests by the look of it.
On a different note, I think we should look at:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112376
and:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112380
as it shows that the reason we probably skip the test_fs/test_mkdir.py
tests is that since board is literal, we don't match sandbox on
sandbox_flattree. That answers one outstanding question about why we
skip some tests and not others at least.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3] common: fdt: Remove additional 4k space for fdt allocation
On 6/18/20 2:51 AM, Michal Simek wrote: > From: Ashok Reddy Soma > > There is no technical reason to add additional 4k space for FDT. This space > is completely unused and just increase memory requirements. This is > problematic on systems with limited memory resources as Xilinx Zynq > CSE/ZynqMP mini and Versal mini configurations. > > The patch is removing additional 4k space. > > EFI code is using copy_fdt() which copy FDT to different location. > And all boot commands in case of using U-Boot's FDT pointed by > $fdtcontroladdr are copying FDT to different locations by > image_setup_libfdt(). > That's why in proper flow none should modified DTB used by U-Boot that's > why there is no need for additional space. Acked-by: Stephen Warren
Re: [PATCH 1/1] gitlab: show skipped Python tests
On 22.06.20 20:23, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 22 Jun 2020 at 10:40, Heinrich Schuchardt wrote:
>>
>> On 22.06.20 18:17, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt
>>> wrote:
Call pytest3 with argument -ra to display reason why Python tests are
skipped.
Signed-off-by: Heinrich Schuchardt
---
.gitlab-ci.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f2e491c117..f53098ea5f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -46,7 +46,7 @@ stages:
# "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if not
- export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
- ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
+ ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
--build-dir "$UBOOT_TRAVIS_BUILD_DIR"
>>>
>>> Do you have a link showing the current output with this patch?
>>
>> Hello Simon,
>>
>> here is an example output:
>>
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
>
> That's what I was afraid of. The skip output is more than the normal
> output, and if we don't intend to fix it, I'd rather not have
> unactionable warnings in the output.
>
> Having said that, we need to enable SPI flash, FPGA and MMC
> environment tests by the look of it.
>
>>
>> Some of the skips are ok. But some we should really fix like:
>>
>> SKIPPED [1]
>> /builds/u-boot/custodians/u-boot-efi/test/py/tests/test_efi_loader.py:100:
>> No static network configuration is defined
>
> Also, I suspect that the warnings will be huge when running on real hardware.
Hello Simon,
this patch does not apply to real hardware. I am changing .gitlab-ci.yml
and not test/run. So the additional lines will only show up in Gitlab CI.
Best regards
Heinrich
Re: [PATCH 1/1] gitlab: show skipped Python tests
On 6/22/20 10:07 AM, Heinrich Schuchardt wrote: > Call pytest3 with argument -ra to display reason why Python tests are > skipped. Acked-by: Stephen Warren
Re: [PATCH 1/1] gitlab: show skipped Python tests
On Mon, Jun 22, 2020 at 12:23:35PM -0600, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 22 Jun 2020 at 10:40, Heinrich Schuchardt wrote:
> >
> > On 22.06.20 18:17, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt
> > > wrote:
> > >>
> > >> Call pytest3 with argument -ra to display reason why Python tests are
> > >> skipped.
> > >>
> > >> Signed-off-by: Heinrich Schuchardt
> > >> ---
> > >> .gitlab-ci.yml | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > >> index f2e491c117..f53098ea5f 100644
> > >> --- a/.gitlab-ci.yml
> > >> +++ b/.gitlab-ci.yml
> > >> @@ -46,7 +46,7 @@ stages:
> > >> # "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if
> > >> not
> > >> - export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
> > >>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
> > >> - ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > >> + ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > >> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> > >> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
> > >
> > > Do you have a link showing the current output with this patch?
> >
> > Hello Simon,
> >
> > here is an example output:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
>
> That's what I was afraid of. The skip output is more than the normal
> output, and if we don't intend to fix it, I'd rather not have
> unactionable warnings in the output.
>
> Having said that, we need to enable SPI flash, FPGA and MMC
> environment tests by the look of it.
So, looking at the output. 40 lines of test output, 32 lines of
explanation of why skips. I think it's still readable. It also shows
where perhaps we could group / re-org things a little as it already does
smart things like:
SKIPPED [131] /builds/u-boot/custodians/u-boot-efi/test/py/conftest.py:468:
board "qemu_arm64" not supported
Looking at the spi flash tests (and also the mmc read/write tests) we
should have a generic check in the tests for them be configured and bail
if not, as that would reduce the skip summary lines and collect them all
in one spot.
> > Some of the skips are ok. But some we should really fix like:
> >
> > SKIPPED [1]
> > /builds/u-boot/custodians/u-boot-efi/test/py/tests/test_efi_loader.py:100:
> > No static network configuration is defined
>
> Also, I suspect that the warnings will be huge when running on real hardware.
Well, that's beside the point with this patch. It's very specifically
only doing it on GitLab (and if/when we add this, v2 should cover
travis/Azure) as it's CI and logs are cheap but recreation can be
annoying. But it's also not true at least here. I see a few more lines
than the above example on my am335x_evm config, but I also have a few
more skips.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] gitlab: show skipped Python tests
Hi Heinrich,
On Mon, 22 Jun 2020 at 10:40, Heinrich Schuchardt wrote:
>
> On 22.06.20 18:17, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt
> > wrote:
> >>
> >> Call pytest3 with argument -ra to display reason why Python tests are
> >> skipped.
> >>
> >> Signed-off-by: Heinrich Schuchardt
> >> ---
> >> .gitlab-ci.yml | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> >> index f2e491c117..f53098ea5f 100644
> >> --- a/.gitlab-ci.yml
> >> +++ b/.gitlab-ci.yml
> >> @@ -46,7 +46,7 @@ stages:
> >> # "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if not
> >> - export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
> >>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
> >> - ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
> >> + ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
> >> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> >> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
> >
> > Do you have a link showing the current output with this patch?
>
> Hello Simon,
>
> here is an example output:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
That's what I was afraid of. The skip output is more than the normal
output, and if we don't intend to fix it, I'd rather not have
unactionable warnings in the output.
Having said that, we need to enable SPI flash, FPGA and MMC
environment tests by the look of it.
>
> Some of the skips are ok. But some we should really fix like:
>
> SKIPPED [1]
> /builds/u-boot/custodians/u-boot-efi/test/py/tests/test_efi_loader.py:100:
> No static network configuration is defined
Also, I suspect that the warnings will be huge when running on real hardware.
Regards,
Simon
Re: [PATCH 1/1] gitlab: show skipped Python tests
On 22.06.20 18:17, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt wrote:
>>
>> Call pytest3 with argument -ra to display reason why Python tests are
>> skipped.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> .gitlab-ci.yml | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index f2e491c117..f53098ea5f 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -46,7 +46,7 @@ stages:
>> # "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if not
>> - export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
>>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
>> - ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
>> + ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
>> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
>> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
>
> Do you have a link showing the current output with this patch?
Hello Simon,
here is an example output:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
Some of the skips are ok. But some we should really fix like:
SKIPPED [1]
/builds/u-boot/custodians/u-boot-efi/test/py/tests/test_efi_loader.py:100:
No static network configuration is defined
Best regards
Heinrich
Re: [PATCH 1/1] gitlab: show skipped Python tests
Hi Heinrich,
On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt wrote:
>
> Call pytest3 with argument -ra to display reason why Python tests are
> skipped.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> .gitlab-ci.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index f2e491c117..f53098ea5f 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -46,7 +46,7 @@ stages:
> # "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if not
> - export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
> - ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
> + ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
Do you have a link showing the current output with this patch?
Regards,
Simon
[PATCH v2 1/1] efi_loader: prepare for read only OP-TEE variables
We currently have two implementations of UEFI variables:
* variables provided via an OP-TEE module
* variables stored in the U-Boot environment
Read only variables are up to now only implemented in the U-Boot
environment implementation.
Provide a common interface for both implementations that allows handling
read-only variables.
Signed-off-by: Heinrich Schuchardt
---
v2:
add missing efi_variable.h
consider attributes==NULL in efi_variable_get()
---
include/efi_variable.h | 40 +++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_variable.c| 171 ---
lib/efi_loader/efi_variable_common.c | 79 +
lib/efi_loader/efi_variable_tee.c| 75
5 files changed, 188 insertions(+), 178 deletions(-)
create mode 100644 include/efi_variable.h
create mode 100644 lib/efi_loader/efi_variable_common.c
diff --git a/include/efi_variable.h b/include/efi_variable.h
new file mode 100644
index 00..784dbd9cf4
--- /dev/null
+++ b/include/efi_variable.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#ifndef _EFI_VARIABLE_H
+#define _EFI_VARIABLE_H
+
+#define EFI_VARIABLE_READ_ONLY BIT(31)
+
+/**
+ * efi_get_variable() - retrieve value of a UEFI variable
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer to which the variable value is copied
+ * @data: buffer to which the variable value is copied
+ * Return: status code
+ */
+efi_status_t efi_get_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+ u32 *attributes, efi_uintn_t *data_size,
+ void *data);
+
+/**
+ * efi_set_variable() - set value of a UEFI variable
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer with the variable value
+ * @data: buffer with the variable value
+ * @ro_check: check the read only read only bit in attributes
+ * Return: status code
+ */
+efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+ u32 attributes, efi_uintn_t data_size,
+ const void *data, bool ro_check);
+
+#endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 57c7e66ea0..16b93ef7f0 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -35,6 +35,7 @@ obj-y += efi_root_node.o
obj-y += efi_runtime.o
obj-y += efi_setup.o
obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
+obj-y += efi_variable_common.o
ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
obj-y += efi_variable_tee.o
else
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index e097670e28..85df1427bc 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -15,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -30,20 +30,6 @@ static bool efi_secure_boot;
static int efi_secure_mode;
static u8 efi_vendor_keys;
-#define READ_ONLY BIT(31)
-
-static efi_status_t efi_get_variable_common(u16 *variable_name,
- const efi_guid_t *vendor,
- u32 *attributes,
- efi_uintn_t *data_size, void *data);
-
-static efi_status_t efi_set_variable_common(u16 *variable_name,
- const efi_guid_t *vendor,
- u32 attributes,
- efi_uintn_t data_size,
- const void *data,
- bool ro_check);
-
/*
* Mapping between EFI variables and u-boot variables:
*
@@ -154,7 +140,7 @@ static const char *parse_attr(const char *str, u32 *attrp,
u64 *timep)
str++;
if ((s = prefix(str, "ro"))) {
- attr |= READ_ONLY;
+ attr |= EFI_VARIABLE_READ_ONLY;
} else if ((s = prefix(str, "nv"))) {
attr |= EFI_VARIABLE_NON_VOLATILE;
} else if ((s = prefix(str, "boot"))) {
@@ -202,29 +188,29 @@ static efi_status_t efi_set_secure_state(int sec_boot,
int setup_mode,
attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS |
-READ_ONLY;
- ret = efi_set_variable_common(L"SecureBoot", _global_variable_guid,
- attributes, sizeof(sec_boot),
[PATCH 1/1] gitlab: show skipped Python tests
Call pytest3 with argument -ra to display reason why Python tests are
skipped.
Signed-off-by: Heinrich Schuchardt
---
.gitlab-ci.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f2e491c117..f53098ea5f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -46,7 +46,7 @@ stages:
# "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if not
- export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
- ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
+ ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
--build-dir "$UBOOT_TRAVIS_BUILD_DIR"
--
2.27.0
Re: [PATCH] board: amlogic: Add Odroid-N2 board support
Hi Neil, On Mon, 22 Jun 2020 at 18:36, Neil Armstrong wrote: > > Hi, > > On 21/06/2020 19:23, Anand Moon wrote: > > Hi Neil, > > > > On Thu, 18 Jun 2020 at 20:11, Neil Armstrong > > wrote: > >> > >> From: Pascal Vizeli > >> > >> Add a proper Odroid-N2 board support to handle the Ethernet MAC > >> address stored in the in-SoC eFuses. > >> > > > > This feature need to be implemented for all Amlogic SoC boards, > > since many boards link libretech-cc also generate random mac address > > for ethernet. > > In fact, AFAIK only HardKernel stores the MAC in the fuses, now Amlogic stores > the MAC in the eMMC custom partitions, but they did for GXBB and previous > SoCs. > Earlier I introduced meson_generate_serial_ethaddr() for GXL and later (not > GXBB), > to generate an unique MAC address from the SoC serial. > > Neil > Thanks for this information. -Anand
[PATCH 2/2] mtd: make spinand driver usable without CONFIG_DM
From: Mikhail Kshevetskiy
Here is an example of spinand driver initialization without CONFIG_DM
enabled:
void board_nand_init(void)
{
static struct spinand_devicespinand;
static struct mtd_info mtd;
static struct spi_slave *slave;
int ret;
memset(, 0, sizeof(spinand));
memset(, 0, sizeof(mtd));
slave = spi_setup_slave(BUS, CS, MAX_HZ, MODE);
if (!slave) {
printf("SPI-NAND: Failed to set up SPI slave\n");
return;
}
slave->mode |= (SPI_TX_BYTE | SPI_RX_SLOW);
slave->max_read_size = SPI_MAX_READ_SIZE;
slave->max_write_size = SPI_MAX_WRITE_SIZE;
ret = spinand_probe_no_dm(, slave, );
if (!ret)
nand_register(0, );
}
Using of dual and quad wire transfer modes requires:
* dual/quad speed capable hardware (both controller and flash)
* physical presence of 4 data wires (quad mode only)
* spi controller driver MUST supports slave->mem_ops.exec_op() operations
(spi_xfer() interface will suits for single speed data transfer mode
only)
Signed-off-by: Mikhail Kshevetskiy
---
drivers/mtd/nand/spi/Kconfig | 2 +-
drivers/mtd/nand/spi/core.c | 46
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/spi/Kconfig b/drivers/mtd/nand/spi/Kconfig
index 0777dfdf0a..fd88e2cec9 100644
--- a/drivers/mtd/nand/spi/Kconfig
+++ b/drivers/mtd/nand/spi/Kconfig
@@ -1,6 +1,6 @@
menuconfig MTD_SPI_NAND
bool "SPI NAND device Support"
- depends on DM_MTD && DM_SPI
+ depends on (DM_MTD && DM_SPI) || (MTD && SPI)
select MTD_NAND_CORE
select SPI_MEM
help
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index e0ebd9c04b..a24e2e6677 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -170,14 +170,22 @@ int spinand_select_target(struct spinand_device *spinand,
unsigned int target)
static int spinand_init_cfg_cache(struct spinand_device *spinand)
{
struct nand_device *nand = spinand_to_nand(spinand);
+#ifdef CONFIG_DM
struct udevice *dev = spinand->slave->dev;
+#endif
unsigned int target;
int ret;
+#ifdef CONFIG_DM
spinand->cfg_cache = devm_kzalloc(dev,
sizeof(*spinand->cfg_cache) *
nand->memorg.ntargets,
GFP_KERNEL);
+#else
+ spinand->cfg_cache = kzalloc(sizeof(*spinand->cfg_cache) *
+nand->memorg.ntargets,
+GFP_KERNEL);
+#endif
if (!spinand->cfg_cache)
return -ENOMEM;
@@ -1135,6 +1144,7 @@ static void spinand_cleanup(struct spinand_device
*spinand)
kfree(spinand->scratchbuf);
}
+#ifdef CONFIG_DM
static int spinand_probe(struct udevice *dev)
{
struct spinand_device *spinand = dev_get_priv(dev);
@@ -1187,6 +1197,40 @@ err_spinand_cleanup:
return ret;
}
+#endif /* CONFIG_DM */
+
+#ifdef __UBOOT__
+int spinand_probe_no_dm(struct spinand_device *spinand,
+ struct spi_slave *slave,
+ struct mtd_info *mtd)
+{
+ struct nand_device *nand = spinand_to_nand(spinand);
+ int ret;
+
+ nand->mtd = mtd;
+ mtd->priv = nand;
+ mtd->name = malloc(20);
+ if (!mtd->name)
+ return -ENOMEM;
+ sprintf(mtd->name, "spi-nand%d", spi_nand_idx++);
+ spinand->slave = slave;
+
+ ret = spinand_init(spinand);
+ if (ret)
+ return ret;
+
+ ret = add_mtd_device(mtd);
+ if (ret)
+ goto err_spinand_cleanup;
+
+ return 0;
+
+err_spinand_cleanup:
+ spinand_cleanup(spinand);
+
+ return ret;
+}
+#endif /* __UBOOT__ */
#ifndef __UBOOT__
static int spinand_remove(struct udevice *slave)
@@ -1238,6 +1282,7 @@ MODULE_AUTHOR("Peter Pan");
MODULE_LICENSE("GPL v2");
#endif /* __UBOOT__ */
+#ifdef CONFIG_DM
static const struct udevice_id spinand_ids[] = {
{ .compatible = "spi-nand" },
{ /* sentinel */ },
@@ -1250,3 +1295,4 @@ U_BOOT_DRIVER(spinand) = {
.priv_auto_alloc_size = sizeof(struct spinand_device),
.probe = spinand_probe,
};
+#endif /* CONFIG_DM */
--
2.27.0
[PATCH 1/2] spi: make spi-mem driver usable without CONFIG_DM_SPI, drop NODM variant
From: Ivan Morozko
There is no reason to have a separate and highly restricted version of
spi-mem driver for NODM case, it's quite easily fix DM based driver
version and use it for all cases.
Signed-off-by: Ivan Morozko
Reviewed-by: Mikhail Kshevetskiy
---
drivers/spi/Makefile | 3 +-
drivers/spi/spi-mem-nodm.c | 107 -
drivers/spi/spi-mem.c | 37 -
include/spi.h | 1 +
4 files changed, 26 insertions(+), 122 deletions(-)
delete mode 100644 drivers/spi/spi-mem-nodm.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 54881a7412..6dff4eed83 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -8,12 +8,11 @@ ifdef CONFIG_DM_SPI
obj-y += spi-uclass.o
obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
obj-$(CONFIG_SOFT_SPI) += soft_spi.o
-obj-$(CONFIG_SPI_MEM) += spi-mem.o
obj-$(CONFIG_TI_QSPI) += ti_qspi.o
else
obj-y += spi.o
-obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
endif
+obj-$(CONFIG_SPI_MEM) += spi-mem.o
obj-$(CONFIG_ALTERA_SPI) += altera_spi.o
obj-$(CONFIG_ATH79_SPI) += ath79_spi.o
diff --git a/drivers/spi/spi-mem-nodm.c b/drivers/spi/spi-mem-nodm.c
deleted file mode 100644
index 765f05fe54..00
--- a/drivers/spi/spi-mem-nodm.c
+++ /dev/null
@@ -1,107 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
- */
-
-#include
-#include
-#include
-#include
-
-int spi_mem_exec_op(struct spi_slave *slave,
- const struct spi_mem_op *op)
-{
- unsigned int pos = 0;
- const u8 *tx_buf = NULL;
- u8 *rx_buf = NULL;
- u8 *op_buf;
- int op_len;
- u32 flag;
- int ret;
- int i;
-
- if (op->data.nbytes) {
- if (op->data.dir == SPI_MEM_DATA_IN)
- rx_buf = op->data.buf.in;
- else
- tx_buf = op->data.buf.out;
- }
-
- op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
- op_buf = calloc(1, op_len);
-
- ret = spi_claim_bus(slave);
- if (ret < 0)
- return ret;
-
- op_buf[pos++] = op->cmd.opcode;
-
- if (op->addr.nbytes) {
- for (i = 0; i < op->addr.nbytes; i++)
- op_buf[pos + i] = op->addr.val >>
- (8 * (op->addr.nbytes - i - 1));
-
- pos += op->addr.nbytes;
- }
-
- if (op->dummy.nbytes)
- memset(op_buf + pos, 0xff, op->dummy.nbytes);
-
- /* 1st transfer: opcode + address + dummy cycles */
- flag = SPI_XFER_BEGIN;
- /* Make sure to set END bit if no tx or rx data messages follow */
- if (!tx_buf && !rx_buf)
- flag |= SPI_XFER_END;
-
- ret = spi_xfer(slave, op_len * 8, op_buf, NULL, flag);
- if (ret)
- return ret;
-
- /* 2nd transfer: rx or tx data path */
- if (tx_buf || rx_buf) {
- ret = spi_xfer(slave, op->data.nbytes * 8, tx_buf,
- rx_buf, SPI_XFER_END);
- if (ret)
- return ret;
- }
-
- spi_release_bus(slave);
-
- for (i = 0; i < pos; i++)
- debug("%02x ", op_buf[i]);
- debug("| [%dB %s] ",
- tx_buf || rx_buf ? op->data.nbytes : 0,
- tx_buf || rx_buf ? (tx_buf ? "out" : "in") : "-");
- for (i = 0; i < op->data.nbytes; i++)
- debug("%02x ", tx_buf ? tx_buf[i] : rx_buf[i]);
- debug("[ret %d]\n", ret);
-
- free(op_buf);
-
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
-int spi_mem_adjust_op_size(struct spi_slave *slave,
- struct spi_mem_op *op)
-{
- unsigned int len;
-
- len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
- if (slave->max_write_size && len > slave->max_write_size)
- return -EINVAL;
-
- if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size)
- op->data.nbytes = min(op->data.nbytes,
- slave->max_read_size);
- else if (slave->max_write_size)
- op->data.nbytes = min(op->data.nbytes,
- slave->max_write_size - len);
-
- if (!op->data.nbytes)
- return -EINVAL;
-
- return 0;
-}
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index d344701aeb..e4544edaad 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -105,6 +105,19 @@ void spi_controller_dma_unmap_mem_op_data(struct
spi_controller *ctlr,
EXPORT_SYMBOL_GPL(spi_controller_dma_unmap_mem_op_data);
#endif /* __UBOOT__ */
+static inline
+struct spi_controller_mem_ops *spi_get_mem_ops(struct spi_slave *slave)
+{
+#ifdef CONFIG_DM_SPI
+ struct udevice *bus = slave->dev->parent;
+ struct dm_spi_ops *ops = spi_get_ops(bus);
+
+ return
Re: [PATCH v5 4/4] usb: xhci: Add reset controller support
On 6/22/20 5:30 PM, Nicolas Saenz Julienne wrote:
[...]
> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> index 1170c0ac69..7d34103fd5 100644
> --- a/include/usb/xhci.h
> +++ b/include/usb/xhci.h
> @@ -16,6 +16,7 @@
> #ifndef HOST_XHCI_H_
> #define HOST_XHCI_H_
>
> +#include
> #include
> #include
> #include
> @@ -1209,6 +1210,7 @@ struct xhci_ctrl {
> #if CONFIG_IS_ENABLED(DM_USB)
> struct udevice *dev;
> #endif
> + struct reset_ctl reset;
Should all this reset logic be protected by if CONFIG_IS_ENABLED(DM_RESET) ?
Otherwise the series looks good to me, thanks.
[PATCH v5 2/4] reset: Add Raspberry Pi 4 firmware reset controller
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/reset/Kconfig | 10
drivers/reset/Makefile| 1 +
drivers/reset/reset-raspberrypi.c | 60 +++
.../reset/raspberrypi,firmware-reset.h| 13
4 files changed, 84 insertions(+)
create mode 100644 drivers/reset/reset-raspberrypi.c
create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 88d3be1593..d02c1522e5 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -148,4 +148,14 @@ config RESET_IMX7
help
Support for reset controller on i.MX7/8 SoCs.
+config RESET_RASPBERRYPI
+ bool "Raspberry Pi 4 Firmware Reset Controller Driver"
+ depends on DM_RESET && ARCH_BCM283X
+ default USB_XHCI_PCI
+ help
+ Raspberry Pi 4's co-processor controls some of the board's HW
+ initialization process, but it's up to Linux to trigger it when
+ relevant. This driver provides a reset controller capable of
+ interfacing with RPi4's co-processor and model these firmware
+ initialization routines as reset lines.
endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 0a044d5d8c..be54dae725 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o
obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o
obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
+obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
diff --git a/drivers/reset/reset-raspberrypi.c
b/drivers/reset/reset-raspberrypi.c
new file mode 100644
index 00..e2d284e5ac
--- /dev/null
+++ b/drivers/reset/reset-raspberrypi.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Raspberry Pi 4 firmware reset driver
+ *
+ * Copyright (C) 2020 Nicolas Saenz Julienne
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int raspberrypi_reset_request(struct reset_ctl *reset_ctl)
+{
+ if (reset_ctl->id >= RASPBERRYPI_FIRMWARE_RESET_NUM_IDS)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int raspberrypi_reset_free(struct reset_ctl *reset_ctl)
+{
+ return 0;
+}
+
+static int raspberrypi_reset_assert(struct reset_ctl *reset_ctl)
+{
+ switch (reset_ctl->id) {
+ case RASPBERRYPI_FIRMWARE_RESET_ID_USB:
+ bcm2711_notify_vl805_reset();
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int raspberrypi_reset_deassert(struct reset_ctl *reset_ctl)
+{
+ return 0;
+}
+
+struct reset_ops raspberrypi_reset_ops = {
+ .request = raspberrypi_reset_request,
+ .rfree = raspberrypi_reset_free,
+ .rst_assert = raspberrypi_reset_assert,
+ .rst_deassert = raspberrypi_reset_deassert,
+};
+
+static const struct udevice_id raspberrypi_reset_ids[] = {
+ { .compatible = "raspberrypi,firmware-reset" },
+ { }
+};
+
+U_BOOT_DRIVER(raspberrypi_reset) = {
+ .name = "raspberrypi-reset",
+ .id = UCLASS_RESET,
+ .of_match = raspberrypi_reset_ids,
+ .ops = _reset_ops,
+};
+
diff --git a/include/dt-bindings/reset/raspberrypi,firmware-reset.h
b/include/dt-bindings/reset/raspberrypi,firmware-reset.h
new file mode 100644
index 00..1a4f4c7927
--- /dev/null
+++ b/include/dt-bindings/reset/raspberrypi,firmware-reset.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_RESET_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_RESET_H
+
+#define RASPBERRYPI_FIRMWARE_RESET_ID_USB 0
+#define RASPBERRYPI_FIRMWARE_RESET_NUM_IDS 1
+
+#endif
--
2.27.0
[PATCH v5 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware
Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
loaded explicitly. Earlier versions didn't need that as they where using
an EEPROM for that purpose. This series takes care of setting up the
relevant infrastructure and run the firmware loading routine at the
right moment.
Note that this builds on top of Sylwester Nawrocki's "USB host support
for Raspberry Pi 4 board" series.
This also depends on a DT/bindings patch available on the linux-mailing lists:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html
Here is the relevant bit for reference/discussion:
{
pci@1,0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
reg = <0 0 0 0 0>;
usb@1,0 {
reg = <0x1 0 0 0 0>;
resets = <
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
};
};
};
---
Changes since v4:
- Correct DT PCI topology, I separated the root bridge and controller
DT nodes
- Get rid of PCI core patch as not needed with correct DT PCI topology
- Move reset support to xchi core
Changes since v3:
- Use reset controller
Changes since v2:
- Correct comment on patch #1
- Address Matthias' comments
Changes since v1:
- Rename function
- Use callback in xhci-pci.c
Nicolas Saenz Julienne (4):
arm: rpi: Add function to trigger VL805's firmware load
reset: Add Raspberry Pi 4 firmware reset controller
configs: Enable support for reset controllers on RPi4
usb: xhci: Add reset controller support
arch/arm/mach-bcm283x/include/mach/mbox.h | 13
arch/arm/mach-bcm283x/include/mach/msg.h | 7 +++
arch/arm/mach-bcm283x/msg.c | 46 ++
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 1 +
drivers/reset/Kconfig | 10
drivers/reset/Makefile| 1 +
drivers/reset/reset-raspberrypi.c | 60 +++
drivers/usb/host/xhci-mem.c | 2 +
drivers/usb/host/xhci.c | 33 ++
.../reset/raspberrypi,firmware-reset.h| 13
include/usb/xhci.h| 2 +
13 files changed, 190 insertions(+)
create mode 100644 drivers/reset/reset-raspberrypi.c
create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
--
2.27.0
[PATCH v5 1/4] arm: rpi: Add function to trigger VL805's firmware load
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- Rename function so it's not mistaken with regular firmware loading
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
arch/arm/mach-bcm283x/include/mach/msg.h | 7
arch/arm/mach-bcm283x/msg.c | 46 +++
3 files changed, 66 insertions(+)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 60e226ce1d..2ae2d3d97c 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -491,6 +491,19 @@ struct bcm2835_mbox_tag_set_palette {
} body;
};
+#define BCM2835_MBOX_TAG_NOTIFY_XHCI_RESET 0x00030058
+
+struct bcm2835_mbox_tag_pci_dev_addr {
+ struct bcm2835_mbox_tag_hdr tag_hdr;
+ union {
+ struct {
+ u32 dev_addr;
+ } req;
+ struct {
+ } resp;
+ } body;
+};
+
/*
* Pass a raw u32 message to the VC, and receive a raw u32 back.
*
diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h
b/arch/arm/mach-bcm283x/include/mach/msg.h
index 4afb08631b..e45c1bf010 100644
--- a/arch/arm/mach-bcm283x/include/mach/msg.h
+++ b/arch/arm/mach-bcm283x/include/mach/msg.h
@@ -48,4 +48,11 @@ int bcm2835_set_video_params(int *widthp, int *heightp, int
depth_bpp,
int pixel_order, int alpha_mode, ulong *fb_basep,
ulong *fb_sizep, int *pitchp);
+/**
+ * bcm2711_load_vl805_firmware() - get vl805's firmware loaded
+ *
+ * @return 0 if OK, -EIO on error
+ */
+int bcm2711_notify_vl805_reset(void);
+
#endif
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 94b75283f8..347aece3cd 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
struct msg_set_power_state {
struct bcm2835_mbox_hdr hdr;
@@ -40,6 +41,12 @@ struct msg_setup {
u32 end_tag;
};
+struct msg_notify_vl805_reset {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_pci_dev_addr dev_addr;
+ u32 end_tag;
+};
+
int bcm2835_power_on_module(u32 module)
{
ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1);
@@ -151,3 +158,42 @@ int bcm2835_set_video_params(int *widthp, int *heightp,
int depth_bpp,
return 0;
}
+
+/*
+ * On the Raspberry Pi 4, after a PCI reset, VL805's (the xHCI chip) firmware
+ * may either be loaded directly from an EEPROM or, if not present, by the
+ * SoC's VideoCore. This informs VideoCore that VL805 needs its firmware
+ * loaded.
+ */
+int bcm2711_notify_vl805_reset(void)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset,
+msg_notify_vl805_reset, 1);
+ int ret;
+
+ BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset);
+ BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,
+ NOTIFY_XHCI_RESET);
+
+ /*
+* The pci device address is expected like this:
+*
+* PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12
+*
+* But since RPi4's PCIe setup is hardwired, we know the address in
+* advance.
+*/
+ msg_notify_vl805_reset->dev_addr.body.req.dev_addr = 0x10;
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
+_notify_vl805_reset->hdr);
+ if (ret) {
+ printf("bcm2711: Faild to load vl805's firmware, %d\n", ret);
+ return -EIO;
+ }
+
+ udelay(200);
+
+ return 0;
+}
+
--
2.27.0
[PATCH v5 3/4] configs: Enable support for reset controllers on RPi4
This is required in order to access the reset controller used to initialize the board's xHCI chip. Signed-off-by: Nicolas Saenz Julienne --- configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index b0797373b5..00c8d963ab 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -35,6 +35,7 @@ CONFIG_DM_PCI=y CONFIG_PCI_BRCMSTB=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set +CONFIG_DM_RESET=y # CONFIG_REQUIRE_SERIAL_CONSOLE is not set CONFIG_USB=y CONFIG_DM_USB=y diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 932b768164..c73eccb61c 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -35,6 +35,7 @@ CONFIG_DM_PCI=y CONFIG_PCI_BRCMSTB=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set +CONFIG_DM_RESET=y # CONFIG_REQUIRE_SERIAL_CONSOLE is not set CONFIG_USB=y CONFIG_DM_USB=y diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 855afcf1cf..800b51e6f5 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -32,6 +32,7 @@ CONFIG_DM_PCI=y CONFIG_PCI_BRCMSTB=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set +CONFIG_DM_RESET=y # CONFIG_REQUIRE_SERIAL_CONSOLE is not set CONFIG_USB=y CONFIG_DM_USB=y -- 2.27.0
[PATCH v5 4/4] usb: xhci: Add reset controller support
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Move reset support to xchi core
drivers/usb/host/xhci-mem.c | 2 ++
drivers/usb/host/xhci.c | 33 +
include/usb/xhci.h | 2 ++
3 files changed, 37 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f446520528..108f4bd8cf 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -180,6 +180,8 @@ void xhci_cleanup(struct xhci_ctrl *ctrl)
xhci_free_virt_devices(ctrl);
free(ctrl->erst.entries);
free(ctrl->dcbaa);
+ if (reset_valid(>reset))
+ reset_free(>reset);
memset(ctrl, '\0', sizeof(struct xhci_ctrl));
}
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ebd2954571..03b41cc855 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -190,6 +190,35 @@ static int xhci_start(struct xhci_hcor *hcor)
return ret;
}
+/**
+ * Resets XHCI Hardware
+ *
+ * @param ctrl pointer to host controller
+ * @return 0 if OK, or a negative error code.
+ */
+static int xhci_reset_hw(struct xhci_ctrl *ctrl)
+{
+ int ret;
+
+ ret = reset_get_by_index(ctrl->dev, 0, >reset);
+ if (ret && ret != -ENOENT) {
+ dev_err(ctrl->dev, "failed to get reset\n");
+ return ret;
+ }
+
+ if (reset_valid(>reset)) {
+ ret = reset_assert(>reset);
+ if (ret)
+ return ret;
+
+ ret = reset_deassert(>reset);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* Resets the XHCI Controller
*
@@ -1508,6 +1537,10 @@ int xhci_register(struct udevice *dev, struct xhci_hccr
*hccr,
ctrl->dev = dev;
+ ret = xhci_reset_hw(ctrl);
+ if (ret)
+ goto err;
+
/*
* XHCI needs to issue a Address device command to setup
* proper device context structures, before it can interact
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 1170c0ac69..7d34103fd5 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -16,6 +16,7 @@
#ifndef HOST_XHCI_H_
#define HOST_XHCI_H_
+#include
#include
#include
#include
@@ -1209,6 +1210,7 @@ struct xhci_ctrl {
#if CONFIG_IS_ENABLED(DM_USB)
struct udevice *dev;
#endif
+ struct reset_ctl reset;
struct xhci_hccr *hccr; /* R/O registers, not need for volatile */
struct xhci_hcor *hcor;
struct xhci_doorbell_array *dba;
--
2.27.0
Re: [RFC 0/4] drivers: footprint reduction proposal
Hi Tom, On 22/6/20 11:20, Tom Rini wrote: On Mon, Jun 22, 2020 at 11:12:40AM -0300, Walter Lozano wrote: Hi Tom, On 19/6/20 18:48, Tom Rini wrote: On Fri, Jun 19, 2020 at 06:11:36PM -0300, Walter Lozano wrote: Based on several reports and discussions it is clear that U-Boot's footprint is always a concern, and any kind of reduction is an improvement. This series is a proposal to help reducing the footprint by parsing information provided in DT and drivers in different ways and adding additional intelligence to dtoc. The current version implements the basic functionality in dtoc but this is no fully integrated, however it will allow us to discuss this approach. Firstly, based on the compatible strings found in drivers, include only DT nodes which are supported by any driver present in U-Boot. Secondly, generate struct udevice_id entries only for nodes present in DT, which will allow to avoid including additional data. These are the first steps for further improvements as proposed in the specific patches in this series. This work is based on the work of Simon Glass present in [1] which adds support to dtoc for parsing compatible strings. [1] https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working I applied this series on top of the above tree, but there's no rule for so is something missing? Thanks! Thanks for taking the time to check this RFC. As you pointed, the Makefile needs to be tweaked in order to be able to run a build, that is what I meant by "not fully integrated", also some additional stuff are missing. However, I thought that sending this RFC explaining the idea will be nice in order to confirm if the approaches proposed make sense for the community and at least the one to handle compatible strings is different from the linker list suggestion. I think I like the idea, but I need to give a build a spin and poke things harder. What do I need to do to manually have this build+link? Thanks! Well, I don't think this version will give you something to fully test, as there are several pieces missing, but the fact you think you like the idea is good starting point. Just to do some testing you can try Shrink a dtb with ./tools/dtoc/dtoc shrink -d u-boot.dtb this will shrink u-boot.dtb and create u-boot-shrink.dtb by only include nodes with compatible strings present in drivers Generate include/generated/compatible.h ./tools/dtoc/dtoc compatible -d u-boot.dtb -o include/generated/compatible.h this will generate compatible.h but the code does not yet support struct udevice_id with data in struct udevice_id and does not filter anything. I will continue working on these features but any early feedback is welcome. Regards,
[PATCH v1] imx: mx7: fix DDRC size in A7-M4 mapping table
From: Igor Opaniuk
According to i.MX 7Solo Applications Processor Reference Manual,
2.1.3 Cortex-M4 Memory Map, M4 can address only 1536MB of DDRC
(Start Address: 0x8000_; End Address: 0xDFFF_).
Correct DDRC size to 0x6000.
Fixes: c0f037f6("mach-imx: bootaux: elf firmware support")
Signed-off-by: Igor Opaniuk
---
arch/arm/mach-imx/mx7/soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 798fe74..9cb61f5 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -218,7 +218,7 @@ const struct rproc_att hostmap[] = {
{ 0x0094, 0x0094, 0x2 }, /* OCRAM_PXP */
{ 0x2024, 0x0094, 0x2 }, /* OCRAM_PXP */
{ 0x1000, 0x8000, 0x0fff }, /* DDR Code alias */
- { 0x8000, 0x8000, 0xe000 }, /* DDRC */
+ { 0x8000, 0x8000, 0x6000 }, /* DDRC */
{ /* sentinel */ }
};
#endif
--
2.7.4
Re: [PATCH v2 5/6] crypto/fsl: instantiate the RNG with prediciton resistance
On 6/19/2020 10:02 PM, Michael Walle wrote:
> Am 2020-06-19 18:54, schrieb Horia Geantă:
>> On 6/19/2020 7:37 PM, Horia Geanta wrote:
>>> On 6/17/2020 11:48 PM, Michael Walle wrote:
Am 2020-06-17 21:15, schrieb Horia Geantă:
> On 6/4/2020 6:48 PM, Michael Walle wrote:
>> +
>> +desc = memalign(ARCH_DMA_MINALIGN, desc_size);
>> +if (!desc) {
>> +debug("cannot allocate RNG init descriptor memory\n");
>> +return -ENOMEM;
>> +}
>> +
>> +for (sh_idx = 0; sh_idx < RNG4_MAX_HANDLES; sh_idx++) {
>> +/*
>> + * If the corresponding bit is set, then it means the
>> state
>> + * handle was initialized by us, and thus it needs to be
>> + * deinitialized as well
>> + */
>> +
>> +if (state_handle_mask & RDSTA_IF(sh_idx)) {
>> +/*
>> + * Create the descriptor for deinstantating
>> this state
>> + * handle.
>> + */
>> +inline_cnstr_jobdesc_rng_deinstantiation(desc,
>> sh_idx);
>> +flush_dcache_range((unsigned long)desc,
>> + (unsigned long)desc +
>> desc_size);
> Shouldn't this be roundup(desc_size, ARCH_DMA_MINALIGN) instead of
> desc_size?
I've seen the same idioms sometimes, but it wasn't clear to me why
that
would
be needed; the hardware only uses the desc_size, right?
>>> Yes, HW will use only [desc, desc + desc_size].
>>>
>>> I think this is needed to avoid cacheline sharing issues
>>> on non-coherent platforms: CPU needs to make sure a larger area
>>> is written back to memory and corresponding cache lines are
>>> invalidated.
>>>
>>> Looking at flush_dcache_range() implementation, it does its own
>>> rounding,
>>> based on CTR_EL0[DminLine] - "smallest data cache line size".
>>> I guess this value might be smaller than ARCH_DMA_MINALIGN,
>>> hence the explicit rounding to ARCH_DMA_MINALIGN is needed.
>>>
>> Btw, I think
>> desc = memalign(ARCH_DMA_MINALIGN, desc_size);
>> needs to be replaced with
>> desc = malloc_cache_aligned(desc_size);
>
> But then the rounding is not needed, right? I mean there can't
> be any other malloc() which might allocate memory in the same
> cache line.
>
Yes, in this case the rounding is no longer needed.
Horia
Re: [RFC 0/4] drivers: footprint reduction proposal
On Mon, Jun 22, 2020 at 11:12:40AM -0300, Walter Lozano wrote: > Hi Tom, > > On 19/6/20 18:48, Tom Rini wrote: > > On Fri, Jun 19, 2020 at 06:11:36PM -0300, Walter Lozano wrote: > > > > > Based on several reports and discussions it is clear that U-Boot's > > > footprint is always a concern, and any kind of reduction is an > > > improvement. > > > > > > This series is a proposal to help reducing the footprint by parsing > > > information provided in DT and drivers in different ways and adding > > > additional intelligence to dtoc. The current version implements the basic > > > functionality in dtoc but this is no fully integrated, however it will > > > allow > > > us to discuss this approach. > > > > > > Firstly, based on the compatible strings found in drivers, include only > > > DT nodes > > > which are supported by any driver present in U-Boot. > > > > > > Secondly, generate struct udevice_id entries only for nodes present in DT, > > > which will allow to avoid including additional data. > > > > > > These are the first steps for further improvements as proposed in the > > > specific > > > patches in this series. > > > > > > This work is based on the work of Simon Glass present in [1] which adds > > > support to dtoc for parsing compatible strings. > > > > > > [1] https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working > > I applied this series on top of the above tree, but there's no rule for > > so is something missing? Thanks! > > > Thanks for taking the time to check this RFC. > > As you pointed, the Makefile needs to be tweaked in order to be able to run > a build, that is what I meant by "not fully integrated", also some > additional stuff are missing. However, I thought that sending this RFC > explaining the idea will be nice in order to confirm if the approaches > proposed make sense for the community and at least the one to handle > compatible strings is different from the linker list suggestion. I think I like the idea, but I need to give a build a spin and poke things harder. What do I need to do to manually have this build+link? Thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC 0/4] drivers: footprint reduction proposal
Hi Tom, On 19/6/20 18:48, Tom Rini wrote: On Fri, Jun 19, 2020 at 06:11:36PM -0300, Walter Lozano wrote: Based on several reports and discussions it is clear that U-Boot's footprint is always a concern, and any kind of reduction is an improvement. This series is a proposal to help reducing the footprint by parsing information provided in DT and drivers in different ways and adding additional intelligence to dtoc. The current version implements the basic functionality in dtoc but this is no fully integrated, however it will allow us to discuss this approach. Firstly, based on the compatible strings found in drivers, include only DT nodes which are supported by any driver present in U-Boot. Secondly, generate struct udevice_id entries only for nodes present in DT, which will allow to avoid including additional data. These are the first steps for further improvements as proposed in the specific patches in this series. This work is based on the work of Simon Glass present in [1] which adds support to dtoc for parsing compatible strings. [1] https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working I applied this series on top of the above tree, but there's no rule for so is something missing? Thanks! Thanks for taking the time to check this RFC. As you pointed, the Makefile needs to be tweaked in order to be able to run a build, that is what I meant by "not fully integrated", also some additional stuff are missing. However, I thought that sending this RFC explaining the idea will be nice in order to confirm if the approaches proposed make sense for the community and at least the one to handle compatible strings is different from the linker list suggestion. Regards, Walter
Re: Please pull u-boot-dm/next
On Mon, Jun 22, 2020 at 10:01:09PM +0800, Bin Meng wrote: > Hi Tom, > > On Mon, Jun 22, 2020 at 9:58 PM Tom Rini wrote: > > > > On Mon, Jun 22, 2020 at 09:43:57PM +0800, Bin Meng wrote: > > > Hi Tom, > > > > > > On Mon, Jun 15, 2020 at 12:00 AM Tom Rini wrote: > > > > > > > > On Fri, Jun 12, 2020 at 09:17:28PM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > This is for -next > > > > > > > > > > But I based it on master to avoid pulling in other people's commits. > > > > > I hope > > > > > that works OK. > > > > > > > > > > > > > > > The following changes since commit > > > > > be79009f3b9bbdbce283e67a865121e576d790ea: > > > > > > > > > > Merge tag 'u-boot-imx-20200609' of > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-09 > > > > > 09:17:24 > > > > > -0400) > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-pull-12jun20 > > > > > > > > > > for you to fetch changes up to > > > > > cea8f2c995b9d87af6ef42f967402e1c8a3506db: > > > > > > > > > > doc: driver-model: fix typo in design.rst (2020-06-11 20:52:11 > > > > > -0600) > > > > > > > > > > > > > Applied to u-boot/master, thanks! > > > > > > I did not find my 2 patches are in u-boot/master. Anything wrong? > > > > > > Bin Meng (2): > > > fdtdec: Fix the types of addr and size in > > > fdtdec_add_reserved_memory() > > > fdtdec: Honor #address-cells and #size-cells in > > > fdtdec_add_reserved_memory() > > > > Yes, sorry, I hit the wrong keys. This is in -next and not master as > > Simon noted this is a PR for -next. > > Okay, good to know. I was thinking these 2 are bug fixes, and should > be against this release, not next :) Are they regression fixes too? Or just bug fixes? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 8/8] board: ns3: start sp805 watchdog service
On Mon, Jun 22, 2020 at 3:08 PM Stefan Roese wrote: > > On 22.06.20 11:33, Rayagonda Kokatanur wrote: > > > > >> Sure it takes time to update images. But all this should be possible > >> with an actively serviced watchdog while still running in U-Boot. > >> This is why we have all these WATCHDOG_RESET() calls sprinkled all over > >> the system. If some code paths are missing such WDT triggering, then we > >> should find and fix them. > > > > One more issue we are facing is, > > So did you work on fixing some of he missing WDT trigger calls? > >>> > >>> No, this issue we used to face before this patch. > >>> > >>> So you are suggesting to use WATCHDOF_RESET instead of stopping and > >>> starting the wdt. > >>> WATCHDOG_RESET will take care of resetting wdt in uboot. > >> > >> Yes. > > Thank you. > > > >> > >>> And it won't > >>> lead to system reboot while running any test (ex-i2c read/write test) > >>> in uboot or debugging any issue in uboot ? > >> > >> Correct. The U-Boot code is "sprinkled" with these calls, easpecially > >> ion places where looping might take some time (polling for input etc). > >> So the WD timer is triggered / services via this WATCHDOG_RESET call > >> to keep U-Boot running even with an active watchdog. > > > > What is the motivation to start watchdog service during uboot and keep > > on resetting it. > > Its similar to why this is done in the OS. There might be execution > paths, where the bootloader might crash or hang (loading an image > from some device etc). And this WD behavior makes sure, that the > system does not hang but reboots in such cases. Thank you Stefan for the detailed explanation. Best regards, Rayagonda > > Thanks, > Stefan
Re: Please pull u-boot-dm/next
Hi Tom, On Mon, Jun 22, 2020 at 9:58 PM Tom Rini wrote: > > On Mon, Jun 22, 2020 at 09:43:57PM +0800, Bin Meng wrote: > > Hi Tom, > > > > On Mon, Jun 15, 2020 at 12:00 AM Tom Rini wrote: > > > > > > On Fri, Jun 12, 2020 at 09:17:28PM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > This is for -next > > > > > > > > But I based it on master to avoid pulling in other people's commits. I > > > > hope > > > > that works OK. > > > > > > > > > > > > The following changes since commit > > > > be79009f3b9bbdbce283e67a865121e576d790ea: > > > > > > > > Merge tag 'u-boot-imx-20200609' of > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-09 09:17:24 > > > > -0400) > > > > > > > > are available in the Git repository at: > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-pull-12jun20 > > > > > > > > for you to fetch changes up to cea8f2c995b9d87af6ef42f967402e1c8a3506db: > > > > > > > > doc: driver-model: fix typo in design.rst (2020-06-11 20:52:11 -0600) > > > > > > > > > > Applied to u-boot/master, thanks! > > > > I did not find my 2 patches are in u-boot/master. Anything wrong? > > > > Bin Meng (2): > > fdtdec: Fix the types of addr and size in fdtdec_add_reserved_memory() > > fdtdec: Honor #address-cells and #size-cells in > > fdtdec_add_reserved_memory() > > Yes, sorry, I hit the wrong keys. This is in -next and not master as > Simon noted this is a PR for -next. Okay, good to know. I was thinking these 2 are bug fixes, and should be against this release, not next :) Regards, Bin
Re: [PATCH v3 6/6] sifive: fu540: Enable SF distro bootcmd
On Fri, Jun 5, 2020 at 4:41 AM Jagan Teki wrote: > > Enable SPI flash(SF) distro boot command in Sifive FU540. > > This distro boot will read the boot script at specific > location at the flash and start sourcing the same. > > Included the SF device at the last of the target devices > list since all the rest of the devices on the list have > more possibility to boot the distribution due to the > size of the SPI flash is concern. > > Signed-off-by: Jagan Teki > --- > Changes for v3: > - none > > include/configs/sifive-fu540.h | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: Please pull u-boot-dm/next
On Mon, Jun 22, 2020 at 09:43:57PM +0800, Bin Meng wrote: > Hi Tom, > > On Mon, Jun 15, 2020 at 12:00 AM Tom Rini wrote: > > > > On Fri, Jun 12, 2020 at 09:17:28PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > This is for -next > > > > > > But I based it on master to avoid pulling in other people's commits. I > > > hope > > > that works OK. > > > > > > > > > The following changes since commit > > > be79009f3b9bbdbce283e67a865121e576d790ea: > > > > > > Merge tag 'u-boot-imx-20200609' of > > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-09 09:17:24 > > > -0400) > > > > > > are available in the Git repository at: > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-pull-12jun20 > > > > > > for you to fetch changes up to cea8f2c995b9d87af6ef42f967402e1c8a3506db: > > > > > > doc: driver-model: fix typo in design.rst (2020-06-11 20:52:11 -0600) > > > > > > > Applied to u-boot/master, thanks! > > I did not find my 2 patches are in u-boot/master. Anything wrong? > > Bin Meng (2): > fdtdec: Fix the types of addr and size in fdtdec_add_reserved_memory() > fdtdec: Honor #address-cells and #size-cells in > fdtdec_add_reserved_memory() Yes, sorry, I hit the wrong keys. This is in -next and not master as Simon noted this is a PR for -next. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 3/6] env: Enable SPI flash env for SiFive FU540
On Mon, Jun 22, 2020 at 9:55 PM Bin Meng wrote: > > On Fri, Jun 5, 2020 at 4:41 AM Jagan Teki wrote: > > > > SPI flash device on HiFive Unleashed has 32MiB Size. > > > > This patch add SPI flash environment after U-Boot proper Forgot to mention a nit: add -> adds > > partition with a size of 128KiB. > > > > SPI flash partition layout(32MiB): > > 0 - 34 : reserved for GPT header > >35 - 39 : unused > >40 - 2087: loader1 (SPL, FSBL) > > 2088 - 10279 : loader2 (U-Boot proper, U-Boot) > > 10280 - 10535 : environment > > 10536 - 65494 : rootfs > > 65528 - 65536 : distro script > > > > Note: the loader1 must start from 40th sector even though > > there are 6 free sectors prior since 40th sector is nearest > > flash sector boundary. > > > > Signed-off-by: Jagan Teki > > --- > > Changes for v3: > > - fixed build issues > > > > arch/riscv/cpu/fu540/Kconfig | 13 + > > 1 file changed, 13 insertions(+) > > > > Reviewed-by: Bin Meng > Tested-by: Bin Meng
Re: [PATCH v3 5/6] sifive: fu540: Add boot flash script offset, size
On Fri, Jun 5, 2020 at 4:41 AM Jagan Teki wrote: > > HiFive-Unleashed-A00 has SPI flash with 32MiB size. > So, let's use the script offset at the end of 4K. > This way it cannot overlap any offsets being used > by software components in flash layout. > > So, SF distrocmd will pick the script at desired > script address and run. > > Signed-off-by: Jagan Teki > --- > Changes for v3: > - none > > include/configs/sifive-fu540.h | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 4/6] sifive: fu540: Mark the default env as SPI flash
On Fri, Jun 5, 2020 at 4:41 AM Jagan Teki wrote: > > Mark the default U-Boot environment as SPI flash since > this is an on board flash device. > > Reviewed-by: Bin Meng > Signed-off-by: Jagan Teki > --- > Changes for v3: > - none > > board/sifive/fu540/Kconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: [PATCH v3 3/6] env: Enable SPI flash env for SiFive FU540
On Fri, Jun 5, 2020 at 4:41 AM Jagan Teki wrote: > > SPI flash device on HiFive Unleashed has 32MiB Size. > > This patch add SPI flash environment after U-Boot proper > partition with a size of 128KiB. > > SPI flash partition layout(32MiB): > 0 - 34 : reserved for GPT header >35 - 39 : unused >40 - 2087: loader1 (SPL, FSBL) > 2088 - 10279 : loader2 (U-Boot proper, U-Boot) > 10280 - 10535 : environment > 10536 - 65494 : rootfs > 65528 - 65536 : distro script > > Note: the loader1 must start from 40th sector even though > there are 6 free sectors prior since 40th sector is nearest > flash sector boundary. > > Signed-off-by: Jagan Teki > --- > Changes for v3: > - fixed build issues > > arch/riscv/cpu/fu540/Kconfig | 13 + > 1 file changed, 13 insertions(+) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: [PATCH v3 2/6] sifive: fu540: Add Booting from SPI
On Fri, Jun 5, 2020 at 4:40 AM Jagan Teki wrote:
>
> Add booting from SPI for SiFive Unleashed board.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v3:
> - updated based on master
>
> arch/riscv/cpu/fu540/Kconfig | 2 +
> .../dts/hifive-unleashed-a00-u-boot.dtsi | 12 ++
> configs/sifive_fu540_defconfig| 4 ++
> doc/board/sifive/fu540.rst| 41 +++
> 4 files changed, 59 insertions(+)
>
> diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
> index e9302e87c0..7a813a9ac8 100644
> --- a/arch/riscv/cpu/fu540/Kconfig
> +++ b/arch/riscv/cpu/fu540/Kconfig
> @@ -5,6 +5,8 @@
> config SIFIVE_FU540
> bool
> select ARCH_EARLY_INIT_R
> + imply BOARD
> + imply BOARD_FU540
These 2 are not needed in v3.
> imply CPU
> imply CPU_RISCV
> imply RISCV_TIMER
> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> index 303806454b..4b2b242deb 100644
> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> @@ -12,6 +12,10 @@
> spi2 =
> };
>
> + config {
> + u-boot,spl-payload-offset = <0x105000>; /* loader2 @1044KB */
> + };
> +
> hfclk {
> u-boot,dm-spl;
> };
> @@ -22,6 +26,14 @@
>
> };
>
> + {
> + u-boot,dm-spl;
> +
> + flash@0 {
> + u-boot,dm-spl;
> + };
> +};
> +
> {
> mmc@0 {
> u-boot,dm-spl;
Other than above,
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Re: [PATCH v3 1/6] sifive: fu540: Add runtime boot mode detection
On Fri, Jun 5, 2020 at 4:40 AM Jagan Teki wrote: > > Add support to detect boot mode at runtime for > SiFive FU540 boards. > > Signed-off-by: Jagan Teki > --- > Changes for v3: > - new patch > > board/sifive/fu540/fu540.c | 25 +++-- > 1 file changed, 19 insertions(+), 6 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: Please pull u-boot-dm/next
Hi Tom, On Mon, Jun 15, 2020 at 12:00 AM Tom Rini wrote: > > On Fri, Jun 12, 2020 at 09:17:28PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > This is for -next > > > > But I based it on master to avoid pulling in other people's commits. I hope > > that works OK. > > > > > > The following changes since commit be79009f3b9bbdbce283e67a865121e576d790ea: > > > > Merge tag 'u-boot-imx-20200609' of > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-09 09:17:24 > > -0400) > > > > are available in the Git repository at: > > > > git://git.denx.de/u-boot-dm.git tags/dm-pull-12jun20 > > > > for you to fetch changes up to cea8f2c995b9d87af6ef42f967402e1c8a3506db: > > > > doc: driver-model: fix typo in design.rst (2020-06-11 20:52:11 -0600) > > > > Applied to u-boot/master, thanks! I did not find my 2 patches are in u-boot/master. Anything wrong? Bin Meng (2): fdtdec: Fix the types of addr and size in fdtdec_add_reserved_memory() fdtdec: Honor #address-cells and #size-cells in fdtdec_add_reserved_memory() Regards, Bin
[PATCH 2/4] mtd: spinand: Explicitly use MTD_OPS_RAW to write the bad block marker to OOB
From: Frieder Schrempf
When writing the bad block marker to the OOB area the access mode
should be set to MTD_OPS_RAW as it is done for reading the marker.
Currently this only works because req.mode is initialized to
MTD_OPS_PLACE_OOB (0) and spinand_write_to_cache_op() checks for
req.mode != MTD_OPS_AUTO_OOB.
Fix this by explicitly setting req.mode to MTD_OPS_RAW.
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Signed-off-by: Frieder Schrempf
Reviewed-by: Boris Brezillon
Signed-off-by: Miquel Raynal
Link:
https://lore.kernel.org/linux-mtd/20200218100432.32433-3-frieder.schre...@kontron.de
---
drivers/mtd/nand/spi/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 410ea2382d..c74a7b5ef3 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -708,6 +708,7 @@ static int spinand_markbad(struct nand_device *nand, const
struct nand_pos *pos)
.ooboffs = 0,
.ooblen = sizeof(marker),
.oobbuf.out = marker,
+ .mode = MTD_OPS_RAW,
};
int ret;
--
2.27.0
[PATCH 3/4] mtd: spinand: Do not erase the block before writing a bad block marker
From: Frieder Schrempf
Currently when marking a block, we use spinand_erase_op() to erase
the block before writing the marker to the OOB area. Doing so without
waiting for the operation to finish can lead to the marking failing
silently and no bad block marker being written to the flash.
In fact we don't need to do an erase at all before writing the BBM.
The ECC is disabled for raw accesses to the OOB data and we don't
need to work around any issues with chips reporting ECC errors as it
is known to be the case for raw NAND.
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Cc: sta...@vger.kernel.org
Signed-off-by: Frieder Schrempf
Reviewed-by: Boris Brezillon
Signed-off-by: Miquel Raynal
Link:
https://lore.kernel.org/linux-mtd/20200218100432.32433-4-frieder.schre...@kontron.de
---
drivers/mtd/nand/spi/core.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index c74a7b5ef3..e0ebd9c04b 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -712,19 +712,10 @@ static int spinand_markbad(struct nand_device *nand,
const struct nand_pos *pos)
};
int ret;
- /* Erase block before marking it bad. */
ret = spinand_select_target(spinand, pos->target);
if (ret)
return ret;
- ret = spinand_write_enable_op(spinand);
- if (ret)
- return ret;
-
- ret = spinand_erase_op(spinand, pos);
- if (ret)
- return ret;
-
return spinand_write_page(spinand, );
}
--
2.27.0
[PATCH 1/4] mtd: spinand: Stop using spinand->oobbuf for buffering bad block markers
From: Frieder Schrempf
For reading and writing the bad block markers, spinand->oobbuf is
currently used as a buffer for the marker bytes. During the
underlying read and write operations to actually get/set the content
of the OOB area, the content of spinand->oobbuf is reused and changed
by accessing it through spinand->oobbuf and/or spinand->databuf.
This is a flaw in the original design of the SPI NAND core and at the
latest from 13c15e07eedf ("mtd: spinand: Handle the case where
PROGRAM LOAD does not reset the cache") on, it results in not having
the bad block marker written at all, as the spinand->oobbuf is
cleared to 0xff after setting the marker bytes to zero.
To fix it, we now just store the two bytes for the marker on the
stack and let the read/write operations copy it from/to the page
buffer later.
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Cc: sta...@vger.kernel.org
Signed-off-by: Frieder Schrempf
Reviewed-by: Boris Brezillon
Signed-off-by: Miquel Raynal
Link:
https://lore.kernel.org/linux-mtd/20200218100432.32433-2-frieder.schre...@kontron.de
---
drivers/mtd/nand/spi/core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 93371fdde0..410ea2382d 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -655,16 +655,16 @@ static int spinand_mtd_write(struct mtd_info *mtd, loff_t
to,
static bool spinand_isbad(struct nand_device *nand, const struct nand_pos *pos)
{
struct spinand_device *spinand = nand_to_spinand(nand);
+ u8 marker[2] = { };
struct nand_page_io_req req = {
.pos = *pos,
- .ooblen = 2,
+ .ooblen = sizeof(marker),
.ooboffs = 0,
- .oobbuf.in = spinand->oobbuf,
+ .oobbuf.in = marker,
.mode = MTD_OPS_RAW,
};
int ret;
- memset(spinand->oobbuf, 0, 2);
ret = spinand_select_target(spinand, pos->target);
if (ret)
return ret;
@@ -673,7 +673,7 @@ static bool spinand_isbad(struct nand_device *nand, const
struct nand_pos *pos)
if (ret)
return ret;
- if (spinand->oobbuf[0] != 0xff || spinand->oobbuf[1] != 0xff)
+ if (marker[0] != 0xff || marker[1] != 0xff)
return true;
return false;
@@ -702,11 +702,12 @@ static int spinand_mtd_block_isbad(struct mtd_info *mtd,
loff_t offs)
static int spinand_markbad(struct nand_device *nand, const struct nand_pos
*pos)
{
struct spinand_device *spinand = nand_to_spinand(nand);
+ u8 marker[2] = { };
struct nand_page_io_req req = {
.pos = *pos,
.ooboffs = 0,
- .ooblen = 2,
- .oobbuf.out = spinand->oobbuf,
+ .ooblen = sizeof(marker),
+ .oobbuf.out = marker,
};
int ret;
@@ -723,7 +724,6 @@ static int spinand_markbad(struct nand_device *nand, const
struct nand_pos *pos)
if (ret)
return ret;
- memset(spinand->oobbuf, 0, 2);
return spinand_write_page(spinand, );
}
--
2.27.0
[PATCH 4/4] mtd: spinand: enable erasing of bad mtd blocks
U-Boot is able to erase bad mtd blocks on raw nand devices, but this
is not true for spinand flashes. Lets enable this feature for spinand
flashes as well. This is extemelly useful for flash testing.
Signed-off-by: Mikhail Kshevetskiy
---
drivers/mtd/nand/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index 6fbd24ba74..a39b4c4b30 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -130,10 +130,18 @@ EXPORT_SYMBOL_GPL(nanddev_isreserved);
*/
int nanddev_erase(struct nand_device *nand, const struct nand_pos *pos)
{
+ unsigned int entry;
+
if (nanddev_isbad(nand, pos) || nanddev_isreserved(nand, pos)) {
pr_warn("attempt to erase a bad/reserved block @%llx\n",
nanddev_pos_to_offs(nand, pos));
- return -EIO;
+ if (nanddev_isreserved(nand, pos))
+ return -EIO;
+
+ /* remove bad block from BBT */
+ entry = nanddev_bbt_pos_to_entry(nand, pos);
+ nanddev_bbt_set_block_status(nand, entry,
+NAND_BBT_BLOCK_STATUS_UNKNOWN);
}
return nand->ops->erase(nand, pos);
--
2.27.0
[PATCH] rockchip: rk3188: Fix back to BROM boot
Move the setting for noc remap out of SPL code. Changing
noc remap inside SPL results in breaking back to BROM
boot.
Fixes commit c14fe2a8e192 ("rockchip: rk3188: Move SoC
one time setting into arch_cpu_init()").
Signed-off-by: Alexander Kochetkov
---
arch/arm/mach-rockchip/rk3188/rk3188.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 1b012f7f67..4115f95d77 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -73,15 +73,32 @@ int arch_cpu_init(void)
BYPASSSEL_MASK | BYPASSDMEN_MASK,
1 << BYPASSSEL_SHIFT | 1 << BYPASSDMEN_SHIFT);
#endif
+ return 0;
+}
+#endif
+
+__weak int rk3188_board_late_init(void)
+{
+ return 0;
+}
+
+int rk_board_late_init(void)
+{
+ struct rk3188_grf *grf;
+
+ grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+ if (IS_ERR(grf)) {
+ pr_err("grf syscon returned %ld\n", PTR_ERR(grf));
+ return 0;
+ }
/* enable noc remap to mimic legacy loaders */
rk_clrsetreg(>soc_con0,
NOC_REMAP_MASK << NOC_REMAP_SHIFT,
NOC_REMAP_MASK << NOC_REMAP_SHIFT);
- return 0;
+ return rk3188_board_late_init();
}
-#endif
#ifdef CONFIG_SPL_BUILD
static int setup_led(void)
--
2.17.1
[PATCH 2/2] rockchip: clk: rk3188: enable bwadj for rk3188 DPLL
Empirically, I found that DPLL on rk3188 has bwadj registers.
Configuring DPLL with bwadj increase DPLL stability. Because
of DPLL provide clock for ethernet, enabling bwaj reduces
the number of errors on the ethernet.
Signed-off-by: Alexander Kochetkov
---
drivers/clk/rockchip/clk_rk3188.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3188.c
b/drivers/clk/rockchip/clk_rk3188.c
index 4fc5c78563..ee5782d25d 100644
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -117,7 +117,7 @@ static int rkclk_set_pll(struct rk3188_cru *cru, enum
rk_clk_id clk_id,
}
static int rkclk_configure_ddr(struct rk3188_cru *cru, struct rk3188_grf *grf,
- unsigned int hz, bool has_bwadj)
+ unsigned int hz)
{
static const struct pll_div dpll_cfg[] = {
{.nf = 75, .nr = 1, .no = 6},
@@ -149,7 +149,8 @@ static int rkclk_configure_ddr(struct rk3188_cru *cru,
struct rk3188_grf *grf,
rk_clrsetreg(>cru_mode_con, DPLL_MODE_MASK << DPLL_MODE_SHIFT,
DPLL_MODE_SLOW << DPLL_MODE_SHIFT);
- rkclk_set_pll(cru, CLK_DDR, _cfg[cfg], has_bwadj);
+ /* rk3188 and rk3188a DPLL has bwadj */
+ rkclk_set_pll(cru, CLK_DDR, _cfg[cfg], 1);
/* wait for pll lock */
while (!(readl(>soc_status0) & SOCSTS_DPLL_LOCK))
@@ -504,8 +505,7 @@ static ulong rk3188_clk_set_rate(struct clk *clk, ulong
rate)
priv->has_bwadj);
break;
case CLK_DDR:
- new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate,
- priv->has_bwadj);
+ new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate);
break;
case HCLK_EMMC:
case HCLK_SDMMC:
--
2.17.1
[PATCH 0/2] v2: rr3188: change APP to 600MHz and enable bwadj for DPLL
Hello! Here are two patches I found usefull for rk3188. Changes in v2: Add u-boot@lists.denx.de as addressee. Alexander Kochetkov (2): rockchip: clk: rk3188: change APLL to safe 600MHz rockchip: clk: rk3188: enable bwadj for rk3188 DPLL drivers/clk/rockchip/clk_rk3188.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) -- 2.17.1
[PATCH 1/2] rockchip: clk: rk3188: change APLL to safe 600MHz
The commit 84a6a27ae3ff ("rockchip: rk3188: init CPU freq in clock
driver") changed ARM clock from 600MHz to 1600MHz. It made boot
unstable due to the fact that PMIC at the start generates insufficient
voltage for operation. See also: commit f4f57c58b589 ("rockchip:
rk3188: Setup the armclk in spl").
Fixes commit 84a6a27ae3ff ("rockchip: rk3188: init CPU freq in clock
driver").
Signed-off-by: Alexander Kochetkov
---
drivers/clk/rockchip/clk_rk3188.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk_rk3188.c
b/drivers/clk/rockchip/clk_rk3188.c
index b193ac913e..4fc5c78563 100644
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -564,7 +564,8 @@ static int rk3188_clk_probe(struct udevice *dev)
rkclk_init(priv->cru, priv->grf, priv->has_bwadj);
/* Init CPU frequency */
- rkclk_configure_cpu(priv->cru, priv->grf, APLL_HZ, priv->has_bwadj);
+ rkclk_configure_cpu(priv->cru, priv->grf, APLL_SAFE_HZ,
+ priv->has_bwadj);
#endif
return 0;
--
2.17.1
Re: [PATCH] board: amlogic: Add Odroid-N2 board support
Hi,
On 21/06/2020 19:23, Anand Moon wrote:
> Hi Neil,
>
> On Thu, 18 Jun 2020 at 20:11, Neil Armstrong wrote:
>>
>> From: Pascal Vizeli
>>
>> Add a proper Odroid-N2 board support to handle the Ethernet MAC
>> address stored in the in-SoC eFuses.
>>
>
> This feature need to be implemented for all Amlogic SoC boards,
> since many boards link libretech-cc also generate random mac address
> for ethernet.
In fact, AFAIK only HardKernel stores the MAC in the fuses, now Amlogic stores
the MAC in the eMMC custom partitions, but they did for GXBB and previous SoCs.
Earlier I introduced meson_generate_serial_ethaddr() for GXL and later (not
GXBB),
to generate an unique MAC address from the SoC serial.
Neil
>
> Please add my: Tested on N2.
> Tested-by: Anand Moon
>
> -Anand
>
>> Signed-off-by: Pascal Vizeli
>> Signed-off-by: Neil Armstrong
>> ---
>> board/amlogic/odroid-n2/MAINTAINERS | 7 +
>> board/amlogic/odroid-n2/Makefile| 6
>> board/amlogic/odroid-n2/odroid-n2.c | 49 +
>> board/amlogic/w400/MAINTAINERS | 2 --
>> configs/odroid-n2_defconfig | 2 +-
>> 5 files changed, 63 insertions(+), 3 deletions(-)
>> create mode 100644 board/amlogic/odroid-n2/MAINTAINERS
>> create mode 100644 board/amlogic/odroid-n2/Makefile
>> create mode 100644 board/amlogic/odroid-n2/odroid-n2.c
>>
>> diff --git a/board/amlogic/odroid-n2/MAINTAINERS
>> b/board/amlogic/odroid-n2/MAINTAINERS
>> new file mode 100644
>> index 00..5627e54058
>> --- /dev/null
>> +++ b/board/amlogic/odroid-n2/MAINTAINERS
>> @@ -0,0 +1,7 @@
>> +ODROID-N2
>> +M: Neil Armstrong
>> +S: Maintained
>> +L: u-boot-amlo...@groups.io
>> +F: board/amlogic/odroid-n2/
>> +F: configs/odroid-n2_defconfig
>> +F: doc/board/amlogic/odroid-n2.rst
>> diff --git a/board/amlogic/odroid-n2/Makefile
>> b/board/amlogic/odroid-n2/Makefile
>> new file mode 100644
>> index 00..68e4e2a828
>> --- /dev/null
>> +++ b/board/amlogic/odroid-n2/Makefile
>> @@ -0,0 +1,6 @@
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +# (C) Copyright 2020 BayLibre, SAS
>> +# Author: Neil Armstrong
>> +
>> +obj-y := odroid-n2.o
>> diff --git a/board/amlogic/odroid-n2/odroid-n2.c
>> b/board/amlogic/odroid-n2/odroid-n2.c
>> new file mode 100644
>> index 00..caf7fd6810
>> --- /dev/null
>> +++ b/board/amlogic/odroid-n2/odroid-n2.c
>> @@ -0,0 +1,49 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2020 BayLibre, SAS
>> + * Author: Neil Armstrong
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define EFUSE_MAC_OFFSET 20
>> +#define EFUSE_MAC_SIZE 12
>> +#define MAC_ADDR_LEN 6
>> +
>> +int misc_init_r(void)
>> +{
>> + u8 mac_addr[MAC_ADDR_LEN];
>> + char efuse_mac_addr[EFUSE_MAC_SIZE], tmp[3];
>> + ssize_t len;
>> +
>> + meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
>> +
>> + if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
>> + len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
>> + efuse_mac_addr, EFUSE_MAC_SIZE);
>> + if (len != EFUSE_MAC_SIZE)
>> + return 0;
>> +
>> + /* MAC is stored in ASCII format, 1bytes = 2characters */
>> + for (int i = 0; i < 6; i++) {
>> + tmp[0] = efuse_mac_addr[i * 2];
>> + tmp[1] = efuse_mac_addr[i * 2 + 1];
>> + tmp[2] = '\0';
>> + mac_addr[i] = simple_strtoul(tmp, NULL, 16);
>> + }
>> +
>> + if (is_valid_ethaddr(mac_addr))
>> + eth_env_set_enetaddr("ethaddr", mac_addr);
>> + else
>> + meson_generate_serial_ethaddr();
>> + }
>> +
>> + return 0;
>> +}
>> diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS
>> index 5e837cfaef..a1b0ac8636 100644
>> --- a/board/amlogic/w400/MAINTAINERS
>> +++ b/board/amlogic/w400/MAINTAINERS
>> @@ -5,8 +5,6 @@ L: u-boot-amlo...@groups.io
>> F: board/amlogic/w400/
>> F: configs/khadas-vim3_defconfig
>> F: configs/khadas-vim3l_defconfig
>> -F: configs/odroid-n2_defconfig
>> F: doc/board/amlogic/w400.rst
>> F: doc/board/amlogic/khadas-vim3.rst
>> F: doc/board/amlogic/khadas-vim3l.rst
>> -F: doc/board/amlogic/odroid-n2.rst
>> diff --git a/configs/odroid-n2_defconfig b/configs/odroid-n2_defconfig
>> index e0cc6e3729..063809416e 100644
>> --- a/configs/odroid-n2_defconfig
>> +++ b/configs/odroid-n2_defconfig
>> @@ -1,5 +1,5 @@
>> CONFIG_ARM=y
>> -CONFIG_SYS_BOARD="w400"
>> +CONFIG_SYS_BOARD="odroid-n2"
>> CONFIG_ARCH_MESON=y
>> CONFIG_SYS_TEXT_BASE=0x0100
>> CONFIG_ENV_SIZE=0x2000
>> --
>> 2.22.0
>>
[PATCH] rockchip: i2c: fix switch to new implementation for rk3188
The commit e7ae4cf27a6d 'pinctrl: rockchip: Add common rockchip
pinctrl driver' dropped rk3188_pinctrl_request operation, that
did switching to new implementation.
This commit implement switching to new implementation using
writing bits to GRF.
I don't have rk3060 board to test, so switching implemented
as a stub returning -ENOSYS.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/rk_i2c.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 32b2ee8578..ad3c66843b 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -41,6 +43,7 @@ enum {
*/
struct rk_i2c_soc_data {
int controller_type;
+ int (*switch_to_new_type)(int bus_nr);
};
static inline void rk_i2c_get_div(int div, int *divh, int *divl)
@@ -388,11 +391,33 @@ static int rockchip_i2c_ofdata_to_platdata(struct udevice
*bus)
return 0;
}
+static int rockchip_i2c_switch_to_new_type_rk3066(int bus_nr)
+{
+ return -ENOSYS;
+}
+
+static int rockchip_i2c_switch_to_new_type_rk3188(int bus_nr)
+{
+ struct rk3188_grf *grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+
+ if (grf == NULL)
+ return -ENOSYS;
+
+ if (bus_nr < 0 || bus_nr > (RKI2C4_SEL_SHIFT - RKI2C0_SEL_SHIFT))
+ return -EINVAL;
+
+ /* enable new i2c controller */
+ rk_clrsetreg(>soc_con1,
+1 << (RKI2C0_SEL_SHIFT + bus_nr),
+1 << (RKI2C0_SEL_SHIFT + bus_nr));
+
+ return 0;
+}
+
static int rockchip_i2c_probe(struct udevice *bus)
{
struct rk_i2c *priv = dev_get_priv(bus);
struct rk_i2c_soc_data *soc_data;
- struct udevice *pinctrl;
int bus_nr;
int ret;
@@ -408,17 +433,10 @@ static int rockchip_i2c_probe(struct udevice *bus)
return ret;
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, );
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- return ret;
- }
-
- /* pinctrl will switch I2C to new type */
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_I2C0 + bus_nr);
- if (ret) {
+ ret = soc_data->switch_to_new_type(bus_nr);
+ if (ret < 0) {
debug("%s: Failed to switch I2C to new type %s: %d\n",
- __func__, bus->name, ret);
+__func__, bus->name, ret);
return ret;
}
}
@@ -433,10 +451,12 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
static const struct rk_i2c_soc_data rk3066_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3066,
};
static const struct rk_i2c_soc_data rk3188_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3188,
};
static const struct rk_i2c_soc_data rk3228_soc_data = {
--
2.17.1
Re: [PATCH 0/7] Add support for CONFIG_API on RISC-V
On Sat, Apr 25, 2020 at 4:31 AM Heinrich Schuchardt wrote:
>
> On 4/24/20 10:52 PM, Tom Rini wrote:
> > On Fri, Apr 24, 2020 at 05:46:43PM -0300, Mitchell Horne wrote:
> >> On Fri, Apr 24, 2020 at 1:52 PM Tom Rini wrote:
> >>>
> >>> On Mon, Apr 20, 2020 at 06:34:11PM -0400, mho...@freebsd.org wrote:
> >>>
> From: Mitchell Horne
>
> FreeBSD makes use of u-boot's CONFIG_API to provide a version of its
> standard bootloader for embedded architectures. This series adds the
> necessary support for the RISC-V architecture, along with some small
> fixes to the API demo program for 64-bit systems.
> >>>
> >>> Adding in the RISC-V maintainer and EFI maintainer. I thought the
> >>> intention was for OSes to use the EFI loader here, even for "embedded" ?
> >>> Thanks!
> >>>
> >>
> >> Hi Tom,
> >>
> >> You are right, EFI is preferred. FreeBSD's loader has two
> >> implementations on arm: one that is an EFI application, and one based
> >> on this u-boot API (known as "ubldr"). ubldr precedes the EFI
> >> implementation by a few years.
> >>
> >> For RISC-V my intention is also to implement both versions, and ubldr
> >> was simpler on FreeBSD's side, so I chose to do that first. Do you
> >> think this series is still worth pursuing if u-boot is going the way
> >> of EFI?
> >
> > In my mind at least, the EFI interface is preferred as it's a defined
> > external standard interface. If the architecture maintainers want to
> > support both the U-Boot API and EFI on RISC-V, I don't object. But one
> > of the intentions is to have there be less work for OS folks to have to
> > do for example. So that you found this a good first step for your use
> > case means perhaps we need to continue to have the U-Boot API method be
> > around (not that we had planned any sort of removal). Thanks!
> >
>
> Hello Mitchell,
>
> let me just give me an overview of where we currently are with UEFI
> support for RISC-V:
>
> U-Boot supports UEFI to the point that we can start GRUB as EFI binary.
>
> In Linux the UEFI support for RISC-V is being set up, cf.
> https://lkml.org/lkml/2020/4/20/1800
>
> In EDK2 RISC-V support is under active development
> (https://edk2.groups.io/g/devel/search?q=RISC-V). In EDK2's staging
> repository (https://github.com/tianocore/edk2-staging.git) you can find
> a branch RISC-V-V2-CI-log-all-archs.
>
> One challenge is the transfer of the HART id which is used for booting.
> In U-Boot this has been addressed by the patch 5370478d1c7a ("riscv: Add
> boot hartid to device tree").
Hi, just so this thread isn't left dangling, I eventually went the EFI
route. I found this to be easier because the hart-id fixups aren't
applied when executing plain binaries via the "go" command. I don't
think this patchset will be needed. Thanks!
Mitchell
>
> @Atish:
> Is there a corresponding patch for EDK2?
>
> Best regards
>
> Heinrich
Re: [PATCH 03/16] dh_imx6: Switch to full DM-aware
On Mon, Jun 22, 2020 at 09:38:36AM +, Ludwig Zenz wrote: > On 6/13/20 3:55 PM, Jagan Teki wrote: > > Enable DM_SPI/DM_SPI_FLASH with a related config option. > > > > Build fine, but not tested. > > Hello, > > due to memory limitations in the SRAM of the i.MX6S in SPL we have not used > the device tree. Have the restrictions been removed in the meantime? We need > a single binary for the i.MX6 q/d/dl/s variants of our system on module. > > I think this patch breaks the board support for our module. I _think_ i.MX is making use of the generic hooks to cause build time failures when we grow too large. And we have addressed some, but not all of the concerns about DM size. Can you please test this patch? If it doesn't work doing: > > diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h index > > 5bfdf4044b..5fb84f72a2 100644 > > --- a/include/configs/dh_imx6.h > > +++ b/include/configs/dh_imx6.h > > @@ -53,12 +53,6 @@ > > /* SATA Configs */ > > #define CONFIG_LBA48 > > > > -/* SPI Flash Configs */ > > -#if defined(CONFIG_SPL_BUILD) > > -#undef CONFIG_DM_SPI > > -#undef CONFIG_DM_SPI_FLASH > > -#endif is still needed as we have a symbol to control DM SPI in SPL directly so the above isn't doing what you imply you want. Thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/5] dt-bindings: prci: add indexes for reset signals available in prci
Add bit indexes for reset signals within the PRCI module on FU540-C000 SoC. The DDR and ethernet sub-system's have reset signals indicated by these reset indexes. Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Pragnesh Patel --- include/dt-bindings/clock/sifive-fu540-prci.h | 8 1 file changed, 8 insertions(+) diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h b/include/dt-bindings/clock/sifive-fu540-prci.h index 6a0b70a..1c03b09 100644 --- a/include/dt-bindings/clock/sifive-fu540-prci.h +++ b/include/dt-bindings/clock/sifive-fu540-prci.h @@ -15,4 +15,12 @@ #define PRCI_CLK_GEMGXLPLL2 #define PRCI_CLK_TLCLK3 +/* Reset bit indexes to be used by driver */ +#define PRCI_RST_DDR_CTRL_N0 +#define PRCI_RST_DDR_AXI_N 1 +#define PRCI_RST_DDR_AHB_N 2 +#define PRCI_RST_DDR_PHY_N 3 +/* bit 4 is reserved bit */ +#define PRCI_RST_RSVD_N4 +#define PRCI_RST_GEMGXL_N 5 #endif -- 2.7.4
[PATCH 0/5] add DM based reset driver for SiFive SoC's
The FU540-C000 support in U-Boot is missing DM based reset driver,
and is handling reset's to sub-system within the prci driver itself.
The series here adds a generic DM reset driver for SiFive SoC's so as
to leverage the U-Boot's reset framework and binds the reset driver with
prci driver.
The PRCI driver takes care of triggering the consumers reset signals
appropriately.
Patch 1: Add necessary dt indexes for device reset register.
Patch 2: Update macro's to use common dt indexes from binding header.
Patch 3: Add reset producer and consumer entries within the device tree.
Patch 4: Add reset dm driver and bind it within prci module.
Patch 5: Add Kconfig, Makefile entries and enable the driver
This series is based on mainline U-Boot
commit 2b8692bac1e8 ("Merge tag 'efi-2020-07-rc5-2' of
https://gitlab.denx.de/u-boot/custodians/u-boot-efi;)
Sagar Shrikant Kadam (5):
dt-bindings: prci: add indexes for reset signals available in prci
fu540: prci: use common reset indexes defined in binding header
fu540: dtsi: add reset producer and consumer entries
sifive: reset: add DM based reset driver for SiFive SoC's
configs: reset: fu540: enable dm reset framework for SiFive SoC
arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 +++
arch/riscv/include/asm/arch-fu540/reset.h | 13 +++
configs/sifive_fu540_defconfig| 2 +
drivers/clk/sifive/fu540-prci.c | 89 +--
drivers/reset/Kconfig | 9 ++
drivers/reset/Makefile| 1 +
drivers/reset/reset-sifive.c | 118 ++
include/dt-bindings/clock/sifive-fu540-prci.h | 8 ++
8 files changed, 225 insertions(+), 25 deletions(-)
create mode 100644 arch/riscv/include/asm/arch-fu540/reset.h
create mode 100644 drivers/reset/reset-sifive.c
--
2.7.4
[PATCH 4/5] sifive: reset: add DM based reset driver for SiFive SoC's
PRCI module within SiFive SoC's has register with which we can
reset the sub-systems within the SoC. The resets to DDR and ethernet
sub systems within FU540-C000 SoC are active low, and are hold low
by default on power-up. Currently these are directly asserted within
prci driver via register read/write.
With the DM based reset driver support here, we bind the reset
driver with clock (prci) driver and assert the reset signals of
both sub-system's appropriately.
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
---
arch/riscv/include/asm/arch-fu540/reset.h | 13
drivers/clk/sifive/fu540-prci.c | 73 ++
drivers/reset/reset-sifive.c | 118 ++
3 files changed, 189 insertions(+), 15 deletions(-)
create mode 100644 arch/riscv/include/asm/arch-fu540/reset.h
create mode 100644 drivers/reset/reset-sifive.c
diff --git a/arch/riscv/include/asm/arch-fu540/reset.h
b/arch/riscv/include/asm/arch-fu540/reset.h
new file mode 100644
index 000..e42797a
--- /dev/null
+++ b/arch/riscv/include/asm/arch-fu540/reset.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2020 SiFive, Inc.
+ *
+ * Author: Sagar Kadam
+ */
+
+#ifndef __RESET_SIFIVE_H
+#define __RESET_SIFIVE_H
+
+int sifive_reset_bind(struct udevice *dev, ulong count);
+
+#endif
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index 57d811e..675b508 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -30,11 +30,15 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -131,6 +135,7 @@
/* DEVICESRESETREG */
#define PRCI_DEVICESRESETREG_OFFSET0x28
+#define PRCI_DEVICERESETCNT 5
#define PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_MASK \
(0x1 << PRCI_RST_DDR_CTRL_N)
@@ -524,6 +529,41 @@ static const struct __prci_clock_ops
sifive_fu540_prci_tlclksel_clk_ops = {
.recalc_rate = sifive_fu540_prci_tlclksel_recalc_rate,
};
+static int __prci_consumer_reset(const char *rst_name, bool trigger)
+{
+ struct udevice *dev;
+ struct reset_ctl rst_sig;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_RESET,
+ DM_GET_DRIVER(sifive_reset),
+ );
+ if (ret) {
+ dev_err(dev, "Reset driver not found: %d\n", ret);
+ return ret;
+ }
+
+ ret = reset_get_by_name(dev, rst_name, _sig);
+ if (ret) {
+ dev_err(dev, "failed to get %s reset\n", rst_name);
+ return ret;
+ }
+
+ if (reset_valid(_sig)) {
+ if (trigger)
+ ret = reset_deassert(_sig);
+ else
+ ret = reset_assert(_sig);
+ if (ret) {
+ dev_err(dev, "failed to trigger reset id = %ld\n",
+ rst_sig.id);
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
/**
* __prci_ddr_release_reset() - Release DDR reset
* @pd: struct __prci_data * for the PRCI containing the DDRCLK mux reg
@@ -531,19 +571,20 @@ static const struct __prci_clock_ops
sifive_fu540_prci_tlclksel_clk_ops = {
*/
static void __prci_ddr_release_reset(struct __prci_data *pd)
{
- u32 v;
-
- v = __prci_readl(pd, PRCI_DEVICESRESETREG_OFFSET);
- v |= PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_MASK;
- __prci_writel(v, PRCI_DEVICESRESETREG_OFFSET, pd);
+ /* Release DDR ctrl reset */
+ __prci_consumer_reset("ddr_ctrl", true);
/* HACK to get the '1 full controller clock cycle'. */
asm volatile ("fence");
- v = __prci_readl(pd, PRCI_DEVICESRESETREG_OFFSET);
- v |= (PRCI_DEVICESRESETREG_DDR_AXI_RST_N_MASK |
- PRCI_DEVICESRESETREG_DDR_AHB_RST_N_MASK |
- PRCI_DEVICESRESETREG_DDR_PHY_RST_N_MASK);
- __prci_writel(v, PRCI_DEVICESRESETREG_OFFSET, pd);
+
+ /* Release DDR AXI reset */
+ __prci_consumer_reset("ddr_axi", true);
+
+ /* Release DDR AHB reset */
+ __prci_consumer_reset("ddr_ahb", true);
+
+ /* Release DDR PHY reset */
+ __prci_consumer_reset("ddr_phy", true);
/* HACK to get the '1 full controller clock cycle'. */
asm volatile ("fence");
@@ -563,12 +604,8 @@ static void __prci_ddr_release_reset(struct __prci_data
*pd)
*/
static void __prci_ethernet_release_reset(struct __prci_data *pd)
{
- u32 v;
-
/* Release GEMGXL reset */
- v = __prci_readl(pd, PRCI_DEVICESRESETREG_OFFSET);
- v |= PRCI_DEVICESRESETREG_GEMGXL_RST_N_MASK;
- __prci_writel(v, PRCI_DEVICESRESETREG_OFFSET, pd);
+ __prci_consumer_reset("gemgxl_reset", true);
/* Procmon => core clock */
[PATCH 2/5] fu540: prci: use common reset indexes defined in binding header
Indexes of reset signals available in PRCI driver are also defined in include/dt-bindings/clock/sifive-fu540-prci.h. So use those instead of defining new ones again within the fu540-prci driver. Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Pragnesh Patel [A --- drivers/clk/sifive/fu540-prci.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..57d811e 100644 --- a/drivers/clk/sifive/fu540-prci.c +++ b/drivers/clk/sifive/fu540-prci.c @@ -131,21 +131,17 @@ /* DEVICESRESETREG */ #define PRCI_DEVICESRESETREG_OFFSET0x28 -#define PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_SHIFT 0 + #define PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_MASK \ - (0x1 << PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_SHIFT) -#define PRCI_DEVICESRESETREG_DDR_AXI_RST_N_SHIFT 1 + (0x1 << PRCI_RST_DDR_CTRL_N) #define PRCI_DEVICESRESETREG_DDR_AXI_RST_N_MASK \ - (0x1 << PRCI_DEVICESRESETREG_DDR_AXI_RST_N_SHIFT) -#define PRCI_DEVICESRESETREG_DDR_AHB_RST_N_SHIFT 2 + (0x1 << PRCI_RST_DDR_AXI_N) #define PRCI_DEVICESRESETREG_DDR_AHB_RST_N_MASK \ - (0x1 << PRCI_DEVICESRESETREG_DDR_AHB_RST_N_SHIFT) -#define PRCI_DEVICESRESETREG_DDR_PHY_RST_N_SHIFT 3 + (0x1 << PRCI_RST_DDR_AHB_N) #define PRCI_DEVICESRESETREG_DDR_PHY_RST_N_MASK \ - (0x1 << PRCI_DEVICESRESETREG_DDR_PHY_RST_N_SHIFT) -#define PRCI_DEVICESRESETREG_GEMGXL_RST_N_SHIFT 5 + (0x1 << PRCI_RST_DDR_PHY_N) #define PRCI_DEVICESRESETREG_GEMGXL_RST_N_MASK \ - (0x1 << PRCI_DEVICESRESETREG_GEMGXL_RST_N_SHIFT) + (0x1 << PRCI_RST_GEMGXL_N) /* CLKMUXSTATUSREG */ #define PRCI_CLKMUXSTATUSREG_OFFSET0x2c -- 2.7.4
[PATCH 5/5] configs: reset: fu540: enable dm reset framework for SiFive SoC
Add necessary defconfig and Kconfig entries to enable SiFive SoC's reset driver so as to utilise U-Boot's reset framework. Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Pragnesh Patel --- configs/sifive_fu540_defconfig | 2 ++ drivers/reset/Kconfig | 9 + drivers/reset/Makefile | 1 + 3 files changed, 12 insertions(+) diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig index 8d412f8..6d78943 100644 --- a/configs/sifive_fu540_defconfig +++ b/configs/sifive_fu540_defconfig @@ -21,3 +21,5 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SPL_CLK=y CONFIG_DM_MTD=y +CONFIG_SPL_DM_RESET=y +CONFIG_DM_RESET=y diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index 88d3be1..627f8e8 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -148,4 +148,13 @@ config RESET_IMX7 help Support for reset controller on i.MX7/8 SoCs. +config RESET_SIFIVE + bool "Reset Driver for SiFive SoC's" + depends on DM_RESET && CLK_SIFIVE_FU540_PRCI && TARGET_SIFIVE_FU540 + default y + help + PRCI module within SiFive SoC's provides mechanism to reset + different hw blocks like DDR, gemgxl. With this driver we leverage + U-Boot's reset framework to reset these hardware blocks. + endmenu diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 0a044d5..e3c27c4 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -23,3 +23,4 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o obj-$(CONFIG_RESET_IMX7) += reset-imx7.o +obj-$(CONFIG_RESET_SIFIVE) += reset-sifive.o -- 2.7.4
[PATCH 3/5] fu540: dtsi: add reset producer and consumer entries
The resets to DDR and ethernet sub-system are connected to
PRCI device reset control register, these reset signals
are active low and are held low at power-up. Add these reset
producer and consumer details needed by the reset driver.
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
---
arch/riscv/dts/fu540-c000-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
b/arch/riscv/dts/fu540-c000-u-boot.dtsi
index 9bba554..b37241e 100644
--- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
+++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
@@ -59,6 +59,16 @@
reg = <0x0 0x200 0x0 0xc>;
u-boot,dm-spl;
};
+ prci: clock-controller@1000 {
+ #reset-cells = <1>;
+ resets = < PRCI_RST_DDR_CTRL_N>,
+< PRCI_RST_DDR_AXI_N>,
+< PRCI_RST_DDR_AHB_N>,
+< PRCI_RST_DDR_PHY_N>,
+< PRCI_RST_GEMGXL_N>;
+ reset-names = "ddr_ctrl", "ddr_axi", "ddr_ahb",
+ "ddr_phy", "gemgxl_reset";
+ };
dmc: dmc@100b {
compatible = "sifive,fu540-c000-ddr";
reg = <0x0 0x100b 0x0 0x0800
--
2.7.4
Re: [PULL] u-boot-sh/net
On Sat, Jun 20, 2020 at 07:18:22PM +0200, Marek Vasut wrote: > Below is another networking PR for u-boot/next (!). It's more DM > conversion of the PCI networking drivers. > > Any news on Joe ? Nothing as of yet. > The following changes since commit 7a81989b7b04bd87d1e684f2bafdc92a9c16fecc: > > common: hash: Remove a debug printf statement (2020-06-16 11:36:30 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git net > > for you to fetch changes up to d789a8259e3b3b77e3eb2b090373ab2cbc225629: > > net: pcnet: Add Kconfig entries (2020-06-18 19:34:41 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request (-next): u-boot-spi/master
On Sat, Jun 20, 2020 at 12:00:02AM +0530, Jagan Teki wrote: > Hi Tom, > > PR is for -next (v2020.10) as part of spi dm-conversion changes. > > Summary: > - Convert fsl_espi to driver model (Chuanhua) > - Enable am335x baltos to DM_SPI (Jagan) > - Drop few powerpc board which doesn't have DM enabled (Jagan) > > Travis-CI: > https://travis-ci.org/github/openedev/u-boot-amarula/builds/699804652 > > Any inputs? Please do this in "next" not master, in the future so that history won't get too funny if you need to give me some changes later on for v2020.07. And signed tags to pull from would be nice too. More specifically, I see the commit to drop T1024QDS_DDR4_SECURE_BOOT is missing Priyanka's reviewed-by, which was given for v1. Not a deal-breaker but I did go back to confirm that one of the to-keep platforms wasn't being removed by accident. > Jagan. > > The following changes since commit 9cb895203a46654f7ee6dd95be5c8ab05e4dfbd3: > > Merge tag 'u-boot-stm32-20200616' of > https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2020-06-16 09:18:56 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-spi master > > for you to fetch changes up to 2a2b94a9d9a3139853c6ccd911c55db77b714a68: > > am335x: baltos: Enable DM_SPI (2020-06-18 21:53:21 +0530) Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Sat, Jun 20, 2020 at 07:16:23PM +0200, Marek Vasut wrote: > The following changes since commit 9cb895203a46654f7ee6dd95be5c8ab05e4dfbd3: > > Merge tag 'u-boot-stm32-20200616' of > https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2020-06-16 09:18:56 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 10fa7ec9f64dec9bc90e85e37248eabfb9b44bf2: > > ARM: rmobile: Increase PHY auto-negotiation timeout to 20s (2020-06-18 > 19:35:03 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v9 1/2] i2c: i2c-cortina: added CAxxxx I2C support
Hi Alex,
Am 17.06.2020 um 22:09 schrieb Alex Nemirovsky:
Hi Heiko,
Sorry for the late reply!
seems that this patch set may have slipped through the cracks.
Is there anything keeping it from being merged into master?
No, but we are so late in release cycle, so I planned it for the next
merge window!
bye,
Heiko
On Jun 1, 2020, at 12:56 PM, Alex Nemirovsky
wrote:
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
Reviewed-by: Heiko Schocher
---
Changes in v9:
- specially include bitops.h and delay.h which
were removed from common.h
Changes in v8:
- No code change
- Split out individual driver from Cortina Package 2 patch series
to help streamline acceptence into master
Changes in v7:
- Added additional description info in I2C KConfig
Changes in v6:
- Add I2C DT binding document
Changes in v4:
- Utilize standard I2C macros from
- Return ETIMEDOUT in funcs that can timeout
- Return i2c_xfer_init() result to caller of i2c_read() if it
fails within i2c_read() execution
- Fix misc. style guide conformance issues
- Use printf() to report i2c_xfer() runtime errors
instead of debug()
MAINTAINERS | 4 +
doc/device-tree-bindings/i2c/i2c-cortina.txt | 18 ++
drivers/i2c/Kconfig | 8 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-cortina.c| 346 +++
drivers/i2c/i2c-cortina.h| 87 +++
6 files changed, 464 insertions(+)
create mode 100644 doc/device-tree-bindings/i2c/i2c-cortina.txt
create mode 100644 drivers/i2c/i2c-cortina.c
create mode 100644 drivers/i2c/i2c-cortina.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8add9d4..ce70ca9 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
@@ -732,6 +734,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/doc/device-tree-bindings/i2c/i2c-cortina.txt
b/doc/device-tree-bindings/i2c/i2c-cortina.txt
new file mode 100644
index 000..59d5235
--- /dev/null
+++ b/doc/device-tree-bindings/i2c/i2c-cortina.txt
@@ -0,0 +1,18 @@
+* I2C for Cortina platforms
+
+Required properties :
+- compatible : Must be "cortina,ca-i2c"
+- reg : Offset and length of the register set for the device
+
+Recommended properties :
+- clock-frequency : desired I2C bus clock frequency in Hz. If not specified,
+ default value is 10. Possible values are 10,
+ 40 and 100.
+
+Examples :
+
+ i2c: i2c@f4329120 {
+ compatible = "cortina,ca-i2c";
+ reg = <0x0 0xf4329120 0x28>;
+ clock-frequency = <40>;
+ };
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index f8b18de..b56e0d9 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -93,6 +93,14 @@ 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
+ Add support for the Cortina Access I2C host controller.
+ 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 62935b7..d2b07ce 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..08b812a
--- /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);
+
Re: Setting DEVICE_TREE for xilinx_zynq_virt_defconfig?
Hi, On 20. 06. 20 20:06, Florian Klink wrote: > Hey, > > I tried building latest master 2b8692bac1e8795cbb87b0d00213fd193409851d, > for a zynq device, and did according to the documentation: > > $ export DEVICE_TREE=zynq-zc702 > $ make xilinx_zynq_virt_defconfig > $ make > > Reading f7c6ee7fe7bcc387de4c92300f46cb725b845b53, I assumed this should > have fixed FDT loading, but for some reason u-boot still tries to look > for a `zynq-zynq.dtb` in FDTDIR. > > Could it be this broke in the meantime, or is this expected? I am not aware about any issue like this. Can you please provide more logs to see what it is happening? Thanks, Michal signature.asc Description: OpenPGP digital signature
[PATCH 1/2] mmc: fsl_esdhc_imx: fix the mask for tuning start point
From: Haibo Chen
According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
TUNING_START_TAP, bit[7] of this register is to disable the command
CRC check for standard tuning. So fix it here.
Fixes: fa33d207494c ("mmc: split fsl_esdhc driver for i.MX")
Signed-off-by: Haibo Chen
---
include/fsl_esdhc_imx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h
index 33c6d52bfe..220a76b9ee 100644
--- a/include/fsl_esdhc_imx.h
+++ b/include/fsl_esdhc_imx.h
@@ -203,7 +203,7 @@
#define ESDHC_STD_TUNING_EN BIT(24)
/* NOTE: the minimum valid tuning start tap for mx6sl is 1 */
#define ESDHC_TUNING_START_TAP_DEFAULT 0x1
-#define ESDHC_TUNING_START_TAP_MASK0xff
+#define ESDHC_TUNING_START_TAP_MASK0x7f
#define ESDHC_TUNING_STEP_MASK 0x0007
#define ESDHC_TUNING_STEP_SHIFT16
--
2.17.1
[PATCH 2/2] mmc: fsl_esdhc_imx: disable the CMD CRC check for standard tuning
From: Haibo Chen
In current code, we add 1ms dealy after each tuning command for standard
tuning method. Adding this 1ms dealy is because USDHC default check the
CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning
IC logic do not wait for the tuning data sending out by the card, trigger
the buffer read ready interrupt immediately, and step to next cycle. So
when next time the new tuning command send out by USDHC, card may still
not send out the tuning data of the upper command，then some eMMC cards
may stuck, can't response to any command, block the whole tuning procedure.
If do not check the CMD CRC for tuning, then do not has this issue. USDHC
will wait for the tuning data of each tuning command and check them. If the
tuning data pass the check, it also means the CMD line also okay for tuning.
So this patch disable the CMD CRC check for tuning, save some time for the
whole tuning procedure.
Signed-off-by: Haibo Chen
---
drivers/mmc/fsl_esdhc_imx.c | 22 --
include/fsl_esdhc_imx.h | 1 +
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index f42e018434..5b61eeb214 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -907,19 +907,9 @@ static int fsl_esdhc_execute_tuning(struct udevice *dev,
uint32_t opcode)
ctrl = readl(>autoc12err);
if ((!(ctrl & MIX_CTRL_EXE_TUNE)) &&
(ctrl & MIX_CTRL_SMPCLK_SEL)) {
- /*
-* need to wait some time, make sure sd/mmc fininsh
-* send out tuning data, otherwise, the sd/mmc can't
-* response to any command when the card still out
-* put the tuning data.
-*/
- mdelay(1);
ret = 0;
break;
}
-
- /* Add 1ms delay for SD and eMMC */
- mdelay(1);
}
writel(irqstaten, >irqstaten);
@@ -1267,6 +1257,18 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
val |= priv->tuning_start_tap;
val &= ~ESDHC_TUNING_STEP_MASK;
val |= (priv->tuning_step) << ESDHC_TUNING_STEP_SHIFT;
+
+ /* Disable the CMD CRC check for tuning, if not, need to
+* add some delay after every tuning command, because
+* hardware standard tuning logic will directly go to
next
+* step once it detect the CMD CRC error, will not wait
for
+* the card side to finally send out the tuning data,
trigger
+* the buffer read ready interrupt immediately. If
usdhc send
+* the next tuning command some eMMC card will stuck,
can't
+* response, block the tuning procedure or the first
command
+* after the whole tuning procedure always can't get
any response.
+*/
+ val |= ESDHC_TUNING_CMD_CRC_CHECK_DISABLE;
writel(val, >tuning_ctrl);
}
}
diff --git a/include/fsl_esdhc_imx.h b/include/fsl_esdhc_imx.h
index 220a76b9ee..279a66d9bf 100644
--- a/include/fsl_esdhc_imx.h
+++ b/include/fsl_esdhc_imx.h
@@ -204,6 +204,7 @@
/* NOTE: the minimum valid tuning start tap for mx6sl is 1 */
#define ESDHC_TUNING_START_TAP_DEFAULT 0x1
#define ESDHC_TUNING_START_TAP_MASK0x7f
+#define ESDHC_TUNING_CMD_CRC_CHECK_DISABLE BIT(7)
#define ESDHC_TUNING_STEP_MASK 0x0007
#define ESDHC_TUNING_STEP_SHIFT16
--
2.17.1
Re: [PATCH 1/1] efi_loader: prepare for read only OP-TEE variables
On 22.06.20 11:16, Ilias Apalodimas wrote: > Hi Heincrich, > > Thanks for merging those. > > > Thanks > /Ilias > > > On Sat, Jun 20, 2020 at 12:56:15PM +0200, Heinrich Schuchardt wrote: >> We currently have two implementations of UEFI variables: >> >> * variables provided via an OP-TEE module >> * variables stored in the U-Boot environment >> >> Read only variables are up to now only implemented in the U-Boot >> environment implementation. >> >> Provide a common interface for both implementations that allows handling >> read-only variables. >> >> Signed-off-by: Heinrich Schuchardt >> --- > > [...] > >> #include >> >> @@ -30,20 +30,6 @@ static bool efi_secure_boot; >> static int efi_secure_mode; >> static u8 efi_vendor_keys; >> >> -#define READ_ONLY BIT(31) >> - >> -static efi_status_t efi_get_variable_common(u16 *variable_name, >> -const efi_guid_t *vendor, >> -u32 *attributes, >> -efi_uintn_t *data_size, void *data); >> - >> -static efi_status_t efi_set_variable_common(u16 *variable_name, >> -const efi_guid_t *vendor, >> -u32 attributes, >> -efi_uintn_t data_size, >> -const void *data, >> -bool ro_check); >> - > > Is there any commit I've missed prior to that? > I don't see efi_variable.h in the patchset or additions of > EFI_VARIABLE_READ_ONLY > >> /* >> * Mapping between EFI variables and u-boot variables: > > [...] > > > Rest of the changes look good I will resend the patch. Please, fetch https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/tree/efi-2020-10 Best regards Heinrich > > Regards > /Ilias >
rk3399: boot from compressed Image
Hello, booti now supports booting from compressed Image. See 414c34ed555b8ce5c260cf641261ecf45beca251. Would you please add kernel_comp_addr_r and kernel_comp_size to rk3399_common.h, so that people can use compressed Image (e.g. Image.gz) in extlinux.conf. Thanks, Yuanhao
Re: Usb on imx8mm
Hi Peng, Thanks for your reply. Will it be done in the near future, if not can you give me recommendations to do it? Best regards, Joris Offouga Le 22/06/2020 à 03:14, Peng Fan a écrit : It is not supported for now. Regards, Peng. Subject: Usb on imx8mm Hello, I try to use the usb on u imx8mm but the usb controller does not seem recognized: u-boot => usb start starting USB ... Do you have an idea ? Best regards Joris Offouga
Re: [PATCH v4] mmc: sdhci: Fix HISPD bit handling
On 6/22/20 6:26 PM, Jagan Teki wrote:
> On Mon, Jun 22, 2020 at 2:54 PM Jaehoon Chung wrote:
>>
>> Hi Peng,
>>
>> On 6/22/20 10:49 AM, Peng Fan wrote:
>>> Jaehoon,
>>>
Subject: [PATCH v4] mmc: sdhci: Fix HISPD bit handling
>>>
>>> Are you fine with this v4?
>>
>> Thanks for sharing it. i didn't see patch v4.
>>
>>>
>>> Thanks,
>>> Peng.
>>>
SDHCI HISPD bits need to be configured based on desired mmc timings mode
and some HISPD quirks.
So, handle the HISPD bit based on the mmc computed selected mode(timing
parameter) rather than fixed mmc card clock frequency.
Linux handle the HISPD similar like this in below commit but no
SDHCI_QUIRK_BROKEN_HISPD_MODE,
commit <501639bf2173> ("mmc: sdhci: fix SDHCI_QUIRK_NO_HISPD_BIT
handling")
This eventually fixed the mmc write issue observed in
rk3399 sdhci controller.
Bug log for refernece,
=> gpt write mmc 0 $partitions
Writing GPT: mmc write failed
** Can't write to device 0 **
** Can't write to device 0 **
error!
Cc: Kever Yang
Cc: Peng Fan
Tested-by: Suniel Mahesh # roc-rk3399-pc
Signed-off-by: Jagan Teki
---
Changes for v4:
- update commit message
- simplify the logic.
drivers/mmc/sdhci.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
92cc8434af..6cb702111b 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -567,6 +567,7 @@ static int sdhci_set_ios(struct mmc *mmc) #endif
u32 ctrl;
struct sdhci_host *host = mmc->priv;
+bool no_hispd_bit = false;
if (host->ops && host->ops->set_control_reg)
host->ops->set_control_reg(host);
@@ -594,14 +595,24 @@ static int sdhci_set_ios(struct mmc *mmc)
ctrl &= ~SDHCI_CTRL_4BITBUS;
}
-if (mmc->clock > 2600)
-ctrl |= SDHCI_CTRL_HISPD;
-else
-ctrl &= ~SDHCI_CTRL_HISPD;
-
if ((host->quirks & SDHCI_QUIRK_NO_HISPD_BIT) ||
(host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE))
-ctrl &= ~SDHCI_CTRL_HISPD;
+no_hispd_bit = true;
>>
>> No. ctrl variable is set to bit[2] of HOST_CONTROL register.
>> But Some samsung SoCs are using its bit[2] as other purpose.
>> So it needs to revert the value with "ctrl &= ~SDHCI_CTRL_HISPD".
>> Because it's possible to set to 1.
>>
>> SDHCI_QUIRK_NO_HISPD_BIT means that it's used other purpose.
>
> So, what are you suggesting? could you please elaborate?
if ((host->quirks & SDHCI_QUIRK_NO_HISPD_BIT) ||
(host->quirks & SDHCI_QUIRK_NO_BROKEN_HISPD_MODE)) {
ctrl &= ~SDHCI_CTRL_HISPD;
no_hispd_bit = true;
}
Just adding "ctrl &= ~SDHCI_CTRL_HISPD;" into its condition.
Then it's helpful to me.
Best Regards,
Jaehoon Chung
>
> Jagan.
>
RE: [PATCH 03/16] dh_imx6: Switch to full DM-aware
On 6/13/20 3:55 PM, Jagan Teki wrote: > Enable DM_SPI/DM_SPI_FLASH with a related config option. > > Build fine, but not tested. Hello, due to memory limitations in the SRAM of the i.MX6S in SPL we have not used the device tree. Have the restrictions been removed in the meantime? We need a single binary for the i.MX6 q/d/dl/s variants of our system on module. I think this patch breaks the board support for our module. regards, Ludwig Zenz > Cc: Ludwig Zenz > Cc: Andreas Geisreiter > Signed-off-by: Jagan Teki > --- > configs/dh_imx6_defconfig | 3 +++ > include/configs/dh_imx6.h | 6 -- > 2 files changed, 3 insertions(+), 6 deletions(-) > > diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig index > d20405e5b2..da756a8e3d 100644 > --- a/configs/dh_imx6_defconfig > +++ b/configs/dh_imx6_defconfig > @@ -49,12 +49,14 @@ CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_OF_CONTROL=y > +CONFIG_SPL_OF_CONTROL=y > CONFIG_DEFAULT_DEVICE_TREE="imx6q-dhcom-pdk2" > CONFIG_OF_LIST="imx6q-dhcom-pdk2 imx6dl-dhcom-pdk2" > CONFIG_MULTI_DTB_FIT=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SPL_DM=y > CONFIG_DWC_AHSATA=y > CONFIG_BOOTCOUNT_LIMIT=y > CONFIG_DM_I2C=y > @@ -100,4 +102,5 @@ CONFIG_CI_UDC=y > CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_WATCHDOG_TIMEOUT_MSECS=6 > CONFIG_IMX_WATCHDOG=y > +# CONFIG_SPL_WDT is not set > CONFIG_BZIP2=y > diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h index > 5bfdf4044b..5fb84f72a2 100644 > --- a/include/configs/dh_imx6.h > +++ b/include/configs/dh_imx6.h > @@ -53,12 +53,6 @@ > /* SATA Configs */ > #define CONFIG_LBA48 > > -/* SPI Flash Configs */ > -#if defined(CONFIG_SPL_BUILD) > -#undef CONFIG_DM_SPI > -#undef CONFIG_DM_SPI_FLASH > -#endif > - > /* UART */ > #define CONFIG_MXC_UART > #define CONFIG_MXC_UART_BASE UART1_BASE > -- > 2.25.1
Re: [PATCH v2 8/8] board: ns3: start sp805 watchdog service
On 22.06.20 11:33, Rayagonda Kokatanur wrote: Sure it takes time to update images. But all this should be possible with an actively serviced watchdog while still running in U-Boot. This is why we have all these WATCHDOG_RESET() calls sprinkled all over the system. If some code paths are missing such WDT triggering, then we should find and fix them. One more issue we are facing is, So did you work on fixing some of he missing WDT trigger calls? No, this issue we used to face before this patch. So you are suggesting to use WATCHDOF_RESET instead of stopping and starting the wdt. WATCHDOG_RESET will take care of resetting wdt in uboot. Yes. Thank you. And it won't lead to system reboot while running any test (ex-i2c read/write test) in uboot or debugging any issue in uboot ? Correct. The U-Boot code is "sprinkled" with these calls, easpecially ion places where looping might take some time (polling for input etc). So the WD timer is triggered / services via this WATCHDOG_RESET call to keep U-Boot running even with an active watchdog. What is the motivation to start watchdog service during uboot and keep on resetting it. Its similar to why this is done in the OS. There might be execution paths, where the bootloader might crash or hang (loading an image from some device etc). And this WD behavior makes sure, that the system does not hang but reboots in such cases. Thanks, Stefan
Re: [PATCH v2 8/8] board: ns3: start sp805 watchdog service
Hi Stefan,
On Mon, Jun 22, 2020 at 1:06 PM Stefan Roese wrote:
>
> Hi Rayagonda,
>
> On 21.06.20 12:19, Rayagonda Kokatanur wrote:
> > Hi Stefan,
> >
> > On Wed, Jun 17, 2020 at 6:40 PM Stefan Roese wrote:
> >>
> >> Hi Rayagonda,
> >>
> >> On 17.06.20 09:44, Rayagonda Kokatanur wrote:
> >>> Hi Stefan,
> >>>
> >>> On Thu, Jun 11, 2020 at 4:19 PM Stefan Roese wrote:
>
> Hi Rayagonda,
>
> On 10.06.20 18:35, Rayagonda Kokatanur wrote:
> > Hi Stefan,
> >
> > On Wed, Jun 10, 2020 at 4:33 PM Stefan Roese wrote:
> >>
> >> On 10.06.20 12:52, Rayagonda Kokatanur wrote:
> >>> Start sp805 watchdog service.
> >>>
> >>> Parse wdt timeout from env and dts, give precedence to env
> >>> timeout if defined. Set default timeout to 60s if both env
> >>> and dts doesn't specifiy timeout.
> >>>
> >>> Stop the WDT in board late init and start the
> >>> WDT service before giving control to Linux.
> >>
> >> I don't really understand, why you need such a board specific
> >> watchdog handling. You disable and enable it at some points? Why
> >> exactly? Usually the common WDT IF is used and it enables and
> >> services the WDT (if configured this way) until the OS is started.
> >> Then the OS needs to service the WDT. If the OS fails here (doesn't
> >> start correctly etc), then the board will reset via the WDT.
> >>
> >> So what is missing in the commin WDT IF for your setup?
> >
> > Our boot sequence is , first we check for valid Linux images in
> > Linux_part_1, Linux_part_2 and Linux_part_3 of eMMC partition tables.
> > If the Linux image is not available, then we check for a valid Linux
> > image on a USB device. If it is not available in USB devices, then we
> > attempt for PXE boot. We observe the WDT trigger for the PXE boot
> > case.
>
> So the WDT triggers a reset while you are booting via PXE boot? While
> a image is loaded via PXE boot (pxe command)? If this is the case,
> I would prefer to fix this issue (WDT reset while running a U-Boot
> command).
>
> > U-boot is used for updating the binaries (like fip.bin {ATF, optee,
> > and uboot}, Linux and file system). For updating, we use tftp
> > protocol, which will take more time and depends up on the network
> > speed.
> >
> > Hence we stop and start wdt service.
>
> Sure it takes time to update images. But all this should be possible
> with an actively serviced watchdog while still running in U-Boot.
> This is why we have all these WATCHDOG_RESET() calls sprinkled all over
> the system. If some code paths are missing such WDT triggering, then we
> should find and fix them.
> >>>
> >>> One more issue we are facing is,
> >>
> >> So did you work on fixing some of he missing WDT trigger calls?
> >
> > No, this issue we used to face before this patch.
> >
> > So you are suggesting to use WATCHDOF_RESET instead of stopping and
> > starting the wdt.
> > WATCHDOG_RESET will take care of resetting wdt in uboot.
>
> Yes.
Thank you.
>
> > And it won't
> > lead to system reboot while running any test (ex-i2c read/write test)
> > in uboot or debugging any issue in uboot ?
>
> Correct. The U-Boot code is "sprinkled" with these calls, easpecially
> ion places where looping might take some time (polling for input etc).
> So the WD timer is triggered / services via this WATCHDOG_RESET call
> to keep U-Boot running even with an active watchdog.
What is the motivation to start watchdog service during uboot and keep
on resetting it.
>
> Thanks,
> Stefan
>
> >>
> >>> If we stop at uboot and run some test or analyse some memory to debug
> >>> some issue, running test or debug may take any time.
> >>> So if we don't stop wdt service then it will trigger system reset.
> >>
> >> Are you talking about using U-Boot via the command line prompt?
> > Yes.
> >
> >> Using some "md" or other U-Boot commands to debug and test some
> >> issues / features? If yes, then this is absolutely common and
> >> should be supported by the U-Boot internal watchdog servicing. Its
> >> used on many boards for quite some time.
> >
> > Okay, thank you for the info, will check it.
> >
> >>
> >> Or are you talking about some other way to "stop at uboot"? If yes,
> >> what exactly do you mean?
> > No, not any other way.
> >
> > Thanks
> > Rayagonda
> >
> >>
> >> Thanks,
> >> Stefan
>
>
> Viele Grüße,
> Stefan
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
