Re: pull request of u-boot-fsl-qoriq for v2020.04-rc2
On Wed, Feb 05, 2020 at 06:13:51AM +, Priyanka Jain wrote: > Dear Tom, > > Please find my pull-request for u-boot-fsl-qoriq/master > https://travis-ci.org/p-priyanka-jain/u-boot/builds/645892188 > > Summary > Bug fixes on ls1012a, ls1021a, ls1028ardb platforms > Integrate fspi for ls1028a , add DM-I2C support, > update secure boot header offset > > priyankajain Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] Sharing a hardware lab
On 2/5/20 7:10 AM, Simon Glass wrote: Hi Tom, On Wed, 4 Dec 2019 at 15:30, Tom Rini wrote: On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote: Hi Tom, I have been meaning to have a crack at setting up a little hardware lab for a while. I made some progress recently and hooked up a rpi_3 with sdwire for USB/SD, ykush for power and a little computer to control it. It builds U-Boot, sticks it on the SD card and runs pytest. I pushed a tree here and hopefully you can see the 'hwlab' thing at the end: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/148 So far it is just running the 'help' test. It seems to hang with serial console problems if I try to do more. It is not 100% reliable yet. I based it on Stephen's test hooks: https://github.com/sglass68/uboot-test-hooks Is it possible to share this so that others can use the lab when they push trees? Is it as simple as adding to the .gitlab-ci.yml file as I have done here? https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/gitlab-working/.gitlab-ci.yml I also got tbot going in a similar way, to test booting into Linux. Should we look at integrating that at the same time? It should be fairly easy to do. I have quite a lot of random boards and in principle it should not be too hard to hook up some more of them, with sufficient SDwires, hubs and patience. Bumping this thread as I have now hooked up about about 8 mostly ARM and x86 boards and have tbot and pytest automation mostly working for them. There's two parts of this. The first part I think is that we need some good examples of how to have one private CI job poll / monitor other public jobs and run. I believe some labs do this today. This would be helpful as at least personally I'm kicking my hardware tests manually. This is because as best I can tell there isn't a way to include an optional stage/portion of a CI job. So the model here is that people with a lab 'watch' various repos? I think that would be useful. Stephen Warren does this I think, but I'm not sure how the builds are kicked off. Yes, my Jenkins instance directly polls the relevant git repos/branches for changes, then do a full build and test cycle, so is independent of anything else. Well actually, I mirror the git repos locally and Jenkins polls the mirrors, so that when I run n builds, the upstream git serves only get hit once for the mirroring operation, and not once per build, but that's an implementation detail.
RE: [U-Boot Patch v2 0/4] Fix currently available support for flash on HiFive Unleashed
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:21 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 0/4] Fix currently available support for flash
> on
> HiFive Unleashed
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > Currently device ID for flash mounted on HiFive Unleashed is added to
> > U-Boot. Also there are few patches about to go in mainline (Thanks to
> > Jagan Tekki and Bin Meng).
> >
> > This series addresses few issues discussed there:
> > Patch 1:Add num-cs to device tree which is used by spi-uclass to detect
> > valid chip select numbers
> > Patch 2:Handles valid chip selects only. Flash device is now detected only
> > on chip select 0.
> > Patch 3:Over-ride spi tx/rx width specified in hifive-unleshed-a00.dts file
> > from 4 to 1 in corresponding -u-boot.dtsi
> >
>
> Thank you for fixing all these SPI flash issues!
>
> > This series is based on mainline commit c05b38df477a ("common: fix
> > regression on block cache init") and two below mentioned patches from
> > [1] [U-Boot,v2,4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi
> > [U-Boot,v2,5/5] sifive: fu540: Enable spi-nor flash support
> >
> > [1] https://patchwork.ozlabs.org/patch/1177979/
> >
> > The above series is available for testing here[2] [2]
> > https://github.com/sagsifive/u-boot/tree/dev/sagark/test_spi-nor_v2
> >
> > Change History:
> > V1-V2:
> > 1. Dropped 6th and 7th patch sent in V1 from this series so as to separate
> >out spi-nor related changes in different series and avoid adding TODO
> >fixes to spi-nor-core framework.
>
> Did you resend the 6th and 7th patches as a separate series? I can't find
> them on the ML.
>
Thanks for your review Bin.
I have differed 6th and 7th patches as of now, as these could be handled
separately as it contained a TODO part which was not suitable to be introduced
into the spi-nor framework. So for now, I have added a workaround in the 3rd
patch
using which one can a working flash support.
BR,
Sagar
> > 2. Removed patch to include -uboot.dts, as it gets automatically included.
> > 3. Over-ride tx/rx width from hifive-unleashed-a00.dts using hifive
> >-unleashed-a00-u-boot.dtsi
> > 4. Print fdt base address in board info for debugging.
> >
> > V1: First version of series
> >
> >
> > Log for reference= Flash
> detection
> > only at valid Chip select => sf probe 0:0
> > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB,
> > total 32 MiB => sf probe 0:1 Invalid cs number = 1 Failed to
> > initialize SPI flash at 0:1 (error -22) => sf probe 0:2 Invalid cs
> > number = 2 Failed to initialize SPI flash at 0:2 (error -22) => sf
> > probe 0:0
> > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB,
> > total 32 MiB
> >
> > =>
> > Full flash memory erase/write/read/validate => mw 0x8060
> > 0x12348765 0x80 => sf erase 0x0 0x200
> > SF: 33554432 bytes @ 0x0 Erased: OK
> > => sf write 0x8060 0x0 0x200
> > device 0 whole chip
> > SF: 33554432 bytes @ 0x0 Written: OK
> > => sf read 0x8260 0x0 0x200
> > device 0 whole chip
> > SF: 33554432 bytes @ 0x0 Read: OK
> > => cmp.b 0x8060 0x8260 0x200 Total of 33554432 byte(s)
> > were the same
> > =>
>
> Regards,
> Bin
Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"
Hi Rasmus,
On Tue, 4 Feb 2020 at 18:08, Rasmus Villemoes
wrote:
>
> Currently, there's no way to fetch the value of an environment
> variable whose name is stored in some other variable, or generated from
> such - in non-working pseudo-code,
>
> ${${varname}}
> ${array${index}}
>
> This forces some scripts to needlessly duplicate logic and hardcode
> assumptions. For example, in an A/B scheme with three variables
>
> BOOT_ORDER # Either "A B" or "B A" depending on which slot was last updated
> BOOT_A_LEFT # 0..3
> BOOT_B_LEFT # 0..3
>
> when one needs to determine the slot to boot from, one does something
> like
>
> setenv found
> for slot in $BOOT_ORDER ; do
> if test "x$found" != "x" ; then
> # work around lack of break
> elif test "x$slot" = "xA" ; then
> if test $BOOT_A_LEFT -gt 0 ; then
> setexpr BOOT_A_LEFT $BOOT_A_LEFT - 1
> setenv found A
> setenv bootargs ${bootargs_A}
> setenv ubivol ${ubivol_A}
> # more setup based on A
> fi
> elif test "x$slot" = "xB" ; then
> if test $BOOT_B_LEFT -gt 0 ; then
> # the same ...
> fi
> fi
> done
>
> This is already bad enough, but extending that to A/B/C is tedious and
> prone to copy-pastos.
>
> So this is an attempt at allowing one to do "env set -E var value1 value2"
> with the effect that, of course, normal variable expansion happens on
> the command line, the valueX are joined with spaces as usual, and then
> one more pass is done over that string replacing occurrences of
> ${foo}.
>
> The above would become
>
> setenv found
> for slot in $BOOT_ORDER ; do
> if test "x$found" != "x" ; then
> # work around lack of break
> else
> env set -E boot_left "\${BOOT_${slot}_LEFT}"
> if test $boot_left -gt 0 ; then
> setexpr BOOT_${slot}_LEFT $boot_left - 1
> env set found $slot
> env set -E bootargs "\${bootargs_${slot}}"
> env set -E ubivol "\${ubivol_${slot}}"
> fi
> fi
> done
>
> I'm pleasantly surprised it was that easy to implement, but of course
> I'm cheating a bit (cli_simple_process_macros is only available if
> CONFIG_CMDLINE, though I think cli_simple.o could be unconditionally
> built and then link-time GC should get rid of the excess
> functions).
>
> This has been lightly tested in the sandbox. I'll add some proper unit
> tests, update the help texts and try to handle the Kconfig issue if
> this is something that might be accepted.
>
> Signed-off-by: Rasmus Villemoes
> ---
> cmd/nvedit.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
Seems OK to me. I suppose we don't want to implement bash's nested
expansion? ${var${suffix}}
Regards,
Simon
Re: [PATCH v2 2/2] pxe: Get default selection from board type if label matches
Hi Schrempf,
On Wed, 5 Feb 2020 at 08:12, Schrempf Frieder
wrote:
>
> From: Frieder Schrempf
>
> In order to auto-select an option from the pxe boot menu, that
> matches the detected board, we check the board model string in the
> devicetree and set the default menu selection, if it matches the
> label of the menu entry and there is no default selection already
> set.
>
> This is useful in combination with SPL that loads a FIT image with
> U-Boot and multiple DTBs. SPL can detect the board and choose the
> matching configuration in the FIT by using
> board_fit_config_name_match().
>
> Signed-off-by: Frieder Schrempf
> ---
> Changes in v2:
> * Don't use internal structs of menu, but instead call
> menu_set_default_by_item_data_match() that does the iteration work.
> ---
> cmd/pxe_utils.c | 47 +++
> 1 file changed, 47 insertions(+)
>
> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> index 53af04d7dc..62a1ee310d 100644
> --- a/cmd/pxe_utils.c
> +++ b/cmd/pxe_utils.c
> @@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
> unsigned long menucfg)
> return cfg;
> }
>
> +#ifdef CONFIG_OF_CONTROL
> +int pxe_match_menu_label_with_str(void *data, void *str)
> +{
> + struct pxe_label *label;
> +
> + if (!data || !str)
> + return 0;
> +
> + label = (struct pxe_label *)data;
> +
> + if (strcmp(label->name, str) == 0)
> + return 1;
> +
> + return 0;
> +}
> +
> +int pxe_runtime_select_menu_default(struct menu *m)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> + const char *model;
> + char *key;
> + int ret;
> +
> + model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
> +
> + if (!model)
> + return 0;
> +
> + ret = menu_set_default_by_item_data_match(m,
> + pxe_match_menu_label_with_str, (void *)model, );
> + if (ret)
> + return ret;
> +
> + printf("Menu entry %s fits detected board. " \
> + "Use as default selection...\n", key);
> +
> + return 0;
> +}
> +#endif
> +
> /*
> * Converts a pxe_menu struct into a menu struct for use with U-Boot's
> generic
> * menu code.
> @@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
> *cfg)
> /*
> * After we've created items for each label in the menu, set the
> * menu's default label if one was specified.
> +* If OF_CONTROL is enabled and we don't have a default specified,
> +* we try to use an entry that matches the board/model name as
> default.
> */
> if (default_num) {
> err = menu_default_set(m, default_num);
> @@ -1269,6 +1311,11 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
> *cfg)
>
> printf("Missing default: %s\n", cfg->default_label);
> }
> +#ifdef CONFIG_OF_CONTROL
> + } else if (pxe_runtime_select_menu_default(m)) {
can you do:
} else if (IS_ENABLED(CONFIG_OF_CONTROL) &&
pxe_runtime_select_menu_default...
?
Then you can drop your #ifdef above.
> + menu_destroy(m);
> + return NULL;
> +#endif
> }
>
> return m;
> --
> 2.17.1
Regards,
Simon
Re: [PATCH v3 2/2] gpio: search for gpio label if gpio is not found through bank name
On Tue, 4 Feb 2020 at 23:21, Heiko Schocher wrote: > > dm_gpio_lookup_name() searches for a gpio through > the bank name. But we have also gpio labels, and it > makes sense to search for a gpio also in the labels > we have defined, if no gpio is found through the > bank name definition. > > This is useful for example if you have a wp pin on > different gpios on different board versions. > > If dm_gpio_lookup_name() searches also for the gpio labels, > you can give the gpio an unique label name and search > for this label, and do not need to differ between > board revisions. > > Signed-off-by: Heiko Schocher > --- > > Example on the aristainetos board: > > => gpio clear wp_spi_nor.gpio-hog > gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0 > => > > before this patch, you need to know where your > pin is: > > => gpio clear GPIO2_15 > gpio: pin GPIO2_15 (gpio 47) value is 0 > => > > travis build: > > Changes in v3: > - add comment from Simon Glass > make this new function configurable through Kconfig > option DM_GPIO_LOOKUP_LABEL > > Changes in v2: > - add comment from Simon Glass > move code into seperate function dm_gpio_lookup_label() > add test if dm_gpio_lookup_label() works > > drivers/gpio/Kconfig | 22 ++ > drivers/gpio/gpio-uclass.c | 47 ++ > test/dm/gpio.c | 7 ++ > 3 files changed, 76 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v3 1/2] sandbox, test: add test for GPIO_HOG function
On Tue, 4 Feb 2020 at 23:20, Heiko Schocher wrote: > > currently gpio hog function is not tested with "ut dm gpio" > so add some basic tests for gpio hog functionality. > > For this enable GPIO_HOG in sandbox_defconfig, add > in DTS some gpio hog entries, and add testcase in > "ut dm gpio" command. > > Signed-off-by: Heiko Schocher > > --- > > Changes in v3: None > Changes in v2: > - add basic gpio hog test functions > > arch/sandbox/dts/test.dts | 24 > configs/sandbox64_defconfig| 1 + > configs/sandbox_defconfig | 1 + > configs/sandbox_flattree_defconfig | 1 + > configs/sandbox_spl_defconfig | 1 + > test/dm/gpio.c | 23 +++ > 6 files changed, 51 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 1/2] menu: Add a function to set the default by matching the item data
Hi Schrempf,
On Wed, 5 Feb 2020 at 08:12, Schrempf Frieder
wrote:
>
> From: Frieder Schrempf
>
> In order to make it possible to auto select a default entry by
> matching the data of the menu entries by an external matching
> function, we add some helpers and expose the
> menu_set_default_by_item_data_match() function.
>
> Signed-off-by: Frieder Schrempf
> ---
> Changes in v2:
> * Keep the menu structs private and instead only expose one additional
> function, that sets the default by calling an external matching
> function on each entry.
> * Change the title and commit message to reflect the changes.
> ---
> common/menu.c | 40
> include/menu.h | 3 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/common/menu.c b/common/menu.c
> index 7b66d199a9..3833b8a237 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -160,6 +160,46 @@ static inline struct menu_item *menu_item_by_key(struct
> menu *m,
> return menu_items_iter(m, menu_item_key_match, item_key);
> }
>
> +/*
> + * Find the first matching item, if any exists by calling a matching function
> + * on the items data field.
> + */
> +static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
> + int match(void *, void *), void * extra)
> +{
> + struct list_head *pos, *n;
> + struct menu_item *item;
> + int ret;
> +
> + list_for_each_safe(pos, n, >items) {
> + item = list_entry(pos, struct menu_item, list);
> + if (item->key) {
> + ret = match(item->data, extra);
> + if (ret == 1)
> + return item;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +/*
> + * Select the menus default entry based on matching the data field of the
> menu
> + * items by calling a matching function.
> + */
> +int menu_set_default_by_item_data_match(struct menu *m,
> + int match(void *, void *), void *extra, char **key)
> +{
> + struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
> +
> + if (!item)
> + return -ENOENT;
> +
> + *key = item->key;
> + m->default_item = item;
> + return 0;
> +}
> +
> /*
> * Set *choice to point to the default item's data, if any default item was
> * set, and returns 1. If no default item was set, returns -ENOENT.
> diff --git a/include/menu.h b/include/menu.h
> index 2d227c20bd..0a8b41a905 100644
> --- a/include/menu.h
> +++ b/include/menu.h
> @@ -18,6 +18,9 @@ int menu_item_add(struct menu *m, char *item_key, void
> *item_data);
> int menu_destroy(struct menu *m);
> void menu_display_statusline(struct menu *m);
> int menu_default_choice(struct menu *m, void **choice);
Please add a full function comment here, including the args/return for match.
> +int menu_set_default_by_item_data_match(struct menu *m,
> + int match(void *, void *), void
> *extra,
> + char **key);
>
> /**
> * menu_show() Show a boot menu
> --
> 2.17.1
Regards,
Simon
Re: [PATCH] image: fdt: check "status" of "/reserved-memory" subnodes
On Tue, 4 Feb 2020 at 17:16, Simon Glass wrote: > > ]Hi Thirupathaiah, > > On Tue, 4 Feb 2020 at 10:09, Thirupathaiah Annapureddy > wrote: > > > > Thank You Simon for the review. > > > > May I know what are the next steps in making forward progress on this? > > The patch is in my queue but I've had some test failures. Assuming it > is not the culprit I expect it will be applied by next week. Applied to u-boot-dm, thanks!
Re: dm, serial: problem with using ns16550 driver before relocation on mpc83xx
Hi Heiko,
On Wed, 5 Feb 2020 at 02:04, Heiko Schocher wrote:
>
> Hello Bin, Simon,
>
> I just porting the mpc83xx based kmcoge5ne board support DTS and got
> problems using the serial ns16550 driver.
>
> I need the serial driver before rolcation, so I enabled
> "u-boot,dm-pre-reloc;" as usual in the device tree, but board does not
> boot ...
>
> I found the commit:
>
> commit 4687919684e0e4390b9fc20d1809ecaa9dc3cb81
> Author: Bin Meng
> Date: Wed Oct 24 06:36:36 2018 -0700
>
> serial: Remove DM_FLAG_PRE_RELOC flag in various drivers
>
> which added to the ns16550 serial driver:
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 04b604fa2c..1e6fc6c668 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -487,7 +487,9 @@ U_BOOT_DRIVER(ns16550_serial) = {
> .priv_auto_alloc_size = sizeof(struct NS16550),
> .probe = ns16550_serial_probe,
> .ops= _serial_ops,
> +#if !CONFIG_IS_ENABLED(OF_CONTROL)
> .flags = DM_FLAG_PRE_RELOC,
> +#endif
> };
> #endif
> #endif /* SERIAL_PRESENT */
>
> So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
> not working anymore ...
>
> Adding this back:
>
> hs@xmglap:u-boot-secu [20200205-temp] $ git diff
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 9851663dc5..386ca9cffa 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -528,7 +528,7 @@ U_BOOT_DRIVER(ns16550_serial) = {
> .priv_auto_alloc_size = sizeof(struct NS16550),
> .probe = ns16550_serial_probe,
> .ops= _serial_ops,
> -#if !CONFIG_IS_ENABLED(OF_CONTROL)
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> .flags = DM_FLAG_PRE_RELOC,
> #endif
> };
>
> and board boots fine with the flag "u-boot,dm-pre-reloc" in DTS ...
>
> May I do something wrong here? I found in mainline for example
> the "arch/powerpc/dts/gdsys/gazerbeam-uboot.dtsi" board, which
> has the exactly same dts settings than I have now.
>
> @Dirk: Can you check, if this board boots with current mainline?
>
> Shouldn;t be the logic, that in case OF_CONTROL is enabled and if
> flag "u-boot,dm-pre-reloc" is set in DTS for the device, the device
> should be bound before relocation, and we do not need to check, if
> the driver sets DM_FLAG_PRE_RELOC ?
>
> But may I miss here something ...
>
> Any hints?
+Tom Rini
I found I needed this for rpi.
http://patchwork.ozlabs.org/patch/1202913/
But I still haven't gone back to figure out why Tom doesn't.
Regards,
Simon
[PATCH 1/1] pci: definition of pci_addr_t and pci_size_t
Currently the size of pci_addr_t and pci_size_t depends on
CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
to an error
pci_hose_phys_to_bus: invalid physical address
which is due to the truncation of the bus address in _dm_pci_phys_to_bus.
Defining CONFIG_SYS_PCI_64BIT is not a solution as this results in an error
PCI: Failed autoconfig bar 10
So let's use unsigned long for pci_addr_t and pci_size_t.
Signed-off-by: Heinrich Schuchardt
---
include/pci.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/include/pci.h b/include/pci.h
index 8c761d8da3..d8bce8ab80 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -484,13 +484,8 @@
#include
-#ifdef CONFIG_SYS_PCI_64BIT
-typedef u64 pci_addr_t;
-typedef u64 pci_size_t;
-#else
-typedef u32 pci_addr_t;
-typedef u32 pci_size_t;
-#endif
+typedef unsigned long pci_addr_t;
+typedef unsigned long pci_size_t;
struct pci_region {
pci_addr_t bus_start; /* Start on the bus */
--
2.24.1
Re: U-Boot Logo showing incorrect colors with eLCDIF
Hi Anatolij, On Wed, Feb 5, 2020 at 2:00 PM Anatolij Gustschin wrote: > I tried to extend the BMP code to fix this, but my testing with > sandbox SDL end of last week has shown incorrect colors in 24bpp > mode, and I didn't find the reason for it. I do not see what is > wrong in the code, maybe there is some issue with sandbox SDL. > So I've submitted some patches [1], [2], [3]. Could you please > test them on mx6ul-14x14-evk ? Thanks! Thanks for the patches. I can see the logo colors correctly now, but there is some breakage now. Please see the result at: https://ibb.co/0YKwTxJ Thanks!
Re: [PATCH 1/1] pci: definition of pci_addr_t and pci_size_t
On 2/5/20 9:05 PM, Simon Glass wrote: Hi Heinrich, On Wed, 5 Feb 2020 at 12:07, Heinrich Schuchardt wrote: Currently the size of pci_addr_t and pci_size_t depends on CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads to an error pci_hose_phys_to_bus: invalid physical address which is due to the truncation of the bus address in _dm_pci_phys_to_bus. Defining CONFIG_SYS_PCI_64BIT is not a solution as this results in an error PCI: Failed autoconfig bar 10 So let's use unsigned long for pci_addr_t and pci_size_t. But how will this work on x86 where we might have 32-bit U-Boot but need 64-bit PCI addresses? Regards, Simon So would you suggest to only change the code for CONFIG_SYS_PCI_64BIT=n? Best regards Heinrich
[PATCH v2 1/1] pci: definition of pci_addr_t and pci_size_t
Currently the size of pci_addr_t and pci_size_t depends on
CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
to an error
pci_hose_phys_to_bus: invalid physical address
which is due to the truncation of the bus address in _dm_pci_phys_to_bus.
Defining CONFIG_SYS_PCI_64BIT is not a solution as this results in an error
PCI: Failed autoconfig bar 10
So let's use unsigned long for pci_addr_t and pci_size_t if
CONFIG_SYS_PCI_64BIT is not defined.
Considering that 32bit U-Boot is used to launch some 64bit x86 systems we
cannot do without CONFIG_SYS_PCI_64BIT requiring u64 as type.
Signed-off-by: Heinrich Schuchardt
---
v2
Do not change CONFIG_SYS_PCI_64BIT=y case.
---
include/pci.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/pci.h b/include/pci.h
index 8c761d8da3..06a09f8987 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -488,8 +488,8 @@
typedef u64 pci_addr_t;
typedef u64 pci_size_t;
#else
-typedef u32 pci_addr_t;
-typedef u32 pci_size_t;
+typedef unsigned long pci_addr_t;
+typedef unsigned long pci_size_t;
#endif
struct pci_region {
--
2.24.1
Re: [PATCH 05/21] dm: core: Use const device for the dev_read_...() interface
These functions do not modify the device so should use a const pointer to it. Update the code accordingly. Signed-off-by: Simon Glass --- drivers/core/read.c | 97 +++-- include/dm/read.h | 205 +++- 2 files changed, 159 insertions(+), 143 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 04/21] dm: core: Use const device for the devfdt...() interface
These functions do not modify the device so should use a const pointer to it. Update the code accordingly. Signed-off-by: Simon Glass --- drivers/core/fdtaddr.c | 26 +- include/dm/fdtaddr.h | 26 +- 2 files changed, 26 insertions(+), 26 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 1/5] x86: fsp: Allow skipping init code when chain loading
Hi Bin,
On Mon, 3 Feb 2020 at 21:52, Bin Meng wrote:
>
> Hi Simon,
>
> On Tue, Feb 4, 2020 at 1:15 AM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > On Mon, 3 Feb 2020 at 10:10, Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Mon, 3 Feb 2020 at 04:05, Bin Meng wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass
> > > > > wrote:
> > > > > >
> > > > > > When U-Boot is no the first-stage bootloader much of this code is
> > > > > > not
> > > > > > needed and can break booting. Add checks for this to the FSP code.
> > > > > >
> > > > > > Rather than checking for the amount of available SDRAM, just use
> > > > > > 1GB in
> > > > > > this situation, which should be safe. Using 2GB may run into a
> > > > > > memory
> > > > > > hole on some SoCs.
> > > > > >
> > > > > > Signed-off-by: Simon Glass
> > > > > > ---
> > > > > >
> > > > > > arch/x86/lib/fsp/fsp_dram.c | 8
> > > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +++
> > > > > > arch/x86/lib/fsp2/fsp_dram.c| 10 ++
> > > > > > arch/x86/lib/fsp2/fsp_init.c| 2 +-
> > > > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c
> > > > > > b/arch/x86/lib/fsp/fsp_dram.c
> > > > > > index 9ce0ddf0d3..15e82de2fe 100644
> > > > > > --- a/arch/x86/lib/fsp/fsp_dram.c
> > > > > > +++ b/arch/x86/lib/fsp/fsp_dram.c
> > > > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> > > > > > phys_addr_t low_end;
> > > > > > uint bank;
> > > > > >
> > > > > > + if (!ll_boot_init()) {
> > > > > > + gd->bd->bi_dram[0].start = 0;
> > > > > > + gd->bd->bi_dram[0].size = gd->ram_size;
> > > > > > +
> > > > > > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> > > > > > + return 0;
> > > > > > + }
> > > > > > +
> > > > >
> > > > > I wonder why this change is needed. When booting from other
> > > > > bootloader, this dram_init_banksize() will not be called, no?
> > > >
> > > > How about this:
> > > >
> > > > It is useful to be able to boot the same x86 image on a device with or
> > > > without a first-stage bootloader. For example, with chromebook_coral, it
> > > > is helpful for testing to be able to boot the same U-Boot (complete with
> > > > FSP) on bare metal and from coreboot. It allows checking of things like
> > > > CPU speed, comparing registers, ACPI tables and the like.
> > > >
> > > > The idea is to change ll_boot_init() to false, and rebuild without
> > > > changing
> > > > anything else.
> > >
> > > This sounds like for a debugging purpose, instead of a supported
> > > configuration. So when we boot from previous bootloader, we really
> > > should use its configuration, for the coreboot case,
> > > coreboot-x86_defconfig should be used, and we can compare the
> > > registers, ACPI tables in that configuration, instead of "hacking"
> > > current U-Boot codes like in this series.
> >
> > Well the problem is then that we cannot boot the same image with or
> > without coreboot. Also there are various of device-tree things in
> > coral that we need for the laptop to work properly. My idea is to
> > detect coreboot and set ll_boot_init() dynamically if needed.
>
> If so, why should we keep coreboot_defconfig for U-Boot as a supported target?
>
> I am more interested in what you proposed here: "detect coreboot and
> set ll_boot_init() dynamically if needed." The name ll_boot_init()
> does not sound great. It's written like a function call but actually
> it is a macro for true/false. Can we do something in the gd->flags to
> indicate we are booting from previous stage bootloaders instead of
> relying on ll_boot_init()?
That sounds like a good idea, although at present it is statically
configured. But we don't really care about code size here I think.
Regards,
Simon
Re: [U-Boot] [PATCH v2 03/10] tiny-printf: Reorder code to support %p
Hi Vignesh, On Tue, 4 Feb 2020 at 00:58, Vignesh Raghavendra wrote: > > Faiz, > > On 31/01/20 11:44 pm, Simon Glass wrote: > > Hi Vignesh, > > > > On Thu, 30 Jan 2020 at 22:12, Vignesh Raghavendra wrote: > >> > >> Hi Simon, > >> > >> On 31/01/20 7:57 am, Simon Glass wrote: > >>> Hi Faiz, > >>> > >>> On Thu, 30 Jan 2020 at 08:22, Faiz Abbas wrote: > > Hi Simon, > > On 22/10/19 4:56 am, Simon Glass wrote: > > With a bit of code reordering we can support %p using the existing code > > for ulong. > > > > Move the %p code up and adjust the logic accordingly. > > > >> > >> [...] > > Retry time exceeded; starting again > Problem booting with BOOTP > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > Reverting this patch on the latest U-boot master fixes the issue for me. > > I'll look into this more deeply tomorrow. Let me know if you see > something obviously wrong with the patch. > >>> > >>> Well one thing is that eth_env_set_enetaddr() called from the board's > >>> board.c has this: > >>> > >>> sprintf(buf, "%pM", enetaddr); > >>> > >>> which is not supported with tiny-printf. > >> > >> That is not true. %pM is supported when SPL_NET_SUPPORT is enabled. See: > >> > >> https://gitlab.denx.de/u-boot/u-boot/blob/master/lib/tiny-printf.c#L183 > >> > >> I added this specifically to support Ethernet Boot usecases on TI platforms > >> > >> But above commit seems to move pointer() function that formats the > >> output under #ifdef DEBUG which definitely breaks %pM > > > > OK I see. I think it is too confusing to use #ifdef DEBUG in this code. > > > > One fix would be to change pointer() to return true if it actually > > does something. I'll take a look. > > > > This code needs tests also. Vignesh, do you feel like writing something? > > > > Is there a testcase for full printf()? I am not sure where to look for. > Is test/print_ut.c the right place to add new test? Yes. See also this commit in u-boot-dm/testing test: Add a way to check each line of console output Regards, Simon
Re: [PATCH v2] cmd: Add command to dump drivers and compatible strings
Hi Sean, On Mon, 3 Feb 2020 at 13:51, Sean Anderson wrote: > > This adds a subcommand to dm to dump out what drivers are installed, and their > compatible strings. I have found this useful in ensuring that I have the > correct > drivers compiled, and that I have put in the correct compatible strings. > > Signed-off-by: Sean Anderson > --- > Changes for v2: > - Check if entry->of_match is NULL before accessing it > > cmd/dm.c| 12 +++- > drivers/core/dump.c | 20 > include/dm/util.h | 3 +++ > 3 files changed, 34 insertions(+), 1 deletion(-) Looks good. Please can you add a test? If it helps u-boot-dm/.testing has 'test: Add a way to check each line of console output' so you can write it in C. Regards, Simon
Re: [GIT PULL] Raspberry Pi updates for v2020.04
On Wed, Feb 05, 2020 at 10:33:18AM +0100, Matthias Brugger wrote: > Hi Tom, > > Please take into account the following commits for RPi boards. > > It includes support for DFU on RPi4 as well as network support on that board. > > You can find the CI output here: > https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/2065 > and here > https://travis-ci.org/mbgg/u-boot/builds/645395557 > > Regarding the DFU series [0] I didn't took the first two patches as I > understand > that you wanted to see a test for the FAT bug fixed. > > Regards, > Matthias > > [0] https://patchwork.ozlabs.org/user/todo/uboot/?series=145985 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 04/17] tegra: i2c: Change driver to use helper function
On 2/4/20 7:03 PM, Simon Glass wrote: Now that we have uclass_first_device_drvdata(), use it from the I2C driver to reduce code duplication. Acked-by: Stephen Warren
Re: [PATCH v2 1/1] pci: definition of pci_addr_t and pci_size_t
On Wed, 5 Feb 2020 at 13:59, Heinrich Schuchardt wrote: > > Currently the size of pci_addr_t and pci_size_t depends on > CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads > to an error > > pci_hose_phys_to_bus: invalid physical address > > which is due to the truncation of the bus address in _dm_pci_phys_to_bus. > > Defining CONFIG_SYS_PCI_64BIT is not a solution as this results in an error > >PCI: Failed autoconfig bar 10 > > So let's use unsigned long for pci_addr_t and pci_size_t if > CONFIG_SYS_PCI_64BIT is not defined. > > Considering that 32bit U-Boot is used to launch some 64bit x86 systems we > cannot do without CONFIG_SYS_PCI_64BIT requiring u64 as type. > > Signed-off-by: Heinrich Schuchardt > --- > v2 > Do not change CONFIG_SYS_PCI_64BIT=y case. > --- > include/pci.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 3/3] imx: mx6ul_14x14_evk: configure for 24bpp display
Hi Anatolij,
On Wed, Feb 5, 2020 at 1:50 PM Anatolij Gustschin wrote:
>
> Before DM_VIDEO conversion this board used 24bpp
> display configuration, so use it again.
>
> Signed-off-by: Anatolij Gustschin
> ---
> arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
> b/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
> index e9efdb9831..d0cbf79e33 100644
> --- a/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
> @@ -31,7 +31,7 @@
> u-boot,dm-pre-reloc;
>
> display0: display@0 {
> - bits-per-pixel = <16>;
> + bits-per-pixel = <24>;
Yes, this fix is correct;
Reviewed-by: Fabio Estevam
RE: [U-Boot Patch v2 1/4] fu540: dtsi: spi: add num-cs info to device tree
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 1/4] fu540: dtsi: spi: add num-cs info to device
> tree
>
> Hi Sagar,
>
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
> wrote:
> >
> > Add the number of chip select information to spi nodes which can be
> > used by spi-uclass for error handling if invalid cs number passed from
> > command.
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > ---
> > arch/riscv/dts/fu540-c000.dtsi | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/riscv/dts/fu540-c000.dtsi
> > b/arch/riscv/dts/fu540-c000.dtsi index afa43c7..9c6ab21 100644
> > --- a/arch/riscv/dts/fu540-c000.dtsi
> > +++ b/arch/riscv/dts/fu540-c000.dtsi
> > @@ -191,6 +191,7 @@
> > clocks = < PRCI_CLK_TLCLK>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > + num-cs = <1>;
>
> Why is this necessary? I can't find the codes that handle the num-cs
> property.
The code handling num-cs is a part of patch 2. I intended to keep it separate
thinking better to isolate dt and c files patches. Please let me know if I need
to keep it together.
> In the SiFive SPI driver, num_cs is determined from register
> SIFIVE_SPI_REG_CSDEF.
>
The SiFive SPI driver does read the num_cs defined in the register you
mentioned.
but it's hard defined with cs_width, eg: QSPI0 = 1, QSPI1 = 4, QSPI2 = 1.
I have added the option after sifive_spi_init_hw to read from device tree as
well
so that if the user want's to change the chip select's (less than that defined
in
SIFIVE_SPI_REG_CSDEF) then it can be done in hifive-unleashed-a00.dtsi
Please let me know your thoughts over here.
BR,
Sagar
> > status = "disabled";
> > };
> > qspi1: spi@10041000 {
> > @@ -202,6 +203,7 @@
> > clocks = < PRCI_CLK_TLCLK>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > + num-cs = <1>;
> > status = "disabled";
> > };
> > qspi2: spi@1005 {
> > @@ -212,6 +214,7 @@
> > clocks = < PRCI_CLK_TLCLK>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > + num-cs = <1>;
> > status = "disabled";
> > };
> > eth0: ethernet@1009 {
> > --
>
> Regards,
> Bin
Re: [PATCH v2 1/4] clock_imx8mq: Delete not used init_usb_clk()
On Mon, Feb 3, 2020 at 5:48 AM Jon Nettleton wrote: > I have a working port of the Linux usb phy driver for the iMX8MQ > already. I think the only piece that is missing to use dwc3-generic > for iMX8MQ is the common clk driver. Has anyone started work on this? Not that I am aware of. Peng, do you know?
Re: [PATCH 19/21] console: Add a function to read a line of the output / eof
When recording the console output for testing it is useful to be able to read the output a line at a time to check that the output is correct. Also we need to check that we get to the end of the output. Add a console function to return the next line and another to see how must data is left. Signed-off-by: Simon Glass --- common/console.c | 11 +++ include/console.h | 19 +++ 2 files changed, 30 insertions(+) Applied to u-boot-dm, thanks!
Re: [PATCH 20/21] test: Enable console recording in tests
At present we reset the console buffer before each test but do not actually set the recording flag. Without this, the output is not recorded. Update the code to set the flag before the test and clear it afterwards. Signed-off-by: Simon Glass --- test/dm/test-main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH] doc: dm: debugging: Fix the steps for activating debug
On Wed, 29 Jan 2020 at 10:45, Fabio Estevam wrote: > > Following the recommendation of adding '#define DEBUG' at the top > of drivers/core/lists.c does not cause the debug messages to be > shown. Change it to '#define LOG_DEBUG' instead, which actually > makes it work as per doc/README.log. > > While at it, provide the full path to lists.c to in order to make > the instructions clearer. > > Signed-off-by: Fabio Estevam > --- > doc/driver-model/debugging.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH] dtc: add ability to make nodes conditional on them being referenced
On Tue, 28 Jan 2020 10:07:18 -0700 Simon Glass wrote: Hi Simon, > On Sat, 25 Jan 2020 at 16:18, André Przywara wrote: > > > > On 25/01/2020 16:20, Tom Rini wrote: > > > > Hi Tom, > > > > thanks for having a look! > > > > > > > On Tue, Jan 21, 2020 at 10:23:17AM +, Andre Przywara wrote: > > > > > >> From: Maxime Ripard > > >> > > >> This is needed when importing mainline DTs into U-Boot, as some started > > >> using this /omit-if-no-ref/ tag, so won't compile with U-Boot's current > > >> dtc copy. This is just a cherry-pick of the patch introducing this > > >> feature. > > >> Original commit message from Maxime: > > >> -- > > >> A number of platforms have a need to reduce the number of DT nodes, > > >> mostly because of two similar constraints: the size of the DT blob, and > > >> the time it takes to parse it. > > >> > > >> As the DT is used in more and more SoCs, and by more projects, some > > >> constraints start to appear in bootloaders running from SRAM with an > > >> order of magnitude of 10kB. A typical DT is in the same order of > > >> magnitude, so any effort to reduce the blob size is welcome in such an > > >> environment. > > >> > > >> Some platforms also want to reach very fast boot time, and the time it > > >> takes to parse a typical DT starts to be noticeable. > > >> > > >> Both of these issues can be mitigated by reducing the number of nodes in > > >> the DT. The biggest provider of nodes is usually the pin controller and > > >> its subnodes, usually one for each valid pin configuration in a given > > >> SoC. > > >> > > >> Obviously, a single, fixed, set of these nodes will be used by a given > > >> board, so we can introduce a node property that will tell the DT > > >> compiler to drop the nodes when they are not referenced in the tree, and > > >> as such wouldn't be useful in the targetted system. > > >> > > >> Signed-off-by: Maxime Ripard > > >> Reviewed-by: Rob Herring > > >> Signed-off-by: Andre Przywara > > >> --- > > >> scripts/dtc/checks.c | 13 + > > >> scripts/dtc/dtc-lexer.l | 7 +++ > > >> scripts/dtc/dtc-parser.y | 17 + > > >> scripts/dtc/dtc.h| 4 > > >> scripts/dtc/livetree.c | 14 ++ > > >> 5 files changed, 55 insertions(+) > > Reviewed-by: Simon Glass Thanks! > > Is this for SPL or U-Boot proper? I don't think either of those was the original target here, as this showed up in the Linux tree first. If you need an answer to your question: it would actually be U-Boot proper, as it originates from Maxime's work on some Allwinner A20 devices - and we don't use DT in the SPL on sunxi. > I assume the former since you talk about SRAM. I think the idea was to provide a generic solution for some specific problem. The observation was that the .dtb is growing with all those pinmux nodes, also reportedly boot time increased because of the parsing efforts. So short of hacking/trimming the DT manually, this tag was introduced, to address the issue in a generic way. > But changing dtc won't affect SPL at present, since the DT > is not separately compiled for SPL. Of course if nodes are not needed > for U-Boot proper, removing them is good and may have SPL too. But we > use dtoc to drop unwanted nodes (as you probably know), and U-Boot has > its own tags for indicating what nodes should be present (since > everything is omitted from SPL by default). Understood. As mentioned, sunxi doesn't even use the DT at all in the SPL. The reason I posted this patch is simply that some mainline Linux .dts files carry this tag now, and without U-Boot's dtc understanding it, those DTs fail to build. So for the sake of copying .dts files verbatim from the kernel tree, we need dtc support for this tag. Cheers, Andre. Applied to u-boot-dm, thanks!
Re: [PATCH] tpm2: ftpm: A driver for firmware TPM running inside TEE
Hi Thirupathaiah, On Tue, 4 Feb 2020 at 10:08, Thirupathaiah Annapureddy wrote: > > Hi All, > > May I know what are the next steps in making forward progress on this? Can you please add a test for this? We need a sandbox driver of some sort - see the existing sandbox TPM driver. Regards, Simon > > Best Regards, > Thiru > > On 1/12/2020 11:34 PM, Thirupathaiah Annapureddy wrote: > > Add a driver for a firmware TPM running inside TEE. > > > > Documentation of the firmware TPM: > > https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ > > > > Implementation of the firmware TPM: > > https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM > > > > Signed-off-by: Thirupathaiah Annapureddy > > --- > > drivers/tpm/Kconfig | 6 + > > drivers/tpm/Makefile| 1 + > > drivers/tpm/tpm2_ftpm_tee.c | 250 > > drivers/tpm/tpm2_ftpm_tee.h | 35 + > > 4 files changed, 292 insertions(+) > > create mode 100644 drivers/tpm/tpm2_ftpm_tee.c > > create mode 100644 drivers/tpm/tpm2_ftpm_tee.h Applied to u-boot-dm, thanks!
Re: [PATCH] buildman: Enable buildman on aarch64 hosts
On Fri, 17 Jan 2020 at 02:53, wrote: > > From: Matthias Brugger > > At kernel.org aarch64 toolchains are published in folder > arm64. Fix the URL for that case, so that we can fetch > toolchains on aarch64 machines. > > Signed-off-by: Matthias Brugger > > --- > > tools/buildman/toolchain.py | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH 03/21] dm: pci: Update a few more interfaces for const udevice *
Tidy up a few places where const * should be used. Signed-off-by: Simon Glass --- drivers/pci/pci-uclass.c | 18 +- include/fdtdec.h | 2 +- include/pci.h| 16 lib/fdtdec.c | 2 +- 4 files changed, 19 insertions(+), 19 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 01/21] dm: core: Use const where possible in device.h
Update this header file to use const devices where possible, to permit callers to also use const. Signed-off-by: Simon Glass --- drivers/core/device.c | 27 ++- include/dm/device.h | 30 -- include/dm/read.h | 4 ++-- 3 files changed, 32 insertions(+), 29 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 1/1] pci: definition of pci_addr_t and pci_size_t
Hi Heinrich, On Wed, 5 Feb 2020 at 12:07, Heinrich Schuchardt wrote: > > Currently the size of pci_addr_t and pci_size_t depends on > CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads > to an error > > pci_hose_phys_to_bus: invalid physical address > > which is due to the truncation of the bus address in _dm_pci_phys_to_bus. > > Defining CONFIG_SYS_PCI_64BIT is not a solution as this results in an error > >PCI: Failed autoconfig bar 10 > > So let's use unsigned long for pci_addr_t and pci_size_t. But how will this work on x86 where we might have 32-bit U-Boot but need 64-bit PCI addresses? Regards, Simon
Re: [PATCH v3] dm: uclass: don't assign aliased seq numbers
On Mon, 3 Feb 2020 at 10:12, Michael Walle wrote: > > If there are aliases for an uclass, set the base for the "dynamically" > allocated numbers next to the highest alias. > > Please note, that this might lead to holes in the sequences, depending > on the device tree. For example if there is only an alias "ethernet1", > the next device seq number would be 2. > > In particular this fixes a problem with boards which are using ethernet > aliases but also might have network add-in cards like the E1000. If the > board is started with the add-in card and depending on the order of the > drivers, the E1000 might occupy the first ethernet device and mess up > all the hardware addresses, because the devices are now shifted by one. > > Also adapt the test cases to the new handling and add test cases > checking the holes in the seq numbers. > > Signed-off-by: Michael Walle > Reviewed-by: Alex Marginean > Tested-by: Alex Marginean > Acked-by: Vladimir Oltean > --- Reviewed-by: Simon Glass (added Joe for review fo network parts)
Re: [PATCH 1/1] pci: definition of pci_addr_t and pci_size_t
Hi Heinrich, On Wed, 5 Feb 2020 at 13:18, Heinrich Schuchardt wrote: > > > > On 2/5/20 9:05 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 5 Feb 2020 at 12:07, Heinrich Schuchardt wrote: > >> > >> Currently the size of pci_addr_t and pci_size_t depends on > >> CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads > >> to an error > >> > >> pci_hose_phys_to_bus: invalid physical address > >> > >> which is due to the truncation of the bus address in _dm_pci_phys_to_bus. > >> > >> Defining CONFIG_SYS_PCI_64BIT is not a solution as this results in an error > >> > >> PCI: Failed autoconfig bar 10 > >> > >> So let's use unsigned long for pci_addr_t and pci_size_t. > > > > But how will this work on x86 where we might have 32-bit U-Boot but > > need 64-bit PCI addresses? > > > > Regards, > > Simon > > > > So would you suggest to only change the code for CONFIG_SYS_PCI_64BIT=n? I think that is safe, since nothing has a ulong less than 32 bits. Regards, Simon
Re: [PATCH v2] cli: Make the sandbox board_run_command the default
On Sat, Jan 11, 2020 at 1:32 AM Sean Anderson wrote: > > If CONFIG_CMDLINE=n, common/cli.c calls board_run_command. This fails to > link on most architectures. However, the sandbox architecture has an > implementation which we can use. > > Signed-off-by: Sean Anderson > --- > Changes for v2: > - Sent without any word wrap afaik > - Rebased onto v2020.01 > > arch/sandbox/cpu/start.c | 7 --- > common/cli.c | 7 +++ > 2 files changed, 7 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng Applied to u-boot-dm, thanks!
Re: [U-Boot] [PATCH] board: ax25-ae350: Print board information.
Hi Bin
> Hi Rick,
>
> When going through all patches in the RISC-V queue, I found this old
> patch was not applied. Is it still needed?
It is unnecessary now.
>
> Anyway, see my review comments below.
Thanks for your review!
Thanks
Rick
>
> On Mon, Oct 8, 2018 at 1:43 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > Add to print board and bit information message.
>
> nits: please remove the ending period in the commit title
>
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > board/AndesTech/ax25-ae350/ax25-ae350.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > index 5f4ca0f..61ca10b 100644
> > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > @@ -20,6 +20,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> > int board_init(void)
> > {
> > + printf("Board: %s (%d)\n" , CONFIG_SYS_BOARD, __riscv_xlen);
>
> nits: remove the space after \n", and one space before CONFIG_SYS_BOARD.
>
> > gd->bd->bi_boot_params = PHYS_SDRAM_0 + 0x400;
> >
> > return 0;
> > --
>
> Regards,
> Bin
Re: [PATCH v2 25/32] gitlab: Disable SDL when building sandbox
I am not sure how to add libsdl2-dev to the gitlab image, so disable building sandbox with SDL for now. Signed-off-by: Simon Glass --- Changes in v2: None .gitlab-ci.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
RE: [PATCH v2 1/4] clock_imx8mq: Delete not used init_usb_clk()
> Subject: Re: [PATCH v2 1/4] clock_imx8mq: Delete not used init_usb_clk() > > On Mon, Feb 3, 2020 at 5:48 AM Jon Nettleton wrote: > > > I have a working port of the Linux usb phy driver for the iMX8MQ > > already. I think the only piece that is missing to use dwc3-generic > > for iMX8MQ is the common clk driver. Has anyone started work on this? > > Not that I am aware of. > > Peng, do you know? I have not start to do that. Jon, great to know that you did that. Look forward your patches in community. Thanks, Peng.
Re: [PATCH 1/9] dma-mapping: fix the prototype of dma_map_single()
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, February 04, 2020 7:09 PM
> To: u-boot@lists.denx.de
> Cc: Masahiro Yamada; Bin Meng; Rick Jian-Zhi Chen(陳建志); Simon Glass
> Subject: [PATCH 1/9] dma-mapping: fix the prototype of dma_map_single()
>
> Make dma_map_single() return the dma address, and remove the pointless
> volatile.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Rick Chen
> ---
>
> arch/arm/include/asm/dma-mapping.h | 5 +++--
> arch/nds32/include/asm/dma-mapping.h | 5 +++--
> arch/riscv/include/asm/dma-mapping.h | 5 +++--
> arch/x86/include/asm/dma-mapping.h | 5 +++--
> 4 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index d20703739fad..d0895a209666 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #definedma_mapping_error(x, y) 0
> @@ -26,8 +27,8 @@ static inline void dma_free_coherent(void *addr)
> free(addr);
> }
>
> -static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
> - enum dma_data_direction dir)
> +static inline dma_addr_t dma_map_single(void *vaddr, size_t len,
> + enum dma_data_direction dir)
> {
> unsigned long addr = (unsigned long)vaddr;
>
> diff --git a/arch/nds32/include/asm/dma-mapping.h
> b/arch/nds32/include/asm/dma-mapping.h
> index c8876ceadda6..9387dec34768 100644
> --- a/arch/nds32/include/asm/dma-mapping.h
> +++ b/arch/nds32/include/asm/dma-mapping.h
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> static void *dma_alloc_coherent(size_t len, unsigned long *handle) @@ -18,8
> +19,8 @@ static void *dma_alloc_coherent(size_t len, unsigned long *handle)
> return (void *)*handle;
> }
>
> -static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
> - enum dma_data_direction dir)
> +static inline dma_addr_t dma_map_single(void *vaddr, size_t len,
> + enum dma_data_direction dir)
> {
> unsigned long addr = (unsigned long)vaddr;
>
> diff --git a/arch/riscv/include/asm/dma-mapping.h
> b/arch/riscv/include/asm/dma-mapping.h
> index 6cc39469590a..eac56f8fbdfa 100644
> --- a/arch/riscv/include/asm/dma-mapping.h
> +++ b/arch/riscv/include/asm/dma-mapping.h
> @@ -10,6 +10,7 @@
> #define __ASM_RISCV_DMA_MAPPING_H
>
> #include
> +#include
> #include
> #include
> #include
> @@ -28,8 +29,8 @@ static inline void dma_free_coherent(void *addr)
> free(addr);
> }
>
> -static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
> - enum dma_data_direction dir)
> +static inline dma_addr_t dma_map_single(void *vaddr, size_t len,
> + enum dma_data_direction dir)
> {
> unsigned long addr = (unsigned long)vaddr;
>
> diff --git a/arch/x86/include/asm/dma-mapping.h
> b/arch/x86/include/asm/dma-mapping.h
> index 900b99b8a69a..7e205e3313ac 100644
> --- a/arch/x86/include/asm/dma-mapping.h
> +++ b/arch/x86/include/asm/dma-mapping.h
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #definedma_mapping_error(x, y) 0
> @@ -26,8 +27,8 @@ static inline void dma_free_coherent(void *addr)
> free(addr);
> }
>
> -static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
> - enum dma_data_direction dir)
> +static inline dma_addr_t dma_map_single(void *vaddr, size_t len,
> + enum dma_data_direction dir)
> {
> unsigned long addr = (unsigned long)vaddr;
>
> --
> 2.17.1
>
Re: [PATCH 2/9] dma-mapping: fix the prototype of dma_unmap_single()
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, February 04, 2020 7:09 PM
> To: u-boot@lists.denx.de
> Cc: Masahiro Yamada; Bin Meng; Joe Hershberger; Lukasz Majewski; Marek Vasut;
> Peng Fan; Rick Jian-Zhi Chen(陳建志); Simon Glass
> Subject: [PATCH 2/9] dma-mapping: fix the prototype of dma_unmap_single()
>
> dma_unmap_single() takes the dma address, not virtual address.
>
> Signed-off-by: Masahiro Yamada
Acked-by: Rick Chen
> ---
>
> arch/arm/include/asm/dma-mapping.h | 4 +---
> arch/nds32/include/asm/dma-mapping.h | 4 +---
> arch/riscv/include/asm/dma-mapping.h | 4 +---
> arch/x86/include/asm/dma-mapping.h | 4 +---
> drivers/mmc/tmio-common.c| 2 +-
> drivers/mtd/nand/raw/denali.c| 2 +-
> drivers/net/macb.c | 2 +-
> drivers/usb/dwc3/core.c | 6 +++---
> drivers/usb/gadget/udc/udc-core.c| 2 +-
> 9 files changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index d0895a209666..efdbed7280dd 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -42,11 +42,9 @@ static inline dma_addr_t dma_map_single(void *vaddr,
> size_t len,
> return addr;
> }
>
> -static inline void dma_unmap_single(volatile void *vaddr, size_t len,
> +static inline void dma_unmap_single(dma_addr_t addr, size_t len,
> enum dma_data_direction dir)
> {
> - unsigned long addr = (unsigned long)vaddr;
> -
> len = ALIGN(len, ARCH_DMA_MINALIGN);
>
> if (dir != DMA_TO_DEVICE)
> diff --git a/arch/nds32/include/asm/dma-mapping.h
> b/arch/nds32/include/asm/dma-mapping.h
> index 9387dec34768..784f489db54e 100644
> --- a/arch/nds32/include/asm/dma-mapping.h
> +++ b/arch/nds32/include/asm/dma-mapping.h
> @@ -34,11 +34,9 @@ static inline dma_addr_t dma_map_single(void *vaddr,
> size_t len,
> return addr;
> }
>
> -static inline void dma_unmap_single(volatile void *vaddr, size_t len,
> +static inline void dma_unmap_single(dma_addr_t addr, size_t len,
> enum dma_data_direction dir)
> {
> - unsigned long addr = (unsigned long)vaddr;
> -
> len = ALIGN(len, ARCH_DMA_MINALIGN);
>
> if (dir != DMA_TO_DEVICE)
> diff --git a/arch/riscv/include/asm/dma-mapping.h
> b/arch/riscv/include/asm/dma-mapping.h
> index eac56f8fbdfa..1ac4a4fed58d 100644
> --- a/arch/riscv/include/asm/dma-mapping.h
> +++ b/arch/riscv/include/asm/dma-mapping.h
> @@ -44,11 +44,9 @@ static inline dma_addr_t dma_map_single(void *vaddr,
> size_t len,
> return addr;
> }
>
> -static inline void dma_unmap_single(volatile void *vaddr, size_t len,
> +static inline void dma_unmap_single(dma_addr_t addr, size_t len,
> enum dma_data_direction dir)
> {
> - unsigned long addr = (unsigned long)vaddr;
> -
> len = ALIGN(len, ARCH_DMA_MINALIGN);
>
> if (dir != DMA_TO_DEVICE)
> diff --git a/arch/x86/include/asm/dma-mapping.h
> b/arch/x86/include/asm/dma-mapping.h
> index 7e205e3313ac..37704da5dd4f 100644
> --- a/arch/x86/include/asm/dma-mapping.h
> +++ b/arch/x86/include/asm/dma-mapping.h
> @@ -42,11 +42,9 @@ static inline dma_addr_t dma_map_single(void *vaddr,
> size_t len,
> return addr;
> }
>
> -static inline void dma_unmap_single(volatile void *vaddr, size_t len,
> +static inline void dma_unmap_single(dma_addr_t addr, size_t len,
> enum dma_data_direction dir)
> {
> - unsigned long addr = (unsigned long)vaddr;
> -
> len = ALIGN(len, ARCH_DMA_MINALIGN);
>
> if (dir != DMA_TO_DEVICE)
> diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c index
> 5a8506dcb6bd..e5d9d64b9684 100644
> --- a/drivers/mmc/tmio-common.c
> +++ b/drivers/mmc/tmio-common.c
> @@ -352,7 +352,7 @@ static int tmio_sd_dma_xfer(struct udevice *dev, struct
> mmc_data *data)
> if (poll_flag == TMIO_SD_DMA_INFO1_END_RD)
> udelay(1);
>
> - dma_unmap_single(buf, len, dir);
> + dma_unmap_single(dma_addr, len, dir);
>
> return ret;
> }
> diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
> index 8537c609fb62..8dfffad63b60 100644
> --- a/drivers/mtd/nand/raw/denali.c
> +++ b/drivers/mtd/nand/raw/denali.c
> @@ -577,7 +577,7 @@ static int denali_dma_xfer(struct denali_nand_info
> *denali, void *buf,
>
> iowrite32(0, denali->reg + DMA_ENABLE);
>
> - dma_unmap_single(buf, size, dir);
> + dma_unmap_single(dma_addr, size, dir);
>
> if (irq_status & INTR__ERASED_PAGE)
> memset(buf, 0xff, size);
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c index
> 0d4929bec131..7a2b1abeeb03 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -342,7 +342,7 @@ static int _macb_send(struct macb_device *macb, const
> char
Pull request for UEFI sub-system for efi-2020-04-rc2
The following changes since commit d4827fcd4c1b04c338e4019e412f495aa4231d24: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2020-02-04 11:36:49 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2020-04-rc2 for you to fetch changes up to 491e87a79742711a5f747068f76fbbc17d0bc2a0: test: efi_selftest: fix pylint warnings (2020-02-05 06:58:03 +0100) Pull request for UEFI sub-system for efi-2020-04-rc2 Fix pylint issues in Python based tests. Heinrich Schuchardt (2): test: test_efi_fit: fix pylint warnings test: efi_selftest: fix pylint warnings test/py/tests/test_efi_fit.py | 77 test/py/tests/test_efi_selftest.py | 361 +++-- 2 files changed, 226 insertions(+), 212 deletions(-)
RE: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on mpc830x
> -Original Message-
> From: Peng Fan
> Sent: Wednesday, February 5, 2020 3:08 PM
> To: Rasmus Villemoes ; u-boot@lists.denx.de;
> Y.b. Lu
> Cc: Mario Six
> Subject: RE: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on
> mpc830x
>
> > Subject: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on
> mpc830x
>
> + Y.b
>
> Are you ok with this patch?
The mpc830x is old Freescale PowerPC platforms I don't have.
But I agree the fix-up.
Reviewed-by: Yangbo Lu
>
> Thanks,
> Peng.
>
> >
> > The reference manuals for MPC8308 and MPC8309 both say that the
> esdhcctl
> > aka DMA Control Register "is implemented as SDHCCR" in the System
> > configuration registers. Unfortunately, that doesn't mean that the registers
> are
> > just mirrors of each other - any write to esdhcctl is simply ignored. So to
> > actually enable cache snooping, we unfortunately have to add a little
> > ifdeffery.
> >
> > There is, naturally, no description of the bit fields of esdhcctl in the
> > MPC8309
> > manual, but comparing the description of esdhcctl from the LS1021A
> > reference manual to the description of the sdhccr in MPC8309, one also finds
> > that the fields are bit-reversed, so the bit to set is
> > 0x0200 rather than 0x0040 - this is also what board_mmc_init()
> > uses in the two gdsys/mpc8308/ boards.
> >
> > Signed-off-by: Rasmus Villemoes
> > ---
> > drivers/mmc/fsl_esdhc.c | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> > 1e7d606cd8..34e5bd270f 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -577,6 +577,18 @@ static int esdhc_set_ios_common(struct
> > fsl_esdhc_priv *priv, struct mmc *mmc)
> > return 0;
> > }
> >
> > +static void esdhc_enable_cache_snooping(struct fsl_esdhc *regs) {
> > +#ifdef CONFIG_ARCH_MPC830X
> > + immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
> > + sysconf83xx_t *sysconf = >sysconf;
> > +
> > + setbits_be32(>sdhccr, 0x0200); #else
> > + esdhc_write32(>esdhcctl, 0x0040); #endif }
> > +
> > static int esdhc_init_common(struct fsl_esdhc_priv *priv, struct mmc
> *mmc)
> > {
> > struct fsl_esdhc *regs = priv->esdhc_regs; @@ -592,8 +604,7 @@ static
> > int esdhc_init_common(struct fsl_esdhc_priv *priv, struct mmc *mmc)
> > return -ETIMEDOUT;
> > }
> >
> > - /* Enable cache snooping */
> > - esdhc_write32(>esdhcctl, 0x0040);
> > + esdhc_enable_cache_snooping(regs);
> >
> > esdhc_setbits32(>sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN);
> >
> > --
> > 2.23.0
Re: dm, serial: problem with using ns16550 driver before relocation on mpc83xx
Hello Simon,
Am 05.02.2020 um 18:59 schrieb Simon Glass:
Hi Heiko,
On Wed, 5 Feb 2020 at 02:04, Heiko Schocher wrote:
Hello Bin, Simon,
I just porting the mpc83xx based kmcoge5ne board support DTS and got
problems using the serial ns16550 driver.
I need the serial driver before rolcation, so I enabled
"u-boot,dm-pre-reloc;" as usual in the device tree, but board does not
boot ...
I found the commit:
commit 4687919684e0e4390b9fc20d1809ecaa9dc3cb81
Author: Bin Meng
Date: Wed Oct 24 06:36:36 2018 -0700
serial: Remove DM_FLAG_PRE_RELOC flag in various drivers
which added to the ns16550 serial driver:
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 04b604fa2c..1e6fc6c668 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -487,7 +487,9 @@ U_BOOT_DRIVER(ns16550_serial) = {
.priv_auto_alloc_size = sizeof(struct NS16550),
.probe = ns16550_serial_probe,
.ops= _serial_ops,
+#if !CONFIG_IS_ENABLED(OF_CONTROL)
.flags = DM_FLAG_PRE_RELOC,
+#endif
};
#endif
#endif /* SERIAL_PRESENT */
So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
not working anymore ...
Adding this back:
hs@xmglap:u-boot-secu [20200205-temp] $ git diff
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 9851663dc5..386ca9cffa 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -528,7 +528,7 @@ U_BOOT_DRIVER(ns16550_serial) = {
.priv_auto_alloc_size = sizeof(struct NS16550),
.probe = ns16550_serial_probe,
.ops= _serial_ops,
-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.flags = DM_FLAG_PRE_RELOC,
#endif
};
and board boots fine with the flag "u-boot,dm-pre-reloc" in DTS ...
May I do something wrong here? I found in mainline for example
the "arch/powerpc/dts/gdsys/gazerbeam-uboot.dtsi" board, which
has the exactly same dts settings than I have now.
@Dirk: Can you check, if this board boots with current mainline?
Shouldn;t be the logic, that in case OF_CONTROL is enabled and if
flag "u-boot,dm-pre-reloc" is set in DTS for the device, the device
should be bound before relocation, and we do not need to check, if
the driver sets DM_FLAG_PRE_RELOC ?
But may I miss here something ...
Any hints?
+Tom Rini
I found I needed this for rpi.
http://patchwork.ozlabs.org/patch/1202913/
But I still haven't gone back to figure out why Tom doesn't.
Hmm... I have added the "u-boot,dm-pre-reloc;" to the uart node.
Like it is for the gazerbeam board, see [1]
It works if "DM_FLAG_PRE_RELOC" is set the driver in flags... no
need for a gpio node before relocation like it is inabove patch.
I wonder if we need DM_FLAG_PRE_RELOC at all in a driver and
OF_CONTROL case. Shouldn't it be enough if the DTB node for the
driver contains the "u-boot,dm-pre-reloc;" property?
bye,
Heiko
[1]
https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/powerpc/dts/gdsys/gazerbeam-uboot.dtsi#L238
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v3 16/17] tpm: Add a driver for H1/Cr50
On Wed, Feb 5, 2020 at 10:04 AM Simon Glass wrote: > > H1 is a Google security chip present in recent Chromebooks, Pixel phones > and other devices. Cr50 is the name of the software that runs on H1 in > Chromebooks. > > This chip is used to handle TPM-like functionality and also has quite a > few additional features. > > Add a driver for this. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Fix 'devuce' typo > - s/@tpm/@dev/ in function comments > - Use log_debug() instead of debug() > - Fix 'consceivably' typo > - Rewrite comment for claim_locality() > - Shorten comment in cr50_i2c_wait_tpm_ready() to fit on one line > > Changes in v2: > - Significant rewrite of cr50 init procedure > - Support use of interrupts > > drivers/tpm/Kconfig| 10 + > drivers/tpm/Makefile | 1 + > drivers/tpm/cr50_i2c.c | 659 + > 3 files changed, 670 insertions(+) > create mode 100644 drivers/tpm/cr50_i2c.c > Reviewed-by: Bin Meng
Re: [PATCH] x86: Move P2SB from Apollo Lake to a more generic location
On Tue, Feb 4, 2020 at 4:21 PM Bin Meng wrote:
>
> On Tue, Feb 4, 2020 at 4:04 PM Wolfgang Wallner
> wrote:
> >
> > The Primary to Sideband Bridge (P2SB) is not specific to Apollo Lake, so
> > move its driver to a common location within arch/x86.
> >
> > Signed-off-by: Wolfgang Wallner
> >
> > ---
> > This commit follows a similar rational as the recent moving of the ITSS
> > driver from Apollo Lake to the intel_common directory, and it also depends
> > on those patches (which are currently in u-boot-x86).
> >
> > arch/x86/Kconfig | 7 +++
> > arch/x86/cpu/apollolake/Kconfig | 1 +
> > arch/x86/cpu/apollolake/Makefile | 1 -
> > arch/x86/cpu/intel_common/Makefile | 1 +
> > arch/x86/cpu/{apollolake => intel_common}/p2sb.c | 0
> > 5 files changed, 9 insertions(+), 1 deletion(-)
> > rename arch/x86/cpu/{apollolake => intel_common}/p2sb.c (100%)
> >
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
Re: [U-Boot] Sharing a hardware lab
Hi Stephen, On Wed, 5 Feb 2020 at 11:21, Stephen Warren wrote: > > On 2/5/20 7:10 AM, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 4 Dec 2019 at 15:30, Tom Rini wrote: > >> > >> On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote: > >> > >>> Hi Tom, > >>> > >>> I have been meaning to have a crack at setting up a little hardware > >>> lab for a while. > >>> > >>> I made some progress recently and hooked up a rpi_3 with sdwire for > >>> USB/SD, ykush for power and a little computer to control it. It builds > >>> U-Boot, sticks it on the SD card and runs pytest. > >>> > >>> I pushed a tree here and hopefully you can see the 'hwlab' thing at the > >>> end: > >>> > >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/148 > >>> > >>> So far it is just running the 'help' test. It seems to hang with > >>> serial console problems if I try to do more. It is not 100% reliable > >>> yet. I based it on Stephen's test hooks: > >>> > >>> https://github.com/sglass68/uboot-test-hooks > >>> > >>> Is it possible to share this so that others can use the lab when they > >>> push trees? Is it as simple as adding to the .gitlab-ci.yml file as I > >>> have done here? > >>> > >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/gitlab-working/.gitlab-ci.yml > >>> > >>> I also got tbot going in a similar way, to test booting into Linux. > >>> Should we look at integrating that at the same time? It should be > >>> fairly easy to do. > >>> > >>> I have quite a lot of random boards and in principle it should not be > >>> too hard to hook up some more of them, with sufficient SDwires, hubs > >>> and patience. > > > > Bumping this thread as I have now hooked up about about 8 mostly ARM > > and x86 boards and have tbot and pytest automation mostly working for > > them. > > > >> > >> There's two parts of this. The first part I think is that we need some > >> good examples of how to have one private CI job poll / monitor other > >> public jobs and run. I believe some labs do this today. This would be > >> helpful as at least personally I'm kicking my hardware tests manually. > >> This is because as best I can tell there isn't a way to include an > >> optional stage/portion of a CI job. > > > > So the model here is that people with a lab 'watch' various repos? I > > think that would be useful. Stephen Warren does this I think, but I'm > > not sure how the builds are kicked off. > > Yes, my Jenkins instance directly polls the relevant git repos/branches > for changes, then do a full build and test cycle, so is independent of > anything else. > > Well actually, I mirror the git repos locally and Jenkins polls the > mirrors, so that when I run n builds, the upstream git serves only get > hit once for the mirroring operation, and not once per build, but that's > an implementation detail. OK thanks, that explains it. Tom, I added a kea-sandbox runner - is it possible to try that as a public group runner? Regards, Simon
Re: [PATCH v3 00/17] x86: coral: Add support for Cr50
Hi Simon, On Wed, Feb 5, 2020 at 10:03 AM Simon Glass wrote: > > This series adds a driver for the Cr50 security chip and enables it on > coral. This supports the 'tpm' command. > > In order to make this work a few other changes are included: > - Additional UCLASS_IRQ operations to support requesting and reading > interrupts, using the device tree > - A driver for ACPI general-purpose events > > There are also a few small clean-ups to the recently landed Apollo Lake > support. > > This series relies on this patch: > >http://patchwork.ozlabs.org/patch/1214541/ > This series does not apply on top of u-boot-x86/master: Applying: x86: apl: Use the clock driver error: patch failed: arch/x86/cpu/apollolake/Kconfig:40 error: arch/x86/cpu/apollolake/Kconfig: patch does not apply Patch failed at 0006 x86: apl: Use the clock driver I tried to apply it on top of an old commit and got no luck. Would you please rebase this series against u-boot-x86/master and resend? Regards, Bin
Re: [U-Boot] [PATCH] board: ax25-ae350: Print board information.
Hi Rick, On Thu, Feb 6, 2020 at 9:41 AM Rick Chen wrote: > > Hi Bin > > > Hi Rick, > > > > When going through all patches in the RISC-V queue, I found this old > > patch was not applied. Is it still needed? > > It is unnecessary now. Thanks. I updated the patch status on patchwork. > > > > > Anyway, see my review comments below. > > Thanks for your review! > Regards, Bin
Re: U-Boot Logo showing incorrect colors with eLCDIF
Hi Fabio, On Mon, 3 Feb 2020 12:15:09 -0300 Fabio Estevam feste...@gmail.com wrote: > Hi Anatolij, > > On Sat, Jan 25, 2020 at 3:36 PM Anatolij Gustschin wrote: > > > Before DM_VIDEO conversion cfb_console driver was used and > > it supports such rendering. I'm working on a fix for this. > > Thanks for testing! > > Have you been able to fix this? I tried to extend the BMP code to fix this, but my testing with sandbox SDL end of last week has shown incorrect colors in 24bpp mode, and I didn't find the reason for it. I do not see what is wrong in the code, maybe there is some issue with sandbox SDL. So I've submitted some patches [1], [2], [3]. Could you please test them on mx6ul-14x14-evk ? Thanks! [1] http://patchwork.ozlabs.org/patch/1233910 [2] http://patchwork.ozlabs.org/patch/1233911 [3] http://patchwork.ozlabs.org/patch/1233912 -- Anatolij
dm, serial: problem with using ns16550 driver before relocation on mpc83xx
Hello Bin, Simon,
I just porting the mpc83xx based kmcoge5ne board support DTS and got
problems using the serial ns16550 driver.
I need the serial driver before rolcation, so I enabled
"u-boot,dm-pre-reloc;" as usual in the device tree, but board does not
boot ...
I found the commit:
commit 4687919684e0e4390b9fc20d1809ecaa9dc3cb81
Author: Bin Meng
Date: Wed Oct 24 06:36:36 2018 -0700
serial: Remove DM_FLAG_PRE_RELOC flag in various drivers
which added to the ns16550 serial driver:
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 04b604fa2c..1e6fc6c668 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -487,7 +487,9 @@ U_BOOT_DRIVER(ns16550_serial) = {
.priv_auto_alloc_size = sizeof(struct NS16550),
.probe = ns16550_serial_probe,
.ops= _serial_ops,
+#if !CONFIG_IS_ENABLED(OF_CONTROL)
.flags = DM_FLAG_PRE_RELOC,
+#endif
};
#endif
#endif /* SERIAL_PRESENT */
So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
not working anymore ...
Adding this back:
hs@xmglap:u-boot-secu [20200205-temp] $ git diff
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 9851663dc5..386ca9cffa 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -528,7 +528,7 @@ U_BOOT_DRIVER(ns16550_serial) = {
.priv_auto_alloc_size = sizeof(struct NS16550),
.probe = ns16550_serial_probe,
.ops= _serial_ops,
-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
.flags = DM_FLAG_PRE_RELOC,
#endif
};
and board boots fine with the flag "u-boot,dm-pre-reloc" in DTS ...
May I do something wrong here? I found in mainline for example
the "arch/powerpc/dts/gdsys/gazerbeam-uboot.dtsi" board, which
has the exactly same dts settings than I have now.
@Dirk: Can you check, if this board boots with current mainline?
Shouldn;t be the logic, that in case OF_CONTROL is enabled and if
flag "u-boot,dm-pre-reloc" is set in DTS for the device, the device
should be bound before relocation, and we do not need to check, if
the driver sets DM_FLAG_PRE_RELOC ?
But may I miss here something ...
Any hints?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[GIT PULL] Raspberry Pi updates for v2020.04
Hi Tom, Please take into account the following commits for RPi boards. It includes support for DFU on RPi4 as well as network support on that board. You can find the CI output here: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/2065 and here https://travis-ci.org/mbgg/u-boot/builds/645395557 Regarding the DFU series [0] I didn't took the first two patches as I understand that you wanted to see a test for the FAT bug fixed. Regards, Matthias [0] https://patchwork.ozlabs.org/user/todo/uboot/?series=145985 --- The following changes since commit b00c3c995bf2293e32cd2be3cb4be7eb39c4ac26: Prepare v2020.04-rc1 (2020-01-28 16:59:30 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-next-2020.04 for you to fetch changes up to 095c6eba9d02688e7a1c3cd2093f826d05fe961f: rpi4: Enable GENET Ethernet controller (2020-01-29 18:30:33 +0100) - DFU support file operations lager then the default max size - add dfu support to dwc2 for bcm2835 - enable DFU for RPi4 - Fix RPi4 memory map to include the genet device - add driver for the genet ethernet device - enable network support in RPi4 config Amit Singh Tomar (3): net: Add support for Broadcom GENETv5 Ethernet controller rpi4: Update memory map to accommodate scb devices rpi4: Enable GENET Ethernet controller Marek Szyprowski (4): dfu: mmc: rearrange the code dfu: mmc: remove file size limit for io operations usb: dwc2_udc_otg: add bcm2835 SoC (Raspberry Pi4) support config: enable DFU over USB on Raspberry Pi4 boards arch/arm/mach-bcm283x/init.c | 6 +- configs/rpi_4_32b_defconfig| 14 + configs/rpi_4_defconfig| 14 + configs/rpi_arm64_defconfig| 1 + drivers/dfu/dfu_mmc.c | 93 ++-- drivers/net/Kconfig| 7 + drivers/net/Makefile | 1 + drivers/net/bcmgenet.c | 729 + drivers/usb/gadget/dwc2_udc_otg.c | 2 + drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 12 +- include/configs/rpi.h | 20 + 11 files changed, 854 insertions(+), 45 deletions(-) create mode 100644 drivers/net/bcmgenet.c
Re: [PATCH v7 00/10] Add support for loading main_r5fss0_core0
On 04/02/20 12:06 PM, Keerthy wrote: > This patch series enables mcu_r5fss0_core0 & main_r5fss0_core0. > Tested for firmware loading and execution on J721e. I still see build error with multiple imx boards: === arm: + mx7dsabresd_qspi +arch/arm/mach-imx/imx_bootaux.c:18:32: error: 'get_host_mapping' defined but not used [-Werror=unused-function] + static const struct rproc_att *get_host_mapping(unsigned long auxcore) +^~~~ +cc1: all warnings being treated as errors +make[2]: *** [arch/arm/mach-imx/imx_bootaux.o] Error 1 +make[1]: *** [arch/arm/mach-imx] Error 2 +make: *** [sub-make] Error 2 Thanks and regards, Lokesh > > Changes in v7: > > * Added BSD-2 SPDX on lib/elf.c file. > * Added Tom's Reviewed-by for the relevant patches. > > Changes in v6: > > * Fixed the imx build issue. > > Changes in v5: > > * Moved the fs_loader node under r5-common-proc-board-u-boot.dtsi > * Added more information on the envnowhere patch. > * Added help LIB_ELF option and removed user configurable description. > > Changes in v4: > > * Changed env variable names, config names and enhanced commit logs. > > Changes in v3: > > * Removed saving env in MMC and fixed env saving in SPL when nowhere > option is set. > > Changes in v2: > > * Factored out all the generic elf handling functions under lib/elf.c > > Keerthy (10): > env: nowhere: set default enviroment > lib: elf: Move the generic elf loading/validating functions to lib > arm: k3: Add support for loading non linux remote cores > armv7R: K3: r5_mpu: Enable execute permission for MCU0 BTCM > armv7R: K3: Add support for jumping to firmware > arm: dts: k3-j721e-r5-u-boot: Add fs_loader node > arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL > include: configs: j721e_evm: Add env variables for mcu_r5fss0_core0 & > main_r5fss0_core0 > configs: j721e_evm_r5: Enable R5F remoteproc support > configs: j721e_evm_r5_defconfig: Remove saving ENV in eMMC > > .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 27 ++ > .../arm/dts/k3-j721e-r5-common-proc-board.dts | 2 + > arch/arm/mach-imx/imx_bootaux.c | 46 > arch/arm/mach-k3/common.c | 106 +++- > arch/arm/mach-k3/common.h | 2 + > arch/arm/mach-k3/j721e_init.c | 34 +++ > arch/arm/mach-k3/r5_mpu.c | 4 +- > cmd/Kconfig | 1 + > cmd/elf.c | 229 > configs/j721e_evm_r5_defconfig| 6 +- > env/nowhere.c | 1 + > include/configs/j721e_evm.h | 4 + > include/elf.h | 4 + > lib/Kconfig | 6 + > lib/Makefile | 1 + > lib/elf.c | 246 ++ > 16 files changed, 428 insertions(+), 291 deletions(-) > create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi > create mode 100644 lib/elf.c >
Re: Time frame for "Refactor the architecture parts of mt7628 "?
Timid reminder... Is there any reason why these could *not* get into mainline? These work for me, should I add a "tested-by" annotation? Many Thanks Mauro On 1/30/20 3:28 PM, Mauro Condarelli wrote: > Hi, > I would like to have a tentative time frame for inclusion > of Wiijie Gao "Refactor the architecture parts of mt7628" > series into master. > Reason why I ask is my own patches are based on it. > > Thanks in Advance > Mauro >
RE: [v8 1/8] rtc: pcf8563: Add driver model support
> u-boot@lists.denx.de > Subject: RE: [v8 1/8] rtc: pcf8563: Add driver model support > > >-Original Message- > >From: Biwen Li > >Sent: Wednesday, February 5, 2020 7:39 AM > >To: Biwen Li ; Jagdish Gediya > >; Priyanka Jain ; > >h...@denx.de; ja...@amarulasolutions.com; aford...@gmail.com; Alison > Wang > >; jh80.ch...@samsung.com; Pramod Kumar > >; Rajesh Bhagat ; > >Ruchika Gupta ; olte...@gmail.com > >Cc: Xiaobo Xie ; Jiafei Pan ; > >u- b...@lists.denx.de > >Subject: RE: [v8 1/8] rtc: pcf8563: Add driver model support > > > >> Subject: [v8 1/8] rtc: pcf8563: Add driver model support > >> > >> Add support of driver model of pcf8563 > >> > >> Signed-off-by: Biwen Li > >> --- > Series (except 6/8, 7/8 for which changes are requested) applied (after fixing > checkpatch errors) on u-boot-fsl-qoriq/master. > Awaiting upstream Okay, get it, thanks. Best regards, Biwen Li > -priyankajain
Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
On 2/5/20 8:43 AM, Ard Biesheuvel wrote:
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt wrote:
RISC-V booting currently is based on a per boot stage lottery to determine
the active CPU. The Hart State Management (HSM) SBI extension replaces
this lottery by using a dedicated primary CPU.
Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
In this scenario the id of the active hart has to be passed from boot stage
to boot stage. Using a UEFI variable would provide an easy implementation.
This patch provides a weak function that is called at the end of the setup
of U-Boot's UEFI sub-system. By overriding this function architecture
specific UEFI variables or configuration tables can be created.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Atish Patra
OK, so I have a couple of questions:
- does RISC-V use device tree? if so, why are you not passing the
In the Linux kernel tree you can find the SiFive HiFive Unleashed device
tree: arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
Some of the QEMU emulated RISC-V boards provide device trees, cf.
https://github.com/riscv/riscv-qemu/wiki#machines
active hart via a property in the /chosen node? I'd assume the EFI
There is a hart (core) that calls the entry point of the next
boot-stage. Could this define the active hart?
Best regards
Heinrich
stub would not care at all about this information, and it would give
you a Linux/RISC-V specific way to convey this information that is
independent of EFI.
- using variables to pass information from firmware to OS only is
overkill, and config tables are preferred, given that they only
require access to the system table. If required, a RISC-V specific
data structure containing boot parameters could be installed as a
configuration table, and the address passed to the startup code in the
kernel proper [rather than just a hart id], allowing you to put any
piece of information you like in there.
Config tables work fine with kexec, btw. It is up to the first OS to
memblock_reserve() the table to guarantee that it is still there at
kexec time, but this applies equally to all other data structures
passed as config tables. Alternatively, in this case, you can
stipulate that it is passed as AcpiReclaim [ignore the 'Acpi' in the
name] which is intended for firmware tables (and we never reclaim it
in linux)
I'd also recommend that RISC-V adopt the same principle as ARM does
when it comes to EFI: call SetVirtualAddressMap in the stub, so that
the kernel proper always sees the same handover state, regardless of
kexec. Additionally, you shouldn't ever modify the EFI memory map
provided by the firmware, so that the kexec kernel sees the exact same
version.
---
v2:
reference the Hart State Management Extension in the commit message
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_setup.c | 16
2 files changed, 19 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d4c59b54c4..d87de85e83 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -116,6 +116,9 @@ extern efi_uintn_t efi_memory_map_key;
extern struct efi_runtime_services efi_runtime_services;
extern struct efi_system_table systab;
+/* Architecture specific initialization of the UEFI system */
+efi_status_t efi_setup_arch_specific(void);
+
extern struct efi_simple_text_output_protocol efi_con_out;
extern struct efi_simple_text_input_protocol efi_con_in;
extern struct efi_console_control_protocol efi_console_control;
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index de7b616c6d..8469f0f43c 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -22,6 +22,17 @@ void __weak allow_unaligned(void)
{
}
+/**
+ * efi_setup_arch_specific() - architecture specific UEFI setup
+ *
+ * This routine can be used to define architecture specific variables
+ * or configuration tables, e.g. HART id for RISC-V
+ */
+efi_status_t __weak efi_setup_arch_specific(void)
+{
+ return EFI_SUCCESS;
+}
+
/**
* efi_init_platform_lang() - define supported languages
*
@@ -179,6 +190,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
+ /* Architecture specific setup */
+ ret = efi_setup_arch_specific();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
out:
efi_obj_list_initialized = ret;
return ret;
--
2.24.1
Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
Hello Daniel, hello Leif,
what is the GRUB view on this discussion?
Best regards
Heinrich
On 2/5/20 12:32 PM, Heinrich Schuchardt wrote:
On 2/5/20 8:43 AM, Ard Biesheuvel wrote:
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt
wrote:
RISC-V booting currently is based on a per boot stage lottery to
determine
the active CPU. The Hart State Management (HSM) SBI extension replaces
this lottery by using a dedicated primary CPU.
Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
In this scenario the id of the active hart has to be passed from boot
stage
to boot stage. Using a UEFI variable would provide an easy
implementation.
This patch provides a weak function that is called at the end of the
setup
of U-Boot's UEFI sub-system. By overriding this function architecture
specific UEFI variables or configuration tables can be created.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Atish Patra
OK, so I have a couple of questions:
- does RISC-V use device tree? if so, why are you not passing the
In the Linux kernel tree you can find the SiFive HiFive Unleashed device
tree: arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
Some of the QEMU emulated RISC-V boards provide device trees, cf.
https://github.com/riscv/riscv-qemu/wiki#machines
active hart via a property in the /chosen node? I'd assume the EFI
There is a hart (core) that calls the entry point of the next
boot-stage. Could this define the active hart?
Best regards
Heinrich
stub would not care at all about this information, and it would give
you a Linux/RISC-V specific way to convey this information that is
independent of EFI.
- using variables to pass information from firmware to OS only is
overkill, and config tables are preferred, given that they only
require access to the system table. If required, a RISC-V specific
data structure containing boot parameters could be installed as a
configuration table, and the address passed to the startup code in the
kernel proper [rather than just a hart id], allowing you to put any
piece of information you like in there.
Config tables work fine with kexec, btw. It is up to the first OS to
memblock_reserve() the table to guarantee that it is still there at
kexec time, but this applies equally to all other data structures
passed as config tables. Alternatively, in this case, you can
stipulate that it is passed as AcpiReclaim [ignore the 'Acpi' in the
name] which is intended for firmware tables (and we never reclaim it
in linux)
I'd also recommend that RISC-V adopt the same principle as ARM does
when it comes to EFI: call SetVirtualAddressMap in the stub, so that
the kernel proper always sees the same handover state, regardless of
kexec. Additionally, you shouldn't ever modify the EFI memory map
provided by the firmware, so that the kexec kernel sees the exact same
version.
---
v2:
reference the Hart State Management Extension in the commit
message
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_setup.c | 16
2 files changed, 19 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d4c59b54c4..d87de85e83 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -116,6 +116,9 @@ extern efi_uintn_t efi_memory_map_key;
extern struct efi_runtime_services efi_runtime_services;
extern struct efi_system_table systab;
+/* Architecture specific initialization of the UEFI system */
+efi_status_t efi_setup_arch_specific(void);
+
extern struct efi_simple_text_output_protocol efi_con_out;
extern struct efi_simple_text_input_protocol efi_con_in;
extern struct efi_console_control_protocol efi_console_control;
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index de7b616c6d..8469f0f43c 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -22,6 +22,17 @@ void __weak allow_unaligned(void)
{
}
+/**
+ * efi_setup_arch_specific() - architecture specific UEFI setup
+ *
+ * This routine can be used to define architecture specific variables
+ * or configuration tables, e.g. HART id for RISC-V
+ */
+efi_status_t __weak efi_setup_arch_specific(void)
+{
+ return EFI_SUCCESS;
+}
+
/**
* efi_init_platform_lang() - define supported languages
*
@@ -179,6 +190,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
+ /* Architecture specific setup */
+ ret = efi_setup_arch_specific();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
out:
efi_obj_list_initialized = ret;
return ret;
--
2.24.1
[PATCH] imx8mm/mn: Add missing root clock entry for ARM core clock
From: Frieder Schrempf
The current implementation in arch/arm/mach-imx/cpu.c uses non-DM
code to retrieve the core clock frequency. As the root clock is not
listed we currently get:
CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz
Fix this by adding the missing entry, which results in:
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz
Signed-off-by: Frieder Schrempf
---
arch/arm/mach-imx/imx8m/clock_slice.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-imx/imx8m/clock_slice.c
b/arch/arm/mach-imx/imx8m/clock_slice.c
index 31925ccaba..8b7a4dad65 100644
--- a/arch/arm/mach-imx/imx8m/clock_slice.c
+++ b/arch/arm/mach-imx/imx8m/clock_slice.c
@@ -477,6 +477,11 @@ static struct clk_root_map root_array[] = {
};
#elif defined(CONFIG_IMX8MM) || defined(CONFIG_IMX8MN)
static struct clk_root_map root_array[] = {
+ {ARM_A53_CLK_ROOT, CORE_CLOCK_SLICE, 0,
+{OSC_24M_CLK, ARM_PLL_CLK, SYSTEM_PLL2_500M_CLK,
+ SYSTEM_PLL2_1000M_CLK, SYSTEM_PLL1_800M_CLK,
+ SYSTEM_PLL1_400M_CLK, AUDIO_PLL1_CLK, SYSTEM_PLL3_CLK}
+ },
{NAND_USDHC_BUS_CLK_ROOT, BUS_CLOCK_SLICE, 2,
{OSC_24M_CLK, SYSTEM_PLL1_266M_CLK, SYSTEM_PLL1_800M_CLK,
SYSTEM_PLL2_200M_CLK, SYSTEM_PLL1_133M_CLK,
--
2.17.1
Re: [PATCH v3 02/10] arm: k3: Add support for loading non linux remote cores
On 24/01/20 5:33 PM, Keerthy wrote:
>
>
> On 23/01/20 10:49 pm, Keerthy wrote:
>>
>>
>> On 23/01/20 10:35 pm, Andrew F. Davis wrote:
>>> On 1/23/20 11:44 AM, Keerthy wrote:
On 23/01/20 6:54 pm, Andrew F. Davis wrote:
> On 1/22/20 11:10 PM, Keerthy wrote:
>>
>>
>> On 22/01/20 9:55 pm, Andrew F. Davis wrote:
>>> On 1/21/20 8:10 PM, keerthy wrote:
On 1/21/2020 6:26 PM, Andrew F. Davis wrote:
> On 1/21/20 6:07 AM, Keerthy wrote:
>> Add MAIN domain R5FSS0 remoteproc support from spl. This enables
>> loading the elf firmware in SPL and starting the remotecore.
>>
>> In order to start the core, there should be a file with path
>> "/lib/firmware/j7-main-r5f0_0-fw" under filesystem
>> of respective boot mode.
>>
>> Signed-off-by: Keerthy
>> Signed-off-by: Lokesh Vutla
>> [Guard start_non_linux_remote_cores under CONFIG_FS_LOADER]
>> Signed-off-by: Andreas Dannenberg
>> ---
>> arch/arm/mach-k3/common.c | 84
>> ---
>> arch/arm/mach-k3/common.h | 2 +
>> arch/arm/mach-k3/j721e_init.c | 34 ++
>> 3 files changed, 115 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
>> index 8d1529062d..f0ac0c39f1 100644
>> --- a/arch/arm/mach-k3/common.c
>> +++ b/arch/arm/mach-k3/common.c
>> @@ -16,6 +16,10 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>> +#include
>> struct ti_sci_handle *get_ti_sci_handle(void)
>> {
>> @@ -57,6 +61,74 @@ int early_console_init(void)
>> #endif
>> #ifdef CONFIG_SYS_K3_SPL_ATF
>> +
>> +void init_env(void)
>> +{
>> +#ifdef CONFIG_SPL_ENV_SUPPORT
>> + char *part;
>> +
>> + env_init();
>> + env_load();
>> + switch (spl_boot_device()) {
>> + case BOOT_DEVICE_MMC2:
>> + part = env_get("bootpart");
>> + env_set("storage_interface", "mmc");
>> + env_set("fw_dev_part", part);
>> + break;
>> + case BOOT_DEVICE_SPI:
>> + env_set("storage_interface", "ubi");
>> + env_set("fw_ubi_mtdpart", "UBI");
>> + env_set("fw_ubi_volume", "UBI0");
>> + break;
>> + default:
>> + printf("%s from device %u not supported!\n",
>> + __func__, spl_boot_device());
>
>
> This will print for almost every boot mode..
I can keep this under debug.
>
>
>> + return;
>> + }
>> +#endif
>> +}
>> +
>> +#ifdef CONFIG_FS_LOADER
>> +int load_firmware(char *name_fw, char *name_loadaddr, u32
>> *loadaddr)
>> +{
>> + struct udevice *fsdev;
>> + char *name = NULL;
>> + int size = 0;
>> +
>> + *loadaddr = 0;
>> +#ifdef CONFIG_SPL_ENV_SUPPORT
>> + switch (spl_boot_device()) {
>> + case BOOT_DEVICE_MMC2:
>> + name = env_get(name_fw);
>> + *loadaddr = env_get_hex(name_loadaddr, *loadaddr);
>> + break;
>> + default:
>> + printf("Loading rproc fw image from device %u not
>> supported!\n",
>> + spl_boot_device());
>
>
> This whole thing seems very MMC specific, if early firmware
> loading is
> important it should work for all boot modes. Find a way to include
> it in
> the next boot stage FIT image (tispl.bin) so it works for all modes.
That was not NAKd. We are going with fs_loader approach.
>>>
>>>
>>> When, where, link?
>>
>> I had implemented that way internally. That was rejected for multiple
>> right reasons:
>>
>
>
> I must have missed the internal reviews for this, anyway this is posted
> upstream so lets discus it here.
>
>
>> 1) SPL size would bloat based on the size of the firmware.
>
>
> SPL size would remain constant, the combined FIT (tispl.bin) would grow,
> but that is okay as DRAM is enabled at this point so we have no hard
> memory constraints.
I meant the FIT image containing the SPL will bloat.
>>>
>>>
>>> Exactly what I said, and so size is not a huge deal.
>>>
>>>
>
>
>> 2) There are multiple cores that need to be loaded and hence adding all
>> the firmwares under a fit can be really painful.
>
>
Re: [PATCH v1 1/5] colibri_vf: enable relocation of fdt and initrd
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > Rely on 'bootm_size' value instead to safely relocate kernel, device tree and > initrd. > > Signed-off-by: Igor Opaniuk Reviewed-by: Oleksandr Suvorov > --- > > include/configs/colibri_vf.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h > index 1478ea844e..b03ccaf094 100644 > --- a/include/configs/colibri_vf.h > +++ b/include/configs/colibri_vf.h > @@ -51,8 +51,6 @@ > #define MEM_LAYOUT_ENV_SETTINGS \ > "bootm_size=0x1000\0" \ > "fdt_addr_r=0x8200\0" \ > - "fdt_high=0x\0" \ > - "initrd_high=0x\0" \ > "kernel_addr_r=0x8100\0" \ > "pxefile_addr_r=0x8710\0" \ > "ramdisk_addr_r=0x8210\0" \ > -- > 2.17.1 > -- Best regards Oleksandr Suvorov cryo...@gmail.com
Re: [PATCH v1 2/5] colibri_imx7: enable relocation of fdt and initrd
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > Rely on 'bootm_size' value instead to safely relocate kernel, device tree and > initrd. > > Signed-off-by: Igor Opaniuk Reviewed-by: Oleksandr Suvorov > --- > > include/configs/colibri_imx7.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h > index 603ea3a053..7c00f78ef1 100644 > --- a/include/configs/colibri_imx7.h > +++ b/include/configs/colibri_imx7.h > @@ -108,8 +108,6 @@ > #define MEM_LAYOUT_ENV_SETTINGS \ > "bootm_size=0x1000\0" \ > "fdt_addr_r=0x8200\0" \ > - "fdt_high=0x\0" \ > - "initrd_high=0x\0" \ > "kernel_addr_r=0x8100\0" \ > "ramdisk_addr_r=0x8210\0" \ > "scriptaddr=0x8250\0" > -- > 2.17.1 > -- Best regards Oleksandr Suvorov cryo...@gmail.com
Re: [PATCH v1 5/5] colibri_imx6: enable relocation of fdt and initrd
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > Rely on 'bootm_size' value instead to safely relocate kernel, device tree and > initrd. > > Signed-off-by: Igor Opaniuk Reviewed-by: Oleksandr Suvorov > --- > > include/configs/colibri_imx6.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h > index cbc7501bcc..4cdd3c53af 100644 > --- a/include/configs/colibri_imx6.h > +++ b/include/configs/colibri_imx6.h > @@ -134,8 +134,6 @@ > #define MEM_LAYOUT_ENV_SETTINGS \ > "bootm_size=0x1000\0" \ > "fdt_addr_r=0x1210\0" \ > - "fdt_high=0x\0" \ > - "initrd_high=0x\0" \ > "kernel_addr_r=0x1100\0" \ > "pxefile_addr_r=0x1710\0" \ > "ramdisk_addr_r=0x1220\0" \ > -- > 2.17.1 > -- Best regards Oleksandr Suvorov cryo...@gmail.com
Re: [RFC] mx6cuboxi: Enable OF_CONTROL and DM in SPL
Hi Baruch,
Thanks for your comments. My replay below.
On 4/2/20 10:41, Baruch Siach wrote:
Hi Walter,
Thanks for the patch.
One comment below.
On Wed, Jan 29, 2020 at 10:58:07AM -0300, Walter Lozano wrote:
Make an additional step to add full DM support to mx6cuboxi, including its
support for SPL
With this new configuration SPL image is 50 KB, higher than the
38 KB from the previous version, but it still under the 68 KB limit.
Signed-off-by: Walter Lozano
---
arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 4
configs/mx6cuboxi_defconfig | 3 +++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index d302b2e275..b1364a0bbf 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -34,3 +34,7 @@
{
status = "disabled";
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
Have you tested boot from eMMC?
You would most likely need to add to SPL DT for that.
Good point. I haven't tested booting from eMMC as I can only boot from
SD because of eFuse settings. However after re thinking it should be
still possible to test it by keeping SPL on SD and placing U-Boot on eMMC.
Regards,
Walter
baruch
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 23ce485f43..ae8d920260 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -24,6 +24,7 @@ CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv
stdout serial,vga; setenv stderr serial,vga; else setenv stdin serial; setenv stdout
serial; setenv stderr serial; fi;"
CONFIG_BOUNCE_BUFFER=y
CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_FS_EXT4=y
CONFIG_SPL_I2C_SUPPORT=y
CONFIG_SPL_WATCHDOG_SUPPORT=y
@@ -36,6 +37,7 @@ CONFIG_CMD_CACHE=y
CONFIG_CMD_EXT4_WRITE=y
# CONFIG_SPL_PARTITION_UUIDS is not set
CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE="imx6dl-hummingboard2-emmc-som-v15"
CONFIG_OF_LIST="imx6dl-hummingboard2-emmc-som-v15
imx6q-hummingboard2-emmc-som-v15"
CONFIG_MULTI_DTB_FIT=y
@@ -44,6 +46,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_DM=y
+CONFIG_SPL_DM=y
CONFIG_DWC_AHSATA=y
CONFIG_DM_GPIO=y
CONFIG_DM_MMC=y
Re: [PATCH v3] riscv: add Kconfig entries for the F and D ISA extensions support
Hi Bin, Bin Meng 於 2020年2月4日 週二 下午11:50寫道： > > On Thu, Jun 6, 2019 at 5:06 PM Eric Lin wrote: > > > > This patch adds Kconfig entries for the F (Single-Precision) > > and D (Double-Precision) floating point instruction-set extensions. > > > > Signed-off-by: Eric Lin > > --- > > Changes for v2: > > - Grammatical correction in commit message "adds" > > - Fixed the config name to indicate both F and D > > > > Changes for v3: > > - Separate the config name for ISA_F and ISA_D > > > > arch/riscv/Kconfig | 14 ++ > > arch/riscv/Makefile | 16 > > 2 files changed, 26 insertions(+), 4 deletions(-) > > > > Reviewed-by: Bin Meng > > @Eric Lin @Rick Chen > > This patch was never applied. Do we still need this patch? > I think this patch is unnecessary now. Thanks. > Regards, > Bin Regards, Eric
Re: [PATCH 1/1] efi_loader: architecture specific UEFI setup
On Sat, Feb 1, 2020 at 8:55 AM Heinrich Schuchardt wrote:
>
> RISC-V patches are developed for OpenSBI and Linux to replace random boot
> by sequential CPU bring-up.
>
> In this scenario the id of the active hart has to be passed from boot stage
> to boot stage. Using a UEFI variable would provide an easy implementation.
>
> This patch provides a weak function that is called at the end of the setup
> of the UEFI sub-system. This patch can be used to create architecture
> specific UEFI variables or configuration tables.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_loader.h | 3 +++
> lib/efi_loader/efi_setup.c | 16
> 2 files changed, 19 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index d4c59b54c4..d87de85e83 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -116,6 +116,9 @@ extern efi_uintn_t efi_memory_map_key;
> extern struct efi_runtime_services efi_runtime_services;
> extern struct efi_system_table systab;
>
> +/* Architecture specific initialization of the UEFI system */
> +efi_status_t efi_setup_arch_specific(void);
> +
> extern struct efi_simple_text_output_protocol efi_con_out;
> extern struct efi_simple_text_input_protocol efi_con_in;
> extern struct efi_console_control_protocol efi_console_control;
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index de7b616c6d..8469f0f43c 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -22,6 +22,17 @@ void __weak allow_unaligned(void)
> {
> }
>
> +/**
> + * efi_setup_arch_specific() - architecture specific UEFI setup
> + *
> + * This routine can be used to define architecture specific variables
> + * or configuration tables, e.g. HART id for RISC-V
> + */
> +efi_status_t __weak efi_setup_arch_specific(void)
> +{
> + return EFI_SUCCESS;
> +}
> +
> /**
> * efi_init_platform_lang() - define supported languages
> *
> @@ -179,6 +190,11 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
>
> + /* Architecture specific setup */
> + ret = efi_setup_arch_specific();
> + if (ret != EFI_SUCCESS)
> + goto out;
> +
> out:
> efi_obj_list_initialized = ret;
> return ret;
> --
> 2.24.1
>
Thanks for the quick patch. Looks good to me.
Reviewed-by: Atish Patra
Do you mind if I include this in my RISC-V specific patch and send it along with
EFI stub linux kernel patches so that all of them can be tested together.
--
Regards,
Atish
fw_printenv resulting in bad crc, using default environment
Hello,
I am using a Linux evaluation board MBa6x with the TQMa6x module. The system is
configured in order to boot from eMMC. I would like to use the tool fw_printenv
and get following result:
fw_printenv
Warning: Bad CRC, using default environment
bootargs=
bootcmd=
bootdelay=2
baudrate=115200
...
The content of /etc/fw_env.config is as follows:
cat /etc/fw_env.config
# Configuration file for fw_(printenv/setenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
# Notice, that the "Number of sectors" is ignored on NOR and SPI-dataflash.
# Futhermore, if the Flash sector size is ommitted, this value is assumed to
# be the same as the Environment size, which is valid for NOR and SPI-dataflash
# THIS IS VALID FOR TQMa6x eMMC-card only!
# eMMC Block device access
/dev/mmcblk00x100x2000
# if using with redundant env
/dev/mmcblk00x102x2000
...
As a first action, I interrupted the boot process to enter the u-boot shell.
Within the u-boot shall I forced to re-write the environment variables by using
the command saveenv. This seems to work without any issues.
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
But next time, when the system reboots, the fw_printenv command issues the same
result as described above (Bad CRC...).
Next action I have done is to dump the content of the memory at address
0x10, which seems to be ok.
hexdump -C -s 0x10 -n 8192 /dev/mmcblk0
0010 95 fc 63 38 61 64 64 63 6d 61 3d 73 65 74 65 6e |..c8addcma=seten|
00100010 76 20 62 6f 6f 74 61 72 67 73 20 24 7b 62 6f 6f |v bootargs ${boo|
...
A hexdump at address 0x102000 seems to be incorrect. Maybe this is the root
cause of the bad CRC issue?
hexdump -C -s 0x102000 -n 8192 /dev/mmcblk0
00102000 18 00 9f e5 95 24 01 eb 3c 30 94 e5 04 00 a0 e1 |.$..<0..|
00102010 08 30 43 e2 3c 30 84 e5 80 ff ff eb 7b ff ff eb |.0C.<0..{...|
...
Here is also the output of /dev
ls /dev
...
cuse memory_bandwidthstdout
disk mmcblk0 tty
dri mmcblk0boot0 ttymxc1
fd mmcblk0boot1 ttymxc2
fullmmcblk0p1 ttymxc3
fuse mmcblk0p2 ttymxc4
gpiochip0mmcblk0p3 ubi_ctrl
gpiochip1mmcblk0rpmb uhid
gpiochip2mmcblk1 uinput
gpiochip3mmcblk1p1 urandom
gpiochip4mmcblk1p2 v4l
gpiochip5mmcblk1p3 vga_arbiter
gpiochip6mqueue video0
...
Thank you for any hints you could provide in order to solve this issue.
Regards,
Robert Varga
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to which they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.
Re: [PATCH v2 13/17] x86: Add support for ACPI general-purpose events
Hi Bin,
On Tue, 4 Feb 2020 at 02:08, Bin Meng wrote:
>
> On Tue, Feb 4, 2020 at 8:20 AM Simon Glass wrote:
> >
> > ACPI GPEs are used to signal interrupts from peripherals that are accessed
> > via ACPI. In U-Boot these are modelled as interrupts using a separate
> > interrupt controller. Configuration is via the device tree.
> >
> > Add a simple driver for this.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v2: None
> >
> > arch/x86/Kconfig | 33 +++
> > arch/x86/cpu/Makefile | 1 +
> > arch/x86/cpu/acpi_gpe.c | 85 +++
> > .../interrupt-controller/intel,acpi-gpe.txt | 30 +++
> > 4 files changed, 149 insertions(+)
> > create mode 100644 arch/x86/cpu/acpi_gpe.c
> > create mode 100644
> > doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
> >
[..]
> > diff --git
> > a/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
> > b/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
> > new file mode 100644
> > index 00..d9252bf29f
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
> > @@ -0,0 +1,30 @@
> > +* Intel Advanced Configuration and Power Interface General Purpose Events
> > +
> > +This describes an interrupt controller which provides access to GPEs
> > supported
> > +by the SoC.
> > +
> > +Required properties:
> > +
> > +- compatible : "intel,acpi-gpe"
> > +- interrupt-controller : Identifies the node as an interrupt controller
> > +- #interrupt-cells : The number of cells to define the interrupts. Must
> > be 2:
> > + cell 0: interrupt number (normally >=32 since GPEs below that are
> > reserved)
> > + cell 1: 0 (flags, but none are currently defined)
>
> I wonder why we have to use #interrupt-cells = <2> since cell 1 is always zero
I am thinking that we will need a lot of flags eventually and want to
avoid needing to change the binding later.
>
> > +- reg : The register bank for the controller (set this to the ACPI base).
> > +
> > +Example:
> > +
> > + general-purpose-events {
> > + reg = ;
> > + compatible = "intel,acpi-gpe";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > +
> > + ...
> > + tpm@50 {
> > + reg = <0x50>;
> > + compatible = "google,cr50";
> > + ready-gpio = <_n 0x1c GPIO_ACTIVE_LOW>;
> > + interrupts-extended = <_gpe 0x3c 0>;
> > + };
> > --
>
> Reviewed-by: Bin Meng
Regards,
Simon
Re: [PATCH] imx8mm/mn: Add missing root clock entry for ARM core clock
Hi Frieder, On Wed, Feb 5, 2020 at 8:45 AM Schrempf Frieder wrote: > > From: Frieder Schrempf > > The current implementation in arch/arm/mach-imx/cpu.c uses non-DM > code to retrieve the core clock frequency. As the root clock is not > listed we currently get: > > CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz > > Fix this by adding the missing entry, which results in: > > CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz > > Signed-off-by: Frieder Schrempf Thanks for the fix: Reviewed-by: Fabio Estevam
Re: fw_printenv resulting in bad crc, using default environment
On Wed, 5 Feb 2020 10:09:40 +
Robert Varga robert.va...@getinge.com wrote:
...
> The content of /etc/fw_env.config is as follows:
> cat /etc/fw_env.config
> # Configuration file for fw_(printenv/setenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
The above statement is a hint.
> # Notice, that the "Number of sectors" is ignored on NOR and SPI-dataflash.
> # Futhermore, if the Flash sector size is ommitted, this value is assumed to
> # be the same as the Environment size, which is valid for NOR and
> SPI-dataflash
>
> # THIS IS VALID FOR TQMa6x eMMC-card only!
> # eMMC Block device access
> /dev/mmcblk00x100x2000
> # if using with redundant env
> /dev/mmcblk00x102x2000
Comment out the above line and try again.
...
> hexdump -C -s 0x10 -n 8192 /dev/mmcblk0
> 0010 95 fc 63 38 61 64 64 63 6d 61 3d 73 65 74 65 6e |..c8addcma=seten|
> 00100010 76 20 62 6f 6f 74 61 72 67 73 20 24 7b 62 6f 6f |v bootargs ${boo|
It looks like this U-Boot configuration does not use redundant environment,
so you must have only one entry in /etc/fw_env.config.
--
Anatolij
Re: [PATCH v1 4/5] colibri-imx6ull: enable relocation of fdt and initrd
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > Rely on 'bootm_size' value instead to safely relocate kernel, device tree and > initrd. > > Signed-off-by: Igor Opaniuk Reviewed-by: Oleksandr Suvorov > --- > > include/configs/colibri-imx6ull.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/colibri-imx6ull.h > b/include/configs/colibri-imx6ull.h > index ea5ba6bfce..2a76f576a8 100644 > --- a/include/configs/colibri-imx6ull.h > +++ b/include/configs/colibri-imx6ull.h > @@ -40,8 +40,6 @@ > #define MEM_LAYOUT_ENV_SETTINGS \ > "bootm_size=0x1000\0" \ > "fdt_addr_r=0x8210\0" \ > - "fdt_high=0x\0" \ > - "initrd_high=0x\0" \ > "kernel_addr_r=0x8100\0" \ > "pxefile_addr_r=0x8710\0" \ > "ramdisk_addr_r=0x8220\0" \ > -- > 2.17.1 > -- Best regards Oleksandr Suvorov Toradex AG Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 4800 (main line)
Re: [PATCH v1 3/5] apalis_imx6: enable relocation of fdt and initrd
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > Rely on 'bootm_size' value instead to safely relocate kernel, device tree and > initrd. > > Signed-off-by: Igor Opaniuk Reviewed-by: Oleksandr Suvorov > --- > > include/configs/apalis_imx6.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h > index d2ff7e9534..fb0037444f 100644 > --- a/include/configs/apalis_imx6.h > +++ b/include/configs/apalis_imx6.h > @@ -146,8 +146,6 @@ > #define MEM_LAYOUT_ENV_SETTINGS \ > "bootm_size=0x2000\0" \ > "fdt_addr_r=0x1210\0" \ > - "fdt_high=0x\0" \ > - "initrd_high=0x\0" \ > "kernel_addr_r=0x1100\0" \ > "pxefile_addr_r=0x1710\0" \ > "ramdisk_addr_r=0x1220\0" \ > -- > 2.17.1 > -- Best regards Oleksandr Suvorov cryo...@gmail.com
Re: [PATCH v1 5/5] colibri_imx6: enable relocation of fdt and initrd
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > Rely on 'bootm_size' value instead to safely relocate kernel, device tree and > initrd. > > Signed-off-by: Igor Opaniuk Reviewed-by: Oleksandr Suvorov > --- > > include/configs/colibri_imx6.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h > index cbc7501bcc..4cdd3c53af 100644 > --- a/include/configs/colibri_imx6.h > +++ b/include/configs/colibri_imx6.h > @@ -134,8 +134,6 @@ > #define MEM_LAYOUT_ENV_SETTINGS \ > "bootm_size=0x1000\0" \ > "fdt_addr_r=0x1210\0" \ > - "fdt_high=0x\0" \ > - "initrd_high=0x\0" \ > "kernel_addr_r=0x1100\0" \ > "pxefile_addr_r=0x1710\0" \ > "ramdisk_addr_r=0x1220\0" \ > -- > 2.17.1 > -- Best regards Oleksandr Suvorov Toradex AG Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 4800 (main line)
Re: [PATCH 1/2] menu: Make some parts of the menu available to other components
Hi Simon,
On 30.12.19 02:21, Simon Glass wrote:
> Hi Schrempf,
>
> On Tue, 10 Dec 2019 at 08:47, Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> In order to iterate over the menu entries and match for a specific
>> name in the pxe boot, we need to properly export the needed structs
>> and functions.
>>
>> Signed-off-by: Frieder Schrempf
>> ---
>> common/menu.c | 31 +--
>> include/menu.h | 34 +-
>> 2 files changed, 34 insertions(+), 31 deletions(-)
>>
>> diff --git a/common/menu.c b/common/menu.c
>> index 7b66d199a9..82b03f17f7 100644
>> --- a/common/menu.c
>> +++ b/common/menu.c
>> @@ -12,36 +12,7 @@
>>
>> #include "menu.h"
>>
>> -/*
>> - * Internally, each item in a menu is represented by a struct menu_item.
>> - *
>> - * These items will be alloc'd and initialized by menu_item_add and
>> destroyed
>> - * by menu_item_destroy, and the consumer of the interface never sees that
>> - * this struct is used at all.
>> - */
>> -struct menu_item {
>> - char *key;
>> - void *data;
>> - struct list_head list;
>> -};
>>
>> -/*
>> - * The menu is composed of a list of items along with settings and callbacks
>> - * provided by the user. An incomplete definition of this struct is
>> available
>> - * in menu.h, but the full definition is here to prevent consumers from
>> - * relying on its contents.
>> - */
>> -struct menu {
>> - struct menu_item *default_item;
>> - int timeout;
>> - char *title;
>> - int prompt;
>> - void (*item_data_print)(void *);
>> - char *(*item_choice)(void *);
>> - void *item_choice_data;
>> - struct list_head items;
>> - int item_cnt;
>> -};
>>
>> /*
>>* An iterator function for menu items. callback will be called for each
>> item
>> @@ -51,7 +22,7 @@ struct menu {
>>* used for search type operations. It is also safe for callback to remove
>> the
>>* item from the list of items.
>>*/
>> -static inline void *menu_items_iter(struct menu *m,
>> +inline void *menu_items_iter(struct menu *m,
>> void *(*callback)(struct menu *, struct menu_item *, void
>> *),
>> void *extra)
>> {
>> diff --git a/include/menu.h b/include/menu.h
>> index 2d227c20bd..b3f8db87e4 100644
>> --- a/include/menu.h
>> +++ b/include/menu.h
>> @@ -6,8 +6,40 @@
>> #ifndef __MENU_H__
>> #define __MENU_H__
>>
>> -struct menu;
>> +/*
>> + * Internally, each item in a menu is represented by a struct menu_item.
>> + *
>> + * These items will be alloc'd and initialized by menu_item_add and
>> destroyed
>> + * by menu_item_destroy, and the consumer of the interface never sees that
>> + * this struct is used at all.
>> + */
>> +struct menu_item {
>> + char *key;
>> + void *data;
>> + struct list_head list;
>> +};
>> +
>> +/*
>> + * The menu is composed of a list of items along with settings and callbacks
>> + * provided by the user. An incomplete definition of this struct is
>> available
>> + * in menu.h, but the full definition is here to prevent consumers from
>> + * relying on its contents.
>
> This comment doesn't seem to be true anymore.
Right.
>
> Is it possible to add a function to get the info you need from the menu?
Unfortunately I didn't find a better solution, that doesn't expose the
menu structures. The problem is that menu and pxe are not separated
cleanly as the menu items contain references to struct pxe_label.
If I would add a function to iterate over the items to the menu code, I
would need to make struct pxe_label known to the menu code, which
doesn't seem nice, either.
Please let me know if you propose a different approach.
Thanks,
Frieder
>
>> + */
>> +struct menu {
>> + struct menu_item *default_item;
>> + int timeout;
>> + char *title;
>> + int prompt;
>> + void (*item_data_print)(void *);
>> + char *(*item_choice)(void *);
>> + void *item_choice_data;
>> + struct list_head items;
>> + int item_cnt;
>> +};
>>
>> +void *menu_items_iter(struct menu *m,
>> + void *(*callback)(struct menu *, struct menu_item *, void *),
>> + void *extra);
>> struct menu *menu_create(char *title, int timeout, int prompt,
>> void (*item_data_print)(void *),
>> char *(*item_choice)(void *),
>> --
>> 2.17.1
>
> Regards,
> Simon
>
[RESEND v8 6/8] dm: arm64: ls1043a: add i2c DM support
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1043A
Reviewed-by: Priyanka Jain
Signed-off-by: Biwen Li
---
Changes in RESEND v8:
- fix build warning
Changes in v8:
- none
Changes in v7:
- none
Changes in v6:
- correct dependencies
Changes in v5:
- update subject
Changes in v4:
- update copyright
Changes in v3:
- none
Changes in v2:
- merge some patches to one patch
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 +-
arch/arm/include/asm/gpio.h | 4 +-
board/freescale/ls1043aqds/ls1043aqds.c | 98 +--
configs/ls1043aqds_defconfig | 2 +
configs/ls1043aqds_lpuart_defconfig | 2 +
configs/ls1043aqds_nand_defconfig | 2 +
configs/ls1043aqds_nor_ddr3_defconfig | 2 +
configs/ls1043aqds_qspi_defconfig | 2 +
configs/ls1043aqds_sdcard_ifc_defconfig | 2 +
configs/ls1043aqds_sdcard_qspi_defconfig | 2 +
configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1043aqds_tfa_defconfig | 2 +
configs/ls1043ardb_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_defconfig | 2 +
configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_nand_defconfig | 2 +
.../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_sdcard_defconfig | 2 +
configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_tfa_defconfig | 2 +
include/configs/ls1043a_common.h | 11 +++
21 files changed, 144 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 275c66d992..760053e401 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -74,11 +74,11 @@ config ARCH_LS1043A
select SYS_FSL_HAS_DDR4
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
- select SYS_I2C_MXC
- select SYS_I2C_MXC_I2C1
- select SYS_I2C_MXC_I2C2
- select SYS_I2C_MXC_I2C3
- select SYS_I2C_MXC_I2C4
+ select SYS_I2C_MXC if !DM_I2C
+ select SYS_I2C_MXC_I2C1 if !DM_I2C
+ select SYS_I2C_MXC_I2C2 if !DM_I2C
+ select SYS_I2C_MXC_I2C3 if !DM_I2C
+ select SYS_I2C_MXC_I2C4 if !DM_I2C
imply CMD_PCI
config ARCH_LS1046A
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 29dc498bd8..c480e712fe 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,8 +3,8 @@
!defined(CONFIG_ARCH_BCM6858) && !defined(CONFIG_ARCH_BCM63158) && \
!defined(CONFIG_ARCH_ROCKCHIP) && !defined(CONFIG_ARCH_LX2160A) && \
!defined(CONFIG_ARCH_LS1012A) && !defined(CONFIG_ARCH_LS1028A) && \
- !defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A)
&& \
- !defined(CONFIG_ARCH_ASPEED) && \
+ !defined(CONFIG_ARCH_LS1043A) && !defined(CONFIG_ARCH_LS2080A) && \
+ !defined(CONFIG_ARCH_LS1088A) && !defined(CONFIG_ARCH_ASPEED) && \
!defined(CONFIG_ARCH_U8500)
#include
#endif
diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
b/board/freescale/ls1043aqds/ls1043aqds.c
index 8c96b962b7..2d4b18cdbc 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2015 Freescale Semiconductor, Inc.
+ * Copyright 2019 NXP
*/
#include
@@ -271,11 +272,24 @@ unsigned long get_board_ddr_clk(void)
return ;
}
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
{
int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return ret;
+ }
+ ret = dm_i2c_write(dev, 0, , 1);
+#else
ret = i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+#endif
if (ret) {
puts("PCA: failed to select proper channel\n");
return ret;
@@ -290,8 +304,10 @@ int dram_init(void)
* When resuming from deep sleep, the I2C channel may not be
* in the default channel. So, switch to the default channel
* before accessing DDR SPD.
+*
+* PCA9547 mount on I2C1 bus
*/
- select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
+ select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
fsl_initdram();
#if (!defined(CONFIG_SPL) && !defined(CONFIG_TFABOOT)) || \
defined(CONFIG_SPL_BUILD)
@@ -304,16 +320,83 @@ int dram_init(void)
int i2c_multiplexer_select_vid_channel(u8 channel)
{
- return select_i2c_ch_pca9547(channel);
+ return
[RESEND v8 7/8] dm: arm64: ls1046a: add i2c DM support
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1046A
Reviewed-by: Priyanka Jain
Signed-off-by: Biwen Li
---
Changes in RESEND v8:
- fix build warning
Changes in v8:
- none
Changes in v7:
- none
Changes in v6:
- correct dependencies
Changes in v5:
- update subject
Changes in v4:
- update copyright
Changes in v3:
- none
Changes in v2:
- merge some patches to one patch
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 ++--
arch/arm/dts/fsl-ls1046a-frwy.dts | 3 ++
arch/arm/dts/fsl-ls1046a-qds.dtsi | 4 ++
arch/arm/dts/fsl-ls1046a-rdb.dts | 8
arch/arm/include/asm/gpio.h | 5 +-
board/freescale/ls1046afrwy/ls1046afrwy.c | 17 ++-
board/freescale/ls1046aqds/ls1046aqds.c | 25 --
configs/ls1046afrwy_tfa_defconfig | 2 +
configs/ls1046aqds_SECURE_BOOT_defconfig | 2 +
configs/ls1046aqds_defconfig | 2 +
configs/ls1046aqds_lpuart_defconfig | 2 +
configs/ls1046aqds_nand_defconfig | 2 +
configs/ls1046aqds_qspi_defconfig | 2 +
configs/ls1046aqds_sdcard_ifc_defconfig | 2 +
configs/ls1046aqds_sdcard_qspi_defconfig | 2 +
configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1046aqds_tfa_defconfig | 2 +
configs/ls1046ardb_emmc_defconfig | 2 +
configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 2 +
configs/ls1046ardb_qspi_defconfig | 2 +
configs/ls1046ardb_qspi_spl_defconfig | 2 +
.../ls1046ardb_sdcard_SECURE_BOOT_defconfig | 2 +
configs/ls1046ardb_sdcard_defconfig | 2 +
configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1046ardb_tfa_defconfig | 2 +
drivers/power/power_i2c.c | 46 ++-
include/configs/ls1046a_common.h | 11 +
27 files changed, 150 insertions(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 760053e401..b25639183f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -107,11 +107,11 @@ config ARCH_LS1046A
select SYS_FSL_SRDS_2
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
- select SYS_I2C_MXC
- select SYS_I2C_MXC_I2C1
- select SYS_I2C_MXC_I2C2
- select SYS_I2C_MXC_I2C3
- select SYS_I2C_MXC_I2C4
+ select SYS_I2C_MXC if !DM_I2C
+ select SYS_I2C_MXC_I2C1 if !DM_I2C
+ select SYS_I2C_MXC_I2C2 if !DM_I2C
+ select SYS_I2C_MXC_I2C3 if !DM_I2C
+ select SYS_I2C_MXC_I2C4 if !DM_I2C
imply SCSI
imply SCSI_AHCI
diff --git a/arch/arm/dts/fsl-ls1046a-frwy.dts
b/arch/arm/dts/fsl-ls1046a-frwy.dts
index 3d41e3bd44..d39159322a 100644
--- a/arch/arm/dts/fsl-ls1046a-frwy.dts
+++ b/arch/arm/dts/fsl-ls1046a-frwy.dts
@@ -32,3 +32,6 @@
};
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-qds.dtsi
b/arch/arm/dts/fsl-ls1046a-qds.dtsi
index c95f44fc36..76dc397328 100644
--- a/arch/arm/dts/fsl-ls1046a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1046a-qds.dtsi
@@ -80,3 +80,7 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-rdb.dts b/arch/arm/dts/fsl-ls1046a-rdb.dts
index a05c9e9b9e..83e34ab02a 100644
--- a/arch/arm/dts/fsl-ls1046a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1046a-rdb.dts
@@ -43,3 +43,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index c480e712fe..09573722ac 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,8 +3,9 @@
!defined(CONFIG_ARCH_BCM6858) && !defined(CONFIG_ARCH_BCM63158) && \
!defined(CONFIG_ARCH_ROCKCHIP) && !defined(CONFIG_ARCH_LX2160A) && \
!defined(CONFIG_ARCH_LS1012A) && !defined(CONFIG_ARCH_LS1028A) && \
- !defined(CONFIG_ARCH_LS1043A) && !defined(CONFIG_ARCH_LS2080A) && \
- !defined(CONFIG_ARCH_LS1088A) && !defined(CONFIG_ARCH_ASPEED) && \
+ !defined(CONFIG_ARCH_LS1043A) && !defined(CONFIG_ARCH_LS1046A) && \
+ !defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
+ !defined(CONFIG_ARCH_ASPEED) && \
!defined(CONFIG_ARCH_U8500)
#include
#endif
diff --git a/board/freescale/ls1046afrwy/ls1046afrwy.c
b/board/freescale/ls1046afrwy/ls1046afrwy.c
index db8b3a5b92..8c0abb63a9 100644
--- a/board/freescale/ls1046afrwy/ls1046afrwy.c
+++ b/board/freescale/ls1046afrwy/ls1046afrwy.c
@@ -36,11 +36,24 @@
DECLARE_GLOBAL_DATA_PTR;
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
{
int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+
Re: [U-Boot] Sharing a hardware lab
Hi Tom, On Wed, 4 Dec 2019 at 15:30, Tom Rini wrote: > > On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > I have been meaning to have a crack at setting up a little hardware > > lab for a while. > > > > I made some progress recently and hooked up a rpi_3 with sdwire for > > USB/SD, ykush for power and a little computer to control it. It builds > > U-Boot, sticks it on the SD card and runs pytest. > > > > I pushed a tree here and hopefully you can see the 'hwlab' thing at the end: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/148 > > > > So far it is just running the 'help' test. It seems to hang with > > serial console problems if I try to do more. It is not 100% reliable > > yet. I based it on Stephen's test hooks: > > > > https://github.com/sglass68/uboot-test-hooks > > > > Is it possible to share this so that others can use the lab when they > > push trees? Is it as simple as adding to the .gitlab-ci.yml file as I > > have done here? > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/gitlab-working/.gitlab-ci.yml > > > > I also got tbot going in a similar way, to test booting into Linux. > > Should we look at integrating that at the same time? It should be > > fairly easy to do. > > > > I have quite a lot of random boards and in principle it should not be > > too hard to hook up some more of them, with sufficient SDwires, hubs > > and patience. Bumping this thread as I have now hooked up about about 8 mostly ARM and x86 boards and have tbot and pytest automation mostly working for them. > > There's two parts of this. The first part I think is that we need some > good examples of how to have one private CI job poll / monitor other > public jobs and run. I believe some labs do this today. This would be > helpful as at least personally I'm kicking my hardware tests manually. > This is because as best I can tell there isn't a way to include an > optional stage/portion of a CI job. So the model here is that people with a lab 'watch' various repos? I think that would be useful. Stephen Warren does this I think, but I'm not sure how the builds are kicked off. But what about a full public lab? E.g. is it possible to add some of the boards I have here to every build that people do? > > The second part is that long term, we need to most likely develop some > LAVA experience as that will get us easier access to various kernelci > labs and in turn be included in kernelci labs, when the overall SoC and > lab support being able to test firmware. I wonder if these are set up for replacing firmware? It specifically mentions boards getting bricked, so I suspect not. Regards, Simon
Re: [PATCH v1] imx: imx8qm: enable relocation of fdt and initrd
On Wed, Feb 05, 2020 at 03:51:42PM +, Oliver Graute wrote: > Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) > from default environment which prevents relocation of FDT and initrd. > > Signed-off-by: Oliver Graute > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: Peng Fan > Cc: Simon Glass > Cc: Ye Li > Cc: uboot-imx > --- > include/configs/imx8qm_rom7720.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/imx8qm_rom7720.h > b/include/configs/imx8qm_rom7720.h > index 865863eb7c..8beb65e96b 100644 > --- a/include/configs/imx8qm_rom7720.h > +++ b/include/configs/imx8qm_rom7720.h > @@ -63,11 +63,9 @@ > "panel=NULL\0" \ > "console=ttyLP0\0" \ > "fdt_addr=0x8300\0" \ > - "fdt_high=0x\0" \ > "boot_fdt=try\0" \ > "fdt_file=imx8qm-rom7720-a1.dtb\0" \ > "initrd_addr=0x8380\0" \ > - "initrd_high=0x\0" \ > "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \ > "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \ > "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \ Is bootm_size or CONFIG_SYS_BOOTMAPSZ already being set somewhere for these platforms? In Linux, Documentation/arm64/booting.rst does describe limitations on where FDT/initrd can reside in memory so we need to make sure they're obeyed. That's best done by using bootm_size in environment or CONFIG_SYS_BOOTMAPSZ at build time to ensure alignment and non-overlap within those limits and not "don't move anything ever" as fdt_high/initrd_high=0xff... does. Thanks! -- Tom signature.asc Description: PGP signature
RE: [EXT] Re: fw_printenv resulting in bad crc, using default environment
Hi Anatolij,
Thank you very much for solving the problem. After commenting out the line
within /etc/fw_env.config the fw_printenv tool now works as expected.
Regards,
Robert
-Original Message-
From: Anatolij Gustschin [mailto:ag...@denx.de]
Sent: Wednesday, February 05, 2020 3:03 PM
To: Robert Varga
Cc: u-boot@lists.denx.de
Subject: [EXT] Re: fw_printenv resulting in bad crc, using default environment
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On Wed, 5 Feb 2020 10:09:40 +
Robert Varga robert.va...@getinge.com wrote:
...
> The content of /etc/fw_env.config is as follows:
> cat /etc/fw_env.config
> # Configuration file for fw_(printenv/setenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
The above statement is a hint.
> # Notice, that the "Number of sectors" is ignored on NOR and SPI-dataflash.
> # Futhermore, if the Flash sector size is ommitted, this value is assumed to
> # be the same as the Environment size, which is valid for NOR and
> SPI-dataflash
>
> # THIS IS VALID FOR TQMa6x eMMC-card only!
> # eMMC Block device access
> /dev/mmcblk00x100x2000
> # if using with redundant env
> /dev/mmcblk00x102x2000
Comment out the above line and try again.
...
> hexdump -C -s 0x10 -n 8192 /dev/mmcblk0
> 0010 95 fc 63 38 61 64 64 63 6d 61 3d 73 65 74 65 6e |..c8addcma=seten|
> 00100010 76 20 62 6f 6f 74 61 72 67 73 20 24 7b 62 6f 6f |v bootargs ${boo|
It looks like this U-Boot configuration does not use redundant environment,
so you must have only one entry in /etc/fw_env.config.
--
Anatolij
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to which they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.
Re: Problem building u-boot
Hi Olivier, On Wed, Feb 5, 2020 at 11:01 AM Olivier BERTON < olivier.ber...@etu.univ-nantes.fr> wrote: > Hi, > > I'm a student working on ZedBoard FPGA, and I have to install a custom > Linux on the ZedBoard. > I have to build u-boot, so I'm following this Wiki : > https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841973/Build+U-Boot > In the third command I have to enter "Make", and I get this error : > > cc1: error: bad value (‘generic-armv7-a’) for ‘-mtune=’ switch > cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem > corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell > core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl > intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 > nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx > amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 > generic > Kbuild:43: recipe for target 'lib/asm-offsets.s' failed > make[1]: *** [lib/asm-offsets.s] Error 1 > Makefile:1579: recipe for target 'prepare0' failed > make: *** [prepare0] Error 2 > You are using your default x86 compiler toolchain for the compiler. This doesn't work because the ZedBoard is an ARM processor. You need to install the ARM cross compiler toolchain and set CROSS_COMPILE appropriately. For Ubuntu/apt based systems... $ apt-get install crossbuild-essential-armhf $ export CROSS_COMPILE=gcc-7-arm-linux-gnueabihf- (The above may be inaccurate in its details because I did not actually execute the commands on my computer.) gvb
[PATCH 1/3] video: add support for drawing 8bpp bitmap on 32bpp framebuffer
cfb_console driver supported 8bpp bitmap drawing on 24bpp/32bpp
displays and some boards used this configuration for drawing
the logo. After conversion to DM_VIDEO the logo drawing on such
boards doesn't work any more due to missing rendering code in the
updated bmp command code for DM_VIDEO. Add 8bpp bitmap support
for 32bpp displays.
Signed-off-by: Anatolij Gustschin
---
drivers/video/video-uclass.c | 6
drivers/video/video_bmp.c| 62
include/video.h | 2 +-
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 12057c8a5b..44380a38d9 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -228,6 +228,12 @@ static int video_post_probe(struct udevice *dev)
struct udevice *cons;
int ret;
+ if (priv->bpix == VIDEO_BPP32) {
+ priv->cmap = realloc(priv->cmap, 256 * sizeof(uint));
+ if (!priv->cmap)
+ return -ENOMEM;
+ }
+
/* Set up the line and display size */
priv->fb = map_sysmem(plat->base, plat->size);
if (!priv->line_length)
diff --git a/drivers/video/video_bmp.c b/drivers/video/video_bmp.c
index 8768228029..79d6c6afa5 100644
--- a/drivers/video/video_bmp.c
+++ b/drivers/video/video_bmp.c
@@ -172,16 +172,29 @@ static void video_set_cmap(struct udevice *dev,
struct bmp_color_table_entry *cte, unsigned colours)
{
struct video_priv *priv = dev_get_uclass_priv(dev);
+ u16 *cmap16;
+ u32 *cmap32;
int i;
- ushort *cmap = priv->cmap;
debug("%s: colours=%d\n", __func__, colours);
- for (i = 0; i < colours; ++i) {
- *cmap = ((cte->red << 8) & 0xf800) |
- ((cte->green << 3) & 0x07e0) |
- ((cte->blue >> 3) & 0x001f);
- cmap++;
- cte++;
+ if (priv->bpix == VIDEO_BPP16) {
+ cmap16 = priv->cmap;
+ for (i = 0; i < colours; ++i) {
+ *cmap16 = ((cte->red << 8) & 0xf800) |
+ ((cte->green << 3) & 0x07e0) |
+ ((cte->blue >> 3) & 0x001f);
+ cmap16++;
+ cte++;
+ }
+ } else if (priv->bpix == VIDEO_BPP32) {
+ cmap32 = priv->cmap;
+ for (i = 0; i < colours; ++i) {
+ *cmap32 = (cte->red << 16) |
+ (cte->green << 8) |
+ cte->blue;
+ cmap32++;
+ cte++;
+ }
}
}
@@ -189,7 +202,8 @@ int video_bmp_display(struct udevice *dev, ulong bmp_image,
int x, int y,
bool align)
{
struct video_priv *priv = dev_get_uclass_priv(dev);
- ushort *cmap_base = NULL;
+ u32 *cmap32_base = NULL;
+ u16 *cmap16_base = NULL;
int i, j;
uchar *fb;
struct bmp_image *bmp = map_sysmem(bmp_image, 0);
@@ -227,11 +241,11 @@ int video_bmp_display(struct udevice *dev, ulong
bmp_image, int x, int y,
}
/*
-* We support displaying 8bpp and 24bpp BMPs on 16bpp LCDs
-* and displaying 24bpp BMPs on 32bpp LCDs
+* We support displaying 8bpp and 24bpp BMPs on 16bpp or 32bpp LCDs
*/
if (bpix != bmp_bpix &&
!(bmp_bpix == 8 && bpix == 16) &&
+ !(bmp_bpix == 8 && bpix == 32) &&
!(bmp_bpix == 24 && bpix == 16) &&
!(bmp_bpix == 24 && bpix == 32)) {
printf("Error: %d bit/pixel mode, but BMP has %d bit/pixel\n",
@@ -264,36 +278,42 @@ int video_bmp_display(struct udevice *dev, ulong
bmp_image, int x, int y,
switch (bmp_bpix) {
case 1:
case 8: {
- cmap_base = priv->cmap;
#ifdef CONFIG_VIDEO_BMP_RLE8
u32 compression = get_unaligned_le32(>header.compression);
debug("compressed %d %d\n", compression, BMP_BI_RLE8);
if (compression == BMP_BI_RLE8) {
if (bpix != 16) {
/* TODO implement render code for bpix != 16 */
- printf("Error: only support 16 bpix");
+ printf("Error: only support 16 bpix\n");
return -EPROTONOSUPPORT;
}
- video_display_rle8_bitmap(dev, bmp, cmap_base, fb, x,
+ video_display_rle8_bitmap(dev, bmp, priv->cmap, fb, x,
y, width, height);
break;
}
#endif
- if (bpix != 16)
- byte_width = width;
- else
+ cmap16_base = priv->cmap;
+
[PATCH 2/3] splash: fix banner output on small displays
On boards with small displays (i.e. 480x272) the banner
output on video console can sometimes overwrite the logo
(depending on the logo size and banner length). Check
for free space right of the logo before drawing the
banner and adjust the starting position to draw the
banner string below the logo. Also adjust the cursor
position after banner output to avoid overwriting the
rendered banner when the user switches stdout to the
vidconsole.
Signed-off-by: Anatolij Gustschin
---
common/splash.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/common/splash.c b/common/splash.c
index e7d847726d..c12dd38975 100644
--- a/common/splash.c
+++ b/common/splash.c
@@ -123,26 +123,38 @@ void splash_get_pos(int *x, int *y)
void splash_display_banner(void)
{
+ struct vidconsole_priv *priv;
struct udevice *dev;
char buf[DISPLAY_OPTIONS_BANNER_LENGTH];
int col, row, ret;
+ size_t banner_len;
ret = uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, );
if (ret)
return;
+ priv = dev_get_uclass_priv(dev);
+ if (!priv)
+ return;
+
#ifdef CONFIG_VIDEO_LOGO
col = BMP_LOGO_WIDTH / VIDEO_FONT_WIDTH + 1;
row = BMP_LOGO_HEIGHT / VIDEO_FONT_HEIGHT + 1;
#else
col = 0;
- row = 0;
+ row = 1;
#endif
-
display_options_get_banner(false, buf, sizeof(buf));
- vidconsole_position_cursor(dev, col, 1);
+
+ banner_len = strlen(buf);
+ if (priv->cols <= (col + banner_len))
+ col = 0;
+
+ vidconsole_position_cursor(dev, col, row);
vidconsole_put_string(dev, buf);
- vidconsole_position_cursor(dev, 0, row);
+ if (priv->cols < banner_len)
+ row++;
+ vidconsole_position_cursor(dev, 0, row + 1);
}
#endif /* CONFIG_DM_VIDEO && !CONFIG_HIDE_LOGO_VERSION */
--
2.17.1
[PATCH 3/3] imx: mx6ul_14x14_evk: configure for 24bpp display
Before DM_VIDEO conversion this board used 24bpp
display configuration, so use it again.
Signed-off-by: Anatolij Gustschin
---
arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
b/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
index e9efdb9831..d0cbf79e33 100644
--- a/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
@@ -31,7 +31,7 @@
u-boot,dm-pre-reloc;
display0: display@0 {
- bits-per-pixel = <16>;
+ bits-per-pixel = <24>;
bus-width = <24>;
display-timings {
--
2.17.1
Re: [PATCH v7 00/10] Add support for loading main_r5fss0_core0
On 2/5/2020 2:45 PM, Lokesh Vutla wrote: On 04/02/20 12:06 PM, Keerthy wrote: This patch series enables mcu_r5fss0_core0 & main_r5fss0_core0. Tested for firmware loading and execution on J721e. I still see build error with multiple imx boards: === arm: + mx7dsabresd_qspi +arch/arm/mach-imx/imx_bootaux.c:18:32: error: 'get_host_mapping' defined but not used [-Werror=unused-function] + static const struct rproc_att *get_host_mapping(unsigned long auxcore) +^~~~ +cc1: all warnings being treated as errors +make[2]: *** [arch/arm/mach-imx/imx_bootaux.o] Error 1 +make[1]: *** [arch/arm/mach-imx] Error 2 +make: *** [sub-make] Error 2 Phew... Local builds did not catch for me. I will make sure i run the travis builds before i submit v8. Thanks and regards, Lokesh Changes in v7: * Added BSD-2 SPDX on lib/elf.c file. * Added Tom's Reviewed-by for the relevant patches. Changes in v6: * Fixed the imx build issue. Changes in v5: * Moved the fs_loader node under r5-common-proc-board-u-boot.dtsi * Added more information on the envnowhere patch. * Added help LIB_ELF option and removed user configurable description. Changes in v4: * Changed env variable names, config names and enhanced commit logs. Changes in v3: * Removed saving env in MMC and fixed env saving in SPL when nowhere option is set. Changes in v2: * Factored out all the generic elf handling functions under lib/elf.c Keerthy (10): env: nowhere: set default enviroment lib: elf: Move the generic elf loading/validating functions to lib arm: k3: Add support for loading non linux remote cores armv7R: K3: r5_mpu: Enable execute permission for MCU0 BTCM armv7R: K3: Add support for jumping to firmware arm: dts: k3-j721e-r5-u-boot: Add fs_loader node arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL include: configs: j721e_evm: Add env variables for mcu_r5fss0_core0 & main_r5fss0_core0 configs: j721e_evm_r5: Enable R5F remoteproc support configs: j721e_evm_r5_defconfig: Remove saving ENV in eMMC .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 27 ++ .../arm/dts/k3-j721e-r5-common-proc-board.dts | 2 + arch/arm/mach-imx/imx_bootaux.c | 46 arch/arm/mach-k3/common.c | 106 +++- arch/arm/mach-k3/common.h | 2 + arch/arm/mach-k3/j721e_init.c | 34 +++ arch/arm/mach-k3/r5_mpu.c | 4 +- cmd/Kconfig | 1 + cmd/elf.c | 229 configs/j721e_evm_r5_defconfig| 6 +- env/nowhere.c | 1 + include/configs/j721e_evm.h | 4 + include/elf.h | 4 + lib/Kconfig | 6 + lib/Makefile | 1 + lib/elf.c | 246 ++ 16 files changed, 428 insertions(+), 291 deletions(-) create mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi create mode 100644 lib/elf.c
[PATCH v2 2/2] pxe: Get default selection from board type if label matches
From: Frieder Schrempf
In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.
This is useful in combination with SPL that loads a FIT image with
U-Boot and multiple DTBs. SPL can detect the board and choose the
matching configuration in the FIT by using
board_fit_config_name_match().
Signed-off-by: Frieder Schrempf
---
Changes in v2:
* Don't use internal structs of menu, but instead call
menu_set_default_by_item_data_match() that does the iteration work.
---
cmd/pxe_utils.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 53af04d7dc..62a1ee310d 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
unsigned long menucfg)
return cfg;
}
+#ifdef CONFIG_OF_CONTROL
+int pxe_match_menu_label_with_str(void *data, void *str)
+{
+ struct pxe_label *label;
+
+ if (!data || !str)
+ return 0;
+
+ label = (struct pxe_label *)data;
+
+ if (strcmp(label->name, str) == 0)
+ return 1;
+
+ return 0;
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ const char *model;
+ char *key;
+ int ret;
+
+ model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+ if (!model)
+ return 0;
+
+ ret = menu_set_default_by_item_data_match(m,
+ pxe_match_menu_label_with_str, (void *)model, );
+ if (ret)
+ return ret;
+
+ printf("Menu entry %s fits detected board. " \
+ "Use as default selection...\n", key);
+
+ return 0;
+}
+#endif
+
/*
* Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
* menu code.
@@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
+* If OF_CONTROL is enabled and we don't have a default specified,
+* we try to use an entry that matches the board/model name as default.
*/
if (default_num) {
err = menu_default_set(m, default_num);
@@ -1269,6 +1311,11 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
printf("Missing default: %s\n", cfg->default_label);
}
+#ifdef CONFIG_OF_CONTROL
+ } else if (pxe_runtime_select_menu_default(m)) {
+ menu_destroy(m);
+ return NULL;
+#endif
}
return m;
--
2.17.1
[PATCH v2 1/2] menu: Add a function to set the default by matching the item data
From: Frieder Schrempf
In order to make it possible to auto select a default entry by
matching the data of the menu entries by an external matching
function, we add some helpers and expose the
menu_set_default_by_item_data_match() function.
Signed-off-by: Frieder Schrempf
---
Changes in v2:
* Keep the menu structs private and instead only expose one additional
function, that sets the default by calling an external matching
function on each entry.
* Change the title and commit message to reflect the changes.
---
common/menu.c | 40
include/menu.h | 3 +++
2 files changed, 43 insertions(+)
diff --git a/common/menu.c b/common/menu.c
index 7b66d199a9..3833b8a237 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -160,6 +160,46 @@ static inline struct menu_item *menu_item_by_key(struct
menu *m,
return menu_items_iter(m, menu_item_key_match, item_key);
}
+/*
+ * Find the first matching item, if any exists by calling a matching function
+ * on the items data field.
+ */
+static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
+ int match(void *, void *), void * extra)
+{
+ struct list_head *pos, *n;
+ struct menu_item *item;
+ int ret;
+
+ list_for_each_safe(pos, n, >items) {
+ item = list_entry(pos, struct menu_item, list);
+ if (item->key) {
+ ret = match(item->data, extra);
+ if (ret == 1)
+ return item;
+ }
+ }
+
+ return NULL;
+}
+
+/*
+ * Select the menus default entry based on matching the data field of the menu
+ * items by calling a matching function.
+ */
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra, char **key)
+{
+ struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
+
+ if (!item)
+ return -ENOENT;
+
+ *key = item->key;
+ m->default_item = item;
+ return 0;
+}
+
/*
* Set *choice to point to the default item's data, if any default item was
* set, and returns 1. If no default item was set, returns -ENOENT.
diff --git a/include/menu.h b/include/menu.h
index 2d227c20bd..0a8b41a905 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -18,6 +18,9 @@ int menu_item_add(struct menu *m, char *item_key, void
*item_data);
int menu_destroy(struct menu *m);
void menu_display_statusline(struct menu *m);
int menu_default_choice(struct menu *m, void **choice);
+int menu_set_default_by_item_data_match(struct menu *m,
+ int match(void *, void *), void *extra,
+ char **key);
/**
* menu_show() Show a boot menu
--
2.17.1
[PATCH v1] imx: imx8qm: enable relocation of fdt and initrd
Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x) from default environment which prevents relocation of FDT and initrd. Signed-off-by: Oliver Graute Cc: Stefano Babic Cc: Fabio Estevam Cc: Peng Fan Cc: Simon Glass Cc: Ye Li Cc: uboot-imx --- include/configs/imx8qm_rom7720.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/imx8qm_rom7720.h b/include/configs/imx8qm_rom7720.h index 865863eb7c..8beb65e96b 100644 --- a/include/configs/imx8qm_rom7720.h +++ b/include/configs/imx8qm_rom7720.h @@ -63,11 +63,9 @@ "panel=NULL\0" \ "console=ttyLP0\0" \ "fdt_addr=0x8300\0" \ - "fdt_high=0x\0" \ "boot_fdt=try\0" \ "fdt_file=imx8qm-rom7720-a1.dtb\0" \ "initrd_addr=0x8380\0" \ - "initrd_high=0x\0" \ "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \ "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \ "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \ -- 2.17.1
Re: [PATCH 1/2] menu: Make some parts of the menu available to other components
On 05.02.20 14:44, Frieder Schrempf wrote:
> Hi Simon,
>
> On 30.12.19 02:21, Simon Glass wrote:
>> Hi Schrempf,
>>
>> On Tue, 10 Dec 2019 at 08:47, Schrempf Frieder
>> wrote:
>>>
>>> From: Frieder Schrempf
>>>
>>> In order to iterate over the menu entries and match for a specific
>>> name in the pxe boot, we need to properly export the needed structs
>>> and functions.
>>>
>>> Signed-off-by: Frieder Schrempf
>>> ---
>>> common/menu.c | 31 +--
>>> include/menu.h | 34 +-
>>> 2 files changed, 34 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/common/menu.c b/common/menu.c
>>> index 7b66d199a9..82b03f17f7 100644
>>> --- a/common/menu.c
>>> +++ b/common/menu.c
>>> @@ -12,36 +12,7 @@
>>>
>>> #include "menu.h"
>>>
>>> -/*
>>> - * Internally, each item in a menu is represented by a struct
>>> menu_item.
>>> - *
>>> - * These items will be alloc'd and initialized by menu_item_add and
>>> destroyed
>>> - * by menu_item_destroy, and the consumer of the interface never
>>> sees that
>>> - * this struct is used at all.
>>> - */
>>> -struct menu_item {
>>> - char *key;
>>> - void *data;
>>> - struct list_head list;
>>> -};
>>>
>>> -/*
>>> - * The menu is composed of a list of items along with settings and
>>> callbacks
>>> - * provided by the user. An incomplete definition of this struct is
>>> available
>>> - * in menu.h, but the full definition is here to prevent consumers from
>>> - * relying on its contents.
>>> - */
>>> -struct menu {
>>> - struct menu_item *default_item;
>>> - int timeout;
>>> - char *title;
>>> - int prompt;
>>> - void (*item_data_print)(void *);
>>> - char *(*item_choice)(void *);
>>> - void *item_choice_data;
>>> - struct list_head items;
>>> - int item_cnt;
>>> -};
>>>
>>> /*
>>> * An iterator function for menu items. callback will be called for
>>> each item
>>> @@ -51,7 +22,7 @@ struct menu {
>>> * used for search type operations. It is also safe for callback to
>>> remove the
>>> * item from the list of items.
>>> */
>>> -static inline void *menu_items_iter(struct menu *m,
>>> +inline void *menu_items_iter(struct menu *m,
>>> void *(*callback)(struct menu *, struct menu_item *,
>>> void *),
>>> void *extra)
>>> {
>>> diff --git a/include/menu.h b/include/menu.h
>>> index 2d227c20bd..b3f8db87e4 100644
>>> --- a/include/menu.h
>>> +++ b/include/menu.h
>>> @@ -6,8 +6,40 @@
>>> #ifndef __MENU_H__
>>> #define __MENU_H__
>>>
>>> -struct menu;
>>> +/*
>>> + * Internally, each item in a menu is represented by a struct
>>> menu_item.
>>> + *
>>> + * These items will be alloc'd and initialized by menu_item_add and
>>> destroyed
>>> + * by menu_item_destroy, and the consumer of the interface never
>>> sees that
>>> + * this struct is used at all.
>>> + */
>>> +struct menu_item {
>>> + char *key;
>>> + void *data;
>>> + struct list_head list;
>>> +};
>>> +
>>> +/*
>>> + * The menu is composed of a list of items along with settings and
>>> callbacks
>>> + * provided by the user. An incomplete definition of this struct is
>>> available
>>> + * in menu.h, but the full definition is here to prevent consumers from
>>> + * relying on its contents.
>>
>> This comment doesn't seem to be true anymore.
>
> Right.
>
>>
>> Is it possible to add a function to get the info you need from the menu?
>
> Unfortunately I didn't find a better solution, that doesn't expose the
> menu structures. The problem is that menu and pxe are not separated
> cleanly as the menu items contain references to struct pxe_label.
Actually, on second thought, if I don't use the existing iterator
function in the menu code, I could keep all the menu code in menu.c and
expose just one additional function.
I'll send a v2 with this approach.
>
> If I would add a function to iterate over the items to the menu code, I
> would need to make struct pxe_label known to the menu code, which
> doesn't seem nice, either.
>
> Please let me know if you propose a different approach.
>
> Thanks,
> Frieder
>
>>
>>> + */
>>> +struct menu {
>>> + struct menu_item *default_item;
>>> + int timeout;
>>> + char *title;
>>> + int prompt;
>>> + void (*item_data_print)(void *);
>>> + char *(*item_choice)(void *);
>>> + void *item_choice_data;
>>> + struct list_head items;
>>> + int item_cnt;
>>> +};
>>>
>>> +void *menu_items_iter(struct menu *m,
>>> + void *(*callback)(struct menu *, struct menu_item *,
>>> void *),
>>> + void *extra);
>>> struct menu *menu_create(char *title, int timeout, int prompt,
>>> void (*item_data_print)(void *),
>>> char *(*item_choice)(void *),
>>> --
>>> 2.17.1
>>
>> Regards,
>> Simon
>>
Re: [RFC 1/2] hack to boot with 2020.01
On 04/02/20, Tom Rini wrote:
> On Mon, Feb 03, 2020 at 01:59:14PM +, Oliver Graute wrote:
> > As proposed here:
> >
> > https://lists.denx.de/pipermail/u-boot/2020-January/396749.html
> >
> > Both of my imx8qm boards (Advantech and Congatec) aren't booting
> > 2020.01 without this change. Whats the proper way to fix this on my side?
> >
> > ---
> > drivers/core/device.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/core/device.c b/drivers/core/device.c
> > index 4e037083a6..8358051d60 100644
> > --- a/drivers/core/device.c
> > +++ b/drivers/core/device.c
> > @@ -395,11 +395,8 @@ int device_probe(struct udevice *dev)
> >
> > if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
> > (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> > - !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
> > - ret = dev_power_domain_on(dev);
> > - if (ret)
> > - goto fail;
> > - }
> > + !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
> > + dev_power_domain_on(dev);
> >
> > ret = uclass_pre_probe_device(dev);
> > if (ret)
>
> Adding Lokesh and quoting him from
> http://patchwork.ozlabs.org/patch/1211325/
>
> "Can you check by not returning on failure here? If yes then check the
> power-domain/driver that is failing. If any driver doesn't expect core
> to enable power-domain then enable DM_FLAG_DEFAULT_PD_CTRL_OFF in the
> respective driver."
I tried, if I'am not returning on failure here. U-Boot boots well and
any logging shows me a return value 0 for dev_power_domain_on(). As soon
as I add the if statement with the goto fail U-Boot is stuck and I don't
see any msg on the uart neither return value for dev_power_domain_on.
So currently I can't tell which power-domain driver cause the issue.
Best Regards,
Oliver
Problem building u-boot
Hi, I'm a student working on ZedBoard FPGA, and I have to install a custom Linux on the ZedBoard. I have to build u-boot, so I'm following this Wiki : https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841973/Build+U-Boot In the third command I have to enter "Make", and I get this error : cc1: error: bad value (generic-armv7-a) for -mtune= switch cc1: note: valid arguments to -mtune= switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 generic Kbuild:43: recipe for target 'lib/asm-offsets.s' failed make[1]: *** [lib/asm-offsets.s] Error 1 Makefile:1579: recipe for target 'prepare0' failed make: *** [prepare0] Error 2 I don't understand this error and I don't know where is the problem. Also I didn't find the words "generic-armv7-a" or "-mtune= switch" in the makefile of the u-boot, or in /lib/asm-offsets.c . Could you help me? Sincerely, -- Olivier Berton; Etudiant Polytech Nantes Mail : olivier.bert...@etu.univ-nantes.fr Téléphone : 06 81 51 63 04
