Re: [U-Boot] [PATCH v2 2/2] regulator: bd718x7: support ROHM BD71837 and BD71847 PMICs
Hello Simon and thanks again for taking the time to check this =)
On Wed, 2019-04-24 at 17:58 -0600, Simon Glass wrote:
> HI Matti,
>
> On Wed, 24 Apr 2019 at 06:37, Matti Vaittinen
> wrote:
> >
> > BD71837 and BD71847 is PMIC intended for powering single-core,
> > dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847
> > is used for example on NXP imx8mm EVK.
> >
> > Add regulator driver for ROHM BD71837 and BD71847 PMICs.
> > BD71837 contains 8 bucks and 7 LDOS. BD71847 is reduced
> > version containing 6 bucks and 6 LDOs. Voltages for DVS
>
> This is great info and I think it should be in your Kconfig help -
> i.e.a bit more detail in your description of the chip.
Good idea. I'll do so in the next version.
> > +static int bd718x7_probe(struct udevice *dev)
> > +{
> > + int ret;
> > + u8 unlock;
> > +
> > + /* Unlock the PMIC regulator control before probing the
> > children */
> > + ret = pmic_reg_read(dev, BD718XX_REGLOCK);
> > + if (ret < 0) {
> > + debug("%s: %s Failed to read lock register, error
> > %d\n",
> > + __func__, dev->name, ret);
> > + return ret;
> > + }
> > +
> > + unlock = ret;
> > + unlock &= ~(BD718XX_REGLOCK_PWRSEQ | BD718XX_REGLOCK_VREG);
> > +
> > + ret = pmic_reg_write(dev, BD718XX_REGLOCK, unlock);
>
> Can you use pmic_clrsetbits() ?
Sure. I'll fix this too. Makes this much nicer.
> > index 00..060e6efe74
> > --- /dev/null
> > +++ b/drivers/power/regulator/bd71837.c
> > @@ -0,0 +1,469 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2019 ROHM Semiconductors
> > + *
> > + * ROHM BD71837 regulator driver
> > + */
> > +
> > +#include
> > +#include
> > +#include
>
> Drop this?
errno.h? I return -EINVAL from few of the functions. Or do you mean
i2c.h? I think that can be dropped, thanks.
>
> > +#include
> > +#include
> > +#include
> > +#include
>
> Put above power/pmic to keep ordering
I'll do that.
> >
> > +static int vrange_find_value(struct bd71837_vrange *r, u8 sel,
>
> Can you use uint instea of u8?
I'll replace u8 with uint8_t for all occurrences in this file. I
personally prefer uint8_t. I've got this u8 infection from the linux
kernel code where u8 seems to be preferred =)
> > +
> > +static int bd71837_set_value(struct udevice *dev, int uvolt)
> > +{
> > + u8 sel;
> > + u8 range;
>
> and here
>
> > + int i;
> > + int not_found = 1;
>
> I think the logic would be easier if you used 'found'
I see your point =) not_found became not_found just because return
value 0 from vrange_find_selector() (or pretty much any other function
I write) means success. So direct assignment to variable made it
'not_found' :] But "double negation" (!not_) is indeed a bit
difficult. I'll change this too.
>
> > + struct bd71837_platdata *plat = dev_get_platdata(dev);
> > +
> > + /*
> > +* An under/overshooting may occur if voltage is changed
> > for other
> > +* regulators but buck 1,2,3 or 4 when regulator is
> > enabled. Prevent
> > +* change to protect the HW
> > +*/
> > + if (!plat->dvs)
> > + if (bd71837_get_enable(dev)) {
> > + pr_err("Only DVS bucks can be changed when
> > enabled\n");
> > + return -EINVAL;
> > + }
> > +
> > + for (i = 0; i < plat->numranges; i++) {
> > + struct bd71837_vrange *r = >ranges[i];
> > +
> > + not_found = vrange_find_selector(r, uvolt, );
> > + if (!not_found) {
> > + unsigned int tmp;
> > +
> > + /*
> > +* We require exactly the requested value
> > to be
> > +* supported - this can be changed later if
> > needed
> > +*/
> > + range = r->rangeval;
> > + not_found = vrange_find_value(r, sel,
> > );
> > + if (!not_found && tmp == uvolt)
> > + break;
> > + not_found = 1;
> > + }
> > + }
> > +
> > + if (not_found)
> > + return -EINVAL;
> > +
> > + sel <<= ffs(plat->volt_mask) - 1;
> > +
> > + if (plat->rangemask)
> > + sel |= range;
> > +
> > + return pmic_clrsetbits(dev->parent, plat->volt_reg, plat-
> > >volt_mask |
> > + plat->rangemask, sel);
> > +}
Best Regards
Matti Vaittinen
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit
(Thanks for the translation Simon)
___
U-Boot mailing list
[U-Boot] [PATCH 1/1] efi_loader: parameter check CreateEventEx()
CreateEvent() and CreateEventEx() should check that a notify function is provided for either of EVT_NOTIFY_SIGNAL or EVT_NOTIFY_WAIT. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_boottime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 601b0a2cb8..a72cbe1559 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -618,7 +618,7 @@ efi_status_t efi_create_event(uint32_t type, efi_uintn_t notify_tpl, } if ((type & (EVT_NOTIFY_WAIT | EVT_NOTIFY_SIGNAL)) && - (is_valid_tpl(notify_tpl) != EFI_SUCCESS)) + (!notify_function || is_valid_tpl(notify_tpl) != EFI_SUCCESS)) return EFI_INVALID_PARAMETER; evt = calloc(1, sizeof(struct efi_event)); -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: turris_omnia: Use thumb instructions in SPL to save space
With the latest changes to the drivers (SPI_FLASH_SPANSION etc), Travis reports that the SPL image is too big. Let's use the thumb instructions in SPL to save some space and make the image fit again. Signed-off-by: Stefan Roese Cc: Baruch Siach Cc: Marek Behun --- configs/turris_omnia_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index 5ef3548647..a528a9b5bc 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_SPL_SYS_THUMB_BUILD=y CONFIG_ARCH_MVEBU=y CONFIG_SYS_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y @@ -7,13 +8,13 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_TURRIS_OMNIA=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL=y +CONFIG_NR_DRAM_BANKS=2 CONFIG_DEBUG_UART_BASE=0xd0012000 CONFIG_DEBUG_UART_CLOCK=25000 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_NR_DRAM_BANKS=2 CONFIG_BOOTDELAY=3 CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_MISC_INIT_R=y @@ -40,9 +41,9 @@ CONFIG_ENV_SPI_MAX_HZ=5000 CONFIG_SPL_OF_TRANSLATE=y CONFIG_SCSI_AHCI=y CONFIG_ATSHA204A=y +CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_MV=y -CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHY_MARVELL=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/9] Revert "pico-imx7d: Add LCD support"
Hi Jun,
On Wed, Apr 24, 2019 at 11:53 PM Jun Nie wrote:
> It blocks boot up with default defconfig. I see it is suggested to be
> reverted in mailist weeks ago. I thought you guys knew about it.
Please keep in mind that the rationale of a patch must always be provided.
In this case the issue is related to the limit of the current that the
host PC USB port can provide.
Please see the following commit for detaisl:
commit 00102ae52055e294ac37ae1380f37620f4a8bb26
Author: Fabio Estevam
Date: Wed Mar 27 20:03:39 2019 -0300
pico-imx7d: README: Recommend the usage of a USB hub
Since commit 9e3c0174da842 ("pico-imx7d: Add LCD support") we started to
notice some hangs in U-Boot.
There is not an issue on such commit per se, but due to the LCD support
the current drawn is increased and this may cause issues when powering
pico-imx7d-pi from USB.
Some computers may be a bit strict with USB current draw and will
shut down their ports if the draw is too high.
The solution for that is to use an externally powered USB hub between the
board and the host computer.
Add such recommendation to the README file.
Signed-off-by: Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal
Hi Bryan,
Em ter, 23 de abr de 2019 às 07:20, Bryan O'Donoghue
escreveu:
>
> Use __sec_set_jr_context_normal() to set job-ring ownership rather than the
> current in-line array walk.
>
> Signed-off-by: Bryan O'Donoghue
> ---
> drivers/crypto/fsl/jr.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 7b13aa4a61..65982b8369 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -616,7 +616,6 @@ int sec_init_idx(uint8_t sec_idx)
> {
> ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> uint32_t mcr = sec_in32(>mcfgr);
> - uint32_t jrown_ns;
> int i;
We may also need to remove this variable otherwise we get build warning below:
drivers/crypto/fsl/jr.c: In function 'sec_init_idx':
drivers/crypto/fsl/jr.c:625:6: warning: unused variable 'i' [-Wunused-variable]
int i;
^
Thanks for submitting this patch set.
I couldn't get encrypted boot working in my first attempt, doing the
exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl:
assign job-rings to non-TrustZone") reverted works fine.
I will take a better look in your patch set and let you know if I find
something.
Best Regards,
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] firmware: ti_sci: Fix TISCI mailbox receive timeout handling
On 25/04/19 12:50 AM, Andreas Dannenberg wrote:
> An earlier commit converted the TISCI receive timeouts to be specified
> in ms rather than us however it failed to take this change into account
> when passing the actual timeout to be used when invoking the mailbox
> receive API. This leads to the actual timeout to be 1,000 times shorter
> than expected and as a result certain TISCI operations would fail.
>
> Fix the issue by converting the timeout declared in ms to us on the fly
> as expected by the respective API.
>
> Fixes: fd6b40b1ba20 ("firmware: ti_sci: Add support for NAVSS resource
> management")
> Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
>
> Found this issue through bisecting the u-boot tree while maintaining my
> yet-to-be-submitted-upstream system firmware loader series current, which
> would cause SYSFW PM init to time out and the AM654x board to constantly
> reset. The TI "ti-u-boot-2019.01" tree has this change already built-in
> (it appears like when "firmware: ti_sci: Add support for NAVSS resource
> management" was originally submitted upstream this change was missed).
>
> Regards, Andreas
>
>
> drivers/firmware/ti_sci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index d47d22fff3..d72dd73f3b 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -158,7 +158,7 @@ static inline int ti_sci_get_response(struct ti_sci_info
> *info,
> int ret;
>
> /* Receive the response */
> - ret = mbox_recv(chan, msg, info->desc->max_rx_timeout_ms);
> + ret = mbox_recv(chan, msg, info->desc->max_rx_timeout_ms * 1000);
> if (ret) {
> dev_err(info->dev, "%s: Message receive failed. ret = %d\n",
> __func__, ret);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/9] pico-imx7d: Add device tree for pico-imx7d
Fabio Estevam 于2019年4月24日周三 下午6:31写道： > > On Wed, Apr 24, 2019 at 1:00 AM Jun Nie wrote: > > > > Copy device tree files from Linux directly. > > > > Signed-off-by: Jun Nie > > There is a series from Joris that does the pico-mx7d DM conversion. When is that series expected to be merged? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: the dm of SPL does not support very well on spiboot
Hi,simon Thank you for your replay! > -Original Message- > From: Simon Glass > Sent: 2019年4月25日 7:59 > To: Chuanhua Han > Cc: eugen.hris...@microchip.com; Ruchika Gupta ; > Shengzhou Liu ; tr...@konsulko.com; Prabhakar > Kushwaha ; u-boot@lists.denx.de; > simon.k.r.goldschm...@gmail.com; ma...@denx.de; s...@denx.de; > kever.y...@rock-chips.com; alex.kier...@gmail.com > Subject: [EXT] Re: the dm of SPL does not support very well on spiboot > > Caution: EXT Email > > Hi Chuanhua, > > On Sun, 21 Apr 2019 at 09:00, Chuanhua Han > wrote: > > > > Hi,all > > > > > > > > 1. When I tested and compiled some spiboot boards, I found that the > board compilation of these spiflash boot configurations failed. > > > > These boards all support the dm mode of spl, and the boot mode used is > spiboot. > > > > Here is the board configuration I compiled: > > > > > > > > configs/sama5d2_xplained_spiflash_defconfig > > > > configs/sama5d3xek_spiflash_defconfig > > > > configs/sama5d4_xplained_spiflash_defconfig > > > > configs/sama5d4ek_spiflash_defconfig > > > > > > > > eg: > > > > sama5d4ek_spiflash_defconfig > > > > > > > > CC spl/drivers/clk/at91/clk-master.o > > > > drivers/spi/spi.c: In function ‘spi_do_alloc_slave’: > > > > CC spl/lib/libfdt/fdt_ro.o > > > > CC spl/lib/libfdt/fdt_region.o > > > > drivers/spi/spi.c:34:8: error: ‘struct spi_slave’ has no member named > ‘bus’ > > > >slave->bus = bus; > > > > ^~ > > > > drivers/spi/spi.c:35:8: error: ‘struct spi_slave’ has no member named ‘cs’ > > > >slave->cs = cs; > > > > ^~ > > > > scripts/Makefile.build:278: recipe for target 'spl/drivers/spi/spi.o' > > failed > > > > > > > > So far there seems to be no spiboot board that compiles successfully and > works properly. > > > > > > > > I would like to know how to configure uboot in SPL using dm spiboot to > ensure normal compilation. > > > > > > > > === > > > > > > > > 2. When I compile d with T2080QDS_SPIFLASH_defconfig, a similar > error message appears. > > > > I have included the following options in the configuration file: > > > > CONFIG_DM_SPI=y > > > > CONFIG_DM_SPI_FLASH=y > > > > > > > > The following is the error log: > > > > $ make T2080QDS_SPIFLASH_defconfig& -j32 all > > > > HOSTCC scripts/basic/fixdep > > > > HOSTCC scripts/kconfig/conf.o > > > > … > > > > LD spl/lib/built-in.o > > > > LD spl/u-boot-spl > > > > env/built-in.o: In function `setup_flash_device': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:60: undefined reference to > `spi_flash_probe_bus_cs' > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:68: undefined reference to > `dev_get_uclass_priv' > > > > env/built-in.o: In function `spi_flash_read': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined > reference to `spi_flash_read_dm' > > > > env/built-in.o: In function `env_sf_load': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:317: undefined reference to > `spi_flash_free' > > > > drivers/built-in.o: In function `fsl_spi_spl_load_image': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/fsl_espi_spl.c:18: > undefined reference to `spi_flash_probe' > > > > drivers/built-in.o: In function `spi_flash_read': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined > reference to `spi_flash_read_dm' > > > > drivers/built-in.o: In function `fsl_spi_boot': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/fsl_espi_spl.c:44: > undefined reference to `spi_flash_probe' > > > > drivers/built-in.o: In function `spi_flash_read': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined > reference to `spi_flash_read_dm' > > > > drivers/built-in.o: In function `spi_flash_std_write': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:113: > undefined reference to `dev_get_uclass_priv' > > > > drivers/built-in.o: In function `spi_flash_std_read': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:103: > undefined reference to `dev_get_uclass_priv' > > > > drivers/built-in.o: In function `spi_flash_std_get_sw_write_prot': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:140: > undefined reference to `dev_get_uclass_priv' > > > > drivers/built-in.o: In function `spi_flash_std_erase': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:122: > undefined reference to `dev_get_uclass_priv' > > > > drivers/built-in.o: In function `spi_flash_std_probe': > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:147: > undefined reference to `dev_get_parent_priv' > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:148: > undefined reference to `dev_get_parent_platdata' > > > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:151: > undefined reference to `dev_get_uclass_priv' > > > > scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed > > > > make[1]:
Re: [U-Boot] [PATCH v1 1/3] drivers: pci_ep: Introduce UCLASS_PCI_EP uclass
On Thu, Apr 25, 2019 at 2:44 AM Simon Glass wrote:
> HI Ramon,
>
> On Mon, 22 Apr 2019 at 10:33, Ramon Fried wrote:
> >
> >
> > Hi Simon,
> > Thanks for the review.
> > please see inline, I have few questions/suggestions regarding
> > your notes.
> >
> > Thanks,
> > Ramon.
> > On Mon, Apr 22, 2019 at 5:56 AM Simon Glass wrote:
> >>
> >> Hi Ramon,
> >>
> >> On Fri, 5 Apr 2019 at 19:12, Ramon Fried wrote:
> >> >
> >> > Introduce new UCLASS_PCI_EP class for handling PCI endpoint
> >> > devices, allowing to set various attributes of the PCI endpoint
> >> > device, such as:
> >> > * configuration space header
> >> > * BAR definitions
> >> > * outband memory mapping
> >> > * start/stop PCI link
> >> >
> >> > Signed-off-by: Ramon Fried
> >> >
> >> > ---
> >> >
> >> > drivers/Kconfig | 2 +
> >> > drivers/Makefile | 1 +
> >> > drivers/pci_endpoint/Kconfig | 16 ++
> >> > drivers/pci_endpoint/Makefile| 6 +
> >> > drivers/pci_endpoint/pci_ep-uclass.c | 192 ++
> >> > include/dm/uclass-id.h | 1 +
> >> > include/pci_ep.h | 375
> +++
> >> > 7 files changed, 593 insertions(+)
> >> > create mode 100644 drivers/pci_endpoint/Kconfig
> >> > create mode 100644 drivers/pci_endpoint/Makefile
> >> > create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c
> >> > create mode 100644 include/pci_ep.h
> >>
>
> [..]
>
> >> > +int dm_pci_ep_set_bar(struct udevice *dev, u8 func_no,
> >>
> >> Please use uint for func_no. There is no need to limit it to 8 bits,
> >> and this may not be efficient for non-8-bit machines. Please fix
> >> globally.
> >
> > I tried to keep the API as similar as it can to the Linux API.
> > I can change it, no problem, but IMHO I think it's better to keep it
> similar.
>
> Hmm, why?
>
Nevermind, I already changed my mind :)
>
> >> Perhaps you should declare a 'mask' variable? In any case, it is
> >> confusing for the same variable to have two different meanings, and it
> >> does not save code at run-time.
> >
> > as before, this is practically a copy-paste from Linux, I can change it,
> but I think it's clearer if the code looks the same as in Linux,
> > might be easier the port patches like that.
>
> It's a minor thing so you can keep the linux code if you like.
>
> [..]
>
> >> > +int dm_pci_ep_get_msix(struct udevice *dev, u8 func_no)
> >> > +{
> >> > + struct dm_pci_ep_ops *ops = pci_ep_get_ops(dev);
> >> > + int interrupt;
> >> > +
> >> > + if (!ops->get_msix)
> >> > + return -ENODEV;
> >> > +
> >> > + interrupt = ops->get_msix(dev, func_no);
> >> > +
> >> > + if (interrupt < 0)
> >> > + return 0;
> >> > +
> >> > + return interrupt + 1;
> >>
> >> It's odd that your uclass function returns a different value from your
> >> driver function. I think that will be confusing. Is it necessary?
> >
> > As you can understand from the code, 0 means 1 interrupt. basically the
> driver functions just return the msix field in the PCI registers,
> > The translation to real number is done by the uclass wrapper.
>
> OK, but why? Why not use the same return value for the drive methods
> and the uclass? If you are using a different API, then please rename
> one of the functions.
>
I'm here advocating for the Linux implementation, you're right, I'll change
it.
>
> [..]
>
> >> What is a DWORD? I think i is 32-bits, so just say that, since WORD is
> >> a confusing term on a non-16-bit machine.
> >
> > hehe, I presume it's just a copy-paste from the PCI spec. I'll check, if
> so, I'll prefer to keep the original naming.
>
> OK, then how about adding the length as well, since DWORD is pretty
> obscure these days.
>
OK, will do.
>
> >
> >
> >>
> >>
> >> > + * @subsys_vendor_id: vendor of the add-in card or subsystem
> >> > + * @subsys_id: id specific to vendor
> >> > + * @interrupt_pin: interrupt pin the device (or device function) uses
> >> > + */
> >> > +struct pci_ep_header {
> >> > + u16 vendorid;
> >> > + u16 deviceid;
> >> > + u8 revid;
> >> > + u8 progif_code;
> >> > + u8 subclass_code;
> >> > + u8 baseclass_code;
> >> > + u8 cache_line_size;
> >> > + u16 subsys_vendor_id;
> >> > + u16 subsys_id;
> >> > + enum pci_interrupt_pin interrupt_pin;
> >>
> >> Shouldn't that be a u16 or something? The enum does not have a defined
> >> size, I think.
> >
> > well, there can be only 4 different interrupt pins, so it doesn't matter
> as long as the rage
> > is checked.
> >
>
> My concern is that if this is a hardware-mapped register, then the
> enum could be any size, and may not map over the correct bits.
>
> If this is not a hardware-mapped register, then OK.
>
Not mapped, phew.
>
> [..]
>
> >> > + /**
> >> > +* set_msix() - set msix capability property
> >> > +*
> >> > +* set the number
Re: [U-Boot] [PATCH v3 1/9] Revert "pico-imx7d: Add LCD support"
Fabio Estevam 于2019年4月24日周三 下午6:30写道： > > On Wed, Apr 24, 2019 at 1:00 AM Jun Nie wrote: > > > > This reverts commit 9e3c0174da842dd88f5feaffbf843ba332233897. > > Why are you reverting it? It blocks boot up with default defconfig. I see it is suggested to be reverted in mailist weeks ago. I thought you guys knew about it. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: mx6sabresd: fix boot hang with video
Meet the following boot hang.
"
U-Boot SPL 2019.04-00661-gdc80a012e4 (Apr 25 2019 - 10:31:57 +0800)
Trying to boot from MMC1
U-Boot 2019.04-00661-gdc80a012e4 (Apr 25 2019 - 10:31:57 +0800)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Automotive temperature grade (-40C to 125C)Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Smart Device Board
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
Video device 'ipu@240' cannot allocate frame buffer memory -ensure the
device is set up before relocation
Error binding driver 'ipuv3_video': -28
Video device 'ipu@280' cannot allocate frame buffer memory -ensure the
device is set up before relocation
Error binding driver 'ipuv3_video': -28
Some drivers failed to bind
Error binding driver 'generic_simple_bus': -28
Some drivers failed to bind
initcall sequence 4ffe4500 failed at call 1780dfb7 (err=-28)
"
1. fdtdec_get_alias_seq will use "video" as base, however in alias node,
we use ipux, so add new alias for U-Boot dts.
2. DM_VIDEO is enabled, however reserve_video is called before
relocation, so to make DM_VIDEO work before relocation, need to
set SYS_MALLOC_F_LEN
3. defconfig is updated with savedefconfig
Note: I do not have a video panel to test, but with this patch, U-Boot
boots up again, below log.
"
U-Boot SPL 2019.04-00662-g0b62453bff (Apr 25 2019 - 10:36:31 +0800)
Trying to boot from MMC1
U-Boot 2019.04-00662-g0b62453bff (Apr 25 2019 - 10:36:31 +0800)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Automotive temperature grade (-40C to 125C) at 34C
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Smart Device Board
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3
Loading Environment from MMC... *** Warning - bad CRC, using default environment
PCI: pcie phy link never came up
In:serial
Out: serial
Err: serial
Net: FEC [PRIME]
Hit any key to stop autoboot: 0
"
Signed-off-by: Peng Fan
---
arch/arm/dts/imx6q.dtsi | 1 +
arch/arm/dts/imx6qdl.dtsi| 1 +
configs/mx6sabresd_defconfig | 6 +++---
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/imx6q.dtsi b/arch/arm/dts/imx6q.dtsi
index ab1716b6b0..bc104f7bbb 100644
--- a/arch/arm/dts/imx6q.dtsi
+++ b/arch/arm/dts/imx6q.dtsi
@@ -9,6 +9,7 @@
/ {
aliases {
ipu1 =
+ video1 =
spi4 =
};
diff --git a/arch/arm/dts/imx6qdl.dtsi b/arch/arm/dts/imx6qdl.dtsi
index c0a9478008..83eeb5cc59 100644
--- a/arch/arm/dts/imx6qdl.dtsi
+++ b/arch/arm/dts/imx6qdl.dtsi
@@ -33,6 +33,7 @@
i2c1 =
i2c2 =
ipu0 =
+ video0 =
mmc0 =
mmc1 =
mmc2 =
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index eaf0f01004..5b527cbd5b 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -4,13 +4,13 @@ CONFIG_SYS_TEXT_BASE=0x1780
CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_TARGET_MX6SABRESD=y
CONFIG_SPL_MMC_SUPPORT=y
CONFIG_SPL_SERIAL_SUPPORT=y
CONFIG_SPL=y
-CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_NR_DRAM_BANKS=1
-# CONFIG_SYS_MALLOC_F is not set
+CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_FIT=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
@@ -62,6 +62,7 @@ CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd"
CONFIG_MULTI_DTB_FIT=y
CONFIG_SPL_MULTI_DTB_FIT=y
CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd"
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
CONFIG_SPL_DM=y
@@ -97,4 +98,3 @@ CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_DM_VIDEO=y
CONFIG_VIDEO_IPUV3=y
-# CONFIG_VIDEO_SW_CURSOR is not set
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
Update and reminder. On Mon, Mar 18, 2019 at 11:17:14AM +0900, AKASHI, Takahiro wrote: > Hi, > > I'd like to discuss this topic in public. > I will appreciate your comments here. > # FYI, I now started to experimentally port linux's pkcs7/x509 > # parser. I've done porting linux's pkcs7/x509 parsers and they work well with my UEFI secure boot patch, but I'm still looking for other options as well. * openssl Most of existing components linked to UEFI secure boot, including EDK2, shim and grub, reply on this library. Why not for U-Boot? The size of U-Boot UEFI code in U-Boot is already quite big, and so the size of openssl won't be a big issue. * mbedTLS which is maintained by ARM and used with Zephyr, I guess it should have small footprint. But it currently lacks pkcs7 parser. Any thoughts? Thanks, -Takahiro Akashi > Thanks, > -Takahiro Akashi > > - Forwarded message from Simon Glass - > > Date: Thu, 7 Mar 2019 19:56:10 -0700 > From: Simon Glass > To: "AKASHI, Takahiro" > Subject: Re: RSA in U-Boot > > Hi Takahiro, > > On Thu, 7 Mar 2019 at 17:27, AKASHI, Takahiro > wrote: > > > > Hi Simon, > > > > Before I start discussions publicly, I'd like to hear > > your opinion first. > > I do think it is better to discuss this in public since there will be > other opinions. > > > > > I'm now working on implementing "secure boot" > > for UEFI U-Boot. > > > > As you might know, there are a couple of features > > required to achieve "secure boot": > > (I won't discuss about secure storage here though.) > > - x509 certificate decoder > > - pkcs7 decoder (for PE file's signature) > > - RSA verification > > - (hash digest, sha256) > > > > The original code, which was written by some other guy, > > Patrick, uses BearSSL for x509 and RSA and > > I'm now wondering what is the best solution. > > Obviously, I can think of several options here: > > 1. use BearSSL > > 1.a just import minimum set of files akin lib/libfdt > > 1.b link whole BearSSL as a library, merging the code > > as git submodule > > 2. use openssl > > 3. import linux kernel code, particularly x509 & pkcs7 parser > > 4. write our own code > > > > I suppose that you weighed similar choices when you implemented > > "FIT image signing". > > Can you share your opinion with me? > > I think if you can do 3 then it keeps U-Boot self-contained and > perhaps provides for simple code. That said, if the amount of code is > large and has an upstream there is clear precident for 1a, as you say. > > I am not sure about 4. If it is a relatively small amount of code, > then maybe, but surely it makes sense to use the linux code where > possible. That is what I did with the U-Boot livetree code. > > 1b sounds painful to me. > > > > > Regarding your lib/rsa code, you intentionally avoided to > > add formula of inverse-mod and power-mod of R. Do you still > > believe that the assumption is appropriate? > > (BearSSL implements its own montgomery. > > If you look at a talk I gave on this, you can see that one of the > goals was to implement it efficiently, with minimal extra code at > run-time, and minimal memory usage. So unpacking complex key > structures did not seem like a good idea. From memory you can do > verified boot in about 7KB of extra code in U-Boot and it runs in a > small number of milliseconds. > > UEFI is obviously pretty big, so perhaps efficiency concerns are less > important. More important probably is wide compatibility, supporting > all possible options, etc. > > I hope this is helpful. > > Regards, > Simon > > - End forwarded message - ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] efi_loader: non-volatile variables support
On Thu, Apr 25, 2019 at 12:12:39AM +0200, Heinrich Schuchardt wrote: > On 4/24/19 8:30 AM, AKASHI Takahiro wrote: > >This patch set is an attempt to implement non-volatile attribute for > >UEFI variables. Under the current implementation, > >* SetVariable API doesn't recognize non-volatile attribute > >* While some variables are defined non-volatile in UEFI specification, > > they are NOT marked as non-volatile in the code. > >* env_save() (or "env save" command) allows us to save all the variables > > into persistent storage, but it may cause volatile UEFI variables, > > along with irrelevant U-Boot variables, to be saved unconditionally. > > > >Those observation rationalizes that the implementation of UEFI variables > >should be revamped utilizing dedicated storage for them. > > > >This patch set is yet experimental and rough-edged(See known issues below), > >but shows how UEFI variables can be split from U-Boot environment. > >This enhancement will also be vital when we introduce UEFI secure boot > >where secure and tamper-resistant storage (with authentication) is > >required. > > > >Usage: > >To enable this feature, the following configs must be enabled: > > CONFIG_ENV_IS_IN_FAT > > CONFIG_ENV_FAT_INTERFACE > > CONFIG_ENV_EFI_FAT_DEVICE_AND_PART > > CONFIG_ENV_EFI_FAT_FILE > > > >You can also define a non-volatile variable from command interface: > >=> setenv -e -nv FOO baa > > > >Known issues/restriction: > >* UEFI spec defines "globally defined variables" with specific > > attributes, but with this patch, we don't check against the user-supplied > > attribute for any variable. > >* Only FAT can be enabled for persistent storage for UEFI non-volatile > > variables. > >* The whole area of storage will be saved at every update of one variable. > > It can be optimized. > >* An error during saving may cause inconsistency between cache (hash table) > > and the storage. > >* Cache is of fixed size and can be quite big for normal usage. > > Hello Takahiro, > > thanks a lot for looking into persisting non-volatile UEFI variables. > > Before diving into the details of the patches let us discuss the overall > design. I like this kind of discussions as this patch set is more or less RFC. > My understanding is that we need a buffer that lives in > EFI_RUNTIME_SERVICES_DATA and holds all variables. It is this buffer > that the operating system will access when getting or setting variables. > > If a non-volatile variable is set via SetVariable() we will call a > backend driver. Get/SetVariable() is not mandatory in runtime services, and EBBR, at least, says: If any EFI_RUNTIME_SERVICES functions are only available during boot services then firmware shall provide the global RuntimeServicesSupported variable to indicate which functions are available during runtime services. (in section 2.5), and Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified. (in section 2.5.3) # Variable update can also be done via 'capsule.' > Our current backend is using U-Boot environment variables. It can only > be accessed at boottime. Right. > Currently there is no guarantee that the U-Boot > variables are saved before booting. Right, but if 'saved before booting' were the only issue, we could call env_save() in efi_start_image(). The problems are not there. > So it does not support persisting > non-volatile variables reliably. > > Your patch series supplies a new backend using a file for persisting > non-volatile variables. It can only be accessed at boottime. Essentially > this solution requires no restriction to FAT file systems. We could as > well use the EXT4 driver for reading or writing the file. Right, we can also use flash, nand, emmc and others like U-Boot environment as we still reply on helper functions for U-Boot environment. > This file > storage is completely independent of the U-Boot environment. No. We don't have to care about format in persistent storage. What is required is that we should provide Get/SetVariable APIs. > So it shall > not involve any changes to files env/*. I think a documentation of the > file format provided in a README would be helpful. > > In case of both backends we would return EFI_UNSUPPORTED when trying to > set a non-volatile variable at runtime. Setting a volatile variable at > runtime should be allowable as long as we have sufficient space in our > buffer. Well, there are several possibilities: 1. We don't support Get/SetVariable in runtime at all 2. GetVariable is available through 'cache' (U-Boot environment uses a on-memory hash tables to maintain variables.) Optionally, SetVariable can be achieved via capsule. 3. Get/SetVariable is implemented by an independent entity and gets avaiable even in
Re: [U-Boot] [PATCH 2/3] sound: tegra: Add the binding file for tegra-audio
Hi Jon,
On Wed, 24 Apr 2019 at 03:15, Jon Hunter wrote:
>
>
> On 24/04/2019 04:56, Simon Glass wrote:
> > This file was missed when adding the sound driver to U-Boot. Bring it in
> > from Linux 5.0.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > .../sound/nvidia,tegra-audio-max98090.txt | 53 +++
> > 1 file changed, 53 insertions(+)
> > create mode 100644
> > doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt
> >
> > diff --git a/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt
> > b/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt
> > new file mode 100644
> > index 000..c3495beba35
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/sound/nvidia,tegra-audio-max98090.txt
> > @@ -0,0 +1,53 @@
> > +NVIDIA Tegra audio complex, with MAX98090 CODEC
>
> Does this work for all Tegra chips? I have noticed in some of our kernel
> binding docs we don't really say specifically what Tegra devices this is
> applicable for. If this is only verified for Tegra124 then it could be
> worth mentioning that.
This file comes from Linux so I would rather not modify it in U-Boot.
I believe this works for anything with a 'tegra audio' component and
that this is from tegra124 onwards, but then, you guys are the
experts!
>
> > +
> > +Required properties:
> > +- compatible : "nvidia,tegra-audio-max98090"
> > +- clocks : Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > +- clock-names : Must include the following entries:
> > + - pll_a
> > + - pll_a_out0
> > + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
> > +- nvidia,model : The user-visible name of this sound complex.
> > +- nvidia,audio-routing : A list of the connections between audio
> > components.
> > + Each entry is a pair of strings, the first being the connection's sink,
> > + the second being the connection's source. Valid names for sources and
> > + sinks are the MAX98090's pins (as documented in its binding), and the
> > jacks
> > + on the board:
> > +
> > + * Headphones
> > + * Speakers
> > + * Mic Jack
> > + * Int Mic
>
> I don't see 'Int Mic' used anywhere in the example. Is this really a
> physical jack?
I suspect not, but it can still be routed.
>
> > +
> > +- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's
> > + connected to the CODEC.
> > +- nvidia,audio-codec : The phandle of the MAX98090 audio codec.
> > +
> > +Optional properties:
> > +- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in
> > +- nvidia,mic-det-gpios : The GPIO that detect microphones are plugged in
> > +
> > +Example:
> > +
> > +sound {
> > + compatible = "nvidia,tegra-audio-max98090-venice2",
> > + "nvidia,tegra-audio-max98090";
> > + nvidia,model = "NVIDIA Tegra Venice2";
> > +
> > + nvidia,audio-routing =
> > + "Headphones", "HPR",
> > + "Headphones", "HPL",
> > + "Speakers", "SPKR",
> > + "Speakers", "SPKL",
> > + "Mic Jack", "MICBIAS",
> > + "IN34", "Mic Jack";
> > +
> > + nvidia,i2s-controller = <_i2s1>;
> > + nvidia,audio-codec = <>;
> > +
> > + clocks = <_car TEGRA124_CLK_PLL_A>,
> > + <_car TEGRA124_CLK_PLL_A_OUT0>,
> > + <_car TEGRA124_CLK_EXTERN1>;
> > + clock-names = "pll_a", "pll_a_out0", "mclk";
> > +};
> >
>
> Otherwise LGTM.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] riscv: configs: AE350 will use CONFIG_OF_PRIOR_STAGE when booting from ram
HI Bin Bin Meng 於 2019年4月24日 週三 下午3:02寫道： > > On Wed, Apr 24, 2019 at 2:38 PM Andes wrote: > > > > From: Rick Chen > > > > When AE350 was booting from ram, use CONFIG_OF_PRIOR_STAGE instead > > was -> is OK > > > of CONFIG_OF_BOARD. > > > > Signed-off-by: Rick Chen > > Cc: Greentime Hu > > --- > > configs/ae350_rv32_defconfig | 2 +- > > configs/ae350_rv64_defconfig | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > Other than that, > Reviewed-by: Bin Meng Thanks Rick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled
Bin Meng 於 2019年4月24日 週三 下午3:02寫道：
>
> On Wed, Apr 24, 2019 at 2:38 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > This patch will fix prior_stage_fdt_address write failure problem, when
> > AE350 was booting from flash.
>
> was -> is
OK
>
> >
> > When AE350 was booting from falsh, prior_stage_fdt_address will be in
>
> was -> is
OK
>
> > flash address, we shall avoid it to be written.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > arch/riscv/cpu/cpu.c | 2 ++
> > arch/riscv/cpu/start.S | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > index 768c44c..a17d37f 100644
> > --- a/arch/riscv/cpu/cpu.c
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -15,7 +15,9 @@
> > * The variables here must be stored in the data section since they are
> > used
> > * before the bss section is available.
> > */
> > +# if CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
>
> Should this be: ifdef CONFIG_OF_PRIOR_STAGE, because the next a few of
> lines you wrote: #ifndef CONFIG_XIP
I just refer to fdtdesc.c and imitate it.
But it is no problem to modify it as ifdef CONFIG_OF_PRIOR_STAGE as you said.
>
> > phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
> > +#endif
> > #ifndef CONFIG_XIP
> > u32 hart_lottery __attribute__((section(".data"))) = 0;
> > /*
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 41d9a32..9ede1a7 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -111,7 +111,9 @@ call_board_init_f_0:
> > bneztp, secondary_hart_loop
> > #endif
> >
> > +# if CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
>
> #ifdef CONFIG_OF_PRIOR_STAGE ?
OK
>
> > la t0, prior_stage_fdt_address
> > +#endif
> > SREGs1, 0(t0)
> >
> > jal board_init_f_init_reserve
> > --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] riscv: hart_lottery and available harts features can be selectable
Bin Meng 於 2019年4月24日 週三 下午3:02寫道：
>
> Hi Rick,
>
> On Wed, Apr 24, 2019 at 2:37 PM Andes wrote:
> >
> > From: Rick Chen
> >
>
> I would write the commit title and message as:
>
> riscv: Introduce CONFIG_XIP to support booting from flash
>
> When U-Boot boots from flash, during the boot process, hart_lottery
> and available_harts_lock variable addresses point to flash which is
> not writable. This causes boot failures on AE350. Introduce a config
> option CONFIG_XIP to support such configuration.
>
OK.
I will modify it as your description.
> > flash.
> >
> > Add CONFIG_XIP to NOT select this two features. It's default value
> > will say NO for booting from ram.
> >
> > AE350 will encounter the the write failure problem since
> > hart_lottery and available_harts_lock was not in ram address but
> > in flash address when booing from flash.
> >
> > This patch can help to fix the write failure problem when AE350
> > booting from flash by disabling this two features.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > arch/riscv/Kconfig | 10 ++
> > arch/riscv/cpu/cpu.c | 3 ++-
> > arch/riscv/cpu/start.S | 7 ++-
> > arch/riscv/include/asm/global_data.h | 2 ++
> > arch/riscv/lib/asm-offsets.c | 2 ++
> > arch/riscv/lib/smp.c | 2 ++
> > 6 files changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index ae8ff7b..fb9a8c6 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -162,6 +162,16 @@ config SBI_IPI
> > default y if RISCV_SMODE
> > depends on SMP
> >
> > +config XIP
> > + bool "XIP mode"
> > + default n
>
> nits: this is not necessary as by default all config options are n
OK
>
> > + help
> > + XIP (eXecute In Place) is a method for executing code directly
> > + from a serial NOR flash memory without copying the code to ram.
>
> It's not necessary to be a serial NOR flash. A parallel flash can be
> the same. I think you can just mention NOR flash memory.
>
> > + This must NOT support hart lottery and available harts features.
> > + These two feature only can be enabled when U-Boot booting from
> > + ram, but shall be disabled when booting from flash.
>
> remove the rest of the help message, and something like this:
>
> Say yes here if U-Boot boots from flash directly.
OK
>
> > +
> > config STACK_SIZE_SHIFT
> > int
> > default 13
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > index c32de8a..768c44c 100644
> > --- a/arch/riscv/cpu/cpu.c
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -16,13 +16,14 @@
> > * before the bss section is available.
> > */
> > phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
> > +#ifndef CONFIG_XIP
> > u32 hart_lottery __attribute__((section(".data"))) = 0;
> > -
> > /*
> > * The main hart running U-Boot has acquired available_harts_lock until it
> > has
> > * finished initialization of global data.
> > */
> > u32 available_harts_lock = 1;
> > +#endif
> >
> > static inline bool supports_extension(char ext)
> > {
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index a4433fb..41d9a32 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -98,6 +98,7 @@ call_board_init_f_0:
> > mv sp, a0
> > #endif
> >
> > +#ifndef CONFIG_XIP
> > /*
> > * Pick hart to initialize global data and run U-Boot. The other
> > harts
> > * wait for initialization to complete.
> > @@ -106,6 +107,9 @@ call_board_init_f_0:
> > li s2, 1
> > amoswap.w s2, t1, 0(t0)
> > bnezs2, wait_for_gd_init
> > +#else
> > + bneztp, secondary_hart_loop
> > +#endif
> >
> > la t0, prior_stage_fdt_address
> > SREGs1, 0(t0)
> > @@ -115,6 +119,7 @@ call_board_init_f_0:
> > /* save the boot hart id to global_data */
> > SREGtp, GD_BOOT_HART(gp)
> >
> > +#ifndef CONFIG_XIP
> > la t0, available_harts_lock
> > fence rw, w
> > amoswap.w zero, zero, 0(t0)
> > @@ -141,7 +146,7 @@ wait_for_gd_init:
> > * secondary_hart_loop.
> > */
> > bnezs2, secondary_hart_loop
> > -
>
> Please keep the original blank line here.
OK
>
> > +#endif
> > /* Enable cache */
> > jal icache_enable
> > jal dcache_enable
> > diff --git a/arch/riscv/include/asm/global_data.h
> > b/arch/riscv/include/asm/global_data.h
> > index dffcd45..b74bd7e 100644
> > --- a/arch/riscv/include/asm/global_data.h
> > +++ b/arch/riscv/include/asm/global_data.h
> > @@ -27,7 +27,9 @@ struct arch_global_data {
> > #ifdef CONFIG_SMP
> > struct ipi_data ipi[CONFIG_NR_CPUS];
> > #endif
> > +#ifndef CONFIG_XIP
> > ulong available_harts;
> > +#endif
> > };
> >
> > #include
> > diff
Re: [U-Boot] [PATCH 0/4] AE350 support SMP boot from flash
Hi Lukas Auer, Lukas 於 2019年4月25日 週四 上午5:18寫道： > > Hi Rick, > > On Wed, 2019-04-24 at 09:35 +0800, Rick Chen wrote: > > Hi Lukas > > > > Auer, Lukas 於 2019年4月24日 週三 上午3:58寫道： > > > Hi Rick, > > > > > > On Tue, 2019-04-23 at 13:42 +0800, Andes wrote: > > > > From: Rick Chen > > > > > > > > In current RISC-V SMP flow, AE350 will encounter the the write > > > > failure problem since hart_lottery and available_harts_lock was > > > > not in ram address but in flash address when booing from flash. > > > > > > > > This patch can help to fix the failure problem when AE350 was > > > > booting from flash by disable this two features. > > > > > > > > > > Can you describe the issue you are seeing a bit more. The write > > > failures are both to variables in the .data section, which should be > > > writable. Perhaps the write failures can be avoided by moving the .data > > > section or just the variable to RAM? > > > > > > > When I compile AE350's CONFIG_SYS_TEXT_BASE=0x8000 which is spi flash > > base. > > And burn u-boot.bin into AE350 spi flash. Power off / on, U-Boot will > > run in XIP mode. > > At this time prior_stage_fdt_address will be in flash address(0x8004e9e8) > > So it is not writable. > > > > 8042: 16021563bneztp,81ac > > > > 8046: 0004f297auipc t0,0x4f > > 804a: 9a22a283lw t0,-1630(t0) # > > 8004e9e8 > > 804e: 0092a023sw s1,0(t0) > > > > Ok, that makes sense. > Another option would be to move the variable to RAM or some other > location, which is write-accessible when U-Boot starts. Would this > work? > I think it would be good to support the hart lottery and the available > harts mask in all configurations. > Actually I have tried to move them to gd, but it fail. Because it need some requirements : hart_lottery need equal to 0 and available_harts_lock equal to 1 at compile time. It is hard to achieve this at run time. That is why I add a CONFIG_XXX to remove this two features simply. Thanks Rick > Thanks, > Lukas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] lib: charset: add u16_strcmp()
On Wed, Apr 24, 2019 at 06:24:44PM +0200, Heinrich Schuchardt wrote:
> On 4/24/19 8:30 AM, AKASHI Takahiro wrote:
> >u16 version of strcmp()
> >
> >AUTHER: Patrick Wildt
>
> %s/AUTHER/Author/
Okay
> >Signed-off-by: AKASHI Takahiro
> >---
> > include/charset.h | 5 +
> > lib/charset.c | 10 ++
> > 2 files changed, 15 insertions(+)
> >
> >diff --git a/include/charset.h b/include/charset.h
> >index 65087f76d1fc..747a9b376c03 100644
> >--- a/include/charset.h
> >+++ b/include/charset.h
> >@@ -166,6 +166,11 @@ s32 utf_to_lower(const s32 code);
> > */
> > s32 utf_to_upper(const s32 code);
> >
> >+/*
> >+ * u16_strcmp() - strcmp() for u16 strings
> >+ */
> >+int u16_strcmp(const u16 *s1, const u16 *s2);
> >+
> > /**
> > * u16_strlen - count non-zero words
> > *
> >diff --git a/lib/charset.c b/lib/charset.c
> >index 5e349ed5ee45..4a25ac0bdb9c 100644
> >--- a/lib/charset.c
> >+++ b/lib/charset.c
> >@@ -335,6 +335,16 @@ s32 utf_to_upper(const s32 code)
> > return ret;
> > }
> >
> >+int u16_strcmp(const u16 *s1, const u16 *s2)
> >+{
> >+while (*s1 == *s2++)
> >+if (*s1++ == 0)
> >+return (0);
> >+--s2;
>
> for (;*s1 == *s2; ++s1, ++s2)
> if (!s1)
> return 0;
>
> does the same job without superfluous increment/decrement.
Indeed :)
> >+
> >+return (*(uint16_t *)s1 - *(uint16_t *)s2);
>
> Why would you use both u16 and uint16_t in the same function?
> You can do without any conversion here.
Will fix.
> How about
>
> #define u16_strcmp(s1, s2) u16_strncmp(s1, s2, SIZE_MAX)
>
> like we do for the other string functions?
Sure
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >+}
> >+
> > size_t u16_strlen(const u16 *in)
> > {
> > size_t i;
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] efi_loader: set OsIndicationsSupported at init
On Wed, Apr 24, 2019 at 10:32:22PM +0200, Heinrich Schuchardt wrote:
> From: AKASHI Takahiro
>
> UEFI variables should be installed using well-defined API.
> Currently we don't support much, but the value of OsIndicationsSupported
> will be updated once some features are added in the future.
>
> Signed-off-by: AKASHI Takahiro
>
> Add comments. Rename a variable.
>
> Reviewed-by: Heinrich Schuchardt
> ---
> Applied to efi-2019-07 branch.
> ---
> cmd/bootefi.c | 4
> lib/efi_loader/efi_setup.c | 11 +++
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index efaa548be4..b93d8c6a32 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -303,10 +303,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle)
> if (ret != EFI_SUCCESS)
> return ret;
>
> - /* we don't support much: */
> -
> env_set("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
> - "{ro,boot}(blob)");
> -
> /* Call our payload! */
> ret = EFI_CALL(efi_start_image(handle, NULL, NULL));
>
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index b32a7b3f93..87db51cbb7 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -79,6 +79,7 @@ out:
> */
> efi_status_t efi_init_obj_list(void)
> {
> + u64 os_indications_supported = 0; /* None */
> efi_status_t ret = EFI_SUCCESS;
>
> /* Initialize once only */
> @@ -90,6 +91,16 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
>
> + /* Indicate supported features */
> + ret = EFI_CALL(efi_set_variable(L"OsIndicationsSupported",
> + _global_variable_guid,
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_RUNTIME_ACCESS,
> + sizeof(os_indications_supported),
> + _indications_supported));
> + if (ret != EFI_SUCCESS)
> + goto out;
> +
Or should we rename efi_init_platform_lang() to, say, efi_init_vars()
and put OsIndcationsSupported in it?
-Takahiro Akashi
> /* Initialize system table */
> ret = efi_initialize_system_table();
> if (ret != EFI_SUCCESS)
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/11] cmd: efidebug: rework "boot dump" sub-command using GetNextVariableName()
On Wed, Apr 24, 2019 at 10:13:37PM +0200, Heinrich Schuchardt wrote:
> On 4/24/19 8:30 AM, AKASHI Takahiro wrote:
> >Efidebug command should be implemented using well-defined EFI interfaces,
> >rather than using internal functions/data. This change will be needed in
> >a later patch where UEFI variables are re-implemented.
>
> I had trouble to get the point. In the next version I suggest to write:
>
> Currently in do_efi_boot_dump() we directly read EFI variables from the
> related environment variables. To accomodate alternative storage
> backends we should switch to using the UEFI API instead.
Okay.
> >
> >Signed-off-by: AKASHI Takahiro
> >---
> > cmd/efidebug.c | 92 --
> > 1 file changed, 66 insertions(+), 26 deletions(-)
> >
> >diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> >index a40c4f4be286..8890dd7268f1 100644
> >--- a/cmd/efidebug.c
> >+++ b/cmd/efidebug.c
> >@@ -509,7 +509,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
> > if (argc < 6 || argc > 7)
> > return CMD_RET_USAGE;
> >
> >-id = (int)simple_strtoul(argv[1], , 16);
> >+id = simple_strtoul(argv[1], , 16);
>
> This change is correct but unrelated. Please, put it into a separate
> patch. Or at least mention it in the commit message.
Sure.
> > if (*endp != '\0' || id > 0x)
> > return CMD_RET_USAGE;
> >
> >@@ -595,7 +595,7 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
> >
> > guid = efi_global_variable_guid;
> > for (i = 1; i < argc; i++, argv++) {
> >-id = (int)simple_strtoul(argv[1], , 16);
> >+id = simple_strtoul(argv[1], , 16);
>
> Same here.
>
> > if (*endp != '\0' || id > 0x)
> > return CMD_RET_FAILURE;
> >
> >@@ -693,6 +693,27 @@ static void show_efi_boot_opt(int id)
> > free(data);
> > }
> >
> >+static bool u16_isxdigit(u16 c)
> >+{
> >+if (c & 0xff00)
> >+return false;
> >+
> >+return isxdigit((u8)c);
> >+}
> >+
> >+static int u16_tohex(u16 c)
> >+{
> >+if (c >= '0' && c < '9')
> >+return c - '0';
> >+if (c >= 'A' && c < 'F')
> >+return c - 'A' + 10;
> >+if (c >= 'a' && c < 'f')
> >+return c - 'a' + 10;
>
> Does the UEFI spec really allow lower case hexadecimal numbers here?
> I only found an example with capital numbers. Would this imply that I
> could have variables Boot00a0 and Boot00A0 side by side? Which one would
> be selected by boot option 00a0?
>
> Or should SetVariable() make a case insensitive search for variable names?
Good point. I found the description below in UEFI section 3.1.1:
Each load option entry resides in a Boot, Driver,
SysPrep, OsRecovery
or PlatformRecovery variable where is replaced by
a unique option number in
printable hexadecimal representation using the digits 0-9,
and the upper case versions of the
characters A-F (-).
> In EDK2 function FindVariableEx() in
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> uses CompareMem() to compare variable names.
>
> Function BmCharToUint() is used to check the digits of boot options and
> has this comment:
>
> "It assumes the input Char is in the scope of L'0' ~ L'9'
> and L'A' ~ L'F'"
>
> So let's us assume that variable names are case sensitive and Boot
> entries can only have capital hexadecimal digits.
>
> So u16_isxdigit() is incorrect.
>
> >+
> >+/* dummy */
> >+return -1;
>
> As we do not check bounds here the function could be reduced to:
>
> return c > '9' ? c - ('A' - 0xa) : c - '9';
>
> But I would prefer one library function instead of the two static
> functions which returns -1 for a non-digit and 0 - 15 for a digit.
> And a unit test in test/unicoode_ut.c
Okay.
> >+}
> >+
> > /**
> > * show_efi_boot_dump() - dump all UEFI load options
> > *
> >@@ -709,38 +730,57 @@ static void show_efi_boot_opt(int id)
> > static int do_efi_boot_dump(cmd_tbl_t *cmdtp, int flag,
> > int argc, char * const argv[])
> > {
> >-char regex[256];
> >-char * const regexlist[] = {regex};
> >-char *variables = NULL, *boot, *value;
> >-int len;
> >-int id;
> >+u16 *var_name16, *p;
> >+efi_uintn_t buf_size, size;
> >+efi_guid_t guid;
> >+int id, i;
> >+efi_status_t ret;
> >
> > if (argc > 1)
> > return CMD_RET_USAGE;
> >
> >-snprintf(regex, 256, "efi_.*-.*-.*-.*-.*_Boot[0-9A-F]+");
> >-
> >-/* TODO: use GetNextVariableName? */
> >-len = hexport_r(_htab, '\n', H_MATCH_REGEX | H_MATCH_KEY,
> >-, 0, 1, regexlist);
> >+buf_size = 128;
> >+var_name16 = malloc(buf_size);
> >+if (!var_name16)
> >+return CMD_RET_FAILURE;
> >
> >-if (!len)
> >-return CMD_RET_SUCCESS;
> >+var_name16[0] = 0;
> >+for (;;) {
> >+size = buf_size;
> >+
Re: [U-Boot] [PATCH v2 02/11] lib: charset: add u16_strncmp()
On Wed, Apr 24, 2019 at 08:36:09PM +0200, Heinrich Schuchardt wrote: > On 4/24/19 8:30 AM, AKASHI Takahiro wrote: > >u16_strncmp() works like u16_strcmp() but only at most n characters > >(in u16) are compared. > >This function will be used in a later patch. > > > >Signed-off-by: AKASHI Takahiro > > The only usage of u16_strncmp() is in patch 3. > u16_strcmp() is not used at all. The fact is that u16_strcmp() is already used in my 'secure boot' patch and then I moved on to non-volatile patch. > In patch 3 'memcmp(var_name16, L"BOOT", 8)' will do the job. > > I am not sure if in other cases we wouldn't prefer to compare Unicode > codepoints instead of u16. That is my concern, too :) > So I suggest to skip patches 1 and 2 and use memcmp() in patch 3. Okay, patch#1 will be planned to be included in 'secure boot' patch. -Takahiro Akashi > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH] core: ofnode: Add ofnode_get_addr_size_index
On Wed, 24 Apr 2019 at 05:49, Keerthy wrote: > > Add ofnode_get_addr_size_index function to fetch the address > and size of the reg space based on index. > > Signed-off-by: Keerthy > --- > > Previous discussion can be found here: > > * https://patchwork.ozlabs.org/patch/999659/ > > drivers/core/ofnode.c | 13 ++--- > include/dm/ofnode.h | 14 ++ > 2 files changed, 24 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram
Hi, On Wed, 24 Apr 2019 at 05:53, Tom Rini wrote: > > On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > On Wed, Apr 24, 2019 at 1:27 PM Tom Rini wrote: > > > > > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > > > wrote: > > > > > > > > > > If the malloc range passed to mem_malloc_init() is at the end of > > > > > address > > > > > range and 'start + size' overflows to 0, following allocations fail as > > > > > mem_malloc_end is zero (which looks like uninitialized). > > > > > > > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > > > > > > Signed-off-by: Simon Goldschmidt > > > > > --- > > > > > > > > > > Changes in v4: None > > > > > Changes in v3: None > > > > > > > > > > common/dlmalloc.c | 4 > > > > > 1 file changed, 4 insertions(+) > > > > > > > > Reviewed-by: Simon Glass > > > > > > So, the problem with this patch is that it increases the generic malloc > > > code size ever so slightly and blows up smartweb :( > > > > Ehrm, ok, so how do we proceed? > > A good question. Take a look at spl/u-boot-spl.map on smartweb and see > if, of the malloc functions it doesn't discard there's something that > maybe could be optimized somewhere? I wonder if we should have a Kconfig option like SPL_CHECKS which enables these sorts of minor checks, which may only fix one board at the cost of code size? Then it could be enabled by default, but disabled on this board? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] the dm of SPL does not support very well on spiboot
Hi Chuanhua, On Sun, 21 Apr 2019 at 09:00, Chuanhua Han wrote: > > Hi,all > > > > 1. When I tested and compiled some spiboot boards, I found that the board > compilation of these spiflash boot configurations failed. > > These boards all support the dm mode of spl, and the boot mode used is > spiboot. > > Here is the board configuration I compiled: > > > > configs/sama5d2_xplained_spiflash_defconfig > > configs/sama5d3xek_spiflash_defconfig > > configs/sama5d4_xplained_spiflash_defconfig > > configs/sama5d4ek_spiflash_defconfig > > > > eg: > > sama5d4ek_spiflash_defconfig > > > > CC spl/drivers/clk/at91/clk-master.o > > drivers/spi/spi.c: In function ‘spi_do_alloc_slave’: > > CC spl/lib/libfdt/fdt_ro.o > > CC spl/lib/libfdt/fdt_region.o > > drivers/spi/spi.c:34:8: error: ‘struct spi_slave’ has no member named ‘bus’ > >slave->bus = bus; > > ^~ > > drivers/spi/spi.c:35:8: error: ‘struct spi_slave’ has no member named ‘cs’ > >slave->cs = cs; > > ^~ > > scripts/Makefile.build:278: recipe for target 'spl/drivers/spi/spi.o' failed > > > > So far there seems to be no spiboot board that compiles successfully and > works properly. > > > > I would like to know how to configure uboot in SPL using dm spiboot to ensure > normal compilation. > > > > === > > > > 2. When I compile d with T2080QDS_SPIFLASH_defconfig, a similar error > message appears. > > I have included the following options in the configuration file: > > CONFIG_DM_SPI=y > > CONFIG_DM_SPI_FLASH=y > > > > The following is the error log: > > $ make T2080QDS_SPIFLASH_defconfig& -j32 all > > HOSTCC scripts/basic/fixdep > > HOSTCC scripts/kconfig/conf.o > > … > > LD spl/lib/built-in.o > > LD spl/u-boot-spl > > env/built-in.o: In function `setup_flash_device': > > /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:60: undefined reference to > `spi_flash_probe_bus_cs' > > /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:68: undefined reference to > `dev_get_uclass_priv' > > env/built-in.o: In function `spi_flash_read': > > /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined > reference to `spi_flash_read_dm' > > env/built-in.o: In function `env_sf_load': > > /home/hanch/DSPI/u-boot-fsl-qoriq/env/sf.c:317: undefined reference to > `spi_flash_free' > > drivers/built-in.o: In function `fsl_spi_spl_load_image': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/fsl_espi_spl.c:18: > undefined reference to `spi_flash_probe' > > drivers/built-in.o: In function `spi_flash_read': > > /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined > reference to `spi_flash_read_dm' > > drivers/built-in.o: In function `fsl_spi_boot': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/fsl_espi_spl.c:44: > undefined reference to `spi_flash_probe' > > drivers/built-in.o: In function `spi_flash_read': > > /home/hanch/DSPI/u-boot-fsl-qoriq/include/spi_flash.h:118: undefined > reference to `spi_flash_read_dm' > > drivers/built-in.o: In function `spi_flash_std_write': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:113: undefined > reference to `dev_get_uclass_priv' > > drivers/built-in.o: In function `spi_flash_std_read': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:103: undefined > reference to `dev_get_uclass_priv' > > drivers/built-in.o: In function `spi_flash_std_get_sw_write_prot': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:140: undefined > reference to `dev_get_uclass_priv' > > drivers/built-in.o: In function `spi_flash_std_erase': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:122: undefined > reference to `dev_get_uclass_priv' > > drivers/built-in.o: In function `spi_flash_std_probe': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:147: undefined > reference to `dev_get_parent_priv' > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:148: undefined > reference to `dev_get_parent_platdata' > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/mtd/spi/sf_probe.c:151: undefined > reference to `dev_get_uclass_priv' > > scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed > > make[1]: *** [spl/u-boot-spl] Error 1 > > Makefile:1649: recipe for target 'spl/u-boot-spl' failed > > make: *** [spl/u-boot-spl] Error 2 > > > > So I added the following two options to solve the above error: > > CONFIG_SPL_DM=y > > CONFIG_SPL_OF_CONTROL=y > > > > > > But it brings new mistakes: > > LD spl/drivers/built-in.o > > LD spl/lib/built-in.o > > LD spl/u-boot-spl > > drivers/built-in.o: In function `blk_post_probe': > > /home/hanch/DSPI/u-boot-fsl-qoriq/drivers/block/blk-uclass.c:645: undefined > reference to `part_init' > > scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed > > make[1]: *** [spl/u-boot-spl] Error 1 > > Makefile:1649: recipe for target 'spl/u-boot-spl' failed > > make: *** [spl/u-boot-spl] Error 2 > > > >
Re: [U-Boot] [PATCH v2 2/2] regulator: bd718x7: support ROHM BD71837 and BD71847 PMICs
HI Matti,
On Wed, 24 Apr 2019 at 06:37, Matti Vaittinen
wrote:
>
> BD71837 and BD71847 is PMIC intended for powering single-core,
> dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847
> is used for example on NXP imx8mm EVK.
>
> Add regulator driver for ROHM BD71837 and BD71847 PMICs.
> BD71837 contains 8 bucks and 7 LDOS. BD71847 is reduced
> version containing 6 bucks and 6 LDOs. Voltages for DVS
This is great info and I think it should be in your Kconfig help -
i.e.a bit more detail in your description of the chip.
> bucks (1-4 on BD71837, 1 and 2 on BD71847) can be adjusted
> when regulators are enabled. For other bucks and LDOs we may
> have over- or undershooting if voltage is adjusted when
> regulator is enabled. Thus this is prevented by default.
>
> BD718x7 has a quirk which may leave power output disabled
> after reset if enable/disable state was controlled by SW.
> Thus the SW control is only allowed for BD71837 bucks
> 3 and 4 by default. The impact of this limitation must be
> evaluated board-by board and restrictions may need to be
> modified. (Linux driver get's these limitations from DT and we
> may want to implement same on u-Boot driver).
>
> Signed-off-by: Matti Vaittinen
> ---
>
> Changelog v1 => v2:
> - document structs containing the platdata
> - use pmic_clrsetbits() instead of using separate reads and writes
> - fix styling issues
>
> drivers/power/pmic/bd71837.c | 42 ++-
> drivers/power/regulator/Kconfig | 15 +
> drivers/power/regulator/Makefile | 1 +
> drivers/power/regulator/bd71837.c | 469 ++
> include/power/bd71837.h | 147 ++
> 5 files changed, 616 insertions(+), 58 deletions(-)
> create mode 100644 drivers/power/regulator/bd71837.c
>
> diff --git a/drivers/power/pmic/bd71837.c b/drivers/power/pmic/bd71837.c
> index b749f9430a..12c2e15a19 100644
> --- a/drivers/power/pmic/bd71837.c
> +++ b/drivers/power/pmic/bd71837.c
> @@ -3,6 +3,8 @@
> * Copyright 2018 NXP
> */
>
> +#define DEBUG
> +
> #include
> #include
> #include
> @@ -16,15 +18,15 @@ DECLARE_GLOBAL_DATA_PTR;
>
> static const struct pmic_child_info pmic_children_info[] = {
> /* buck */
> - { .prefix = "b", .driver = BD71837_REGULATOR_DRIVER},
> + { .prefix = "b", .driver = BD718XX_REGULATOR_DRIVER},
> /* ldo */
> - { .prefix = "l", .driver = BD71837_REGULATOR_DRIVER},
> + { .prefix = "l", .driver = BD718XX_REGULATOR_DRIVER},
> { },
> };
>
> static int bd71837_reg_count(struct udevice *dev)
> {
> - return BD71837_REG_NUM;
> + return BD718XX_MAX_REGISTER - 1;
> }
>
> static int bd71837_write(struct udevice *dev, uint reg, const uint8_t *buff,
> @@ -55,7 +57,7 @@ static int bd71837_bind(struct udevice *dev)
>
> regulators_node = dev_read_subnode(dev, "regulators");
> if (!ofnode_valid(regulators_node)) {
> - debug("%s: %s regulators subnode not found!", __func__,
> + debug("%s: %s regulators subnode not found!\n", __func__,
> dev->name);
> return -ENXIO;
> }
> @@ -70,6 +72,34 @@ static int bd71837_bind(struct udevice *dev)
> return 0;
> }
>
> +static int bd718x7_probe(struct udevice *dev)
> +{
> + int ret;
> + u8 unlock;
> +
> + /* Unlock the PMIC regulator control before probing the children */
> + ret = pmic_reg_read(dev, BD718XX_REGLOCK);
> + if (ret < 0) {
> + debug("%s: %s Failed to read lock register, error %d\n",
> + __func__, dev->name, ret);
> + return ret;
> + }
> +
> + unlock = ret;
> + unlock &= ~(BD718XX_REGLOCK_PWRSEQ | BD718XX_REGLOCK_VREG);
> +
> + ret = pmic_reg_write(dev, BD718XX_REGLOCK, unlock);
Can you use pmic_clrsetbits() ?
> + if (ret) {
> + debug("%s: %s Failed to unlock regulator control\n", __func__,
> + dev->name);
> + return ret;
> + }
> + debug("%s: '%s' - BD718x7 PMIC register unlocked\n", __func__,
> + dev->name);
> +
> + return 0;
> +}
> +
> static struct dm_pmic_ops bd71837_ops = {
> .reg_count = bd71837_reg_count,
> .read = bd71837_read,
> @@ -77,7 +107,8 @@ static struct dm_pmic_ops bd71837_ops = {
> };
>
> static const struct udevice_id bd71837_ids[] = {
> - { .compatible = "rohm,bd71837", .data = 0x4b, },
> + { .compatible = "rohm,bd71837", .data = ROHM_CHIP_TYPE_BD71837, },
> + { .compatible = "rohm,bd71847", .data = ROHM_CHIP_TYPE_BD71847, },
> { }
> };
>
> @@ -86,5 +117,6 @@ U_BOOT_DRIVER(pmic_bd71837) = {
> .id = UCLASS_PMIC,
> .of_match = bd71837_ids,
> .bind = bd71837_bind,
> + .probe = bd718x7_probe,
> .ops = _ops,
> };
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index 3ed0dd2264..323516587c 100644
> ---
Re: [U-Boot] [PATCH v2 1/2] regulator: bd71837: copy the bd71837 pmic driver from NXP imx u-boot
On Wed, 24 Apr 2019 at 06:35, Matti Vaittinen wrote: > > https://source.codeaurora.org/external/imx/uboot-imx > > cherry picked, styled and merged commits: > - MLK-18387 pmic: Add pmic driver for BD71837: e9a3bec2e95a > - MLK-18590 pmic: bd71837: Change to use new fdt API: acdc5c297a96 > > Signed-off-by: Ye Li > Signed-off-by: Matti Vaittinen > --- > > Changelog v1 => v2: > - Drop drivers/power/pmic/pmic_bd71837.c (the old PMIC interface) > - Fix characters in hex numbers to lowercase > > drivers/power/pmic/Kconfig | 7 +++ > drivers/power/pmic/Makefile | 1 + > drivers/power/pmic/bd71837.c | 90 > include/power/bd71837.h | 62 + > 4 files changed, 160 insertions(+) > create mode 100644 drivers/power/pmic/bd71837.c > create mode 100644 include/power/bd71837.h Reviewed-by: Simon Glass Can you drop fdtdec.h? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] misc: uclass: Introduce misc_init_by_ofnode
Hi Keerthy,
On Wed, 24 Apr 2019 at 05:06, Keerthy wrote:
>
> Introduce misc_init_by_ofnode to probe a misc device
> using its ofnode.
Can you please add a motivation for this? Also please can you add a
test for your function in test/dm/misc.c
Regards,
Simon
>
> Signed-off-by: Keerthy
> ---
> drivers/misc/misc-uclass.c | 25 +
> include/misc.h | 9 +
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c
> index 55381edc98..835d3f7118 100644
> --- a/drivers/misc/misc-uclass.c
> +++ b/drivers/misc/misc-uclass.c
> @@ -5,6 +5,8 @@
>
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -65,6 +67,29 @@ int misc_set_enabled(struct udevice *dev, bool val)
> return ops->set_enabled(dev, val);
> }
>
> +int misc_init_by_ofnode(ofnode node)
> +{
> + struct udevice *dev = NULL;
> + int ret;
> + long temp1, temp2;
> +
> + temp1 = ofnode_to_offset(node);
> +
> + for (ret = uclass_find_first_device(UCLASS_MISC, ); dev;
> +ret = uclass_find_next_device()) {
> + temp2 = ofnode_to_offset(dev_ofnode(dev));
> + if (temp1 == temp2) {
> + ret = device_probe(dev);
> + if (ret)
> + debug("%s: Failed to initialize - %d\n",
> + dev->name, ret);
> + return ret;
> + }
> + }
> +
> + return -ENODEV;
> +}
> +
> UCLASS_DRIVER(misc) = {
> .id = UCLASS_MISC,
> .name = "misc",
> diff --git a/include/misc.h b/include/misc.h
> index 12d1325ee2..79263ed480 100644
> --- a/include/misc.h
> +++ b/include/misc.h
> @@ -76,6 +76,15 @@ int misc_call(struct udevice *dev, int msgid, void
> *tx_msg, int tx_size,
> */
> int misc_set_enabled(struct udevice *dev, bool val);
>
> +/**
> + * misc_init_by_ofnode() - Probe a misc device by using ofnode.
> + * @node: ofnode of the misc device.
> + *
> + * A misc device is probed using ofnode.
> + *
> + * Return: -ve on error, 0 on success
> + */
> +int misc_init_by_ofnode(ofnode node);
> /*
> * struct misc_ops - Driver model Misc operations
> *
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv5 0/6] dm: cache: add dm cache driver
On Wed, Apr 24, 2019 at 06:50:30PM -0500, Dinh Nguyen wrote: > > > On 4/24/19 7:58 AM, Tom Rini wrote: > > On Wed, Apr 24, 2019 at 07:32:14AM -0500, Dinh Nguyen wrote: > >> > >> > >> On 4/23/19 5:02 PM, Tom Rini wrote: > >>> On Tue, Apr 23, 2019 at 04:55:00PM -0500, Dinh Nguyen wrote: > Hi, > > This is V4 of the series to add a UCLASS_CACHE dm driver to handling > the configuration of cache settings. Place this new driver under > /drivers/cache. In this initial revision, the driver is only configuring > what I think are essential cache settings. The more comprehensive cache > settings can be done in the OS. > > Diffs from v4: > - Fix compile error found in sandbox_cache.c > >>> > >>> Thanks. I'd greatly appreciate it if you can throw this whole series at > >>> travis (or just do a world build locally) and report back that > >>> everything is OK now. > >>> > >> > >> Will do. By a "world build", you mean using buildman for all > >> architectures right? > > > > Yes. buildman can fetch a valid toolchain for everything I think (and > > there's a documented location in .travis.yml for the maybe 1-2 that it > > doesn't) and then build everything. > > > > buildman just completed and it did not report any errors for this series > of patches. 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] [PATCHv5 0/6] dm: cache: add dm cache driver
On 4/24/19 7:58 AM, Tom Rini wrote: > On Wed, Apr 24, 2019 at 07:32:14AM -0500, Dinh Nguyen wrote: >> >> >> On 4/23/19 5:02 PM, Tom Rini wrote: >>> On Tue, Apr 23, 2019 at 04:55:00PM -0500, Dinh Nguyen wrote: Hi, This is V4 of the series to add a UCLASS_CACHE dm driver to handling the configuration of cache settings. Place this new driver under /drivers/cache. In this initial revision, the driver is only configuring what I think are essential cache settings. The more comprehensive cache settings can be done in the OS. Diffs from v4: - Fix compile error found in sandbox_cache.c >>> >>> Thanks. I'd greatly appreciate it if you can throw this whole series at >>> travis (or just do a world build locally) and report back that >>> everything is OK now. >>> >> >> Will do. By a "world build", you mean using buildman for all >> architectures right? > > Yes. buildman can fetch a valid toolchain for everything I think (and > there's a documented location in .travis.yml for the maybe 1-2 that it > doesn't) and then build everything. > buildman just completed and it did not report any errors for this series of patches. Dinh signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/3] drivers: pci_ep: Introduce UCLASS_PCI_EP uclass
HI Ramon,
On Mon, 22 Apr 2019 at 10:33, Ramon Fried wrote:
>
>
> Hi Simon,
> Thanks for the review.
> please see inline, I have few questions/suggestions regarding
> your notes.
>
> Thanks,
> Ramon.
> On Mon, Apr 22, 2019 at 5:56 AM Simon Glass wrote:
>>
>> Hi Ramon,
>>
>> On Fri, 5 Apr 2019 at 19:12, Ramon Fried wrote:
>> >
>> > Introduce new UCLASS_PCI_EP class for handling PCI endpoint
>> > devices, allowing to set various attributes of the PCI endpoint
>> > device, such as:
>> > * configuration space header
>> > * BAR definitions
>> > * outband memory mapping
>> > * start/stop PCI link
>> >
>> > Signed-off-by: Ramon Fried
>> >
>> > ---
>> >
>> > drivers/Kconfig | 2 +
>> > drivers/Makefile | 1 +
>> > drivers/pci_endpoint/Kconfig | 16 ++
>> > drivers/pci_endpoint/Makefile| 6 +
>> > drivers/pci_endpoint/pci_ep-uclass.c | 192 ++
>> > include/dm/uclass-id.h | 1 +
>> > include/pci_ep.h | 375 +++
>> > 7 files changed, 593 insertions(+)
>> > create mode 100644 drivers/pci_endpoint/Kconfig
>> > create mode 100644 drivers/pci_endpoint/Makefile
>> > create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c
>> > create mode 100644 include/pci_ep.h
>>
[..]
>> > +int dm_pci_ep_set_bar(struct udevice *dev, u8 func_no,
>>
>> Please use uint for func_no. There is no need to limit it to 8 bits,
>> and this may not be efficient for non-8-bit machines. Please fix
>> globally.
>
> I tried to keep the API as similar as it can to the Linux API.
> I can change it, no problem, but IMHO I think it's better to keep it similar.
Hmm, why?
>> Perhaps you should declare a 'mask' variable? In any case, it is
>> confusing for the same variable to have two different meanings, and it
>> does not save code at run-time.
>
> as before, this is practically a copy-paste from Linux, I can change it, but
> I think it's clearer if the code looks the same as in Linux,
> might be easier the port patches like that.
It's a minor thing so you can keep the linux code if you like.
[..]
>> > +int dm_pci_ep_get_msix(struct udevice *dev, u8 func_no)
>> > +{
>> > + struct dm_pci_ep_ops *ops = pci_ep_get_ops(dev);
>> > + int interrupt;
>> > +
>> > + if (!ops->get_msix)
>> > + return -ENODEV;
>> > +
>> > + interrupt = ops->get_msix(dev, func_no);
>> > +
>> > + if (interrupt < 0)
>> > + return 0;
>> > +
>> > + return interrupt + 1;
>>
>> It's odd that your uclass function returns a different value from your
>> driver function. I think that will be confusing. Is it necessary?
>
> As you can understand from the code, 0 means 1 interrupt. basically the
> driver functions just return the msix field in the PCI registers,
> The translation to real number is done by the uclass wrapper.
OK, but why? Why not use the same return value for the drive methods
and the uclass? If you are using a different API, then please rename
one of the functions.
[..]
>> What is a DWORD? I think i is 32-bits, so just say that, since WORD is
>> a confusing term on a non-16-bit machine.
>
> hehe, I presume it's just a copy-paste from the PCI spec. I'll check, if so,
> I'll prefer to keep the original naming.
OK, then how about adding the length as well, since DWORD is pretty
obscure these days.
>
>
>>
>>
>> > + * @subsys_vendor_id: vendor of the add-in card or subsystem
>> > + * @subsys_id: id specific to vendor
>> > + * @interrupt_pin: interrupt pin the device (or device function) uses
>> > + */
>> > +struct pci_ep_header {
>> > + u16 vendorid;
>> > + u16 deviceid;
>> > + u8 revid;
>> > + u8 progif_code;
>> > + u8 subclass_code;
>> > + u8 baseclass_code;
>> > + u8 cache_line_size;
>> > + u16 subsys_vendor_id;
>> > + u16 subsys_id;
>> > + enum pci_interrupt_pin interrupt_pin;
>>
>> Shouldn't that be a u16 or something? The enum does not have a defined
>> size, I think.
>
> well, there can be only 4 different interrupt pins, so it doesn't matter as
> long as the rage
> is checked.
>
My concern is that if this is a hardware-mapped register, then the
enum could be any size, and may not map over the correct bits.
If this is not a hardware-mapped register, then OK.
[..]
>> > + /**
>> > +* set_msix() - set msix capability property
>> > +*
>> > +* set the number of required MSIx vectors the device
>> > +* needs for operation.
>> > +*
>> > +* @dev:device to set
>> > +* @func_num: Function to set
>> > +* @interrupts: required interrupts count
>>
>> This is too vague, please expand it.
>
> You're referring to the set_msix() or the whole section,
> can you elaborate ?
I mean the interrupts line. Can you given example values perhaps? Does
it mean 'number of interrupts required to be
[U-Boot] [PATCH v2 3/4] pci_ep: add pci_ep sandbox driver
Signed-off-by: Ramon Fried
---
arch/sandbox/dts/test.dts | 4 +
configs/sandbox64_defconfig | 2 +
configs/sandbox_defconfig | 2 +
drivers/pci_endpoint/Kconfig | 7 +
drivers/pci_endpoint/Makefile | 1 +
drivers/pci_endpoint/sandbox-pci_ep.c | 176 ++
6 files changed, 192 insertions(+)
create mode 100644 drivers/pci_endpoint/sandbox-pci_ep.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d6451c6..001dc302ed 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -475,6 +475,10 @@
};
};
+ pci_ep: pci_ep {
+ compatible = "sandbox,pci_ep";
+ };
+
probing {
compatible = "simple-bus";
test1 {
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index c04ecd915a..7137ea481c 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -127,9 +127,11 @@ CONFIG_SPI_FLASH_WINBOND=y
CONFIG_DM_ETH=y
CONFIG_NVME=y
CONFIG_PCI=y
+CONFIG_PCI_ENDPOINT=y
CONFIG_DM_PCI=y
CONFIG_DM_PCI_COMPAT=y
CONFIG_PCI_SANDBOX=y
+CONFIG_PCI_SANDBOX_EP=y
CONFIG_PHY=y
CONFIG_PHY_SANDBOX=y
CONFIG_PINCTRL=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index bb508a8d02..04ba9a3ba1 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -142,9 +142,11 @@ CONFIG_SPI_FLASH_WINBOND=y
CONFIG_DM_ETH=y
CONFIG_NVME=y
CONFIG_PCI=y
+CONFIG_PCI_ENDPOINT=y
CONFIG_DM_PCI=y
CONFIG_DM_PCI_COMPAT=y
CONFIG_PCI_SANDBOX=y
+CONFIG_PCI_SANDBOX_EP=y
CONFIG_PHY=y
CONFIG_PHY_SANDBOX=y
CONFIG_PINCTRL=y
diff --git a/drivers/pci_endpoint/Kconfig b/drivers/pci_endpoint/Kconfig
index c54bd2a9ac..e529e560fc 100644
--- a/drivers/pci_endpoint/Kconfig
+++ b/drivers/pci_endpoint/Kconfig
@@ -22,4 +22,11 @@ config PCIE_CADENCE_EP
endpoint mode. This PCIe controller may be embedded into many
different vendors SoCs.
+config PCI_SANDBOX_EP
+ bool "Sandbox PCIe endpoint controller"
+ depends on PCI_ENDPOINT
+ help
+ Say Y here if you want to support the Sandbox PCIe controller in
+ endpoint mode.
+
endmenu
diff --git a/drivers/pci_endpoint/Makefile b/drivers/pci_endpoint/Makefile
index 0a849deb19..3cd987259d 100644
--- a/drivers/pci_endpoint/Makefile
+++ b/drivers/pci_endpoint/Makefile
@@ -5,3 +5,4 @@
obj-y += pci_ep-uclass.o
obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
+obj-$(CONFIG_PCI_SANDBOX_EP) += sandbox-pci_ep.o
diff --git a/drivers/pci_endpoint/sandbox-pci_ep.c
b/drivers/pci_endpoint/sandbox-pci_ep.c
new file mode 100644
index 00..eb19c6da81
--- /dev/null
+++ b/drivers/pci_endpoint/sandbox-pci_ep.c
@@ -0,0 +1,176 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Ramon Fried
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sandbox_pci_ep_priv {
+ struct pci_ep_header hdr;
+ int msix;
+ int msi;
+};
+
+static const struct udevice_id sandbox_pci_ep_ids[] = {
+ { .compatible = "sandbox,pci_ep" },
+ { }
+};
+
+static int sandbox_write_header(struct udevice *dev, uint fn,
+ struct pci_ep_header *hdr)
+{
+ struct sandbox_pci_ep_priv *priv = dev_get_priv(dev);
+
+ if (fn > 0)
+ return -ENODEV;
+
+ memcpy(>hdr, hdr, sizeof(*hdr));
+
+ return 0;
+}
+
+static int sandbox_read_header(struct udevice *dev, uint fn,
+ struct pci_ep_header *hdr)
+{
+ struct sandbox_pci_ep_priv *priv = dev_get_priv(dev);
+
+ if (fn > 0)
+ return -ENODEV;
+
+ memcpy(hdr, >hdr, sizeof(*hdr));
+
+ return 0;
+}
+
+static int sandbox_set_bar(struct udevice *dev, uint fn,
+ struct pci_bar *ep_bar)
+{
+ if (fn > 0)
+ return -ENODEV;
+ return 0;
+}
+
+int sandbox_clear_bar(struct udevice *dev, uint fn,
+ enum pci_barno bar)
+{
+ if (fn > 0)
+ return -ENODEV;
+ return 0;
+}
+
+static int sandbox_map_addr(struct udevice *dev, uint fn, phys_addr_t addr,
+ u64 pci_addr, size_t size)
+{
+ if (fn > 0)
+ return -ENODEV;
+
+ return 0;
+}
+
+static void sandbox_unmap_addr(struct udevice *dev, uint fn, phys_addr_t addr)
+{
+ if (fn > 0)
+ return;
+}
+
+static int sandbox_set_msi(struct udevice *dev, uint fn, uint interrupts)
+{
+ struct sandbox_pci_ep_priv *priv = dev_get_priv(dev);
+
+ if (fn > 0)
+ return -ENODEV;
+
+ priv->msi = interrupts;
+
+ return 0;
+}
+
+static int sandbox_get_msi(struct udevice *dev, uint fn)
+{
+ struct sandbox_pci_ep_priv *priv = dev_get_priv(dev);
+
+ if (fn > 0)
+ return -ENODEV;
+
+ return priv->msi;
+}
+
+static int sandbox_set_msix(struct udevice *dev,
[U-Boot] [PATCH v2 4/4] test: pci_ep: add basic pci_ep tests
Add basic PCI endpoint sandbox testing.
Signed-off-by: Ramon Fried
---
test/dm/Makefile | 1 +
test/dm/pci_ep.c | 45 +
2 files changed, 46 insertions(+)
create mode 100644 test/dm/pci_ep.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 49857c5092..fe36f8df47 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -30,6 +30,7 @@ obj-y += ofnode.o
obj-$(CONFIG_OSD) += osd.o
obj-$(CONFIG_DM_VIDEO) += panel.o
obj-$(CONFIG_DM_PCI) += pci.o
+obj-$(CONFIG_PCI_ENDPOINT) += pci_ep.o
obj-$(CONFIG_PCH) += pch.o
obj-$(CONFIG_PHY) += phy.o
obj-$(CONFIG_POWER_DOMAIN) += power-domain.o
diff --git a/test/dm/pci_ep.c b/test/dm/pci_ep.c
new file mode 100644
index 00..5f2153e393
--- /dev/null
+++ b/test/dm/pci_ep.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Ramon Fried
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Test that sandbox PCI EP works correctly */
+static int dm_test_pci_ep_base(struct unit_test_state *uts)
+{
+ struct udevice *bus;
+ struct pci_ep_header ep_header = {
+ .vendorid = 0x1234,
+ .deviceid = 0x2020,
+ .revid = 1,
+ .interrupt_pin = PCI_INTERRUPT_INTA,
+ };
+
+ struct pci_bar bar = {
+ .phys_addr = 0x8000,
+ .size = 0x10,
+ .barno = BAR_0,
+ .flags = PCI_BASE_ADDRESS_MEM_TYPE_64 |
+ PCI_BASE_ADDRESS_MEM_PREFETCH,
+ };
+
+ ut_assertok(uclass_get_device(UCLASS_PCI_EP, 0, ));
+ ut_assertnonnull(bus);
+
+ ut_assertok(pci_ep_write_header(bus, 0, _header));
+ ut_assertok(pci_ep_set_msi(bus, 0, 4));
+ ut_assertok(pci_ep_set_msix(bus, 0, 360));
+ ut_assertok(pci_ep_set_bar(bus, 0, ));
+
+ return 0;
+}
+
+DM_TEST(dm_test_pci_ep_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] trouble booting spl/u-boot from emmc on i.mx6ul
I am trying to debug a failure to boot spl/u-boot on an NXP i.mx6ul using emmc. I'm using u-boot source from: https://github.com/Freescale/u-boot-fslc.git -b 2017.11+fslc and I'm building target mx6ul_14x14_evk_defconfig. I asked for help on the "NXP Community Forum" but was referred here since NXP apparently doesn't support spl configurations. I'm hoping somebody here might be familiar enough with this soc to help. Basically I get a brick after reset, with no output on the console. My jtag interface won't let me halt the cpu immediately after reset, but I can still poke around. I can see the ivt (initial part of spl image) loaded in ocram, but the code at the spl entry point is not correct (more details below). However, if I manually reload (sdp or jtag) the spl image it runs fine. I can also load and run the same spl image on an sd card on a similar reference board (same soc/ddr, but sd instead of emmc). So I think the spl image itself is okay. I should also mention that I can use an older, non-spl u-boot image that boots from emmc just fine, so I think my hw bootmode/emmc jumpers are okay. The big difference is the older u-boot is a monolithic u-boot.imx image (ivt + dcd + u-boot.bin) rather than a split spl + u-boot.img. For anyone familiar with i.mx6ul boot details, here is what I've tried: a) checking imx_usb_loader scripts to make sure emmc installation was done correctly. dd if=/dev/zero of=/dev/mmcblk1 bs=1k seek=512 conv=fsync count=8 echo 0 > /sys/block/mmcblk1boot0/force_ro dd if=SPL of=/dev/mmcblk1boot0 bs=512 seek=2 dd if=u-boot.img of=/dev/mmcblk1boot0 bs=512 seek=138 echo 1 > /sys/block/mmcblk1boot0/force_ro mmc bootpart enable 1 1 /dev/mmcblk1 # My emmc has an 8g user area and two 16MiB boot partitions. # I've tried zeroing them all out and writing the spl image to one # at a time to verify I am programming/using the correct area # of flash. Everything appears ok, and I am able to boot my # 2015 version of u-boot from emmc using the same steps. b) checking the extcsd info on the emmc to make sure boot partition is enabled. Also played around with Boot bus conditions but wound up leaving them at 0x0. Boot configuration bytes [PARTITION_CONFIG: 0x48] Boot Partition 1 enabled No access to boot partition Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x00] # I've tried all combinations I could find, none worked better, # many worked worse. c) after reset, checking smbr1/sbmr2 (they look mostly ok) sbmr1=10004860 [cfg4: 10 - ECSPIx_SS1 - pulled high by mistake, shouldn't hurt?] [cfg3: 00 - reserved] [cfg2: 48 - 8-bit, eSDHC2, 0-500/400mhz, 3.3v] [cfg1: 60 - emmc, regular-boot, high-speed, fast-boot-ack-enb, no-sd-power-cyc, thru-sd] sbmr2=0241[bmod=internal, 4=??, sec_config=open] d) after reset, checking whether ivt got loaded in ocram (it was). J-Link>mem32 907400,c 00907400 = 402000D1 00908000 00907410 = 00907420 00907400 00907420 = 00907000 D000 400400D2 e) checking spl ivt header for correctness (looks ok) (script from https://community.nxp.com/docs/DOC-102453) $ python3 imxbin.py SPL =IVT data=== ivt_length=20 ivt_entry=908000 ivt_dcd=0 ivt_boot_data=907420 ivt_self=907400 ivt_csf=0 =DCD data=== No DCD data in table f) after reset, checking whether code got loaded into ocram (usually not!) Why is ivt okay but this never got loaded or was it overwritten? J-Link>mem32 908000,8 00908000 = 5880BCE7 9EB3322F E4B82B75 BCA61DFB 00908010 = D81D695D 59B3F13D 483D24F5 21F92F47 when loading from usb-sdp this ocram location contains correct spl code, and it stays there all the way thru the main u-boot prompt. why the difference? J-Link>mem32 908000,8 00908000 = EA0F E59FF014 E59FF014 E59FF014 00908010 = E59FF014 E59FF014 E59FF014 E59FF014 Any other ideas on how to debug this? It seems like (f) is a big clue, but I don't know where to go with it. Sorry for the length of this email! Bob Cagle ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] pci_ep: add Cadence PCIe endpoint driver
Add Cadence PCIe endpoint driver supporting configuration
of header, bars and MSI for device.
Signed-off-by: Ramon Fried
---
.../pci_endpoint/cdns,cdns-pcie-ep.txt| 18 +
drivers/pci_endpoint/Kconfig | 8 +
drivers/pci_endpoint/Makefile | 1 +
drivers/pci_endpoint/pcie-cadence-ep.c| 177 ++
drivers/pci_endpoint/pcie-cadence.h | 309 ++
5 files changed, 513 insertions(+)
create mode 100644 doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt
create mode 100644 drivers/pci_endpoint/pcie-cadence-ep.c
create mode 100644 drivers/pci_endpoint/pcie-cadence.h
diff --git a/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt
b/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt
new file mode 100644
index 00..7705430559
--- /dev/null
+++ b/doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt
@@ -0,0 +1,18 @@
+* Cadence PCIe endpoint controller
+
+Required properties:
+- compatible: Should contain "cdns,cdns-pcie-ep" to identify the IP used.
+- reg: Should contain the controller register base address.
+
+Optional properties:
+- max-functions: Maximum number of functions that can be configured (default
1).
+- cdns,max-outbound-regions: Set to maximum number of outbound regions
(default 8)
+
+Example:
+
+pcie_ep@fc00 {
+ compatible = "cdns,cdns-pcie-ep";
+ reg = <0x0 0xfc00 0x0 0x0100>;
+ cdns,max-outbound-regions = <16>;
+ max-functions = /bits/ 8 <8>;
+};
diff --git a/drivers/pci_endpoint/Kconfig b/drivers/pci_endpoint/Kconfig
index ac4f43d1ab..c54bd2a9ac 100644
--- a/drivers/pci_endpoint/Kconfig
+++ b/drivers/pci_endpoint/Kconfig
@@ -14,4 +14,12 @@ config PCI_ENDPOINT
controllers that can operate in endpoint mode (as a device
connected to PCI host or bridge).
+config PCIE_CADENCE_EP
+ bool "Cadence PCIe endpoint controller"
+ depends on PCI_ENDPOINT
+ help
+ Say Y here if you want to support the Cadence PCIe controller in
+ endpoint mode. This PCIe controller may be embedded into many
+ different vendors SoCs.
+
endmenu
diff --git a/drivers/pci_endpoint/Makefile b/drivers/pci_endpoint/Makefile
index 80a1066925..0a849deb19 100644
--- a/drivers/pci_endpoint/Makefile
+++ b/drivers/pci_endpoint/Makefile
@@ -4,3 +4,4 @@
# Ramon Fried
obj-y += pci_ep-uclass.o
+obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
diff --git a/drivers/pci_endpoint/pcie-cadence-ep.c
b/drivers/pci_endpoint/pcie-cadence-ep.c
new file mode 100644
index 00..60032fc724
--- /dev/null
+++ b/drivers/pci_endpoint/pcie-cadence-ep.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019
+ * Written by Ramon Fried
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pcie-cadence.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int cdns_write_header(struct udevice *dev, uint fn,
+struct pci_ep_header *hdr)
+{
+ struct cdns_pcie *pcie = dev_get_priv(dev);
+
+ cdns_pcie_ep_fn_writew(pcie, fn, PCI_DEVICE_ID, hdr->deviceid);
+ cdns_pcie_ep_fn_writeb(pcie, fn, PCI_REVISION_ID, hdr->revid);
+ cdns_pcie_ep_fn_writeb(pcie, fn, PCI_CLASS_PROG,
+ hdr->progif_code);
+ cdns_pcie_ep_fn_writew(pcie, fn, PCI_CLASS_DEVICE,
+ hdr->subclass_code |
+ hdr->baseclass_code << 8);
+ cdns_pcie_ep_fn_writeb(pcie, fn, PCI_CACHE_LINE_SIZE,
+ hdr->cache_line_size);
+ cdns_pcie_ep_fn_writew(pcie, fn, PCI_SUBSYSTEM_ID,
+ hdr->subsys_id);
+ cdns_pcie_ep_fn_writeb(pcie, fn, PCI_INTERRUPT_PIN,
+ hdr->interrupt_pin);
+
+ /*
+* Vendor ID can only be modified from function 0, all other functions
+* use the same vendor ID as function 0.
+*/
+ if (fn == 0) {
+ /* Update the vendor IDs. */
+ u32 id = CDNS_PCIE_LM_ID_VENDOR(hdr->vendorid) |
+CDNS_PCIE_LM_ID_SUBSYS(hdr->subsys_vendor_id);
+
+ cdns_pcie_writel(pcie, CDNS_PCIE_LM_ID, id);
+ }
+
+ return 0;
+}
+
+static int cdns_set_bar(struct udevice *dev, uint fn, struct pci_bar *ep_bar)
+{
+ struct cdns_pcie *pcie = dev_get_priv(dev);
+ dma_addr_t bar_phys = ep_bar->phys_addr;
+ enum pci_barno bar = ep_bar->barno;
+ int flags = ep_bar->flags;
+ u32 addr0, addr1, reg, cfg, b, aperture, ctrl;
+ u64 sz;
+
+ /* BAR size is 2^(aperture + 7) */
+ sz = max_t(size_t, ep_bar->size, CDNS_PCIE_EP_MIN_APERTURE);
+ /*
+* roundup_pow_of_two() returns an unsigned long, which is not suited
+* for 64bit values.
+*/
+ sz = 1ULL << fls64(sz - 1);
+ aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
+
[U-Boot] [PATCH v2 1/4] drivers: pci_ep: Introduce UCLASS_PCI_EP uclass
Introduce new UCLASS_PCI_EP class for handling PCI endpoint
devices, allowing to set various attributes of the PCI endpoint
device, such as:
* configuration space header
* BAR definitions
* outband memory mapping
* start/stop PCI link
Signed-off-by: Ramon Fried
---
Changes in V2:
- Changed u8/u16... to uint
- Changed EINVAL to ENOSYS
- Changed void funcs to int
- Added a bit more info in comments
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/pci_endpoint/Kconfig | 17 ++
drivers/pci_endpoint/Makefile| 6 +
drivers/pci_endpoint/pci_ep-uclass.c | 189 +
include/dm/uclass-id.h | 1 +
include/pci_ep.h | 388 +++
7 files changed, 604 insertions(+)
create mode 100644 drivers/pci_endpoint/Kconfig
create mode 100644 drivers/pci_endpoint/Makefile
create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c
create mode 100644 include/pci_ep.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e6702eced4..258dfa19e8 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -64,6 +64,8 @@ source "drivers/nvme/Kconfig"
source "drivers/pci/Kconfig"
+source "drivers/pci_endpoint/Kconfig"
+
source "drivers/pch/Kconfig"
source "drivers/pcmcia/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index a7bba3ed56..480b97ef58 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_FPGA) += fpga/
obj-y += misc/
obj-$(CONFIG_MMC) += mmc/
obj-$(CONFIG_NVME) += nvme/
+obj-$(CONFIG_PCI_ENDPOINT) += pci_endpoint/
obj-y += pcmcia/
obj-y += dfu/
obj-$(CONFIG_PCH) += pch/
diff --git a/drivers/pci_endpoint/Kconfig b/drivers/pci_endpoint/Kconfig
new file mode 100644
index 00..ac4f43d1ab
--- /dev/null
+++ b/drivers/pci_endpoint/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# PCI Endpoint Support
+#
+
+menu "PCI Endpoint"
+
+config PCI_ENDPOINT
+ bool "PCI Endpoint Support"
+ depends on DM
+ help
+ Enable this configuration option to support configurable PCI
+ endpoints. This should be enabled if the platform has a PCI
+ controllers that can operate in endpoint mode (as a device
+ connected to PCI host or bridge).
+
+endmenu
diff --git a/drivers/pci_endpoint/Makefile b/drivers/pci_endpoint/Makefile
new file mode 100644
index 00..80a1066925
--- /dev/null
+++ b/drivers/pci_endpoint/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2019
+# Ramon Fried
+
+obj-y += pci_ep-uclass.o
diff --git a/drivers/pci_endpoint/pci_ep-uclass.c
b/drivers/pci_endpoint/pci_ep-uclass.c
new file mode 100644
index 00..403441cf02
--- /dev/null
+++ b/drivers/pci_endpoint/pci_ep-uclass.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * PCI Endpoint uclass
+ *
+ * Based on Linux PCI-EP driver written by
+ * Kishon Vijay Abraham I
+ *
+ * Copyright (c) 2019
+ * Written by Ramon Fried
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int pci_ep_write_header(struct udevice *dev, uint fn, struct pci_ep_header
*hdr)
+{
+ struct pci_ep_ops *ops = pci_ep_get_ops(dev);
+
+ if (!ops->write_header)
+ return -ENOSYS;
+
+ return ops->write_header(dev, fn, hdr);
+}
+
+int pci_ep_read_header(struct udevice *dev, uint fn, struct pci_ep_header *hdr)
+{
+ struct pci_ep_ops *ops = pci_ep_get_ops(dev);
+
+ if (!ops->read_header)
+ return -ENOSYS;
+
+ return ops->read_header(dev, fn, hdr);
+}
+
+int pci_ep_set_bar(struct udevice *dev, uint func_no, struct pci_bar *ep_bar)
+{
+ struct pci_ep_ops *ops = pci_ep_get_ops(dev);
+ int flags = ep_bar->flags;
+
+ /* Some basic bar validity checks */
+ if (((ep_bar->barno == BAR_5) &&
+ (flags & PCI_BASE_ADDRESS_MEM_TYPE_64)) ||
+ ((flags & PCI_BASE_ADDRESS_SPACE_IO) &&
+ (flags & PCI_BASE_ADDRESS_IO_MASK)) ||
+ (upper_32_bits(ep_bar->size) &&
+ !(flags & PCI_BASE_ADDRESS_MEM_TYPE_64)))
+ return -EINVAL;
+
+ if (!ops->set_bar)
+ return -ENOSYS;
+
+ return ops->set_bar(dev, func_no, ep_bar);
+}
+
+int pci_ep_clear_bar(struct udevice *dev, uint func_num, enum pci_barno bar)
+{
+ struct pci_ep_ops *ops = pci_ep_get_ops(dev);
+
+ if (!ops->clear_bar)
+ return -ENOSYS;
+
+ return ops->clear_bar(dev, func_num, bar);
+}
+
+int pci_ep_map_addr(struct udevice *dev, uint func_no, phys_addr_t addr,
+ u64 pci_addr, size_t size)
+{
+ struct pci_ep_ops *ops = pci_ep_get_ops(dev);
+
+ if (!ops->map_addr)
+ return -ENOSYS;
+
+ return ops->map_addr(dev, func_no, addr, pci_addr, size);
+}
+
+void pci_ep_unmap_addr(struct udevice *dev, uint func_no, phys_addr_t addr)
+{
+ struct pci_ep_ops *ops = pci_ep_get_ops(dev);
+
[U-Boot] [PATCH v2 0/4] Add Cadence PCIe endpoint driver with new uclass
This patchset adds support for new uclass, UCLASS_PCI_EP allowing new set of PCI endpoint drivers. Included in the patch is also a driver for Cadence PCIe endpoint. Changes in V2: - Removed "pci.h: add missing maskbit" as it was already merged by Simon. - Added PCI endpoint sandbox driver - Added testing for sandbox driver - Addressed issues raised by Simon in UCLASS_PCI_EP class implementation Ramon Fried (4): drivers: pci_ep: Introduce UCLASS_PCI_EP uclass pci_ep: add Cadence PCIe endpoint driver pci_ep: add pci_ep sandbox driver test: pci_ep: add basic pci_ep tests arch/sandbox/dts/test.dts | 4 + configs/sandbox64_defconfig | 2 + configs/sandbox_defconfig | 2 + .../pci_endpoint/cdns,cdns-pcie-ep.txt| 18 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/pci_endpoint/Kconfig | 32 ++ drivers/pci_endpoint/Makefile | 8 + drivers/pci_endpoint/pci_ep-uclass.c | 189 + drivers/pci_endpoint/pcie-cadence-ep.c| 177 drivers/pci_endpoint/pcie-cadence.h | 309 ++ drivers/pci_endpoint/sandbox-pci_ep.c | 176 include/dm/uclass-id.h| 1 + include/pci_ep.h | 388 ++ test/dm/Makefile | 1 + test/dm/pci_ep.c | 45 ++ 16 files changed, 1355 insertions(+) create mode 100644 doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt create mode 100644 drivers/pci_endpoint/Kconfig create mode 100644 drivers/pci_endpoint/Makefile create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c create mode 100644 drivers/pci_endpoint/pcie-cadence-ep.c create mode 100644 drivers/pci_endpoint/pcie-cadence.h create mode 100644 drivers/pci_endpoint/sandbox-pci_ep.c create mode 100644 include/pci_ep.h create mode 100644 test/dm/pci_ep.c -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] pci_ep: add Cadence PCIe endpoint driver
Hi Ramon, On Wed, 24 Apr 2019 at 12:54, Ramon Fried wrote: > > Add Cadence PCIe endpoint driver supporting configuration > of header, bars and MSI for device. > > Signed-off-by: Ramon Fried > --- > > .../pci_endpoint/cdns,cdns-pcie-ep.txt| 18 + > drivers/pci_endpoint/Kconfig | 8 + > drivers/pci_endpoint/Makefile | 1 + > drivers/pci_endpoint/pcie-cadence-ep.c| 177 ++ > drivers/pci_endpoint/pcie-cadence.h | 309 ++ > 5 files changed, 513 insertions(+) > create mode 100644 > doc/device-tree-bindings/pci_endpoint/cdns,cdns-pcie-ep.txt > create mode 100644 drivers/pci_endpoint/pcie-cadence-ep.c > create mode 100644 drivers/pci_endpoint/pcie-cadence.h This looks OK to me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] drivers: pci_ep: Introduce UCLASS_PCI_EP uclass
Hi Ramon, On Wed, 24 Apr 2019 at 12:54, Ramon Fried wrote: > > Introduce new UCLASS_PCI_EP class for handling PCI endpoint > devices, allowing to set various attributes of the PCI endpoint > device, such as: > * configuration space header > * BAR definitions > * outband memory mapping > * start/stop PCI link > > Signed-off-by: Ramon Fried > > --- > Changes in V2: > - Changed u8/u16... to uint > - Changed EINVAL to ENOSYS > - Changed void funcs to int > - Added a bit more info in comments The only thing I see here is that unmap_addr should return an int, and encode_int should be uint, not u8. > > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/pci_endpoint/Kconfig | 17 ++ > drivers/pci_endpoint/Makefile| 6 + > drivers/pci_endpoint/pci_ep-uclass.c | 189 + > include/dm/uclass-id.h | 1 + > include/pci_ep.h | 388 +++ > 7 files changed, 604 insertions(+) > create mode 100644 drivers/pci_endpoint/Kconfig > create mode 100644 drivers/pci_endpoint/Makefile > create mode 100644 drivers/pci_endpoint/pci_ep-uclass.c > create mode 100644 include/pci_ep.h > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] pci_ep: add pci_ep sandbox driver
Hi Ramon,
On Wed, 24 Apr 2019 at 12:54, Ramon Fried wrote:
Please add a commit message.
>
> Signed-off-by: Ramon Fried
> ---
>
> arch/sandbox/dts/test.dts | 4 +
> configs/sandbox64_defconfig | 2 +
> configs/sandbox_defconfig | 2 +
> drivers/pci_endpoint/Kconfig | 7 +
> drivers/pci_endpoint/Makefile | 1 +
> drivers/pci_endpoint/sandbox-pci_ep.c | 176 ++
> 6 files changed, 192 insertions(+)
> create mode 100644 drivers/pci_endpoint/sandbox-pci_ep.c
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8b2d6451c6..001dc302ed 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -475,6 +475,10 @@
> };
> };
>
> + pci_ep: pci_ep {
> + compatible = "sandbox,pci_ep";
> + };
> +
> probing {
> compatible = "simple-bus";
> test1 {
> diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> index c04ecd915a..7137ea481c 100644
> --- a/configs/sandbox64_defconfig
> +++ b/configs/sandbox64_defconfig
> @@ -127,9 +127,11 @@ CONFIG_SPI_FLASH_WINBOND=y
> CONFIG_DM_ETH=y
> CONFIG_NVME=y
> CONFIG_PCI=y
> +CONFIG_PCI_ENDPOINT=y
It might be better to 'imply' this in the sandbox Kconfig file.
> CONFIG_DM_PCI=y
> CONFIG_DM_PCI_COMPAT=y
> CONFIG_PCI_SANDBOX=y
> +CONFIG_PCI_SANDBOX_EP=y
> CONFIG_PHY=y
> CONFIG_PHY_SANDBOX=y
> CONFIG_PINCTRL=y
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index bb508a8d02..04ba9a3ba1 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -142,9 +142,11 @@ CONFIG_SPI_FLASH_WINBOND=y
> CONFIG_DM_ETH=y
> CONFIG_NVME=y
> CONFIG_PCI=y
> +CONFIG_PCI_ENDPOINT=y
> CONFIG_DM_PCI=y
> CONFIG_DM_PCI_COMPAT=y
> CONFIG_PCI_SANDBOX=y
> +CONFIG_PCI_SANDBOX_EP=y
> CONFIG_PHY=y
> CONFIG_PHY_SANDBOX=y
> CONFIG_PINCTRL=y
> diff --git a/drivers/pci_endpoint/Kconfig b/drivers/pci_endpoint/Kconfig
> index c54bd2a9ac..e529e560fc 100644
> --- a/drivers/pci_endpoint/Kconfig
> +++ b/drivers/pci_endpoint/Kconfig
> @@ -22,4 +22,11 @@ config PCIE_CADENCE_EP
> endpoint mode. This PCIe controller may be embedded into many
> different vendors SoCs.
>
> +config PCI_SANDBOX_EP
> + bool "Sandbox PCIe endpoint controller"
> + depends on PCI_ENDPOINT
> + help
> + Say Y here if you want to support the Sandbox PCIe controller in
Use single space after PCIe
> + endpoint mode.
How about another few sentences saying what the driver does?
> +
> endmenu
> diff --git a/drivers/pci_endpoint/Makefile b/drivers/pci_endpoint/Makefile
> index 0a849deb19..3cd987259d 100644
> --- a/drivers/pci_endpoint/Makefile
> +++ b/drivers/pci_endpoint/Makefile
> @@ -5,3 +5,4 @@
>
> obj-y += pci_ep-uclass.o
> obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
> +obj-$(CONFIG_PCI_SANDBOX_EP) += sandbox-pci_ep.o
> diff --git a/drivers/pci_endpoint/sandbox-pci_ep.c
> b/drivers/pci_endpoint/sandbox-pci_ep.c
> new file mode 100644
> index 00..eb19c6da81
> --- /dev/null
> +++ b/drivers/pci_endpoint/sandbox-pci_ep.c
> @@ -0,0 +1,176 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 Ramon Fried
> + */
> +
> +#include
> +#include
> +#include
I think you can drop this
> +#include
> +#include
> +#include
> +
struct comment, explaining each member.
> +struct sandbox_pci_ep_priv {
> + struct pci_ep_header hdr;
> + int msix;
> + int msi;
> +};
> +
> +static const struct udevice_id sandbox_pci_ep_ids[] = {
> + { .compatible = "sandbox,pci_ep" },
> + { }
> +};
> +
> +static int sandbox_write_header(struct udevice *dev, uint fn,
> + struct pci_ep_header *hdr)
> +{
> + struct sandbox_pci_ep_priv *priv = dev_get_priv(dev);
> +
> + if (fn > 0)
> + return -ENODEV;
> +
> + memcpy(>hdr, hdr, sizeof(*hdr));
> +
> + return 0;
> +}
> +
> +static int sandbox_read_header(struct udevice *dev, uint fn,
> + struct pci_ep_header *hdr)
> +{
> + struct sandbox_pci_ep_priv *priv = dev_get_priv(dev);
> +
> + if (fn > 0)
> + return -ENODEV;
> +
> + memcpy(hdr, >hdr, sizeof(*hdr));
> +
> + return 0;
> +}
> +
> +static int sandbox_set_bar(struct udevice *dev, uint fn,
> + struct pci_bar *ep_bar)
> +{
> + if (fn > 0)
> + return -ENODEV;
blank line before return. Please fix globally.
> + return 0;
> +}
> +
> +int sandbox_clear_bar(struct udevice *dev, uint fn,
static int?
> + enum pci_barno bar)
> +{
> + if (fn > 0)
> + return -ENODEV;
> + return 0;
> +}
> +
> +static int sandbox_map_addr(struct udevice *dev, uint fn, phys_addr_t addr,
> + u64 pci_addr, size_t size)
> +{
> + if (fn > 0)
> +
Re: [U-Boot] [PATCH 1/3] rockchip: rk3399: add tpl support
Hi, On Thu, 18 Apr 2019 at 10:47, Heiko Stübner wrote: > > Am Donnerstag, 18. April 2019, 08:35:49 CEST schrieb Philipp Tomsich: > > Simon, > > > > > On 18.04.2019, at 06:32, Simon Glass wrote: > > > > > > Hi Kever, > > > > > > On Mon, 1 Apr 2019 at 02:21, Kever Yang wrote: > > >> > > >> Rockchip platform suppose to use TPL(run in SRAM) as dram init and > > >> SPL(run in DDR SDRAM) as pre-loader, so that the SPL would not be > > >> limited by SRAM size. > > >> This patch add rk3399-board-tpl.c and its common configs. > > > > > > So this means that TPL inits SDRAM? That seems strange to me...why > > > have SPL at all, then? What is SPL supported to do on RK3399 > > > platforms? > > > > For TPL->SPL implementation on Rockchip, we generally rely on the BootROM > > to load the TPL stage (to SRAM) and the SPL stage (to the start of DRAM). > > The > > BootROM usually limits the size of the SPL stage, so we can’t use a full > > U-Boot > > already. > > > > Even more constricting are the TPL size constraints (as this seems to have > > originally > > only been intended to be size-optimized DRAM init code) on some devices. > > and maybe for a broader functionality description, something needs to > load things like ATF via a FIT image from a mmc for example. > (which needs FIT code and also real mmc drivers). > > And as we experienced on rk3288 as well recently, SRAM may be very well > too small to accomplish that, so TPL needs to init the sdram separately > to make room for the code needed to get ATF up and running, which must > be done before jumping into proper uboot. I have to ask what the boot ROM is buying us? U-Boot TPL/SPL can load programs itself without the boot ROM and its size limit. Why not just stop using the boot ROM on these devices? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting MX6 via Serial Download after DM conversion
Hi Peng, On Tue, Apr 23, 2019 at 11:18 PM Peng Fan wrote: > Not try this. > uuu should support SPL file being loaded, then if SPL could runs into > fastboot mode > to interactive with uuu, then u-boot-dtb.img could be loaded I think. My colleague Breno tried to load SPL + u-boot-dtb.img using the UUU tool and it also failed. Could you please try to fix this regression? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] efi_loader: non-volatile variables support
On 4/24/19 8:30 AM, AKASHI Takahiro wrote: This patch set is an attempt to implement non-volatile attribute for UEFI variables. Under the current implementation, * SetVariable API doesn't recognize non-volatile attribute * While some variables are defined non-volatile in UEFI specification, they are NOT marked as non-volatile in the code. * env_save() (or "env save" command) allows us to save all the variables into persistent storage, but it may cause volatile UEFI variables, along with irrelevant U-Boot variables, to be saved unconditionally. Those observation rationalizes that the implementation of UEFI variables should be revamped utilizing dedicated storage for them. This patch set is yet experimental and rough-edged(See known issues below), but shows how UEFI variables can be split from U-Boot environment. This enhancement will also be vital when we introduce UEFI secure boot where secure and tamper-resistant storage (with authentication) is required. Usage: To enable this feature, the following configs must be enabled: CONFIG_ENV_IS_IN_FAT CONFIG_ENV_FAT_INTERFACE CONFIG_ENV_EFI_FAT_DEVICE_AND_PART CONFIG_ENV_EFI_FAT_FILE You can also define a non-volatile variable from command interface: => setenv -e -nv FOO baa Known issues/restriction: * UEFI spec defines "globally defined variables" with specific attributes, but with this patch, we don't check against the user-supplied attribute for any variable. * Only FAT can be enabled for persistent storage for UEFI non-volatile variables. * The whole area of storage will be saved at every update of one variable. It can be optimized. * An error during saving may cause inconsistency between cache (hash table) and the storage. * Cache is of fixed size and can be quite big for normal usage. Hello Takahiro, thanks a lot for looking into persisting non-volatile UEFI variables. Before diving into the details of the patches let us discuss the overall design. My understanding is that we need a buffer that lives in EFI_RUNTIME_SERVICES_DATA and holds all variables. It is this buffer that the operating system will access when getting or setting variables. If a non-volatile variable is set via SetVariable() we will call a backend driver. Our current backend is using U-Boot environment variables. It can only be accessed at boottime. Currently there is no guarantee that the U-Boot variables are saved before booting. So it does not support persisting non-volatile variables reliably. Your patch series supplies a new backend using a file for persisting non-volatile variables. It can only be accessed at boottime. Essentially this solution requires no restriction to FAT file systems. We could as well use the EXT4 driver for reading or writing the file. This file storage is completely independent of the U-Boot environment. So it shall not involve any changes to files env/*. I think a documentation of the file format provided in a README would be helpful. In case of both backends we would return EFI_UNSUPPORTED when trying to set a non-volatile variable at runtime. Setting a volatile variable at runtime should be allowable as long as we have sufficient space in our buffer. We can remove these backends based on the EVT_SIGNAL_EXIT_BOOT_SERVICES event. A future backend may support persisting non-volatile variables at runtime. I would prefer if we could first introduce patches that provide the buffer for EFI variables and link it to the UEFI variable based backend before adding the new backend as alternative. Best regards Heinrich Patch#1 to #4 are preparatory so that we won't rely on U-Boot environment, that is, env_get/set() helper functions. Patch#5 to #8 are core part of changes. Patch#9 to #11 are for modifying variable attributes. Changes in v2 (Apr 24, 2019) * rebased on efi-2019-07 * revamp the implementation v1 (Nov 28, 2018) * initial AKASHI Takahiro (11): lib: charset: add u16_strcmp() lib: charset: add u16_strncmp() cmd: efidebug: rework "boot dump" sub-command using GetNextVariableName() efi_loader: set OsIndicationsSupported at init env: save UEFI non-volatile variables in dedicated storage efi_loader: variable: support non-volatile attribute efi_loader: variable: split UEFI variables from U-Boot environment efi_loader: load saved non-volatile variables at init efi_loader: bootmgr: handle BootNext as non-volatile cmd: env: add -nv option for UEFI non-volatile variable cmd: efidebug: make some boot variables non-volatile cmd/bootefi.c | 4 - cmd/efidebug.c| 95 +++- cmd/nvedit.c | 3 +- cmd/nvedit_efi.c | 15 ++- env/Kconfig | 34 ++ env/env.c | 98 - env/fat.c | 109 +++ include/asm-generic/global_data.h | 1 + include/charset.h | 10 ++
Re: [U-Boot] [PATCH 1/2] eeprom: fix DM_I2C support with CONFIG_SYS_I2C_EEPROM_BUS
On 4/24/19 7:48 PM, Simon Goldschmidt wrote:
> This fixes eeprom for DM_I2C in u-boot-socfpga/master
> commit 3c43ab903d33 ("eeprom: fix DM_I2C support without
> CONFIG_SYS_I2C_EEPROM_BUS")
> which only fixed it without CONFIG_SYS_I2C_EEPROM_BUS defined.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Please amend to commit 3c43ab903d33 in u-boot-socfpga/master
> ---
> cmd/eeprom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/eeprom.c b/cmd/eeprom.c
> index 9e44960c7d..7b1f81477f 100644
> --- a/cmd/eeprom.c
> +++ b/cmd/eeprom.c
> @@ -168,7 +168,7 @@ static int eeprom_rw(unsigned dev_addr, unsigned offset,
> uchar *buffer,
> uchar addr[3];
>
> #if defined(CONFIG_SYS_I2C_EEPROM_BUS)
> - i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS);
> + eeprom_init(CONFIG_SYS_I2C_EEPROM_BUS);
> #endif
>
> while (offset < end) {
>
Squashed both, thanks.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] AE350 support SMP boot from flash
Hi Rick, On Wed, 2019-04-24 at 09:35 +0800, Rick Chen wrote: > Hi Lukas > > Auer, Lukas 於 2019年4月24日 週三 上午3:58寫道： > > Hi Rick, > > > > On Tue, 2019-04-23 at 13:42 +0800, Andes wrote: > > > From: Rick Chen > > > > > > In current RISC-V SMP flow, AE350 will encounter the the write > > > failure problem since hart_lottery and available_harts_lock was > > > not in ram address but in flash address when booing from flash. > > > > > > This patch can help to fix the failure problem when AE350 was > > > booting from flash by disable this two features. > > > > > > > Can you describe the issue you are seeing a bit more. The write > > failures are both to variables in the .data section, which should be > > writable. Perhaps the write failures can be avoided by moving the .data > > section or just the variable to RAM? > > > > When I compile AE350's CONFIG_SYS_TEXT_BASE=0x8000 which is spi flash > base. > And burn u-boot.bin into AE350 spi flash. Power off / on, U-Boot will > run in XIP mode. > At this time prior_stage_fdt_address will be in flash address(0x8004e9e8) > So it is not writable. > > 8042: 16021563bneztp,81ac > > 8046: 0004f297auipc t0,0x4f > 804a: 9a22a283lw t0,-1630(t0) # > 8004e9e8 > 804e: 0092a023sw s1,0(t0) > Ok, that makes sense. Another option would be to move the variable to RAM or some other location, which is write-accessible when U-Boot starts. Would this work? I think it would be good to support the hart lottery and the available harts mask in all configurations. Thanks, Lukas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] efi_loader: set OsIndicationsSupported at init
From: AKASHI Takahiro
UEFI variables should be installed using well-defined API.
Currently we don't support much, but the value of OsIndicationsSupported
will be updated once some features are added in the future.
Signed-off-by: AKASHI Takahiro
Add comments. Rename a variable.
Reviewed-by: Heinrich Schuchardt
---
Applied to efi-2019-07 branch.
---
cmd/bootefi.c | 4
lib/efi_loader/efi_setup.c | 11 +++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index efaa548be4..b93d8c6a32 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -303,10 +303,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle)
if (ret != EFI_SUCCESS)
return ret;
- /* we don't support much: */
-
env_set("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
- "{ro,boot}(blob)");
-
/* Call our payload! */
ret = EFI_CALL(efi_start_image(handle, NULL, NULL));
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index b32a7b3f93..87db51cbb7 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -79,6 +79,7 @@ out:
*/
efi_status_t efi_init_obj_list(void)
{
+ u64 os_indications_supported = 0; /* None */
efi_status_t ret = EFI_SUCCESS;
/* Initialize once only */
@@ -90,6 +91,16 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
+ /* Indicate supported features */
+ ret = EFI_CALL(efi_set_variable(L"OsIndicationsSupported",
+ _global_variable_guid,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ sizeof(os_indications_supported),
+ _indications_supported));
+ if (ret != EFI_SUCCESS)
+ goto out;
+
/* Initialize system table */
ret = efi_initialize_system_table();
if (ret != EFI_SUCCESS)
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/11] cmd: efidebug: rework "boot dump" sub-command using GetNextVariableName()
On 4/24/19 8:30 AM, AKASHI Takahiro wrote:
Efidebug command should be implemented using well-defined EFI interfaces,
rather than using internal functions/data. This change will be needed in
a later patch where UEFI variables are re-implemented.
I had trouble to get the point. In the next version I suggest to write:
Currently in do_efi_boot_dump() we directly read EFI variables from the
related environment variables. To accomodate alternative storage
backends we should switch to using the UEFI API instead.
Signed-off-by: AKASHI Takahiro
---
cmd/efidebug.c | 92 --
1 file changed, 66 insertions(+), 26 deletions(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index a40c4f4be286..8890dd7268f1 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -509,7 +509,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
if (argc < 6 || argc > 7)
return CMD_RET_USAGE;
- id = (int)simple_strtoul(argv[1], , 16);
+ id = simple_strtoul(argv[1], , 16);
This change is correct but unrelated. Please, put it into a separate
patch. Or at least mention it in the commit message.
if (*endp != '\0' || id > 0x)
return CMD_RET_USAGE;
@@ -595,7 +595,7 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
guid = efi_global_variable_guid;
for (i = 1; i < argc; i++, argv++) {
- id = (int)simple_strtoul(argv[1], , 16);
+ id = simple_strtoul(argv[1], , 16);
Same here.
if (*endp != '\0' || id > 0x)
return CMD_RET_FAILURE;
@@ -693,6 +693,27 @@ static void show_efi_boot_opt(int id)
free(data);
}
+static bool u16_isxdigit(u16 c)
+{
+ if (c & 0xff00)
+ return false;
+
+ return isxdigit((u8)c);
+}
+
+static int u16_tohex(u16 c)
+{
+ if (c >= '0' && c < '9')
+ return c - '0';
+ if (c >= 'A' && c < 'F')
+ return c - 'A' + 10;
+ if (c >= 'a' && c < 'f')
+ return c - 'a' + 10;
Does the UEFI spec really allow lower case hexadecimal numbers here?
I only found an example with capital numbers. Would this imply that I
could have variables Boot00a0 and Boot00A0 side by side? Which one would
be selected by boot option 00a0?
Or should SetVariable() make a case insensitive search for variable names?
In EDK2 function FindVariableEx() in
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
uses CompareMem() to compare variable names.
Function BmCharToUint() is used to check the digits of boot options and
has this comment:
"It assumes the input Char is in the scope of L'0' ~ L'9'
and L'A' ~ L'F'"
So let's us assume that variable names are case sensitive and Boot
entries can only have capital hexadecimal digits.
So u16_isxdigit() is incorrect.
+
+ /* dummy */
+ return -1;
As we do not check bounds here the function could be reduced to:
return c > '9' ? c - ('A' - 0xa) : c - '9';
But I would prefer one library function instead of the two static
functions which returns -1 for a non-digit and 0 - 15 for a digit.
And a unit test in test/unicoode_ut.c
+}
+
/**
* show_efi_boot_dump() - dump all UEFI load options
*
@@ -709,38 +730,57 @@ static void show_efi_boot_opt(int id)
static int do_efi_boot_dump(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
{
- char regex[256];
- char * const regexlist[] = {regex};
- char *variables = NULL, *boot, *value;
- int len;
- int id;
+ u16 *var_name16, *p;
+ efi_uintn_t buf_size, size;
+ efi_guid_t guid;
+ int id, i;
+ efi_status_t ret;
if (argc > 1)
return CMD_RET_USAGE;
- snprintf(regex, 256, "efi_.*-.*-.*-.*-.*_Boot[0-9A-F]+");
-
- /* TODO: use GetNextVariableName? */
- len = hexport_r(_htab, '\n', H_MATCH_REGEX | H_MATCH_KEY,
- , 0, 1, regexlist);
+ buf_size = 128;
+ var_name16 = malloc(buf_size);
+ if (!var_name16)
+ return CMD_RET_FAILURE;
- if (!len)
- return CMD_RET_SUCCESS;
+ var_name16[0] = 0;
+ for (;;) {
+ size = buf_size;
+ ret = EFI_CALL(efi_get_next_variable_name(, var_name16,
+ ));
+ if (ret == EFI_NOT_FOUND)
+ break;
+ if (ret == EFI_BUFFER_TOO_SMALL) {
+ buf_size = size;
+ p = realloc(var_name16, buf_size);
+ if (!p) {
+ free(var_name16);
+ return CMD_RET_FAILURE;
+ }
+ var_name16 = p;
+ ret = EFI_CALL(efi_get_next_variable_name(,
+ var_name16,
+
[U-Boot] evb-rk3328_defconfig: dtc: option requires an argument
Hello, I am building u-boot master as the following make evb-rk3328_defconfig make all make u-boot.itb What I see it the following error: LD u-boot OBJCOPY u-boot-nodtb.bin start=$(aarch64-suse-linux-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-suse-linux-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x0020 $start $end MKIMAGE u-boot.itb dtc: option requires an argument -- 'p' Usage: dtc [options] Options: -[qI:O:o:V:d:R:S:p:a:fb:i:H:sW:E:@Ahv] -q, --quiet [skipped] -v, --version Print version and exit Error: unknown option ./tools/mkimage: Can't open 0x0.tmp: No such file or directory make[1]: *** [/usr/src/u-boot/Makefile:1247: u-boot.itb] Error 255 My dtc version is 1.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
Am 18.04.2019 um 23:08 schrieb Julius Werner:
This patch adds support for compressing non-kernel image nodes in a FIT
image (kernel nodes could already be compressed previously). This can
reduce the size of FIT images and therefore improve boot times
(especially when an image bundles many different kernel FDTs). The
images will automatically be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
Just to note it in this thread, too: this is somewhat similar to what I
suggested in this RFC last year:
https://patchwork.ozlabs.org/patch/984996/
So I tested this and it doesn't really seem to work for me.
Somehow, the Kernel loaded from my FIT image doesn't start, but I'm not
convinced that's related to this patch.
However, compared to my above mentioned RFC patch, this here somehow
fails when loading something from the image, e.g. using the cmd 'fpga
loadmk'. Seems like this one doesn't transparently uncompress?
Regards,
Simon
---
common/image-fit.c | 83 +++---
1 file changed, 49 insertions(+), 34 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131c..006e828b79 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -22,6 +22,7 @@
DECLARE_GLOBAL_DATA_PTR;
#endif /* !USE_HOSTCC*/
+#include
#include
#include
#include
@@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void
*fdt)
kfdt_name);
continue;
}
+
+ if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
+ debug("Can't extract compat from \"%s\" (compressed)\n",
+ kfdt_name);
+ continue;
+ }
+
/*
* Get a pointer to this configuration's fdt.
*/
@@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
const char *fit_uname_config;
const char *fit_base_uname_config;
const void *fit;
- const void *buf;
+ void *buf;
+ void *loadbuf;
size_t size;
int type_ok, os_ok;
- ulong load, data, len;
- uint8_t os;
+ ulong load, load_end, data, len;
+ uint8_t os, comp;
#ifndef USE_HOSTCC
uint8_t os_arch;
#endif
@@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
images->os.arch = os_arch;
#endif
- if (image_type == IH_TYPE_FLATDT &&
- !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
- puts("FDT image is compressed");
- return -EPROTONOSUPPORT;
- }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
type_ok = fit_image_check_type(fit, noffset, image_type) ||
fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
@@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
/* get image data address and length */
- if (fit_image_get_data_and_size(fit, noffset, , )) {
+ if (fit_image_get_data_and_size(fit, noffset,
+ (const void **), )) {
printf("Could not find %s subimage data!\n", prop_name);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
return -ENOENT;
@@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
#if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/* perform any post-processing on the image data */
- board_fit_image_post_process((void **), );
+ board_fit_image_post_process(, );
#endif
len = (ulong)size;
- /* verify that image data is a proper FDT blob */
- if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
- puts("Subimage data is not a FDT");
- return -ENOEXEC;
- }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
- /*
-* Work-around for eldk-4.2 which gives this warning if we try to
-* cast in the unmap_sysmem() call:
-* warning: initialization discards qualifiers from pointer target type
-*/
- {
- void *vbuf = (void *)buf;
-
- data = map_to_sysmem(vbuf);
- }
-
+ data = map_to_sysmem(buf);
+ load = data;
if (load_op == FIT_LOAD_IGNORED) {
/* Don't load */
} else if (fit_image_get_load(fit, noffset, )) {
@@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
} else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) {
[U-Boot] [PATCH] firmware: ti_sci: Fix TISCI mailbox receive timeout handling
An earlier commit converted the TISCI receive timeouts to be specified
in ms rather than us however it failed to take this change into account
when passing the actual timeout to be used when invoking the mailbox
receive API. This leads to the actual timeout to be 1,000 times shorter
than expected and as a result certain TISCI operations would fail.
Fix the issue by converting the timeout declared in ms to us on the fly
as expected by the respective API.
Fixes: fd6b40b1ba20 ("firmware: ti_sci: Add support for NAVSS resource
management")
Signed-off-by: Andreas Dannenberg
---
Found this issue through bisecting the u-boot tree while maintaining my
yet-to-be-submitted-upstream system firmware loader series current, which
would cause SYSFW PM init to time out and the AM654x board to constantly
reset. The TI "ti-u-boot-2019.01" tree has this change already built-in
(it appears like when "firmware: ti_sci: Add support for NAVSS resource
management" was originally submitted upstream this change was missed).
Regards, Andreas
drivers/firmware/ti_sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index d47d22fff3..d72dd73f3b 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -158,7 +158,7 @@ static inline int ti_sci_get_response(struct ti_sci_info
*info,
int ret;
/* Receive the response */
- ret = mbox_recv(chan, msg, info->desc->max_rx_timeout_ms);
+ ret = mbox_recv(chan, msg, info->desc->max_rx_timeout_ms * 1000);
if (ret) {
dev_err(info->dev, "%s: Message receive failed. ret = %d\n",
__func__, ret);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test/py: pytest.mark.notbuildconfigspec()
On 4/22/19 1:44 AM, Heinrich Schuchardt wrote: We already can let a Python test depend on a build option being set via @pytest.mark.buildconfigspec(). It may be necessary to let a test depend on a build option *not* being set. So let's introduce @pytest.mark.notbuildconfigspec for this purpose. Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/11] lib: charset: add u16_strncmp()
On 4/24/19 8:30 AM, AKASHI Takahiro wrote: u16_strncmp() works like u16_strcmp() but only at most n characters (in u16) are compared. This function will be used in a later patch. Signed-off-by: AKASHI Takahiro The only usage of u16_strncmp() is in patch 3. u16_strcmp() is not used at all. In patch 3 'memcmp(var_name16, L"BOOT", 8)' will do the job. I am not sure if in other cases we wouldn't prefer to compare Unicode codepoints instead of u16. So I suggest to skip patches 1 and 2 and use memcmp() in patch 3. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] Migrating iMX LCDIF drivers to Driver Model
Hi Igor, On Tue, Apr 16, 2019 at 8:28 PM Peng Fan wrote: > > 2) Will it be OK if I introduce a brand new mxsfb driver (ported from > > Linux), > > which will be used only when U-boot is built with CONFIG_DM_VIDEO > > enabled? Existing mxsfb will be left as it is, so I can be removed easily > > when > > full migration to DM is done for all boards that are using this driver. Sounds like a good plan. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot Security
Am 24.04.2019 um 15:55 schrieb Linder Pascal: Hello everyone, I want to add some supplementary security to my embedded system. The Flattened Image Tree (FIT) to secure the operating system and the device tree, I have already found. Now, I am wondering if I could also secure U-Boot itself before starting it by the Secondary Program Loader (SPL). Does anyone knows a method to do that? Just as U-Boot can load Kernel + DTS as FIT, SPL can load U-Boot as FIT. See CONFIG_SPL_LOAD_FIT. This FIT containing U-Boot + its DTS can then be verified, too. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] eeprom: fix DM_I2C support without CONFIG_SYS_I2C_EEPROM_BUS
Am 23.04.2019 um 21:18 schrieb Simon Goldschmidt:
The current device model enabled eeprom code only works if
CONFIG_SYS_I2C_EEPROM_BUS is set.
This patch makes it work without that define so that the bus
number passed to 'eeprom_init' is used.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Heiko Schocher
Please ignore this version, I've sent a diff for this fix instead.
Regards,
Simon
---
Changes in v3:
- use eeprom_init() to set CONFIG_SYS_I2C_EEPROM_BUS, not
i2c_set_bus_num to make things work with CONFIG_DM_I2C
Changes in v2: None
cmd/eeprom.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/cmd/eeprom.c b/cmd/eeprom.c
index 6c29b33ba3..7b1f81477f 100644
--- a/cmd/eeprom.c
+++ b/cmd/eeprom.c
@@ -59,6 +59,10 @@
#endif
#endif
+#if defined(CONFIG_DM_I2C)
+int eeprom_i2c_bus;
+#endif
+
__weak int eeprom_write_enable(unsigned dev_addr, int state)
{
return 0;
@@ -67,7 +71,9 @@ __weak int eeprom_write_enable(unsigned dev_addr, int state)
void eeprom_init(int bus)
{
/* I2C EEPROM */
-#if defined(CONFIG_SYS_I2C)
+#if defined(CONFIG_DM_I2C)
+ eeprom_i2c_bus = bus;
+#elif defined(CONFIG_SYS_I2C)
if (bus >= 0)
i2c_set_bus_num(bus);
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
@@ -124,14 +130,14 @@ static int eeprom_rw_block(unsigned offset, uchar *addr,
unsigned alen,
{
int ret = 0;
-#if defined(CONFIG_DM_I2C) && defined(CONFIG_SYS_I2C_EEPROM_BUS)
+#if defined(CONFIG_DM_I2C)
struct udevice *dev;
- ret = i2c_get_chip_for_busnum(CONFIG_SYS_I2C_EEPROM_BUS, addr[0],
+ ret = i2c_get_chip_for_busnum(eeprom_i2c_bus, addr[0],
alen - 1, );
if (ret) {
printf("%s: Cannot find udev for a bus %d\n", __func__,
- CONFIG_SYS_I2C_EEPROM_BUS);
+ eeprom_i2c_bus);
return CMD_RET_FAILURE;
}
@@ -141,15 +147,12 @@ static int eeprom_rw_block(unsigned offset, uchar *addr, unsigned alen,
ret = dm_i2c_write(dev, offset, buffer, len);
#else /* Non DM I2C support - will be removed */
-#if defined(CONFIG_SYS_I2C_EEPROM_BUS)
- i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS);
-#endif
if (read)
ret = i2c_read(addr[0], offset, alen - 1, buffer, len);
else
ret = i2c_write(addr[0], offset, alen - 1, buffer, len);
-#endif /* CONFIG_DM_I2C && CONFIG_SYS_I2C_EEPROM_BUS */
+#endif /* CONFIG_DM_I2C */
if (ret)
ret = CMD_RET_FAILURE;
@@ -164,6 +167,10 @@ static int eeprom_rw(unsigned dev_addr, unsigned offset, uchar *buffer,
int rcode = 0;
uchar addr[3];
+#if defined(CONFIG_SYS_I2C_EEPROM_BUS)
+ eeprom_init(CONFIG_SYS_I2C_EEPROM_BUS);
+#endif
+
while (offset < end) {
alen = eeprom_addr(dev_addr, offset, addr);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: socfpga: fix compiling vining_fpga with DM_I2C
commit 6ce1f2d2ce4d ("arm: socfpga: move vining_fpga to DM_I2C") in
u-boot-socfpga/master fails to compile as vining has non-DM compatibility
for I2C disabled.
Signed-off-by: Simon Goldschmidt
---
Please amend to commit 6ce1f2d2ce4d in u-boot-socfpga/master
---
board/samtec/vining_fpga/socfpga.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/board/samtec/vining_fpga/socfpga.c
b/board/samtec/vining_fpga/socfpga.c
index d99aac6828..efc8ddf162 100644
--- a/board/samtec/vining_fpga/socfpga.c
+++ b/board/samtec/vining_fpga/socfpga.c
@@ -52,14 +52,7 @@ int misc_init_r(void)
u32 serial;
int ret;
- /* EEPROM is at bus 0. */
- ret = i2c_set_bus_num(0);
- if (ret) {
- puts("Cannot select EEPROM I2C bus.\n");
- return 0;
- }
-
- /* EEPROM is at address 0x50. */
+ /* EEPROM is at address 0x50 (at bus CONFIG_SYS_EEPROM_BUS_NUM). */
ret = eeprom_read(0x50, 0, data, sizeof(data));
if (ret) {
puts("Cannot read I2C EEPROM.\n");
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] eeprom: fix DM_I2C support with CONFIG_SYS_I2C_EEPROM_BUS
This fixes eeprom for DM_I2C in u-boot-socfpga/master
commit 3c43ab903d33 ("eeprom: fix DM_I2C support without
CONFIG_SYS_I2C_EEPROM_BUS")
which only fixed it without CONFIG_SYS_I2C_EEPROM_BUS defined.
Signed-off-by: Simon Goldschmidt
---
Please amend to commit 3c43ab903d33 in u-boot-socfpga/master
---
cmd/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/eeprom.c b/cmd/eeprom.c
index 9e44960c7d..7b1f81477f 100644
--- a/cmd/eeprom.c
+++ b/cmd/eeprom.c
@@ -168,7 +168,7 @@ static int eeprom_rw(unsigned dev_addr, unsigned offset,
uchar *buffer,
uchar addr[3];
#if defined(CONFIG_SYS_I2C_EEPROM_BUS)
- i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS);
+ eeprom_init(CONFIG_SYS_I2C_EEPROM_BUS);
#endif
while (offset < end) {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] arm: socfpga: clean up socfpga_common.h
On 4/24/19 7:36 PM, Simon Goldschmidt wrote: > Am 23.04.2019 um 23:24 schrieb Marek Vasut: >> On 4/23/19 10:51 PM, Simon Goldschmidt wrote: >>> >>> >>> Marek Vasut mailto:ma...@denx.de>> schrieb am Di., 23. >>> Apr. 2019, 22:43: >>> >>> On 4/23/19 9:36 PM, Simon Goldschmidt wrote: >>> > This series cleans up the include/configs/socfpga_common.h >>> file a bit. >>> > >>> > It removes some defines that are used nowhere and cleans up some >>> > leftovers after various subsystems have been converted to use DM. >>> > >>> > Changes in v4: >>> > - fix DM_I2C case: don't call i2c_set_bus_num() since this is >>> > done in cmd/eeprom already >>> > >>> > Changes in v3: >>> > - changed commit message: s/defines/macros and comments/ >>> > >>> > Changes in v2: >>> > - added (this) patch to move socfpga_vining to DM_I2C >>> > - remove even more outdated things >>> > - added (this) patch with further cleanups to the socfpga >>> board config >>> > files >>> > >>> > Simon Goldschmidt (4): >>> > arm: socfpga: move vining_fpga to DM_I2C >>> > arm: socfpga: clean up socfpga_common.h >>> > arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ >>> > arm: socfpga: clean up board config files >>> > >>> > board/samtec/vining_fpga/socfpga.c | 9 +--- >>> > configs/socfpga_vining_fpga_defconfig | 8 ++- >>> > include/configs/socfpga_arria10_socdk.h | 6 --- >>> > include/configs/socfpga_arria5_socdk.h | 2 - >>> > include/configs/socfpga_common.h | 68 >>> >>> > include/configs/socfpga_cyclone5_socdk.h | 2 - >>> > include/configs/socfpga_de0_nano_soc.h | 2 - >>> > include/configs/socfpga_de10_nano.h | 2 - >>> > include/configs/socfpga_de1_soc.h | 2 - >>> > include/configs/socfpga_is1.h | 2 - >>> > include/configs/socfpga_sockit.h | 2 - >>> > include/configs/socfpga_socrates.h | 2 - >>> > include/configs/socfpga_sr1500.h | 11 >>> > include/configs/socfpga_vining_fpga.h | 18 --- >>> > 14 files changed, 8 insertions(+), 128 deletions(-) >>> >>> Neither of these apply to u-boot-socfpga/master :-( >>> >>> >>> Sorry for the confusion, these are again meant to apply on top of other >>> patches in a PR. Sent to the ML for reference, mainly, as the diffs are >>> tiny. >>> >>> How should I mark such patches to prevent such misunderstandings in the >>> future? >> >> Just send an incremental patch on top of u-boot-socfpga/master please . >> If you want me to squash it into another patch, note it somewhere around >> the diffstat. >> > > OK, in this case, drop this v4. Cool, thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/11] lib: charset: add u16_strncmp()
On 4/24/19 8:30 AM, AKASHI Takahiro wrote:
u16_strncmp() works like u16_strcmp() but only at most n characters
(in u16) are compared.
This function will be used in a later patch.
Signed-off-by: AKASHI Takahiro
---
include/charset.h | 5 +
lib/charset.c | 13 +
2 files changed, 18 insertions(+)
diff --git a/include/charset.h b/include/charset.h
index 747a9b376c03..49842a88bc8b 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -171,6 +171,11 @@ s32 utf_to_upper(const s32 code);
*/
int u16_strcmp(const u16 *s1, const u16 *s2);
+/*
+ * u16_strncmp() - strncmp() for u16 strings
* u16_strncmp() - compare two u16 string
*
* @s1: first string to compare
* @s2: second string to compare
* @n1: maximum number of u16 to compare
* Return: 0 if the first n u16 are the same in s1 and s2
* < 0 if the first different u16 in s1 is less than the
* corresponding u16 in s2
* > 0 if the first different u16 in s1 is greater than the
* corresponding u16 in s2
+ */
+int u16_strncmp(const u16 *s1, const u16 *s2, size_t n);
+
/**
* u16_strlen - count non-zero words
*
diff --git a/lib/charset.c b/lib/charset.c
index 4a25ac0bdb9c..85f08db68fe2 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -345,6 +345,19 @@ int u16_strcmp(const u16 *s1, const u16 *s2)
return (*(uint16_t *)s1 - *(uint16_t *)s2);
}
+int u16_strncmp(const u16 *s1, const u16 *s2, size_t n)
+{
+ while ((n-- > 0) && (*s1 == *s2++)) {
+ if (*s1++ == 0)
+ return 0;
+ if (!n)
+ return 0;
+ }
+ --s2;
For u16_strncmp() called with n = 0 I would prefer to see 0 as return
value instead of the result of an illegal memory access.
+
+ return (*(uint16_t *)s1 - *(uint16_t *)s2);
No need for a conversion here.
Let's avoid the superfluous increment/decrement, provide 0 for n = 0,
and make sure that the compiler calculates the difference only once per
loop:
int u16_strncmp(const u16 *s1, const u16 *s2, size_t n)
{
int ret = 0;
for (; n; --n, ++s1, ++s2) {
ret = *s1 - *s2;
if (ret || !*s1)
break;
}
return ret;
}
I would like to see a unit test in test/unicode_ut.c.
The test should include the n = 0 case.
Best regards
Heinrich
+}
+
size_t u16_strlen(const u16 *in)
{
size_t i;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] arm: socfpga: clean up socfpga_common.h
Am 23.04.2019 um 23:24 schrieb Marek Vasut: On 4/23/19 10:51 PM, Simon Goldschmidt wrote: Marek Vasut mailto:ma...@denx.de>> schrieb am Di., 23. Apr. 2019, 22:43: On 4/23/19 9:36 PM, Simon Goldschmidt wrote: > This series cleans up the include/configs/socfpga_common.h file a bit. > > It removes some defines that are used nowhere and cleans up some > leftovers after various subsystems have been converted to use DM. > > Changes in v4: > - fix DM_I2C case: don't call i2c_set_bus_num() since this is > done in cmd/eeprom already > > Changes in v3: > - changed commit message: s/defines/macros and comments/ > > Changes in v2: > - added (this) patch to move socfpga_vining to DM_I2C > - remove even more outdated things > - added (this) patch with further cleanups to the socfpga board config > files > > Simon Goldschmidt (4): > arm: socfpga: move vining_fpga to DM_I2C > arm: socfpga: clean up socfpga_common.h > arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ > arm: socfpga: clean up board config files > > board/samtec/vining_fpga/socfpga.c | 9 +--- > configs/socfpga_vining_fpga_defconfig | 8 ++- > include/configs/socfpga_arria10_socdk.h | 6 --- > include/configs/socfpga_arria5_socdk.h | 2 - > include/configs/socfpga_common.h | 68 > include/configs/socfpga_cyclone5_socdk.h | 2 - > include/configs/socfpga_de0_nano_soc.h | 2 - > include/configs/socfpga_de10_nano.h | 2 - > include/configs/socfpga_de1_soc.h | 2 - > include/configs/socfpga_is1.h | 2 - > include/configs/socfpga_sockit.h | 2 - > include/configs/socfpga_socrates.h | 2 - > include/configs/socfpga_sr1500.h | 11 > include/configs/socfpga_vining_fpga.h | 18 --- > 14 files changed, 8 insertions(+), 128 deletions(-) Neither of these apply to u-boot-socfpga/master :-( Sorry for the confusion, these are again meant to apply on top of other patches in a PR. Sent to the ML for reference, mainly, as the diffs are tiny. How should I mark such patches to prevent such misunderstandings in the future? Just send an incremental patch on top of u-boot-socfpga/master please . If you want me to squash it into another patch, note it somewhere around the diffstat. OK, in this case, drop this v4. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 2/2] power: regulator: support ROHM BD71837 PMIC
Hi Matti,
On Tue, 23 Apr 2019 at 23:59, Vaittinen, Matti
wrote:
>
> Hello Simon,
>
> Thanks a bunch for taking the time and reviewing this! I do appreciate!
>
> On Tue, 2019-04-23 at 21:54 -0600, Simon Glass wrote:
> > Hi Matti,
> >
> > On Wed, 27 Mar 2019 at 06:40, Matti Vaittinen
> > wrote:
> > >
> > > Add regulator driver for ROHM BD71837 PMIC. BD71837 contains
> > > 8 bucks and 7 LDOS. Voltages for bucks 1-4 can be adjusted
> > > when regulators are enabled. For other bucks and LDOs we may
> > > have over- or undershooting if voltage is adjusted when
> > > regulator is enabled. Thus this is prevented by default.
> > >
> > > BD71837 has a quirk which may leave power output disabled
> > > after reset if enable/disable state was controlled by SW.
> > > Thus the SW control is only allowed for bucks3 and 4 by
> > > default.
> > >
> > > Signed-off-by: Matti Vaittinen
> > > ---
> > > drivers/power/regulator/Kconfig | 15 ++
> > > drivers/power/regulator/Makefile | 1 +
> > > drivers/power/regulator/bd71837.c | 373
> > > ++
> > > include/power/bd71837.h | 20 ++
> > > 4 files changed, 409 insertions(+)
> > >
> >
> > Reviewed-by: Simon Glass
> >
> > But please see nits below.
>
> I see you reviewed the RFC version. I would like to ask you to see also
> the non RFC version https://patchwork.ozlabs.org/patch/1080860/ which
> supports also BD71847. I see that most (maybe all) of these comments
> apply to that patch too - but you might have some additional ideas
> too.
>
> I will create v2 of this non RFC patch based on these comments (and fix
> your comments to patch 1/2 too) but I won't add your reviewed-by just
> yet - I hope you can also check the pieces adding BD71847 support and
> give me a nudge if you see there something to improve. =)
>
> > > --- /dev/null
> > > +++ b/drivers/power/regulator/bd71837.c
> > > @@ -0,0 +1,373 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +//
> > > +// Copyright (C) 2019 ROHM Semiconductors
> > > +//
> > > +// ROHM BD71837 regulator driver
> >
> > The SPDX line has a // comment but everything else should use C
> > comments:
> >
> > /*
> > * Copyright ...
> > *
> > * ROHM ...
> > */
>
> This is fine for me. But just to note that this differs from Linux
> notation which accepts also the copyright block being // - comments. I
> am not sure how closely u-Boot follows (or wants to follow) kernel
> coding guidelines. But as I said, I don't mind changing this.
U-Boot mostly follows Linux, but you can see conventions by looking at
the code, generally.
>
> > > +
> > > +static int bd71837_regulator_probe(struct udevice *dev)
> > > +{
> > > + struct bd71837_data *d = dev_get_platdata(dev);
> > > + int i, ret;
> > > + struct dm_regulator_uclass_platdata *uc_pdata;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(bd71837_reg_data); i++) {
> > > + if (!strcmp(dev->name, bd71837_reg_data[i].name)) {
> > > + *d = bd71837_reg_data[i];
> > > + if (d->enablemask != HW_STATE_CONTROL) {
> > > + u8 ctrl;
> > > +
> > > + /* Take the regulator under SW
> > > control. Ensure
> > > +* the initial state matches dt
> > > flags and then
> > > +* write the SEL bit
> > > +*/
> > > + uc_pdata =
> > > dev_get_uclass_platdata(dev);
> > > + ret = bd71837_set_enable(dev,
> > > +!!(uc_pdat
> > > a->boot_on ||
> > > +uc_pdata-
> > > >always_on));
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ctrl = pmic_reg_read(dev->parent,
> > > +d-
> > > >enable_reg);
> > > + if (ctrl < 0)
> > > + return ctrl;
> > > +
> > > + ctrl |= d->sel_mask;
> > > + return pmic_reg_write(dev->parent,
> > > + d-
> > > >enable_reg, ctrl);
> > > + }
> > > + return 0;
> > > + }
> > > + }
> > > +
> > > + pr_err("Unknown regulator '%s'\n", dev->name);
> > > +
> > > + return -EINVAL;
> >
> > -ENOENT ?
>
> At first the -ENOENT sounded to me like a regulator/device is missing.
> I thought that here we have extra (invalid/unknown) regulator in the
> device-tree. Thus I used the -EINVAL. But I think you are right, we can
> think that DT is correct and the driver lacks of correct regulator
> entity. So -ENOENT can be appropriate. => I'll change this too.
>
> > > --
> > > Matti
Re: [U-Boot] [PATCH 2/2] fsl_qspi: Improve QSPI driver to incorporate 4 byte commands
On 24-Apr-19 6:10 PM, Rajat Srivastava wrote:
> Signed-off-by: Ashish Kumar
> Signed-off-by: Rajat Srivastava
Commit message is missing. But from $patch subject, I infer that $patch
is adding new feature and not actually fixing something broken?
If so, you should move the driver over to use spi-mem APIs instead of
adding more features and hard coding more flash specific commands in the
driver. This makes driver duplicate more of spi-nor core code. I
discourage adding new features w/o moving driver over to spi-mem. IMHO,
converting the driver would not be a huge effort. And I believe its
already done in kernel.
Regards
Vignesh
> ---
> drivers/spi/fsl_qspi.c | 38 +-
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index 1598c4f698..1d26c6344b 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
> #define TX_BUFFER_SIZE 0x40
> #endif
>
> -#define OFFSET_BITS_MASK GENMASK(23, 0)
> +#define OFFSET_BITS_MASK GENMASK(27, 0)
>
> #define FLASH_STATUS_WEL 0x02
>
> @@ -754,7 +754,8 @@ static void qspi_op_erase(struct fsl_qspi_priv *priv)
> while (qspi_read32(priv->flags, >sr) & QSPI_SR_BUSY_MASK)
> ;
>
> - if (priv->cur_seqid == QSPI_CMD_SE) {
> + if ((priv->cur_seqid == QSPI_CMD_SE_4B) ||
> + (priv->cur_seqid == QSPI_CMD_SE)) {
> qspi_write32(priv->flags, >ipcr,
>(SEQID_SE << QSPI_IPCR_SEQID_SHIFT) | 0);
> } else if (priv->cur_seqid == QSPI_CMD_BE_4K) {
> @@ -775,31 +776,40 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int
> bitlen,
> u32 txbuf;
>
> WATCHDOG_RESET();
> -
> if (dout) {
> if (flags & SPI_XFER_BEGIN) {
> priv->cur_seqid = *(u8 *)dout;
> - memcpy(, dout, 4);
> + if (FSL_QSPI_FLASH_SIZE > SZ_16M && bytes > 4)
> + memcpy(, dout + 1, 4);
> + else
> + memcpy(, dout, 4);
> }
>
> if (flags == SPI_XFER_END) {
> priv->sf_addr = wr_sfaddr;
> - qspi_op_write(priv, (u8 *)dout, bytes);
> - return 0;
> + if (priv->cur_seqid == QSPI_CMD_PP ||
> + priv->cur_seqid == QSPI_CMD_PP_4B ||
> + priv->cur_seqid == QSPI_CMD_WRAR) {
> + qspi_op_write(priv, (u8 *)dout, bytes);
> + return 0;
> + }
> }
>
> - if (priv->cur_seqid == QSPI_CMD_FAST_READ ||
> - priv->cur_seqid == QSPI_CMD_RDAR) {
> + if ((priv->cur_seqid == QSPI_CMD_FAST_READ) ||
> + (priv->cur_seqid == QSPI_CMD_FAST_READ_4B) ||
> + (priv->cur_seqid == QSPI_CMD_RDAR)) {
> priv->sf_addr = swab32(txbuf) & OFFSET_BITS_MASK;
> } else if ((priv->cur_seqid == QSPI_CMD_SE) ||
> -(priv->cur_seqid == QSPI_CMD_BE_4K)) {
> +priv->cur_seqid == QSPI_CMD_SE_4B ||
> +priv->cur_seqid == QSPI_CMD_BE_4K) {
> priv->sf_addr = swab32(txbuf) & OFFSET_BITS_MASK;
> qspi_op_erase(priv);
> } else if (priv->cur_seqid == QSPI_CMD_PP ||
> +priv->cur_seqid == QSPI_CMD_PP_4B ||
> priv->cur_seqid == QSPI_CMD_WRAR) {
> wr_sfaddr = swab32(txbuf) & OFFSET_BITS_MASK;
> } else if ((priv->cur_seqid == QSPI_CMD_BRWR) ||
> - (priv->cur_seqid == QSPI_CMD_WREAR)) {
> +(priv->cur_seqid == QSPI_CMD_WREAR)) {
> #ifdef CONFIG_SPI_FLASH_BAR
> wr_sfaddr = 0;
> #endif
> @@ -807,7 +817,8 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int
> bitlen,
> }
>
> if (din) {
> - if (priv->cur_seqid == QSPI_CMD_FAST_READ) {
> + if ((priv->cur_seqid == QSPI_CMD_FAST_READ) ||
> + (priv->cur_seqid == QSPI_CMD_FAST_READ_4B)) {
> #ifdef CONFIG_SYS_FSL_QSPI_AHB
> qspi_ahb_read(priv, din, bytes);
> #else
> @@ -815,10 +826,11 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int
> bitlen,
> #endif
> } else if (priv->cur_seqid == QSPI_CMD_RDAR) {
> qspi_op_read(priv, din, bytes);
> - } else if (priv->cur_seqid == QSPI_CMD_RDID)
> + } else if (priv->cur_seqid == QSPI_CMD_RDID) {
> qspi_op_rdid(priv, din, bytes);
> - else if (priv->cur_seqid == QSPI_CMD_RDSR)
> + } else if (priv->cur_seqid == QSPI_CMD_RDSR) {
>
Re: [U-Boot] [PATCH 1/2] drivers/mtd/spi: Enable 4B opcodes for SPANSION s25fl512s
Hi.
On 24-Apr-19 6:10 PM, Rajat Srivastava wrote:
> From: Ashish Kumar
>
> Signed-off-by: Ashish Kumar
> ---
> drivers/mtd/spi/spi-nor-ids.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index ec929760ee..a89c1910d9 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -177,7 +177,7 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("s25sl064p", 0x010216, 0x4d00, 64 * 1024, 128,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, USE_CLSR) },
> { INFO("s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> - { INFO6("s25fl512s", 0x010220, 0x4d0081, 256 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
> + { INFO6("s25fl512s", 0x010220, 0x4d0081, 256 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR | SPI_NOR_4B_OPCODES) },
You should not be needing this change to enable 4 Byte opcodes. From
spi-nor-core.c:
if (nor->addr_width) {
/* already configured from SFDP */
} else if (info->addr_width) {
nor->addr_width = info->addr_width;
} else if (mtd->size > SZ_16M) {
#ifndef CONFIG_SPI_FLASH_BAR
/* enable 4-byte addressing if the device exceeds 16MiB */
nor->addr_width = 4;
if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
info->flags & SPI_NOR_4B_OPCODES)
spi_nor_set_4byte_opcodes(nor, info);
#else
/* Configure the BAR - discover bank cmds and read current bank */
nor->addr_width = 3;
ret = read_bar(nor, info);
if (ret < 0)
return ret;
#endif
}
[...]
So as long as SPI_FLASH_BAR is not set, 4 Byte opcodes are used by
default with Spansion flashes >16M size. If that's not the case, then we
need to root cause the actual bug instead of adding SPI_NOR_4B_OPCODES
to s25fl512s
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] lib: charset: add u16_strcmp()
On 4/24/19 8:30 AM, AKASHI Takahiro wrote:
u16 version of strcmp()
AUTHER: Patrick Wildt
%s/AUTHER/Author/
Signed-off-by: AKASHI Takahiro
---
include/charset.h | 5 +
lib/charset.c | 10 ++
2 files changed, 15 insertions(+)
diff --git a/include/charset.h b/include/charset.h
index 65087f76d1fc..747a9b376c03 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -166,6 +166,11 @@ s32 utf_to_lower(const s32 code);
*/
s32 utf_to_upper(const s32 code);
+/*
+ * u16_strcmp() - strcmp() for u16 strings
+ */
+int u16_strcmp(const u16 *s1, const u16 *s2);
+
/**
* u16_strlen - count non-zero words
*
diff --git a/lib/charset.c b/lib/charset.c
index 5e349ed5ee45..4a25ac0bdb9c 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -335,6 +335,16 @@ s32 utf_to_upper(const s32 code)
return ret;
}
+int u16_strcmp(const u16 *s1, const u16 *s2)
+{
+ while (*s1 == *s2++)
+ if (*s1++ == 0)
+ return (0);
+ --s2;
for (;*s1 == *s2; ++s1, ++s2)
if (!s1)
return 0;
does the same job without superfluous increment/decrement.
+
+ return (*(uint16_t *)s1 - *(uint16_t *)s2);
Why would you use both u16 and uint16_t in the same function?
You can do without any conversion here.
How about
#define u16_strcmp(s1, s2) u16_strncmp(s1, s2, SIZE_MAX)
like we do for the other string functions?
Best regards
Heinrich
+}
+
size_t u16_strlen(const u16 *in)
{
size_t i;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, Build/test: https://travis-ci.org/sglass68/u-boot/builds/523770406 The following changes since commit 6c5f8dd540d7a8eff244d4c27a09451ca12c8d20: Merge branch 'master' of git://git.denx.de/u-boot-usb (2019-04-21 19:00:04 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/pull-24apr19 for you to fetch changes up to 8781d04f422e110fef864dd849085054fe5b0e65: pci: pci.h: add missing maskbit (2019-04-23 20:26:43 -0600) Various minor sandbox iumprovements Fixes for tracing with sandbox Refactoring for boot_get_fdt() Christoph Muellner (1): common: command: Add command execution tracer. Eugeniu Rosca (5): fdt: boot_get_fdt: remove redundant zeroing out fdt: boot_get_fdt: really boot w/o FDT when "goto no_fdt" fdt: boot_get_fdt: simplify no_fdt handling (non-functional) fdt: boot_get_fdt: android: compress handling (non-functional) fdt: boot_get_fdt: android: use ENV 'fdtaddr' as fallback Lukas Auer (1): simple-bus: add DM_FLAG_PRE_RELOC flag to simple-bus driver Ramon Fried (1): pci: pci.h: add missing maskbit Simon Glass (13): sandbox: Improve debugging in initcall_run_list() sandbox: Correct maths in allocation routines sandbox: Drop the printf() in setup_ram_buf() sandbox: Move pre-console buffer out of the way of tracing bootstage: Allow calling bootstage_mark() before bootstage_init() sandbox: Increase the early-trace-buffer size initcall: Drop use of header files div64: Use kernel types div64: Don't instrument the division function trace: Tidy up error returns Convert CONFIG_TRACE to Kconfig Convert CONFIG_TRACE_BUFFER_SIZE et al to Kconfig sandbox: Enable the 'trace' command when tracing is used Stefan Roese (1): dm: core: Change platform specific translation-offset handling Thierry Reding (1): fdtdec: Use fdt_setprop_u32() for fdtdec_set_phandle() arch/arm/mach-mvebu/Kconfig| 1 + arch/arm/mach-mvebu/spl.c | 12 +++--- arch/sandbox/cpu/os.c | 59 + arch/sandbox/cpu/start.c | 16 +- arch/sandbox/include/asm/global_data.h | 1 + board/sandbox/README.sandbox | 46 +++ cmd/Kconfig| 13 ++- common/board_f.c | 2 +- common/bootstage.c | 7 ++ common/command.c | 14 common/image-fdt.c | 33 ++-- configs/sandbox_defconfig | 2 +- drivers/core/Kconfig | 9 drivers/core/fdtaddr.c | 9 +--- drivers/core/root.c| 21 -- drivers/core/simple-bus.c | 1 + include/asm-generic/global_data.h | 4 include/configs/sandbox.h | 4 ++-- include/div64.h| 70 +-- include/dm/fdtaddr.h | 21 -- include/fdtdec.h | 5 - include/initcall.h | 19 +--- include/os.h | 11 ++ include/pci.h | 1 + lib/Kconfig| 57 lib/div64.c| 20 +++-- lib/fdtdec.c | 7 -- lib/trace.c| 17 ++- scripts/config_whitelist.txt | 5 - 29 files changed, 335 insertions(+), 152 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arch: mips: Update initrd_start and initrd_end
Microsemi SoC defines CONFIG_SYS_SDRAM_BASE to be 0x8000, which
represents the start of kseg0 and represents a virtual address. Meaning
that the initrd_start and initrd_end point somewhere kseg0.
When these parameters are passed to linux kernel through DT
they are pointing somewhere in kseg0 which is a virtual address but linux
kernel expects the addresses to be physical addresses(in kuseg) because
it is converting the physical address to a virtual one.
Therefore update the uboot to pass the physical address of initrd_start
and initrd_end by converting them using the function virt_to_phys before
setting up the DT.
Signed-off-by: Horatiu Vultur
---
arch/mips/lib/bootm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 35152cb..6a462f3 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -247,6 +247,8 @@ int arch_fixup_fdt(void *blob)
static int boot_setup_fdt(bootm_headers_t *images)
{
+ images->initrd_start = virt_to_phys((void *)images->initrd_start);
+ images->initrd_end = virt_to_phys((void *)images->initrd_end);
return image_setup_libfdt(images, images->ft_addr, images->ft_len,
>lmb);
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Refactor IMAGE_ENABLE_VERIFY to handle builds without SPL verification
On Thu, 18 Apr 2019 at 14:35, Alex Kiernan wrote: > > If building with SPL_LOAD_FIT_FULL and FIT_SIGNATURE, but without > SPL_FIT_SIGNATURE then the build fails with: > > common/built-in.o: In function `fit_image_verify_with_data': > common/image-fit.c:1220: undefined reference to > `fit_image_verify_required_sigs' > common/image-fit.c:1244: undefined reference to `fit_image_check_sig' > common/built-in.o: In function `fit_image_load': > common/image-fit.c:1857: undefined reference to `fit_config_verify' > > Refactor so that host builds still depend on FIT_SIGNATURE, but target > builds check FIT_SIGNATURE/SPL_FIT_SIGNATURE 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(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] common: fdt_support: Check mtdparts cell size
On Tue, 23 Apr 2019 at 23:32, Stefan Mavrodiev wrote: > > When using fdt_fixup_mtdparts() offset and length cell sizes > are limited to 4 bytes (1 cell). However if the mtd device is > bigger then 4GiB, then #address-cells and #size-cells are > 8 bytes (2 cells) [1]. > > This patch read #size-cells and uses either fdt32_t or > fdt64_t cell size. The default is fdt32_t. > > [1] Documentation/devicetree/bindings/mtd/partition.txt > > Signed-off-by: Stefan Mavrodiev > --- > Changes for v2: > - Use fdt_setprop_u64() and ..._u32() instead of fdt_setprop() > - Add size value using fdt_appendprop_u64() and ..._u32() > > common/fdt_support.c | 31 ++- > 1 file changed, 22 insertions(+), 9 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] lib: fdt: Allow LZO and GZIP DT compression in U-Boot
On Tue, 9 Apr 2019 at 10:09, Marek Vasut wrote: > > Add required Kconfig symbols, Makefile bits and macro fixes in a > few places to support LZO and DT compression in U-Boot. This can > save a lot of space with multi-DTB fitImages. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Simon Glass > Cc: Tom Rini > --- > V2: - Rebase on u-boot/master > - Do not apply FINAL_DTB_CONTAINER to u-boot-dtb.bin target > --- > Makefile | 16 ++- > dts/Kconfig | 57 +++ > include/config_defaults.h | 3 --- > lib/Kconfig | 13 + > lib/fdtdec.c | 2 +- > 5 files changed, 86 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] lib: fdt: Allow enabling both LZO and GZIP DT compression
On Tue, 9 Apr 2019 at 10:09, Marek Vasut wrote: > > Allow enabling both LZO and GZIP DT compression in SPL and fix a > bug where if the GZIP decompression failed, the LZO decompression > would not even be attempted. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Simon Glass > Cc: Tom Rini > --- > V2: Rebase on u-boot/master > --- > lib/fdtdec.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] pci: pci.h: add missing maskbit
On Sun, 21 Apr 2019 at 20:57, Simon Glass wrote: > > On Fri, 5 Apr 2019 at 19:12, Ramon Fried wrote: > > > > PCI_MSI_FLAGS_MASKBIT was missing from include file, > > add it. > > > > Signed-off-by: Ramon Fried > > --- > > > > include/pci.h | 1 + > > 1 file changed, 1 insertion(+) > > Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4] arm: socfpga: mailbox: Fix off-by-one error on command length checking
On 4/24/19 7:21 AM, Ley Foon Tan wrote: > A mailbox command contains 1-u32 header + arguments. The "len" variable > only contains the length of the arguments, but not the 1-u32 header. > Include the length of header when checking the ring buffer space to > prevent off-by-one error. > > Signed-off-by: Ley Foon Tan > Signed-off-by: Chee Hong Ang > --- > v3->v4: > - Change DWORD to u32 in commit message > - Add note len is in u32 unit in code > > v2->v3: > - Update commit description. > --- > arch/arm/mach-socfpga/mailbox_s10.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c > b/arch/arm/mach-socfpga/mailbox_s10.c > index 3c33223936..4498ab55df 100644 > --- a/arch/arm/mach-socfpga/mailbox_s10.c > +++ b/arch/arm/mach-socfpga/mailbox_s10.c > @@ -55,11 +55,11 @@ static __always_inline int > mbox_fill_cmd_circular_buff(u32 header, u32 len, > cout = MBOX_READL(MBOX_COUT) % MBOX_CMD_BUFFER_SIZE; > > /* if command buffer is full or not enough free space > - * to fit the data > + * to fit the data. Note, len is in u32 unit. >*/ > if (((cin + 1) % MBOX_CMD_BUFFER_SIZE) == cout || > ((MBOX_CMD_BUFFER_SIZE - cin + cout - 1) % > - MBOX_CMD_BUFFER_SIZE) < len) > + MBOX_CMD_BUFFER_SIZE) < (len + 1)) > return -ENOMEM; > > /* write header to circular buffer */ > Applied, thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: Move Stratix 10 SDRAM driver to DM
On 4/24/19 8:21 AM, Ley Foon Tan wrote:
> Convert Stratix 10 SDRAM driver to device model.
>
> Get rid of call to socfpga_per_reset() and use reset
> framework.
>
> SPL is changed from calling function in SDRAM driver
> directly to just probing UCLASS_RAM.
>
> Move sdram_s10.h from arch to driver/ddr/altera directory.
>
> Signed-off-by: Ley Foon Tan
> ---
> v1->v2:
> - Change sdr device tree node enabled by default.
> - Probe UCLASS_RAM only if CONFIG_ALTERA_SDRAM is enabled.
> ---
> arch/arm/dts/socfpga_stratix10.dtsi | 9 +
> arch/arm/mach-socfpga/spl_s10.c | 11 +-
> configs/socfpga_stratix10_defconfig | 1 +
> drivers/ddr/altera/Kconfig| 6 +-
> drivers/ddr/altera/sdram_s10.c| 246 --
> .../mach => drivers/ddr/altera}/sdram_s10.h | 4 -
> include/configs/socfpga_stratix10_socdk.h | 5 -
> 7 files changed, 192 insertions(+), 90 deletions(-)
> rename {arch/arm/mach-socfpga/include/mach =>
> drivers/ddr/altera}/sdram_s10.h (97%)
>
> diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> b/arch/arm/dts/socfpga_stratix10.dtsi
> index d1ae2fabae..bd68a78a37 100755
> --- a/arch/arm/dts/socfpga_stratix10.dtsi
> +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> @@ -258,6 +258,15 @@
> u-boot,dm-pre-reloc;
> };
>
> + sdr: sdr@f8000400 {
> + compatible = "altr,sdr-ctl-s10";
> + reg = <0xf8000400 0x80>,
> +<0xf801 0x190>,
> +<0xf8011000 0x500>;
> + resets = < DDRSCH_RESET>;
> + u-boot,dm-pre-reloc;
> + };
> +
> spi0: spi@ffda4000 {
> compatible = "snps,dw-apb-ssi";
> #address-cells = <1>;
Separate patch please
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
> index a141ffe82a..3d44eabf91 100644
> --- a/arch/arm/mach-socfpga/spl_s10.c
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -15,9 +15,9 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -119,6 +119,7 @@ void board_init_f(ulong dummy)
> {
> const struct cm_config *cm_default_cfg = cm_get_default_config();
> int ret;
> + struct udevice *dev;
>
> #ifdef CONFIG_HW_WATCHDOG
> /* Ensure watchdog is paused when debugging is happening */
> @@ -175,11 +176,13 @@ void board_init_f(ulong dummy)
> clrbits_le32(CCU_REG_ADDR(CCU_IOM_MPRT_ADMASK_MEM_RAM0),
>CCU_ADMASK_P_MASK | CCU_ADMASK_NS_MASK);
>
> - debug("DDR: Initializing Hard Memory Controller\n");
> - if (sdram_mmr_init_full(0)) {
> - puts("DDR: Initialization failed.\n");
> +#ifdef CONFIG_ALTERA_SDRAM
#if CONFIG_IS_ENABLED(ALTERA_SDRAM) (really, altera sdram ? How will
this work with other SDRAM controllers in the FPGA ? I thought that was
already discussed too)
> + ret = uclass_get_device(UCLASS_RAM, 0, );
> + if (ret) {
> + debug("DRAM init failed: %d\n", ret);
> hang();
> }
> +#endif /* CONFIG_ALTERA_SDRAM */
>
> mbox_init();
>
> diff --git a/configs/socfpga_stratix10_defconfig
> b/configs/socfpga_stratix10_defconfig
> index 4848013b21..bda6ab6637 100644
> --- a/configs/socfpga_stratix10_defconfig
> +++ b/configs/socfpga_stratix10_defconfig
> @@ -32,6 +32,7 @@ CONFIG_ENV_IS_IN_MMC=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_SPL_DM=y
> CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_ALTERA_SDRAM=y
> CONFIG_DM_GPIO=y
> CONFIG_DWAPB_GPIO=y
> CONFIG_DM_I2C=y
> diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig
> index 8f60b56eb8..112c4ad7c3 100644
> --- a/drivers/ddr/altera/Kconfig
> +++ b/drivers/ddr/altera/Kconfig
> @@ -1,7 +1,7 @@
> config ALTERA_SDRAM
> bool "SoCFPGA DDR SDRAM driver"
> - depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
> - select RAM if TARGET_SOCFPGA_GEN5
> - select SPL_RAM if TARGET_SOCFPGA_GEN5
> + depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 ||
> TARGET_SOCFPGA_STRATIX10
> + select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> + select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10
> help
> Enable DDR SDRAM controller for the SoCFPGA devices.
> diff --git a/drivers/ddr/altera/sdram_s10.c b/drivers/ddr/altera/sdram_s10.c
> index e4d4a02ca2..d2f3272609 100644
> --- a/drivers/ddr/altera/sdram_s10.c
> +++ b/drivers/ddr/altera/sdram_s10.c
> @@ -5,17 +5,32 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> -#include
> +#include
> +#include
> +#include "sdram_s10.h"
> #include
> #include
> -#include
> #include
> #include
> +#include
> #include
>
> +#ifdef CONFIG_SPL_BUILD
Is this ifdef really needed ?
> +struct altera_sdram_priv {
> + struct
Re: [U-Boot] tbs2910 not buildable
On 23.04.19 01:19, Tom Rini wrote: > On Sun, Apr 14, 2019 at 12:46:25PM +0200, Soeren Moch wrote: >> Hi Stefano, >> >> On 14.04.19 11:52, stefano babic wrote: >>> Hallo Soeren, >>> >>> after pulling from Tom and merging u-boot-imx, - next, your board is not >>> buildable anymore. Better: it is buildable, but size exceeds: >>> >>>arm: + tbs2910 >>> +u-boot.imx exceeds file size limit: >>> + limit: 392192 bytes >>> + actual: 396288 bytes >>> + excess: 4096 bytes >>> >>> Just dropping CONFIG_EFI_PARTITION (I supposed EFI is not used on this >>> board), solves the issue. I can do myself in this way or let me know >>> what is your preferred way. >>> >> Hm, the full name of this board is "TBS2910 Matrix ARM mini PC", so it >> is supposed to provide a full PC environment. It supports booting from >> SATA, and such disk may as well be partitioned with EFI. It is really >> terrible to drop user visible features, just to support a new "driver >> model" that is supposed to ease life for developers, but in fact is much >> work and a real pain for maintainers of existing boards, and brings >> exactly nothing for the board's users. >> >> So much for that. Now to your question. >> >> Would be OK for me to drop CONFIG_EFI_PARTITION for now since it is more >> important to get this series merged, because other boards also depend on >> the SATA patches. We can readd EFI_PARTITION support later. For sure >> there will be more patches in this development cycle. >> But if you can wait a few hours, I will look for a better solution, or >> send a formal patch for this CONFIG_EFI_PARTITION removal. > Now that I'm back from vacation, I do want to chime in here. So, yes, > this presents a difficult challenge. I don't want to encourage people > to take out functionality just to make the binary fit. And I assume the > binary size limit is so that we don't overwrite something else, so we > can't just grow it either. So what options do we have? Taking out > CONFIG_DM_WARN and CONFIG_MMC_VERBOSE gives us about 2KB. Changing the > loglevel from 4 to 3 saves another 2KB. Dropping the memtest command > (which is not helpful and discouraged) gives another 1KB. > > But these are also, well, stopgaps. Is it all going to be worth it? > Well, I hope so. We can for example gain another 1KB back by disabling > block cache, which does improve read speed from filesystems and thus > something end users see. But it could have been written without DM, > it's just a new feature and "carrot" to move to DM. > > I don't even see any obvious-to-me cases of including big hunks of data > that should be dropped, so that brings us to maybe-not-used > functionality like bootelf/bootvx/nfs and so on. Which I don't like. > > So, I'm trying to keep a harder still eye on size growth when pulling in > functionality. And I kinda wish LTO was easier to bring in as that > might really save us some space. > Thanks, Tom, for your additional suggestions. Disabling CMD_FDT in tbs2910_defconfig did the trick for this round, see [1]. Regards, Soeren [1] http://git.denx.de/?p=u-boot.git;a=commit;h=e0627f77f55ea8d606cd4b0902bc47ffaad220d0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: kirkwood: openrd: Increase U-Boot size in flash to make it fit
On 24.04.19 16:13, Tom Rini wrote: On Wed, Apr 24, 2019 at 03:49:35PM +0200, Stefan Roese wrote: On 24.04.19 15:21, Tom Rini wrote: On Sat, Apr 13, 2019 at 09:00:48AM -0400, Tom Rini wrote: On Fri, Apr 12, 2019 at 07:08:40PM +1200, Chris Packham wrote: On Thu, 11 Apr 2019, 10:33 PM Stefan Roese, wrote: We have run now multiple times into size issues with the openrd board port. To finally fix this, this patch now moves the U-Boot size >from 0x6. to 0x8., giving enough space for the next time. This also changes the environment location and potentially the MTD partitioning, but I see no better fix for now. Especially since this board does not have an active maintainer. Signed-off-by: Stefan Roese Cc: Chris Packham One alternative option I looked at was trimming down the dtb to drop the nodes that aren't used in u-boot. This might just get it under the 0x6 limit ... for a while. I agree that this is the best approach in leiu of anyone maintiaining the board. Once this is applied the openrd boards can be reenabled in travis. Reviewed-by: Chris Packham Please note the board is currently orphaned and excluded from travis builds due to the size problem. So if someone is going to address this, I want to see the board un-orphaned too (and travis updated to build it again), thanks! Anyone? Thanks! I can add myself as maintainer and add it back to the travis builds. Even though I can only compile test because I don't have access to this board. OK. Make sure to include updating the travis rules when you update the MAINTAINERS file, thanks! Yep. I'll send a patch for this once I've pushed this patch here to mainline, which should happen shortly. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: kirkwood: openrd: Increase U-Boot size in flash to make it fit
On Wed, Apr 24, 2019 at 03:49:35PM +0200, Stefan Roese wrote: > On 24.04.19 15:21, Tom Rini wrote: > >On Sat, Apr 13, 2019 at 09:00:48AM -0400, Tom Rini wrote: > >>On Fri, Apr 12, 2019 at 07:08:40PM +1200, Chris Packham wrote: > >>>On Thu, 11 Apr 2019, 10:33 PM Stefan Roese, wrote: > >>> > We have run now multiple times into size issues with the openrd > board port. To finally fix this, this patch now moves the U-Boot size > from 0x6. to 0x8., giving enough space for the next time. > > This also changes the environment location and potentially the > MTD partitioning, but I see no better fix for now. Especially since > this board does not have an active maintainer. > > Signed-off-by: Stefan Roese > Cc: Chris Packham > >>> > >>> > >>>One alternative option I looked at was trimming down the dtb to drop the > >>>nodes that aren't used in u-boot. This might just get it under the 0x6 > >>>limit ... for a while. > >>> > >>>I agree that this is the best approach in leiu of anyone maintiaining the > >>>board. Once this is applied the openrd boards can be reenabled in travis. > >>> > >>>Reviewed-by: Chris Packham > >> > >>Please note the board is currently orphaned and excluded from travis > >>builds due to the size problem. So if someone is going to address this, > >>I want to see the board un-orphaned too (and travis updated to build it > >>again), thanks! > > > >Anyone? Thanks! > > I can add myself as maintainer and add it back to the travis builds. > Even though I can only compile test because I don't have access to > this board. OK. Make sure to include updating the travis rules when you update the MAINTAINERS file, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] U-Boot Security
Hello everyone, I want to add some supplementary security to my embedded system. The Flattened Image Tree (FIT) to secure the operating system and the device tree, I have already found. Now, I am wondering if I could also secure U-Boot itself before starting it by the Secondary Program Loader (SPL). Does anyone knows a method to do that? For a helpful answer I would be really grateful. Sincerely, Pascal Linder Student Telekommunikation Netzwerke und Sicherheit Klasse T-3b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 2/4] reset: add reset driver for HiSilicon platform
On Wed, Mar 20, 2019 at 03:32:39PM +0800, Shawn Guo wrote: > It adds a Driver Model compatible reset driver for HiSlicon platform. > The driver implements a custom .of_xlate function, and uses .data field > as reset register offset and .id field as bit shift. > > Signed-off-by: Shawn Guo > Acked-by: Joe Hershberger 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] [U-Boot,V2,4/8] bcm968580xref: enable led support
On Fri, Mar 22, 2019 at 05:02:04PM +0100, Philippe Reynes wrote: > Enable the led support in the configuration > of the board bcm968580xref. > > Signed-off-by: Philippe Reynes 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 3/3] arm: kirkwood: openrd: Increase U-Boot size in flash to make it fit
On 24.04.19 15:21, Tom Rini wrote: On Sat, Apr 13, 2019 at 09:00:48AM -0400, Tom Rini wrote: On Fri, Apr 12, 2019 at 07:08:40PM +1200, Chris Packham wrote: On Thu, 11 Apr 2019, 10:33 PM Stefan Roese, wrote: We have run now multiple times into size issues with the openrd board port. To finally fix this, this patch now moves the U-Boot size from 0x6. to 0x8., giving enough space for the next time. This also changes the environment location and potentially the MTD partitioning, but I see no better fix for now. Especially since this board does not have an active maintainer. Signed-off-by: Stefan Roese Cc: Chris Packham One alternative option I looked at was trimming down the dtb to drop the nodes that aren't used in u-boot. This might just get it under the 0x6 limit ... for a while. I agree that this is the best approach in leiu of anyone maintiaining the board. Once this is applied the openrd boards can be reenabled in travis. Reviewed-by: Chris Packham Please note the board is currently orphaned and excluded from travis builds due to the size problem. So if someone is going to address this, I want to see the board un-orphaned too (and travis updated to build it again), thanks! Anyone? Thanks! I can add myself as maintainer and add it back to the travis builds. Even though I can only compile test because I don't have access to this board. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,6/7] pinctrl: add driver for MT8516
On Sun, Mar 24, 2019 at 04:46:37PM +0100, Fabien Parent wrote: > Add Pinctrl driver for MediaTek MT8516 SoC. > > Signed-off-by: Fabien Parent > Acked-by: Ryder Lee 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] [U-Boot,v3,2/7] mmc: mtk-sd: add support for MT8516
On Sun, Mar 24, 2019 at 04:46:33PM +0100, Fabien Parent wrote: > Add config for handling MT8516 SoC. > > Signed-off-by: Fabien Parent > Acked-by: Ryder Lee 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] [U-Boot, 09/18] drivers: nand: brcmnand: add an option to read the write-protect from device tree
On Fri, Mar 15, 2019 at 03:14:38PM +0100, Philippe Reynes wrote: > The option write-protect may only change on the kernel command line, > we add a property in the device tree to be more flexible. > > Signed-off-by: Philippe Reynes 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] [U-Boot, v3, 7/7] ARM: MediaTek: Add support for MT8516 SoC
On Sun, Mar 24, 2019 at 04:46:38PM +0100, Fabien Parent wrote: > Add support for MediaTek MT8516 SoC. This include the file > that will initialize the SoC after boot and its device tree. > > Signed-off-by: Fabien Parent > Reviewed-by: Tom Rini 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] [U-Boot, v4, 2/2] dlmalloc: be compatible to tiny printf
On Mon, Apr 01, 2019 at 10:01:50PM +0200, Simon Goldschmidt wrote: > Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny > printf used in SPL. > > 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] bootm: Simplying cache flush code
On Wed, Mar 27, 2019 at 11:50:09PM +, Trent Piepho wrote: > The cache flush of the kernel load area needs to be aligned outward to > the DMA cache alignment. The operations are simpler if we think of this > as aligning the start down, ALIGN_DOWN(load, ARCH_DMA_MINALIGN), and > aligning the end up, ALIGN(load_end, ARCH_DMA_MINALIGN), and then find > the length of the flushed region by subtracting the former from the > latter. > > Cc: Tom Rini > Cc: Simon Glass > Cc: Bryan O'Donoghue > Signed-off-by: Trent Piepho > Reviewed-by: Simon Glass 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] [U-Boot,15/18] bcm968580xref: add nand support
On Fri, Mar 15, 2019 at 03:14:44PM +0100, Philippe Reynes wrote: > Enable the nand support (driver and command) > in the configuration of the board bcm968580xref. > > Signed-off-by: Philippe Reynes 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] ARM: da850evm: Remove legacy MMC code
On Fri, Mar 15, 2019 at 02:29:20PM -0500, Adam Ford wrote: > With the migration to DM in SPL and the DT support, the > old legacy code is no longer neaded, so this patch removes it > > Signed-off-by: Adam Ford > > diff --git a/board/davinci/da8xxevm/da850evm.c > b/board/davinci/da8xxevm/da850evm.c > index e8ec553f99..1bc26828bf 100644 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] [U-Boot,v2,2/2] image: android: fix 'iminfo' typo
On Mon, Apr 08, 2019 at 05:35:28PM +0200, Eugeniu Rosca wrote:
> Fix below CP warning triggered by the 'iminfo' output in another patch:
> WARNING: 'addrress' may be misspelled - perhaps 'address'?
>
> Fixes: 4f1318b29c7a20 ("common: image: minimal android image iminfo support")
> Signed-off-by: Eugeniu Rosca
> Acked-by: Marek Vasut
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] [U-Boot, V2, 5/8] led: bcm6858: allow to use this driver on ARCH_963158
On Fri, Mar 22, 2019 at 05:02:05PM +0100, Philippe Reynes wrote: > Allow the led bcm6858 driver to be used on bcm63158. > They have the same led controller. > > Signed-off-by: Philippe Reynes 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] [U-Boot,V2,6/8] dt: bcm63158: add led controller
On Fri, Mar 22, 2019 at 05:02:06PM +0100, Philippe Reynes wrote: > Add the led controller in the bcm63158 device tree. > > Signed-off-by: Philippe Reynes 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] [U-Boot, RESEND] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
On Thu, Apr 04, 2019 at 02:38:50PM +0200, Lars Povlsen wrote: > This fixes relaction isses with the PSCI_TABLE entries in > the psci_32_table and psci_64_table. > > When using 32-bit adress pointers relocation was not being applied to > the tables, causing PSCI handlers to point to the un-relocated code > area. By using 64-bit data relocation is properly applied. The > handlers are thus in the "secure data" area, which is protected by > /memreserve/ in the FDT. > > Signed-off-by: Lars Povlsen 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] [U-Boot,V2,8/8] bcm963158: enable led support
On Fri, Mar 22, 2019 at 05:02:08PM +0100, Philippe Reynes wrote: > Enable the led support in the configuration > of the board bcm963158. > > Signed-off-by: Philippe Reynes 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] [U-Boot, V2, 3/8] dt: bcm968580xref: enable led controller
On Fri, Mar 22, 2019 at 05:02:03PM +0100, Philippe Reynes wrote: > Enable the led controller in the device tree > of the board bcm968580xref. > > Signed-off-by: Philippe Reynes 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] [U-Boot, 06/18] compat linux: import completion from linux 4.18
On Fri, Mar 15, 2019 at 03:14:35PM +0100, Philippe Reynes wrote: > This patch port the file include/linux/completion.h > from linux 4.18 to u-boot. It define the structure > but all the function are stubbed. > > Signed-off-by: Philippe Reynes 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] [U-Boot, 1/1] test: env: Enable env unit tests by default
On Sun, Apr 07, 2019 at 05:57:40PM +0200, Heinrich Schuchardt wrote: > If CONFIG_UNIT_TEST is enabled we should enable the individual tests by > default to ensure good test coverage. > > Signed-off-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] [U-Boot,v3,5/7] clk: mediatek: add driver for MT8516
On Sun, Mar 24, 2019 at 04:46:36PM +0100, Fabien Parent wrote: > Add clock driver for MediaTek MT8516 SoC. > > Signed-off-by: Fabien Parent > Acked-by: Ryder Lee 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] [U-Boot, v3, 1/7] mmc: mtk-sd: add source_cg clock support
On Sun, Mar 24, 2019 at 04:46:32PM +0100, Fabien Parent wrote: > Some MediaTek SoC need an additional clock "source_cg". Enable > this new clock. We reuse the same clock name as in the kernel. > > Signed-off-by: Fabien Parent > Acked-by: Ryder Lee 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] [U-Boot,V2,7/8] dt: bcm963158: enable led controller
On Fri, Mar 22, 2019 at 05:02:07PM +0100, Philippe Reynes wrote: > Enable the led controller in the device tree > of the board bcm963158. > > Signed-off-by: Philippe Reynes 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] [U-Boot, v2, 1/2] image: android: allow booting lz4-compressed kernels
On Mon, Apr 08, 2019 at 05:35:27PM +0200, Eugeniu Rosca wrote: > According to Android image format [1], kernel image resides at 1 page > offset from the boot image address. Grab the magic number from there > and allow U-Boot to handle LZ4-compressed KNL binaries instead of > hardcoding compression type to IH_COMP_NONE. Other compression types, > if needed, can be added later. > > Tested on H3ULCB-KF using the image detailed in [2]. > > [1] Excerpt from include/android_image.h > +-+ > | boot header | 1 page > +-+ > | kernel | n pages > +-+ > | ramdisk | m pages > +-+ > | second stage| o pages > +-+ > > [2] => iminfo 4c00 > ## Checking Image at 4c00 ... > Android image found > kernel size: 85b9d1 > kernel address: 4808 > ramdisk size: 54ddbc > ramdisk addrress: 4a18 > second size: 0 > second address: 48000800 > tags address: 48000100 > page size:800 > os_version: 1200012a (ver: 0.9.0, level: 2018.10) > name: > cmdline: buildvariant=userdebug > > Signed-off-by: Eugeniu Rosca 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
