Re: [U-Boot] [PATCH 003/126] dm: core: Drop a few early returns

[Bin Meng]

On Thu, Oct 3, 2019 at 8:47 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Two functions in this file return early for no good reason. Adjust the
> > code to match the standard DM style of returning 0 at the end of the
> > function on success.
> >
> > Oddly enough this save 12 bytes of code size on ARM.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/uclass.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 001/126] dm: core: Use U-Boot logging instead of pr_debug()

[Bin Meng]

On Thu, Oct 3, 2019 at 8:47 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > The pr_debug() functions do not response to setting the log level and in
> > fact have their own separate log level. Use U-Boot logging instead.
> >
> > Perhaps we should make these options redirect to log_debug(), etc.?
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/lists.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 009/126] dm: core: Call ofdata_to_platdata() with of-platdata

[Bin Meng]

On Fri, Oct 4, 2019 at 5:44 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present this function is never called when of-platdata is enabled since
> > we never have a device tree. However, this function is responsible for
> > copying over the of-platdata, so we must call it. Otherwise the probe()
> > method would have to be used.
> >
> > Correct this and fix the sandbox serial driver to not read from the device
> > tree and try to write to what is read-only platdata on some platforms.
> >
> > Fixes: 396e343b3d (dm: core: Allow binding a device from a live tree)
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/device.c| 3 ++-
> >  drivers/serial/sandbox.c | 2 ++
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 005/126] dm: core: Don't include ofnode functions with of-platdata

[Bin Meng]

On Thu, Oct 3, 2019 at 8:48 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > These functions cannot work with of-platdata since libfdt is not
> > available. At present when dev_read_...() functions are used it produces
> > error messages about ofnode which is confusing.
> >
> > Adjust the Makefile and header to produce an error message for the actual
> > dev_read...() function which is called. This makes it easier to see what
> > code needs to be converted for use with of-platdata.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/Makefile | 4 +++-
> >  include/dm/read.h | 3 +--
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 007/126] dm: test: Fix running of multiple test from command line

[Bin Meng]

On Fri, Oct 4, 2019 at 5:44 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present when multiple 'ut dm' commands are executed, all but the first
> > is run with a flat tree, even if live tree is enabled. This is because the
> > live tree node pointer is set to NULL and never restored.
> >
> > This does not affect normal test running, which just runs all the test in
> > one go, but can be confusing when several individual tests are run during
> > the same U-Boot run.
> >
> > Correct this by restoring the pointer.
> >
> > Fixes: c166c47ba3 (dm: test: Add support for running tests with livetree)
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  test/dm/test-main.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 004/126] dm: core: Add documentation on how to debug driver model

[Bin Meng]

On Thu, Oct 3, 2019 at 8:47 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Sometimes devices don't appear and it can be confusing. Add a few notes to
> > help with this situation.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  doc/driver-model/debugging.rst | 62 ++
>
> missed updating index.rst to include this doc.
>
> I can fix this when applying.
>
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 doc/driver-model/debugging.rst
> >
> > diff --git a/doc/driver-model/debugging.rst b/doc/driver-model/debugging.rst
> > new file mode 100644
> > index 000..9711dd6d653
> > --- /dev/null
> > +++ b/doc/driver-model/debugging.rst
> > @@ -0,0 +1,62 @@
> > +.. SPDX-License-Identifier: GPL-2.0+
> > +.. sectionauthor:: Simon Glass 
> > +
> > +Debugging driver model
> > +==
> > +
> > +This document aims to provide help when you cannot work out why driver 
> > model is
> > +not doing what you expect.
> > +
> > +
> > +Useful techniques in general
> > +
> > +
> > +Here are some useful debugging features generally.
> > +
> > +   - If you are writing a new feature, consider doing it in sandbox 
> > instead of
> > + on your board. Sandbox has no limits, allows each debugging (e.g. 
> > gdb) and
>
> easy debugging
>
> > + you can writing emulators for most common devices.
>
> write

Fixed these issues, and

>
> > +   - Put '#define DEBUG' at the top of a file, to activate all the debug() 
> > and
> > + log_debug() statements in that file.
> > +   - Where logging is used, change the logging level, e.g. in SPL with
> > + CONFIG_SPL_LOG_MAX_LEVEL=7 (which is LOGL_DEBUG) and
> > + CONFIG_LOG_DEFAULT_LEVEL=7
> > +   - Where logging of return values is implemented with log_msg_ret(), set
> > + CONFIG_LOG_ERROR_RETURN=y to see exactly where the error is happening
> > +   - Make sure you have a debug UART enabled - see CONFIG_DEBUG_UART. With 
> > this
> > + you can get serial output (printf(), etc.) before the serial driver is
> > + running.
> > +   - Use a JTAG emulator to set breakpoints and single-step through code
> > +
> > +Not that most of these increase code/data size somewhat when enabled.
> > +
> > +
> > +Failure to locate a device
> > +--
> > +
> > +Let's say you have uclass_first_device_err() and it is not finding 
> > anything.
> > +
> > +If it is returning an error, then that gives you a clue. Look up 
> > linux/errno.h
> > +to see errors. Common ones are:
> > +
> > +   - -ENOMEM which indicates that memory is short. If it happens in SPL or
> > + before relocation in U-Boot, check CONFIG_SPL_SYS_MALLOC_F_LEN and
> > + CONFIG_SYS_MALLOC_F_LEN as they may need to be larger. Add '#define 
> > DEBUG'
> > + at the very top of malloc_simple.c to get an idea of where your 
> > memory is
> > + going.
> > +   - -EINVAL which typically indicates that something was missing or wrong 
> > in
> > + the device tree node. Check that everything is correct and look at the
> > + ofdata_to_platdata() method in the driver.
> > +
> > +If there is no error, you should check if the device is actually bound. 
> > Call
> > +dm_dump_all() just before you locate the device to make sure it exists.
> > +
> > +If it does not exist, check your device tree compatible strings match up 
> > with
> > +what the driver expects (in the struct udevice_id array).
> > +
> > +If you are using of-platdata (e.g. CONFIG_SPL_OF_PLATDATA), check that the
> > +driver name is the same as the first compatible string in the device tree 
> > (with
> > +invalid-variable characters converted to underscore).
> > +
> > +If you are really stuck, #define DEBUG at the top of lists.c should show 
> > you
> > +what is going on.
> > --
>
> Other than that,
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 008/126] dm: test: Don't fail when tests are skipped due to build

[Bin Meng]

On Fri, Oct 4, 2019 at 5:44 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present tests that are marked as only for livetree fail when executed
> > on sandbox_flattree. They cannot actually be executed, but we should not
> > resport them as 'not found', since this causes errors. Instead, they
> > should be silently skipped.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  test/dm/test-main.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 013/126] dm: test: Correct a stray backslash in dm_test_destroy()

[Bin Meng]

On Fri, Oct 4, 2019 at 5:44 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > This should perhaps be a period but it is not necessary. Remove it.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  test/dm/test-main.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/test/dm/test-main.c b/test/dm/test-main.c
> > index 74f77ccc849..c944ab9c5f2 100644
> > --- a/test/dm/test-main.c
> > +++ b/test/dm/test-main.c
> > @@ -64,7 +64,7 @@ static int dm_test_destroy(struct unit_test_state *uts)
> >
> > /*
> >  * If the uclass doesn't exist we don't want to create it. 
> > So
> > -* check that here before we call uclass_find_device()/
> > +* check that here before we call uclass_find_device()
>
> I tend to use a period since it's a complete sentence.

Added the ending period, reworded the commit message, and

>
> >  */
> > uc = uclass_find(id);
> > if (!uc)
> > --
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 011/126] dm: core: Correct the return value for uclass_find_first_device()

[Bin Meng]

On Fri, Oct 4, 2019 at 5:44 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > This function returns -ENODEV when there is no device. This is
> > inconsistent with other functions, such as uclass_find_next_device(),
> > which returns 0.
> >
> > Update it and tidy up the incorrect '-1' values in the comments.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/core/uclass.c| 2 +-
> >  include/dm/uclass-internal.h | 4 ++--
> >  test/dm/core.c   | 3 +--
> >  3 files changed, 4 insertions(+), 5 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 015/126] sandbox: spmi: Add ranges property for address translation

[Bin Meng]

On Sat, Oct 5, 2019 at 9:58 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present address translation does not work since there is no ranges
> > property in the spmi nodes. Add empty ranges properties and a little more
> > logging so that this shows the error:
> >
> >/tmp/b/sandbox/u-boot -d /tmp/b/sandbox/arch/sandbox/dts/test.dtb \
> > -c "ut dm spmi_access_peripheral" -L7 -v
> >...
> >pm8916_gpio_probe() bad address: returning err=-22
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/dts/test.dts  |  2 ++
> >  drivers/gpio/pm8916_gpio.c | 12 ++--
> >  2 files changed, 8 insertions(+), 6 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 012/126] dm: core: Add device_foreach_child()

[Bin Meng]

On Fri, Oct 4, 2019 at 5:44 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > We have a 'safe' version of this function but sometimes it is not needed.
> > Add a normal version too and update a few places that can use it.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/arm/mach-uniphier/pinctrl-glue.c | 4 ++--
> >  drivers/block/blk-uclass.c| 4 ++--
> >  include/dm/device.h   | 9 +
> >  3 files changed, 13 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 016/126] sandbox: mmc: Fix up MMC emulator for valgrind

[Bin Meng]

On Sat, Oct 5, 2019 at 9:58 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present running sandbox with valgrind produces some warnings due to the
> > MMC emulator not filling in all the expected fields. Fix it.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/mmc/sandbox_mmc.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/mmc/sandbox_mmc.c b/drivers/mmc/sandbox_mmc.c
> > index 2fa7d8c3dcd..7ca8da0946c 100644
> > --- a/drivers/mmc/sandbox_mmc.c
> > +++ b/drivers/mmc/sandbox_mmc.c
> > @@ -27,6 +27,7 @@ static int sandbox_mmc_send_cmd(struct udevice *dev, 
> > struct mmc_cmd *cmd,
> >  {
> > switch (cmd->cmdidx) {
> > case MMC_CMD_ALL_SEND_CID:
> > +   memset(cmd->response, '\0', 16);
>
> sizeof(cmd->response)

Changed to use sizeof(), and

>
> > break;
> > case SD_CMD_SEND_RELATIVE_ADDR:
> > cmd->response[0] = 0 << 16; /* mmc->rca */
> > @@ -43,11 +44,14 @@ static int sandbox_mmc_send_cmd(struct udevice *dev, 
> > struct mmc_cmd *cmd,
> > case MMC_CMD_SEND_CSD:
> > cmd->response[0] = 0;
> > cmd->response[1] = 10 << 16;/* 1 << block_len */
> > +   cmd->response[2] = 0;
> > +   cmd->response[3] = 0;
> > break;
> > case SD_CMD_SWITCH_FUNC: {
> > if (!data)
> > break;
> > u32 *resp = (u32 *)data->dest;
> > +   resp[3] = 0;
> > resp[7] = cpu_to_be32(SD_HIGHSPEED_BUSY);
> > if ((cmd->cmdarg & 0xF) == UHS_SDR12_BUS_SPEED)
> > resp[4] = (cmd->cmdarg & 0xF) << 24;
> > --
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 018/126] sandbox: Add support for clrsetio_32() and friends

[Bin Meng]

On Sat, Oct 5, 2019 at 10:01 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > These functions are available on x86 but not sandbox. They are useful
> > shortcuts and clarify the code, so add them to sandbox.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/include/asm/io.h | 42 ++-
> >  arch/sandbox/lib/pci_io.c | 12 +-
> >  2 files changed, 42 insertions(+), 12 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 019/126] sandbox: swap_case: Use statics where possible

[Bin Meng]

On Sat, Oct 5, 2019 at 10:01 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Some functions and a struct should be marked static since they are not
> > used outside this file. Update them.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/misc/swap_case.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 020/126] sandbox: pci: Drop the get_devfn() method

[Bin Meng]

On Sat, Oct 5, 2019 at 10:01 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > This method is not used anymore since the bus/device/function of PCI
> > devices can be obtained from their (parent's per-child) platform data.
> > Drop it.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/misc/swap_case.c | 8 
> >  include/pci.h| 7 ---
> >  2 files changed, 15 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 017/126] sandbox: Rename PCI ID for swap_case to be more specific

[Bin Meng]

On Sat, Oct 5, 2019 at 9:58 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Rename this ID to SANDBOX_PCI_SWAP_CASE_EMUL_ID since it is more
> > descriptive and allows us to add new PCI emulators without any conflict or
> > confusion.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/include/asm/test.h | 2 +-
> >  drivers/misc/swap_case.c| 5 +++--
> >  test/dm/pci.c   | 6 +++---
> >  3 files changed, 7 insertions(+), 6 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 022/126] sandbox: pci: Move pci_offset_to_barnum() to pci.h

[Bin Meng]

On Sat, Oct 5, 2019 at 10:17 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > This function is useful in PCI emulators. More it into the header file to
> > avoid duplicating it in other drivers.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/misc/swap_case.c | 7 ++-
> >  include/pci.h| 4 
> >  2 files changed, 6 insertions(+), 5 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 023/126] sandbox: Add a -T flag to use the test device tree

[Bin Meng]

On Sat, Oct 5, 2019 at 11:13 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > U-Boot already supports using -D to indicate that it should use the normal
> > device tree. It is sometimes useful to run with the test device tree, e.g.
> > when running a test. Add a -T option for this along with some
> > documentation.
> >
> > It can be used like this:
> >
> >/tmp/b/sandbox/u-boot -T -c "ut dm pci_busdev"
> >
> > (this will use /tmp/b/sandbox/arch/sandbox/dts/test.dtb as the DT)
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/cpu/start.c | 25 +
> >  doc/arch/sandbox.rst |  9 +
> >  2 files changed, 34 insertions(+)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 024/126] sandbox: pci: Increase the memory space

[Bin Meng]

On Sat, Oct 5, 2019 at 11:14 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Increase the memory space so we can support the p2sb bus which needs
> > multiples of 1MB.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/dts/test.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 025/126] sandbox: Allow use of real I/O with readl(), etc.

[Bin Meng]

