Re: [U-Boot] U-Boot Digest, Vol 129, Issue 63

Currently switch is unable to boot pass Nintendo logo, will revert a nand backup to the first uboot error which includes and the files created from Uboot. The rest of the error after that are (after running different files like kip files are results of me trying to retrieve inital setup.
Is it because of the firmware update 6.20 that messes everything. Some payloads returns with tesc key and tes root key. All payloads can't retrieve biskeys. Red QR code or only 3 keys, Tesc keys, SBW and Aes key which is only two amd it indicate Aes0 and a AES test key.
However, i did not remember what i did, and i got the crypto amd tweats for biskeys Unable to do clean nand backup with any cfw. Restore from any firmware will give error and can't boot normal or cfw. But can enter cfw mainmenu to launch payload. Will let you all know what are the results when done
Thanks and best regards Terrance Chiang
On Wed, 27 Feb 2019, 20:00 , u-boot-request@lists.denx.de wrote:
Send U-Boot mailing list submissions to u-boot@lists.denx.de
To subscribe or unsubscribe via the World Wide Web, visit https://lists.denx.de/listinfo/u-boot or, via email, send a message with subject or body 'help' to u-boot-request@lists.denx.de
You can reach the person managing the list at u-boot-owner@lists.denx.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot digest..."
Today's Topics:
- Re: [PATCH] efi_loader: Fix serial console size detection (Matthias Brugger)
- Re: [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB (Simon Goldschmidt)
- SDCRARD boot on Intel Arria10 SOCDK (Marcel Gielen [Celestia-STS])
- [PATCH v2] fs: fat: fix reading non-cluster-aligned root directory (Anssi Hannula)
Message: 1 Date: Wed, 27 Feb 2019 10:55:00 +0100 From: Matthias Brugger mbrugger@suse.com To: Heinrich Schuchardt xypron.glpk@gmx.de, matthias.bgg@kernel.org, agraf@csgraf.de Cc: u-boot@lists.denx.de, Matthias Brugger mbrugger@suse.com Subject: Re: [U-Boot] [PATCH] efi_loader: Fix serial console size detection Message-ID: 0d3f133f-ec80-bfdd-7b6b-3b35e493ab21@suse.com Content-Type: text/plain; charset=utf-8
On 26/02/2019 17:58, Heinrich Schuchardt wrote:
On 2/26/19 12:46 PM, matthias.bgg@kernel.org wrote:
From: Matthias Brugger mbrugger@suse.com
Function term_read_reply tries to read from the serial console until the end_char was read. This can hang forever if we are, for some reason, not be able to read the full response (e.g. serial buffer too small, frame error). This patch moves the timeout detection into term_read_reply to assure we will make progress.
Fixes: 6bb591f704 ("efi_loader: query serial console size reliably") Signed-off-by: Matthias Brugger mbrugger@suse.com
Thanks Matthias for the patch.
The general direction is right. Yet I would prefer if you could move the waiting loop as described below.
lib/efi_loader/efi_console.c | 63 +++++++++++++++++++++--------------- 1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index 66c33a551d..817220455f 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -62,6 +62,16 @@ static struct simple_text_output_mode efi_con_mode =
{
.cursor_visible = 1,
};
+static int term_get_char(char *c) +{
- if (tstc()) {
*c = getc();
return 0;
- }
- return 1;
The function signals an error if the character to read is not yet in the UART buffer. I think it would be preferable to put the waiting time (100 ms is sufficient at 110 baud and above) into this function instead. This has the following advantages:
- We would need only one waiting loop.
- We could reuse the function in function efi_cin_read_key() where we have another chance to hang waiting for a character.
Ok, I'll do that in v2.
+}
/*
- Receive and parse a reply from the terminal.
@@ -74,32 +84,42 @@ static int term_read_reply(int *n, int num, char
end_char)
{ char c; int i = 0;
- u64 timeout;
- c = getc();
- if (c != cESC)
- /* Allow up to one second for the response */
- timeout = timer_get_us() + 1000000;
Even at 110 baud a waiting time of 100 ms is sufficient.
So we don't have to wait up to one second for the first character to arrive as we did in query_console_serial() before this patch?
- while (!tstc())
if (timer_get_us() > timeout)
return -1;
This loop could be moved to term_get_char().
- if (term_get_char(&c) || c != cESC) return -1;
- c = getc();
- if (c != '[')
- if (term_get_char(&c) || c != '[')
We should allow time for this character to arrive.
return -1; n[0] = 0; while (1) {
c = getc();
if (c == ';') {
i++;
if (i >= num)> + if
(!term_get_char(&c)) {
On loop entry there is no wait before this term_get_char().
I don't understand, if the character is not yet present, we will loop in the while until it arrives or we hit the timeout.
Regards, Matthias
Best regards
Heinrich
if (c == ';') {
i++;
if (i >= num)
return -1;
n[i] = 0;
continue;
} else if (c == end_char) {
break;
} else if (c > '9' || c < '0') { return -1;
n[i] = 0;
continue;
} else if (c == end_char) {
break;
} else if (c > '9' || c < '0') {
return -1;
}
/* Read one more decimal position */
n[i] *= 10;
n[i] += c - '0'; }
/* Read one more decimal position */
n[i] *= 10;
n[i] += c - '0';
if (timer_get_us() > timeout)
} if (i != num - 1) return -1;return -1;
@@ -196,7 +216,6 @@ static int query_console_serial(int *rows, int
*cols)
{ int ret = 0; int n[2];
u64 timeout;
/* Empty input buffer */ while (tstc())
@@ -216,14 +235,6 @@ static int query_console_serial(int *rows, int
*cols)
ESC "[999;999H" /* Move to bottom right corner */ ESC "[6n"); /* Query cursor position */
- /* Allow up to one second for a response */
- timeout = timer_get_us() + 1000000;
- while (!tstc())
if (timer_get_us() > timeout) {
ret = -1;
goto out;
}
- /* Read {rows,cols} */ if (term_read_reply(n, 2, 'R')) { ret = 1;
Message: 2 Date: Wed, 27 Feb 2019 11:15:23 +0100 From: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com To: Heinrich Schuchardt xypron.glpk@gmx.de, Tom Rini trini@konsulko.com Cc: U-Boot Mailing List u-boot@lists.denx.de, David Wu david.wu@rock-chips.com, Jagan Teki jagan@openedev.com Subject: Re: [U-Boot] [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB Message-ID: < CAAh8qszB72fLPHqcj6i2zJukm0ROYpRbTgC40nTeMTKKSytvFQ@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"
Tom,
On Thu, Feb 14, 2019 at 10:20 AM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
On Thu, Feb 14, 2019 at 7:26 AM Heinrich Schuchardt xypron.glpk@gmx.de
wrote:
The SPL image for the Tinker Board has to fit into 32 KiB. This
includes
up to 2 KiB for the file header.
A new configuration variable CONFIG_SPL_WITH_DTB_SIZE_LIMIT is
introduced
to define the board specific limit.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
Reviewed-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
Is this planned for v2019.04? I know we're in rc phase, but this patch adds a new config option so shouldn't interfere with boards not using it.
Plus if we have this SPL size check in v2019.04, it would probably enable more board maintainers testing/fixing the SPL size check after the release.
Regards, Simon
v3 The maximum size should of the image should be 30 KiB. Allowing 2 KiB for the header. This is 30720 and not 32700 bytes. v2 Instead of using CONFIG_SPL_MAX_SIZE with an estimate of the
FDT
size introduce a new test in scripts/Makefile.spl.
Kconfig | 8 ++++++++ configs/tinker-rk3288_defconfig | 1 + scripts/Makefile.spl | 16 ++++++++++++++++ 3 files changed, 25 insertions(+)
diff --git a/Kconfig b/Kconfig index 512c7beb89..7cce53da74 100644 --- a/Kconfig +++ b/Kconfig @@ -172,6 +172,14 @@ config TPL_SYS_MALLOC_F_LEN particular needs this to operate, so that it can allocate the initial serial device and any others that are needed.
+config SPL_WITH_DTB_SIZE_LIMIT
int "Maximum size of SPL image including device tree"
depends on SPL
default 0
help
Specifies the maximum length of the U-Boot SPL image
including the
device tree. If this value is zero, it is ignored.
menuconfig EXPERT bool "Configure standard U-Boot features (expert users)" default y diff --git a/configs/tinker-rk3288_defconfig
b/configs/tinker-rk3288_defconfig
index fdcab28185..cc5e59bcf1 100644 --- a/configs/tinker-rk3288_defconfig +++ b/configs/tinker-rk3288_defconfig @@ -3,6 +3,7 @@ CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x00000000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_ROCKCHIP_RK3288=y +CONFIG_SPL_WITH_DTB_SIZE_LIMIT=30720 CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y CONFIG_TARGET_TINKER_RK3288=y CONFIG_DEBUG_UART_BASE=0xff690000 diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 9d5921606e..afc329a410 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -254,11 +254,27 @@ FINAL_DTB_CONTAINER =
$(obj)/$(SPL_BIN).multidtb.fit
endif
+ifneq ($(CONFIG_SPL_WITH_DTB_SIZE_LIMIT),0) +SPL_WITH_DTB_SIZE_CHECK = \
@actual=`wc -c $@ | awk '{print $$1}'`; \
limit=`printf "%d" $(CONFIG_SPL_WITH_DTB_SIZE_LIMIT)`; \
if test $$actual -gt $$limit; then \
echo "$@ exceeds file size limit:" >&2 ; \
echo " limit: $$limit bytes" >&2 ; \
echo " actual: $$actual bytes" >&2 ; \
echo " excess: $$((actual - limit)) bytes" >&2; \
exit 1; \
fi
+else +SPL_WITH_DTB_SIZE_CHECK = +endif
ifeq
($(CONFIG_$(SPL_TPL_)OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),yy)
$(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \ $(if
$(CONFIG_SPL_SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
$(FINAL_DTB_CONTAINER) FORCE $(call if_changed,cat)
$(SPL_WITH_DTB_SIZE_CHECK)
$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-dtb.bin FORCE $(call if_changed,copy) -- 2.20.1
Message: 3 Date: Wed, 27 Feb 2019 10:19:57 +0000 From: "Marcel Gielen [Celestia-STS]" M.Gielen@celestia-sts.com To: "u-boot@lists.denx.de" u-boot@lists.denx.de Subject: [U-Boot] SDCRARD boot on Intel Arria10 SOCDK Message-ID: < AM5P193MB00171669DB7FA256E080294DA3740@AM5P193MB0017.EURP193.PROD.OUTLOOK.COM
Content-Type: text/plain; charset="us-ascii"
We are trying to setup the Arria10 SOCDK (DK-SOC-10AS066S-A) to boot form SDCARD in RAW mode. We are under the impression this has never been used before.
Kconfig sets SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR to 0x200 for ARCH_SOCFPGA, which is correct for the Cyclone-V, but not anymore for Arria-10. The SPL image size handled in the A10 bootROM is increased from 64KiB to 256KiB, which would result in an offset 0x800.
The boot process, however ends up in an MMC timeout when trying to boot ( v2019.01 ). Didn't peform any further checks yet, but it looks like card is not responding after this stage. The board boots with an Intel branched u-boot, we like to avoid this branch and stick to mainline.
Default arria10 config: Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices
With CONFIG_MMC_DW enabled: Trying to boot from MMC1 spl: partition error
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR: mmc_load_image_raw_sector: mmc block read error
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800: mmc_load_image_raw_sector: mmc block read error
CONFIG_SD_BOOT: mmc_load_image_raw_sector: mmc block read error
Any suggestion how to setup RAW mode for A10 ? (with a C5 we have no issues using the same options) A10 does not requires SPL, but using SPL would allow more options in the u-boot image. What is the preferred bootmode to use for A10 ( No SPL, SPL with RAW mode, SPL with u-boot on FAT partition (We prefer to avoid FAT), SPL with u-boot on ext partition )
Regards, Marcej
Message: 4 Date: Wed, 27 Feb 2019 12:55:57 +0200 From: Anssi Hannula anssi.hannula@bitwise.fi To: u-boot@lists.denx.de, Bernhard Messerklinger bernhard.messerklinger@br-automation.com Subject: [U-Boot] [PATCH v2] fs: fat: fix reading non-cluster-aligned root directory Message-ID: 20190227105557.20908-1-anssi.hannula@bitwise.fi
A FAT12/FAT16 root directory location is specified by a sector offset and it might not start at a cluster boundary. It also resides before the data area (before cluster 2).
However, the current code assumes that the root directory is located at a beginning of a cluster, causing no files to be found if that is not the case.
Since the FAT12/FAT16 root directory is located before the data area and is not aligned to clusters, using unsigned cluster numbers to refer to the root directory does not work well (the "cluster number" may be negative, and even allowing it be signed would not make it properly aligned).
Modify the code to not use the normal cluster numbering when referring to the root directory of FAT12/FAT16 and instead use a cluster-sized offsets counted from the root directory start sector.
This is a relatively common case as at least the filesystem formatter on Win7 seems to create such filesystems by default on 2GB USB sticks when "FAT" is selected (cluster size 64 sectors, rootdir size 32 sectors, rootdir starts at half a cluster before cluster 2).
dosfstools mkfs.vfat does not seem to create affected filesystems.
Signed-off-by: Anssi Hannula anssi.hannula@bitwise.fi
v2: Rewrite to avoid negative "cluster numbers".
Hi,
I'm sorry about not responding in a timely manner.
Bernhard Messerklinger wrote:
clust_size = 2 rootdir_sect = 113 dara_begin = 132
sect_to_clust: 0xfffffff1 = (0x113 - 132) / 2 sect_to_clust: 114 = 132 + 0xfffffff1 * 2
Now my root_cluster is above the root dir but it should be below it
(112).
You are right, root_cluster going negative is not being handled properly.
However, I'd rather avoid that in the first place, as the code generally assumes that cluster numbers are unsigned - which is the reality as well, it is just that the FAT12/16 rootdir is located before the clusters.
So here is a different take on the original patch that instead avoids using the "cluster numbers" to refer to the root directory on FAT12/16 altogether.
fs/fat/fat.c | 47 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 6ade4ea54e..c5997c2173 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -602,8 +602,13 @@ static int get_fs_info(fsdata *mydata) mydata->data_begin = mydata->rootdir_sect + mydata->rootdir_size - (mydata->clust_size * 2);
mydata->root_cluster =
sect_to_clust(mydata, mydata->rootdir_sect);
/*
* The root directory is not cluster-aligned and may be on
a
* "negative" cluster, this will be handled specially in
* next_cluster().
*/
mydata->root_cluster = 0; } mydata->fatbufnum = -1;
@@ -733,20 +738,38 @@ static void fat_itr_child(fat_itr *itr, fat_itr *parent) itr->last_cluster = 0; }
-static void *next_cluster(fat_itr *itr) +static void *next_cluster(fat_itr *itr, unsigned *nbytes) { fsdata *mydata = itr->fsdata; /* for silly macros */ int ret; u32 sect;
u32 read_size; /* have we reached the end? */ if (itr->last_cluster) return NULL;
sect = clust_to_sect(itr->fsdata, itr->next_clust);
if (itr->is_root && itr->fsdata->fatsize != 32) {
/*
* The root directory is located before the data area and
* cannot be indexed using the regular unsigned cluster
* numbers (it may start at a "negative" cluster or not at
a
* cluster boundary at all), so consider itr->next_clust
to be
* a offset in cluster-sized units from the start of
rootdir.
*/
unsigned sect_offset = itr->next_clust *
itr->fsdata->clust_size;
unsigned remaining_sects = itr->fsdata->rootdir_size -
sect_offset;
sect = itr->fsdata->rootdir_sect + sect_offset;
/* do not read past the end of rootdir */
read_size = min_t(u32, itr->fsdata->clust_size,
remaining_sects);
} else {
sect = clust_to_sect(itr->fsdata, itr->next_clust);
read_size = itr->fsdata->clust_size;
}
debug("FAT read(sect=%d), clust_size=%d, DIRENTSPERBLOCK=%zd\n",
sect, itr->fsdata->clust_size, DIRENTSPERBLOCK);
debug("FAT read(sect=%d), clust_size=%d, read_size=%u,
DIRENTSPERBLOCK=%zd\n",
sect, itr->fsdata->clust_size, read_size, DIRENTSPERBLOCK); /* * NOTE: do_fat_read_at() had complicated logic to deal w/
@@ -757,18 +780,17 @@ static void *next_cluster(fat_itr *itr) * dent at a time and iteratively constructing the vfat long * name. */
ret = disk_read(sect, itr->fsdata->clust_size,
itr->block);
ret = disk_read(sect, read_size, itr->block); if (ret < 0) { debug("Error: reading block\n"); return NULL; }
*nbytes = read_size * itr->fsdata->sect_size; itr->clust = itr->next_clust; if (itr->is_root && itr->fsdata->fatsize != 32) { itr->next_clust++;
sect = clust_to_sect(itr->fsdata, itr->next_clust);
if (sect - itr->fsdata->rootdir_sect >=
if (itr->next_clust * itr->fsdata->clust_size >= itr->fsdata->rootdir_size) { debug("nextclust: 0x%x\n", itr->next_clust); itr->last_cluster = 1;
@@ -787,9 +809,8 @@ static void *next_cluster(fat_itr *itr) static dir_entry *next_dent(fat_itr *itr) { if (itr->remaining == 0) {
struct dir_entry *dent = next_cluster(itr);
unsigned nbytes = itr->fsdata->sect_size *
itr->fsdata->clust_size;
unsigned nbytes;
struct dir_entry *dent = next_cluster(itr, &nbytes); /* have we reached the last cluster? */ if (!dent) {
-- Anssi Hannula / Bitwise Oy
Subject: Digest Footer
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
End of U-Boot Digest, Vol 129, Issue 63
participants (1)
-
Terrance Chiang