[PATCH 3/5] bloblist: Tidy up the data alignment
The intention which bloblists is that each blob's data is aligned in
memory. At present it is only the headers that are aligned.
Update the code to correct this and add a little more documentation.
Signed-off-by: Simon Glass
---
common/bloblist.c | 32 ++--
test/bloblist.c | 38 +-
2 files changed, 63 insertions(+), 7 deletions(-)
diff --git a/common/bloblist.c b/common/bloblist.c
index c86ea029c8d..173f28d8ec9 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -11,6 +11,20 @@
#include
#include
+/*
+ * A bloblist is a single contiguous chunk of memory with a header
+ * (struct bloblist_hdr) and a number of blobs in it.
+ *
+ * Each blob starts on a BLOBLIST_ALIGN boundary relative to the start of the
+ * bloblist and consists of a struct bloblist_rec, some padding to the required
+ * alignment for the blog and then the actual data. The padding ensures that
the
+ * start address of the data in each blob is aligned as required. Note that
+ * each blob's *data* is aligned to BLOBLIST_ALIGN regardless of the alignment
+ * of the bloblist itself or the blob header.
+ *
+ * So far, only BLOBLIST_ALIGN alignment is supported.
+ */
+
DECLARE_GLOBAL_DATA_PTR;
static const char *const tag_name[] = {
@@ -73,9 +87,14 @@ static int bloblist_addrec(uint tag, int size, struct
bloblist_rec **recp)
{
struct bloblist_hdr *hdr = gd->bloblist;
struct bloblist_rec *rec;
- int new_alloced;
+ int data_start, new_alloced;
+
+ /* Figure out where the new data will start */
+ data_start = hdr->alloced + sizeof(*rec);
+ data_start = ALIGN(data_start, BLOBLIST_ALIGN);
- new_alloced = hdr->alloced + sizeof(*rec) + ALIGN(size, BLOBLIST_ALIGN);
+ /* Calculate the new allocated total */
+ new_alloced = data_start + ALIGN(size, BLOBLIST_ALIGN);
if (new_alloced >= hdr->size) {
log(LOGC_BLOBLIST, LOGL_ERR,
"Failed to allocate %x bytes size=%x, need size=%x\n",
@@ -83,15 +102,16 @@ static int bloblist_addrec(uint tag, int size, struct
bloblist_rec **recp)
return log_msg_ret("bloblist add", -ENOSPC);
}
rec = (void *)hdr + hdr->alloced;
- hdr->alloced = new_alloced;
rec->tag = tag;
- rec->hdr_size = sizeof(*rec);
+ rec->hdr_size = data_start - hdr->alloced;
rec->size = size;
rec->spare = 0;
/* Zero the record data */
- memset(rec + 1, '\0', rec->size);
+ memset((void *)rec + rec->hdr_size, '\0', rec->size);
+
+ hdr->alloced = new_alloced;
*recp = rec;
return 0;
@@ -139,7 +159,7 @@ void *bloblist_add(uint tag, int size)
if (bloblist_addrec(tag, size, &rec))
return NULL;
- return rec + 1;
+ return (void *)rec + rec->hdr_size;
}
int bloblist_ensure_size(uint tag, int size, void **blobp)
diff --git a/test/bloblist.c b/test/bloblist.c
index 271fe9f5d7f..3493e681f39 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -29,6 +29,8 @@ enum {
TEST_ADDR = CONFIG_BLOBLIST_ADDR,
TEST_BLOBLIST_SIZE = 0x100,
+
+ ERASE_BYTE = '\xff',
};
static struct bloblist_hdr *clear_bloblist(void)
@@ -41,7 +43,7 @@ static struct bloblist_hdr *clear_bloblist(void)
* to 0xff for testing purposes.
*/
hdr = map_sysmem(CONFIG_BLOBLIST_ADDR, TEST_BLOBLIST_SIZE);
- memset(hdr, '\xff', TEST_BLOBLIST_SIZE);
+ memset(hdr, ERASE_BYTE, TEST_BLOBLIST_SIZE);
memset(hdr, '\0', sizeof(*hdr));
return hdr;
@@ -292,6 +294,40 @@ static int bloblist_test_cmd_list(struct unit_test_state
*uts)
}
BLOBLIST_TEST(bloblist_test_cmd_list, 0);
+/* Test alignment of bloblist blobs */
+static int bloblist_test_align(struct unit_test_state *uts)
+{
+ struct bloblist_hdr *hdr;
+ int i;
+
+ /* At the start there should be no records */
+ hdr = clear_bloblist();
+ ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
+ ut_assertnull(bloblist_find(TEST_TAG, TEST_BLOBLIST_SIZE));
+
+ /* Check the alignment */
+ for (i = 0; i < 3; i++) {
+ int size = i * 3;
+ ulong addr;
+ char *data;
+ int j;
+
+ data = bloblist_add(i, size);
+ ut_assertnonnull(data);
+ addr = map_to_sysmem(data);
+ ut_asserteq(0, addr & (BLOBLIST_ALIGN - 1));
+
+ /* Only the bytes in the blob data should be zeroed */
+ for (j = 0; j < size; j++)
+ ut_asserteq(0, data[j]);
+ for (; j < BLOBLIST_ALIGN; j++)
+ ut_asserteq(ERASE_BYTE, data[j]);
+ }
+
+ return 0;
+}
+BLOBLIST_TEST(bloblist_test_align, 0);
+
int do_ut_bloblist(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[]
[PATCH 2/5] bloblist: Compare addresses rather than pointers in tests
When running these tests on sandbox any failures result in very large or
long pointer values which are a pain to work with. Map them to an address
so it is easier to diagnose failures.
Signed-off-by: Simon Glass
---
include/test/ut.h | 13 +
test/bloblist.c | 17 +
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/include/test/ut.h b/include/test/ut.h
index 3295cd4e548..3f2ee7514b8 100644
--- a/include/test/ut.h
+++ b/include/test/ut.h
@@ -224,6 +224,19 @@ int ut_check_console_dump(struct unit_test_state *uts, int
total_bytes);
} \
}
+/* Assert that two addresses (converted from pointers) are equal */
+#define ut_asserteq_addr(expr1, expr2) { \
+ ulong _val1 = map_to_sysmem(expr1); \
+ ulong _val2 = map_to_sysmem(expr2); \
+ \
+ if (_val1 != _val2) { \
+ ut_failf(uts, __FILE__, __LINE__, __func__, \
+#expr1 " = " #expr2, \
+"Expected %lx, got %lx", _val1, _val2);\
+ return CMD_RET_FAILURE; \
+ } \
+}
+
/* Assert that a pointer is NULL */
#define ut_assertnull(expr) { \
const void *_val = (expr); \
diff --git a/test/bloblist.c b/test/bloblist.c
index cbdc9db4ecf..271fe9f5d7f 100644
--- a/test/bloblist.c
+++ b/test/bloblist.c
@@ -95,26 +95,27 @@ static int bloblist_test_blob(struct unit_test_state *uts)
hdr = clear_bloblist();
ut_assertnull(bloblist_find(TEST_TAG, TEST_BLOBLIST_SIZE));
ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
+ ut_asserteq(map_to_sysmem(hdr), TEST_ADDR);
/* Add a record and check that we can find it */
data = bloblist_add(TEST_TAG, TEST_SIZE);
rec = (void *)(hdr + 1);
- ut_asserteq_ptr(rec + 1, data);
+ ut_asserteq_addr(rec + 1, data);
data = bloblist_find(TEST_TAG, TEST_SIZE);
- ut_asserteq_ptr(rec + 1, data);
+ ut_asserteq_addr(rec + 1, data);
/* Check the data is zeroed */
ut_assertok(check_zero(data, TEST_SIZE));
/* Check the 'ensure' method */
- ut_asserteq_ptr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
+ ut_asserteq_addr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
ut_assertnull(bloblist_ensure(TEST_TAG, TEST_SIZE2));
rec2 = (struct bloblist_rec *)(data + ALIGN(TEST_SIZE, BLOBLIST_ALIGN));
ut_assertok(check_zero(data, TEST_SIZE));
/* Check for a non-existent record */
- ut_asserteq_ptr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
- ut_asserteq_ptr(rec2 + 1, bloblist_ensure(TEST_TAG2, TEST_SIZE2));
+ ut_asserteq_addr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
+ ut_asserteq_addr(rec2 + 1, bloblist_ensure(TEST_TAG2, TEST_SIZE2));
ut_assertnull(bloblist_find(TEST_TAG_MISSING, 0));
return 0;
@@ -140,7 +141,7 @@ static int bloblist_test_blob_ensure(struct unit_test_state
*uts)
/* Check that we get the same thing again */
ut_assertok(bloblist_ensure_size_ret(TEST_TAG, &size, &data2));
ut_asserteq(TEST_SIZE, size);
- ut_asserteq_ptr(data, data2);
+ ut_asserteq_addr(data, data2);
/* Check that the size remains the same */
size = TEST_SIZE2;
@@ -164,8 +165,8 @@ static int bloblist_test_bad_blob(struct unit_test_state
*uts)
ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
data = hdr + 1;
data += sizeof(struct bloblist_rec);
- ut_asserteq_ptr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
- ut_asserteq_ptr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
+ ut_asserteq_addr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
+ ut_asserteq_addr(data, bloblist_ensure(TEST_TAG, TEST_SIZE));
return 0;
}
--
2.28.0.681.g6f77f65b4e-goog
[PATCH 4/5] bloblist: Allow custom alignment for blobs
Some blobs need a larger alignment than the default. For example, ACPI
tables often start at a 4KB boundary. Add support for this.
Update the size of the test blob to allow these larger records.
Signed-off-by: Simon Glass
---
common/bloblist.c | 32
include/bloblist.h | 6 --
test/bloblist.c| 42 +-
3 files changed, 57 insertions(+), 23 deletions(-)
diff --git a/common/bloblist.c b/common/bloblist.c
index 173f28d8ec9..33b58623807 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -83,18 +83,25 @@ static struct bloblist_rec *bloblist_findrec(uint tag)
return NULL;
}
-static int bloblist_addrec(uint tag, int size, struct bloblist_rec **recp)
+static int bloblist_addrec(uint tag, int size, int align,
+ struct bloblist_rec **recp)
{
struct bloblist_hdr *hdr = gd->bloblist;
struct bloblist_rec *rec;
int data_start, new_alloced;
+ if (!align)
+ align = BLOBLIST_ALIGN;
+
/* Figure out where the new data will start */
- data_start = hdr->alloced + sizeof(*rec);
- data_start = ALIGN(data_start, BLOBLIST_ALIGN);
+ data_start = map_to_sysmem(hdr) + hdr->alloced + sizeof(*rec);
+
+ /* Align the address and then calculate the offset from ->alloced */
+ data_start = ALIGN(data_start, align) - map_to_sysmem(hdr);
/* Calculate the new allocated total */
- new_alloced = data_start + ALIGN(size, BLOBLIST_ALIGN);
+ new_alloced = data_start + ALIGN(size, align);
+
if (new_alloced >= hdr->size) {
log(LOGC_BLOBLIST, LOGL_ERR,
"Failed to allocate %x bytes size=%x, need size=%x\n",
@@ -117,7 +124,8 @@ static int bloblist_addrec(uint tag, int size, struct
bloblist_rec **recp)
return 0;
}
-static int bloblist_ensurerec(uint tag, struct bloblist_rec **recp, int size)
+static int bloblist_ensurerec(uint tag, struct bloblist_rec **recp, int size,
+ int align)
{
struct bloblist_rec *rec;
@@ -130,7 +138,7 @@ static int bloblist_ensurerec(uint tag, struct bloblist_rec
**recp, int size)
} else {
int ret;
- ret = bloblist_addrec(tag, size, &rec);
+ ret = bloblist_addrec(tag, size, align, &rec);
if (ret)
return ret;
}
@@ -152,22 +160,22 @@ void *bloblist_find(uint tag, int size)
return (void *)rec + rec->hdr_size;
}
-void *bloblist_add(uint tag, int size)
+void *bloblist_add(uint tag, int size, int align)
{
struct bloblist_rec *rec;
- if (bloblist_addrec(tag, size, &rec))
+ if (bloblist_addrec(tag, size, align, &rec))
return NULL;
return (void *)rec + rec->hdr_size;
}
-int bloblist_ensure_size(uint tag, int size, void **blobp)
+int bloblist_ensure_size(uint tag, int size, int align, void **blobp)
{
struct bloblist_rec *rec;
int ret;
- ret = bloblist_ensurerec(tag, &rec, size);
+ ret = bloblist_ensurerec(tag, &rec, size, align);
if (ret)
return ret;
*blobp = (void *)rec + rec->hdr_size;
@@ -179,7 +187,7 @@ void *bloblist_ensure(uint tag, int size)
{
struct bloblist_rec *rec;
- if (bloblist_ensurerec(tag, &rec, size))
+ if (bloblist_ensurerec(tag, &rec, size, 0))
return NULL;
return (void *)rec + rec->hdr_size;
@@ -190,7 +198,7 @@ int bloblist_ensure_size_ret(uint tag, int *sizep, void
**blobp)
struct bloblist_rec *rec;
int ret;
- ret = bloblist_ensurerec(tag, &rec, *sizep);
+ ret = bloblist_ensurerec(tag, &rec, *sizep, 0);
if (ret == -ESPIPE)
*sizep = rec->size;
else if (ret)
diff --git a/include/bloblist.h b/include/bloblist.h
index 57c0794793b..9ad5678aff8 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -124,10 +124,11 @@ void *bloblist_find(uint tag, int size);
*
* @tag: Tag to add (enum bloblist_tag_t)
* @size: Size of the blob
+ * @align: Alignment of the blob (in bytes), 0 for default
* @return pointer to the newly added block, or NULL if there is not enough
* space for the blob
*/
-void *bloblist_add(uint tag, int size);
+void *bloblist_add(uint tag, int size, int align);
/**
* bloblist_ensure_size() - Find or add a blob
@@ -137,10 +138,11 @@ void *bloblist_add(uint tag, int size);
* @tag: Tag to add (enum bloblist_tag_t)
* @size: Size of the blob
* @blobp: Returns a pointer to blob on success
+ * @align: Alignment of the blob (in bytes), 0 for default
* @return 0 if OK, -ENOSPC if it is missing and could not be added due to lack
* of space, or -ESPIPE it exists but has the wrong size
*/
-int bloblist_ensure_size(uint tag, int size, void **blobp);
+int bloblist_ensure_size(uint tag, int size
[PATCH 5/5] bloblist: Fix up a few comments
Adjust a few comments to make the meaning clearer.
Signed-off-by: Simon Glass
---
include/bloblist.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/bloblist.h b/include/bloblist.h
index 9ad5678aff8..2ede11b87a9 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -60,7 +60,7 @@ enum bloblist_tag_t {
* the bloblist can grow up to this size. This starts out as
* sizeof(bloblist_hdr) since we need at least that much space to store a
* valid bloblist
- * @spare: Space space
+ * @spare: Spare space (for future use)
* @chksum: CRC32 for the entire bloblist allocated area. Since any of the
* blobs can be altered after being created, this checksum is only valid
* when the bloblist is finalised before jumping to the next stage of boot.
@@ -107,7 +107,7 @@ struct bloblist_rec {
* Searches the bloblist and returns the blob with the matching tag
*
* @tag: Tag to search for (enum bloblist_tag_t)
- * @size: Expected size of the blob
+ * @size: Expected size of the blob, or 0 for any size
* @return pointer to blob if found, or NULL if not found, or a blob was found
* but it is the wrong size
*/
--
2.28.0.681.g6f77f65b4e-goog
[PATCH 1/5] bloblist: Add a command
It is helpful to be able to see basic statistics about the bloblist and
also to list its contents. Add a 'bloblist' command to handle this.
Put the display functions in the bloblist modules rather than in the
command code itself. That allows showing a list from SPL, where commands
are not available.
Also make bloblist_first/next_blob() static as they are not used outside
this file.
Signed-off-by: Simon Glass
---
cmd/Kconfig| 9 +++
cmd/Makefile | 1 +
cmd/bloblist.c | 37 +++
common/bloblist.c | 62 +++---
include/bloblist.h | 32
test/bloblist.c| 59 ++-
6 files changed, 196 insertions(+), 4 deletions(-)
create mode 100644 cmd/bloblist.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0761dbb7460..26be32d2a59 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -631,6 +631,15 @@ config CMD_BINOP
Compute binary operations (xor, or, and) of byte arrays of arbitrary
size from memory and store the result in memory or the environment.
+config CMD_BLOBLIST
+ bool "bloblist"
+ default y if BLOBLIST
+ help
+ Show information about the bloblist, a collection of binary blobs
+ held in memory that persist between SPL and U-Boot. In the case of
+ x86 devices the bloblist can be used to hold ACPI tables so that they
+ remain available in memory.
+
config CMD_CRC32
bool "crc32"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index 3a9c9747c94..2892f0fd803 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_CMD_BDI) += bdinfo.o
obj-$(CONFIG_CMD_BEDBUG) += bedbug.o
obj-$(CONFIG_CMD_BIND) += bind.o
obj-$(CONFIG_CMD_BINOP) += binop.o
+obj-$(CONFIG_CMD_BLOBLIST) += bloblist.o
obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
obj-$(CONFIG_CMD_BMP) += bmp.o
obj-$(CONFIG_CMD_BOOTCOUNT) += bootcount.o
diff --git a/cmd/bloblist.c b/cmd/bloblist.c
new file mode 100644
index 000..bb2e682ff84
--- /dev/null
+++ b/cmd/bloblist.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Command-line access to bloblist features
+ *
+ * Copyright 2020 Google LLC
+ * Written by Simon Glass
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int do_bloblist_info(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ bloblist_show_stats();
+
+ return 0;
+}
+
+static int do_bloblist_list(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ bloblist_show_list();
+
+ return 0;
+}
+
+static char bloblist_help_text[] =
+ "info - show information about the bloblist\n"
+ "bloblist list - list blobs in the bloblist";
+
+U_BOOT_CMD_WITH_SUBCMDS(bloblist, "Bloblists", bloblist_help_text,
+ U_BOOT_SUBCMD_MKENT(info, 1, 1, do_bloblist_info),
+ U_BOOT_SUBCMD_MKENT(list, 1, 1, do_bloblist_list));
diff --git a/common/bloblist.c b/common/bloblist.c
index 99501951e0c..c86ea029c8d 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -13,15 +13,31 @@
DECLARE_GLOBAL_DATA_PTR;
-struct bloblist_rec *bloblist_first_blob(struct bloblist_hdr *hdr)
+static const char *const tag_name[] = {
+ [BLOBLISTT_NONE]= "(none)",
+ [BLOBLISTT_EC_HOSTEVENT]= "EC host event",
+ [BLOBLISTT_SPL_HANDOFF] = "SPL hand-off",
+ [BLOBLISTT_VBOOT_CTX] = "Chrome OS vboot context",
+ [BLOBLISTT_VBOOT_HANDOFF] = "Chrome OS vboot hand-off",
+};
+
+const char *bloblist_tag_name(enum bloblist_tag_t tag)
+{
+ if (tag < 0 || tag >= BLOBLISTT_COUNT)
+ return "invalid";
+
+ return tag_name[tag];
+}
+
+static struct bloblist_rec *bloblist_first_blob(struct bloblist_hdr *hdr)
{
if (hdr->alloced <= hdr->hdr_size)
return NULL;
return (struct bloblist_rec *)((void *)hdr + hdr->hdr_size);
}
-struct bloblist_rec *bloblist_next_blob(struct bloblist_hdr *hdr,
- struct bloblist_rec *rec)
+static struct bloblist_rec *bloblist_next_blob(struct bloblist_hdr *hdr,
+ struct bloblist_rec *rec)
{
ulong offset;
@@ -233,6 +249,46 @@ int bloblist_finish(void)
return 0;
}
+void bloblist_get_stats(ulong *basep, ulong *sizep, ulong *allocedp)
+{
+ struct bloblist_hdr *hdr = gd->bloblist;
+
+ *basep = map_to_sysmem(gd->bloblist);
+ *sizep = hdr->size;
+ *allocedp = hdr->alloced;
+}
+
+static void show_value(const char *prompt, ulong value)
+{
+ printf("%s:%*s %-5lx ", prompt, 8 - (int)strlen(prompt), "", value);
+ print_size(value, "\n");
+}
+
+void bloblist_show_stats(void)
+{
+ ulong base, size, alloced;
+
+ bloblist_get_stats(&base, &size, &alloced);
+ printf("base: %lx\
[PATCH 0/5] bloblist: Add alignment control and a command
This little series adds a 'bloblist' command to allow listing of bloblists. It also provides a way to set the alignment of the data in each blob. This means that it is possible to align a blob's data to a 4KB boundary, for example. Simon Glass (5): bloblist: Add a command bloblist: Compare addresses rather than pointers in tests bloblist: Tidy up the data alignment bloblist: Allow custom alignment for blobs bloblist: Fix up a few comments cmd/Kconfig| 9 +++ cmd/Makefile | 1 + cmd/bloblist.c | 37 common/bloblist.c | 120 ++-- include/bloblist.h | 42 +++-- include/test/ut.h | 13 test/bloblist.c| 148 - 7 files changed, 333 insertions(+), 37 deletions(-) create mode 100644 cmd/bloblist.c -- 2.28.0.681.g6f77f65b4e-goog
Re: [PATCH 1/1] sandbox: support CTRL-C processing in U-Boot
Hi Heinrich, On Sat, 19 Sep 2020 at 12:07, Heinrich Schuchardt wrote: > > On 9/19/20 3:26 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Fri, 18 Sep 2020 at 22:19, Heinrich Schuchardt > > wrote: > >> > >> Am 19. September 2020 04:59:46 MESZ schrieb Simon Glass > >> : > >>> Hi Heinrich, > >>> > >>> On Thu, 17 Sep 2020 at 12:04, Heinrich Schuchardt > >>> wrote: > > Currently if SIGINT is received, it terminates U-Boot. This does not > >>> allow > testing the handling of CTRL-C in U-Boot and in UEFI applications. > It is especially annoying when working with the 'mm' command. > > Let the serial console driver provide character 0x03 if SIGINT > >>> occurs. We > can still exit U-Boot using the reset or poweroff command. > > Adjust the sandbox test_ctrl_c() Python test accordingly. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/os.c | 15 --- > drivers/serial/sandbox.c | 11 --- > include/os.h | 14 ++ > test/py/tests/test_sandbox_exit.py | 10 +- > 4 files changed, 43 insertions(+), 7 deletions(-) > >>> > >>> I'm sorry but I still do want Ctrl-C to work. How about adding a short > >>> option to change the terminal mode? > >>> > >>> Regards, > >>> Simon > >> > >> > >> On QEMU you quit via X. Can we use the same for the sandbox? > > > > I just don't like programs that refused to quit when asked I use> Ctrl-C > > all the time. Can you not use the -t options to get what you > > want? Perhaps we could have an environment variable too? > > Sorry, I was not aware of the -t option. > > ./u-boot -t raw -d arch/sandbox/dts/test.dtb > > behaves according to my preferences. OK great! If you want an environment variable we could add that too. Regards, Simon
Re: Cold boot consistently fails to load file from SD
Hi Daniel,
comments inline below.
On 9/19/20 9:15 PM, Daniel Schwierzeck wrote:
> Hi Mauro,
>
> Am Samstag, den 19.09.2020, 15:39 +0200 schrieb Mauro Condarelli:
>
>> Hi,
>> I'm facing a new problem for my Mt7628/vocore2 target.
>>
>> I moved the Linux kernel from a ext4 partition to the "proper" SquashFS
>> partition (I say "proper" because I'm using a dual-system with fallback to
>> avoid updating the currently working rootFS and kernel lies into rootFS).
>>
>> I am using u-boot v2020.10-rc3 plus the attached patches (one pertains
>> SquashFS).
>>
>> Problem is a real cold boot (target off for more than one minute) leads to a
>> load failure for the kernel. A warm boot ("reboot" from a running Linux) or
>> a not-so-cold boot (turn target off and power it on again after a few
>> seconds) seems to work as expected.
> which distro or Linux version do you use? Can you provide a full boot
> log?
I am using a self-compiled Buildroot RootFS, but this is hardly a problem.
Error is in pain u-boot.
I try to load Linux kernel in memory (from SD, from SquashFS) and this fails.
Linux has no chance to start at all.
> Linux MIPS had a bug with setting up memory for its exception vectors
> and handlers if the CPU didn't report support for vectored interrupts.
> mtmips is one of those CPUs. AFAIK this should have been fixed in
> mainline since some months. Could be one reason.
I am using v2020.10-rc3 which should be "recent enough"... or am I wrong?
> You could also try to disable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE in
> U-Boot.
>
> Stefan also had cache issues on the Gardena board. He solved it with
> some memory allocation and copying, see arch/mips/mach-mtmips/cpu.c.
>
> The cmd_cache interface is not supported on MIPS as there is no
> reliable way to disable or enable caches or to separately control i-
> cache and d-cache.
>
> Can you send patches 0001 and 0002 to the mailing list in the proper
> way so that patchwork can pick them up? I'd like to prepare a small
> bugfix pull request for v2020.10. Thanks.
I'll do that tomorrow 'couse I'm too groggy now to be reliable ;)
Thanks
Mauro
Re: RPi4 U-Boot freeze
On 9/19/20 7:55 AM, Stefan Agner wrote:
> On 2020-09-14 10:15, Matthias Brugger wrote:
>> On 10/09/2020 23:12, Stefan Agner wrote:
>>> On 2020-09-07 16:36, Peter Robinson wrote:
> Any thoughts on this issue?
Any reason why you're using 2020.01 and not at least 2020.07, or at
least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has
changed quite a bit since then I suspect.
>>>
>>> Hi Peter,
>>>
>>> It's a stable release and we support a couple of devices with the same
>>> U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well.
>>>
>>> We are on 2020.07 on development branch, and it does work fine there. So
>>> I thought it can't be that hard, just bisect and backport whatever fixes
>>> it... Unfortunately, it seems that there is no particular commit which
>>> fixes it (the bisect ended up in a random unrelated commit, and it seems
>>> that the issue appears/disappears depending on alignment/size...).
>>>
>>> I also did applied pretty much every RPi4 related commit made after
>>> 2020.01 up until master back to 2020.01, no success either.
>>>
>>
>> Which version of the Raspberry Pi firmware did you use?
>> Unfortunately changes in the FW breaks stuff on U-Boot from time to time.
>>
>
> Ok, I am now able to reproduce the issue on master as well as 2020.07
> with standard rpi_4_32b_defconfig, but I still need to have parts of a
> change which seems to trigger the issue in. From what I can tell, the
> change *really* should not lead to a freeze. The change is just
> accessing global variables from the data section... (see below).
>
> To me it still seems as if relocation somehow did not work correctly in
> one way or another.
>
> Are there maybe restrictions in U-Boot when the data section can be
> accessed? E.g. is it not legal to access the data section from the
> serial driver?
One thing bit me recently, and might be relevant here. Because
putc_retry is initialized to zero, it is located in bss and not data.
In U-Boot, bss is not accessable before relocation. The serial driver is
one of the devices which U-Boot needs before relocating, so setting
putc_retry may overwrite data in the device tree. To get around this,
you could try adding __attribute__((section(".data"))) to that variable.
--Sean
>
>
> diff --git a/drivers/serial/serial_bcm283x_mu.c
> b/drivers/serial/serial_bcm283x_mu.c
> index 8a4af87eb6..74de6801ab 100644
> --- a/drivers/serial/serial_bcm283x_mu.c
> +++ b/drivers/serial/serial_bcm283x_mu.c
> @@ -50,7 +50,8 @@ struct bcm283x_mu_regs {
> struct bcm283x_mu_priv {
> struct bcm283x_mu_regs *regs;
> };
> -
> +static char *fs_argv[15];
> +static uint32_t putc_retry = 0;
> static int bcm283x_mu_serial_getc(struct udevice *dev);
>
> static int bcm283x_mu_serial_setbrg(struct udevice *dev, int baudrate)
> @@ -95,6 +96,8 @@ static int bcm283x_mu_serial_putc(struct udevice *dev,
> const char data)
> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
> struct bcm283x_mu_regs *regs = priv->regs;
>
> + putc_retry++;
> +
> /* Wait until there is space in the FIFO */
> if (!(readl(®s->lsr) & BCM283X_MU_LSR_TX_EMPTY))
> return -EAGAIN;
> @@ -162,6 +165,10 @@ static int bcm283x_mu_serial_probe(struct udevice
> *dev)
> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
> fdt_addr_t addr;
>
> + /* Make sure compiler does not optimize out this fs_argv
> instance */
> + if (fs_argv[0])
> + fs_argv[0] = "test";
> +
> /* Don't spawn the device if it's not muxed */
> if (!bcm283x_is_serial_muxed())
> return -ENODEV;
>
> Most curious of all, it seems that the name (!!!) of the variable
> fs_argv matters! I am not sure if that changes order of variables in
> data section or something. I can also reproduce the issue with two
> compilers (GCC 8.3 and GCC 9.2), so a compiler error seems somewhat
> unlikely...
>
> Any ideas? I am a bit out of idea how to debug this (I guess JTAG/gdb
> might help, but I don't have such a setup).
>
> FWIW, I plan to just drop the change which seems to at least partially
> cause the isssue
> (https://github.com/home-assistant/operating-system/blob/dev/buildroot-external/board/raspberrypi/patches/uboot/0002-avoid-block-uart-write.patch).
> Still I think there is something wrong which will show itself someday in
> a certain configuration.
>
> --
> Stefan
>
>
>> Regards,
>> Mathias
>>
>>> I fear that the problem in fact is still in master, but only appears if
>>> certain things align a certain way... That is why I thought I bring it
>>> up, to see if anybody else has noticed something along this lines. We do
>>> have a rather trimmed down configuration, which might make the problem
>>> appear more (fit in a D cache...).
>>>
>>> I probably will just disable cached around relocation for 2020.01 and
>>> see if it resurfaces on development branch.
>>>
>>> --
>>> Stefan
>>>
>>>
> Ju
Re: [PATCH v1 00/10] mips: octeon: Add bootoctlinux command for Octeon Linux kernel booting
Am Donnerstag, den 20.08.2020, 07:21 +0200 schrieb Stefan Roese: > This patchset adds the platforms specific bootoctlinux command, which is > used to boot the MIPS Octeon Linux kernel (4.9.x). A special command is > necessary here, as very platform specific data is passed to the kernel > via the bootinfo / bootmem format. This patchset also includes various > required infrastructure code for this (octeon-feature, coremask, > bootinfo). The code for booting the additional cores is also included > in this patchset. > > Tested on Octeon 7304 EBB with all 16 cores. > > Thanks, > Stefan > > > Aaron Williams (7): > mips: octeon: Add header cvmx-regs.h > mips: octeon: Add header octeon-feature.h > mips: octeon: Add header cvmx-fuse.h > mips: octeon: Add header cvmx-bootinfo.h > mips: octeon: Add coremask support > mips: octeon: Add bootmem support > mips: octeon: Add bootoctlinux command > > Stefan Roese (3): > mips: octeon: octeon-model.h: Enable inclusion from assembler files > mips: octeon: lowlevel_init.S: Add NMI handling code for SMP Linux > booting > mips: octeon: octeon_common.h: Increase CONFIG_SYS_BOOTM_LEN > > arch/mips/mach-octeon/Makefile|3 + > arch/mips/mach-octeon/bootoctlinux.c | 661 > arch/mips/mach-octeon/cvmx-bootmem.c | 1460 + > arch/mips/mach-octeon/cvmx-coremask.c | 366 + > .../mach-octeon/include/mach/bootoct_cmd.h| 54 + > .../mach-octeon/include/mach/cvmx-bootinfo.h | 350 > .../mach-octeon/include/mach/cvmx-bootmem.h | 533 ++ > .../mach-octeon/include/mach/cvmx-coremask.h | 752 + > .../mips/mach-octeon/include/mach/cvmx-fuse.h | 71 + > .../mips/mach-octeon/include/mach/cvmx-regs.h | 144 ++ > .../mach-octeon/include/mach/octeon-feature.h | 442 + > .../mach-octeon/include/mach/octeon-model.h |4 + > arch/mips/mach-octeon/lowlevel_init.S | 76 + > include/configs/octeon_common.h |2 + > 14 files changed, 4918 insertions(+) > create mode 100644 arch/mips/mach-octeon/bootoctlinux.c > create mode 100644 arch/mips/mach-octeon/cvmx-bootmem.c > create mode 100644 arch/mips/mach-octeon/cvmx-coremask.c > create mode 100644 arch/mips/mach-octeon/include/mach/bootoct_cmd.h > create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-bootinfo.h > create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-bootmem.h > create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-coremask.h > create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-fuse.h > create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-regs.h > create mode 100644 arch/mips/mach-octeon/include/mach/octeon-feature.h > series applied to u-boot-mips/next, thanks. I've fixed the usage of gd->bd->bi_memstart to gd->ram_base to be compatible with your gd->bd->bi_mem* cleanup series. -- - Daniel
Re: [PATCH v3 0/9] mips: Add Octeon DDR4 init code
Am Mittwoch, den 02.09.2020, 08:29 +0200 schrieb Stefan Roese:
> This patch adds the DDR4 init code. It is ported from the 2013 Cavium /
> Marvell U-Boot version with no functional change. This was done
> intentionally, as this code is very large and complex and is known to
> work on many boards "as-is". So any functional change might have
> introduced (hidden) incompatibilities.
>
> Please note that the code has undergone many hours (read many days) of
> code cleanup and restructuring. Unfortunately its still not 100%
> checkpatch clean, as some warnings and checks can practically not be
> removed / addresses, like these here:
>
> CHECK: Prefer kernel type 's8' over 'int8_t'
> -> 's8' can't be used on MIPS platforms, as its a register macro
>
> or:
>
> WARNING: Too many leading tabs - consider code refactoring
> + while (xor != 0) {
> -> I've restructured the code already and its very hard to remove all
>these "Too many leading tabs" warnings.
>
> or other warnings / checks.
>
> But compared to the original code in much better shape (checkpatch
> wise). I would have liked to include a checkpatch summary in this cover-
> letter, showing the "before" (original code) and "after" (this code)
> numbers, but unfortunately currently running checkpatch on the really
> big file (octeon3_lmc.c) leads to many false errors. I can only suspect
> that checkpatch has an issue handling this big file because of its size.
>
> This code is tested on the Octeon3 EBB7304 EVK and works without any
> known issues with 1 or 2 DDR4 DIMM configurations (8 & 16 GiB).
>
> Thanks,
> Stefan
>
> Changes in v3:
> - Remove "https://spdx.org/licenses"; line
> - Move multiple comment blocks into one
> - Remove "https://spdx.org/licenses"; line
> - Remove "https://spdx.org/licenses"; line
> - Remove inclusion of "common.h"
> - Remove duplicate comment line
> - Remove "test-only" comment (leftover after cleanup)
> - Remove "https://spdx.org/licenses"; line
> - Remove inclusion of "common.h"
> - Remove all internal defines that resulted in dead code, as they have
> never been changed via external config files or Kconfig. This results
> in a smaller (~13KiB of source code saved, > 450 lines removed) and
> much cleaner code base.
> - Remove "https://spdx.org/licenses"; line
> - Remove "https://spdx.org/licenses"; line
> - Remove inclusion of "common.h"
>
> Changes in v2:
> - Some unsupported Octeon families removed (only Octeon 2 & 3 supported
> in general)
> - Some unsupported Octeon families removed (only Octeon 2 & 3 supported
> in general)
> - Use readq/writeq in cvmx_read64_uint64/cvmx_write64_uint64 instead of
> readl/writel
> - Don't re-init after relocation
> - Some unsupported Octeon families removed (only Octeon 2 & 3 supported
> in general)
> - Only map 256MiB of RAM in U-Boot and print total size as well
> - Add year to copyright line
>
> Aaron Williams (6):
> mips: octeon: Add octeon-model.h header
> mips: octeon Add cvmx/cvmx-lmcx-defs.h header
> mips: octeon: Add octeon_ddr.h header
> ram: octeon: Add MIPS Octeon3 DDR4 support (part 1/3)
> ram: octeon: Add MIPS Octeon3 DDR4 support (part 2/3)
> ram: octeon: Add MIPS Octeon3 DDR4 support (part 3/3)
>
> Stefan Roese (3):
> mips: octeon: dts: mrvl,cn73xx.dtsi: Add memory controller DT node
> mips: octeon: dram.c: Add RAM driver support
> mips: octeon: octeon_ebb7304: Add DDR4 support
>
> arch/mips/dts/mrvl,cn73xx.dtsi|17 +
> arch/mips/mach-octeon/dram.c |72 +-
> .../include/mach/cvmx/cvmx-lmcx-defs.h| 4574 +++
> .../mach-octeon/include/mach/octeon-model.h | 313 +
> .../mach-octeon/include/mach/octeon_ddr.h | 982 ++
> board/Marvell/octeon_ebb7304/board.c |25 +-
> board/Marvell/octeon_ebb7304/board_ddr.h | 447 +
> configs/octeon_ebb7304_defconfig | 3 +
> drivers/ram/Kconfig | 1 +
> drivers/ram/Makefile | 2 +
> drivers/ram/octeon/Kconfig|17 +
> drivers/ram/octeon/Makefile | 8 +
> drivers/ram/octeon/dimm_spd_eeprom.c | 407 +
> drivers/ram/octeon/octeon3_lmc.c | 11030
> drivers/ram/octeon/octeon_ddr.c | 2728
> include/configs/octeon_common.h |11 +-
> 16 files changed, 20622 insertions(+), 15 deletions(-)
> create mode 100644 arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h
> create mode 100644 arch/mips/mach-octeon/include/mach/octeon-model.h
> create mode 100644 arch/mips/mach-octeon/include/mach/octeon_ddr.h
> create mode 100644 board/Marvell/octeon_ebb7304/board_ddr.h
> create mode 100644 drivers/ram/octeon/Kconfig
> create mode 100644 drivers/ram/octeon/Makefile
> create mode 100644 drivers/ram/octeon/dimm_spd_eeprom.c
> create mode 100644 drivers/ram/octeon/octeon3_lmc.c
> cre
Re: [PATCH v4 0/8] mips/usb: Add Octeon xHCI USB support
Am Montag, den 24.08.2020, 13:04 +0200 schrieb Stefan Roese: > This patchset adds xHCI USB support for MIPS Octeon. After the xHCI code > has been fixed to support mapped addresses (virt != phys), this patchset > now adds the missing code pieces to enable USB support on Octeon. This > is mainly the USB glue code for Octeon and the MIPS platform specific > changes (cache fixes, platform specific swapping based on address areas, > DT & defcopnfig changes). > > Thanks, > Stefan > > Changes in v4: > - Add Reviewed-by tag from Bin > - Add Reviewed-by tag from Bin > - Correct another missed multi-line comment style > > Changes in v3: > - Add Reviewed-by tag from Bin > - Minor corrections to the commit text as suggested by Bin > - Minor corrections of the commit text as suggested by Bin > - Minor corrections in comments as suggested by Bin > - Removed empty driver remove() function > - Use macros for clock values instead of numbers > - Add Reviewed-by tag from Bin > - Correct multi-line comment style > > Changes in v2: > - Completely remove BUG_ON() for this trans_event.buffer check > - Reword commit text > - Only use SPDX format for license info > > Stefan Roese (8): > usb: xhci: xhci-dwc3.c: Use dev_remap_addr() instead of dev_get_addr() > usb: xhci: xhci_bulk_tx: Don't "BUG" when comparing addresses > usb: xhci: octeon: Add DWC3 glue layer for Octeon > mips: octeon: cpu.c: Add table for selective swapping > mips: octeon: Add mangle-port.h > mips: octeon: cache.c: Flush all pending writes in > flush_dcache_range() > mips: octeon: Add USB DT nodes > mips: octeon: octeon_ebb7304_defconfig: Enable USB support > > arch/mips/dts/mrvl,cn73xx.dtsi | 60 +++ > arch/mips/dts/mrvl,octeon-ebb7304.dts | 24 ++ > arch/mips/mach-octeon/cache.c | 12 +- > arch/mips/mach-octeon/cpu.c | 21 ++ > arch/mips/mach-octeon/include/mangle-port.h | 56 +++ > configs/octeon_ebb7304_defconfig| 17 + > drivers/usb/host/Kconfig| 9 + > drivers/usb/host/Makefile | 1 + > drivers/usb/host/dwc3-octeon-glue.c | 393 > drivers/usb/host/xhci-dwc3.c| 2 +- > drivers/usb/host/xhci-ring.c| 2 - > 11 files changed, 588 insertions(+), 9 deletions(-) > create mode 100644 arch/mips/mach-octeon/include/mangle-port.h > create mode 100644 drivers/usb/host/dwc3-octeon-glue.c > series applied to u-boot-mips, thanks. -- - Daniel
[BUG] sandbox: './u-boot -l ' fails
Hello Simon, when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run out of the box? $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39 +0200) Model: sandbox DRAM: 128 MiB Warning: host_lo MAC addresses don't match: Address in ROM is 26:4b:ca:6c:98:f4 Address in environment is 00:00:11:22:33:44 Warning: host_virbr0 MAC addresses don't match: Address in ROM is ee:3e:c9:ce:1f:9c Address in environment is 00:00:11:22:33:45 Warning: host_docker0 MAC addresses don't match: Address in ROM is c2:85:07:7b:9a:18 Address in environment is 00:00:11:22:33:46 WDT: Not found! MMC: No output after this point. The problem also exists with U-Boot v2020.07, v2019.10, v2018.11. CONFIG_SANDBOX_SDL=y SDL_InitSubSystem() never returns. It is looping somewhere in U-Boot's __serial_getc(). I wonder how it gets there without returning from the function. I compiled SDL2.cpp from https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18 with g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test and it runs fine showing an X11 windows with red background. So there seems to be no general problem with the SDL2 library. Best regards Heinrich
Re: [PATCH v2 2/2] mips: dts: Fix PIC32MZDA GPIO register definitions
Am Dienstag, den 01.09.2020, 18:02 + schrieb John Robertson: > The GPIO bank name for banks J and K are not correct when using the > 'gpio' command from the console. > > The driver derives the bank name from the device tree instance string by > using the instance value and adding 'A': gpio0@xxaddrxx is Bank A, > gpio1@yyaddryy is Bank B and so on. > > On the PIC32, there is no Bank I so instances 8 and 9 need to be > incremented as a minimum change. > > An alternative (less opaque) implementation would be to use a bank-name > property instead but this would require modifying the driver code too. > > Signed-off-by: John Robertson > --- > > arch/mips/dts/pic32mzda.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > applied to u-boot-mips/fixes, thanks. -- - Daniel
Re: [PATCH v2 1/2] mips: dts: Fix PIC32MZDA GPIO register definitions
Am Dienstag, den 01.09.2020, 18:02 + schrieb John Robertson: > GPIO state cannot be changed via the device tree (e.g. with gpio-hog) or > using the 'gpio' command from the console. > > The root cause is a discrepancy between the driver and the device tree: > the driver code expects an absolute I/O address in the property, > while the device tree defines the address relative to a declaration in > the parent pinctrl node. > > Changing the device tree to fix a driver issue would normally be wrong, > however: > - I have run the first version of U-Boot in which this driver appears > (v2016.03) and the same problem exists, so this is not a regression; > - There is no code that references a parent device tree node that might > suggest the intent of the author was to parse the DT as it exists now; > - The equivalent Linux PIC32 GPIO driver also uses absolute addresses > for the GPIO property. This change brings the U-Boot DT more > into line with Linux. > > Additionally, the data sheet (Microchip ref. 60001361H) shows that the > register set to control a GPIO bank spans 0xE0 bytes, but the device > tree specified size is only 0x48 bytes. > > Signed-off-by: John Robertson > --- > Changes in v2 > - Split patch > - Document change more fully > > arch/mips/dts/pic32mzda.dtsi | 45 ++-- > 1 file changed, 22 insertions(+), 23 deletions(-) > applied to u-boot-mips/fixes, thanks. -- - Daniel
Re: [PATCH] mips: dts: Fix device tree warnings for PIC32MZDA
Am Dienstag, den 01.09.2020, 04:14 + schrieb John Robertson: > Signed-off-by: John Robertson > --- > > arch/mips/dts/pic32mzda.dtsi | 11 +++ > 1 file changed, 11 insertions(+) > applied to u-boot-mips/fixes, thanks. -- - Daniel
Re: [PATCH v3 3/4] mmc: pic32: Refresh PIC32 MMC driver
Am Dienstag, den 01.09.2020, 02:55 + schrieb John Robertson: > The PIC32MZ DA Starter Kit does not need the card detect workaround > because the SDCD signal line is connected properly. Disable the > workaround in this case. > > Signed-off-by: John Robertson > --- > > arch/mips/dts/pic32mzda_sk.dts | 1 + > 1 file changed, 1 insertion(+) > applied to u-boot-mips/fixes, thanks. Note: I've updated the commit subject to "MIPS: pic32mzdask: disable SDHCI SDCD signal workaround" -- - Daniel
Re: [PATCH v3 4/4] mmc: pic32: Refresh PIC32 MMC driver
Am Dienstag, den 01.09.2020, 02:55 + schrieb John Robertson: > CONFIG_BLK needs to be enabled by default to allow U-Boot to > compile after a 'make pic32mzdask_defconfig'. > > Signed-off-by: John Robertson > --- > Changes in v3 - address review comment from Daniel Schwierzeck > - This file should have been generated by 'make savedefconfig' rather than > being > manually edited > > configs/pic32mzdask_defconfig | 1 - > 1 file changed, 1 deletion(-) > applied to u-boot-mips/fixes, thanks. Note: I've updated the commit subject to "MIPS: pic32mzdask: enable CONFIG_BLK" -- - Daniel
Re: [PATCH v3 2/4] mmc: pic32: Refresh PIC32 MMC driver
Am Dienstag, den 01.09.2020, 02:55 + schrieb John Robertson: > The GPIO pins used by the SDHCI controller need to be configured to > allow the interface to work. > > Signed-off-by: John Robertson > --- > > drivers/pinctrl/pinctrl_pic32.c | 28 > 1 file changed, 28 insertions(+) > applied to u-boot-mips/fixes, thanks. Note: I've updated the commit subject to "pinmux: pic32: add SDHCI pin config" -- - Daniel
Re: [PATCH v3 1/4] mmc: pic32: Refresh PIC32 MMC driver
Am Dienstag, den 01.09.2020, 02:55 + schrieb John Robertson: > The existing driver is not compatible with the Driver Model. > > This patch makes the necessary changes while also removing obsolescent > calls/properties as follows: > > - fdtdec_* calls replaced with dev_read_* equivalents; > - 'clock-freq-min-max' property replaced by querying the frequency of > the source clock 'base_clk'; > - The card detect erratum workaround is applied during probe rather than > overriding get_cd. > > The card detect workaround (Microchip ref. DS8736E, erratum #15) is > not always needed and can be disabled using a vendor specific DT > property. > > Signed-off-by: John Robertson > --- > Changes in v3 - address review comments from Daniel Schwierzeck > - Remove , DECLARE_GLOBAL_DATA_PTR not required by dev_* API > - Replace dev_read_addr_size() + ioremap() with dev_remap_addr() > > drivers/mmc/pic32_sdhci.c | 86 +++ > 1 file changed, 50 insertions(+), 36 deletions(-) > applied to u-boot-mips/fixes, thanks. -- - Daniel
Re: [PATCH 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board support
On 9/19/20 8:38 PM, Biju Das wrote:
[...]
> +int dram_init(void)
> +{
> +return fdtdec_setup_mem_size_base(); }
> +
> +int dram_init_banksize(void)
> +{
> +return fdtdec_setup_memory_banksize(); }
> +
> +void reset_cpu(ulong addr)
> +{
> +writel(RST_CODE, RST_CA57RESCNT);
> +}
Isn't there CA53 core in the RZG2 too ?
>>>
>>> Yes, big little CPU 2xCA57 + 4 xCA53. Do you want me to add reset code for
>> in case of CA53 boot mode???
>>
>> I think if you can start U-Boot on either core, then the reset function
>> should
>> handle both, yes.
>
> OK. Will fix this in V3.
Thanks
Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
On 9/19/20 8:35 PM, Biju Das wrote:
Hi,
[...]
> +static const struct udevice_id *of_soc_match_compatible(void) {
> +const struct udevice_id *of_match = soc_ids; int i;
> +
> +for (i = 0; i < ARRAY_SIZE(soc_ids); i++) { if
> +(!fdt_node_check_compatible(gd->fdt_blob, 0,
> + of_match->compatible))
> +return of_match;
> +of_match++;
> +}
> +
> +return NULL;
> +}
This should rather be a generic function, I think this is something
that already exists in Linux common code too, right ?
>>>
>>> No. I have seen some other SoC's uses similar logic [1]& [2] .
>>
>> I mean, this looks like Linux's soc_device_match() , so such a function is
>> likely
>> generic code, there is nothing platform specific to it, is there ?
>
> I agree, we need to have a new generic api for such purpose. The Linux/U-boot
> soc_device_match is for adding quirks with in different ES version of same
> SoC.
>
> What we here need is similar to of_match_compatible for array of different
> SoC's.
> Can you please confirm [1] drivers/soc/soc-uclass.c is the right place for
> such generic api?
Can you use of_machine_is_compatible() ?
[...]
>>> So can you please check whether there might
be some way to tell the two SoCs apart ?
>>>
>>> At present there is no way other than matching the SoC compatible string.
>>
>> Thinking about it a bit more, if you were to use the compatible string psssed
>> from TFA in the / node, you could iterate over soc_ids[] array and return
>> RMOBILE_CPU_TYPE_x , which could be stored there as .data .
>> Then you won't even need the SOC_RZG2 and it would all be faster, as all you
>> would need is a single pass over a smaller array.
>
> Good point. Ok will get rid of SOC_RZG2, will use smaller array forRZG2.
>
> Are you suggesting to modify "arch_misc_init" directly set "platform"
> environment variable using match logic, which use a smaller array
> Compared to rmobile_cpuinfo.
>
> Basically we match the compatible string from TFA, .data from "
> RMOBILE_CPU_TYPE_x" matched against PRR values and set the platform type .
I don't think you need to modify anything then, the DT passed from TFA
would contain the correct compatible string in / node, and that gets
merged into the U-Boot control DT early on in fdtdec_board_setup() in:
board/renesas/rcar-common/common.c
so all you would have to do is use
of_machine_is_compatible("renesas,r8a7-something-");
Would that work ?
Re: Cold boot consistently fails to load file from SD
Hi Mauro,
Am Samstag, den 19.09.2020, 15:39 +0200 schrieb Mauro Condarelli:
> Hi,
> I'm facing a new problem for my Mt7628/vocore2 target.
>
> I moved the Linux kernel from a ext4 partition to the "proper" SquashFS
> partition (I say "proper" because I'm using a dual-system with fallback to
> avoid updating the currently working rootFS and kernel lies into rootFS).
>
> I am using u-boot v2020.10-rc3 plus the attached patches (one pertains
> SquashFS).
>
> Problem is a real cold boot (target off for more than one minute) leads to a
> load failure for the kernel. A warm boot ("reboot" from a running Linux) or a
> not-so-cold boot (turn target off and power it on again after a few seconds)
> seems to work as expected.
which distro or Linux version do you use? Can you provide a full boot
log?
Linux MIPS had a bug with setting up memory for its exception vectors
and handlers if the CPU didn't report support for vectored interrupts.
mtmips is one of those CPUs. AFAIK this should have been fixed in
mainline since some months. Could be one reason.
You could also try to disable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE in
U-Boot.
Stefan also had cache issues on the Gardena board. He solved it with
some memory allocation and copying, see arch/mips/mach-mtmips/cpu.c.
The cmd_cache interface is not supported on MIPS as there is no
reliable way to disable or enable caches or to separately control i-
cache and d-cache.
Can you send patches 0001 and 0002 to the mailing list in the proper
way so that patchwork can pick them up? I'd like to prepare a small
bugfix pull request for v2020.10. Thanks.
--
- Daniel
Re: [PATCH] net: ravb: Fix NULL pointer access
On 9/19/20 8:14 PM, Biju Das wrote: Hi, [...] > By looking at [1], only this driver is using writeext. > [1]https://elixir.bootlin.com/u-boot/v2020.10-rc4/A/ident/writeext git grep indicates a couple more sites where the writeext is called. But look into the KSZ9031 datasheet, that particular writeext call seems to be setting up RGMII Clock Pad Skew (MMD Address 2, Register 8), and I think there is a matching DT binding to set those up too, rxc-skew-ps and txc- skew-ps I think. >>> >>> Thanks for the pointers. I checked the configs[2] which uses renesas >>> ravb driver and found that we are defining only rxc-skew-ps in all dts. >>> >>> since CONFIG DM_ETH is defined it is already picking the value >> corresponding to "rxc-skew-ps". >>> >>> For txc-skew-ps anyway the value is default one. So we don't care. >> >> Are you sure (0xf << 5) | 0x19 is the same as the default value of the clock >> pad skew register ? > > No. > As per [1] & [2], the default values for this registers are 0xf So the combined value of the MMD 2-8 register is (0xf << 5) | (0xf << 0) , right. > [1] > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/net/phy/micrel_ksz90x1.c#L105 > [2] http://ww1.microchip.com/downloads/en/devicedoc/2117f.pdf > > if we remove writephyext, by looking the code at [1], rxc-skew-ps will be > taken from the device tree[3] and "txc-skew-pc" will be the default > value(0xf). > [3]https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/dts/salvator-common.dtsi#L331 So you want to check whether each RCar3 DT contains a PHY node and that PHY node has rxc-skew-ps and txc-skew-ps , which combined then results into a register value (0xf << 5) | (0x19 << 0) . > I will check this and let you know the results after checking on RCar board. > Unfortunately currently I don't have RCar board. It's enough to just check the DTs and verify that they set the matching correct values of rxc-skew-ps/txc-skew-ps . I can test it on the real hardware. If you want, you can add the txc-skew-ps into the Linux R-Car3 DTs too. btw unrelated, you seem to have rxc-skew-ps in your hihope-rzg2-ex.dtsi, but I think you don't have KSZ9031 PHY, so maybe you want to remove it form your DT too. Thanks
RE: [PATCH 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board support
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board
> support
>
> On 9/19/20 2:18 PM, Biju Das wrote:
>
> Hi,
>
> [...]
>
> >>> +++ b/board/hoperun/hihope-rzg2/hihope-rzg2.c
> >>> @@ -0,0 +1,80 @@
> >> [...]
> >>> +#define RST_BASE0xE616
> >>> +#define RST_CA57RESCNT(RST_BASE + 0x40) #define
> RST_CODE0xA5A5000F
> >>> +
> >>> +/* If the firmware passed a device tree use it for U-Boot DRAM setup.
> >>> +*/ extern u64 rcar_atf_boot_args[];
> >>> +
> >>> +DECLARE_GLOBAL_DATA_PTR;
> >>> +
> >>> +void s_init(void)
> >>> +{
> >>> +}
> >>
> >> Is this empty function needed ?
> >
> > Yes Compilation error otherwise. This function is called from
> > lowlevel_init_gen3.S. I believe it is place holder for doing some early
> initialisation such as watchdog That could be the reason all rcar gen3 boards
> have this empty function for eg:-[1], please correct me if you think
> otherwise.
> > [1] board/renesas/salvator-x/Salvator-x.c
>
> Can you try fixing that with WEAK(s_init) in the lowlevel_init_gen3.S ?
> I think that would be much better, if anyone needs to override the function,
> then they can, otherwise empty WEAK function would be used.
OK. Will add weak function in lowlevel_init_gen3.S.
>>> +#ifdef CONFIG_BOARD_EARLY_INIT_F
> >>> +/* Kconfig forces this on, so just return 0 */
> >>
> >> I think BOARD_EARLY_INIT_F should really be disabled in Kconfig
> >> rather than implementing empty function here.
> >>
> >
> > Ok, will fix in v2.
> >
> > For eg:- file arch/arm/Kconfig
> > Select BOARD_EARLY_INIT_FUNCTION if !(RZA1 ||
> TARGET_HIHOPE_RZG2)
>
> Maybe it would be better to use imply BOARD_EARLY_INIT_F , and then
> disable it on boards which don't need it (RZA1 and RZG2)
OK Will fix this in V3.
> > I also noticed other boards in board/renesas directory with empty
> function(for eg:- ebisu,condor etc).
> > For completeness, do you want me to fix that as well in separate patch and
> removing empty functions.
> > Select BOARD_EARLY_INIT_FUNCTION if !(RZA1 ||
> TARGET_HIHOPE_RZG2||
> > TARGET_EBISU || TARGET_CONDOR)
>
> Look at the 'imply' keyword, that might be even better.
Will send separate patch for this.
> [...]
>
> >>> +int fdtdec_board_setup(const void *fdt_blob) { void *atf_fdt_blob =
> >>> +(void *)(rcar_atf_boot_args[1]);
> >>> +
> >>> +if (fdt_magic(atf_fdt_blob) == FDT_MAGIC)
> >>> +fdt_overlay_apply_node((void *)fdt_blob, 0, atf_fdt_blob,
> >> 0);
> >>> +
> >>> +return 0;
> >>> +}
> >>
> >> Please use board/renesas/rcar-common/common.c , no need to
> duplicate
> >> the code.
> >
> > OK will fix in V3.
>
> Thanks
>
> >>> +int dram_init(void)
> >>> +{
> >>> +return fdtdec_setup_mem_size_base(); }
> >>> +
> >>> +int dram_init_banksize(void)
> >>> +{
> >>> +return fdtdec_setup_memory_banksize(); }
> >>> +
> >>> +void reset_cpu(ulong addr)
> >>> +{
> >>> +writel(RST_CODE, RST_CA57RESCNT);
> >>> +}
> >>
> >> Isn't there CA53 core in the RZG2 too ?
> >
> > Yes, big little CPU 2xCA57 + 4 xCA53. Do you want me to add reset code for
> in case of CA53 boot mode???
>
> I think if you can start U-Boot on either core, then the reset function should
> handle both, yes.
OK. Will fix this in V3.
Cheers,
Biju
Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch,
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg.
no.: DE 14978647
RE: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
>
> On 9/19/20 1:37 PM, Biju Das wrote:
> [...]
> >>> +static const struct udevice_id *of_soc_match_compatible(void) {
> >>> +const struct udevice_id *of_match = soc_ids; int i;
> >>> +
> >>> +for (i = 0; i < ARRAY_SIZE(soc_ids); i++) { if
> >>> +(!fdt_node_check_compatible(gd->fdt_blob, 0,
> >>> + of_match->compatible))
> >>> +return of_match;
> >>> +of_match++;
> >>> +}
> >>> +
> >>> +return NULL;
> >>> +}
> >>
> >> This should rather be a generic function, I think this is something
> >> that already exists in Linux common code too, right ?
> >
> > No. I have seen some other SoC's uses similar logic [1]& [2] .
>
> I mean, this looks like Linux's soc_device_match() , so such a function is
> likely
> generic code, there is nothing platform specific to it, is there ?
I agree, we need to have a new generic api for such purpose. The Linux/U-boot
soc_device_match is for adding quirks with in different ES version of same SoC.
What we here need is similar to of_match_compatible for array of different
SoC's.
Can you please confirm [1] drivers/soc/soc-uclass.c is the right place for
such generic api?
[1]
https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/soc/soc-uclass.c
> > [1]
> > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/board/samsung/co
> > mmon/exynos5-dt-types.c#L246 [2]
> > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/mach-un
> > iphier/boards.c#L156
> >
> >
> >>> static int rmobile_cpuinfo_idx(void) { int i = 0;
> >>> u32 cpu_type = rmobile_get_cpu_type();
> >>> +const struct udevice_id *match = of_soc_match_compatible();
> >>>
> >>> +/*
> >>> + * This loop identifies CPU based on PRR register, it
> >>> +differentiates
> >>> + * RZ/G SoC's from R-Car SoC's by matching RZ/G SoC compatible
> >> string
> >>> + * from DT against the family_type.
> >>> + */
> >>> for (; i < ARRAY_SIZE(rmobile_cpuinfo); i++) -if
> >>> (rmobile_cpuinfo[i].cpu_type == cpu_type) -break;
> >>> +if (rmobile_cpuinfo[i].cpu_type == cpu_type) { if (match &&
> >>> +rmobile_cpuinfo[i].family_type == match->data) break; else if
> >>> +(!match && rmobile_cpuinfo[i].family_type !=
> >> SOC_RZG2)
> >>> +break;
> >>> +}
> >>
> >> I still don't understand this, so if cpu_type ==
> >> RMOBILE_CPU_TYPE_R8A7796 , then it can be either RZG2 or R8A7796,
> right?
> >
> > Yep you are right.
> >
> >> And there is no PRR bit or any other bit to tell those two chips apart ?
> > No. Currently only way you can distinguish is by SoC compatible string and
> family type.
> > See [3] for SoC identification logic used to differentiate RCar and
> > RZ/G2
> > [3]:-
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > e/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc5#n311
>
> So Linux is matching on the compatible string of DT passed from U-Boot ,
> right ? Linux has it easier then.
>
> But where does U-Boot get that compatible string from, in case there are
> multiple DTs passed to U-Boot and U-Boot needs to find out on which SoC it
> is running on ?
>
> Maybe you can pass the compatible from TFA, which is already happening.
>
> >> I would like to avoid using the OF match here, because that fails if
> >> you use MULTI_DTB_FIT , does it not ?
> >
> > No. It works OK on both RZ/G2SoC's[4] and RCar[5]
> >
> > [4] MULTI_DTB_FIT logs for RZG2[HMN] boards
> >
> > CPU: Renesas Electronics R8A774E1 rev 3.0
> > Model: HopeRun HiHope RZ/G2H with sub board
> > DRAM: 3.9 GiB
> >
> > CPU: Renesas Electronics R8A774A1 rev 1.3
> > Model: HopeRun HiHope RZ/G2M with sub board
> > DRAM: 3.9 GiB
> >
> > CPU: Renesas Electronics R8A774B1 rev 1.1
> > Model: HopeRun HiHope RZ/G2N with sub board
> > DRAM: 3.9 GiB
> >
> > [5] u-boot based on R-Car M3N using rcar3_salvator-x_defconfig, it reports
> proper SoC.
> >
> > CPU: Renesas Electronics R8A77965 rev 1.1
> > Model: Renesas Salvator-XS board based on r8a77965
> > DRAM: 1.9 GiB
> > Bank #0: 0x04800 - 0x0bfff, 1.9 GiB
> >
> > MMC: sd@ee10: 0, sd@ee14: 1, sd@ee16: 2 Loading
> > Environment from MMC... OK
> > In: serial@e6e88000
> > Out: serial@e6e88000
> > Err: serial@e6e88000
> > Net: eth0: ethernet@e680
> > Hit any key to stop autoboot: 0
> > =>
> >
> > So can you please check whether there might
> >> be some way to tell the two SoCs apart ?
> >
> > At present there is no way other than matching the SoC compatible string.
>
> Thinking about it a bit more, if you were to use the compatible string psssed
> from TFA in the / node, you could iterate over soc_ids[] array and return
> RMOBILE_CPU_TYPE_x , which could be stored there as .data .
> Then you won't even need the SOC_RZG2 and it would all be faster, as all you
> would need is a single pass over a smaller array.
Good point. Ok will get rid of SOC_RZG2, will use smaller array forRZG2.
Are you suggesting to modify "arch_misc_init" directly set "platform"
environment
RE: [PATCH] net: ravb: Fix NULL pointer access
Hi Marek, Thanks for the feedback. > Subject: Re: [PATCH] net: ravb: Fix NULL pointer access > > On 9/19/20 1:14 PM, Biju Das wrote: > [...] > >>> By looking at [1], only this driver is using writeext. > >>> [1]https://elixir.bootlin.com/u-boot/v2020.10-rc4/A/ident/writeext > >> > >> git grep indicates a couple more sites where the writeext is called. > >> But look into the KSZ9031 datasheet, that particular writeext call > >> seems to be setting up RGMII Clock Pad Skew (MMD Address 2, Register > >> 8), and I think there is a matching DT binding to set those up too, > >> rxc-skew-ps and txc- skew-ps I think. > > > > Thanks for the pointers. I checked the configs[2] which uses renesas > > ravb driver and found that we are defining only rxc-skew-ps in all dts. > > > > since CONFIG DM_ETH is defined it is already picking the value > corresponding to "rxc-skew-ps". > > > > For txc-skew-ps anyway the value is default one. So we don't care. > > Are you sure (0xf << 5) | 0x19 is the same as the default value of the clock > pad skew register ? No. As per [1] & [2], the default values for this registers are 0xf [1] https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/net/phy/micrel_ksz90x1.c#L105 [2] http://ww1.microchip.com/downloads/en/devicedoc/2117f.pdf if we remove writephyext, by looking the code at [1], rxc-skew-ps will be taken from the device tree[3] and "txc-skew-pc" will be the default value(0xf). [3]https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/dts/salvator-common.dtsi#L331 I will check this and let you know the results after checking on RCar board. Unfortunately currently I don't have RCar board. Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
Re: [PATCH 1/1] sandbox: support CTRL-C processing in U-Boot
On 9/19/20 3:26 PM, Simon Glass wrote: > Hi Heinrich, > > On Fri, 18 Sep 2020 at 22:19, Heinrich Schuchardt wrote: >> >> Am 19. September 2020 04:59:46 MESZ schrieb Simon Glass : >>> Hi Heinrich, >>> >>> On Thu, 17 Sep 2020 at 12:04, Heinrich Schuchardt >>> wrote: Currently if SIGINT is received, it terminates U-Boot. This does not >>> allow testing the handling of CTRL-C in U-Boot and in UEFI applications. It is especially annoying when working with the 'mm' command. Let the serial console driver provide character 0x03 if SIGINT >>> occurs. We can still exit U-Boot using the reset or poweroff command. Adjust the sandbox test_ctrl_c() Python test accordingly. Signed-off-by: Heinrich Schuchardt --- arch/sandbox/cpu/os.c | 15 --- drivers/serial/sandbox.c | 11 --- include/os.h | 14 ++ test/py/tests/test_sandbox_exit.py | 10 +- 4 files changed, 43 insertions(+), 7 deletions(-) >>> >>> I'm sorry but I still do want Ctrl-C to work. How about adding a short >>> option to change the terminal mode? >>> >>> Regards, >>> Simon >> >> >> On QEMU you quit via X. Can we use the same for the sandbox? > > I just don't like programs that refused to quit when asked I use> Ctrl-C all > the time. Can you not use the -t options to get what you > want? Perhaps we could have an environment variable too? Sorry, I was not aware of the -t option. ./u-boot -t raw -d arch/sandbox/dts/test.dtb behaves according to my preferences. Best regards Heinrich
[PATCH 1/1] doc/arch/sandbox.rst: reformat command line options
Reformat the command line options chapter so that the command line options clearly stand out. Signed-off-by: Heinrich Schuchardt --- doc/arch/sandbox.rst | 57 +--- 1 file changed, 33 insertions(+), 24 deletions(-) diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst index 360f22461a..4674c420ac 100644 --- a/doc/arch/sandbox.rst +++ b/doc/arch/sandbox.rst @@ -97,30 +97,39 @@ Command-line Options Various options are available, mostly for test purposes. Use -h to see -available options. Some of these are described below. - -The terminal is normally in what is called 'raw-with-sigs' mode. This means -that you can use arrow keys for command editing and history, but if you -press Ctrl-C, U-Boot will exit instead of handling this as a keypress. - -Other options are 'raw' (so Ctrl-C is handled within U-Boot) and 'cooked' -(where the terminal is in cooked mode and cursor keys will not work, Ctrl-C -will exit). - -As mentioned above, -l causes the LCD emulation window to be shown. - -A device tree binary file can be provided with -d. If you edit the source -(it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to -recreate the binary file. - -To use the default device tree, use -D. To use the test device tree, use -T. - -To execute commands directly, use the -c option. You can specify a single -command, or multiple commands separated by a semicolon, as is normal in -U-Boot. Be careful with quoting as the shell will normally process and -swallow quotes. When -c is used, U-Boot exits after the command is complete, -but you can force it to go to interactive mode instead with -i. - +available options. Some of these are described below: + +* -t, --terminal + - The terminal is normally in what is called 'raw-with-sigs' mode. This means + that you can use arrow keys for command editing and history, but if you + press Ctrl-C, U-Boot will exit instead of handling this as a keypress. + Other options are 'raw' (so Ctrl-C is handled within U-Boot) and 'cooked' + (where the terminal is in cooked mode and cursor keys will not work, Ctrl-C + will exit). + +* -l + - Show the LCD emulation window. + +* -d + - A device tree binary file can be provided with -d. If you edit the source + (it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to + recreate the binary file. + +* -D + - To use the default device tree, use -D. + +* -T + - To use the test device tree, use -T. + +* -c [;] + - To execute commands directly, use the -c option. You can specify a single + command, or multiple commands separated by a semicolon, as is normal in + U-Boot. Be careful with quoting as the shell will normally process and + swallow quotes. When -c is used, U-Boot exits after the command is complete, + but you can force it to go to interactive mode instead with -i. + +* -i + - Go to interactive mode after executing the commands specified by -c. Memory Emulation -- 2.28.0
[PATCH 1/1] MAINTAINERS: assign doc/arch/sandbox.rst
Add doc/arch/sandbox.rst to the scope of SANDBOX. Signed-off-by: Heinrich Schuchardt --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7e46470c70..a8d8017b5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,6 +951,7 @@ SANDBOX M: Simon Glass S: Maintained F: arch/sandbox/ +F: doc/arch/sandbox.rst SH M: Marek Vasut -- 2.28.0
[PATCH 3/3] doc: global data pointer
Add the description of the global data pointer to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt --- doc/develop/global_data.rst | 53 + doc/develop/index.rst | 1 + 2 files changed, 54 insertions(+) create mode 100644 doc/develop/global_data.rst diff --git a/doc/develop/global_data.rst b/doc/develop/global_data.rst new file mode 100644 index 00..9e7c8a24da --- /dev/null +++ b/doc/develop/global_data.rst @@ -0,0 +1,53 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Global data +=== + +Globally required fields are held in the global data structure. A pointer to the +structure is available as symbol gd. The symbol is made available by the macro +%DECLARE_GLOBAL_DATA_PTR. + +Register pointing to global data + + +On most architectures the global data pointer is stored in a register. + +++--+ +| ARC| r25 | +++--+ +| ARM 32bit | r9 | +++--+ +| ARM 64bit | x18 | +++--+ +| M68000 | d7 | +++--+ +| MicroBlaze | r31 | +++--+ +| NDS32 | r10 | +++--+ +| Nios II| gp | +++--+ +| PowerPC| r2 | +++--+ +| RISC-V | gp (x3) | +++--+ +| SuperH | r13 | +++--+ + +The sandbox, x86, and Xtensa are notable exceptions. + +Clang for ARM does not support assigning a global register. When using Clang +gd is defined as an inline function using assembly code. This adds a few bytes +to the code size. + +Binaries called by U-Boot are not aware of the register usage and will not +conserve gd. UEFI binaries call the API provided by U-Boot and may return to +U-Boot. The value of gd has to be saved every time U-Boot is left and restored +whenever U-Boot is reentered. This is also relevant for the implementation of +function tracing. For setting the value of gd function set_gd() can be used. + +Global data structure +- + +.. kernel-doc:: include/asm-generic/global_data.h + :internal: diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 98a95ad434..89e80eab94 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -9,4 +9,5 @@ Develop U-Boot coccinelle crash_dumps + global_data logging -- 2.28.0
[PATCH 2/3] global_data.h: add Sphinx documentation
Add the missing Sphinx documentation for struct global_data and
gd_board_type().
Signed-off-by: Heinrich Schuchardt
---
include/asm-generic/global_data.h | 357 ++
1 file changed, 309 insertions(+), 48 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 6859df4e1d..abbd64a619 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -24,122 +24,384 @@
#include
#include
-typedef struct global_data {
+typedef struct global_data gd_t;
+
+/**
+ * struct global_data - global data structure
+ */
+struct global_data {
+ /**
+* @bd: board information
+*/
struct bd_info *bd;
+ /**
+* @flags: global data flags
+*
+* See &enum gd_flags
+*/
unsigned long flags;
+ /**
+* @baudrate: baud rate of the serial interface
+*/
unsigned int baudrate;
- unsigned long cpu_clk; /* CPU clock in Hz! */
+ /**
+* @cpu_clk: CPU clock rate in Hz
+*/
+ unsigned long cpu_clk;
+ /**
+* @bus_clk: platform clock rate in Hz
+*/
unsigned long bus_clk;
+ /**
+* @pci_clk: PCI clock rate in Hz
+*/
/* We cannot bracket this with CONFIG_PCI due to mpc5xxx */
unsigned long pci_clk;
+ /**
+* @mem_clk: memory clock rate in Hz
+*/
unsigned long mem_clk;
#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO) || defined(CONFIG_DM_VIDEO)
- unsigned long fb_base; /* Base address of framebuffer mem */
+ /**
+* @fb_base: base address of frame buffer memory
+*/
+ unsigned long fb_base;
#endif
#if defined(CONFIG_POST)
+ /**
+* @post_log_word: active POST tests
+*
+* @post_log_word is a bit mask defining which POST tests are recorded
+* (see constants POST_*).
+*/
unsigned long post_log_word;/* Record POST activities */
- unsigned long post_log_res; /* success of POST test */
- unsigned long post_init_f_time; /* When post_init_f started */
+ /**
+* @post_log_res: POST results
+*
+* @post_log_res is a bit mask with the POST results. A bit with value 1
+* indicates successful execution.
+*/
+ unsigned long post_log_res;
+ /**
+* @post_init_f_time: time in ms when post_init_f() started
+*/
+ unsigned long post_init_f_time;
#endif
#ifdef CONFIG_BOARD_TYPES
+ /**
+* @board_type: board type
+*
+* If a U-Boot configuration supports multiple board types, the actual
+* board type may be stored in this field.
+*/
unsigned long board_type;
#endif
+ /**
+* @have_console: console is available
+*
+* A value of 1 indicates that serial_init() was called and a console
+* is available.
+* A value of 0 indicates that console input and output drivers shall
+* not be called.
+*/
unsigned long have_console; /* serial_init() was called */
#if CONFIG_IS_ENABLED(PRE_CONSOLE_BUFFER)
+ /**
+* @precon_buf_idx: pre-console buffer index
+*
+* @precon_buf_idx indicates the current position of the buffer used to
+* collect output before the console becomes available
+*/
unsigned long precon_buf_idx; /* Pre-Console buffer index */
#endif
- unsigned long env_addr; /* Address of Environment struct */
- unsigned long env_valid;/* Environment valid? enum env_valid */
- unsigned long env_has_init; /* Bitmask of boolean of struct
env_location offsets */
- int env_load_prio; /* Priority of the loaded environment */
-
- unsigned long ram_base; /* Base address of RAM used by U-Boot */
+ /**
+* @env_addr: address of environment structure
+*
+* @env_addr contains the address of the structure holding the
+* environment variables.
+*/
+ unsigned long env_addr;
+ /**
+* @env_valid: environment is valid
+*
+* See &enum env_valid
+*/
+ unsigned long env_valid;
+ /**
+* @env_has_init: bit mask indicating environment locations
+*
+* &enum env_location defines which bit relates to which location
+*/
+ unsigned long env_has_init;
+ /**
+* @env_load_prio: priority of the loaded environment
+*/
+ int env_load_prio;
+ /**
+* @ram_base: base address of RAM used by U-Boot
+*/
+ unsigned long ram_base;
+ /**
+* @ram_top: top address of RAM used by U-Boot
+*/
unsigned long ram_top; /* Top address of RAM used by U-Boot */
+ /**
+* @relocaddr: start address o
[PATCH 1/3] global_data.h: convert GD_FLG_* to enum
Sphinx documentation is only available for enums not for #defines.
Anyway it is better to keep related definitions in an enum.
Signed-off-by: Heinrich Schuchardt
---
include/asm-generic/global_data.h | 104 --
1 file changed, 83 insertions(+), 21 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index d4a4e2215d..6859df4e1d 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -146,27 +146,89 @@ typedef struct global_data {
#define gd_board_type()0
#endif
-/*
- * Global Data Flags
+/**
+ * enum gd_flags - global data flags
+ *
+ * See field flags of &struct global_data.
*/
-#define GD_FLG_RELOC 0x1 /* Code was relocated to RAM */
-#define GD_FLG_DEVINIT 0x2 /* Devices have been initialized */
-#define GD_FLG_SILENT 0x4 /* Silent mode */
-#define GD_FLG_POSTFAIL0x8 /* Critical POST test failed
*/
-#define GD_FLG_POSTSTOP0x00010 /* POST seqeunce aborted
*/
-#define GD_FLG_LOGINIT 0x00020 /* Log Buffer has been initialized */
-#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in & out) */
-#define GD_FLG_ENV_READY 0x00080 /* Env. imported into hash table */
-#define GD_FLG_SERIAL_READY0x00100 /* Pre-reloc serial console ready */
-#define GD_FLG_FULL_MALLOC_INIT0x00200 /* Full malloc() is ready
*/
-#define GD_FLG_SPL_INIT0x00400 /* spl_init() has been called
*/
-#define GD_FLG_SKIP_RELOC 0x00800 /* Don't relocate */
-#define GD_FLG_RECORD 0x01000 /* Record console */
-#define GD_FLG_ENV_DEFAULT 0x02000 /* Default variable flag */
-#define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done */
-#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
-#define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */
-#define GD_FLG_SKIP_LL_INIT0x2 /* Don't perform low-level init*/
-#define GD_FLG_SMP_READY 0x4 /* SMP init is complete*/
+enum gd_flags {
+ /**
+* @GD_FLG_RELOC: code was relocated to RAM
+*/
+ GD_FLG_RELOC = 0x1,
+ /**
+* @GD_FLG_DEVINIT: devices have been initialized
+*/
+ GD_FLG_DEVINIT = 0x2,
+ /**
+* @GD_FLG_SILENT: silent mode
+*/
+ GD_FLG_SILENT = 0x4,
+ /**
+* @GD_FLG_POSTFAIL: critical POST test failed
+*/
+ GD_FLG_POSTFAIL = 0x8,
+ /**
+* @GD_FLG_POSTSTOP: POST sequence aborted
+*/
+ GD_FLG_POSTSTOP = 0x00010,
+ /**
+* @GD_FLG_LOGINIT: log Buffer has been initialized
+*/
+ GD_FLG_LOGINIT = 0x00020,
+ /**
+* @GD_FLG_DISABLE_CONSOLE: disable console (in & out)
+*/
+ GD_FLG_DISABLE_CONSOLE = 0x00040,
+ /**
+* @GD_FLG_ENV_READY: environment imported into hash table
+*/
+ GD_FLG_ENV_READY = 0x00080,
+ /**
+* @GD_FLG_SERIAL_READY: pre-relocation serial console ready
+*/
+ GD_FLG_SERIAL_READY = 0x00100,
+ /**
+* @GD_FLG_FULL_MALLOC_INIT: full malloc() is ready
+*/
+ GD_FLG_FULL_MALLOC_INIT = 0x00200,
+ /**
+* @GD_FLG_SPL_INIT: spl_init() has been called
+*/
+ GD_FLG_SPL_INIT = 0x00400,
+ /**
+* @GD_FLG_SKIP_RELOC: don't relocate
+*/
+ GD_FLG_SKIP_RELOC = 0x00800,
+ /**
+* @GD_FLG_RECORD: record console
+*/
+ GD_FLG_RECORD = 0x01000,
+ /**
+* @GD_FLG_ENV_DEFAULT: default variable flag
+*/
+ GD_FLG_ENV_DEFAULT = 0x02000,
+ /**
+* @GD_FLG_SPL_EARLY_INIT: early SPL initialization is done
+*/
+ GD_FLG_SPL_EARLY_INIT = 0x04000,
+ /**
+* @GD_FLG_LOG_READY: log system is ready for use
+*/
+ GD_FLG_LOG_READY = 0x08000,
+ /**
+* @GD_FLG_WDT_READY: watchdog is ready for use
+*/
+ GD_FLG_WDT_READY = 0x1,
+ /**
+* @GD_FLG_SKIP_LL_INIT: don't perform low-level initialization
+*/
+ GD_FLG_SKIP_LL_INIT = 0x2,
+ /**
+* @GD_FLG_SMP_READY: SMP initialization is complete
+*/
+ GD_FLG_SMP_READY = 0x4,
+};
+
#endif /* __ASM_GENERIC_GBL_DATA_H */
--
2.28.0
[PATCH 0/3] doc: global data pointer
Add the description of the global data pointer to the generated HTML documentation. The first patch converts the GD_FLG_* constants to an enum. The second adds move Sphinx comments. The third finally provides the HTML documentation. Heinrich Schuchardt (3): global_data.h: convert GD_FLG_* to enum global_data.h: add Sphinx documentation doc: global data pointer doc/develop/global_data.rst | 51 doc/develop/index.rst | 1 + include/asm-generic/global_data.h | 459 +- 3 files changed, 443 insertions(+), 68 deletions(-) create mode 100644 doc/develop/global_data.rst -- 2.28.0
Cold boot consistently fails to load file from SD
Hi,
I'm facing a new problem for my Mt7628/vocore2 target.
I moved the Linux kernel from a ext4 partition to the "proper" SquashFS
partition (I say "proper" because I'm using a dual-system with fallback to
avoid updating the currently working rootFS and kernel lies into rootFS).
I am using u-boot v2020.10-rc3 plus the attached patches (one pertains
SquashFS).
Problem is a real cold boot (target off for more than one minute) leads to a
load failure for the kernel. A warm boot ("reboot" from a running Linux) or a
not-so-cold boot (turn target off and power it on again after a few seconds)
seems to work as expected.
I tried to insert delays and/or "mmc rescan", but that does not seem to have
any effect.
Also error message is not always the same; sometimes I get:
Error: too many data blocks to be read.
Failed to load '/boot/uImage'
other times:
** fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
My full environment is:
BOOT_CURRENT=A
SYSTEM_R=/dev/mtdblock5
arch=mips
baudrate=115200
board=vocore2
board_name=vocore2
boot_a=echo "Loading System A";part=6;run boot_x
boot_b=echo "Loading System B";part=7;run boot_x
boot_now=if test "${BOOT_CURRENT}" = A; then run boot_a; elif test
"${BOOT_CURRENT}" = B; then run boot_b; fi; if env exists BOOT_A_GOOD; then run
boot_a; fi; if env exists BOOT_B_GOOD; then run boot_b; fi; run boot_r
boot_r=echo "Loading Recovery"; setenv bootargs "${default_bootargs}
mtdparts=${mtdparts} root=/dev/mtdblock5"; bootm bc05
boot_x=load mmc 0:${part} 8500 /boot/uImage && setenv bootargs
"${default_bootargs} mtdparts=${mtdparts} root=/dev/mmcblk0p${part}" && bootm
${fileaddr}
bootcmd=run do_boot
bootcount=1
bootdelay=2
cpu=mips32
default_bootargs=earlyprintk rootwait console=ttyS2,115200
do_boot=test ${bootcount} -gt 1 && run remove_boot; run boot_now
fdtcontroladdr=86f6d340
fileaddr=8400
filesize=154
fupdate=mmc rescan && load mmc 0:1 8400 uboot.scr && fatrm mmc 0:1
uboot.scr && source 8400 && echo Flash updated || Flash update FAILED!
mtdids=nor0=spi0.0
mtdparts=spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem)
remove_boot=if env exists BOOT_CURRENT; then setenv BOOT_CURRENT; saveenv;
elif env exists BOOT_A_GOOD; then setenv BOOT_A_GOOD; saveenv; elif env exists
BOOT_B_GOOD; then setenv BOOT_B_GOOD; saveenv; fi
soc=mt7628
stderr=uart2@e00
stdin=uart2@e00
stdout=uart2@e00
vendor=vocore
ver=U-Boot 2020.10-rc3 (Sep 16 2020 - 19:43:03 +0200)
It was suggested (on IRC) it could be a cache problem. unfortunately trying to
enable cache control (CONFIG_CMD_CACHE) raises error in compilation:
...
LD u-boot
/home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
cmd/built-in.o: in function `do_icache':
cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
/home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
cmd/cache.c:(.text.do_icache+0x6c): undefined reference to `icache_enable'
/home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
cmd/cache.c:(.text.do_icache+0x8c): undefined reference to `icache_status'
Makefile:1753: recipe for target 'u-boot' failed
make[2]: *** [u-boot] Error 1
package/pkg-generic.mk:266 : recipe for target
'/home/valeria/MyProject/VoCore/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built'
failed
make[1]: ***
[/home/valeria/MyProject/VoCore/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built]
Error 2
Makefile:23: recipe for target '_all' failed
make: *** [_all] Error 2
and I have no idea how to fix this.
Any hint would be very welcome as this is a real show-stopper for me.
Thanks in Advance
Mauro
From 4a9d0b3ce9fcfca9fcb987f26c51600fee66b4e3 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli
Date: Wed, 2 Sep 2020 16:04:40 +0200
Subject: [PATCH 1/4] Small fixes to reduce size and ensure correct console
output.
Signed-off-by: Mauro Condarelli
---
arch/mips/dts/vocore_vocore2.dts | 2 +-
include/configs/vocore2.h| 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
index 3502e4b8b7..9adf39652f 100644
--- a/arch/mips/dts/vocore_vocore2.dts
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -59,7 +59,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
- spi-max-frequency = <2500>;
+ spi-max-frequency = <4000>;
reg = <0>;
};
};
diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h
index 40467b737c..29a57ad233 100644
--- a/include/configs/vocore2.h
+++ b/include/configs/vocore2.h
@@ -25,6 +25,7 @@
#define CONFIG_SPL_BSS_START_ADDR 0x
Re: [PATCH 1/1] sandbox: support CTRL-C processing in U-Boot
Hi Heinrich, On Fri, 18 Sep 2020 at 22:19, Heinrich Schuchardt wrote: > > Am 19. September 2020 04:59:46 MESZ schrieb Simon Glass : > >Hi Heinrich, > > > >On Thu, 17 Sep 2020 at 12:04, Heinrich Schuchardt > >wrote: > >> > >> Currently if SIGINT is received, it terminates U-Boot. This does not > >allow > >> testing the handling of CTRL-C in U-Boot and in UEFI applications. > >> It is especially annoying when working with the 'mm' command. > >> > >> Let the serial console driver provide character 0x03 if SIGINT > >occurs. We > >> can still exit U-Boot using the reset or poweroff command. > >> > >> Adjust the sandbox test_ctrl_c() Python test accordingly. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> arch/sandbox/cpu/os.c | 15 --- > >> drivers/serial/sandbox.c | 11 --- > >> include/os.h | 14 ++ > >> test/py/tests/test_sandbox_exit.py | 10 +- > >> 4 files changed, 43 insertions(+), 7 deletions(-) > > > >I'm sorry but I still do want Ctrl-C to work. How about adding a short > >option to change the terminal mode? > > > >Regards, > >Simon > > > On QEMU you quit via X. Can we use the same for the sandbox? I just don't like programs that refused to quit when asked. I use Ctrl-C all the time. Can you not use the -t options to get what you want? Perhaps we could have an environment variable too? Regards, Simon
Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
On 9/19/20 1:37 PM, Biju Das wrote:
[...]
>>> +static const struct udevice_id *of_soc_match_compatible(void) {
>>> +const struct udevice_id *of_match = soc_ids;
>>> +int i;
>>> +
>>> +for (i = 0; i < ARRAY_SIZE(soc_ids); i++) {
>>> +if (!fdt_node_check_compatible(gd->fdt_blob, 0,
>>> + of_match->compatible))
>>> +return of_match;
>>> +of_match++;
>>> +}
>>> +
>>> +return NULL;
>>> +}
>>
>> This should rather be a generic function, I think this is something that
>> already
>> exists in Linux common code too, right ?
>
> No. I have seen some other SoC's uses similar logic [1]& [2] .
I mean, this looks like Linux's soc_device_match() , so such a function
is likely generic code, there is nothing platform specific to it, is there ?
> [1]
> https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/board/samsung/common/exynos5-dt-types.c#L246
> [2]
> https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/mach-uniphier/boards.c#L156
>
>
>>> static int rmobile_cpuinfo_idx(void)
>>> {
>>> int i = 0;
>>> u32 cpu_type = rmobile_get_cpu_type();
>>> +const struct udevice_id *match = of_soc_match_compatible();
>>>
>>> +/*
>>> + * This loop identifies CPU based on PRR register, it differentiates
>>> + * RZ/G SoC's from R-Car SoC's by matching RZ/G SoC compatible
>> string
>>> + * from DT against the family_type.
>>> + */
>>> for (; i < ARRAY_SIZE(rmobile_cpuinfo); i++)
>>> -if (rmobile_cpuinfo[i].cpu_type == cpu_type)
>>> -break;
>>> +if (rmobile_cpuinfo[i].cpu_type == cpu_type) {
>>> +if (match &&
>>> +rmobile_cpuinfo[i].family_type == match->data)
>>> +break;
>>> +else if (!match &&
>>> + rmobile_cpuinfo[i].family_type !=
>> SOC_RZG2)
>>> +break;
>>> +}
>>
>> I still don't understand this, so if cpu_type ==
>> RMOBILE_CPU_TYPE_R8A7796 , then it can be either RZG2 or R8A7796, right?
>
> Yep you are right.
>
>> And there is no PRR bit or any other bit to tell those two chips apart ?
> No. Currently only way you can distinguish is by SoC compatible string and
> family type.
> See [3] for SoC identification logic used to differentiate RCar and RZ/G2
> [3]:-
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc5#n311
So Linux is matching on the compatible string of DT passed from U-Boot ,
right ? Linux has it easier then.
But where does U-Boot get that compatible string from, in case there are
multiple DTs passed to U-Boot and U-Boot needs to find out on which SoC
it is running on ?
Maybe you can pass the compatible from TFA, which is already happening.
>> I would like to avoid using the OF match here, because that fails if you use
>> MULTI_DTB_FIT , does it not ?
>
> No. It works OK on both RZ/G2SoC's[4] and RCar[5]
>
> [4] MULTI_DTB_FIT logs for RZG2[HMN] boards
>
> CPU: Renesas Electronics R8A774E1 rev 3.0
> Model: HopeRun HiHope RZ/G2H with sub board
> DRAM: 3.9 GiB
>
> CPU: Renesas Electronics R8A774A1 rev 1.3
> Model: HopeRun HiHope RZ/G2M with sub board
> DRAM: 3.9 GiB
>
> CPU: Renesas Electronics R8A774B1 rev 1.1
> Model: HopeRun HiHope RZ/G2N with sub board
> DRAM: 3.9 GiB
>
> [5] u-boot based on R-Car M3N using rcar3_salvator-x_defconfig, it reports
> proper SoC.
>
> CPU: Renesas Electronics R8A77965 rev 1.1
> Model: Renesas Salvator-XS board based on r8a77965
> DRAM: 1.9 GiB
> Bank #0: 0x04800 - 0x0bfff, 1.9 GiB
>
> MMC: sd@ee10: 0, sd@ee14: 1, sd@ee16: 2
> Loading Environment from MMC... OK
> In: serial@e6e88000
> Out: serial@e6e88000
> Err: serial@e6e88000
> Net: eth0: ethernet@e680
> Hit any key to stop autoboot: 0
> =>
>
> So can you please check whether there might
>> be some way to tell the two SoCs apart ?
>
> At present there is no way other than matching the SoC compatible string.
Thinking about it a bit more, if you were to use the compatible string
psssed from TFA in the / node, you could iterate over soc_ids[] array
and return RMOBILE_CPU_TYPE_x , which could be stored there as .data .
Then you won't even need the SOC_RZG2 and it would all be faster, as all
you would need is a single pass over a smaller array.
Re: [PATCH 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board support
On 9/19/20 2:18 PM, Biju Das wrote:
Hi,
[...]
>>> +++ b/board/hoperun/hihope-rzg2/hihope-rzg2.c
>>> @@ -0,0 +1,80 @@
>> [...]
>>> +#define RST_BASE0xE616
>>> +#define RST_CA57RESCNT(RST_BASE + 0x40)
>>> +#define RST_CODE0xA5A5000F
>>> +
>>> +/* If the firmware passed a device tree use it for U-Boot DRAM setup.
>>> +*/ extern u64 rcar_atf_boot_args[];
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +void s_init(void)
>>> +{
>>> +}
>>
>> Is this empty function needed ?
>
> Yes Compilation error otherwise. This function is called from
> lowlevel_init_gen3.S. I believe it is place holder for doing some early
> initialisation such as watchdog
> That could be the reason all rcar gen3 boards have this empty function for
> eg:-[1], please correct me if you think otherwise.
> [1] board/renesas/salvator-x/Salvator-x.c
Can you try fixing that with WEAK(s_init) in the lowlevel_init_gen3.S ?
I think that would be much better, if anyone needs to override the
function, then they can, otherwise empty WEAK function would be used.
>>> +#ifdef CONFIG_BOARD_EARLY_INIT_F
>>> +/* Kconfig forces this on, so just return 0 */
>>
>> I think BOARD_EARLY_INIT_F should really be disabled in Kconfig rather than
>> implementing empty function here.
>>
>
> Ok, will fix in v2.
>
> For eg:- file arch/arm/Kconfig
> Select BOARD_EARLY_INIT_FUNCTION if !(RZA1 || TARGET_HIHOPE_RZG2)
Maybe it would be better to use imply BOARD_EARLY_INIT_F , and then
disable it on boards which don't need it (RZA1 and RZG2)
> I also noticed other boards in board/renesas directory with empty
> function(for eg:- ebisu,condor etc).
> For completeness, do you want me to fix that as well in separate patch and
> removing empty functions.
> Select BOARD_EARLY_INIT_FUNCTION if !(RZA1 || TARGET_HIHOPE_RZG2||
> TARGET_EBISU || TARGET_CONDOR)
Look at the 'imply' keyword, that might be even better.
[...]
>>> +int fdtdec_board_setup(const void *fdt_blob) {
>>> +void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
>>> +
>>> +if (fdt_magic(atf_fdt_blob) == FDT_MAGIC)
>>> +fdt_overlay_apply_node((void *)fdt_blob, 0, atf_fdt_blob,
>> 0);
>>> +
>>> +return 0;
>>> +}
>>
>> Please use board/renesas/rcar-common/common.c , no need to duplicate
>> the code.
>
> OK will fix in V3.
Thanks
>>> +int dram_init(void)
>>> +{
>>> +return fdtdec_setup_mem_size_base(); }
>>> +
>>> +int dram_init_banksize(void)
>>> +{
>>> +return fdtdec_setup_memory_banksize(); }
>>> +
>>> +void reset_cpu(ulong addr)
>>> +{
>>> +writel(RST_CODE, RST_CA57RESCNT);
>>> +}
>>
>> Isn't there CA53 core in the RZG2 too ?
>
> Yes, big little CPU 2xCA57 + 4 xCA53. Do you want me to add reset code for in
> case of CA53 boot mode???
I think if you can start U-Boot on either core, then the reset function
should handle both, yes.
Re: [PATCH] net: ravb: Fix NULL pointer access
On 9/19/20 1:14 PM, Biju Das wrote: [...] >>> By looking at [1], only this driver is using writeext. >>> [1]https://elixir.bootlin.com/u-boot/v2020.10-rc4/A/ident/writeext >> >> git grep indicates a couple more sites where the writeext is called. >> But look into the KSZ9031 datasheet, that particular writeext call seems to >> be >> setting up RGMII Clock Pad Skew (MMD Address 2, Register 8), and I think >> there is a matching DT binding to set those up too, rxc-skew-ps and txc- >> skew-ps I think. > > Thanks for the pointers. I checked the configs[2] which uses renesas ravb > driver > and found that we are defining only rxc-skew-ps in all dts. > > since CONFIG DM_ETH is defined it is already picking the value corresponding > to "rxc-skew-ps". > > For txc-skew-ps anyway the value is default one. So we don't care. Are you sure (0xf << 5) | 0x19 is the same as the default value of the clock pad skew register ? [...]
Re: [PATCH v3 8/8] IPQ40xx: Add USB nodes
On Thu, Sep 10, 2020 at 04:00:06PM +0200, Robert Marko wrote: > There are drivers to support built in USB controller and PHY-s now, so lets > add the USB nodes to DTSI. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: Fix Coverity Scan defects
On Fri, Sep 11, 2020 at 12:21:06PM +0200, Joao Marcos Costa wrote: > Fix control flow issues and null pointer dereferences. > > Signed-off-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5] cmd: mem: fix range of bitflip test
On Wed, Sep 09, 2020 at 12:10:00PM -0400, Ralph Siemsen wrote:
> The bitflip test uses two equal sized memory buffers. This is achieved
> by splitting the range of memory into two pieces. The address of the
> second buffer, as well as the length of each buffer, were not correctly
> calculated. This caused bitflip test to access beyond the end of range.
> This patch fixes the pointer arithmetic problem.
>
> A second problem arises because u-boot "mtest" command expects the
> ending address to be inclusive. When computing (end - start) this
> results in missing 1 byte of the requested length. The bitflip test
> expects a count rather than an "ending" address. Thus it fails to test
> the last word of the requested range. Fixed by using (end - start + 1).
>
> Added Kconfig option to optionally disable the bitflip test, since it
> does add significantly to the time taken for "mtest".
>
> Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
> memory test to alternate mtest")
>
> Signed-off-by: Ralph Siemsen
> Reviewed-by: Stefan Roese
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] configs: bcmstb: Disable networking support
On Fri, Sep 11, 2020 at 02:41:44PM -0400, Thomas Fitzsimmons wrote: > Silence the "Driver Model for Ethernet drivers" migration warning for > the bcm7445 and bcm7260 ports, neither of which supports networking yet. > > Signed-off-by: Thomas Fitzsimmons > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: Fix Coverity Scan defects
On Fri, Sep 11, 2020 at 12:21:06PM +0200, Joao Marcos Costa wrote: > Fix control flow issues and null pointer dereferences. > > Signed-off-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 7/8] usb: dwc3: Add Qualcomm DWC3 compatible string
On Thu, Sep 10, 2020 at 04:00:05PM +0200, Robert Marko wrote: > Lot of Qualcomm SoC-s use DWC3 controller for both USB2.0 and USB3.0 > ports. > Qualcomm has some custom config registers on top of the generic ones, > but for host mode these are not needed. > > So lets add the neccessary compatible string. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/8] reset: Add IPQ40xx reset controller driver
On Thu, Sep 10, 2020 at 04:00:02PM +0200, Robert Marko wrote: > On Qualcomm IPQ40xx SoC series, GCC clock IP also handles the resets. > So since this will be needed by further drivers, lets add a driver for the > reset controller. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 6/8] phy: add driver for Qualcomm IPQ40xx USB PHY
On Thu, Sep 10, 2020 at 04:00:04PM +0200, Robert Marko wrote: > Add a driver to setup the USB PHY-s on Qualcomm IPQ40xx series SoCs. > The driver sets up HS and SS phys. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 3/8] IPQ40xx: Add SMEM support
On Thu, Sep 10, 2020 at 04:00:01PM +0200, Robert Marko wrote: > There is already existing driver for SMEM so lets enable it for IPQ40xx as > well. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/8] IPQ40xx: clk: Use dt-bindings instead of hardcoding
On Thu, Sep 10, 2020 at 04:00:00PM +0200, Robert Marko wrote: > Its common to use dt-bindings instead of hard-coding clocks or resets. > So lets use the imported Linux GCC bindings on IPQ40xx target. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/8] dt-bindings: clock: import Qualcomm IPQ4019 bindings
On Thu, Sep 10, 2020 at 03:59:59PM +0200, Robert Marko wrote: > Import Qualcomm IPQ4019 GCC bindings from Linux. > This will enable using bindings instead of raw clock numbers both in the > driver and DTS like Linux does. > > Signed-off-by: Robert Marko > Cc: Luka Perkov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board support
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board
> support
>
> On 9/18/20 6:03 PM, Biju Das wrote:
>
> [...]
>
> > +++ b/board/hoperun/hihope-rzg2/hihope-rzg2.c
> > @@ -0,0 +1,80 @@
> [...]
> > +#define RST_BASE0xE616
> > +#define RST_CA57RESCNT(RST_BASE + 0x40)
> > +#define RST_CODE0xA5A5000F
> > +
> > +/* If the firmware passed a device tree use it for U-Boot DRAM setup.
> > +*/ extern u64 rcar_atf_boot_args[];
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +void s_init(void)
> > +{
> > +}
>
> Is this empty function needed ?
Yes Compilation error otherwise. This function is called from
lowlevel_init_gen3.S. I believe it is place holder for doing some early
initialisation such as watchdog
That could be the reason all rcar gen3 boards have this empty function for
eg:-[1], please correct me if you think otherwise.
[1] board/renesas/salvator-x/Salvator-x.c
> > +#ifdef CONFIG_BOARD_EARLY_INIT_F
> > +/* Kconfig forces this on, so just return 0 */
>
> I think BOARD_EARLY_INIT_F should really be disabled in Kconfig rather than
> implementing empty function here.
>
Ok, will fix in v2.
For eg:- file arch/arm/Kconfig
Select BOARD_EARLY_INIT_FUNCTION if !(RZA1 || TARGET_HIHOPE_RZG2)
I also noticed other boards in board/renesas directory with empty function(for
eg:- ebisu,condor etc).
For completeness, do you want me to fix that as well in separate patch and
removing empty functions.
Select BOARD_EARLY_INIT_FUNCTION if !(RZA1 || TARGET_HIHOPE_RZG2|| TARGET_EBISU
|| TARGET_CONDOR)
> > +int board_early_init_f(void)
> > +{
> > +return 0;
> > +}
> > +#endif
>
>
> [...]
>
> > +int fdtdec_board_setup(const void *fdt_blob) {
> > +void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
> > +
> > +if (fdt_magic(atf_fdt_blob) == FDT_MAGIC)
> > +fdt_overlay_apply_node((void *)fdt_blob, 0, atf_fdt_blob,
> 0);
> > +
> > +return 0;
> > +}
>
> Please use board/renesas/rcar-common/common.c , no need to duplicate
> the code.
OK will fix in V3.
> > +int dram_init(void)
> > +{
> > +return fdtdec_setup_mem_size_base(); }
> > +
> > +int dram_init_banksize(void)
> > +{
> > +return fdtdec_setup_memory_banksize(); }
> > +
> > +void reset_cpu(ulong addr)
> > +{
> > +writel(RST_CODE, RST_CA57RESCNT);
> > +}
>
> Isn't there CA53 core in the RZG2 too ?
Yes, big little CPU 2xCA57 + 4 xCA53. Do you want me to add reset code for in
case of CA53 boot mode???
Cheers,
Biju
Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch,
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg.
no.: DE 14978647
Re: [PATCH 1/1] efi_loader: QEMU CONFIG_EFI_GRUB_ARM32_WORKAROUND=n
On 19.09.20 13:42, Mark Kettenis wrote:
>> From: Heinrich Schuchardt
>> Date: Thu, 17 Sep 2020 20:03:24 +0200
>>
>> On 9/17/20 7:47 PM, Tom Rini wrote:
>>> On Thu, Sep 17, 2020 at 07:18:08PM +0200, Heinrich Schuchardt wrote:
>>>
CONFIG_EFI_GRUB_ARM32 is only needed for architectures with caches that are
not managed via CP15 (or for some outdated buggy versions of GRUB). It
makes more sense to disable the setting per architecture than per
defconfig.
Move QEMU's CONFIG_EFI_GRUB_ARM32_WORKAROUND=n from defconfig to Kconfig.
Signed-off-by: Heinrich Schuchardt
---
configs/qemu_arm_defconfig | 1 -
lib/efi_loader/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Why? Are we about to move this to be a short list of "default y if ..."
>>> instead? Otherwise no, this is the level of detail that should be in a
>>> defconfig I think and not Kconfig.
>>>
>>
>> Hello Tom,
>>
>> yes, in the long run I want to turn this into "default y if". But I
>> first need to a list of all ARCH_* which have a cache which is not
>> controlled via CP15.
>
> It is fairly standard for SoCs with Cortex-A9 cores. Maybe some SoCs
> with Cortex-A8 are affected as well. Probably the list of affected
> SoCs is those that implement v7_outer_cache_enable().
>
git grep -n v7_outer_cache_enable
yields
arch/arm/cpu/armv7/cache_v7.c:210:__weak void v7_outer_cache_enable(void) {}
arch/arm/include/asm/armv7.h:128:void v7_outer_cache_enable(void);
arch/arm/mach-imx/cache.c:83:void v7_outer_cache_enable(void)
arch/arm/mach-mvebu/cpu.c:658:void v7_outer_cache_enable(void)
arch/arm/mach-omap2/omap3/board.c:433:void v7_outer_cache_enable(void)
arch/arm/mach-omap2/omap4/hwinit.c:166:void v7_outer_cache_enable(void)
arch/arm/mach-s5pc1xx/cache.c:27:void v7_outer_cache_enable(void)
arch/arm/mach-socfpga/misc.c:69:void v7_outer_cache_enable(void)
arch/arm/mach-uniphier/arm32/cache-uniphier.c:277:void
v7_outer_cache_enable(void)
arch/arm/mach-kirkwood/cache.c has an architecture specific
implementation of l2_cache_disable().
> However, since other 32-bit ARM UEFI implementation are generally not
> unavailable, I'm not sure disabling this workaround on other SoCs is
> feasable since the code oath for booting OSes without the MMU enabled
> may not be very well tested.
>
According to the UEFI spec we have to fulfill the following requirements
when handing over to the OS on ARM 32bit:
- MMU enabled
- Instruction and data caches enabled
- Access flag disabled
- Translation remap disabled
- Fast Context Switch Extension (FCSE) must be disabled
- caches requiring platform information to manage or invoke
non-architectural cache/TLB lockdown mechanisms disabled
With the GRUB workaround enabled we call cleanup_before_linux().
According to README.arm_caches this shall disable the MMU.
Mark, I do not understand your concerns regarding a disabled MMU when
*not* calling cleanup_before_linux().
Best regards
Heinrich
Re: RPi4 U-Boot freeze
On 2020-09-14 10:15, Matthias Brugger wrote:
> On 10/09/2020 23:12, Stefan Agner wrote:
>> On 2020-09-07 16:36, Peter Robinson wrote:
Any thoughts on this issue?
>>>
>>> Any reason why you're using 2020.01 and not at least 2020.07, or at
>>> least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has
>>> changed quite a bit since then I suspect.
>>>
>>
>> Hi Peter,
>>
>> It's a stable release and we support a couple of devices with the same
>> U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well.
>>
>> We are on 2020.07 on development branch, and it does work fine there. So
>> I thought it can't be that hard, just bisect and backport whatever fixes
>> it... Unfortunately, it seems that there is no particular commit which
>> fixes it (the bisect ended up in a random unrelated commit, and it seems
>> that the issue appears/disappears depending on alignment/size...).
>>
>> I also did applied pretty much every RPi4 related commit made after
>> 2020.01 up until master back to 2020.01, no success either.
>>
>
> Which version of the Raspberry Pi firmware did you use?
> Unfortunately changes in the FW breaks stuff on U-Boot from time to time.
>
Ok, I am now able to reproduce the issue on master as well as 2020.07
with standard rpi_4_32b_defconfig, but I still need to have parts of a
change which seems to trigger the issue in. From what I can tell, the
change *really* should not lead to a freeze. The change is just
accessing global variables from the data section... (see below).
To me it still seems as if relocation somehow did not work correctly in
one way or another.
Are there maybe restrictions in U-Boot when the data section can be
accessed? E.g. is it not legal to access the data section from the
serial driver?
diff --git a/drivers/serial/serial_bcm283x_mu.c
b/drivers/serial/serial_bcm283x_mu.c
index 8a4af87eb6..74de6801ab 100644
--- a/drivers/serial/serial_bcm283x_mu.c
+++ b/drivers/serial/serial_bcm283x_mu.c
@@ -50,7 +50,8 @@ struct bcm283x_mu_regs {
struct bcm283x_mu_priv {
struct bcm283x_mu_regs *regs;
};
-
+static char *fs_argv[15];
+static uint32_t putc_retry = 0;
static int bcm283x_mu_serial_getc(struct udevice *dev);
static int bcm283x_mu_serial_setbrg(struct udevice *dev, int baudrate)
@@ -95,6 +96,8 @@ static int bcm283x_mu_serial_putc(struct udevice *dev,
const char data)
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
struct bcm283x_mu_regs *regs = priv->regs;
+ putc_retry++;
+
/* Wait until there is space in the FIFO */
if (!(readl(®s->lsr) & BCM283X_MU_LSR_TX_EMPTY))
return -EAGAIN;
@@ -162,6 +165,10 @@ static int bcm283x_mu_serial_probe(struct udevice
*dev)
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
+ /* Make sure compiler does not optimize out this fs_argv
instance */
+ if (fs_argv[0])
+ fs_argv[0] = "test";
+
/* Don't spawn the device if it's not muxed */
if (!bcm283x_is_serial_muxed())
return -ENODEV;
Most curious of all, it seems that the name (!!!) of the variable
fs_argv matters! I am not sure if that changes order of variables in
data section or something. I can also reproduce the issue with two
compilers (GCC 8.3 and GCC 9.2), so a compiler error seems somewhat
unlikely...
Any ideas? I am a bit out of idea how to debug this (I guess JTAG/gdb
might help, but I don't have such a setup).
FWIW, I plan to just drop the change which seems to at least partially
cause the isssue
(https://github.com/home-assistant/operating-system/blob/dev/buildroot-external/board/raspberrypi/patches/uboot/0002-avoid-block-uart-write.patch).
Still I think there is something wrong which will show itself someday in
a certain configuration.
--
Stefan
> Regards,
> Mathias
>
>> I fear that the problem in fact is still in master, but only appears if
>> certain things align a certain way... That is why I thought I bring it
>> up, to see if anybody else has noticed something along this lines. We do
>> have a rather trimmed down configuration, which might make the problem
>> appear more (fit in a D cache...).
>>
>> I probably will just disable cached around relocation for 2020.01 and
>> see if it resurfaces on development branch.
>>
>> --
>> Stefan
>>
>>
Just to be sure, I did some memory testing on the 2GB module, but no
issues found.
I still somehow suspected that something else might be wrong with my
hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the
very same with that:
U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +)
DRAM: 3.9 GiB
I still think there is something wrong with caching. From what I
understand caches are enabled by the RPi (4) firmware. Is it safe to run
32-bit ARM U-Boot with enabled caches?
--
Stefan
On 2020-08-23 19:06, Stefan Agner wrote:
> Hi,
>
> I noticed
Re: [PATCH 1/1] efi_loader: QEMU CONFIG_EFI_GRUB_ARM32_WORKAROUND=n
> From: Heinrich Schuchardt > Date: Thu, 17 Sep 2020 20:03:24 +0200 > > On 9/17/20 7:47 PM, Tom Rini wrote: > > On Thu, Sep 17, 2020 at 07:18:08PM +0200, Heinrich Schuchardt wrote: > > > >> CONFIG_EFI_GRUB_ARM32 is only needed for architectures with caches that are > >> not managed via CP15 (or for some outdated buggy versions of GRUB). It > >> makes more sense to disable the setting per architecture than per > >> defconfig. > >> > >> Move QEMU's CONFIG_EFI_GRUB_ARM32_WORKAROUND=n from defconfig to Kconfig. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> configs/qemu_arm_defconfig | 1 - > >> lib/efi_loader/Kconfig | 1 + > >> 2 files changed, 1 insertion(+), 1 deletion(-) > > > > Why? Are we about to move this to be a short list of "default y if ..." > > instead? Otherwise no, this is the level of detail that should be in a > > defconfig I think and not Kconfig. > > > > Hello Tom, > > yes, in the long run I want to turn this into "default y if". But I > first need to a list of all ARCH_* which have a cache which is not > controlled via CP15. It is fairly standard for SoCs with Cortex-A9 cores. Maybe some SoCs with Cortex-A8 are affected as well. Probably the list of affected SoCs is those that implement v7_outer_cache_enable(). However, since other 32-bit ARM UEFI implementation are generally not unavailable, I'm not sure disabling this workaround on other SoCs is feasable since the code oath for booting OSes without the MMU enabled may not be very well tested.
RE: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
>
> On 9/18/20 6:03 PM, Biju Das wrote:
> > Add CPU and PRR IDs for R8A774A1(a.k.a RZ/G2M) SoC.
>
> [...]
>
> > +static const struct udevice_id *of_soc_match_compatible(void) {
> > +const struct udevice_id *of_match = soc_ids;
> > +int i;
> > +
> > +for (i = 0; i < ARRAY_SIZE(soc_ids); i++) {
> > +if (!fdt_node_check_compatible(gd->fdt_blob, 0,
> > + of_match->compatible))
> > +return of_match;
> > +of_match++;
> > +}
> > +
> > +return NULL;
> > +}
>
> This should rather be a generic function, I think this is something that
> already
> exists in Linux common code too, right ?
No. I have seen some other SoC's uses similar logic [1]& [2] .
[1]
https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/board/samsung/common/exynos5-dt-types.c#L246
[2]
https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/mach-uniphier/boards.c#L156
> > static int rmobile_cpuinfo_idx(void)
> > {
> > int i = 0;
> > u32 cpu_type = rmobile_get_cpu_type();
> > +const struct udevice_id *match = of_soc_match_compatible();
> >
> > +/*
> > + * This loop identifies CPU based on PRR register, it differentiates
> > + * RZ/G SoC's from R-Car SoC's by matching RZ/G SoC compatible
> string
> > + * from DT against the family_type.
> > + */
> > for (; i < ARRAY_SIZE(rmobile_cpuinfo); i++)
> > -if (rmobile_cpuinfo[i].cpu_type == cpu_type)
> > -break;
> > +if (rmobile_cpuinfo[i].cpu_type == cpu_type) {
> > +if (match &&
> > +rmobile_cpuinfo[i].family_type == match->data)
> > +break;
> > +else if (!match &&
> > + rmobile_cpuinfo[i].family_type !=
> SOC_RZG2)
> > +break;
> > +}
>
> I still don't understand this, so if cpu_type ==
> RMOBILE_CPU_TYPE_R8A7796 , then it can be either RZG2 or R8A7796, right?
Yep you are right.
> And there is no PRR bit or any other bit to tell those two chips apart ?
No. Currently only way you can distinguish is by SoC compatible string and
family type.
See [3] for SoC identification logic used to differentiate RCar and RZ/G2
[3]:-
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/renesas/renesas-soc.c?h=v5.9-rc5#n311
> I would like to avoid using the OF match here, because that fails if you use
> MULTI_DTB_FIT , does it not ?
No. It works OK on both RZ/G2SoC's[4] and RCar[5]
[4] MULTI_DTB_FIT logs for RZG2[HMN] boards
CPU: Renesas Electronics R8A774E1 rev 3.0
Model: HopeRun HiHope RZ/G2H with sub board
DRAM: 3.9 GiB
CPU: Renesas Electronics R8A774A1 rev 1.3
Model: HopeRun HiHope RZ/G2M with sub board
DRAM: 3.9 GiB
CPU: Renesas Electronics R8A774B1 rev 1.1
Model: HopeRun HiHope RZ/G2N with sub board
DRAM: 3.9 GiB
[5] u-boot based on R-Car M3N using rcar3_salvator-x_defconfig, it reports
proper SoC.
CPU: Renesas Electronics R8A77965 rev 1.1
Model: Renesas Salvator-XS board based on r8a77965
DRAM: 1.9 GiB
Bank #0: 0x04800 - 0x0bfff, 1.9 GiB
MMC: sd@ee10: 0, sd@ee14: 1, sd@ee16: 2
Loading Environment from MMC... OK
In: serial@e6e88000
Out: serial@e6e88000
Err: serial@e6e88000
Net: eth0: ethernet@e680
Hit any key to stop autoboot: 0
=>
So can you please check whether there might
> be some way to tell the two SoCs apart ?
At present there is no way other than matching the SoC compatible string.
Cheers,
Biju
Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch,
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg.
no.: DE 14978647
RE: [PATCH] net: ravb: Fix NULL pointer access
Hi Marek, Thanks for the feedback. > Subject: Re: [PATCH] net: ravb: Fix NULL pointer access > > On 9/18/20 5:26 PM, Biju Das wrote: > [...] > > > +++ b/drivers/net/ravb.c > > @@ -438,7 +438,8 @@ static int ravb_config(struct udevice *dev) > > > > writel(mask, eth->iobase + RAVB_REG_ECMR); > > > > -phy->drv->writeext(phy, -1, 0x02, 0x08, (0x0f << 5) | 0x19); > > +if (phy->drv->writeext) > > +phy->drv->writeext(phy, -1, 0x02, 0x08, (0x0f << 5) | 0x19); > > Shouldn't we rather move this into the PHY driver altogether ? > >>> > >>> If I fix, the phydriver with empty function, compiler will complain > >>> about > >> unused parameter right? > >>> What about other phy's which doesn't have this callback. > >> > >> I mean, should we not move this entire code which configures > >> something in a Micrel PHY, and is specific to Micrel PHY, into the > >> Micrel PHY driver and remove the whole call of writeext from this > ethernet driver ? > > > > Ok , this function is invoked during data transfer. > > The ravb_config() is invoked when starting the interface, see ravb_start(), it > is not repeatedly called during data transfer. Yep you are correct , it will be called during starting of the interface. I have seen the crash when I started doing tftp or ping, which in turn calls ravb_start. > > We could remove this function and test on all RCar boards to see any issues > present or not? > > No, because calling the writeext configures something in the Micrel > KSZ90x1 PHY, and by removing it, I suspect the Micrel PHY would stop > working. I agree, otherwise it will use default values which may cause issues. > > By looking at [1], only this driver is using writeext. > > [1]https://elixir.bootlin.com/u-boot/v2020.10-rc4/A/ident/writeext > > git grep indicates a couple more sites where the writeext is called. > But look into the KSZ9031 datasheet, that particular writeext call seems to be > setting up RGMII Clock Pad Skew (MMD Address 2, Register 8), and I think > there is a matching DT binding to set those up too, rxc-skew-ps and txc- > skew-ps I think. Thanks for the pointers. I checked the configs[2] which uses renesas ravb driver and found that we are defining only rxc-skew-ps in all dts. since CONFIG DM_ETH is defined it is already picking the value corresponding to "rxc-skew-ps". For txc-skew-ps anyway the value is default one. So we don't care. > So I think if you set those two DT properties in rcar2/3 DTs accordingly (and > that might already be the case, but please double-check), you can even drop > this entire writeext altogether. I did a grep and the below configs enables renesas ravb driver .Only Gen3 uses renesas ravb driver and all of them have "rxc-skew-ps" in Devicetree. So I agree with you, it is safe to remove writephyext. I will post V2, removing this [2] u-boot/configs/rcar3_ulcb_defconfig:CONFIG_RENESAS_RAVB=y u-boot/configs/r8a77990_ebisu_defconfig:CONFIG_RENESAS_RAVB=y u-boot/configs/r8a774a1_beacon_defconfig:CONFIG_RENESAS_RAVB=y u-boot/configs/hihope_rzg2_defconfig:CONFIG_RENESAS_RAVB=y u-boot/configs/r8a77995_draak_defconfig:CONFIG_RENESAS_RAVB=y u-boot/configs/r8a77970_eagle_defconfig:CONFIG_RENESAS_RAVB=y u-boot/configs/rcar3_salvator-x_defconfig:CONFIG_RENESAS_RAVB=y Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