On Sat, Oct 5, 2019 at 11:30 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present these functions are stubbed out. For more comprehensive testing
> > with PCI devices it is useful to be able to fully emulate I/O access. Add
> > simple implementations for these.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/cpu/cpu.c   | 51 
> >  arch/sandbox/include/asm/io.h| 27 +++--
> >  arch/sandbox/include/asm/state.h |  1 +
> >  drivers/nvme/nvme.h  |  4 +--
> >  4 files changed, 72 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
> > index fdfb209f77d..f3af88d79e9 100644
> > --- a/arch/sandbox/cpu/cpu.c
> > +++ b/arch/sandbox/cpu/cpu.c
> > @@ -225,6 +225,57 @@ phys_addr_t map_to_sysmem(const void *ptr)
> > return mentry->tag;
> >  }
> >
> > +unsigned int sandbox_read(const void *addr, enum sandboxio_size_t size)
> > +{
> > +   struct sandbox_state *state = state_get_current();
> > +
> > +   if (!state->allow_memio)
> > +   return 0;
> > +
> > +   switch (size) {
> > +   case SB_SIZE_8:
> > +   return *(u8 *)addr;
> > +   case SB_SIZE_16:
> > +   return *(u16 *)addr;
> > +   case SB_SIZE_32:
> > +   return *(u32 *)addr;
> > +   case SB_SIZE_64:
> > +   return *(u64 *)addr;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +void sandbox_write(void *addr, unsigned int val, enum sandboxio_size_t 
> > size)
>
> const void *addr

Fixed this, and

>
> > +{
> > +   struct sandbox_state *state = state_get_current();
> > +
> > +   if (!state->allow_memio)
> > +   return;
> > +
> > +   switch (size) {
> > +   case SB_SIZE_8:
> > +   *(u8 *)addr = val;
> > +   break;
> > +   case SB_SIZE_16:
> > +   *(u16 *)addr = val;
> > +   break;
> > +   case SB_SIZE_32:
> > +   *(u32 *)addr = val;
> > +   break;
> > +   case SB_SIZE_64:
> > +   *(u64 *)addr = val;
> > +   break;
> > +   }
> > +}
> > +
> > +void sandbox_set_enable_memio(bool enable)
> > +{
> > +   struct sandbox_state *state = state_get_current();
> > +
> > +   state->allow_memio = enable;
> > +}
> > +
> >  void sandbox_set_enable_pci_map(int enable)
> >  {
> > enable_pci_map = enable;
> > diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
> > index 481787b516b..2bbaff26a61 100644
> > --- a/arch/sandbox/include/asm/io.h
> > +++ b/arch/sandbox/include/asm/io.h
> > @@ -6,6 +6,13 @@
> >  #ifndef __SANDBOX_ASM_IO_H
> >  #define __SANDBOX_ASM_IO_H
> >
> > +enum sandboxio_size_t {
> > +   SB_SIZE_8,
> > +   SB_SIZE_16,
> > +   SB_SIZE_32,
> > +   SB_SIZE_64,
> > +};
> > +
> >  void *phys_to_virt(phys_addr_t paddr);
> >  #define phys_to_virt phys_to_virt
> >
> > @@ -38,18 +45,20 @@ static inline void unmap_sysmem(const void *vaddr)
> >  /* Map from a pointer to our RAM buffer */
> >  phys_addr_t map_to_sysmem(const void *ptr);
> >
> > -/* Define nops for sandbox I/O access */
> > -#define readb(addr) ((void)addr, 0)
> > -#define readw(addr) ((void)addr, 0)
> > -#define readl(addr) ((void)addr, 0)
> > +unsigned int sandbox_read(const void *addr, enum sandboxio_size_t size);
> > +void sandbox_write(void *addr, unsigned int val, enum sandboxio_size_t 
> > size);
> > +
> > +#define readb(addr) sandbox_read(addr, SB_SIZE_8)
> > +#define readw(addr) sandbox_read(addr, SB_SIZE_16)
> > +#define readl(addr) sandbox_read(addr, SB_SIZE_32)
> >  #ifdef CONFIG_SANDBOX64
> > -#define readq(addr) ((void)addr, 0)
> > +#define readq(addr) sandbox_read(addr, SB_SIZE_64)
> >  #endif
> > -#define writeb(v, addr) ((void)addr)
> > -#define writew(v, addr) ((void)addr)
> > -#define writel(v, addr) ((void)addr)
> > +#define writeb(v, addr) sandbox_write(addr, v, SB_SIZE_8)
> > +#define writew(v, addr) sandbox_write(addr, v, SB_SIZE_16)
> > +#define writel(v, addr) sandbox_write(addr, v, SB_SIZE_32)
> >  #ifdef CONFIG_SANDBOX64
> > -#define writeq(v, addr) ((void)addr)
> > +#define writeq(v, addr) sandbox_write(addr, v, SB_SIZE_64)
> >  #endif
> >
> >  /*
> > diff --git a/arch/sandbox/include/asm/state.h 
> > b/arch/sandbox/include/asm/state.h
> > index 2d773d3fa6b..ad3e94beb9a 100644
> > --- a/arch/sandbox/include/asm/state.h
> > +++ b/arch/sandbox/include/asm/state.h
> > @@ -102,6 +102,7 @@ struct sandbox_state {
> > ulong next_tag; /* Next address tag to allocate */
> > struct list_head mapmem_head;   /* struct sandbox_mapmem_entry */
> > bool hwspinlock;/* Hardware Spinlock status */
> > +   bool allow_memio;   /* Allow readl() etc. to work */
> >
> > /*
> >  * This struct is getting large.
> > diff --git a/drivers/nvme/nvme.h b/drivers/nvme/

Re: [U-Boot] [PATCH 026/126] pci: sandbox: Move the emulators into their own node

[Bin Meng]

On Sat, Oct 5, 2019 at 1:03 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Sandbox i2c works using emulation drivers which are currently children of
>
> pci
>
> > the i2c device:
>
> pci

Fixed these, and

>
> >
> > pci-controller {
> > pci@1f,0 {
> > compatible = "pci-generic";
> > reg = <0xf800 0 0 0 0>;
> > emul@1f,0 {
> > compatible = "sandbox,swap-case";
> > };
> > };
> > };
> >
> > In this case the emulation device is attached to pci device on address
> > f800 (device 1f, function 0) and provides the swap-case functionality.
> >
> > However this is not ideal, since every device on a PCI bus has a child
> > device. This is only really the case for sandbox, but we want to avoid
> > special-case code for sandbox.
> >
> > Worse, child devices cannot be probed before their parents. This forces
> > us to use 'find' rather than 'get' to obtain the emulator device. In fact
> > the emulator devices are never probed. There is code in
> > sandbox_pci_emul_post_probe() which tries to track when emulators are
> > active, but at present this does not work.
> >
> > A better approach seems to be to add a separate node elsewhere in the
> > device tree, an 'emulation parent'. This could be given a bogus address
> > (such as -1) to hide the emulators away from the 'pci' command, but it
> > seems better to keep it at the root node to avoid such hacks.
> >
> > Then we can use a phandle to point from the  evice to the correct
>
> typo: device

Fixed this, and

>
>
> > emulator, and only on sandbox. The code to find an emulator does not
> > interfere with normal pci operation.
> >
> > Add a new UCLASS_PCI_EMUL_PARENT uclass which allows finding an emulator
> > given a bus, and finding a bus given an emulator. Update the existing
> > device trees and the code for finding an emulator.
> >
> > This brings PCI emulators more into line with I2C.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/dts/sandbox.dtsi | 11 +++---
> >  arch/sandbox/dts/test.dts | 38 +++
> >  doc/driver-model/pci-info.rst | 23 +++--
> >  drivers/pci/pci-emul-uclass.c | 37 --
> >  include/dm/uclass-id.h|  1 +
> >  5 files changed, 77 insertions(+), 33 deletions(-)
> >
> > diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
> > index c6d5650c20b..f09bc70b0da 100644
> > --- a/arch/sandbox/dts/sandbox.dtsi
> > +++ b/arch/sandbox/dts/sandbox.dtsi
> > @@ -103,9 +103,14 @@
> > pci@1f,0 {
> > compatible = "pci-generic";
> > reg = <0xf800 0 0 0 0>;
> > -   emul@1f,0 {
> > -   compatible = "sandbox,swap-case";
> > -   };
> > +   sandbox,emul = <&swap_case_emul>;
> > +   };
> > +   };
> > +
> > +   emul {
> > +   compatible = "sandbox,pci-emul-parent";
> > +   swap_case_emul: emul@1f,0 {
> > +   compatible = "sandbox,swap-case";
> > };
> > };
> >
> > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > index 5669ede7051..a2e75981f0b 100644
> > --- a/arch/sandbox/dts/test.dts
> > +++ b/arch/sandbox/dts/test.dts
> > @@ -452,24 +452,31 @@
> > pci@0,0 {
> > compatible = "pci-generic";
> > reg = <0x 0 0 0 0>;
> > -   emul@0,0 {
> > -   compatible = "sandbox,swap-case";
> > -   };
> > +   sandbox,emul = <&swap_case_emul0>;
>
> &swap_case_emul0_0
>
> > };
> > pci@1,0 {
> > compatible = "pci-generic";
> > reg = <0x0800 0 0 0 0>;
> > -   emul@0,0 {
> > -   compatible = "sandbox,swap-case";
> > -   use-ea;
> > -   };
> > +   sandbox,emul = <&swap_case_emul1>;
>
> &swap_case_emul0_1
>
> > };
> > pci@1f,0 {
> > compatible = "pci-generic";
> > reg = <0xf800 0 0 0 0>;
> > -   emul@1f,0 {
> > -   compatible = "sandbox,swap-case";
> > -   };
> > +   sandbox,emul = <&swap_case_emul1f>;
>
> &swap_case_emul0_1f

Fixed the label names, and

>
> > +   };
> > +   };
> > +
> > +   pci-emul0 {
> > +   compatible = "sandbox,pci-emul-parent";
> > +   swap_case_emul0: emul@0,0 {
> > +   compatible = "sandbox,swap-case";
> 

Re: [U-Boot] [PATCH 028/126] pci: Show the result of binding a device

[Bin Meng]

On Sat, Oct 5, 2019 at 1:03 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Update the debugging info a little to show the result of trying to bind
> > a PCI device.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/pci/pci-uclass.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 027/126] pci: sandbox: Probe PCI emulation devices when used

[Bin Meng]

On Sat, Oct 5, 2019 at 1:03 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present PCI emulation devices are not probed before use, since they
> > used to be children of the device that used them, and children cannot be
> > probed before their parents.
> >
> > Now that PCI emulation devices are attached to the root node, we can
> > simply probe them, and avoid using the internal function.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/pci/pci-emul-uclass.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

Rebased the patch against u-boot-x86/next to get it applied cleanly, and

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 030/126] pci: Correct 'specifified' and 'Plese' typos

[Bin Meng]

On Sat, Oct 5, 2019 at 1:03 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Fix these spelling errors the header file and documentation.
>
> in the header
>
> >
> > Fix a small typo in the PCI documentation.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  doc/driver-model/pci-info.rst | 2 +-
> >  include/pci.h | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 029/126] pci: Disable autoconfig in SPL

[Bin Meng]

On Sat, Oct 5, 2019 at 1:03 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present U-Boot runs autoconfig in SPL but this is best left to U-Boot
> > proper. For TPL and SPL we can normally used fixed BARs and save code size
> > and time.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/pci/pci-uclass.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Baruch Siach]

Hi Adam,

(Adding MMC and i.MX maintainers to Cc)

On Fri, Sep 27 2019, Adam Ford wrote:
> On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  wrote:
>>
>> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
>> > Hi Vagrant,
>> >
>> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  
>> > wrote:
>> > >
>> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
>> > > u-boot.img from MMC:
>> > >
>> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 -
>> > > 08:03:23 +)
>> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
>> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
>> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19
>> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices
>> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
>> >
>> > Thanks for reporting this issue.
>> >
>> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
>> > and Baruch on Cc.
>>
>> Works after reverting the following commit.
>>
> I am going to argue that making the board comply with DM_MMC is why I
> needed to make the patch, because when booting from MMC2, the function
> was returning MMC1 which was clearly not the boot source.
>
> If the boards that fail accept MMC2 as a response when booting from
> MMC2, that seems like a bug on the indvidual boards.  Instead they
> should setup their boot sequence to configure MMC2 when MMC2 is the
> boot source.  Instead, it seems like some boards are configuring MMC1
> with MMC2 info which only prolongs the conversion to DM_MMC.
>
> If we revert the patch, then boards like imx6_logic who rely solely on
> device tree and DM_MMC for booting will have to manually override the
> MMC driver in order to boot from MMC2, and that seems like a step
> backwards.  I would argue that this board should migrate to DM_MMC and
> use the device tree to boot, and the problem should go away.

I started working on migration to DM_MMC as you suggested. Unfortunately
I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
the general case.

The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
and their corresponding DT representation.

However, the 'index' parameter in uclass_get_device() that is set
according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
(see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
optional eMMC. When booting from SD card, uclass_get_device(), returns
-ENODEV when eMMC is not available, or the eMMC device when it is
available. In both cases, boot fails.

In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?

How is all that intended to work?

Aren't other i.MX boards impacted by this commit?

Thanks,
baruch

>> 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit
>> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a
>> Author: Adam Ford 
>> Date:   Thu May 23 14:11:30 2019 -0500
>>
>> spl: imx6: Let spl_boot_device return USDHC1 or USDHC2
>>
>> Currently, when the spl_boot_device checks the boot device, it
>> will only return MMC1 when it's either sd or eMMC regardless
>> of whether or not it's MMC1 or MMC2.  This is a problem when
>> booting from MMC2 if MMC isn't being manually configured like in
>> the DM_SPL case with SPL_OF_CONTROL.
>>
>> This patch will check the register and return either MMC1 or MMC2.
>>
>> Signed-off-by: Adam Ford 
>>
>>  arch/arm/mach-imx/spl.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)

--
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] gitlab-ci: fix typo 'plaforms'

[Heinrich Schuchardt]

%s/plaforms/platforms/g

Signed-off-by: Heinrich Schuchardt 
---

 .gitlab-ci.yml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index a1c5b4fc76..0c4343468d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -59,7 +59,7 @@ stages:
 fi;
   fi;

-build all 32bit ARM plaforms:
+build all 32bit ARM platforms:
   tags: [ 'all' ]
   stage: world build
   script:
@@ -70,7 +70,7 @@ build all 32bit ARM plaforms:
exit $ret;
  fi;

-build all 64bit ARM plaforms:
+build all 64bit ARM platforms:
   tags: [ 'all' ]
   stage: world build
   script:
@@ -84,7 +84,7 @@ build all 64bit ARM plaforms:
exit $ret;
  fi;

-build all PowerPC plaforms:
+build all PowerPC platforms:
   tags: [ 'all' ]
   stage: world build
   script:
@@ -95,7 +95,7 @@ build all PowerPC plaforms:
exit $ret;
  fi;

-build all other plaforms:
+build all other platforms:
   tags: [ 'all' ]
   stage: world build
   script:
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gitlab-ci: fix typo 'plaforms'

[Bin Meng]

On Sun, Oct 6, 2019 at 6:26 PM Heinrich Schuchardt  wrote:
>
> %s/plaforms/platforms/g
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>
>  .gitlab-ci.yml | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 031/126] pci: Add more debug detail when resources are exhausted

[Bin Meng]

On Sat, Oct 5, 2019 at 9:12 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > If PCI auto-config runs out of memory, show a few more details to help
> > diagnose the problem.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/pci/pci_auto_common.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 034/126] serial: ns16550: Add a PCI device/function field

[Bin Meng]

On Sat, Oct 5, 2019 at 9:12 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > When this UART is used early in boot (before PCI is set up) it is
> > convenient to store the PCI BDF of the UART so that it can be manually
> > configured. This is useful when it is used as a debug UART, for example.
> >
> > Add a new field to hold this information, so that drivers can simply use
> > the existing platform data.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  include/ns16550.h | 4 
> >  1 file changed, 4 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 032/126] pci: Show a message if PCI autoconfig fails

[Bin Meng]

On Sat, Oct 5, 2019 at 9:12 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present this fails silently which can be confusing since some devices
> > on the PCI bus may not work correctly. Show a message in this case
>
> nits: missing . after case

Fixed, and

>
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/pci/pci_auto.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
> > index 1a3bf708347..7755ffb6fa2 100644
> > --- a/drivers/pci/pci_auto.c
> > +++ b/drivers/pci/pci_auto.c
> > @@ -39,6 +39,8 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
> > bars_num,
> >
> > for (bar = PCI_BASE_ADDRESS_0;
> >  bar < PCI_BASE_ADDRESS_0 + (bars_num * 4); bar += 4) {
> > +   int ret = 0;
> > +
> > /* Tickle the BAR and get the response */
> > if (!enum_only)
> > dm_pci_write_config32(dev, bar, 0x);
> > @@ -97,9 +99,13 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
> > bars_num,
> >   (unsigned long long)bar_size);
> > }
> >
> > -   if (!enum_only && pciauto_region_allocate(bar_res, bar_size,
> > - &bar_value,
> > - found_mem64) == 
> > 0) {
> > +   if (!enum_only) {
> > +   ret = pciauto_region_allocate(bar_res, bar_size,
> > + &bar_value, 
> > found_mem64);
> > +   if (ret)
> > +   printf("PCI: Failed autoconfig bar %x", 
> > bar);
>
> nits: should have a '\n'

Added a '\n', and

>
> > +   }
> > +   if (!enum_only && !ret) {
> > /* Write it out and update our limit */
> > dm_pci_write_config32(dev, bar, (u32)bar_value);
> >
> > --
>
> Other than above,
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 033/126] dm: pci: Add a function to read a PCI BAR

[Bin Meng]

On Sat, Oct 5, 2019 at 9:12 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present PCI address transaction is not supported so drivers must
> > manually read the correct BAR after reading the device tree info. The
> > ns16550 has a suitable implementation, so move this code into the core
> > DM support.
> >
> > Note that there is no live-tree equivalent at present.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/sandbox/dts/test.dts |  7 --
> >  drivers/core/fdtaddr.c| 33 
> >  drivers/core/read.c   | 11 ++
> >  drivers/serial/ns16550.c  | 31 +--
> >  include/dm/fdtaddr.h  |  8 +++
> >  include/dm/read.h | 25 ++
> >  test/dm/pci.c | 45 +++
> >  7 files changed, 128 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > index a2e75981f0b..8733e0d7e19 100644
> > --- a/arch/sandbox/dts/test.dts
> > +++ b/arch/sandbox/dts/test.dts
> > @@ -456,12 +456,15 @@
> > };
> > pci@1,0 {
> > compatible = "pci-generic";
> > -   reg = <0x0800 0 0 0 0>;
> > +   /* BAR0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
>
> reg 0
>
> > +   reg = <0x02000814 0 0 0 0
> > +   0x0100f810 0 0 0 0>;
>
> it should be 0x01000810, and should have a similar comment like reg 0
>
> > sandbox,emul = <&swap_case_emul1>;
> > };
> > pci@1f,0 {
> > compatible = "pci-generic";
> > -   reg = <0xf800 0 0 0 0>;
> > +   /* BAR1 is at 0x10, using FDT_PCI_SPACE_IO */
>
> reg 0

Corrected the above comments, and

>
> > +   reg = <0x0100f810 0 0 0 0>;
> > sandbox,emul = <&swap_case_emul1f>;
> > };
> > };
> > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > index 6850003a287..c9a941116a3 100644
> > --- a/drivers/core/fdtaddr.c
> > +++ b/drivers/core/fdtaddr.c
> > @@ -190,3 +190,36 @@ void *devfdt_map_physmem(struct udevice *dev, unsigned 
> > long size)
> >
> > return map_physmem(addr, size, MAP_NOCACHE);
> >  }
> > +
> > +fdt_addr_t devfdt_get_addr_pci(struct udevice *dev)
> > +{
> > +   ulong addr;
> > +
> > +   addr = devfdt_get_addr(dev);
> > +   if (CONFIG_IS_ENABLED(PCI) && IS_ENABLED(CONFIG_DM_PCI) &&
> > +   addr == FDT_ADDR_T_NONE) {
> > +   struct fdt_pci_addr pci_addr;
> > +   u32 bar;
> > +   int ret;
> > +
> > +   ret = fdtdec_get_pci_addr(gd->fdt_blob,
> > + dev_of_offset(dev),
> > + FDT_PCI_SPACE_MEM32, "reg",
> > + &pci_addr);
> > +   if (ret) {
> > +   /* try if there is any i/o-mapped register */
> > +   ret = fdtdec_get_pci_addr(gd->fdt_blob,
> > + dev_of_offset(dev),
> > + FDT_PCI_SPACE_IO, "reg",
> > + &pci_addr);
> > +   if (ret)
> > +   return FDT_ADDR_T_NONE;
> > +   }
> > +   ret = fdtdec_get_pci_bar32(dev, &pci_addr, &bar);
> > +   if (ret)
> > +   return FDT_ADDR_T_NONE;
> > +   addr = bar;
> > +   }
> > +
> > +   return addr;
> > +}
> > diff --git a/drivers/core/read.c b/drivers/core/read.c
> > index fb3dcd9a790..9602e52d1b1 100644
> > --- a/drivers/core/read.c
> > +++ b/drivers/core/read.c
> > @@ -307,3 +307,14 @@ int dev_read_alias_highest_id(const char *stem)
> >
> > return fdtdec_get_alias_highest_id(gd->fdt_blob, stem);
> >  }
> > +
> > +fdt_addr_t dev_read_addr_pci(struct udevice *dev)
> > +{
> > +   ulong addr;
> > +
> > +   addr = dev_read_addr(dev);
> > +   if (addr == FDT_ADDR_T_NONE && !of_live_active())
> > +   addr = devfdt_get_addr_pci(dev);
> > +
> > +   return addr;
> > +}
> > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> > index 01f334938ea..754b6e99215 100644
> > --- a/drivers/serial/ns16550.c
> > +++ b/drivers/serial/ns16550.c
> > @@ -440,36 +440,7 @@ int ns16550_serial_ofdata_to_platdata(struct udevice 
> > *dev)
> > int err;
> >
> > /* try Processor Local Bus device first */
> > -   addr = dev_read_addr(dev);
> > -#if CONFIG_IS_ENABLED(PCI) && defined(CONFIG_DM_PCI)
> > -   if (addr == FDT_ADDR_T_NONE) {
> > -   /* then try pci device */
> > -   struct fdt_pci_addr pci_addr;
> > -   u32 bar;
> 

Re: [U-Boot] [PATCH 037/126] binman: Handle reading data for end-at-4gb sections

[Bin Meng]

On Sat, Oct 5, 2019 at 10:42 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Some x86 sections have special offsets which currently result in empty
> > data being returned from the 'extract' command. Fix this by taking account
> > of the skip-at-start property.
> >
> > Add a little more debugging while we are here.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/binman/entry.py |  6 --
> >  tools/binman/etype/section.py | 16 +---
> >  tools/binman/image.py |  2 ++
> >  3 files changed, 11 insertions(+), 13 deletions(-)
> >
>
> Acked-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 040/126] cros_ec: Add MEC_EMI_BASE and size to the header file

[Bin Meng]

On Sat, Oct 5, 2019 at 10:42 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > Provide these values which are part of the EC interface now.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  include/ec_commands.h | 4 
> >  1 file changed, 4 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 036/126] binman: Add a base implementation of Entry.ReadChildData()

[Bin Meng]

On Sat, Oct 5, 2019 at 10:41 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present this function is not present in the Entry base class so it is
> > hard to find the documentation for it. Move the docs from the section
> > class and expand it a little.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/binman/entry.py | 16 
> >  1 file changed, 16 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 039/126] log: Add log_nop() to avoid unused-variable warnings

[Bin Meng]

On Sat, Oct 5, 2019 at 10:42 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > If a log statement includes a variable and logging is disabled, this can
> > generate warnings about unused variables. Add a bit more complexity to the
> > macros to avoid this for the common case.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  include/log.h | 33 ++---
> >  1 file changed, 26 insertions(+), 7 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 038/126] binman: Take account of skip-at-start with image-header

[Bin Meng]

On Sat, Oct 5, 2019 at 10:42 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > The image-header currently sets it offset assuming that skip-at-start is
> > zero. This does not work on x86 where offsets end at 4GB. Add in this
> > value so that the offset is correct.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/binman/etype/image_header.py | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Acked-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 035/126] binman: Allow verbose output with all commands

[Bin Meng]

On Sat, Oct 5, 2019 at 9:12 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present the verbose flag only works for the 'build' command. This is
> > not intended, nor is it useful. Update the code to support the verbose
> > flag and make use of a command exception handler.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/binman/control.py | 36 +++-
> >  1 file changed, 15 insertions(+), 21 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

Rebased the patch against u-boot-x86/next to get it applied cleanly, and

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] lib: errno: sync error codes

[Heinrich Schuchardt]

Macro ERRNO_MSG() ignores the error number but we should still use the same
constants as in include/linux/errno.h.

Signed-off-by: Heinrich Schuchardt 
---
 lib/errno_str.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/errno_str.c b/lib/errno_str.c
index 0ba950e970..fbe56395d1 100644
--- a/lib/errno_str.c
+++ b/lib/errno_str.c
@@ -13,7 +13,7 @@
 static const char * const errno_message[] = {
ERRNO_MSG(0, "Success"),
ERRNO_MSG(EPERM, "Operation not permitted"),
-   ERRNO_MSG(ENOEN, "No such file or directory"),
+   ERRNO_MSG(ENOENT, "No such file or directory"),
ERRNO_MSG(ESRCH, "No such process"),
ERRNO_MSG(EINTR, "Interrupted system call"),
ERRNO_MSG(EIO, "I/O error"),
@@ -26,7 +26,7 @@ static const char * const errno_message[] = {
ERRNO_MSG(ENOMEM, "Out of memory"),
ERRNO_MSG(EACCES, "Permission denied"),
ERRNO_MSG(EFAULT, "Bad address"),
-   ERRNO_MSG(ENOTBL, "Block device required"),
+   ERRNO_MSG(ENOTBLK, "Block device required"),
ERRNO_MSG(EBUSY, "Device or resource busy"),
ERRNO_MSG(EEXIST, "File exists"),
ERRNO_MSG(EXDEV, "Cross-device link"),
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Peter Robinson]

> > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> > u-boot.img from MMC:
> >
> > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 -
> > 08:03:23 +)
> > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19
> > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices
> > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
>
> Thanks for reporting this issue.
>
> Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
> and Baruch on Cc.

For reference I have also seen the same with the udoo-neo and I have
had reports from a Fedora user of a similar problem on the Wandboard.

Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Adam Ford]

On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
>
> Hi Adam,
>
> (Adding MMC and i.MX maintainers to Cc)
>
> On Fri, Sep 27 2019, Adam Ford wrote:
> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  wrote:
> >>
> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> >> > Hi Vagrant,
> >> >
> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  >> > debian.org> wrote:
> >> > >
> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> >> > > u-boot.img from MMC:
> >> > >
> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 
> >> > > -
> >> > > 08:03:23 +)
> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: 
> >> > > -19
> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices
> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
> >> >
> >> > Thanks for reporting this issue.
> >> >
> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
> >> > and Baruch on Cc.
> >>
> >> Works after reverting the following commit.
> >>
> > I am going to argue that making the board comply with DM_MMC is why I
> > needed to make the patch, because when booting from MMC2, the function
> > was returning MMC1 which was clearly not the boot source.
> >
> > If the boards that fail accept MMC2 as a response when booting from
> > MMC2, that seems like a bug on the indvidual boards.  Instead they
> > should setup their boot sequence to configure MMC2 when MMC2 is the
> > boot source.  Instead, it seems like some boards are configuring MMC1
> > with MMC2 info which only prolongs the conversion to DM_MMC.
> >
> > If we revert the patch, then boards like imx6_logic who rely solely on
> > device tree and DM_MMC for booting will have to manually override the
> > MMC driver in order to boot from MMC2, and that seems like a step
> > backwards.  I would argue that this board should migrate to DM_MMC and
> > use the device tree to boot, and the problem should go away.
>
> I started working on migration to DM_MMC as you suggested. Unfortunately
> I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
> the general case.
>
> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
> both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
> and their corresponding DT representation.
>
> However, the 'index' parameter in uclass_get_device() that is set
> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
> usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
> optional eMMC. When booting from SD card, uclass_get_device(), returns
> -ENODEV when eMMC is not available, or the eMMC device when it is
> available. In both cases, boot fails.
>
> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
>

My patch only extended it to support MMC1 or MMC2.  I don't have
hardware to test MMC3 or MMC4, nor where they defined in the boot
table.
The intention what to eliminate all functions from board files which
did a something like:

static int mmc_init_spl(bd_t *bis)
{
 struct src *psrc = (struct src *)SRC_BASE_ADDR;
  unsigned reg = readl(&psrc->sbmr1) >> 11;

 /*
 * Upon reading BOOT_CFG register the following map is done:
 * Bit 11 and 12 of BOOT_CFG register can determine the current
 * mmc port
 * 0x1  SD2
 * 0x2  SD3
 */
 switch (reg & 0x3) {
 ...
 }
}

> How is all that intended to work?

Basically the above function determines which BOOT_CFG regiser is used
and returns sets MMC1 values to the returned value.  In my case MMC1
was going to be configured with the clock and pin mux of mmc1 or 2.
In your case, mmc1 gets configured with the information for mmc2 or 3.
  Since it appears that arch/arm/mach-imx/spl.c is supposed to be able
