n't want to pay attention to out of tree patches.
> > Simon randomly responds to emails 'applied to sjg1/master' or something
> > along those lines, which further complicates things as people might think
> > their code got merged.
> >
>
> Me too. I do
/*
> * This only happens if image is somehow faulty so we start
> --
Doesn't this change the logic? Previously if you didn't set
fastboot_bootcmd you'd fall into the bootm path (if CONFIG_BOOTM was
enabled), with this, if CONFIG_CMDLINE is enabled then you will never
hit the bootm path.
--
Alex Kiernan
t;
Some notes I have from a previous life which may be useful, but I'm
afraid I've no way of checking these days:
* CONFIG_DEBUG_UART=y
* CONFIG_DEBUG_UART_BASE=0x44e09000
* CONFIG_DEBUG_UART_CLOCK=4800
* CONFIG_DEBUG_UART_OMAP=y
* CONFIG_DEBUG_UART_SHIFT=2
* CONFIG_DEBUG_UART_BOARD_INIT=y
* CONFIG_DEBUG_UART_ANNOUNCE=y
--
Alex Kiernan
On Sat, Aug 29, 2020 at 6:51 PM Marek Vasut wrote:
>
> On 8/29/20 4:14 PM, Alex Kiernan wrote:
> > On Thu, Aug 27, 2020 at 5:20 PM Alex Kiernan wrote:
> >>
> >> On Thu, Aug 27, 2020 at 2:03 PM Tom Rini wrote:
> >>>
> >>> On Thu, Aug 27, 20
On Thu, Aug 27, 2020 at 5:20 PM Alex Kiernan wrote:
>
> On Thu, Aug 27, 2020 at 2:03 PM Tom Rini wrote:
> >
> > On Thu, Aug 27, 2020 at 11:49:25AM +0200, Marek Vasut wrote:
> > > On 8/27/20 11:43 AM, Alex Kiernan wrote:
> > > > This reverts commit 0
On Thu, Aug 27, 2020 at 2:03 PM Tom Rini wrote:
>
> On Thu, Aug 27, 2020 at 11:49:25AM +0200, Marek Vasut wrote:
> > On 8/27/20 11:43 AM, Alex Kiernan wrote:
> > > This reverts commit 0f036bf4b87e6416f5c4d23865a62a62d9073c20.
> > >
> > > With this change app
rint ethaddr
ethaddr=00:00:00:00:00:00
Signed-off-by: Alex Kiernan
---
As I noted in my email, I can't see an immediately obvious way to make
this work as intended and given we're at -rc3, I think a revert is the
most appropriate way forward.
env/flags.c | 4 +---
1 file changed, 1 ins
return 0;
}
-#endif
+
switch (op) {
case env_op_delete:
if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_DELETE) {
But I think with that you'll get the message for variables which can
be overwritten, so still not what's intended.
--
Alex Kiernan
On Mon, Jun 1, 2020 at 1:55 PM Roman Kovalivskyi
wrote:
>
> On 27.05.20 15:56, Alex Kiernan wrote:
>
> > On Wed, May 27, 2020 at 12:14 PM Roman Kovalivskyi
> > wrote:
> >> From: Roman Stratiienko
> >>
> >> Android 10 adds support for dyna
2,8 @@ enum {
> FASTBOOT_COMMAND_CONTINUE,
> FASTBOOT_COMMAND_REBOOT,
> FASTBOOT_COMMAND_REBOOT_BOOTLOADER,
> + FASTBOOT_COMMAND_REBOOT_FASTBOOTD,
> + FASTBOOT_COMMAND_REBOOT_RECOVERY,
> FASTBOOT_COMMAND_SET_ACTIVE,
> #if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_FORMAT)
> FASTBOOT_COMMAND_OEM_FORMAT,
> @@ -79,6 +81,13 @@ void fastboot_okay(const char *reason, char *response);
> */
> int fastboot_set_reboot_flag(void);
>
> +/**
> + * fastboot_set_flag() - Set flag to indicate reboot-fastboot
> + *
> + * Set flag which indicates that system should reboot into specified mode.
> + */
> +int fastboot_set_flag(const char *command);
> +
> /**
> * fastboot_set_progress_callback() - set progress callback
> *
> --
> 2.17.1
>
--
Alex Kiernan
>>>> Hi Tom,
> >>>>>>>
> >>>>>>> On Tue, 5 May 2020 at 11:50, Tom Rini wrote:
> >>>>>>>>
> >>>>>>>> On Tue, May 05, 2020 at 06:39:58PM +0200, Marek Vasut wrote:
>
On Tue, May 5, 2020 at 7:41 PM Simon Glass wrote:
>
> Hi Tom,
>
> On Tue, 5 May 2020 at 11:50, Tom Rini wrote:
> >
> > On Tue, May 05, 2020 at 06:39:58PM +0200, Marek Vasut wrote:
> > > On 5/5/20 6:37 PM, Alex Kiernan wrote:
> > > > On T
On Tue, May 5, 2020 at 10:17 PM Michael Walle wrote:
>
> Hi all,
>
> Am 2020-05-05 20:41, schrieb Simon Glass:
> > Hi Tom,
> >
> > On Tue, 5 May 2020 at 11:50, Tom Rini wrote:
> >>
> >> On Tue, May 05, 2020 at 06:39:58PM +0200, Marek Vasut wro
On Tue, May 5, 2020 at 2:28 PM Marek Vasut wrote:
>
> On 5/5/20 3:22 PM, Alex Kiernan wrote:
> > On Mon, May 4, 2020 at 12:28 PM Tom Rini wrote:
> >>
> >> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote:
> >>
> >>> There is no reason
othing at all on the console, if I boot over ymodem
it stalls at 420k, before continuing to 460k. My guess is there's some
error going to the console at the 420k mark, but obviously it's lost
in the ymodem... I have two DTBs in the FIT image, 420k would about
align to the point between them.
--
Alex Kiernan
aviour for `gpio input` only.
Fixes: 4dbc107f4683 ("cmd: gpio: Correct do_gpio() return value")
Signed-off-by: Alex Kiernan
Signed-off-by: Alex Kiernan
Reviewed-by: Simon Glass
---
Changes in v2:
- add test
cmd/gpio.c | 7 ++-
test/py/tes
On Tue, Mar 10, 2020 at 12:37 PM Tom Rini wrote:
>
> On Tue, Mar 10, 2020 at 09:47:33AM +, Alex Kiernan wrote:
> > On Sat, Feb 8, 2020 at 12:06 AM Tom Rini wrote:
> > >
> > > On Sun, Jan 05, 2020 at 08:10:56PM +0100, Luka Kovacic wrote:
> > >
> >
aviour for `gpio input` only.
Fixes: 4dbc107f4683 ("cmd: gpio: Correct do_gpio() return value")
Signed-off-by: Alex Kiernan
---
cmd/gpio.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/gpio.c b/cmd/gpio.c
index 16c2cebb3d4b..b716f6f18b95 100644
--- a/cmd/gpi
ed-by: Robert Marko
>
> Applied to u-boot/master, thanks!
>
I just pulled in HEAD for a test build and our boot scripts are broken
with this gpio change - I don't see a way to get the value of a gpio
pin in a script now?
Whilst I agree what's there was wrong, I'm really not sure we can
change an existing interface like this.
--
Alex Kiernan
On Tue, Feb 11, 2020 at 10:22 AM Rasmus Villemoes
wrote:
>
> On 11/02/2020 10.54, Alex Kiernan wrote:
> > On Tue, Feb 11, 2020 at 9:49 AM Rasmus Villemoes
> > wrote:
> >>
> >> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
>
}
> +
> + while (1) {
> + destfd = mmap_fdt(cmdname, keydest, size_inc, &dest_blob,
> &dest_sbuf, false, false);
> + if (destfd < 0)
> + exit(EXIT_FAILURE);
> +
> + ret = info.crypto->add_verify_data(&info, dest_blob);
> +
> + munmap(dest_blob, dest_sbuf.st_size);
> + close(destfd);
> + if (!ret || ret != -ENOSPC)
> + break;
> + fprintf(stderr, ".dtb too small, increasing size by 1024
> bytes\n");
> + size_inc = 1024;
> + }
> +
> + if (ret) {
> + fprintf(stderr, "%s: Cannot add public key to FIT blob: %s\n",
> + cmdname, strerror(-ret));
> + exit(EXIT_FAILURE);
> + }
> +
> + exit(EXIT_SUCCESS);
> +}
> --
> 2.23.0
>
--
Alex Kiernan
VICE_MMC2)
spl_boot_list[0] = BOOT_DEVICE_MMC1;
else
spl_boot_list[0] = boot_device;
}
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
ar *name, u32
> mdio_base,
> return NULL;
> }
>
> - cpsw_mdio->regs = (struct cpsw_mdio_regs *)mdio_base;
> + cpsw_mdio->regs = (struct cpsw_mdio_regs *)(uintptr_t)mdio_base;
>
I'm missing something... the (uintptr_t) cast
create a "required" property in my signature block,
> then u-boot will require that the signature match. But if I don't
> have that, then it will happily boot an unsigned image (or even one
> that doesn't have any signature blocks).
>
> Am I missing something here
If flash_write fails, whilst we propagate this up to our caller, we need
to avoid swapping in the new file (if we're on a filesystem) in this
case.
Fixes: dbc34323796b ("tools: env: Implement atomic replace for filesystem")
Signed-off-by: Alex Kiernan
---
tools/env/fw_env.c
On Tue, May 21, 2019 at 10:14 AM Eugeniu Rosca wrote:
>
> Hi Lukasz,
>
> On Tue, May 21, 2019 at 10:02:34AM +0100, Alex Kiernan wrote:
> > On Tue, May 21, 2019 at 9:37 AM Lukasz Majewski wrote:
> > >
> > > Hi Alex,
> > >
> > > > On
it). Moreover there is OE/Yocto's
> recipe 'u-boot-fw-utils' which can be easily used and installed.
>
It's a long story... I'm constrained by historic choices, which makes
using the environment problematic. But you're right.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
mmunicate between
the kernel and U-Boot when I want to force a board through recovery,
but this looks like something that might well give me a better
interface.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
acked down to calling DM
functions before the DT was loaded (because we needed to probe GPIOs
in order to know which DT we wanted), obviously that wasn't useful,
but even with a heap of the size you've got here we were OOMing.
To figure out exactly where we'd got we it wrong we
On Wed, May 1, 2019 at 3:49 PM Tom Rini wrote:
>
> On Wed, May 01, 2019 at 07:58:27AM +, Alex Kiernan wrote:
> > This converts the following to Kconfig:
> >CONFIG_SUPPORT_EMMC_BOOT
> >
> > As requested by Michal Simek , these boards
> > have no eMMC
xilinx_zynqmp_zcu100_revC
xilinx_zynqmp_zcu102_rev1_0
xilinx_zynqmp_zcu102_revA
xilinx_zynqmp_zcu102_revB
xilinx_zynqmp_zcu104_revA
xilinx_zynqmp_zcu104_revC
xilinx_zynqmp_zcu106_revA
xilinx_zynqmp_zcu111_revA
Signed-off-by: Alex Kiernan
Acked-by: Lukasz Majewski
Acked-by: Patrick Delaunay
Acked-by: Ramon
On Thu, Apr 25, 2019 at 8:07 PM Michal Simek wrote:
>
> On 19. 04. 19 6:38, Alex Kiernan wrote:
> > This converts the following to Kconfig:
> >CONFIG_SUPPORT_EMMC_BOOT
> >
> > Signed-off-by: Alex Kiernan
> > ---
> > Green travis build:
> >
This converts the following to Kconfig:
CONFIG_SUPPORT_EMMC_BOOT
Signed-off-by: Alex Kiernan
---
Green travis build:
https://travis-ci.org/akiernan/u-boot/builds/521906850
Testing affected boards for configuration changes:
boards.cfg is up to date. Nothing to do.
Summary of 3 commits
RE dependent on the build.
Signed-off-by: Alex Kiernan
---
Green travis build:
https://travis-ci.org/akiernan/u-boot/builds/521570862
include/image.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/image.h b/include/image.h
index 765ffecee0a7..c8522189ebab 100
/arm/mach-omap2/built-in.o:(.data.usb0+0x24): undefined reference to
`musb_dsps_ops'
Reviewed-by: Hannes Schmelzer
Tested-by: Hannes Schmelzer
Signed-off-by: Alex Kiernan
---
Green Travis build:
https://travis-ci.org/akiernan/u-boot/builds/521570727
configs/am335x_boneblack_vboot_defc
t;firmware-1";
loadables = "firmware-1";
fdt = "fdt-1";
};
conf-2 {
description = "A335XHUB-0003";
firmware = "firmware-1";
loadables = "firmware-1";
fdt = "fdt-2";
};
};
};
Still digging...
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Migrate support for disable MUSB bulk split/combine to Kconfig
Green Travis build:
https://travis-ci.org/akiernan/u-boot/builds/519101867
Signed-off-by: Alex Kiernan
---
drivers/usb/musb-new/Kconfig | 9 +
include/configs/am335x_evm.h | 1 -
include/configs
h all header types to find
> one where image validation succeeds.
>
Doesn't this text want to be part of the changelog and not below the marker?
However, definitely fixes it up for me.
Tested-by: Alex Kiernan
--
Alex Kiernan
___
U-Boot mail
Where we have to compute partition names, rather than using a hardcoded
32 for the partition name length, replace with PART_NAME_LEN.
Signed-off-by: Alex Kiernan
---
drivers/fastboot/fb_mmc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b
ger than the available memory, so it needs to be done
> in blocks?
>
Convert to Android sparse format and use that? You still need the
sparse image to fit into memory though.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
hed. Total time: 0.003s
>
> Be more user friendly and output:
> - "partition not given" for [A-D]
> - "partition not found" for [E-F]
>
> Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
> Signed-off-by: Eugeniu Rosca
Acked-by: Alex Kiernan
On Wed, Mar 27, 2019 at 12:32 PM Eugeniu Rosca wrote:
>
> Hi Alex,
>
> Thanks for the precious comments. Some remarks below.
>
> On Wed, Mar 27, 2019 at 05:55:51AM +, Alex Kiernan wrote:
> > On Wed, Mar 27, 2019 at 5:44 AM Alex Kiernan wrote:
> > > On Wed
On Wed, Mar 27, 2019 at 5:44 AM Alex Kiernan wrote:
>
> On Wed, Mar 27, 2019 at 1:04 AM Eugeniu Rosca wrote:
> >
> > With eMMC partitioning [1], 'fastboot getvar has-slot:'
> > returns 'yes' only for 'system' and 'boot', while i
ocol out of sync
> +
> + strlcpy(name, part_name, sizeof(name) - 2);
> + strcat(name, "_a");
> +
> + if (fastboot_mmc_get_part_info(name, &dev_desc, &info, response) >= 0)
> fastboot_okay("yes", response);
> else
> fastboot_okay("no", response);
This will fail if you're building with CONFIG_FASTBOOT_FLASH_NAND.
Also fastboot_mmc_get_part_info() sends its own fastboot_fail so this
just isn't going to work in a failure case.
> --
> 2.21.0
>
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
rce.com/platform/system/core/+/a797479bd51c
> ("Fix fastboot variable name")
> [2] https://android.googlesource.com/platform/system/extras/+/72de393e118e3
> ("Bootloader verification for AndroidThings.")
>
> Fixes: f73a7df984a9 ("net: fastboot: Merge
On Thu, Mar 21, 2019 at 2:58 AM Marek Vasut wrote:
>
> On 3/20/19 8:52 PM, Alex Kiernan wrote:
> > If CONFIG_SPL_FIT_SIGNATURE is enabled and U-Boot is being loaded from UART
> > over Ymodem then we can't emit messages using printf() without causing
> > errors li
: Got 68 for sector ACK
Retry 0: NAK on sector
Ymodem sectors/kbytes sent: 3273/409kRetry 0: Got 23 for sector ACK
Retry 0: NAK on sector
Retry 0: Got 68 for sector ACK
Retry 0: NAK on sector
Use debug() rather than printf() to avoid sending messages on the serial
port.
Signed-off-by:
t; # Consistency checks
> # ---
>
> --
> 2.17.1
>
> _______
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Migrate support for disable MUSB bulk split/combine to Kconfig
Green Travis build:
https://travis-ci.org/akiernan/u-boot/builds/497722366
Signed-off-by: Alex Kiernan
---
drivers/usb/musb-new/Kconfig | 9 +
include/configs/am335x_evm.h | 1 -
include/configs
USB_MUSB_TI requires USB_MUSB_DSPS, failing at link time if it's not
selected:
drivers/usb/musb-new/built-in.o: In function
`ti_musb_host_ofdata_to_platdata':
drivers/usb/musb-new/ti-musb.c:193: undefined reference to `musb_dsps_ops'
Signed-off-by: Alex Kiernan
On Tue, Jan 15, 2019 at 11:04 PM Douglas Zobel
wrote:
>
> On Tue, Jan 15, 2019 at 4:12 AM Alex Kiernan wrote:
>>
>> On Mon, Jan 14, 2019 at 8:49 PM Douglas Zobel
>> wrote:
>> >
>> > I've made some changes to the fastboot handlers to meet my ne
nges to add UDP
support, my intention was that you'd implement oem command using
linker lists, at that point you can plug in whatever you need.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
gt; > Yes, that's a much clearer description...
>
> Frankly, your mail opened my eyes to a use case which was handled (I
> assume on purpose) with the old code - the "cross" boot with pinmux
> and devices.
>
> For example boot from UART (MLO/SPL) and then continue with eMMC (which
> require pinmux).
>
So I guess this needs something like a bloblist to communicate the
initialisation state between MLO/SPL and u-boot, which I've not the
faintest idea where to start on.
Horrible as they are, is a CONFIG symbol a possibility whilst we
figure out how to solve this properly?
I guess another option would be an additional two properties that give
the two behaviours, but that feels like something we don't want long
term.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
t; property?
>
Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess
that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL.
> The problem is not with lack of eMMC probing - it is with pinctrl nodes
> having "u-boot,dm-pre-reloc"
so long as I boot MLO from MMC (so
the MMC is probed, pinctrl setup), but if I boot from UART then I get
to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up
for the MMC.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Fri, Dec 7, 2018 at 12:30 PM Marek Vasut wrote:
>
> On 12/07/2018 01:29 PM, Alex Kiernan wrote:
> > On Fri, Dec 7, 2018 at 11:54 AM Marek Vasut wrote:
> >>
> >> On 12/07/2018 09:56 AM, Alex Kiernan wrote:
> >> [...]
> >>> +++ b/drivers/usb/
On Fri, Dec 7, 2018 at 11:54 AM Marek Vasut wrote:
>
> On 12/07/2018 09:56 AM, Alex Kiernan wrote:
> [...]
> > +++ b/drivers/usb/musb-new/musb_uboot.c
> > @@ -214,7 +214,7 @@ int musb_lowlevel_init(struct musb_host_data *host)
> > {
> > void *mbase;
>
ff-by: Alex Kiernan
---
drivers/usb/musb-new/Kconfig | 8
drivers/usb/musb-new/musb_uboot.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig
index f8f2205a62d3..5b9df5227961 100644
--- a/drivers/usb/mus
On Fri, Nov 9, 2018 at 7:09 AM Belisko Marek wrote:
>
> Hi Alex,
>
> On Tue, Oct 30, 2018 at 7:12 AM Alex Kiernan wrote:
> >
> > On Mon, Oct 29, 2018 at 11:36 PM Belisko Marek
> > wrote:
> > >
> > > Hi,
> > >
> > > I
Thanks a lot for any
> pointers.
>
FWIW I gave up trying to use the internal clock as I couldn't get it
to tick reliably (my suspicion was my hand modified board wasn't
actually driving the reset correctly) and instead switched to keeping
the bootcounter in SRAM.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
arning: Bad CRC, using default
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> + environment.dirty = 1;
> dev_current = 0;
>
unds reasonable to me... the reason I
ended up looking at this code was because I deployed a broken FIT
image, then got stuck here. But if bootm had returned with a failure I
could have done useful recovery actions without needing a reboot.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
If we fail to find the MMC boot device, report the number of the one
we were looking for in the error to aid diagnosis.
Signed-off-by: Alex Kiernan
---
common/spl/spl_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index
When the image which bootm is given can't be booted, call panic with
the error message rather than printf/hang so that we can recover from
broken images via a bootcount mechanism. If hang on failure is still
required then CONFIG_PANIC_HANG can still be enabled.
Signed-off-by: Alex Ki
> > gcc (Debian 8.2.0-4) 8.2.0
> > Copyright (C) 2018 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> So, first time it's being built, consequent runs usually failed.
>
I've seen this problem - building inside a VMware VM. I've always
found that logging out and back in appears to fix it, so possibly
something related to the session... I've similarly failed to figure
out what the problem is as it comes and goes.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
gt; >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> -
> >> >> > >> >> - debug("%s speed %u\n", __func__, max_hz);
> >> >> > >> >> - if (max_hz > CONFIG_SYS_SPI_CLK / 2)
> >> >> > >> >> - return -EINVAL;
> >> >> > >> >> -
> >> >> > >> >> - ds->freq = max_hz;
> >> >> > >> >>
> >> >> > >> >> return 0;
> >> >> > >> >> }
> >> >> > >> >>
> >> >> > >> >> -static int davinci_spi_set_mode(struct udevice *bus, uint mode)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> -
> >> >> > >> >> - debug("%s mode %u\n", __func__, mode);
> >> >> > >> >> - ds->mode = mode;
> >> >> > >> >> -
> >> >> > >> >> - return 0;
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -static int davinci_spi_claim_bus(struct udevice *dev)
> >> >> > >> >> -{
> >> >> > >> >> - struct dm_spi_slave_platdata *slave_plat =
> >> >> > >> >> - dev_get_parent_platdata(dev);
> >> >> > >> >> - struct udevice *bus = dev->parent;
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> -
> >> >> > >> >> - if (slave_plat->cs >= ds->num_cs) {
> >> >> > >> >> - printf("Invalid SPI chipselect\n");
> >> >> > >> >> - return -EINVAL;
> >> >> > >> >> - }
> >> >> > >> >> - ds->half_duplex = slave_plat->mode & SPI_PREAMBLE;
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_claim_bus(ds, slave_plat->cs);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -static int davinci_spi_release_bus(struct udevice *dev)
> >> >> > >> >> -{
> >> >> > >> >> - struct davinci_spi_slave *ds =
> >> >> > >> >> dev_get_priv(dev->parent);
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_release_bus(ds);
> >> >> > >> >> -}
> >> >> > >> >> +static const struct dm_spi_ops davinci_spi_ops = {
> >> >> > >> >> + .claim_bus = davinci_spi_claim_bus,
> >> >> > >> >> + .release_bus= davinci_spi_release_bus,
> >> >> > >> >> + .xfer = davinci_spi_xfer,
> >> >> > >> >> + .set_speed = davinci_spi_set_speed,
> >> >> > >> >> + .set_mode = davinci_spi_set_mode,
> >> >> > >> >> +};
> >> >> > >> >>
> >> >> > >> >> -static int davinci_spi_xfer(struct udevice *dev, unsigned int
> >> >> > >> >> bitlen,
> >> >> > >> >> - const void *dout, void *din,
> >> >> > >> >> - unsigned long flags)
> >> >> > >> >> +static int davinci_spi_probe(struct udevice *bus)
> >> >> > >> >> {
> >> >> > >> >> - struct dm_spi_slave_platdata *slave =
> >> >> > >> >> - dev_get_parent_platdata(dev);
> >> >> > >> >> - struct udevice *bus = dev->parent;
> >> >> > >> >> struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> + struct davinci_spi_platdata *plat = bus->platdata;
> >> >> > >> >> + ds->regs = plat->regs;
> >> >> > >> >> + ds->num_cs = plat->num_cs;
> >> >> > >> >>
> >> >> > >> >> - if (slave->cs >= ds->num_cs) {
> >> >> > >> >> - printf("Invalid SPI chipselect\n");
> >> >> > >> >> - return -EINVAL;
> >> >> > >> >> - }
> >> >> > >> >> - ds->cur_cs = slave->cs;
> >> >> > >> >> -
> >> >> > >> >> - return __davinci_spi_xfer(ds, bitlen, dout, din, flags);
> >> >> > >> >> -}
> >> >> > >> >> -
> >> >> > >> >> -static int davinci_spi_probe(struct udevice *bus)
> >> >> > >> >> -{
> >> >> > >> >> - /* Nothing to do */
> >> >> > >> >> return 0;
> >> >> > >> >> }
> >> >> > >> >>
> >> >> > >> >> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> >> >> > >> >
> >> >> > >> > Looking at other drivers, I wonder if this should be
> >> >> > >> > +#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> >> > >> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >> static int davinci_ofdata_to_platadata(struct udevice *bus)
> >> >> > >> >> {
> >> >> > >> >> - struct davinci_spi_slave *ds = dev_get_priv(bus);
> >> >> > >> >> - const void *blob = gd->fdt_blob;
> >> >> > >> >> - int node = dev_of_offset(bus);
> >> >> > >> >> + struct davinci_spi_platdata *plat = bus->platdata;
> >> >> > >> >> + fdt_addr_t addr;
> >> >> > >> >>
> >> >> > >> >> - ds->regs = devfdt_map_physmem(bus, sizeof(struct
> >> >> > >> >> davinci_spi_regs));
> >> >> > >> >> - if (!ds->regs) {
> >> >> > >> >> - printf("%s: could not map device address\n",
> >> >> > >> >> __func__);
> >> >> > >> >> + addr = devfdt_get_addr(bus);
> >> >> > >> >> + if (addr == FDT_ADDR_T_NONE)
> >> >> > >> >> return -EINVAL;
> >> >> > >> >> - }
> >> >> > >> >> - ds->num_cs = fdtdec_get_int(blob, node, "num-cs", 4);
> >> >> > >> >> +
> >> >> > >> >> + plat->regs = (struct davinci_spi_regs *)addr;
> >> >> > >> >> + plat->num_cs = fdtdec_get_int(gd->fdt_blob,
> >> >> > >> >> dev_of_offset(bus), "num-cs", 4);
> >> >> > >> >>
> >> >> > >> >> return 0;
> >> >> > >> >> }
> >> >> > >> >>
> >> >> > >> >> -static const struct dm_spi_ops davinci_spi_ops = {
> >> >> > >> >> - .claim_bus = davinci_spi_claim_bus,
> >> >> > >> >> - .release_bus= davinci_spi_release_bus,
> >> >> > >> >> - .xfer = davinci_spi_xfer,
> >> >> > >> >> - .set_speed = davinci_spi_set_speed,
> >> >> > >> >> - .set_mode = davinci_spi_set_mode,
> >> >> > >> >> -};
> >> >> > >> >> -
> >> >> > >> >> static const struct udevice_id davinci_spi_ids[] = {
> >> >> > >> >> { .compatible = "ti,keystone-spi" },
> >> >> > >> >> { .compatible = "ti,dm6441-spi" },
> >> >> > >> >> { .compatible = "ti,da830-spi" },
> >> >> > >> >> { }
> >> >> > >> >> };
> >> >> > >> >> +#endif
> >> >> > >> >>
> >> >> > >> >> U_BOOT_DRIVER(davinci_spi) = {
> >> >> > >> >> .name = "davinci_spi",
> >> >> > >> >> .id = UCLASS_SPI,
> >> >> > >> >> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> >> >> > >> >
> >> >> > >> > Like above, should this be:
> >> >> > >> > +#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> >> > >> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> >> > >> >
> >> >> > >> > With limited SPL resources, I cannot build OF_CONTROL in SPL and
> >> >> > >> > disabling OF_CONTROL in SPL doesn't build either.
> >> >> > >> > With the modification, I can build with OF_PLATDATA enabled.
> >> >> >
> >> >> > Is it possible to enable DM_SPI in SPL? da850evm_direct_nor_defconfig
> >> >> > is able to build since it has it.
> >> >>
> >> >> Enabling DM_SPI in SPL starts to grow, hence my other comments about
> >> >> SPL_OF_PLATDATA in order to make it fit into SPL.
> >> >> da850evm_direct_nor_defconfig does not enable SPL, but it does enable
> >> >> DM_SPI.
> >> >> I had to get the NOR expansion board in order to try it. I'm trying
> >> >> to get it to work now, but for some reason, I'm having difficulty
> >> >> booting the stock da850evm_direct_nor_defconfig
> >> >>
> >> >> It would be easiest if we could have both a DM_SPI and non DM_SPI
> >> >> version of the driver so it can fit into SPL or the ability to disable
> >> >> SPI in SPL. I am experimenting with the latter. Several drivers
> >> >> offer the option to be disabled in SPL, so I'm experimenting with that
> >> >> to save space in SPL.
> >> >>
> >> >
> >> > I was able to verify your code works for the
> >> > da850evm_direct_nor_defconfig version which doesn't use SPL.
> >> > I spent a significant amount of time yesterday trying to get SPL to
> >> > work, but just enabling SPL and disabling
> >> > all drivers except serial, I was not able to boot, so I think
> >> > something is wrong with DM and SPL. I don't have
> >> > a debugger at home for this board, so I'll need to get one from work
> >> > to further troubleshoot.
> >>
> >> I don't think it is much difficult to get serial up here. I made few
> >> changes for serial and spi platdata for SPL. If haven't try these
> >> please check the same and better change proper clock value for uart if
> >> added one is improper.
> >>
> >> >
> >> > I don't think any DA850/L138/AM1808 board uses DM in SPL, so I think
> >> > it would be best to maintain both DM
> >> > and non-DM code bases for now until we're able to support DM in SPL.
> >>
> >> But the whole idea is to drop nod-dm SPI as much as possible.
> >
> >
> > What your saying makes sense.
> >>
> >>
> >> [1]
> >> http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/spi-dm-migrate
> >
> >
> > I am traveling today, but I will try to look at that tomorrow. I did
> > something similar already without success, but I will try again with your
> > patch to see if it's any better.
> >
> > Is there a document somewhere that shows the order of operations during
> > SPL? I'm wondering if some of the SPL Davinci code should be refactored to
> > make sure the hardware is ready in the order that SPL is expecting it when
> > used with DM.
> >
>
> Your patch adding the UART stuff and enabling DM still didn't work.
> As soon as I enable DM in SPL, I no longer get any of the SPL text
> stuff that normally gets displayed immediately on boot. I will try to
> take a look at the suggestion from Simon Goldschmidt to see if I can
> adapt any of his work to the Davinci platform.
>
In case it's of use as another line to explore, we had the same
problem, which we eventually tracked down to some board detection code
which doing GPIO bashing using gpio_get_value (and friends) which with
SPL_DM ended up using a lot more RAM than we had with
SPL_SYS_MALLOC_SIMPLE. In truth the problem was actually slightly
worse because the board detection was before DM was initialised so the
GPIOs it was attempting to interrogate just failed... so we're now
just doing raw GPIO to do the board detect. But fixing the OOM at
least got us to the point where we could figure out what was actually
wrong.
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Wed, Aug 1, 2018 at 11:41 AM Alex Kiernan wrote:
>
> I've long been trying to convert our board (AM3352) to all DM, after
> knocking out lots of problems, I've run into one I can't seem to
> configure my way around, when I enable SPL_OF_CONTROL.
>
> We have
Hi Johann
On Wed, Aug 1, 2018 at 2:18 PM Alex Kiernan wrote:
>
> On Wed, Aug 1, 2018 at 12:30 PM Johann Neuhauser
> wrote:
> >
> > Hello Alex,
> >
> > have you tried to set "u-boot,spl-boot-order" in choosen node?
> >
> > Take a look into:
tigate!
> Best regards
>
> Johann Neuhauser
>
> -Ursprüngliche Nachricht-
> Von: U-Boot [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Alex Kiernan
> Gesendet: Mittwoch, 1. August 2018 12:42
> An: u-boot ; Simon Glass
> Betreff: [U-Boot] Converting to
err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, &dev);
if (!err)
*mmcp = mmc_get_mmc_dev(dev);
#else
But that feels like a pretty fundamental change to make across every
board and I've no real idea if that would even be the right thing to
do
in
there).
Would making that timeout configurable be a crazy thing to do, or are
these devices which we're trying to use just broken and we should
avoid them. Given the timeout's down in a driver, I assume other
drivers have the same 1s timeout?
--
Alex Kiernan
___
On Fri, Jul 27, 2018 at 1:26 AM Tom Rini wrote:
>
> On Thu, Jul 26, 2018 at 09:31:08AM +0100, Alex Kiernan wrote:
> > On Fri, Jul 20, 2018 at 11:34 PM Tom Rini wrote:
> > >
> > > On Thu, Jul 05, 2018 at 12:38:15PM +, Alex Kiernan wrote:
> > >
> >
On Fri, Jul 20, 2018 at 11:34 PM Tom Rini wrote:
>
> On Thu, Jul 05, 2018 at 12:38:15PM +, Alex Kiernan wrote:
>
> > The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the
> > beginning, but the meaning of it has changed over time. Allow the
> > d
: 1947c2d2a0 ("bootcount: flush after storing the bootcounter")
Signed-off-by: Alex Kiernan
---
drivers/bootcount/bootcount.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/bootcount/bootcount.c b/drivers/bootcount/bootcount.c
index a3162c97ed..
CONFIG_BOOTDELAY has been migrated to Kconfig, but cl-som-imx7 was
missed. We can just delete the assignments as the config already has
the correct value.
Signed-off-by: Alex Kiernan
---
include/configs/cl-som-imx7.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/configs/cl-som
et reboot limit
03: Migrate bootlimit to Kconfig
- display5_factory: bootlimit=3
Signed-off-by: Alex Kiernan
Reviewed-by: Lukasz Majewski
---
Changes in v3:
- Rebase
- Add Lukasz' Reviewed-by
Changes in v2:
- include display5 in the migration to Kconfig
configs/calimain_defco
Add ability to set environment bootlimit from Kconfig
Signed-off-by: Alex Kiernan
---
Changes in v3: None
Changes in v2: None
drivers/bootcount/Kconfig | 8
include/env_default.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/bootcount/Kconfig b/drivers
This patch series adds the bootlimit environment variable to Kconfig
and migrates users to it.
Changes in v3:
- Rebase
- Add Lukasz' Reviewed-by
Changes in v2:
- include display5 in the migration to Kconfig
Alex Kiernan (2):
Add BOOTCOUNT_BOOTLIMIT to set reboot limit
Migrate bootlim
On Thu, Jul 19, 2018 at 2:26 PM Maxime Ripard wrote:
>
> On Wed, Jul 18, 2018 at 08:15:23PM +0100, Alex Kiernan wrote:
> > On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote:
>
On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard
wrote:
>
> On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote:
> > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki
> > wrote:
> > >
> > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard
> > > wrot
efault 1 if ARCH_SUNXI && !DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1
> >> + default 2 if ARCH_SUNXI && DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1
> >
> > It'd be better to be fixed properly, instead of just relying on a
> > broken index.
>
> I don't think we can't do anything with this now, since this INDEX
> more rely on SPL for pinctrl enablement. if you have any suggestion
> please share.
Would another answer (at least for this specific case) to change the
fastboot code so it doesn't need the device number in advance? Given
we get device names along the lines of 'mmcsda1', we could parse out
the 'a' to figure out the device number (and then use the alias code
so your board can expose a portable name).
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Sun, Jul 15, 2018 at 10:36 AM Prabhakar Kushwaha
wrote:
>
>
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alex Kiernan
> > Sent: Saturday, July 14, 2018 1:30 PM
> > To: u-boot@lists.denx.de
> > Cc: Thoma
ig share a SYS_CONFIG_NAME,
but only display5_defconfig enables CONFIG_BOOTCOUNT_LIMIT, so we fail to
set bootlimit= in display5_factory_defconfig. This is okay because the
display5_factory_defconfig doesn't need to have it set, as it is only
meant to prepare the board in the factory.
Signed-off-b
This patch series adds the bootlimit environment variable to Kconfig
and migrates users to it.
Changes in v2:
- include display5 in the migration to Kconfig
Alex Kiernan (2):
Add BOOTCOUNT_BOOTLIMIT to set reboot limit
Migrate bootlimit to Kconfig
configs/brppt1_mmc_defconfig
Add ability to set environment bootlimit from Kconfig
Signed-off-by: Alex Kiernan
---
Changes in v2: None
drivers/bootcount/Kconfig | 8
include/env_default.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index
anyone have any suggestions?
>
From memory I just grabbed the 17.10 deb and installed that on 18.04:
http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.6-1_amd64.deb
Shout if that doesn't work and I'll dig some more.
--
Alex Kiernan
___
Extend BOOTDELAY help text to cover its additional usage within the
bootmenu command.
Signed-off-by: Alex Kiernan
---
common/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/common/Kconfig b/common/Kconfig
index 4c7a1a9af8..81e88ea77c 100644
--- a/common/Kconfig
+++ b/common
hat will take precedence (as before).
Signed-off-by: Alex Kiernan
---
include/env_default.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/env_default.h b/include/env_default.h
index 54d8124793..bd600cfa44 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@
ted, var A is removed from the
> current environnement.
> the example for this is basically: env import 0xaddr varA varB varC
>
> What I suggested is to modify 3 and 4) to the following:
> 3) himport_r WITH a list of variables (vars!=NULL) and with flag = 0:
> = import the va
On Mon, Jul 2, 2018 at 3:25 AM Tom Rini wrote:
>
> On Fri, Jun 29, 2018 at 09:19:34PM -0700, Simon Glass wrote:
> > +Tom
> >
> > Hi Alex,
> >
> > On 29 June 2018 at 02:31, Alex Kiernan wrote:
> > >
> > > I've just been digging into a
as far back as I've gone), but we've then changed the
behaviours of the bootdelay values in (the commit I was looking at was
2fbb8462b0e18893b4b739705db047ffda82d4fc from Mon Jun 27 16:23:01 2016
+0900, but I'm not sure that's really the right one)
I think we should change th
When sourcing a FIT format script, if we've not been told the unit name
to use, look for a default property at the root of /images to work out
which unit we should use.
Signed-off-by: Alex Kiernan
---
cmd/source.c | 31 ++-
1 file changed, 26 insertions(
When generating timestamps in signatures, use imagetool_get_source_date()
so we can be overridden by SOURCE_DATE_EPOCH to generate reproducible
images.
Signed-off-by: Alex Kiernan
---
include/image.h| 3 ++-
tools/fit_image.c | 3 ++-
tools/image-host.c | 34
So we can use imagetool_get_source_date() from callers who do not have
the image tool params struct, just pass in the command name for the error
message.
Signed-off-by: Alex Kiernan
---
tools/default_image.c | 2 +-
tools/fit_image.c | 3 ++-
tools/imagetool.c | 4 ++--
tools
images (like we have inside
/configurations for bootable images) be a reasonable approach? Trying
to add the full configuration machinery feels over the top (though I'm
wondering if down the road we want signed scripts if that might
preclude it).
--
Alex Kiernan
_
should say something different?
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
When building without FASTBOOT_FLASH we don't include the intermediate
update callback to keep the client alive, so ensure we don't try setting
it here.
Signed-off-by: Alex Kiernan
---
net/fastboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/fastboot.c b/net/fastbo
When the `mmc hwpartition` command is disabled, remove the associated help
text.
Signed-off-by: Alex Kiernan
---
cmd/mmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index c2ee2d9c0a..3920a1836a 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -935,6 +935,7
amp;& !CONFIG_IS_ENABLED(SPL_BUILD)) || \
> +(CONFIG_IS_ENABLED(SPL_BLOCK_CACHE) && CONFIG_IS_ENABLED(SPL_BUILD))
Assuming I read it right, you shouldn't need all the &&/|| gyrations, just:
#if CONFIG_IS_ENABLED(BLOCK_CACHE)
Should get you what you want.
> /**
> * blkcache_read() - attempt to read a set of blocks from cache
> *
> --
> 2.17.1
>
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Sat, Jun 9, 2018 at 3:04 PM Adam Ford wrote:
>
> On Sat, Jun 9, 2018 at 8:26 AM Alex Kiernan wrote:
> >
> > On Fri, Jun 8, 2018 at 9:48 PM Adam Ford wrote:
> > >
> > > When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> > > some
1 - 100 of 452 matches
Mail list logo
