Re: [PATCH] riscv: setup per-hart stack earlier
Hi Bo Gan, > From: Bo Gan > Sent: Tuesday, May 09, 2023 9:46 AM > To: u-boot@lists.denx.de > Cc: Bo Gan ; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) > Subject: [PATCH] riscv: setup per-hart stack earlier > > Harts need to use per-hart stack before any function call, even if that > function is a simple one. When the callee uses stack for register save/ > restore, especially RA, if nested call, concurrent access by multiple harts > on the same stack will cause data-race. > > This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of > this is that the memory layout has changed as the following: > > ++++ <- SPL_STACK/ > | ..|| hart 0 stack |SYS_INIT_SP_ADDR > | malloc_base |++ > ++| hart 1 stack | > | GD|++ If not SMP, N=1 > ++| ..| > | hart 0 stack |++ > ++ ==> | hart N-1 stack| > | hart 1 stack |++ > ++| ..| > | ..|| malloc_base | > ++++ > | hart N-1 stack|| GD| > ++++ > |||| > > Signed-off-by: Bo Gan > Cc: Rick Chen > Cc: Leo > --- > arch/riscv/cpu/start.S | 37 - > 1 file changed, 24 insertions(+), 13 deletions(-) > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index > dad22bf..90015c2 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -91,16 +91,35 @@ _start: > * Set stackpointer in internal/ex RAM to call board_init_f > */ > call_board_init_f: > - li t0, -16 > #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) > - li t1, CONFIG_SPL_STACK > + li t0, CONFIG_SPL_STACK > #else > - li t1, SYS_INIT_SP_ADDR > + li t0, CONFIG_SYS_INIT_SP_ADDR It builds fail as below: arch/riscv/cpu/start.S:97: Error: illegal operands `li t0,CONFIG_SYS_INIT_SP_ADDR' Thanks, Rick
Re: [PATCH v3 12/17] x86: Return mtrr_add_request() to its old purpose
Hi Simon,
On Tue, May 9, 2023 at 11:08 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Mon, 8 May 2023 at 08:51, Bin Meng wrote:
> >
> > On Mon, May 8, 2023 at 10:48 PM Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, May 5, 2023 at 6:51 AM Simon Glass wrote:
> > > >
> > > > This function used to be for adding a list of requests to be actioned on
> > > > relocation. Revert it back to this purpose, to avoid problems with
> > > > boards
> > > > which need control of their MTRRs (i.e. those which don't use FSP).
> > > >
> > > > The mtrr_set_next_var() function is available when the next free
> > > > variable-MTRR must be set, so this can be used instead.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > Fixes: 3bcd6cf89ef ("x86: mtrr: Skip MSRs that were already
> > > > programmed..")
> > > > Fixes: 596bd0589ad ("x86: mtrr: Do not clear the unused ones..")
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - Fix invalid commit IDs obtained from another branch
> > > >
> > > > arch/x86/cpu/mtrr.c | 6 +-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/cpu/mtrr.c b/arch/x86/cpu/mtrr.c
> > > > index e69dfb552b1..c174dd9b3ad 100644
> > > > --- a/arch/x86/cpu/mtrr.c
> > > > +++ b/arch/x86/cpu/mtrr.c
> > > > @@ -156,8 +156,12 @@ int mtrr_commit(bool do_caches)
> > > > debug("open done\n");
> > > > qsort(req, gd->arch.mtrr_req_count, sizeof(*req), h_comp_mtrr);
> > > > for (i = 0; i < gd->arch.mtrr_req_count; i++, req++)
> > > > - mtrr_set_next_var(req->type, req->start, req->size);
> > > > + set_var_mtrr(i, req->type, req->start, req->size);
> > >
> > > This change actually reverts 3bcd6cf89ef ("x86: mtrr: Skip MSRs that
> > > were already programmed.."), but as 3bcd6cf89ef commit message says:
> > >
> > > At present mtrr_commit() programs the MTRR MSRs starting from
> > > index 0, which may overwrite MSRs that were already programmed
> > > by previous boot stage or FSP.
> > >
> > > So this change will cause regression.
> > >
> > > >
> > > > + /* Clear the ones that are unused */
> > > > + debug("clear\n");
> > > > + for (; i < mtrr_get_var_count(); i++)
> > > > + wrmsrl(MTRR_PHYS_MASK_MSR(i), 0);
> > >
> > > This change actually reverts 596bd0589ad ("x86: mtrr: Do not clear the
> > > unused ones.."), which will also create regression unfortunately..
> > >
> > > > debug("close\n");
> > > > mtrr_close(, do_caches);
> > > > debug("mtrr done\n");
> > > > --
> >
> > The regression mentioned above will cause Intel Crown Bay fail to
> > boot. See
> > https://lore.kernel.org/u-boot/20210731084529.7524-1-bmeng...@gmail.com/
>
> Can that board perhaps use the other functoin to set MTRRs? It is
> mtrr_set_next_var()
mtrr_commit() is called by the following common places:
- arch/x86/lib/init_helpers.c::init_cache_f_r()
- arch/x86/lib/spl.c::board_init_f_r()
- arch/x86/lib/fsp/fsp_graphics.c::fsp_video_probe()
- drivers/video/vesa.c::vesa_video_probe()
> The change in the API has broken two of the Chromebooks which is why I
> am trying to go back to the way it was. Does this board set up the
> MTRRs in FSP? If so, perhaps we need a Kconfig for that? It is not
Yes, FSPv1 sets up the MTRRs.
> what the newer FSPs do, but perhaps we could use that behaviour for
> FSPv1?
This mtrr_commit() API is overloaded. On some places it is called with
caller's intention to initialize MTRRs completely from scratch but on
some other places it is called with caller's intention to initialize
the next available MTRR. We should make this API usage clear. I will
see if I can make a patch.
Regards,
Bin
Re: [PATCH] board: rockchip: Add Support for RG353PS and Panel Auto Detection
Hi Chris,
Please split this patch into a series with:
- driver update
- dts update
- config update.
Thanks,
- Kever
On 2023/5/13 00:34, Chris Morgan wrote:
From: Chris Morgan
Add support for panel auto detection for the Anbernic RGxx3 series.
This requires us to probe the DSI and DSI-DPHY controllers so that
we may send a MIPI_DCS_GET_DISPLAY_ID command to the panel to find
out which panel we are running. This requires creating a kind of
"skeleton" driver for the panel so we have just enough information
about it to issue the necessary command.
Once the panel type is determined the panel type is saved as an
environment variable, and additionally the panel compatible string
is automatically fixed-up in the devicetree if it is found to be
incompatible. There is a table of panel IDs and compatible strings,
support for a new panel only requires knowing the ID and the string.
Additionally, the device auto detection was changed so that it
mimicks the panel auto detection, requiring only defining a few
new values to add support for a new compatible board. This is done
while also adding a new board, the RG353PS.
Tested the auto detection on an RG353P, RG353PS (2nd revision panel),
RG353V, RG353V (2nd revision panel), RG353M, and RG503. As long as
the correct devicetrees were located in ${boot}/rockchip/. U-Boot
was able to automatically detect the correct board and panel and
boot each device correctly.
Signed-off-by: Chris Morgan
---
.../arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi | 10 +
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c| 322 +++---
configs/anbernic-rgxx3_defconfig | 15 +
3 files changed, 307 insertions(+), 40 deletions(-)
diff --git a/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
index a18e5d1cf7..f986e1941e 100644
--- a/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
+++ b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
@@ -46,7 +46,17 @@
< CLK_RTC32K_FRAC>;
};
+_dphy0 {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
+ pinctrl-0 = <_xfer>;
+ pinctrl-names = "default";
status = "okay";
};
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index decc46db78..027f4872bb 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -6,25 +6,37 @@
#include
#include
#include
+#include
#include
+#include
+#include
+#include
#include
+#include
+#include
+#include
#include
#include
#include
-#include
-#include
+#include
#define GPIO0_BASE 0xfdd6
+#define GPIO4_BASE 0xfe77
+#define GPIO_SWPORT_DR_L 0x
#define GPIO_SWPORT_DR_H 0x0004
+#define GPIO_SWPORT_DDR_L 0x0008
#define GPIO_SWPORT_DDR_H 0x000c
-#define GPIO_A5BIT(5)
-#define GPIO_A6BIT(6)
+#define GPIO_A0BIT(0)
+#define GPIO_C5BIT(5)
+#define GPIO_C6BIT(6)
+#define GPIO_C7BIT(7)
#define GPIO_WRITEMASK(bits) ((bits) << 16)
#define DTB_DIR "rockchip/"
struct rg3xx_model {
+ const u16 adc_value;
const char *board;
const char *board_name;
const char *fdtfile;
@@ -34,49 +46,74 @@ enum rgxx3_device_id {
RG353M,
RG353P,
RG353V,
- RG353VS,
RG503,
+ /* Devices with duplicate ADC value */
+ RG353PS,
+ RG353VS,
};
static const struct rg3xx_model rg3xx_model_details[] = {
[RG353M] = {
+ 517, /* Observed average from device */
"rk3566-anbernic-rg353m",
"RG353M",
- DTB_DIR "rk3566-anbernic-rg353m.dtb",
+ DTB_DIR "rk3566-anbernic-rg353p.dtb", /* Identical devices */
},
[RG353P] = {
+ 860, /* Documented value of 860 */
"rk3566-anbernic-rg353p",
"RG353P",
DTB_DIR "rk3566-anbernic-rg353p.dtb",
},
[RG353V] = {
+ 695, /* Observed average from device */
"rk3566-anbernic-rg353v",
"RG353V",
DTB_DIR "rk3566-anbernic-rg353v.dtb",
},
- [RG353VS] = {
- "rk3566-anbernic-rg353vs",
- "RG353VS",
- DTB_DIR "rk3566-anbernic-rg353vs.dtb",
- },
[RG503] = {
+ 1023, /* Observed average from device */
"rk3566-anbernic-rg503",
"RG503",
DTB_DIR "rk3566-anbernic-rg503.dtb",
},
+ /* Devices with duplicate ADC value */
+ [RG353PS] = {
+ 860, /* Gathered from second hand information */
+ "rk3566-anbernic-rg353ps",
+ "RG353PS",
+ DTB_DIR
Re: Issues with bcm2835-host: let firmware manage the clock divisor
Hi Nuno, Am 14.05.23 um 14:06 schrieb Nuno Gonçalves: Hi, after 85bdd28d2bb0827f311913e00e4e338f8e4e6565 (bcm2835-host: let firmware manage the clock divisor), Linux fails to start the eMMC memory on a CM3 most times (but it sometimes also works). thanks for your report. I am using Linux mainline and I wonder if this assumes the change in which this was based also needs to be used in Linux? Yes, this is very likely. But how can U-Boot assume that at least Linux is booting afterwards. How about the other OSes with devicetree support? In that case I would think it's fair to revert until it comes to mainline. Actually from the original commit i wasn't able to see a real benefit from the change. Shorter boot time? Thanks, Nuno
Re: [PATCH 2/2] bootstd: Create a new BOOTMETH_DISTRO
On Wed, May 10, 2023 at 04:34:47PM -0600, Simon Glass wrote: > We cannot be sure what bootmeth a distro will need to use. Add a new > BOOTMETH_DISTRO option which collects these together. Select this from > BOOTSTD_DEFAULTS so that it is clear what is needed. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] bootstd: Rename distro and syslinux to extlinux
On Wed, May 10, 2023 at 04:34:46PM -0600, Simon Glass wrote: > We use the terms 'distro' to mean extlinux but they are not really the > same. 'Distro' could refer to any method of booting a distribution, > whereas extlinux is a particular method. > > Also we sometimes use syslinux, but it is better to use the same term in > all cases. > > Rename distro to syslinux and also update bootstd uses of syslinux to use > extlinux instead. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] bootstd: Tidy up reporting of errors
On Wed, May 10, 2023 at 04:34:26PM -0600, Simon Glass wrote: > In a few cases the error handling is not quite right. Make sure we > return the actual error in distro_efi_read_bootflow_file() rather than > -EINVAL. Return -IO when a file cannot be read. Also show the error name > if available. > > This does not change operation, but does make it easier to diagnose > problems. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootstd: Correct default boot command
On Sat, May 06, 2023 at 08:27:09AM -0600, Simon Glass wrote:
> The patch to relax flag requirements was not accepted[1], so we still have
> to have separate bootcommands depending on CMD_BOOTFLOW_FULL.
>
> The previous attempt at this did not work, since it used the wrong name
> for the options.
>
> Fix this and change the message to mention BOOTSTD_FULL since this affects
> not just the flags, but all functionality, so is more likely what the user
> wants.
>
> Drop the useless condition on CMD_BOOTFLOW_FULL while we are here.
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20230329071655.1959513-2-...@chromium.org/
>
> Signed-off-by: Simon Glass
> Fixes: a91492b6e9c ("bootstd: Provide a default command")
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/3] bootstd: Require HUSH_PARSER for script booting
On Fri, May 05, 2023 at 08:03:05PM -0600, Simon Glass wrote: > Armbian uses a script which needs the HUSH parser. It is likely that > other distros will do the same. Enable it by default, just in case. > > Signed-off-by: Simon Glass > Tested-by: Jonas Karlman Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] bootstd: usb: Avoid initing USB twice
On Fri, May 05, 2023 at 08:03:04PM -0600, Simon Glass wrote: > This causes crashes on some boards, e.g. rockpro64. In any case, we > should not do it. > > Check the usb_started flag to avoid this. > > Signed-off-by: Simon Glass > Tested-by: Jonas Karlman > Tested-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] usb: Tidy up the usb_start flag
On Fri, May 05, 2023 at 08:03:03PM -0600, Simon Glass wrote: > This should be declared in a header file so that type-checking works > correctly. > > Add a single declaration to usb.h and remove the others. > > Signed-off-by: Simon Glass > Reviewed-by: Marek Vasut > Reviewed-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/18] bootstd: Work around missing partition 1
On Fri, Apr 28, 2023 at 01:18:09PM -0600, Simon Glass wrote: > If there is no partition numbered 1, we decide that there are no > partitions at all. That may not be correct, since at least one Debian > installed has just a single partition numbered 2. > > Continue searching up to partition 3, just in case. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] clang: Link with --no-pie instead of --apply-dynamic-relocs
On Fri, May 12, 2023 at 05:01:35PM -0600, Sam Edwards wrote: > The goal of using --apply-dynamic-relocs seems to be to have all > relocations applied "statically" to the output binary, so that > the dynamic segment can be dropped safely. However, LLD still > creates sections to support the dynamic section, and platform > linker scripts may not know to discard these. > > Since the build process does not appear to make use of the dynamic > segment at all, it would be more sensible to suppress it entirely. > > Signed-off-by: Sam Edwards > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 20785860f7..d71127e412 100644 > --- a/Makefile > +++ b/Makefile > @@ -1024,7 +1024,7 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL) > LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker) > > # ld.lld support > -LDFLAGS_u-boot += -z notext $(call ld-option,--apply-dynamic-relocs) > +LDFLAGS_u-boot += -z notext $(call ld-option,--no-pie) > > LDFLAGS_u-boot += --build-id=none > How extensively have you tested this change? We don't install ld.lld in our container environment right now (but should..) and from some local testing I forget if we need to pass further make logic in to have ld.lld be used instead. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] makefile: Fix symbol typo in binary_size_check
On Fri, May 12, 2023 at 05:01:33PM -0600, Sam Edwards wrote: > The start-of-image marker symbol is `__image_copy_start`; by > searching for `_image_copy_start` instead, this check can > accidentally match `_image_copy_start_ofs`. > > Signed-off-by: Sam Edwards Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Issues with bcm2835-host: let firmware manage the clock divisor
Hi, after 85bdd28d2bb0827f311913e00e4e338f8e4e6565 (bcm2835-host: let firmware manage the clock divisor), Linux fails to start the eMMC memory on a CM3 most times (but it sometimes also works). I am using Linux mainline and I wonder if this assumes the change in which this was based also needs to be used in Linux? In that case I would think it's fair to revert until it comes to mainline. Thanks, Nuno