to return the correct boot source, my goal was to make that function
actually return that which could eliminate the above function on all
boards.  Unfortunately, I don't have hardware with MMC3 or MMC4, so I
couldn't test it and therefore didn't write it into the code.  It was
my hope that someone with MMC3 or MMC4 would be able to easily expand
it in the hope to better facilitate support for DM_MMC and device tree
in SPL.

>
> Aren't other i.MX boards impacted by this commit?

Yes and no.  If they only support MMC1 or MMC2 and have DM_MMC with
device tree support, the theory is that mmc_init_spl(bd_t *bis)
function can be completely eliminated.  People with MMC3 and MMC4 as
boot sources are quite possibly impacted, but like I said before, I
was trying to lay the 

[U-Boot] [PATCH 1/1] lib: errno: avoid error format-overflow

[Heinrich Schuchardt]

In cmd/regulator.c an error occurs with GCC 9.2.1 if CONFIG_ERRNO_STR is
not defined:

cmd/regulator.c: In function ‘failure’:
cmd/regulator.c:20:2: error: ‘%s’ directive argument is null
[-Werror=format-overflow=]
   20 |  printf("Error: %d (%s)\n", ret, errno_str(ret));
  |  ^~~
In function ‘constraint’,
inlined from ‘constraint’ at cmd/regulator.c:111:12:
cmd/regulator.c:115:3: error: ‘%s’ directive argument is null
[-Werror=format-overflow=]
  115 |   printf(" %s (err: %d)\n", errno_str(val), val);
  |   ^~

errno_str() should return a valid string instead of NULL if
CONFIG_ERRNO_STR is not defined.

Signed-off-by: Heinrich Schuchardt 
---
 include/errno.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/errno.h b/include/errno.h
index ccb7869e17..3af539b9e9 100644
--- a/include/errno.h
+++ b/include/errno.h
@@ -12,12 +12,21 @@ extern int errno;

 #define __set_errno(val) do { errno = val; } while (0)

+/**
+ * errno_str() - get description for error number
+ *
+ * @errno: error number (negative in case of error)
+ * Return: string describing the error. If CONFIG_ERRNO_STR is not
+ * defined an empty string is returned.
+ */
 #ifdef CONFIG_ERRNO_STR
 const char *errno_str(int errno);
 #else
+static const char error_message[] = "";
+
 static inline const char *errno_str(int errno)
 {
-   return 0;
+   return error_message;
 }
 #endif
 #endif /* _ERRNO_H */
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Adam Ford]

On Sun, Oct 6, 2019 at 6:30 AM Adam Ford  wrote:
>
> On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
> >
> > Hi Adam,
> >
> > (Adding MMC and i.MX maintainers to Cc)
> >
> > On Fri, Sep 27 2019, Adam Ford wrote:
> > > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  wrote:
> > >>
> > >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> > >> > Hi Vagrant,
> > >> >
> > >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  > >> > debian.org> wrote:
> > >> > >
> > >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> > >> > > u-boot.img from MMC:
> > >> > >
> > >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 
> > >> > > 2019 -
> > >> > > 08:03:23 +)
> > >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> > >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> > >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: 
> > >> > > -19
> > >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices
> > >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
> > >> >
> > >> > Thanks for reporting this issue.
> > >> >
> > >> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
> > >> > and Baruch on Cc.
> > >>
> > >> Works after reverting the following commit.
> > >>
> > > I am going to argue that making the board comply with DM_MMC is why I
> > > needed to make the patch, because when booting from MMC2, the function
> > > was returning MMC1 which was clearly not the boot source.
> > >
> > > If the boards that fail accept MMC2 as a response when booting from
> > > MMC2, that seems like a bug on the indvidual boards.  Instead they
> > > should setup their boot sequence to configure MMC2 when MMC2 is the
> > > boot source.  Instead, it seems like some boards are configuring MMC1
> > > with MMC2 info which only prolongs the conversion to DM_MMC.
> > >
> > > If we revert the patch, then boards like imx6_logic who rely solely on
> > > device tree and DM_MMC for booting will have to manually override the
> > > MMC driver in order to boot from MMC2, and that seems like a step
> > > backwards.  I would argue that this board should migrate to DM_MMC and
> > > use the device tree to boot, and the problem should go away.
> >
> > I started working on migration to DM_MMC as you suggested. Unfortunately
> > I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
> > the general case.
> >
> > The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
> > both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
> > and their corresponding DT representation.
> >
> > However, the 'index' parameter in uclass_get_device() that is set
> > according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
> > usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
> > (see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
> > is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
> > optional eMMC. When booting from SD card, uclass_get_device(), returns
> > -ENODEV when eMMC is not available, or the eMMC device when it is
> > available. In both cases, boot fails.
> >
> > In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
> > boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
> >
>
> My patch only extended it to support MMC1 or MMC2.  I don't have
> hardware to test MMC3 or MMC4, nor where they defined in the boot
> table.
> The intention what to eliminate all functions from board files which
> did a something like:
>
> static int mmc_init_spl(bd_t *bis)
> {
>  struct src *psrc = (struct src *)SRC_BASE_ADDR;
>   unsigned reg = readl(&psrc->sbmr1) >> 11;
>
>  /*
>  * Upon reading BOOT_CFG register the following map is done:
>  * Bit 11 and 12 of BOOT_CFG register can determine the current
>  * mmc port
>  * 0x1  SD2
>  * 0x2  SD3
>  */
>  switch (reg & 0x3) {
>  ...
>  }
> }
>
> > How is all that intended to work?
>
> Basically the above function determines which BOOT_CFG regiser is used
> and returns sets MMC1 values to the returned value.  In my case MMC1
> was going to be configured with the clock and pin mux of mmc1 or 2.
> In your case, mmc1 gets configured with the information for mmc2 or 3.
>   Since it appears that arch/arm/mach-imx/spl.c is supposed to be able
> to return the correct boot source, my goal was to make that function
> actually return that which could eliminate the above function on all
> boards.  Unfortunately, I don't have hardware with MMC3 or MMC4, so I
> couldn't test it and therefore didn't write it into the code.  It was
> my hope that someone with MMC3 or MMC4 would be able to easily expand
> it in the hope to better facilitate support for DM_MMC and device tree
> in SPL.
>
> >
> > Aren't other i.MX boards impacted by this commit?
>
> Yes and no.  If the

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Baruch Siach]

Hi Adam,

On Sun, Oct 06 2019, Adam Ford wrote:
> On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
>> (Adding MMC and i.MX maintainers to Cc)
>>
>> On Fri, Sep 27 2019, Adam Ford wrote:
>> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  wrote:
>> >>
>> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
>> >> > Hi Vagrant,
>> >> >
>> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > >> > debian.org> wrote:
>> >> > >
>> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
>> >> > > u-boot.img from MMC:
>> >> > >
>> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 
>> >> > > 2019 -
>> >> > > 08:03:23 +)
>> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
>> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
>> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: 
>> >> > > -19
>> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices
>> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
>> >> >
>> >> > Thanks for reporting this issue.
>> >> >
>> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
>> >> > and Baruch on Cc.
>> >>
>> >> Works after reverting the following commit.
>> >>
>> > I am going to argue that making the board comply with DM_MMC is why I
>> > needed to make the patch, because when booting from MMC2, the function
>> > was returning MMC1 which was clearly not the boot source.
>> >
>> > If the boards that fail accept MMC2 as a response when booting from
>> > MMC2, that seems like a bug on the indvidual boards.  Instead they
>> > should setup their boot sequence to configure MMC2 when MMC2 is the
>> > boot source.  Instead, it seems like some boards are configuring MMC1
>> > with MMC2 info which only prolongs the conversion to DM_MMC.
>> >
>> > If we revert the patch, then boards like imx6_logic who rely solely on
>> > device tree and DM_MMC for booting will have to manually override the
>> > MMC driver in order to boot from MMC2, and that seems like a step
>> > backwards.  I would argue that this board should migrate to DM_MMC and
>> > use the device tree to boot, and the problem should go away.
>>
>> I started working on migration to DM_MMC as you suggested. Unfortunately
>> I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
>> the general case.
>>
>> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
>> both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
>> and their corresponding DT representation.
>>
>> However, the 'index' parameter in uclass_get_device() that is set
>> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
>> usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
>> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
>> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
>> optional eMMC. When booting from SD card, uclass_get_device(), returns
>> -ENODEV when eMMC is not available, or the eMMC device when it is
>> available. In both cases, boot fails.

I think you missed this part. See more below.

>> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
>> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
>>
>
> My patch only extended it to support MMC1 or MMC2.  I don't have
> hardware to test MMC3 or MMC4, nor where they defined in the boot
> table.
> The intention what to eliminate all functions from board files which
> did a something like:
>
> static int mmc_init_spl(bd_t *bis)
> {
>  struct src *psrc = (struct src *)SRC_BASE_ADDR;
>   unsigned reg = readl(&psrc->sbmr1) >> 11;
>
>  /*
>  * Upon reading BOOT_CFG register the following map is done:
>  * Bit 11 and 12 of BOOT_CFG register can determine the current
>  * mmc port
>  * 0x1  SD2
>  * 0x2  SD3
>  */
>  switch (reg & 0x3) {
>  ...
>  }
> }
>
>> How is all that intended to work?
>
> Basically the above function determines which BOOT_CFG regiser is used
> and returns sets MMC1 values to the returned value.  In my case MMC1
> was going to be configured with the clock and pin mux of mmc1 or 2.
> In your case, mmc1 gets configured with the information for mmc2 or 3.

But there is another side effect to this change. The code in spl_mmc.c
uses BOOT_DEVICE_MMC* macros to determine the boot device as I mentioned
above. These macros have nothing to do with usdhcX sequence
numbering. When usdhc1 is missing, BOOT_DEVICE_MMC1 refers to usdhc2
which happens to be the first probed device, and BOOT_DEVICE_MMC2
becomes usdhc3. This code is broken since commit 14d319b185.

spl_boot_device() can not blindly return BOOT_DEVICE_MMC{1,2} without
knowing which devices are actually available.

There must be some other way to achieve what you want without breaking
boot when usdhc1 is missing.

>   Since it appears tha

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Adam Ford]

On Sun, Oct 6, 2019 at 7:22 AM Baruch Siach  wrote:
>
> Hi Adam,
>
> On Sun, Oct 06 2019, Adam Ford wrote:
> > On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
> >> (Adding MMC and i.MX maintainers to Cc)
> >>
> >> On Fri, Sep 27 2019, Adam Ford wrote:
> >> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  wrote:
> >> >>
> >> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> >> >> > Hi Vagrant,
> >> >> >
> >> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  >> >> > debian.org> wrote:
> >> >> > >
> >> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> >> >> > > u-boot.img from MMC:
> >> >> > >
> >> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 
> >> >> > > 2019 -
> >> >> > > 08:03:23 +)
> >> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> >> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> >> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. 
> >> >> > > error: -19
> >> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot 
> >> >> > > devices
> >> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ###
> >> >> >
> >> >> > Thanks for reporting this issue.
> >> >> >
> >> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
> >> >> > and Baruch on Cc.
> >> >>
> >> >> Works after reverting the following commit.
> >> >>
> >> > I am going to argue that making the board comply with DM_MMC is why I
> >> > needed to make the patch, because when booting from MMC2, the function
> >> > was returning MMC1 which was clearly not the boot source.
> >> >
> >> > If the boards that fail accept MMC2 as a response when booting from
> >> > MMC2, that seems like a bug on the indvidual boards.  Instead they
> >> > should setup their boot sequence to configure MMC2 when MMC2 is the
> >> > boot source.  Instead, it seems like some boards are configuring MMC1
> >> > with MMC2 info which only prolongs the conversion to DM_MMC.
> >> >
> >> > If we revert the patch, then boards like imx6_logic who rely solely on
> >> > device tree and DM_MMC for booting will have to manually override the
> >> > MMC driver in order to boot from MMC2, and that seems like a step
> >> > backwards.  I would argue that this board should migrate to DM_MMC and
> >> > use the device tree to boot, and the problem should go away.
> >>
> >> I started working on migration to DM_MMC as you suggested. Unfortunately
> >> I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
> >> the general case.
> >>
> >> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
> >> both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
> >> and their corresponding DT representation.
> >>
> >> However, the 'index' parameter in uclass_get_device() that is set
> >> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
> >> usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
> >> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
> >> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
> >> optional eMMC. When booting from SD card, uclass_get_device(), returns
> >> -ENODEV when eMMC is not available, or the eMMC device when it is
> >> available. In both cases, boot fails.
>
> I think you missed this part. See more below.
>
> >> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
> >> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
> >>
> >
> > My patch only extended it to support MMC1 or MMC2.  I don't have
> > hardware to test MMC3 or MMC4, nor where they defined in the boot
> > table.
> > The intention what to eliminate all functions from board files which
> > did a something like:
> >
> > static int mmc_init_spl(bd_t *bis)
> > {
> >  struct src *psrc = (struct src *)SRC_BASE_ADDR;
> >   unsigned reg = readl(&psrc->sbmr1) >> 11;
> >
> >  /*
> >  * Upon reading BOOT_CFG register the following map is done:
> >  * Bit 11 and 12 of BOOT_CFG register can determine the current
> >  * mmc port
> >  * 0x1  SD2
> >  * 0x2  SD3
> >  */
> >  switch (reg & 0x3) {
> >  ...
> >  }
> > }
> >
> >> How is all that intended to work?
> >
> > Basically the above function determines which BOOT_CFG regiser is used
> > and returns sets MMC1 values to the returned value.  In my case MMC1
> > was going to be configured with the clock and pin mux of mmc1 or 2.
> > In your case, mmc1 gets configured with the information for mmc2 or 3.
>
> But there is another side effect to this change. The code in spl_mmc.c
> uses BOOT_DEVICE_MMC* macros to determine the boot device as I mentioned
> above. These macros have nothing to do with usdhcX sequence
> numbering. When usdhc1 is missing, BOOT_DEVICE_MMC1 refers to usdhc2
> which happens to be the first probed device, and BOOT_DEVICE_MMC2
> becomes usdhc3. This 

[U-Boot] [PATCH 0/2] lib: errno: check for unsupported error number

[Heinrich Schuchardt]

errno_str() should not return a random pointer for unknown error codes.

Provide a unit test for errno_str().

Heinrich Schuchardt (2):
  lib: errno: check for unsupported error number
  test: provide test for errno_str()

 lib/errno_str.c   |  8 ++-
 test/lib/Makefile |  1 +
 test/lib/test_errno_str.c | 50 +++
 3 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 test/lib/test_errno_str.c

--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] lib: errno: check for unsupported errors

[Heinrich Schuchardt]

If errno_str() is called with an unsupported error number, do not return a
random pointer but a reasonable text.

Signed-off-by: Heinrich Schuchardt 
---
 lib/errno_str.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/errno_str.c b/lib/errno_str.c
index fbe56395d1..2e5f4a887d 100644
--- a/lib/errno_str.c
+++ b/lib/errno_str.c
@@ -136,6 +136,8 @@ static const char * const errno_message[] = {
ERRNO_MSG(EDQUOT, "Quota exceeded"),
ERRNO_MSG(ENOMEDIUM, "No medium found"),
ERRNO_MSG(EMEDIUMTYPE, "Wrong medium type"),
+   /* Message for unsupported error numbers */
+   ERRNO_MSG(0, "Unknown error"),
 };

 const char *errno_str(int errno)
@@ -143,5 +145,9 @@ const char *errno_str(int errno)
if (errno >= 0)
return errno_message[0];

-   return errno_message[abs(errno)];
+   errno = -errno;
+   if (errno >= ARRAY_SIZE(errno_message))
+   errno = ARRAY_SIZE(errno_message) - 1;
+
+   return errno_message[errno];
 }
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] test: provide test for errno_str()

[Heinrich Schuchardt]

Provide a unit test for errno_str(). Test that known and unknown error
numbers are handled correctly.

Signed-off-by: Heinrich Schuchardt 
---
 test/lib/Makefile |  1 +
 test/lib/test_errno_str.c | 50 +++
 2 files changed, 51 insertions(+)
 create mode 100644 test/lib/test_errno_str.c

diff --git a/test/lib/Makefile b/test/lib/Makefile
index 308c61708e..b13aaca7ce 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -6,3 +6,4 @@ obj-y += cmd_ut_lib.o
 obj-y += hexdump.o
 obj-y += lmb.o
 obj-y += string.o
+obj-$(CONFIG_ERRNO_STR) += test_errno_str.o
diff --git a/test/lib/test_errno_str.c b/test/lib/test_errno_str.c
new file mode 100644
index 00..77072d04f9
--- /dev/null
+++ b/test/lib/test_errno_str.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Heinrich Schuchardt 
+ *
+ * Unit tests for memory functions
+ *
+ * The architecture dependent implementations run through different lines of
+ * code depending on the alignment and length of memory regions copied or set.
+ * This has to be considered in testing.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const char errno_str_ok[] = "Success";
+static const char errno_str_enomem[] = "Out of memory";
+static const char errno_str_unknown[] = "Unknown error";
+
+/**
+ * lib_errno_str() - unit test for errno_str()
+ *
+ * Test errno_str() with varied alignment and length of the copied buffer.
+ *
+ * @uts:   unit test state
+ * Return: 0 = success, 1 = failure
+ */
+static int lib_errno_str(struct unit_test_state *uts)
+{
+   const char *msg;
+
+   msg = errno_str(1);
+   ut_asserteq_str(errno_str_ok, msg);
+
+   msg = errno_str(0);
+   ut_asserteq_str(errno_str_ok, msg);
+
+   msg = errno_str(-ENOMEM);
+   ut_asserteq_str(errno_str_enomem, msg);
+
+   msg = errno_str(-9);
+   ut_asserteq_str(errno_str_unknown, msg);
+
+   return 0;
+}
+
+LIB_TEST(lib_errno_str, 0);
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] lib: errno: check for unsupported error number

[Heinrich Schuchardt]

If errno_str() is called with an unsupported error number, do not return a
random pointer but a reasonable text.

Signed-off-by: Heinrich Schuchardt 
---
 lib/errno_str.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/errno_str.c b/lib/errno_str.c
index fbe56395d1..2e5f4a887d 100644
--- a/lib/errno_str.c
+++ b/lib/errno_str.c
@@ -136,6 +136,8 @@ static const char * const errno_message[] = {
ERRNO_MSG(EDQUOT, "Quota exceeded"),
ERRNO_MSG(ENOMEDIUM, "No medium found"),
ERRNO_MSG(EMEDIUMTYPE, "Wrong medium type"),
+   /* Message for unsupported error numbers */
+   ERRNO_MSG(0, "Unknown error"),
 };

 const char *errno_str(int errno)
@@ -143,5 +145,9 @@ const char *errno_str(int errno)
if (errno >= 0)
return errno_message[0];

-   return errno_message[abs(errno)];
+   errno = -errno;
+   if (errno >= ARRAY_SIZE(errno_message))
+   errno = ARRAY_SIZE(errno_message) - 1;
+
+   return errno_message[errno];
 }
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] lib: errno: check for unsupported errors

[Heinrich Schuchardt]

On 10/6/19 2:33 PM, Heinrich Schuchardt wrote:

If errno_str() is called with an unsupported error number, do not return a
random pointer but a reasonable text.

Signed-off-by: Heinrich Schuchardt


This mail was sent by mistake. The correct patch is

[PATCH 1/2] lib: errno: check for unsupported error number
https://lists.denx.de/pipermail/u-boot/2019-October/385618.html
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Adam Ford]

On Sun, Oct 6, 2019 at 7:30 AM Adam Ford  wrote:
>
> On Sun, Oct 6, 2019 at 7:22 AM Baruch Siach  wrote:
> >
> > Hi Adam,
> >
> > On Sun, Oct 06 2019, Adam Ford wrote:
> > > On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
> > >> (Adding MMC and i.MX maintainers to Cc)
> > >>
> > >> On Fri, Sep 27 2019, Adam Ford wrote:
> > >> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  wrote:
> > >> >>
> > >> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> > >> >> > Hi Vagrant,
> > >> >> >
> > >> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  > >> >> > debian.org> wrote:
> > >> >> > >
> > >> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> > >> >> > > u-boot.img from MMC:
> > >> >> > >
> > >> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 
> > >> >> > > 2019 -
> > >> >> > > 08:03:23 +)
> > >> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> > >> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> > >> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. 
> > >> >> > > error: -19
> > >> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot 
> > >> >> > > devices
> > >> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board 
> > >> >> > > ###
> > >> >> >
> > >> >> > Thanks for reporting this issue.
> > >> >> >
> > >> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
> > >> >> > and Baruch on Cc.
> > >> >>
> > >> >> Works after reverting the following commit.
> > >> >>
> > >> > I am going to argue that making the board comply with DM_MMC is why I
> > >> > needed to make the patch, because when booting from MMC2, the function
> > >> > was returning MMC1 which was clearly not the boot source.
> > >> >
> > >> > If the boards that fail accept MMC2 as a response when booting from
> > >> > MMC2, that seems like a bug on the indvidual boards.  Instead they
> > >> > should setup their boot sequence to configure MMC2 when MMC2 is the
> > >> > boot source.  Instead, it seems like some boards are configuring MMC1
> > >> > with MMC2 info which only prolongs the conversion to DM_MMC.
> > >> >
> > >> > If we revert the patch, then boards like imx6_logic who rely solely on
> > >> > device tree and DM_MMC for booting will have to manually override the
> > >> > MMC driver in order to boot from MMC2, and that seems like a step
> > >> > backwards.  I would argue that this board should migrate to DM_MMC and
> > >> > use the device tree to boot, and the problem should go away.
> > >>
> > >> I started working on migration to DM_MMC as you suggested. Unfortunately
> > >> I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
> > >> the general case.
> > >>
> > >> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
> > >> both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
> > >> and their corresponding DT representation.
> > >>
> > >> However, the 'index' parameter in uclass_get_device() that is set
> > >> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
> > >> usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
> > >> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
> > >> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
> > >> optional eMMC. When booting from SD card, uclass_get_device(), returns
> > >> -ENODEV when eMMC is not available, or the eMMC device when it is
> > >> available. In both cases, boot fails.
> >
> > I think you missed this part. See more below.
> >
> > >> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
> > >> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
> > >>
> > >
> > > My patch only extended it to support MMC1 or MMC2.  I don't have
> > > hardware to test MMC3 or MMC4, nor where they defined in the boot
> > > table.
> > > The intention what to eliminate all functions from board files which
> > > did a something like:
> > >
> > > static int mmc_init_spl(bd_t *bis)
> > > {
> > >  struct src *psrc = (struct src *)SRC_BASE_ADDR;
> > >   unsigned reg = readl(&psrc->sbmr1) >> 11;
> > >
> > >  /*
> > >  * Upon reading BOOT_CFG register the following map is done:
> > >  * Bit 11 and 12 of BOOT_CFG register can determine the current
> > >  * mmc port
> > >  * 0x1  SD2
> > >  * 0x2  SD3
> > >  */
> > >  switch (reg & 0x3) {
> > >  ...
> > >  }
> > > }
> > >
> > >> How is all that intended to work?
> > >
> > > Basically the above function determines which BOOT_CFG regiser is used
> > > and returns sets MMC1 values to the returned value.  In my case MMC1
> > > was going to be configured with the clock and pin mux of mmc1 or 2.
> > > In your case, mmc1 gets configured with the information for mmc2 or 3.
> >
> > But there is another side effect to this change. The code in spl_mmc.c
> > uses BOOT_DEV

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Baruch Siach]

