[U-Boot] U-Boot Digest, Vol 129, Issue 63
Terrance Chiang
chiang77 at gmail.com
Wed Feb 27 13:56:43 UTC 2019
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 at lists.denx.de> wrote:
> Send U-Boot mailing list submissions to
> u-boot at 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 at lists.denx.de
>
> You can reach the person managing the list at
> u-boot-owner at 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:
>
> 1. Re: [PATCH] efi_loader: Fix serial console size detection
> (Matthias Brugger)
> 2. Re: [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file
> must fit into 32 KiB (Simon Goldschmidt)
> 3. SDCRARD boot on Intel Arria10 SOCDK (Marcel Gielen [Celestia-STS])
> 4. [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 at suse.com>
> To: Heinrich Schuchardt <xypron.glpk at gmx.de>, matthias.bgg at kernel.org,
> agraf at csgraf.de
> Cc: u-boot at lists.denx.de, Matthias Brugger <mbrugger at suse.com>
> Subject: Re: [U-Boot] [PATCH] efi_loader: Fix serial console size
> detection
> Message-ID: <0d3f133f-ec80-bfdd-7b6b-3b35e493ab21 at 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 at kernel.org wrote:
> >> From: Matthias Brugger <mbrugger at 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 at 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)
> >> + return -1;
> >> }
> >> if (i != num - 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 at gmail.com>
> To: Heinrich Schuchardt <xypron.glpk at gmx.de>, Tom Rini
> <trini at konsulko.com>
> Cc: U-Boot Mailing List <u-boot at lists.denx.de>, David Wu
> <david.wu at rock-chips.com>, Jagan Teki <jagan at openedev.com>
> Subject: Re: [U-Boot] [PATCH v3 1/1] configs: rk3288: Tinker Board SPL
> file must fit into 32 KiB
> Message-ID:
> <
> CAAh8qszB72fLPHqcj6i2zJukm0ROYpRbTgC40nTeMTKKSytvFQ at 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 at gmail.com> wrote:
> >
> > On Thu, Feb 14, 2019 at 7:26 AM Heinrich Schuchardt <xypron.glpk at 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 at gmx.de>
> >
> > Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt at 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 at celestia-sts.com>
> To: "u-boot at lists.denx.de" <u-boot at lists.denx.de>
> Subject: [U-Boot] SDCRARD boot on Intel Arria10 SOCDK
> Message-ID:
> <
> AM5P193MB00171669DB7FA256E080294DA3740 at 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 at bitwise.fi>
> To: u-boot at lists.denx.de, Bernhard Messerklinger
> <bernhard.messerklinger at br-automation.com>
> Subject: [U-Boot] [PATCH v2] fs: fat: fix reading non-cluster-aligned
> root directory
> Message-ID: <20190227105557.20908-1-anssi.hannula at 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 at 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
>
> ------------------------------
>
> End of U-Boot Digest, Vol 129, Issue 63
> ***************************************
>
More information about the U-Boot
mailing list