Hi Adam,

On Sun, Oct 06 2019, Adam Ford wrote:
> On Sun, Oct 6, 2019 at 7:30 AM Adam Ford  wrote:
>>
>> On Sun, Oct 6, 2019 at 7:22 AM Baruch Siach  wrote:
>> >
>> > Hi Adam,
>> >
>> > On Sun, Oct 06 2019, Adam Ford wrote:
>> > > On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
>> > >> (Adding MMC and i.MX maintainers to Cc)
>> > >>
>> > >> On Fri, Sep 27 2019, Adam Ford wrote:
>> > >> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  
>> > >> > wrote:
>> > >> >>
>> > >> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
>> > >> >> > Hi Vagrant,
>> > >> >> >
>> > >> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > > >> >> > debian.org> wrote:
>> > >> >> > >
>> > >> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
>> > >> >> > > u-boot.img from MMC:
>> > >> >> > >
>> > >> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 
>> > >> >> > > 24 2019 -
>> > >> >> > > 08:03:23 +)
>> > >> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
>> > >> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
>> > >> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. 
>> > >> >> > > error: -19
>> > >> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot 
>> > >> >> > > devices
>> > >> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board 
>> > >> >> > > ###
>> > >> >> >
>> > >> >> > Thanks for reporting this issue.
>> > >> >> >
>> > >> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon
>> > >> >> > and Baruch on Cc.
>> > >> >>
>> > >> >> Works after reverting the following commit.
>> > >> >>
>> > >> > I am going to argue that making the board comply with DM_MMC is why I
>> > >> > needed to make the patch, because when booting from MMC2, the function
>> > >> > was returning MMC1 which was clearly not the boot source.
>> > >> >
>> > >> > If the boards that fail accept MMC2 as a response when booting from
>> > >> > MMC2, that seems like a bug on the indvidual boards.  Instead they
>> > >> > should setup their boot sequence to configure MMC2 when MMC2 is the
>> > >> > boot source.  Instead, it seems like some boards are configuring MMC1
>> > >> > with MMC2 info which only prolongs the conversion to DM_MMC.
>> > >> >
>> > >> > If we revert the patch, then boards like imx6_logic who rely solely on
>> > >> > device tree and DM_MMC for booting will have to manually override the
>> > >> > MMC driver in order to boot from MMC2, and that seems like a step
>> > >> > backwards.  I would argue that this board should migrate to DM_MMC and
>> > >> > use the device tree to boot, and the problem should go away.
>> > >>
>> > >> I started working on migration to DM_MMC as you suggested. Unfortunately
>> > >> I can't see how this solves the problem for Cubox-i/Hummingboard, nor in
>> > >> the general case.
>> > >>
>> > >> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, and
>> > >> both are always enabled. This matches perfectly to BOOT_DEVICE_MMC{1,2},
>> > >> and their corresponding DT representation.
>> > >>
>> > >> However, the 'index' parameter in uclass_get_device() that is set
>> > >> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
>> > >> usdhcX sequence number. It simply returns the Nth probed SD/eMMC device
>> > >> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, usdhc1
>> > >> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
>> > >> optional eMMC. When booting from SD card, uclass_get_device(), returns
>> > >> -ENODEV when eMMC is not available, or the eMMC device when it is
>> > >> available. In both cases, boot fails.
>> >
>> > I think you missed this part. See more below.
>> >
>> > >> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
>> > >> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
>> > >>
>> > >
>> > > My patch only extended it to support MMC1 or MMC2.  I don't have
>> > > hardware to test MMC3 or MMC4, nor where they defined in the boot
>> > > table.
>> > > The intention what to eliminate all functions from board files which
>> > > did a something like:
>> > >
>> > > static int mmc_init_spl(bd_t *bis)
>> > > {
>> > >  struct src *psrc = (struct src *)SRC_BASE_ADDR;
>> > >   unsigned reg = readl(&psrc->sbmr1) >> 11;
>> > >
>> > >  /*
>> > >  * Upon reading BOOT_CFG register the following map is done:
>> > >  * Bit 11 and 12 of BOOT_CFG register can determine the current
>> > >  * mmc port
>> > >  * 0x1  SD2
>> > >  * 0x2  SD3
>> > >  */
>> > >  switch (reg & 0x3) {
>> > >  ...
>> > >  }
>> > > }
>> > >
>> > >> How is all that intended to work?
>> > >
>> > > Basically the above function determines which BOOT_CFG regiser is used
>> > > and returns sets MMC1 values to the returned value.  In my case MMC1
>> > > was going to be configured with the clock and pin mux of mmc1 or 2.
>> > 

[U-Boot] [PATCH 1/1] configs: sheevaplug disable EFI_UNICODE_CAPITALIZATION

[Heinrich Schuchardt]

With upcoming patches u-boot.kwb gets too large.

Save 3740 bytes in u-boot.kwb by disabling Unicode support in the UEFI
sub-system.

Signed-off-by: Heinrich Schuchardt 
---
 configs/sheevaplug_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig
index 734e894c98..cc48536415 100644
--- a/configs/sheevaplug_defconfig
+++ b/configs/sheevaplug_defconfig
@@ -46,3 +46,4 @@ CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
 CONFIG_LZMA=y
+# CONFIG_EFI_UNICODE_CAPITALIZATION is not set
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] ARM: socfpga: arria10: Add common u-boot devicetree include

[Marek Vasut]

On 10/6/19 1:25 AM, Dalon L Westergreen wrote:
> On Sat, 2019-10-05 at 01:49 +0200, Marek Vasut wrote:
>> On 10/5/19 12:30 AM, Dalon Westergreen wrote:
>>> From: Dalon Westergreen 
>>> Add a common u-boot devicetree include file for the SocFPGAArria10 device.
>>
>> Isn't arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi doing basicallythe 
>> same
>> thing, except more fine-grained ?
>>> diff --git a/arch/arm/dts/socfpga_arria10-common-u-boot.dtsi
>>> b/arch/arm/dts/socfpga_arria10-common-u-boot.dtsinew file mode 100644index
>>> 00..bd4f1271f3--- /dev/null+++ b/arch/arm/dts/socfpga_arria10-
>>> common-u-boot.dtsi@@ -0,0 +1,206 @@+// SPDX-License-Identifier: GPL-2.0+/*+
>>> * Copyright Altera Corporation (C) 2014. All rights reserved.+ */++/ {+ 
>>> #address-cells = <1>;+  #size-cells = <1>;++chosen {+   
>>> tick
>>> -timer = &timer2;+  u-boot,dm-pre-reloc;+   };++memory@0 {+ 
>>> u-boot,dm-pre-reloc;+   };++soc {+  u-boot,dm-pre-
>>> reloc;++clkmgr@ffd04000 {+  u-boot,dm-pre-
>>> reloc;++clocks {+   
>>> u-
>>> boot,dm-pre-reloc;++cb_intosc_hs_div
>>> 2_clk {+u-boot,dm-pre-reloc;+   
>>> };++cb_i
>>> ntosc_ls_clk {+ u-boot,dm-pre-
>>> reloc;+ };++
>>> f2s_free_clk {+ u-boot,dm-
>>> pre-reloc;+ };++
>>> osc1 {+ u-boot,dm-pre-
>>> reloc;+ };++
>>> main_pll@40 {+  u-boot,dm-
>>> pre-reloc;++main_mpu_base_cl
>>> k {+u-boot,dm-pre-
>>> reloc;+ };++
>>> main_noc_base_clk {+
>>> u-boot,dm-pre-reloc;+   
>>> };++main_emaca_clk@68 {+
>>> u-boot,dm-pre-reloc;+   
>>> };
>>
>> Do we really need all this in SPL for every board ?
> 
> We likely don't, but we arent that memory constrained in a10 and this 
> simplifies
> devicetree creation for custom boards.

We shouldn't enable what we don't need in SPL.

> We do have customers using ethernet
> in spl, for example.  I can slim this down, but is it necessary?

Just enable the necessary clock in the board-specific DT, since it's a
board-specific configuration.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include

[Marek Vasut]

On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
>> On 10/5/19 12:30 AM, Dalon Westergreen wrote:
>>> From: Dalon Westergreen 
>>> Generic handoff devicetree include uses a header generated bythe qts-filter-
>>> a10.sh script in mach-socfpga.  The scriptcreates the header based on design
>>> specific implementationsfor clock and pinmux configurations.
>>
>> [...]
>>> diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
>>> b/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
>>
>> [...]
>>> -   clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
>>> compatible =
>>> "altr,socfpga-a10-clk-init";+   reg = <0xffd04000 0x0200>;+ 
>>> reg-names = "soc_clock_manager_OCP_SLV";u-boot,dm-pre-
>>> reloc;  mainpll {+  vco0-psrc =
>>> ;+vco1-denom =
>>> ;+   vco1-numer =
>>> ;
>>
>> But these bits are board-specific , they shouldn't be in common DT.
> 
> This common dtsi requires that the top level u-boot.dtsi include the board
> specific header.  The format
> and #define names are in fact common.

OK, I now see what you're doing here. Can you explain that in a bit more
detail in the commit message ?

Basically socfpga_board.h is included socfpga_board.dts , and then the
preprocessor correctly expands the values from socfpga_board.h in the
socfpga_board.dts , so this works for multiple boards too ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] cmd: disable CMD_NVEDIT_EFI by default

[Heinrich Schuchardt]

The growth of the UEFI sub-system leads to build failures for systems with
strict limits on the U-Boot image size.

CMD_NVEDIT_EFI supports displaying and editing of UEFI variables. The
setting is not needed for booting. Disabling it by default reduces the
size of the U-Boot image by 2 KiB.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4e61565aab..8e55b34c96 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -531,7 +531,6 @@ config CMD_ENV_FLAGS
 config CMD_NVEDIT_EFI
bool "env [set|print] -e - set/print UEFI variables"
depends on EFI_LOADER
-   default y
imply HEXDUMP
help
  UEFI variables are encoded as some form of U-Boot variables.
--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Adam Ford]

On Sun, Oct 6, 2019 at 7:48 AM Baruch Siach  wrote:
>
> Hi Adam,
>
> On Sun, Oct 06 2019, Adam Ford wrote:
> > On Sun, Oct 6, 2019 at 7:30 AM Adam Ford  wrote:
> >>
> >> On Sun, Oct 6, 2019 at 7:22 AM Baruch Siach  wrote:
> >> >
> >> > Hi Adam,
> >> >
> >> > On Sun, Oct 06 2019, Adam Ford wrote:
> >> > > On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
> >> > >> (Adding MMC and i.MX maintainers to Cc)
> >> > >>
> >> > >> On Fri, Sep 27 2019, Adam Ford wrote:
> >> > >> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  
> >> > >> > wrote:
> >> > >> >>
> >> > >> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> >> > >> >> > Hi Vagrant,
> >> > >> >> >
> >> > >> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  >> > >> >> > debian.org> wrote:
> >> > >> >> > >
> >> > >> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
> >> > >> >> > > u-boot.img from MMC:
> >> > >> >> > >
> >> > >> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 
> >> > >> >> > > 24 2019 -
> >> > >> >> > > 08:03:23 +)
> >> > >> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> >> > >> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> >> > >> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. 
> >> > >> >> > > error: -19
> >> > >> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot 
> >> > >> >> > > devices
> >> > >> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the 
> >> > >> >> > > board ###
> >> > >> >> >
> >> > >> >> > Thanks for reporting this issue.
> >> > >> >> >
> >> > >> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding 
> >> > >> >> > Jon
> >> > >> >> > and Baruch on Cc.
> >> > >> >>
> >> > >> >> Works after reverting the following commit.
> >> > >> >>
> >> > >> > I am going to argue that making the board comply with DM_MMC is why 
> >> > >> > I
> >> > >> > needed to make the patch, because when booting from MMC2, the 
> >> > >> > function
> >> > >> > was returning MMC1 which was clearly not the boot source.
> >> > >> >
> >> > >> > If the boards that fail accept MMC2 as a response when booting from
> >> > >> > MMC2, that seems like a bug on the indvidual boards.  Instead they
> >> > >> > should setup their boot sequence to configure MMC2 when MMC2 is the
> >> > >> > boot source.  Instead, it seems like some boards are configuring 
> >> > >> > MMC1
> >> > >> > with MMC2 info which only prolongs the conversion to DM_MMC.
> >> > >> >
> >> > >> > If we revert the patch, then boards like imx6_logic who rely solely 
> >> > >> > on
> >> > >> > device tree and DM_MMC for booting will have to manually override 
> >> > >> > the
> >> > >> > MMC driver in order to boot from MMC2, and that seems like a step
> >> > >> > backwards.  I would argue that this board should migrate to DM_MMC 
> >> > >> > and
> >> > >> > use the device tree to boot, and the problem should go away.
> >> > >>
> >> > >> I started working on migration to DM_MMC as you suggested. 
> >> > >> Unfortunately
> >> > >> I can't see how this solves the problem for Cubox-i/Hummingboard, nor 
> >> > >> in
> >> > >> the general case.
> >> > >>
> >> > >> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, 
> >> > >> and
> >> > >> both are always enabled. This matches perfectly to 
> >> > >> BOOT_DEVICE_MMC{1,2},
> >> > >> and their corresponding DT representation.
> >> > >>
> >> > >> However, the 'index' parameter in uclass_get_device() that is set
> >> > >> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with the
> >> > >> usdhcX sequence number. It simply returns the Nth probed SD/eMMC 
> >> > >> device
> >> > >> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, 
> >> > >> usdhc1
> >> > >> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
> >> > >> optional eMMC. When booting from SD card, uclass_get_device(), returns
> >> > >> -ENODEV when eMMC is not available, or the eMMC device when it is
> >> > >> available. In both cases, boot fails.
> >> >
> >> > I think you missed this part. See more below.
> >> >
> >> > >> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
> >> > >> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
> >> > >>
> >> > >
> >> > > My patch only extended it to support MMC1 or MMC2.  I don't have
> >> > > hardware to test MMC3 or MMC4, nor where they defined in the boot
> >> > > table.
> >> > > The intention what to eliminate all functions from board files which
> >> > > did a something like:
> >> > >
> >> > > static int mmc_init_spl(bd_t *bis)
> >> > > {
> >> > >  struct src *psrc = (struct src *)SRC_BASE_ADDR;
> >> > >   unsigned reg = readl(&psrc->sbmr1) >> 11;
> >> > >
> >> > >  /*
> >> > >  * Upon reading BOOT_CFG register the following map is done:
> >> > >  * Bit 11 and 12 of BOOT_CFG register can determine the current
> >> > >  * mmc port
> >> > >  * 0x1  SD2
> >

[U-Boot] [RFC] [PATCH 1/1] Dockerfile: enable colored output

[Heinrich Schuchardt]

Set environment variables needed for colored output.

Signed-off-by: Heinrich Schuchardt 
---
Hello Tom,

I do not have my own Gitlab to test this. But we should get a more legible
output with these variables set.

Best regards

Heinrich
---
 Dockerfile | 4 
 1 file changed, 4 insertions(+)

diff --git a/Dockerfile b/Dockerfile
index 1d7a3da..7df9e71 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -6,6 +6,10 @@ FROM ubuntu:xenial-20190720
 MAINTAINER Tom Rini 
 LABEL Description=" This image is for building U-Boot inside a container"

+# Let's have colored output
+ENV TERM=xterm-256color
+ENV PYTEST_ADDOPTS="--color=yes"
+
 # Make sure apt is happy
 ENV DEBIAN_FRONTEND=noninteractive

--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Baruch Siach]

Hi Adam,

On Sun, Oct 06 2019, Adam Ford wrote:
> On Sun, Oct 6, 2019 at 7:48 AM Baruch Siach  wrote:
>> On Sun, Oct 06 2019, Adam Ford wrote:
>> > On Sun, Oct 6, 2019 at 7:30 AM Adam Ford  wrote:
>> >>
>> >> On Sun, Oct 6, 2019 at 7:22 AM Baruch Siach  wrote:
>> >> >
>> >> > Hi Adam,
>> >> >
>> >> > On Sun, Oct 06 2019, Adam Ford wrote:
>> >> > > On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  wrote:
>> >> > >> (Adding MMC and i.MX maintainers to Cc)
>> >> > >>
>> >> > >> On Fri, Sep 27 2019, Adam Ford wrote:
>> >> > >> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  
>> >> > >> > wrote:
>> >> > >> >>
>> >> > >> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
>> >> > >> >> > Hi Vagrant,
>> >> > >> >> >
>> >> > >> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > >> > >> >> > debian.org> wrote:
>> >> > >> >> > >
>> >> > >> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load
>> >> > >> >> > > u-boot.img from MMC:
>> >> > >> >> > >
>> >> > >> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 
>> >> > >> >> > > (Sep 24 2019 -
>> >> > >> >> > > 08:03:23 +)
>> >> > >> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
>> >> > >> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
>> >> > >> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. 
>> >> > >> >> > > error: -19
>> >> > >> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot 
>> >> > >> >> > > devices
>> >> > >> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the 
>> >> > >> >> > > board ###
>> >> > >> >> >
>> >> > >> >> > Thanks for reporting this issue.
>> >> > >> >> >
>> >> > >> >> > Unfortunately, I don't have access to my Cuboxi, so I am adding 
>> >> > >> >> > Jon
>> >> > >> >> > and Baruch on Cc.
>> >> > >> >>
>> >> > >> >> Works after reverting the following commit.
>> >> > >> >>
>> >> > >> > I am going to argue that making the board comply with DM_MMC is 
>> >> > >> > why I
>> >> > >> > needed to make the patch, because when booting from MMC2, the 
>> >> > >> > function
>> >> > >> > was returning MMC1 which was clearly not the boot source.
>> >> > >> >
>> >> > >> > If the boards that fail accept MMC2 as a response when booting from
>> >> > >> > MMC2, that seems like a bug on the indvidual boards.  Instead they
>> >> > >> > should setup their boot sequence to configure MMC2 when MMC2 is the
>> >> > >> > boot source.  Instead, it seems like some boards are configuring 
>> >> > >> > MMC1
>> >> > >> > with MMC2 info which only prolongs the conversion to DM_MMC.
>> >> > >> >
>> >> > >> > If we revert the patch, then boards like imx6_logic who rely 
>> >> > >> > solely on
>> >> > >> > device tree and DM_MMC for booting will have to manually override 
>> >> > >> > the
>> >> > >> > MMC driver in order to boot from MMC2, and that seems like a step
>> >> > >> > backwards.  I would argue that this board should migrate to DM_MMC 
>> >> > >> > and
>> >> > >> > use the device tree to boot, and the problem should go away.
>> >> > >>
>> >> > >> I started working on migration to DM_MMC as you suggested. 
>> >> > >> Unfortunately
>> >> > >> I can't see how this solves the problem for Cubox-i/Hummingboard, 
>> >> > >> nor in
>> >> > >> the general case.
>> >> > >>
>> >> > >> The imx6_logic board happens to use only usdhc1 and usdhc2 for boot, 
>> >> > >> and
>> >> > >> both are always enabled. This matches perfectly to 
>> >> > >> BOOT_DEVICE_MMC{1,2},
>> >> > >> and their corresponding DT representation.
>> >> > >>
>> >> > >> However, the 'index' parameter in uclass_get_device() that is set
>> >> > >> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with 
>> >> > >> the
>> >> > >> usdhcX sequence number. It simply returns the Nth probed SD/eMMC 
>> >> > >> device
>> >> > >> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, 
>> >> > >> usdhc1
>> >> > >> is never used for boot, usdhc2 is always an SD card, and usdhc3 is an
>> >> > >> optional eMMC. When booting from SD card, uclass_get_device(), 
>> >> > >> returns
>> >> > >> -ENODEV when eMMC is not available, or the eMMC device when it is
>> >> > >> available. In both cases, boot fails.
>> >> >
>> >> > I think you missed this part. See more below.
>> >> >
>> >> > >> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
>> >> > >> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
>> >> > >>
>> >> > >
>> >> > > My patch only extended it to support MMC1 or MMC2.  I don't have
>> >> > > hardware to test MMC3 or MMC4, nor where they defined in the boot
>> >> > > table.
>> >> > > The intention what to eliminate all functions from board files which
>> >> > > did a something like:
>> >> > >
>> >> > > static int mmc_init_spl(bd_t *bis)
>> >> > > {
>> >> > >  struct src *psrc = (struct src *)SRC_BASE_ADDR;
>> >> > >   unsigned reg = readl(&psrc->sbmr1) >> 11;
>> >> > >
>> >> > >  /*
>> >> > >  * Upon reading BOOT_CFG register the fo

Re: [U-Boot] [PATCH 051/126] x86: Use a common definition of MSR_IA32_PERF_CTL

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> Remove the duplicate definition as it is not needed.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/cpu.c  | 2 +-
>  arch/x86/cpu/broadwell/cpu_full.c | 2 +-
>  arch/x86/cpu/intel_common/cpu.c   | 2 +-
>  arch/x86/include/asm/cpu_common.h | 2 --
>  4 files changed, 3 insertions(+), 5 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 052/126] x86: Add a common function to set CPU thermal target

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> This code appears in a few places, so move it to a common file.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/cpu_full.c| 20 +---
>  arch/x86/cpu/intel_common/cpu.c  | 22 ++
>  arch/x86/cpu/ivybridge/model_206ax.c | 25 +++--
>  arch/x86/include/asm/cpu_common.h| 11 +++
>  4 files changed, 37 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/cpu/broadwell/cpu_full.c 
> b/arch/x86/cpu/broadwell/cpu_full.c
> index 0e3d8781392..d1f3c07109f 100644
> --- a/arch/x86/cpu/broadwell/cpu_full.c
> +++ b/arch/x86/cpu/broadwell/cpu_full.c
> @@ -495,24 +495,6 @@ static void configure_misc(void)
> msr_write(MSR_IA32_PACKAGE_THERM_INTERRUPT, msr);
>  }
>
> -static void configure_thermal_target(struct udevice *dev)
> -{
> -   int tcc_offset;
> -   msr_t msr;
> -
> -   tcc_offset = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> -   "intel,tcc-offset", 0);

"intel,tcc-offset" removed

> -
> -   /* Set TCC activaiton offset if supported */
> -   msr = msr_read(MSR_PLATFORM_INFO);
> -   if ((msr.lo & (1 << 30)) && tcc_offset) {
> -   msr = msr_read(MSR_TEMPERATURE_TARGET);
> -   msr.lo &= ~(0xf << 24); /* Bits 27:24 */
> -   msr.lo |= (tcc_offset & 0xf) << 24;
> -   msr_write(MSR_TEMPERATURE_TARGET, msr);
> -   }
> -}
> -
>  static void configure_dca_cap(void)
>  {
> struct cpuid_result cpuid_regs;
> @@ -562,7 +544,7 @@ static void cpu_core_init(struct udevice *dev)
> configure_misc();
>
> /* Thermal throttle activation offset */
> -   configure_thermal_target(dev);
> +   cpu_configure_thermal_target(dev);
>
> /* Enable Direct Cache Access */
> configure_dca_cap();
> diff --git a/arch/x86/cpu/intel_common/cpu.c b/arch/x86/cpu/intel_common/cpu.c
> index 3a0d505a321..7d0ed73b4b6 100644
> --- a/arch/x86/cpu/intel_common/cpu.c
> +++ b/arch/x86/cpu/intel_common/cpu.c
> @@ -123,3 +123,25 @@ int cpu_intel_get_info(struct cpu_info *info, int bclk)
>
> return 0;
>  }
> +
> +int cpu_configure_thermal_target(struct udevice *dev)
> +{
> +   u32 tcc_offset;
> +   msr_t msr;
> +   int ret;
> +
> +   ret = dev_read_u32(dev, "tcc-offset", &tcc_offset);

"tcc-offset" added, so I wonder how this commit could avoid breaking
broadwell? But I see no dts file provides "tcc-offset", or
"intel,tcc-offset" neither. Probably not a problem.

> +   if (!ret)
> +   return -ENOENT;
> +
> +   /* Set TCC activaiton offset if supported */
> +   msr = msr_read(MSR_PLATFORM_INFO);
> +   if (msr.lo & (1 << 30)) {
> +   msr = msr_read(MSR_TEMPERATURE_TARGET);
> +   msr.lo &= ~(0xf << 24); /* Bits 27:24 */
> +   msr.lo |= (tcc_offset & 0xf) << 24;
> +   msr_write(MSR_TEMPERATURE_TARGET, msr);
> +   }
> +
> +   return 0;
> +}
> diff --git a/arch/x86/cpu/ivybridge/model_206ax.c 
> b/arch/x86/cpu/ivybridge/model_206ax.c
> index 68e78e9478b..ed66d2dd8d7 100644
> --- a/arch/x86/cpu/ivybridge/model_206ax.c
> +++ b/arch/x86/cpu/ivybridge/model_206ax.c
> @@ -283,26 +283,6 @@ static void configure_c_states(void)
> msr_write(MSR_PP1_CURRENT_CONFIG, msr);
>  }
>
> -static int configure_thermal_target(struct udevice *dev)
> -{
> -   int tcc_offset;
> -   msr_t msr;
> -
> -   tcc_offset = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> -   "tcc-offset", 0);
> -
> -   /* Set TCC activaiton offset if supported */
> -   msr = msr_read(MSR_PLATFORM_INFO);
> -   if ((msr.lo & (1 << 30)) && tcc_offset) {
> -   msr = msr_read(MSR_TEMPERATURE_TARGET);
> -   msr.lo &= ~(0xf << 24); /* Bits 27:24 */
> -   msr.lo |= (tcc_offset & 0xf) << 24;
> -   msr_write(MSR_TEMPERATURE_TARGET, msr);
> -   }
> -
> -   return 0;
> -}
> -
>  static void configure_misc(void)
>  {
> msr_t msr;
> @@ -414,10 +394,11 @@ static int model_206ax_init(struct udevice *dev)
> configure_misc();
>
> /* Thermal throttle activation offset */
> -   ret = configure_thermal_target(dev);
> +   ret = cpu_configure_thermal_target(dev);
> if (ret) {
> debug("Cannot set thermal target\n");
> -   return ret;
> +   if (ret != -ENOENT)
> +   return ret;
> }
>
> /* Enable Direct Cache Access */
> diff --git a/arch/x86/include/asm/cpu_common.h 
> b/arch/x86/include/asm/cpu_common.h
> index eb922da2ab8..a1fd7498741 100644
> --- a/arch/x86/include/asm/cpu_common.h
> +++ b/arch/x86/include/asm/cpu_common.h
> @@ -40,4 +40,15 @@ int cpu_set_flex_ratio_to_tdp_nominal(void);
>   */
>  int cpu_intel_get_info(struct cpu_info *info, int bclk_mz);
>
> +/**
> + * cpu_configure_ther

Re: [U-Boot] [PATCH 053/126] x86: Use a common bus clock for Intel CPUs

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> Modern Intel CPUs use a standard bus clock value of 100MHz, so put this in
> a common file and tidy up the copies.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/cpu.c  | 2 +-
>  arch/x86/cpu/broadwell/cpu_full.c | 4 ++--
>  arch/x86/cpu/ivybridge/model_206ax.c  | 4 ++--
>  arch/x86/include/asm/arch-broadwell/cpu.h | 3 ---
>  arch/x86/include/asm/arch-broadwell/pch.h | 3 ---
>  arch/x86/include/asm/arch-ivybridge/model_206ax.h | 3 ---
>  arch/x86/include/asm/cpu_common.h | 5 +
>  7 files changed, 10 insertions(+), 14 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 055/126] x86: Tidy up some duplicate MSR defines

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> Some MSR registers are defined twice in different parts of the file. Move
> them together and remove the duplicates. Also drop some thermal defines
> which are not used.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/baytrail/cpu.c   |   6 +-
>  arch/x86/cpu/broadwell/cpu_full.c |   6 +-
>  arch/x86/cpu/turbo.c  |  10 +--
>  arch/x86/include/asm/msr-index.h  | 106 --
>  4 files changed, 54 insertions(+), 74 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 054/126] x86: Add common functions for TDP and perf control

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> These functions are the same on modern Intel CPUs, so use common code to
> set them.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/cpu.c  |  7 ++
>  arch/x86/cpu/broadwell/cpu_full.c |  9 ---
>  arch/x86/cpu/intel_common/cpu.c   | 20 +++
>  arch/x86/cpu/ivybridge/model_206ax.c  | 25 +++
>  arch/x86/cpu/ivybridge/northbridge.c  |  2 +-
>  .../include/asm/arch-ivybridge/model_206ax.h  |  2 +-
>  arch/x86/include/asm/cpu_common.h | 18 +
>  7 files changed, 51 insertions(+), 32 deletions(-)
>
> diff --git a/arch/x86/cpu/broadwell/cpu.c b/arch/x86/cpu/broadwell/cpu.c
> index 586a2e8f05a..55a7439f1c1 100644
> --- a/arch/x86/cpu/broadwell/cpu.c
> +++ b/arch/x86/cpu/broadwell/cpu.c
> @@ -41,12 +41,9 @@ int arch_cpu_init_dm(void)
>
>  void set_max_freq(void)
>  {
> -   msr_t msr, perf_ctl, platform_info;
> +   msr_t msr, perf_ctl;
>
> -   /* Check for configurable TDP option */
> -   platform_info = msr_read(MSR_PLATFORM_INFO);
> -
> -   if ((platform_info.hi >> 1) & 3) {
> +   if (cpu_config_tdp_levels()) {
> /* Set to nominal TDP ratio */
> msr = msr_read(MSR_CONFIG_TDP_NOMINAL);
> perf_ctl.lo = (msr.lo & 0xff) << 8;
> diff --git a/arch/x86/cpu/broadwell/cpu_full.c 
> b/arch/x86/cpu/broadwell/cpu_full.c
> index 58cc2f362cc..169b5b02a6a 100644
> --- a/arch/x86/cpu/broadwell/cpu_full.c
> +++ b/arch/x86/cpu/broadwell/cpu_full.c
> @@ -329,15 +329,6 @@ static int bsp_init_before_ap_bringup(struct udevice 
> *dev)
> return 0;
>  }
>
> -static int cpu_config_tdp_levels(void)
> -{
> -   msr_t platform_info;
> -
> -   /* Bits 34:33 indicate how many levels supported */
> -   platform_info = msr_read(MSR_PLATFORM_INFO);
> -   return (platform_info.hi >> 1) & 3;
> -}
> -
>  static void set_max_ratio(void)
>  {
> msr_t msr, perf_ctl;
> diff --git a/arch/x86/cpu/intel_common/cpu.c b/arch/x86/cpu/intel_common/cpu.c
> index 7d0ed73b4b6..1898903853f 100644
> --- a/arch/x86/cpu/intel_common/cpu.c
> +++ b/arch/x86/cpu/intel_common/cpu.c
> @@ -145,3 +145,23 @@ int cpu_configure_thermal_target(struct udevice *dev)
>
> return 0;
>  }
> +
> +void cpu_set_perf_control(uint clk_ratio)
> +{
> +   msr_t perf_ctl;
> +
> +   perf_ctl.lo = (clk_ratio & 0xff) << 8;
> +   perf_ctl.hi = 0;
> +   msr_write(MSR_IA32_PERF_CTL, perf_ctl);
> +   debug("CPU: frequency set to %d MHz\n", clk_ratio * INTEL_BCLK_MHZ);
> +}
> +
> +bool cpu_config_tdp_levels(void)
> +{
> +   msr_t platform_info;
> +
> +   /* Bits 34:33 indicate how many levels supported */
> +   platform_info = msr_read(MSR_PLATFORM_INFO);
> +
> +   return ((platform_info.hi >> 1) & 3) != 0;
> +}
> diff --git a/arch/x86/cpu/ivybridge/model_206ax.c 
> b/arch/x86/cpu/ivybridge/model_206ax.c
> index 3177ba3297f..2c8cedbaea2 100644
> --- a/arch/x86/cpu/ivybridge/model_206ax.c
> +++ b/arch/x86/cpu/ivybridge/model_206ax.c
> @@ -140,19 +140,16 @@ static const u8 power_limit_time_msr_to_sec[] = {
> [0x11] = 128,
>  };
>
> -int cpu_config_tdp_levels(void)
> +bool cpu_ivybridge_config_tdp_levels(void)
>  {
> struct cpuid_result result;
> -   msr_t platform_info;
>
> /* Minimum CPU revision */
> result = cpuid(1);
> if (result.eax < IVB_CONFIG_TDP_MIN_CPUID)
> return 0;

We should return false here, since the return value type is now changed to bool.

>
> -   /* Bits 34:33 indicate how many levels supported */
> -   platform_info = msr_read(MSR_PLATFORM_INFO);
> -   return (platform_info.hi >> 1) & 3;
> +   return cpu_config_tdp_levels();
>  }
>
>  /*
> @@ -213,7 +210,7 @@ void set_power_limits(u8 power_limit_1_time)
> msr_write(MSR_PKG_POWER_LIMIT, limit);
>
> /* Use nominal TDP values for CPUs with configurable TDP */
> -   if (cpu_config_tdp_levels()) {
> +   if (cpu_ivybridge_config_tdp_levels()) {
> msr = msr_read(MSR_CONFIG_TDP_NOMINAL);
> limit.hi = 0;
> limit.lo = msr.lo & 0xff;
> @@ -329,24 +326,20 @@ static void configure_dca_cap(void)
>
>  static void set_max_ratio(void)
>  {
> -   msr_t msr, perf_ctl;
> -
> -   perf_ctl.hi = 0;
> +   msr_t msr;
> +   uint ratio;
>
> /* Check for configurable TDP option */
> -   if (cpu_config_tdp_levels()) {
> +   if (cpu_ivybridge_config_tdp_levels()) {
> /* Set to nominal TDP ratio */
> msr = msr_read(MSR_CONFIG_TDP_NOMINAL);
> -   perf_ctl.lo = (msr.lo & 0xff) << 8;
> +   ratio = msr.lo & 0xff;
> } else {
> /* Platform Info bits 15:8 give max ratio */
> msr = msr_read(MSR_PLATFORM_INFO);
> -   perf_ctl.lo = msr.lo & 0xff00;
> +

Re: [U-Boot] [PATCH 054/126] x86: Add common functions for TDP and perf control

[Bin Meng]

On Mon, Oct 7, 2019 at 12:09 AM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > These functions are the same on modern Intel CPUs, so use common code to
> > set them.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/x86/cpu/broadwell/cpu.c  |  7 ++
> >  arch/x86/cpu/broadwell/cpu_full.c |  9 ---
> >  arch/x86/cpu/intel_common/cpu.c   | 20 +++
> >  arch/x86/cpu/ivybridge/model_206ax.c  | 25 +++
> >  arch/x86/cpu/ivybridge/northbridge.c  |  2 +-
> >  .../include/asm/arch-ivybridge/model_206ax.h  |  2 +-
> >  arch/x86/include/asm/cpu_common.h | 18 +
> >  7 files changed, 51 insertions(+), 32 deletions(-)
> >

[snip]

> > diff --git a/arch/x86/include/asm/cpu_common.h 
> > b/arch/x86/include/asm/cpu_common.h
> > index 3d093021ae6..e6a2a0eb3e5 100644
> > --- a/arch/x86/include/asm/cpu_common.h
> > +++ b/arch/x86/include/asm/cpu_common.h
> > @@ -1,5 +1,7 @@
> >  /* SPDX-License-Identifier: GPL-2.0 */
> >  /*
> > + * Common code for Intel CPUs
> > + *
> >   * Copyright (c) 2016 Google, Inc
> >   */
> >
> > @@ -56,4 +58,20 @@ int cpu_intel_get_info(struct cpu_info *info, int 
> > bclk_mz);
> >   */
> >  int cpu_configure_thermal_target(struct udevice *dev);
> >
> > +/**
> > + * cpu_set_perf_control() - Set the nominal CPU clock speed
> > + *
> > + * This sets the clock speed as a muiltiplier of BCLK

typo: multiplier

> > + *
> > + * @clk_ratio: Ratio to use
> > + */
> > +void cpu_set_perf_control(uint clk_ratio);
> > +
> > +/**
> > + * cpu_config_tdp_levels() - Check for configurable TDP option
> > + *
> > + * @return true if the CPU has configurable TDP (Thermal-desgn power)

typo: design

> > + */
> > +bool cpu_config_tdp_levels(void);
> > +
> >  #endif
> > --

Will fix these typos when applying.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mx6cuboxi fails to load u-boot.img

[Adam Ford]

On Sun, Oct 6, 2019 at 10:55 AM Baruch Siach  wrote:
>
> Hi Adam,
>
> On Sun, Oct 06 2019, Adam Ford wrote:
> > On Sun, Oct 6, 2019 at 7:48 AM Baruch Siach  wrote:
> >> On Sun, Oct 06 2019, Adam Ford wrote:
> >> > On Sun, Oct 6, 2019 at 7:30 AM Adam Ford  wrote:
> >> >>
> >> >> On Sun, Oct 6, 2019 at 7:22 AM Baruch Siach  wrote:
> >> >> >
> >> >> > Hi Adam,
> >> >> >
> >> >> > On Sun, Oct 06 2019, Adam Ford wrote:
> >> >> > > On Sun, Oct 6, 2019 at 5:23 AM Baruch Siach  
> >> >> > > wrote:
> >> >> > >> (Adding MMC and i.MX maintainers to Cc)
> >> >> > >>
> >> >> > >> On Fri, Sep 27 2019, Adam Ford wrote:
> >> >> > >> > On Fri, Sep 27, 2019 at 4:38 AM Jonathan Gray  
> >> >> > >> > wrote:
> >> >> > >> >>
> >> >> > >> >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote:
> >> >> > >> >> > Hi Vagrant,
> >> >> > >> >> >
> >> >> > >> >> > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian  >> >> > >> >> > debian.org> wrote:
> >> >> > >> >> > >
> >> >> > >> >> > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to 
> >> >> > >> >> > > load
> >> >> > >> >> > > u-boot.img from MMC:
> >> >> > >> >> > >
> >> >> > >> >> > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 
> >> >> > >> >> > > (Sep 24 2019 -
> >> >> > >> >> > > 08:03:23 +)
> >> >> > >> >> > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2
> >> >> > >> >> > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found
> >> >> > >> >> > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 
> >> >> > >> >> > > 1. error: -19
> >> >> > >> >> > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all 
> >> >> > >> >> > > boot devices
> >> >> > >> >> > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the 
> >> >> > >> >> > > board ###
> >> >> > >> >> >
> >> >> > >> >> > Thanks for reporting this issue.
> >> >> > >> >> >
> >> >> > >> >> > Unfortunately, I don't have access to my Cuboxi, so I am 
> >> >> > >> >> > adding Jon
> >> >> > >> >> > and Baruch on Cc.
> >> >> > >> >>
> >> >> > >> >> Works after reverting the following commit.
> >> >> > >> >>
> >> >> > >> > I am going to argue that making the board comply with DM_MMC is 
> >> >> > >> > why I
> >> >> > >> > needed to make the patch, because when booting from MMC2, the 
> >> >> > >> > function
> >> >> > >> > was returning MMC1 which was clearly not the boot source.
> >> >> > >> >
> >> >> > >> > If the boards that fail accept MMC2 as a response when booting 
> >> >> > >> > from
> >> >> > >> > MMC2, that seems like a bug on the indvidual boards.  Instead 
> >> >> > >> > they
> >> >> > >> > should setup their boot sequence to configure MMC2 when MMC2 is 
> >> >> > >> > the
> >> >> > >> > boot source.  Instead, it seems like some boards are configuring 
> >> >> > >> > MMC1
> >> >> > >> > with MMC2 info which only prolongs the conversion to DM_MMC.
> >> >> > >> >
> >> >> > >> > If we revert the patch, then boards like imx6_logic who rely 
> >> >> > >> > solely on
> >> >> > >> > device tree and DM_MMC for booting will have to manually 
> >> >> > >> > override the
> >> >> > >> > MMC driver in order to boot from MMC2, and that seems like a step
> >> >> > >> > backwards.  I would argue that this board should migrate to 
> >> >> > >> > DM_MMC and
> >> >> > >> > use the device tree to boot, and the problem should go away.
> >> >> > >>
> >> >> > >> I started working on migration to DM_MMC as you suggested. 
> >> >> > >> Unfortunately
> >> >> > >> I can't see how this solves the problem for Cubox-i/Hummingboard, 
> >> >> > >> nor in
> >> >> > >> the general case.
> >> >> > >>
> >> >> > >> The imx6_logic board happens to use only usdhc1 and usdhc2 for 
> >> >> > >> boot, and
> >> >> > >> both are always enabled. This matches perfectly to 
> >> >> > >> BOOT_DEVICE_MMC{1,2},
> >> >> > >> and their corresponding DT representation.
> >> >> > >>
> >> >> > >> However, the 'index' parameter in uclass_get_device() that is set
> >> >> > >> according to BOOT_DEVICE_MMC{1,2} selection has nothing to do with 
> >> >> > >> the
> >> >> > >> usdhcX sequence number. It simply returns the Nth probed SD/eMMC 
> >> >> > >> device
> >> >> > >> (see uclass_find_device()). In the case of Cubox-i/Hummingboard, 
> >> >> > >> usdhc1
> >> >> > >> is never used for boot, usdhc2 is always an SD card, and usdhc3 is 
> >> >> > >> an
> >> >> > >> optional eMMC. When booting from SD card, uclass_get_device(), 
> >> >> > >> returns
> >> >> > >> -ENODEV when eMMC is not available, or the eMMC device when it is
> >> >> > >> available. In both cases, boot fails.
> >> >> >
> >> >> > I think you missed this part. See more below.
> >> >> >
> >> >> > >> In addition, your patch returns BOOT_DEVICE_MMC2 only for usdhc2
> >> >> > >> boot. All others return BOOT_DEVICE_MMC1. What about usdhc{3,4}?
> >> >> > >>
> >> >> > >
> >> >> > > My patch only extended it to support MMC1 or MMC2.  I don't have
> >> >> > > hardware to test MMC3 or MMC4, nor where they defined in the boot
> >> >> > > table.
> >> >> > > The intenti

[U-Boot] [PATCH 0/2] Fix memory instability on ROCK64

[Simon South]

These two patches fix small issues with the Rockchip RK3328 SDRAM
driver that prevented my PINE64 ROCK64 from booting and running
normally using U-Boot's TPL [1].

The first patch updates the phy_dll_bypass_set() function to use the
correct units for its DDR-frequency parameter, which is already
specified in MHz and does not need converting. This issue caused the
DRAM controller to be misconfigured for all but the lowest memory
speeds.

The second patch fixes an apparent typo in phy_cfg() that caused the
DRAM controller's deskew registers to be loaded with incorrect values:
Instead of copying from the second 44-element portion of the
skew-value array the driver instead re-used a portion of the first.
This also produced instability.

With both these patches applied my ROCK64 boots and runs normally
using the U-Boot TPL and a memory frequency of either 800 or 933 MHz:
In both cases the "mtest" memory-test command runs indefinitely
without error, and I can boot into NetBSD successfully without the
kernel hanging or panicking.

[1] https://lists.denx.de/pipermail/u-boot/2019-September/384076.html

Simon South (2):
  ram: rk3328: Use correct frequency units in function
  ram: rk3328: Fix loading of skew values

 drivers/ram/rockchip/sdram_rk3328.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] ram: rk3328: Use correct frequency units in function

[Simon South]

Fix a pair of tests in phy_dll_bypass_set() that used incorrect units
for the DDR frequency, causing the DRAM controller to be misconfigured
in most cases.

Signed-off-by: Simon South 
---
 drivers/ram/rockchip/sdram_rk3328.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ram/rockchip/sdram_rk3328.c 
b/drivers/ram/rockchip/sdram_rk3328.c
index 656696ac3c..0541bbadf0 100644
--- a/drivers/ram/rockchip/sdram_rk3328.c
+++ b/drivers/ram/rockchip/sdram_rk3328.c
@@ -311,12 +311,12 @@ static void phy_dll_bypass_set(struct dram_info *dram, 
u32 freq)
setbits_le32(PHY_REG(phy_base, 0x56), 1 << 4);
clrbits_le32(PHY_REG(phy_base, 0x57), 1 << 3);
 
-   if (freq <= (400 * MHz))
+   if (freq <= 400)
/* DLL bypass */
setbits_le32(PHY_REG(phy_base, 0xa4), 0x1f);
else
clrbits_le32(PHY_REG(phy_base, 0xa4), 0x1f);
-   if (freq <= (680 * MHz))
+   if (freq <= 680)
tmp = 2;
else
tmp = 1;
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] ram: rk3328: Fix loading of skew values

[Simon South]

Fix a typo that caused incorrect values to be loaded into the DRAM
controller's deskew registers.

Signed-off-by: Simon South 
---
 drivers/ram/rockchip/sdram_rk3328.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ram/rockchip/sdram_rk3328.c 
b/drivers/ram/rockchip/sdram_rk3328.c
index 0541bbadf0..e84c9be6a2 100644
--- a/drivers/ram/rockchip/sdram_rk3328.c
+++ b/drivers/ram/rockchip/sdram_rk3328.c
@@ -394,7 +394,7 @@ static void phy_cfg(struct dram_info *dram,
copy_to_reg(PHY_REG(phy_base, 0x70),
&sdram_params->skew.cs0_dm0_skew[0], 44 * 4);
copy_to_reg(PHY_REG(phy_base, 0xc0),
-   &sdram_params->skew.cs0_dm1_skew[0], 44 * 4);
+   &sdram_params->skew.cs1_dm0_skew[0], 44 * 4);
 }
 
 static int update_refresh_reg(struct dram_info *dram)
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] [PATCH 1/1] Dockerfile: enable colored output

[Tom Rini]

On Sun, Oct 06, 2019 at 05:12:02PM +0200, Heinrich Schuchardt wrote:

> Set environment variables needed for colored output.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> Hello Tom,
> 
> I do not have my own Gitlab to test this. But we should get a more legible
> output with these variables set.

You can build your own images, push those and have your branch use them,
as that's how I test my own Docker changes.  If you can't easily do that
however, I'll give this a spin.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 10/15] Makefile: Query the SPL Fit Generator for its dependencies

[Auer, Lukas]

Hi Jean-Jacques,

On Fri, 2019-09-20 at 17:28 +0200, Jean-Jacques Hiblot wrote:
> To reduce the complexity of the Makefile, let the generator tell what its
> dependencies are. For this purpose use the "--deps" option.
> 

We recently added a generic FIT generator script for RISC-V, located at
arch/riscv/lib/mkimage_fit_opensbi.sh . Can you add the --deps option
to that script as well? It does not have any dependencies, so it can be
handled the same way as in the i.MX and sunxi FIT generator scripts.

Thanks,
Lukas

> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  Makefile   | 9 ++---
>  arch/arm/mach-imx/mkimage_fit_atf.sh   | 5 +
>  arch/arm/mach-rockchip/make_fit_atf.py | 7 +++
>  board/sunxi/mksunxi_fit_atf.sh | 4 
>  board/theobroma-systems/puma_rk3399/fit_spl_atf.sh | 6 ++
>  5 files changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 8a28740b22..1fa63d2a6b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1235,13 +1235,8 @@ U_BOOT_ITS = $(src)/$(SPL_FIT_SOURCE)
>  else
>  ifneq ($(SPL_FIT_GENERATOR),)
>  U_BOOT_ITS := u-boot.its
> -ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-imx/mkimage_fit_atf.sh")
> -U_BOOT_ITS_DEPS += u-boot-nodtb.bin
> -endif
> -ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py")
> -U_BOOT_ITS_DEPS += u-boot
> -endif
> -$(U_BOOT_ITS): $(U_BOOT_ITS_DEPS) FORCE
> +U_BOOT_ITS_DEPS += $(shell $(srctree)/$(SPL_FIT_GENERATOR) --deps $(BOARD))
> +$(U_BOOT_ITS): u-boot-nodtb.bin $(U_BOOT_ITS_DEPS) FORCE
>   $(srctree)/$(SPL_FIT_GENERATOR) \
>   $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@
>  endif
> diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh 
> b/arch/arm/mach-imx/mkimage_fit_atf.sh
> index 38c9858e84..4da7531954 100755
> --- a/arch/arm/mach-imx/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
> @@ -11,6 +11,11 @@
>  [ -z "$ATF_LOAD_ADDR" ] && ATF_LOAD_ADDR="0x0091"
>  [ -z "$BL33_LOAD_ADDR" ] && BL33_LOAD_ADDR="0x4020"
>  
> +
> +if [ x"$1" = x"--deps" ]; then
> + exit 0
> +fi
> +
>  if [ ! -f $BL31 ]; then
>   echo "ERROR: BL31 file $BL31 NOT found" >&2
>   exit 0
> diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
> b/arch/arm/mach-rockchip/make_fit_atf.py
> index b9a1988298..56fab4e330 100755
> --- a/arch/arm/mach-rockchip/make_fit_atf.py
> +++ b/arch/arm/mach-rockchip/make_fit_atf.py
> @@ -163,6 +163,10 @@ def unpack_elf(filename):
>  segments.append((index, e_entry, p_paddr, p_data))
>  return segments
>  
> +def show_deps_and_exit():
> + print("u-boot")
> + sys.exit(0)
> +
>  def main():
>  uboot_elf = "./u-boot"
>  fit_its = sys.stdout
> @@ -178,6 +182,9 @@ def main():
>  logging.warning(' BL31 file bl31.elf NOT found, resulting binary is 
> non-functional')
>  logging.warning(' Please read Building section in 
> doc/README.rockchip')
>  
> +if sys.argv[1] == "--deps":
> + show_deps_and_exit()
> +
>  opts, args = getopt.getopt(sys.argv[1:], "o:u:b:h")
>  for opt, val in opts:
>  if opt == "-o":
> diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
> index 88ad719747..c0ce4394e2 100755
> --- a/board/sunxi/mksunxi_fit_atf.sh
> +++ b/board/sunxi/mksunxi_fit_atf.sh
> @@ -5,6 +5,10 @@
>  #
>  # usage: $0  [ [  
> +if [ x"$1" = x"--deps" ]; then
> + exit 0
> +fi
> +
>  [ -z "$BL31" ] && BL31="bl31.bin"
>  
>  if [ ! -f $BL31 ]; then
> diff --git a/board/theobroma-systems/puma_rk3399/fit_spl_atf.sh 
> b/board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
> index 420e7daf4c..a7bada193a 100755
> --- a/board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
> +++ b/board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
> @@ -11,6 +11,12 @@
>  #
>  # usage: $0  [ [  
> +
> +if [ x"$1" = x"--deps" ]; then
> + echo "u-boot.dtb"
> + exit 0
> +fi
> +
>  [ -z "$BL31" ] && BL31="bl31.bin"
>  
>  if [ ! -f $BL31 ]; then
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 10/15] Makefile: Query the SPL Fit Generator for its dependencies

[Tom Rini]

On Sun, Oct 06, 2019 at 04:57:29PM +, Auer, Lukas wrote:
> Hi Jean-Jacques,
> 
> On Fri, 2019-09-20 at 17:28 +0200, Jean-Jacques Hiblot wrote:
> > To reduce the complexity of the Makefile, let the generator tell what its
> > dependencies are. For this purpose use the "--deps" option.
> > 
> 
> We recently added a generic FIT generator script for RISC-V, located at
> arch/riscv/lib/mkimage_fit_opensbi.sh . Can you add the --deps option
> to that script as well? It does not have any dependencies, so it can be
> handled the same way as in the i.MX and sunxi FIT generator scripts.

Can we please work on generalizing these scripts and either using
binman, updating binman as needed or coming up with a POSIX SH tool that
can do what needs doing?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] cmd: disable CMD_NVEDIT_EFI by default

[Tom Rini]

On Sun, Oct 06, 2019 at 03:53:42PM +0200, Heinrich Schuchardt wrote:

> The growth of the UEFI sub-system leads to build failures for systems with
> strict limits on the U-Boot image size.
> 
> CMD_NVEDIT_EFI supports displaying and editing of UEFI variables. The
> setting is not needed for booting. Disabling it by default reduces the
> size of the U-Boot image by 2 KiB.
> 
> Signed-off-by: Heinrich Schuchardt 

Thanks!

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include

[Dalon L Westergreen]

On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > From: Dalon Westergreen Generic handoff
> > > > devicetree include uses a header generated bythe qts-filter-a10.sh
> > > > script in mach-socfpga.  The scriptcreates the header based on
> > > > designspecific implementationsfor clock and pinmux configurations.
> > > 
> > > [...]
> > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > > 
> > > [...]
> > > > -   clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > compatible ="altr,socfpga-a10-clk-init";+   reg =
> > > > <0xffd04000 0x0200>;+   reg-names =
> > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > mainpll {+  vco0-psrc =;+ 
> > > > 
> > > > vco1-denom =;+   vco1-
> > > > numer =;
> > > 
> > > But these bits are board-specific , they shouldn't be in common DT.
> > 
> > This common dtsi requires that the top level u-boot.dtsi include the
> > boardspecific header.  The formatand #define names are in fact common.
> 
> OK, I now see what you're doing here. Can you explain that in a bit moredetail
> in the commit message ?
> Basically socfpga_board.h is included socfpga_board.dts , and then
> thepreprocessor correctly expands the values from socfpga_board.h in
> thesocfpga_board.dts , so this works for multiple boards too ?

Exactly.  Will add more detail in the commit message, and slim down the included
clocks in
the u-boot.dtsi
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] riscv: dts: Add hifive-unleashed-a00 dts from Linux

[Auer, Lukas]

Hi Jagan,

On Sun, 2019-09-29 at 13:12 +0530, Jagan Teki wrote:
> Sync the hifive-unleashed-a00 dts from Linux with
> below commit details:
> commit 11ae2d892139a1086f257188d457ddcb71ab5257
> Author: Paul Walmsley 
> Date:   Thu Jul 25 13:41:31 2019 -0700
> 
> riscv: dts: fu540-c000: drop "timebase-frequency"
> 
> Idea is to periodically sync the dts from Linux instead of
> tweeking internal changes one after another, so better not
> add any intermediate changes in between. This would help to
> maintain the dts files easy and meaningful since we are
> reusing devicetree files from Linux.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/riscv/dts/Makefile |   1 +
>  arch/riscv/dts/fu540-c000.dtsi  | 235 
>  arch/riscv/dts/hifive-unleashed-a00.dts |  88 +
>  3 files changed, 324 insertions(+)
>  create mode 100644 arch/riscv/dts/fu540-c000.dtsi
>  create mode 100644 arch/riscv/dts/hifive-unleashed-a00.dts
> 
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index f9cd606a9a..4f30e6936f 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  
>  dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
> +dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
>  
>  targets += $(dtb-y)
>  
> diff --git a/arch/riscv/dts/fu540-c000.dtsi b/arch/riscv/dts/fu540-c000.dtsi
> new file mode 100644
> index 00..42b5ec2231
> --- /dev/null
> +++ b/arch/riscv/dts/fu540-c000.dtsi
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/* Copyright (c) 2018-2019 SiFive, Inc */
> +
> +/dts-v1/;
> +
> +#include 
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "sifive,fu540-c000", "sifive,fu540";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + chosen {
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + compatible = "sifive,e51", "sifive,rocket0", "riscv";
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <128>;
> + i-cache-size = <16384>;
> + reg = <0>;
> + riscv,isa = "rv64imac";
> + status = "disabled";
> + cpu0_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu1: cpu@1 {
> + compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <1>;
> + riscv,isa = "rv64imafdc";
> + tlb-split;
> + cpu1_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu2: cpu@2 {
> + clock-frequency = <0>;
> + compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <32>;
> + mmu-type = "riscv,sv39";
> + reg = <2>;
> + riscv,isa = "rv64imafdc";
> + tlb-split;
> + cpu2_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu3: cpu@3 {
> + clock-frequency = <0>;
>

Re: [U-Boot] [PATCH 1/5] riscv: dts: Add hifive-unleashed-a00 dts from Linux

[Auer, Lukas]

Hi Jagan,

On Wed, 2019-10-02 at 15:57 +0530, Jagan Teki wrote:
> On Mon, Sep 30, 2019 at 3:35 PM Bin Meng  wrote:
> > Hi Jagan,
> > 
> > On Sun, Sep 29, 2019 at 3:42 PM Jagan Teki  
> > wrote:
> > > Sync the hifive-unleashed-a00 dts from Linux with
> > > below commit details:
> > > commit 11ae2d892139a1086f257188d457ddcb71ab5257
> > 
> > The latest commit should be:
> > 
> > commit c81007116bd23e9e2103c267184dc38d3acc1099
> > Author: Bin Meng 
> > Date:   Thu Sep 5 05:45:53 2019 -0700
> > 
> > riscv: dts: sifive: Drop "clock-frequency" property of cpu nodes
> > 
> > Could you use the latest one?
> 
> Syncing these commits other than the patch used one seems not working.
> SBI is failing to load u-boot-dtb.bin. I think this would some sort of
> cpu nodes changes on commits after
> riscv: dts: fu540-c000: drop "timebase-frequency"

I just tried it with the device tree from the commit Bin referred to
and did not have any problems starting U-Boot. Are you perhaps only
missing chosen/stdout-path?

Thanks,
Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include

[Simon Goldschmidt]

Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen:

On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:

On 10/6/19 1:19 AM, Dalon L Westergreen wrote:

On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:

On 10/5/19 12:30 AM, Dalon Westergreen wrote:

From: Dalon Westergreen <
dalon.westergr...@intel.com
 
>
Generic handoff devicetree include uses a header generated bythe qts-filter-
a10.sh script in mach-socfpga.  The scriptcreates the header based on design
specific implementationsfor clock and pinmux configurations.


[...]

diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
b/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi


[...]

-   clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
compatible =
"altr,socfpga-a10-clk-init";+ reg = <0xffd04000 0x0200>;+   
reg-names = "soc_clock_manager_OCP_SLV";  u-boot,dm-pre-
reloc;  mainpll {+  vco0-psrc =
;+  vco1-denom =
;+ vco1-numer =
;


But these bits are board-specific , they shouldn't be in common DT.


This common dtsi requires that the top level u-boot.dtsi include the board
specific header.  The format
and #define names are in fact common.


OK, I now see what you're doing here. Can you explain that in a bit more
detail in the commit message ?

Basically socfpga_board.h is included socfpga_board.dts , and then the
preprocessor correctly expands the values from socfpga_board.h in the
socfpga_board.dts , so this works for multiple boards too ?


Exactly. Will add more detail in the commit message, and slim down the 
included clocks in

the u-boot.dtsi


I'm (still) working on a series to bring gen5 completely to devicetree, 
so that the 'qts' directories can be removed. I chose a different 
approach however, in that I generated everything into a '-handoff.dtsi' 
file (*). I'd be happy if we could find a common mechanism for all 
socfpga sub-archs. How does S10/Agilex handle this?


(*): Gen5 has the downside that we're low on memory in SPL (regarding 
DM), and as we require large binary arrays there, I chose to encode the 
binary blob arrays in host byte order so that they could be used 
in-place instead of copying them from BE (dtb) to LE (stack/heap). Maybe 
that doesn't fit A10/S10/Agilex anyway?


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] common: spl: atf: support booting bl32 image

[Heiko Stuebner]

From: Joseph Chen 

Trusted-Firmware can also initialize a secure payload to use as a trusted
execution environment. In general for the arm64 case this is provided as
separate image and uboot is supposed to also place it in a predetermined
location in memory and add the necessary parameters to the ATF boot params.

So add the possibility to get this tee payload from the provided FIT image
and setup things as necessary.

Tested on a Rockchip PX30 with mainline TF-A, mainline OP-Tee (with pending
PX30 support) and mainline 5.4-rc1 Linux kernel.

Signed-off-by: Joseph Chen 
Signed-off-by: Heiko Stuebner 
---
changes in v2: set fdt address as param for tee

 common/spl/spl_atf.c | 49 +++-
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 4715f9d371..7a46ed6e6d 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -30,8 +30,11 @@ static struct bl31_params *bl2_to_bl31_params;
  *
  * @return bl31 params structure pointer
  */
-static struct bl31_params *bl2_plat_get_bl31_params(uintptr_t bl33_entry)
+static struct bl31_params *bl2_plat_get_bl31_params(uintptr_t bl32_entry,
+   uintptr_t bl33_entry,
+   uintptr_t fdt_addr)
 {
+   struct entry_point_info *bl32_ep_info;
struct entry_point_info *bl33_ep_info;
 
/*
@@ -49,16 +52,22 @@ static struct bl31_params 
*bl2_plat_get_bl31_params(uintptr_t bl33_entry)
SET_PARAM_HEAD(bl2_to_bl31_params->bl31_image_info,
   ATF_PARAM_IMAGE_BINARY, ATF_VERSION_1, 0);
 
-   /* Fill BL32 related information if it exists */
+
+   /* Fill BL32 related information */
bl2_to_bl31_params->bl32_ep_info = &bl31_params_mem.bl32_ep_info;
-   SET_PARAM_HEAD(bl2_to_bl31_params->bl32_ep_info, ATF_PARAM_EP,
-  ATF_VERSION_1, 0);
+   bl32_ep_info = &bl31_params_mem.bl32_ep_info;
+   SET_PARAM_HEAD(bl32_ep_info, ATF_PARAM_EP, ATF_VERSION_1,
+  ATF_EP_SECURE);
+
+   /* secure payload is optional, so set pc to 0 if absent */
+   bl32_ep_info->args.arg3 = fdt_addr;
+   bl32_ep_info->pc = bl32_entry ? bl32_entry : 0;
+   bl32_ep_info->spsr = SPSR_64(MODE_EL1, MODE_SP_ELX,
+DISABLE_ALL_EXECPTIONS);
+
bl2_to_bl31_params->bl32_image_info = &bl31_params_mem.bl32_image_info;
SET_PARAM_HEAD(bl2_to_bl31_params->bl32_image_info,
   ATF_PARAM_IMAGE_BINARY, ATF_VERSION_1, 0);
-#ifndef BL32_BASE
-   bl2_to_bl31_params->bl32_ep_info->pc = 0;
-#endif /* BL32_BASE */
 
/* Fill BL33 related information */
bl2_to_bl31_params->bl33_ep_info = &bl31_params_mem.bl33_ep_info;
@@ -86,13 +95,14 @@ static inline void raw_write_daif(unsigned int daif)
 
 typedef void (*atf_entry_t)(struct bl31_params *params, void *plat_params);
 
-static void bl31_entry(uintptr_t bl31_entry, uintptr_t bl33_entry,
-  uintptr_t fdt_addr)
+static void bl31_entry(uintptr_t bl31_entry, uintptr_t bl32_entry,
+  uintptr_t bl33_entry, uintptr_t fdt_addr)
 {
struct bl31_params *bl31_params;
atf_entry_t  atf_entry = (atf_entry_t)bl31_entry;
 
-   bl31_params = bl2_plat_get_bl31_params(bl33_entry);
+   bl31_params = bl2_plat_get_bl31_params(bl32_entry, bl33_entry,
+  fdt_addr);
 
raw_write_daif(SPSR_EXCEPTION_MASK);
dcache_disable();
@@ -100,7 +110,7 @@ static void bl31_entry(uintptr_t bl31_entry, uintptr_t 
bl33_entry,
atf_entry((void *)bl31_params, (void *)fdt_addr);
 }
 
-static int spl_fit_images_find_uboot(void *blob)
+static int spl_fit_images_find(void *blob, int os)
 {
int parent, node, ndepth;
const void *data;
@@ -122,7 +132,7 @@ static int spl_fit_images_find_uboot(void *blob)
if (!data)
continue;
 
-   if (genimg_get_os_id(data) == IH_OS_U_BOOT)
+   if (genimg_get_os_id(data) == os)
return node;
};
 
@@ -143,11 +153,21 @@ uintptr_t spl_fit_images_get_entry(void *blob, int node)
 
 void spl_invoke_atf(struct spl_image_info *spl_image)
 {
+   uintptr_t  bl32_entry = 0;
uintptr_t  bl33_entry = CONFIG_SYS_TEXT_BASE;
void *blob = spl_image->fdt_addr;
uintptr_t platform_param = (uintptr_t)blob;
int node;
 
+   /*
+* Find the OP-TEE binary (in /fit-images) load address or
+* entry point (if different) and pass it as the BL3-2 entry
+* point, this is optional.
+*/
+   node = spl_fit_images_find(blob, IH_OS_TEE);
+   if (node >= 0)
+   bl32_entry = spl_fit_images_get_entry(blob, node);
+
/*
 * Find the U-Boot binary (in /fit-images) load addreess or
 * entry point (if

[U-Boot] [PATCH v2 1/2] rockchip: make_fit_atf.py: allow inclusion of a tee binary

[Heiko Stuebner]

A trusted execution environment should also get loaded as loadable from
a fit image, so add the possibility to present a tee.elf to make_fit_atf.py
that then gets included as additional loadable into the generated its.

For ease of integration the additional loadable is created as atf_(x+1)
after all others to re-use core generation loops.

Tested against the combinations of 1-part-atf and multi-part-atf each
time with and without a tee binary present.

Signed-off-by: Heiko Stuebner 
---
changes in v2: none

 arch/arm/mach-rockchip/make_fit_atf.py | 52 +++---
 1 file changed, 46 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-rockchip/make_fit_atf.py 
b/arch/arm/mach-rockchip/make_fit_atf.py
index 585edcf9d5..3c045a5e17 100755
--- a/arch/arm/mach-rockchip/make_fit_atf.py
+++ b/arch/arm/mach-rockchip/make_fit_atf.py
@@ -63,6 +63,21 @@ def append_bl31_node(file, atf_index, phy_addr, elf_entry):
 file.write('\t\t};\n')
 file.write('\n')
 
+def append_tee_node(file, atf_index, phy_addr, elf_entry):
+# Append TEE DT node to input FIT dts file.
+data = 'tee_0x%08x.bin' % phy_addr
+file.write('\t\tatf_%d {\n' % atf_index)
+file.write('\t\t\tdescription = \"TEE\";\n')
+file.write('\t\t\tdata = /incbin/("%s");\n' % data)
+file.write('\t\t\ttype = "tee";\n')
+file.write('\t\t\tarch = "arm64";\n')
+file.write('\t\t\tos = "tee";\n')
+file.write('\t\t\tcompression = "none";\n')
+file.write('\t\t\tload = <0x%08x>;\n' % phy_addr)
+file.write('\t\t\tentry = <0x%08x>;\n' % elf_entry)
+file.write('\t\t};\n')
+file.write('\n')
+
 def append_fdt_node(file, dtbs):
 # Append FDT nodes.
 cnt = 1
@@ -115,15 +130,23 @@ def generate_atf_fit_dts_uboot(fit_file, uboot_file_name):
 index, entry, p_paddr, data = segments[0]
 fit_file.write(DT_UBOOT % p_paddr)
 
-def generate_atf_fit_dts_bl31(fit_file, bl31_file_name, dtbs_file_name):
+def generate_atf_fit_dts_bl31(fit_file, bl31_file_name, tee_file_name, 
dtbs_file_name):
 segments = unpack_elf(bl31_file_name)
 for index, entry, paddr, data in segments:
 append_bl31_node(fit_file, index + 1, paddr, entry)
+num_segments = len(segments)
+
+if tee_file_name:
+tee_segments = unpack_elf(tee_file_name)
+for index, entry, paddr, data in tee_segments:
+append_tee_node(fit_file, num_segments + index + 1, paddr, entry)
+num_segments = num_segments + len(tee_segments)
+
 append_fdt_node(fit_file, dtbs_file_name)
 fit_file.write(DT_IMAGES_NODE_END)
-append_conf_node(fit_file, dtbs_file_name, len(segments))
+append_conf_node(fit_file, dtbs_file_name, num_segments)
 
-def generate_atf_fit_dts(fit_file_name, bl31_file_name, uboot_file_name, 
dtbs_file_name):
+def generate_atf_fit_dts(fit_file_name, bl31_file_name, tee_file_name, 
uboot_file_name, dtbs_file_name):
 # Generate FIT script for ATF image.
 if fit_file_name != sys.stdout:
 fit_file = open(fit_file_name, "wb")
@@ -132,7 +155,7 @@ def generate_atf_fit_dts(fit_file_name, bl31_file_name, 
uboot_file_name, dtbs_fi
 
 fit_file.write(DT_HEADER)
 generate_atf_fit_dts_uboot(fit_file, uboot_file_name)
-generate_atf_fit_dts_bl31(fit_file, bl31_file_name, dtbs_file_name)
+generate_atf_fit_dts_bl31(fit_file, bl31_file_name, tee_file_name, 
dtbs_file_name)
 fit_file.write(DT_END)
 
 if fit_file_name != sys.stdout:
@@ -144,6 +167,13 @@ def generate_atf_binary(bl31_file_name):
 with open(file_name, "wb") as atf:
 atf.write(data)
 
+def generate_tee_binary(tee_file_name):
+if tee_file_name:
+for index, entry, paddr, data in unpack_elf(tee_file_name):
+file_name = 'tee_0x%08x.bin' % paddr
+with open(file_name, "wb") as atf:
+atf.write(data)
+
 def unpack_elf(filename):
 with open(filename, 'rb') as file:
 elf = file.read()
@@ -178,7 +208,14 @@ def main():
 logging.warning(' BL31 file bl31.elf NOT found, resulting binary is 
non-functional')
 logging.warning(' Please read Building section in doc/README.rockchip')
 
-opts, args = getopt.getopt(sys.argv[1:], "o:u:b:h")
+if "TEE" in os.environ:
+tee_elf = os.getenv("TEE")
+elif os.path.isfile("./tee.elf"):
+tee_elf = "./tee.elf"
+else:
+tee_elf = ""
+
+opts, args = getopt.getopt(sys.argv[1:], "o:u:b:t:h")
 for opt, val in opts:
 if opt == "-o":
 fit_its = val
@@ -186,14 +223,17 @@ def main():
 uboot_elf = val
 elif opt == "-b":
 bl31_elf = val
+elif opt == "-t":
+tee_elf = val
 elif opt == "-h":
 print(__doc__)
 sys.exit(2)
 
 dtbs = args
 
-generate_atf_fit_dts(fit_its, bl31_elf, uboot_elf, dtbs)
+generate_atf_fit_dts(fit_its, bl31_elf, tee_elf, uboot_elf, dtbs)
 generate_atf_binary(bl31_elf)
+generate_tee_binary(tee_elf)
 
 

[U-Boot] Pull request for UEFI sub-system for efi-2020-01-rc1

[Heinrich Schuchardt]

The following changes since commit dac51e9aaf6fd38298007b266feb6a80e9ec91ee:

  Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-10-05
20:06:58 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-01-rc1

for you to fetch changes up to 3b728f8728fa7c596d30ecd27ebb64d37a54a12e:

  cmd: disable CMD_NVEDIT_EFI by default (2019-10-06 16:02:37 +0200)


Pull request for UEFI sub-system for efi-2020-01-rc1

The major corrections in this pull request are:

Fixes for the SetVariable() boot service.
Device path node for NVMe drives.
Disable CONFIG_CMD_NVEDIT by default.

Gitlab CI and Travis CI showed no problems:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/845
https://travis-ci.org/xypron2/u-boot/builds/594214233


AKASHI Takahiro (1):
  cmd: env: fix a typo in a comment of do_env_set_efi()

Heinrich Schuchardt (4):
  efi_loader: appending to non-existent variable
  efi_selftest: correct SetVariable() test
  efi_selftest: testing read-only variables
  cmd: disable CMD_NVEDIT_EFI by default

Mian Yousaf Kaukab (1):
  Revert "ARM: tegra: reserve unmapped RAM so EFI doesn't use it"

Patrick Wildt (2):
  nvme: add accessor to namespace id and eui64
  efi: device path for nvme

 arch/arm/mach-tegra/board2.c  | 14 ---
 cmd/Kconfig   |  1 -
 cmd/nvedit_efi.c  |  2 +-
 drivers/nvme/nvme.c   | 13 ++
 drivers/nvme/nvme.h   |  1 +
 include/efi_api.h |  7 ++
 include/nvme.h| 12 +
 lib/efi_loader/efi_device_path.c  | 20 +++
 lib/efi_loader/efi_device_path_to_text.c  | 15 +++
 lib/efi_loader/efi_variable.c | 10 +---
 lib/efi_selftest/efi_selftest_variables.c | 41
---
 11 files changed, 91 insertions(+), 45 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] MAINTAINERS: Update my email address

[Tom Rini]

On Thu, Oct 03, 2019 at 06:32:11PM +0200, Maxime Ripard wrote:

> I'm not at bootlin anymore, and my mail address doesn't work any longer.
> 
> Signed-off-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd: host: fix seg fault at "host info"

[Tom Rini]

On Thu, Aug 22, 2019 at 04:47:39PM +0900, AKASHI Takahiro wrote:

> With the patch below applied, host_block_dev structure was switched
> to be placed in platdata rather than priv. The command "host info"
> must be aligned with this change. Otherwise, we will see "Segmentation
> Fault."
> 
> Fixes: 8f994c860d91 ("sandbox: blk: Switch to use platdata_auto_alloc_size 
> for the driver data")
> Signed-off-by: AKASHI Takahiro 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
> Reviewed-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: disable CONFIG_SPL_WDT for gen5 and a10

[Tom Rini]

On Sat, Oct 05, 2019 at 10:10:11PM +0200, Simon Goldschmidt wrote:

> These boards don't have a watchdog enabled in SPL, so make sure
> CONFIG_SPL_WDT is not enabled.
> 
> Fixes: commit 6874cb72204f ("watchdog: Split WDT from SPL_WDT")
> 
> Signed-off-by: Simon Goldschmidt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] gitlab-ci: fix typo 'plaforms'

[Tom Rini]

On Sun, Oct 06, 2019 at 12:26:16PM +0200, Heinrich Schuchardt wrote:

> %s/plaforms/platforms/g
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] tools: provide cbfstool

[Tom Rini]

On Sun, Oct 06, 2019 at 10:50:45PM +0200, Heinrich Schuchardt wrote:

> 'make tests' requires cbfstool. But this file is not built by U-Boot.
> 
> cbfstool can be built from https://github.com/coreboot/coreboot.git
> after copying some include files from
> https://github.com/coreboot/vboot.git but that is to much of a hassle.
> 
> Let's deliver cbfstool with U-Boot.
> 
> Signed-off-by: Heinrich Schuchardt 

I do not want to bundle yet another "thing" from another project that
will require re-syncing.  We already frankly have problems with too many
things getting out-of-date (and making a regular re-sync is on my TODO
list, but below removing python2 from our build).

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] cbfs: do not pack struct cbfs_cachenode

[Heinrich Schuchardt]

With the __packed attribute sandbox_defconfig cannot be compiled with GCC
9.2.1:

fs/cbfs/cbfs.c: In function ‘file_cbfs_fill_cache’:
fs/cbfs/cbfs.c:164:16: error: taking address of packed member of
‘struct cbfs_cachenode’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
  164 |   cache_tail = &new_node->next;
  |^~~

struct cbfs_cachenode is only an internal structure. So let's rearrange the
fields such that the structure is naturally packed and remove the __packed
attribute.

Signed-off-by: Heinrich Schuchardt 
---
 include/cbfs.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/cbfs.h b/include/cbfs.h
index 6d4c4d4b06..f3bc8ca24a 100644
--- a/include/cbfs.h
+++ b/include/cbfs.h
@@ -72,13 +72,13 @@ struct cbfs_fileheader {

 struct cbfs_cachenode {
struct cbfs_cachenode *next;
-   u32 type;
void *data;
-   u32 data_length;
char *name;
+   u32 type;
+   u32 data_length;
u32 name_length;
u32 attributes_offset;
-} __packed;
+};

 extern enum cbfs_result file_cbfs_result;

--
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include

[Dalon L Westergreen]

On Sun, 2019-10-06 at 20:05 +0200, Simon Goldschmidt wrote:
> Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen:
> > On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> > > On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > > > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > > > From: Dalon Westergreen  > > > > >  
> > > > > > Generic handoff devicetree include uses a header generated bythe
> > > > > > qts-filter-a10.sh script in mach-socfpga.  The scriptcreates the
> > > > > > header based on designspecific implementationsfor clock and pinmux
> > > > > > configurations.
> > > > > 
> > > > > [...]
> > > > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > > > > 
> > > > > [...]
> > > > > > -   clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > > > comp
> > > > > > atible ="altr,socfpga-a10-clk-init";+   reg =
> > > > > > <0xffd04000 0x0200>;+   reg-names =
> > > > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > > > mainpll {+  vco0-psrc 
> > > > > > =;+ 
> > > > > > vco1-denom =;+   
> > > > > > vco1-numer =;
> > > > > 
> > > > > But these bits are board-specific , they shouldn't be in common DT.
> > > > 
> > > > This common dtsi requires that the top level u-boot.dtsi include the
> > > > boardspecific header.  The formatand #define names are in fact common.
> > > 
> > > OK, I now see what you're doing here. Can you explain that in a bit
> > > moredetail in the commit message ?
> > > Basically socfpga_board.h is included socfpga_board.dts , and then
> > > thepreprocessor correctly expands the values from socfpga_board.h in
> > > thesocfpga_board.dts , so this works for multiple boards too ?
> > 
> > Exactly. Will add more detail in the commit message, and slim down the
> > included clocks inthe u-boot.dtsi
> 
> I'm (still) working on a series to bring gen5 completely to devicetree, so
> that the 'qts' directories can be removed. I chose a different approach
> however, in that I generated everything into a '-handoff.dtsi' file (*). I'd
> be happy if we could find a common mechanism for all socfpga sub-archs. How
> does S10/Agilex handle this?
> (*): Gen5 has the downside that we're low on memory in SPL (regarding DM), and
> as we require large binary arrays there, I chose to encode the binary blob
> arrays in host byte order so that they could be used in-place instead of
> copying them from BE (dtb) to LE (stack/heap). Maybe that doesn't fit
> A10/S10/Agilex anyway?

S10/Agilex are entirely different.  The onchip ram is loaded with any
configuration data bythe secure device manager.  There is no need to modify the
dts for any io/pll/bridgeconfiguration. 
A10 is better than cv/av in that is requires far less configuration data, and no
dataregarding the dram is needed.  Also, there is no binary parsing required for
extractingthe required data, hence the simple qts-filter-a10.sh.  
I think a -handoff.dtsi is a good approach, but why not do the same thing i do
here anduse a header file for the config data.  that way the -handoff.dtsi can
be common and theheader only needs to be included in the toplevel -u-boot.dtsi?
--dalon
> Regards,Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include

[Dalon L Westergreen]

On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > From: Dalon Westergreen Generic handoff
> > > > devicetree include uses a header generated bythe qts-filter-a10.sh
> > > > script in mach-socfpga.  The scriptcreates the header based on
> > > > designspecific implementationsfor clock and pinmux configurations.
> > > 
> > > [...]
> > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > > 
> > > [...]
> > > > -   clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > compatible ="altr,socfpga-a10-clk-init";+   reg =
> > > > <0xffd04000 0x0200>;+   reg-names =
> > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > mainpll {+  vco0-psrc =;+ 
> > > > 
> > > > vco1-denom =;+   vco1-
> > > > numer =;
> > > 
> > > But these bits are board-specific , they shouldn't be in common DT.
> > 
> > This common dtsi requires that the top level u-boot.dtsi include the
> > boardspecific header.  The formatand #define names are in fact common.
> 
> OK, I now see what you're doing here. Can you explain that in a bit moredetail
> in the commit message ?
> Basically socfpga_board.h is included socfpga_board.dts , and then
> thepreprocessor correctly expands the values from socfpga_board.h in
> thesocfpga_board.dts , so this works for multiple boards too ?

oh, and yes, it does work for multiple boards, i have already tested this.

--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] cbfs: do not pack struct cbfs_cachenode

[Bin Meng]

On Mon, Oct 7, 2019 at 6:37 AM Heinrich Schuchardt  wrote:
>
> With the __packed attribute sandbox_defconfig cannot be compiled with GCC
> 9.2.1:
>
> fs/cbfs/cbfs.c: In function ‘file_cbfs_fill_cache’:
> fs/cbfs/cbfs.c:164:16: error: taking address of packed member of
> ‘struct cbfs_cachenode’ may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
>   164 |   cache_tail = &new_node->next;
>   |^~~
>
> struct cbfs_cachenode is only an internal structure. So let's rearrange the
> fields such that the structure is naturally packed and remove the __packed
> attribute.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/cbfs.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 056/126] x86: Add new common CPU functions for turbo/burst mode

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> Add a few more CPU functions that are common on Intel CPUs. Also add
> attribution for the code source.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/intel_common/cpu.c   | 60 +++
>  arch/x86/include/asm/cpu_common.h | 49 +
>  2 files changed, 109 insertions(+)
>
> diff --git a/arch/x86/cpu/intel_common/cpu.c b/arch/x86/cpu/intel_common/cpu.c
> index 1898903853f..e4ce1b0703e 100644
> --- a/arch/x86/cpu/intel_common/cpu.c
> +++ b/arch/x86/cpu/intel_common/cpu.c
> @@ -1,12 +1,17 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (c) 2016 Google, Inc

nits: put this line after 2014 below?

> + * Copyright (C) 2014 Google Inc.
> + * Copyright (C) 2015-2018 Intel Corporation.
> + * Copyright (C) 2018 Siemens AG
> + * Some code taken from coreboot cpulib.c
>   */
>
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -165,3 +170,58 @@ bool cpu_config_tdp_levels(void)
>
> return ((platform_info.hi >> 1) & 3) != 0;
>  }
> +
> +void cpu_set_p_state_to_turbo_ratio(void)
> +{
> +   msr_t msr;
> +
> +   msr = msr_read(MSR_TURBO_RATIO_LIMIT);
> +   cpu_set_perf_control(msr.lo);
> +}
> +
> +enum burst_mode_t cpu_get_burst_mode_state(void)
> +{
> +   enum burst_mode_t state;
> +   int burst_en, burst_cap;
> +   msr_t msr;
> +   uint eax;
> +
> +   eax = cpuid_eax(0x6);
> +   burst_cap = eax & 0x2;
> +   msr = msr_read(MSR_IA32_MISC_ENABLE);
> +   burst_en = !(msr.hi & BURST_MODE_DISABLE);
> +
> +   if (!burst_cap && burst_en)
> +   state = BURST_MODE_UNAVAILABLE;
> +   else if (burst_cap && !burst_en)
> +   state = BURST_MODE_DISABLED;
> +   else if (burst_cap && burst_en)
> +   state = BURST_MODE_ENABLED;
> +   else
> +   state = BURST_MODE_UNKNOWN;
> +
> +   return state;
> +}
> +
> +void cpu_set_burst_mode(bool burst_mode)
> +{
> +   msr_t msr;
> +
> +   msr = msr_read(MSR_IA32_MISC_ENABLE);
> +   if (burst_mode)
> +   msr.hi &= ~BURST_MODE_DISABLE;
> +   else
> +   msr.hi |= BURST_MODE_DISABLE;
> +   msr_write(MSR_IA32_MISC_ENABLE, msr);
> +}
> +
> +void cpu_set_eist(bool eist_status)
> +{
> +   msr_t msr;
> +
> +   msr = msr_read(MSR_IA32_MISC_ENABLE);
> +   if (eist_status)
> +   msr.lo |= MISC_ENABLE_ENHANCED_SPEEDSTEP;
> +   else
> +   msr.lo &= ~MISC_ENABLE_ENHANCED_SPEEDSTEP;

There is no write back to the MSR_IA32_MISC_ENABLE.

> +}
> diff --git a/arch/x86/include/asm/cpu_common.h 
> b/arch/x86/include/asm/cpu_common.h
> index e6a2a0eb3e5..d5c09dccae0 100644
> --- a/arch/x86/include/asm/cpu_common.h
> +++ b/arch/x86/include/asm/cpu_common.h
> @@ -74,4 +74,53 @@ void cpu_set_perf_control(uint clk_ratio);
>   */
>  bool cpu_config_tdp_levels(void);
>
> +/** enum burst_mode_t - Burst-mode states */
> +enum burst_mode_t {
> +   BURST_MODE_UNKNOWN,
> +   BURST_MODE_UNAVAILABLE,
> +   BURST_MODE_DISABLED,
> +   BURST_MODE_ENABLED
> +};
> +
> +/*
> + * cpu_get_burst_mode_state() - Get the Burst/Turbo Mode State
> + *
> + * This reads MSR IA32_MISC_ENABLE 0x1A0
> + * Bit 38 - TURBO_MODE_DISABLE Bit to get state ENABLED / DISABLED.
> + * Also checks cpuid 0x6 to see whether Burst mode us supported.

nits: Burst -> burst, us -> is

> + *
> + * @return current burst mode status
> + */
> +enum burst_mode_t cpu_get_burst_mode_state(void);
> +
> +/**
> + * cpu_set_burst_mode() - Set CPU burst mode
> + *
> + * @burst_mode: true to enable burst mode, false to disable
> + */
> +void cpu_set_burst_mode(bool burst_mode);
> +
> +/**
> + * cpu_set_eist() - Enable Enhanced Intel Speed Step Technology
> + *
> + * @eist_status: true to enable EIST, false to disable
> + */
> +void cpu_set_eist(bool eist_status);
> +
> +/**
> + * cpu_set_p_state_to_turbo_ratio() - Set turbo ratio
> + *
> + * TURBO_RATIO_LIMIT MSR (0x1AD) Bits 31:0 indicates the
> + * factory configured values for of 1-core, 2-core, 3-core
> + * and 4-core turbo ratio limits for all processors.
> + *
> + * 7:0 -   MAX_TURBO_1_CORE
> + * 15:8 -  MAX_TURBO_2_CORES
> + * 23:16 - MAX_TURBO_3_CORES
> + * 31:24 - MAX_TURBO_4_CORES
> + *
> + * Set PERF_CTL MSR (0x199) P_Req with that value.
> + */
> +void cpu_set_p_state_to_turbo_ratio(void);
> +
>  #endif
> --

Other than above,

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 057/126] dm: core: Drop fdtdec_get_pci_addr()

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> This function ise effectively replaced by ofnode_read_pci_addr() which
> works with flat tree. Delete it to avoid code duplication.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/core/fdtaddr.c | 13 --
>  include/fdtdec.h   | 17 -
>  lib/fdtdec.c   | 54 --
>  3 files changed, 5 insertions(+), 79 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 060/126] x86: timer: Set up the timer in timer_early_get_count()

[Bin Meng]

Hi Simon,

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> This function can be called before the timer is set up. Make sure that the
> init function is called so that it works correctly.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/timer/tsc_timer.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
> index 9630036bc7f..85bdd95a819 100644
> --- a/drivers/timer/tsc_timer.c
> +++ b/drivers/timer/tsc_timer.c
> @@ -464,6 +464,8 @@ unsigned long notrace timer_early_get_rate(void)
>
>  u64 notrace timer_early_get_count(void)
>  {
> +   tsc_timer_ensure_setup(true);

Could you please specify why this is needed? I remember we had done
quite some fixes to the tsc_timer to support the early timer.

> +
> return rdtsc() - gd->arch.tsc_base;
>  }
>

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 059/126] x86: Allow the PCH and LPC uclasses to work with of-platdata

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> At present these uclasses assumes that they are used with a device tree.
> Update them to support of-platdata as well.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/lpc-uclass.c | 2 ++
>  drivers/pch/pch-uclass.c  | 2 ++
>  2 files changed, 4 insertions(+)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 058/126] sandbox: pci: Create a new sandbox_pci_read_bar() function

[Bin Meng]

On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
>
> The code in swapcase can be used by other sandbox drivers. Move it into a
> common place to allow this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/sandbox/include/asm/test.h | 15 +++
>  drivers/misc/Makefile   |  2 +-
>  drivers/misc/swap_case.c| 18 +++---
>  drivers/pci/pci-emul-uclass.c   | 20 
>  drivers/pci/pci_sandbox.c   |  1 +
>  5 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
> index 1b21af6bed7..cd2b9e3155d 100644
> --- a/arch/sandbox/include/asm/test.h
> +++ b/arch/sandbox/include/asm/test.h
> @@ -198,4 +198,19 @@ int sandbox_get_pch_spi_protect(struct udevice *dev);
>   */
>  int sandbox_get_pci_ep_irq_count(struct udevice *dev);
>
> +/**
> + * sandbox_pci_read_bar() - Read the BAR value for a read_config operation
> + *
> + * This is used in PCI emulators to read a base address reset. This has 
> special
> + * rules because when the register is set to 0x it can be used to
> + * discover the type and size of the BAR.
> + *
> + * @barval: Current value of the BAR
> + * @type: Type of BAR (PCI_BASE_ADDRESS_SPACE_IO or
> + * PCI_BASE_ADDRESS_MEM_TYPE_32)
> + * @size: Size of BAR in bytes
> + * @return BAR value to return from emulator
> + */
> +uint sandbox_pci_read_bar(u32 barval, int type, uint size);
> +
>  #endif
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 509c588582d..0001d105bae 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_TPL_)CROS_EC_LPC) += cros_ec_lpc.o
>  ifndef CONFIG_SPL_BUILD
>  obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
>  obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
> +obj-$(CONFIG_SANDBOX) += swap_case.o
>  endif
>
>  ifdef CONFIG_DM_I2C
> @@ -52,7 +53,6 @@ obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
>  obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
>  obj-$(CONFIG_QFW) += qfw.o
>  obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
> -obj-$(CONFIG_SANDBOX) += swap_case.o
>  obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o
>  obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o
>  obj-$(CONFIG_SMSC_SIO1007) += smsc_sio1007.o
> diff --git a/drivers/misc/swap_case.c b/drivers/misc/swap_case.c
> index 75fe6416707..11189d16c83 100644
> --- a/drivers/misc/swap_case.c
> +++ b/drivers/misc/swap_case.c
> @@ -139,25 +139,13 @@ static int sandbox_swap_case_read_config(struct udevice 
> *emul, uint offset,
> case PCI_BASE_ADDRESS_4:
> case PCI_BASE_ADDRESS_5: {
> int barnum;
> -   u32 *bar, result;
> +   u32 *bar;
>
> barnum = pci_offset_to_barnum(offset);
> bar = &plat->bar[barnum];
>
> -   result = *bar;
> -   if (*bar == 0x) {
> -   if (barinfo[barnum].type) {
> -   result = (~(barinfo[barnum].size - 1) &
> -   PCI_BASE_ADDRESS_IO_MASK) |
> -   PCI_BASE_ADDRESS_SPACE_IO;
> -   } else {
> -   result = (~(barinfo[barnum].size - 1) &
> -   PCI_BASE_ADDRESS_MEM_MASK) |
> -   PCI_BASE_ADDRESS_MEM_TYPE_32;
> -   }
> -   }
> -   debug("r bar %d=%x\n", barnum, result);
> -   *valuep = result;
> +   *valuep = sandbox_pci_read_bar(*bar, barinfo[barnum].type,
> +  barinfo[barnum].size);
> break;
> }
> case PCI_CAPABILITY_LIST:
> diff --git a/drivers/pci/pci-emul-uclass.c b/drivers/pci/pci-emul-uclass.c
> index a70c5e7633d..6e6172836a4 100644
> --- a/drivers/pci/pci-emul-uclass.c
> +++ b/drivers/pci/pci-emul-uclass.c
> @@ -43,6 +43,26 @@ int sandbox_pci_get_emul(struct udevice *bus, pci_dev_t 
> find_devfn,
> return *emulp ? 0 : -ENODEV;
>  }
>
> +uint sandbox_pci_read_bar(u32 barval, int type, uint size)
> +{
> +   u32 result;
> +
> +   result = barval;
> +   if (result == 0x) {
> +   if (type == PCI_BASE_ADDRESS_SPACE_IO) {
> +   result = (~(size - 1) &
> +   PCI_BASE_ADDRESS_IO_MASK) |
> +   PCI_BASE_ADDRESS_SPACE_IO;
> +   } else {
> +   result = (~(size - 1) &
> +   PCI_BASE_ADDRESS_MEM_MASK) |
> +   PCI_BASE_ADDRESS_MEM_TYPE_32;
> +   }
> +   }
> +
> +   return result;
> +}
> +
>  static int sandbox_pci_emul_post_probe(struct udevice *dev)
>  {
> struct sandbox_pci_emul_priv *priv = dev->uclass->priv;
> diff --git a/drivers/pci/pci_sandbox.c b/drivers/pci/pci_sandbox.c

Re: [U-Boot] [PATCH v3] cmd: env: extend "env [set|print] -e" to manage UEFI variables

[AKASHI Takahiro]

On Sat, Oct 05, 2019 at 08:53:39AM +0200, Heinrich Schuchardt wrote:
> On 10/4/19 3:20 AM, AKASHI Takahiro wrote:
> >With this patch, when setting UEFI variable with "env set -e" command,
> >we will be able to
> >- specify vendor guid with "-guid guid",
> >- specify variable attributes,  BOOTSERVICE_ACCESS, RUNTIME_ACCESS,
> >   respectively with "-bs" and "-rt",
> >- append a value instead of overwriting with "-a",
> >- use memory as variable's value instead of explicit values given
> >   at the command line with "-i address,size"
> >
> >If guid is not explicitly given, default value will be used.
> >
> >When "-at" is given, a variable should be authenticated with
> >appropriate signature database before setting or modifying its value.
> >(Authentication is not supported yet though.)
> 
> Didn't you remove this in v2?

It was an editorial error, which also existed in v2 commit message.

> >
> >Meanwhile, "env print -e," will be modified so that it will dump
> >a variable's value only if '-v' (verbose) is specified.
> >
> >Signed-off-by: AKASHI Takahiro 
> 
> This does not work as expected:
> 
> => setenv -e -guid 0123456789abcdef0123456789abcdef -bs ARGONAUT hello world
> => printenv -e
> OsIndicationsSupported:
> EFI_GLOBAL_VARIABLE_GUID: BS|RT, DataSize = 0x8
> PlatformLang:
> EFI_GLOBAL_VARIABLE_GUID: NV|BS|RT, DataSize = 0x6
> PlatformLangCodes:
> EFI_GLOBAL_VARIABLE_GUID: BS|RT, DataSize = 0x6
> RuntimeServicesSupported:
> EFI_GLOBAL_VARIABLE_GUID: BS|RT, DataSize = 0x2
> 
> Neither do I see an error nor is the variable set.

You have an incorrect guid format, so env_set_efi() should
return CMD_RET_USAGE, but mistakenly returns CMD_RET_FAILURE.

> The patch increases the size of u-boot.bin by 2216 bytes for qemu-arm64.
> Tom is always asking me how we can stop the size increase in the UEFI
> sub-system.
> 
> Why do we need this patch? This functionality is already available via
> the UEFI shell.

Such a question should have been made before initially "-e" option
has been introduced a long time ago.

* As far as we have "-e" option, this new patch is a natural extension.
* Why do we have to reply on external apps? We should have a minimum
  self-contained command set to manage UEFI as part of U-Boot.
* "-i" is used in secure boot pytest.

Thanks,
-Takahiro Akashi

> Just open the UEFI shell and run
> 
> Shell> setvar ARGONAUT -guid 01234567-89ab-cdef-0123-456789abcdef -rt
> =L"Hello world"
> Shell> exit
> 
> Best regards
> 
> Heinrich
> 
> 
> >---
> >Changes in v3 (Oct 4, 2019)
> >* add verbose messages when SetVariable() fails
> >
> >Changes in v2 (Sept 6, 2019)
> >* remove "-at" option
> >
> >---
> >  cmd/nvedit.c |  19 +++--
> >  cmd/nvedit_efi.c | 212 +++
> >  2 files changed, 190 insertions(+), 41 deletions(-)
> >
> >diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> >index 1cb0bc1460b9..1e542972db30 100644
> >--- a/cmd/nvedit.c
> >+++ b/cmd/nvedit.c
> >@@ -1387,7 +1387,7 @@ static char env_help_text[] =
> >  #endif
> > "env print [-a | name ...] - print environment\n"
> >  #if defined(CONFIG_CMD_NVEDIT_EFI)
> >-"env print -e [name ...] - print UEFI environment\n"
> >+"env print -e [-v] [name ...] - print UEFI environment\n"
> >  #endif
> >  #if defined(CONFIG_CMD_RUN)
> > "env run var [...] - run commands in an environment variable\n"
> >@@ -1399,7 +1399,8 @@ static char env_help_text[] =
> >  #endif
> >  #endif
> >  #if defined(CONFIG_CMD_NVEDIT_EFI)
> >-"env set -e name [arg ...] - set UEFI variable; unset if 'arg' not 
> >specified\n"
> >+"env set -e [-nv][-bs][-rt][-a][-i addr,size][-v] name [arg ...]\n"
> >+"- set UEFI variable; unset if '-i' or 'arg' not specified\n"
> >  #endif
> > "env set [-f] name [arg ...]\n";
> >  #endif
> >@@ -1428,8 +1429,9 @@ U_BOOT_CMD_COMPLETE(
> > "print environment variables",
> > "[-a]\n- print [all] values of all environment variables\n"
> >  #if defined(CONFIG_CMD_NVEDIT_EFI)
> >-"printenv -e [name ...]\n"
> >+"printenv -e [-v] [name ...]\n"
> > "- print UEFI variable 'name' or all the variables\n"
> >+"  \"-v\": verbose for signature database\n"
> >  #endif
> > "printenv name ...\n"
> > "- print value of environment variable 'name'",
> >@@ -1459,9 +1461,16 @@ U_BOOT_CMD_COMPLETE(
> > setenv, CONFIG_SYS_MAXARGS, 0,  do_env_set,
> > "set environment variables",
> >  #if defined(CONFIG_CMD_NVEDIT_EFI)
> >-"-e [-nv] name [value ...]\n"
> >+"-e [-guid guid][-nv][-bs][-rt][-a][-v]\n"
> >+"[-i addr,size name], or [name [value ...]]\n"
> > "- set UEFI variable 'name' to 'value' ...'\n"
> >-"  'nv' option makes the variable non-volatile\n"
> >+"  \"-guid\": set vendor guid\n"
> >+"  \"-nv\": set non-volatile attribute\n"
> >+"  \"-bs\": set boot-service attribute\n"
> >+"  \"-rt\": set runtime attribute\n"
> >+"  \"-a\": append-write\n"
> >+

Re: [U-Boot] [PATCH 041/126] iod: Enhance to support display of multiple values

[Bin Meng]

On Sat, Oct 5, 2019 at 11:18 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present the 'iod' command differs from 'md' in that it only shows a
> > single value. It is useful to see a dump of multiple values, particularly
> > when x86 peripherals contain register sets accessible via I/O ports.
> >
> > Enhance the command to match md.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  cmd/io.c | 84 +++-
> >  1 file changed, 65 insertions(+), 19 deletions(-)
> >
> > diff --git a/cmd/io.c b/cmd/io.c
> > index 79faf814ff7..2021a44b10f 100644
> > --- a/cmd/io.c
> > +++ b/cmd/io.c
> > @@ -11,6 +11,15 @@
> >  #include 
> >  #include 
> >
> > +/* Display values from last command.
>
> nits: wrong multi-line comment format
>
> > + * Memory modify remembered values are different from display memory.
>
> This comment does not apply as there is no "memory modify" in this context.
>
> > + */
> > +static ulong last_addr, last_size;
> > +static ulong last_length = 0x40;
> > +static ulong base_address;
> > +
> > +#define DISP_LINE_LEN  16
> > +
> >  /*
> >   * IO Display
> >   *
> > @@ -19,26 +28,63 @@
> >   */
> >  int do_io_iod(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> >  {
> > -   ulong addr;
> > -   int size;
> > -
> > -   if (argc != 2)
> > +   ulong addr, length, bytes;
> > +   u8 buf[DISP_LINE_LEN];
> > +   int size, todo;
> > +
> > +   /* We use the last specified parameters, unless new ones are
>
> nits: wrong multi-line comment format
>
> > +* entered.
> > +*/
> > +   addr = last_addr;
> > +   size = last_size;
> > +   length = last_length;
> > +
> > +   if (argc < 2)
> > return CMD_RET_USAGE;
> >
> > -   size = cmd_get_data_size(argv[0], 4);
> > -   if (size < 0)
> > -   return 1;
> > -
> > -   addr = simple_strtoul(argv[1], NULL, 16);
> > -
> > -   printf("%04x: ", (u16) addr);
> > -
> > -   if (size == 4)
> > -   printf("%08x\n", inl(addr));
> > -   else if (size == 2)
> > -   printf("%04x\n", inw(addr));
> > -   else
> > -   printf("%02x\n", inb(addr));
> > +   if ((flag & CMD_FLAG_REPEAT) == 0) {
> > +   /* New command specified.  Check for a size specification.
>
> nits: wrong multi-line comment format
>
> > +* Defaults to long if no or incorrect specification.
> > +*/
> > +   size = cmd_get_data_size(argv[0], 4);
> > +   if (size < 0)
> > +   return 1;
> > +
> > +   /* Address is specified since argc > 1 */
> > +   addr = simple_strtoul(argv[1], NULL, 16);
> > +   addr += base_address;
> > +
> > +   /* If another parameter, it is the length to display.
>
> nits: wrong multi-line comment format

Corrected these wrong multi-line comment format, and

>
> > +* Length is the number of objects, not number of bytes.
> > +*/
> > +   if (argc > 2)
> > +   length = simple_strtoul(argv[2], NULL, 16);
> > +   }
> > +
> > +   bytes = size * length;
> > +
> > +   /* Print the lines */
> > +   for (; bytes > 0; addr += todo) {
> > +   u8 *ptr = buf;
> > +   int i;
> > +
> > +   todo = min(bytes, (ulong)DISP_LINE_LEN);
> > +   for (i = 0; i < todo; i += size, ptr += size) {
> > +   if (size == 4)
> > +   *(u32 *)ptr = inl(addr + i);
> > +   else if (size == 2)
> > +   *(u16 *)ptr = inw(addr + i);
> > +   else
> > +   *ptr = inb(addr + i);
> > +   }
> > +   print_buffer(addr, buf, size, todo / size,
> > +DISP_LINE_LEN / size);
> > +   bytes -= todo;
> > +   }
> > +
> > +   last_addr = addr;
> > +   last_length = length;
> > +   last_size = size;
> >
> > return 0;
> >  }
> > @@ -69,7 +115,7 @@ int do_io_iow(cmd_tbl_t *cmdtp, int flag, int argc, char 
> > *const argv[])
> >  }
> >
> >  /**/
> > -U_BOOT_CMD(iod, 2, 0, do_io_iod,
> > +U_BOOT_CMD(iod, 3, 1, do_io_iod,
> >"IO space display", "[.b, .w, .l] address");
> >
> >  U_BOOT_CMD(iow, 3, 0, do_io_iow,
> > --
>
> Other than above issues,
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 042/126] arm: mxs: Correct CONFIG_SPL_NO_CPU_SUPPORT option

[Bin Meng]

On Sat, Oct 5, 2019 at 11:18 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present this is defined in Kconfig but there is a separate one in the
> > CONFIG whitelist. It looks like these are duplicates.
> >
> > Rename the non-Kconfig one and remove it from the whitelist.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/arm/cpu/arm926ejs/Makefile | 2 +-
> >  include/configs/mxs.h   | 2 +-
> >  scripts/config_whitelist.txt| 1 -
> >  3 files changed, 2 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 044/126] spl: Convert CONFIG_SPL_LIMIT to hex

[Bin Meng]

On Sat, Oct 5, 2019 at 11:18 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > This is currently a decimal value which is not as convenient or
> > meaningful. Also U-Boot tends to use hex everywhere.
> >
> > Convert this option to hex and add a comment for the size_check macro.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  Makefile| 10 +++---
> >  arch/arm/mach-socfpga/Kconfig   |  2 +-
> >  common/spl/Kconfig  |  2 +-
> >  configs/evb-rk3288_defconfig|  2 +-
> >  configs/tinker-rk3288_defconfig |  2 +-
> >  5 files changed, 11 insertions(+), 7 deletions(-)
> >
>
> Acked-by: Bin Meng 
>
> I can fix the commit summary issue (missing _SIZE, as pointed out by
> Simon Goldschmidt) when applying.

Fixed the typo in the commit title, and

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 043/126] spl: Allow tiny printf() to be controlled in SPL and TPL

[Bin Meng]

On Sat, Oct 5, 2019 at 11:18 PM Bin Meng  wrote:
>
> On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> >
> > At present there is only one control for this and it is used for both SPL
> > and TPL. But SPL might have a lot more space than TPL so the extra cost of
> > a full printf() might be acceptable.
> >
> > Split the option into two, providing separate SPL and TPL controls. The
> > TPL setting defaults to the same as SPL.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/arm/Kconfig  |  2 +-
> >  arch/arm/mach-omap2/Kconfig   |  6 +++---
> >  arch/arm/mach-rmobile/Kconfig |  2 +-
> >  arch/arm/mach-rmobile/Kconfig.32  | 14 ++---
> >  arch/arm/mach-socfpga/Kconfig |  4 ++--
> >  common/spl/Kconfig|  2 +-
> >  common/xyzModem.c |  2 +-
> >  configs/am335x_pdu001_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/sandbox_spl_defconfig |  2 +-
> >  drivers/gpio/gpio-uclass.c|  4 ++--
> >  drivers/mmc/mmc.c |  2 +-
> >  drivers/mtd/spi/sf-uclass.c   |  2 +-
> >  lib/Kconfig   | 20 +++
> >  lib/Makefile  |  2 +-
> >  18 files changed, 43 insertions(+), 31 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 005/126] dm: core: Don't include ofnode functions with of-platdata

[Bin Meng]

Hi Simon,

On Sun, Oct 6, 2019 at 5:15 PM Bin Meng  wrote:
>
> On Thu, Oct 3, 2019 at 8:48 PM Bin Meng  wrote:
> >
> > On Wed, Sep 25, 2019 at 10:58 PM Simon Glass  wrote:
> > >
> > > These functions cannot work with of-platdata since libfdt is not
> > > available. At present when dev_read_...() functions are used it produces
> > > error messages about ofnode which is confusing.
> > >
> > > Adjust the Makefile and header to produce an error message for the actual
> > > dev_read...() function which is called. This makes it easier to see what
> > > code needs to be converted for use with of-platdata.

As this commit message says, with this patch now it causes a large
number of ARM boards build break. See:
https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/16696
https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/jobs/16697

So this is intentional, but I think we should provide the build fix at
the same time to make gitlab-CI happy.

> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > >  drivers/core/Makefile | 4 +++-
> > >  include/dm/read.h | 3 +--
> > >  2 files changed, 4 insertions(+), 3 deletions(-)
> > >
> >
> > Reviewed-by: Bin Meng 
>
> applied to u-boot-x86/next, thanks!

I will have to drop this patch from the queue.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot