Re: [U-Boot] [PATCH] i2c: at91: Add missing probe function to device driver
Hello Wenyou,
Am 31.07.2017 um 03:56 schrieb Wenyou Yang:
Add missing probe function to the device driver to active a device.
Signed-off-by: Wenyou Yang
---
drivers/i2c/at91_i2c.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index b7298cf774..d394044f80 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -199,7 +199,7 @@ static int at91_i2c_enable_clk(struct udevice *dev)
return 0;
}
-static int at91_i2c_probe(struct udevice *dev, uint chip, uint chip_flags)
+static int at91_i2c_probe_chip(struct udevice *dev, uint chip, uint chip_flags)
{
struct at91_i2c_bus *bus = dev_get_priv(dev);
struct at91_i2c_regs *reg = bus->regs;
@@ -254,11 +254,32 @@ static int at91_i2c_ofdata_to_platdata(struct udevice
*dev)
static const struct dm_i2c_ops at91_i2c_ops = {
.xfer = at91_i2c_xfer,
- .probe_chip = at91_i2c_probe,
+ .probe_chip = at91_i2c_probe_chip,
.set_bus_speed = at91_i2c_set_bus_speed,
.get_bus_speed = at91_i2c_get_bus_speed,
};
+static int at91_i2c_probe(struct udevice *dev)
+{
+ struct at91_i2c_bus *bus = dev_get_priv(dev);
+ struct at91_i2c_regs *reg = bus->regs;
+ int ret;
+
+ ret = at91_i2c_enable_clk(dev);
+ if (ret)
+ return ret;
+
+ writel(TWI_CR_SWRST, ®->cr);
+
+ at91_calc_i2c_clock(dev, bus->clock_frequency);
+
+ writel(bus->cwgr_val, ®->cwgr);
+ writel(TWI_CR_MSEN, ®->cr);
+ writel(TWI_CR_SVDIS, ®->cr);
+
+ return 0;
+}
+
static const struct at91_i2c_pdata at91rm9200_config = {
.clk_max_div = 5,
.clk_offset = 3,
@@ -315,6 +336,7 @@ U_BOOT_DRIVER(i2c_at91) = {
.name = "i2c_at91",
.id = UCLASS_I2C,
.of_match = at91_i2c_ids,
+ .probe = at91_i2c_probe,
.ofdata_to_platdata = at91_i2c_ofdata_to_platdata,
.per_child_auto_alloc_size = sizeof(struct dm_i2c_chip),
.priv_auto_alloc_size = sizeof(struct at91_i2c_bus),
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] configs: socfpga: Add config for RBF loading from FAT fs
On Isn, 2017-07-31 at 12:54 +0200, Marek Vasut wrote: > On 07/31/2017 12:50 PM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > This config enable the mechanism for loading RBF file from FAT fs > > into > > FPGA manager. > > > > Signed-off-by: Tien Fong Chee > > --- > > arch/arm/mach-socfpga/Kconfig |7 +++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach- > > socfpga/Kconfig > > index 45e5379..3fbac20 100644 > > --- a/arch/arm/mach-socfpga/Kconfig > > +++ b/arch/arm/mach-socfpga/Kconfig > > @@ -33,6 +33,13 @@ config > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE > > config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE > > default 0xa2 > > > > +config RBF_SDMMC_FAT_SUPPORT > NAK, Xilinx already has some support for loading FPGA from FS, so > improve on that. > I can change to CONFIG_CMD_FPGA_LOADFS. > > > > + bool "Support FPGA program with FAT RBF" > > + default y if SPL_FAT_SUPPORT > > + help > > + Enable support for programming FPGA with RAW > > binary file > > + (periph rbf + core rbf) loading from FAT > > partition. > > + > > config TARGET_SOCFPGA_ARRIA5 > > bool > > select TARGET_SOCFPGA_GEN5 > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] configs: socfpga: Add config for RBF loading from FAT fs
On 08/07/2017 09:18 AM, Chee, Tien Fong wrote: > On Isn, 2017-07-31 at 12:54 +0200, Marek Vasut wrote: >> On 07/31/2017 12:50 PM, tien.fong.c...@intel.com wrote: >>> >>> From: Tien Fong Chee >>> >>> This config enable the mechanism for loading RBF file from FAT fs >>> into >>> FPGA manager. >>> >>> Signed-off-by: Tien Fong Chee >>> --- >>> arch/arm/mach-socfpga/Kconfig |7 +++ >>> 1 files changed, 7 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach- >>> socfpga/Kconfig >>> index 45e5379..3fbac20 100644 >>> --- a/arch/arm/mach-socfpga/Kconfig >>> +++ b/arch/arm/mach-socfpga/Kconfig >>> @@ -33,6 +33,13 @@ config >>> SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE >>> config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE >>> default 0xa2 >>> >>> +config RBF_SDMMC_FAT_SUPPORT >> NAK, Xilinx already has some support for loading FPGA from FS, so >> improve on that. >> > I can change to CONFIG_CMD_FPGA_LOADFS. That's what they use iirc. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sf: Preserve QE bit when clearing BP# bits for Macronix flash
On Fri, Aug 4, 2017 at 12:21 PM, Bin Meng wrote:
> On Wed, Aug 2, 2017 at 6:26 AM, Bin Meng wrote:
>> Hi Jagan,
>>
>> On Wed, Aug 2, 2017 at 12:01 AM, Jagan Teki wrote:
>>> On Sun, Jul 23, 2017 at 8:14 PM, Bin Meng wrote:
On some flash (like Macronix), QE (quad enable) bit is in the same
status register as BP# bits, and we need preserve its original value
during a reboot cycle as this is required by some platforms (like
Intel ICH SPI controller working under descriptor mode).
Signed-off-by: Bin Meng
---
drivers/mtd/spi/spi_flash.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 0034a28..7d8c660 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -947,11 +947,24 @@ int spi_flash_scan(struct spi_flash *flash)
if (IS_ERR_OR_NULL(info))
return -ENOENT;
- /* Flash powers up read-only, so clear BP# bits */
+ /*
+* Flash powers up read-only, so clear BP# bits.
+*
+* Note on some flash (like Macronix), QE (quad enable) bit is in
the
+* same status register as BP# bits, and we need preserve its
original
+* value during a reboot cycle as this is required by some
platforms
+* (like Intel ICH SPI controller working under descriptor mode).
+*/
if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_ATMEL ||
- JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX ||
JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST)
write_sr(flash, 0);
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX) {
+ u8 sr = 0;
+
+ read_sr(flash, &sr);
+ sr &= STATUS_QEB_MXIC;
+ write_sr(flash, sr);
+ }
>>>
>>> It doesn't make sense to have one(specific) controller fix to be
>>> generic to all macronix chips, think about alternative.
>>>
>>
>> This is no way to fix at the controller level. Actually this is
>> nothing related to controller level. It's just the bootstrap settings
>> (QE bit in this case) that cannot be overwritten by someone else
>> (although it's seen on Intel, it might happen on some other
>> architecture). The logic in the codes are having issues. Its comment
>> says: clear BP# bits, but it clears QE bit for Macronix flash as well,
>> which is wrong. The update was just to make sure the codes do as what
>> its comment says.
>>
>> If you have any other alternative, please suggest.
>>
>
> Ping again..
>
> Can you please comment on this? I would like this patch gets in the
> upcoming release.
>
Ping ..
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sf: Add Macronix MX25U6435F device parameters
Hi Jagan,
On Mon, Jul 31, 2017 at 7:33 PM, Bin Meng wrote:
> Hi Jagan,
>
> On Mon, Jul 31, 2017 at 5:33 PM, Jagan Teki wrote:
>> On Sun, Jul 23, 2017 at 8:14 PM, Bin Meng wrote:
>>> This adds support for Macronix flash MX25U6435F (device ID 0xc22537).
>>>
>>> Signed-off-by: Bin Meng
>>> ---
>>>
>>> drivers/mtd/spi/spi_flash_ids.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mtd/spi/spi_flash_ids.c
>>> b/drivers/mtd/spi/spi_flash_ids.c
>>> index edca94e..c4ccf48 100644
>>> --- a/drivers/mtd/spi/spi_flash_ids.c
>>> +++ b/drivers/mtd/spi/spi_flash_ids.c
>>> @@ -81,6 +81,7 @@ const struct spi_flash_info spi_flash_ids[] = {
>>> {"mx25l12805", INFO(0xc22018, 0x0, 64 * 1024, 256, RD_FULL |
>>> WR_QPP) },
>>> {"mx25l25635f",INFO(0xc22019, 0x0, 64 * 1024, 512, RD_FULL |
>>> WR_QPP) },
>>> {"mx25l51235f",INFO(0xc2201a, 0x0, 64 * 1024, 1024, RD_FULL |
>>> WR_QPP) },
>>> + {"mx25u6435f", INFO(0xc22537, 0x0, 64 * 1024, 128, RD_FULL |
>>> WR_QPP) },
>>
>> Applied to u-boot-spi/master
>
I don't see this patch gets applied anywhere. Can you please make sure
the patch state is consistent when you reply the email?
> What about the 2nd patch [1] in this series?
>
> And I don't see this patch showing in
> http://git.denx.de/?p=u-boot/u-boot-spi.git;a=summary. Am I missing
> anything?
>
> [1] http://patchwork.ozlabs.org/patch/792565/
Also I don't see your response for the 2nd patch for some days.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sf: Preserve QE bit when clearing BP# bits for Macronix flash
Hi Bing,
On Mon, Aug 7, 2017 at 1:09 PM, Bin Meng wrote:
> On Fri, Aug 4, 2017 at 12:21 PM, Bin Meng wrote:
>> On Wed, Aug 2, 2017 at 6:26 AM, Bin Meng wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Aug 2, 2017 at 12:01 AM, Jagan Teki
>>> wrote:
On Sun, Jul 23, 2017 at 8:14 PM, Bin Meng wrote:
> On some flash (like Macronix), QE (quad enable) bit is in the same
> status register as BP# bits, and we need preserve its original value
> during a reboot cycle as this is required by some platforms (like
> Intel ICH SPI controller working under descriptor mode).
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/mtd/spi/spi_flash.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 0034a28..7d8c660 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -947,11 +947,24 @@ int spi_flash_scan(struct spi_flash *flash)
> if (IS_ERR_OR_NULL(info))
> return -ENOENT;
>
> - /* Flash powers up read-only, so clear BP# bits */
> + /*
> +* Flash powers up read-only, so clear BP# bits.
> +*
> +* Note on some flash (like Macronix), QE (quad enable) bit is in
> the
> +* same status register as BP# bits, and we need preserve its
> original
> +* value during a reboot cycle as this is required by some
> platforms
> +* (like Intel ICH SPI controller working under descriptor mode).
> +*/
> if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_ATMEL ||
> - JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX ||
> JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST)
> write_sr(flash, 0);
> + if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX) {
> + u8 sr = 0;
> +
> + read_sr(flash, &sr);
> + sr &= STATUS_QEB_MXIC;
> + write_sr(flash, sr);
> + }
It doesn't make sense to have one(specific) controller fix to be
generic to all macronix chips, think about alternative.
>>>
>>> This is no way to fix at the controller level. Actually this is
>>> nothing related to controller level. It's just the bootstrap settings
>>> (QE bit in this case) that cannot be overwritten by someone else
>>> (although it's seen on Intel, it might happen on some other
>>> architecture). The logic in the codes are having issues. Its comment
>>> says: clear BP# bits, but it clears QE bit for Macronix flash as well,
>>> which is wrong. The update was just to make sure the codes do as what
>>> its comment says.
>>>
>>> If you have any other alternative, please suggest.
>>>
>>
>> Ping again..
Wait for sometime, I've queue that I need to review-it and respond
accordingly patches with latest may take some time. And commenting
yes will respond soon.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fastboot: mmc: fix pointer size warning in 64bit system
To fix warning in ARM64:
common/fb_mmc.c: In function ‘fb_mmc_update_zimage’:
common/fb_mmc.c:216:13: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
hdr_addr = (u32)download_buffer + ALIGN(download_bytes, PAGE_SIZE);
^
common/fb_mmc.c:217:8: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
hdr = (struct andr_img_hdr *)hdr_addr;
Signed-off-by: Kever Yang
---
common/fb_mmc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index a4b73dc..4511b8c 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -190,7 +190,6 @@ static int fb_mmc_update_zimage(struct blk_desc *dev_desc,
unsigned int download_bytes,
char *response)
{
- u32 hdr_addr; /* boot image header address */
struct andr_img_hdr *hdr; /* boot image header */
lbaint_t hdr_sectors; /* boot image header sectors */
u8 *ramdisk_buffer;
@@ -213,8 +212,7 @@ static int fb_mmc_update_zimage(struct blk_desc *dev_desc,
}
/* Put boot image header in fastboot buffer after downloaded zImage */
- hdr_addr = (u32)download_buffer + ALIGN(download_bytes, PAGE_SIZE);
- hdr = (struct andr_img_hdr *)hdr_addr;
+ hdr = download_buffer + ALIGN(download_bytes, PAGE_SIZE);
/* Read boot image header */
hdr_sectors = fb_mmc_get_boot_header(dev_desc, &info, hdr, response);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager
On Isn, 2017-07-31 at 12:55 +0200, Marek Vasut wrote: > On 07/31/2017 12:50 PM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > Configuration flip-flop driver is mainly used for handling the FPGA > > program > > operation where the FPGA image loading from the flash into FPGA > > manager. > > > > Signed-off-by: Tien Fong Chee > > --- > > arch/arm/mach-socfpga/cff.c | 581 > > ++ > > arch/arm/mach-socfpga/include/mach/cff.h | 40 ++ > > include/configs/socfpga_arria10_socdk.h |6 + > > 3 files changed, 627 insertions(+), 0 deletions(-) > > create mode 100644 arch/arm/mach-socfpga/cff.c > > create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h > > > Same comment as to previous patch, there is already support for > loading > FPGA from storage used by Xilinx, improve on that. > Hi Marek, After i going through the xilinx codes, i found that we are sharing similar fpga framework design. The only different are the way of decoding fpga design and loading from flash to fpga. So this would be handled in cff.c, as for xilinx if i am not mistaken is drivers/fpga/zynqpl.c. I think appropiate location for cff.c should be in arch/mach-socfpga because this is not fpga driver, this is more like platform specific algorithm mechanism to handle fpga decoding and loading from flash to fpga. For the U-boot console command fpga loafs, which will wrap the cff.c and acting as upper layer driver for user console interface. I plan to enhance this after having a complete boot from sdmmc, qspi and nand because this require considering a lot use case scenarios, and some workaround on PLL clock glitch issue. You know our DDR IOs is part of the fpga periph rbf, simply calling fpga loadfs to reconfigure fpga can corrupt the DDR IOs configuration, and board may hang if it is not handle properly, so i need a workable complete boot to console environment for testing out the enhancement. Let me know what you think about this patchset, and can i continue process with this patchset? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368
Andy, Doing a non-buildman defconfig + make works fine. I’ve seen this too (I did a full buildman for all arm, x86 and powerpc boards) and it seems as if a shell-script is trying to source the generated auto.config file. I couldn’t spot where in buildman that happens, so I’ll need to leave this to someone with more insight into buildman to figure out… Regards, Phil. > On 07 Aug 2017, at 03:19, Andy Yan wrote: > > Hi : > >When run buildman rockchip on the master branch of current u-boot-rockchip > tree, I got warnings about 16 rockchip arm32 based boards: > > include/config/auto.config: line x: ARCH: command not found. > > the line x is the definition of the: SPL_LDSCRITP > "arch/$(ARCH)/cpu/u-boot-spl.lds" > > not sure is there somethings wrong about this series change. > > > On 2017年08月07日 01:18, Philipp Tomsich wrote: >>> Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our >>> header file. >>> >>> Signed-off-by: Philipp Tomsich >>> Reviewed-by: Simon Glass >>> --- >>> >>> Changes in v4: >>> - (added) sets TPL_LDSCRIPT via Kconfig >>> >>> Changes in v3: None >>> Changes in v2: None >>> >>> arch/arm/mach-rockchip/Kconfig | 7 +++ >>> include/configs/rk3368_common.h | 2 -- >>> 2 files changed, 7 insertions(+), 2 deletions(-) >>> >> Applied to u-boot-rockchip, thanks! >> >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv4 0/2] ARM: sunxi: Add support for OLinuXino Lime2 eMMC
On Fri, May 12, 2017 at 10:22 PM, Maxime Ripard wrote: > On Fri, May 12, 2017 at 11:38:52AM +0200, Olliver Schinagl wrote: >> This patch series adds support for the Olimex OLinuXino Lime2 eMMC. This >> assembly variant uses eMMC flash instead of NAND (or no flash) on the other >> Lime2's. Additionally, we sync the dts with upstream as we now use this dts >> from the new defconfig. > > Acked-by: Maxime Ripard Applied to u-boot-sunxi/master thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mmc: uniphier-sd: Factor out register IO
On 08/07/2017 04:30 AM, Masahiro Yamada wrote:
> Hi Marek,
Hi Masahiro,
This is gonna be a great discussion, let's wrestle about consts and ints :-)
> 2017-08-06 4:23 GMT+09:00 Marek Vasut :
>> On 08/03/2017 02:36 PM, Masahiro Yamada wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>> [...]
>>
+static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg)
>>>
>>> "const" is unneeded here.
>>
>> Why? The function should not modify reg , so it is const.
>
>
> Because "const" is useless here.
>
> The "reg" is not a pointer, so it is obvious
> that there is no impact to the callers.
>
>
>
> Moreover, whether "reg" is constant or not
> depends on how you implement the function.
>
>
> If you force "const" to the argument, the only choice for the implementation
> will be as follows:
>
>
>
> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg)
> {
> if (priv->caps & UNIPHIER_SD_CAP_64BIT)
> return readl(priv->regbase + (reg << 1));
> else
> return readl(priv->regbase + reg);
> }
>
>
>
> If you want to implement the function as follows, you need to drop "const".
>
> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, u32 reg)
> {
> if (priv->caps & UNIPHIER_SD_CAP_64BIT)
> reg <<= 1;
>
> return readl(priv->regbase + reg);
> }
My argument would be that the const prevents you from accidentally
modifying the $reg inside the function.
>>> Also, could you use "unsigned int" or "int" for reg?
>>
>> Why?
>
>
> Because "unsigned int" or "int" is more natural.
>
> No reason to use a fixed width variable for the address offset.
You're loosing the benefit of fixed width with using unsigned int though?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager
On 08/07/2017 10:16 AM, Chee, Tien Fong wrote: > On Isn, 2017-07-31 at 12:55 +0200, Marek Vasut wrote: >> On 07/31/2017 12:50 PM, tien.fong.c...@intel.com wrote: >>> >>> From: Tien Fong Chee >>> >>> Configuration flip-flop driver is mainly used for handling the FPGA >>> program >>> operation where the FPGA image loading from the flash into FPGA >>> manager. >>> >>> Signed-off-by: Tien Fong Chee >>> --- >>> arch/arm/mach-socfpga/cff.c | 581 >>> ++ >>> arch/arm/mach-socfpga/include/mach/cff.h | 40 ++ >>> include/configs/socfpga_arria10_socdk.h |6 + >>> 3 files changed, 627 insertions(+), 0 deletions(-) >>> create mode 100644 arch/arm/mach-socfpga/cff.c >>> create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h >>> >> Same comment as to previous patch, there is already support for >> loading >> FPGA from storage used by Xilinx, improve on that. >> > Hi Marek, > > After i going through the xilinx codes, i found that we are sharing > similar fpga framework design. The only different are the way of > decoding fpga design and loading from flash to fpga. So this would be > handled in cff.c, as for xilinx if i am not mistaken > is drivers/fpga/zynqpl.c. I think appropiate location for cff.c should > be in arch/mach-socfpga because this is not fpga driver, this is more > like platform specific algorithm mechanism to handle fpga decoding and > loading from flash to fpga. For the U-boot console command fpga loafs, > which will wrap the cff.c and acting as upper layer driver for user > console interface. I plan to enhance this after having a complete boot > from sdmmc, qspi and nand because this require considering a lot use > case scenarios, and some workaround on PLL clock glitch issue. You know > our DDR IOs is part of the fpga periph rbf, simply calling fpga loadfs > to reconfigure fpga can corrupt the DDR IOs configuration, and board > may hang if it is not handle properly, so i need a workable complete > boot to console environment for testing out the enhancement. > > Let me know what you think about this patchset, and can i continue > process with this patchset? I think cff.c is not even needed. Otherwise, submit patches and we'll see how that looks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/10] mips: bmips: add SPI support
Hi, On Sun, Jul 30, 2017 at 5:43 PM, Álvaro Fernández Rojas wrote: > BCM63xx SPI controller is a bit tricky since it doesn't allow keeping CS > active between transfers, so I had to modify the spi_flash driver in order > to allow limiting reads. > > v5: Introduce changes suggested by Jagan Teki: > - Use long structs for registers > v4: Introduce changes suggested by Jagan Teki: > - Add data for each HW controller instead of having two separate configs. > v3: Fix bug introduced in v2: sizeof(cmd) vs len. > Also rename BCM6338 SPI driver to BCM6348 SPI since BCM6338 is a stripped > down version of the BCM6348. > Switch to devfdt_get_addr_size_index(). > v2: Introduce changes requested by Simon Glass: > - Always include command bytes when determining max write size. > Also move SPI aliases from .dts to .dtsi files. Did you sent the latest changes? I couldn't find it on patchwork even with status "any" thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368
Hi Philipp: On 2017年08月07日 16:24, Dr. Philipp Tomsich wrote: Andy, Doing a non-buildman defconfig + make works fine. I’ve seen this too (I did a full buildman for all arm, x86 and powerpc boards) and it seems as if a shell-script is trying to source the generated auto.config file. I couldn’t spot where in buildman that happens, so I’ll need to leave this to someone with more insight into buildman to figure out… I build with : make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- firefly-rk3288_defconfig all Also can see the waring: inclue/config/auto.conf: line 209: ARCH: command not found. Regards, Phil. On 07 Aug 2017, at 03:19, Andy Yan wrote: Hi : When run buildman rockchip on the master branch of current u-boot-rockchip tree, I got warnings about 16 rockchip arm32 based boards: include/config/auto.config: line x: ARCH: command not found. the line x is the definition of the: SPL_LDSCRITP "arch/$(ARCH)/cpu/u-boot-spl.lds" not sure is there somethings wrong about this series change. On 2017年08月07日 01:18, Philipp Tomsich wrote: Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our header file. Signed-off-by: Philipp Tomsich Reviewed-by: Simon Glass --- Changes in v4: - (added) sets TPL_LDSCRIPT via Kconfig Changes in v3: None Changes in v2: None arch/arm/mach-rockchip/Kconfig | 7 +++ include/configs/rk3368_common.h | 2 -- 2 files changed, 7 insertions(+), 2 deletions(-) Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368
Hm, ok: let me check again, maybe I can spot this now. I wonder why this didn’t show for me when I tried earlier. > On 07 Aug 2017, at 10:38, Andy Yan wrote: > > Hi Philipp: > > > On 2017年08月07日 16:24, Dr. Philipp Tomsich wrote: >> Andy, >> >> Doing a non-buildman defconfig + make works fine. >> I’ve seen this too (I did a full buildman for all arm, x86 and powerpc >> boards) and it seems as if a shell-script is trying to source the generated >> auto.config file. >> I couldn’t spot where in buildman that happens, so I’ll need to leave this >> to someone with more insight into buildman to figure out… > > >I build with : make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- > firefly-rk3288_defconfig all > Also can see the waring: inclue/config/auto.conf: line 209: ARCH: command not > found. >> >> Regards, >> Phil. >> >>> On 07 Aug 2017, at 03:19, Andy Yan wrote: >>> >>> Hi : >>> >>>When run buildman rockchip on the master branch of current >>> u-boot-rockchip tree, I got warnings about 16 rockchip arm32 based boards: >>> >>> include/config/auto.config: line x: ARCH: command not found. >>> >>> the line x is the definition of the: SPL_LDSCRITP >>> "arch/$(ARCH)/cpu/u-boot-spl.lds" >>> >>> not sure is there somethings wrong about this series change. >>> >>> >>> On 2017年08月07日 01:18, Philipp Tomsich wrote: > Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our > header file. > > Signed-off-by: Philipp Tomsich > Reviewed-by: Simon Glass > --- > > Changes in v4: > - (added) sets TPL_LDSCRIPT via Kconfig > > Changes in v3: None > Changes in v2: None > > arch/arm/mach-rockchip/Kconfig | 7 +++ > include/configs/rk3368_common.h | 2 -- > 2 files changed, 7 insertions(+), 2 deletions(-) > Applied to u-boot-rockchip, thanks! >>> >> >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager
On Isn, 2017-08-07 at 10:19 +0200, Marek Vasut wrote: > On 08/07/2017 10:16 AM, Chee, Tien Fong wrote: > > > > On Isn, 2017-07-31 at 12:55 +0200, Marek Vasut wrote: > > > > > > On 07/31/2017 12:50 PM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > Configuration flip-flop driver is mainly used for handling the > > > > FPGA > > > > program > > > > operation where the FPGA image loading from the flash into FPGA > > > > manager. > > > > > > > > Signed-off-by: Tien Fong Chee > > > > --- > > > > arch/arm/mach-socfpga/cff.c | 581 > > > > ++ > > > > arch/arm/mach-socfpga/include/mach/cff.h | 40 ++ > > > > include/configs/socfpga_arria10_socdk.h |6 + > > > > 3 files changed, 627 insertions(+), 0 deletions(-) > > > > create mode 100644 arch/arm/mach-socfpga/cff.c > > > > create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h > > > > > > > Same comment as to previous patch, there is already support for > > > loading > > > FPGA from storage used by Xilinx, improve on that. > > > > > Hi Marek, > > > > After i going through the xilinx codes, i found that we are sharing > > similar fpga framework design. The only different are the way of > > decoding fpga design and loading from flash to fpga. So this would > > be > > handled in cff.c, as for xilinx if i am not mistaken > > is drivers/fpga/zynqpl.c. I think appropiate location for cff.c > > should > > be in arch/mach-socfpga because this is not fpga driver, this is > > more > > like platform specific algorithm mechanism to handle fpga decoding > > and > > loading from flash to fpga. For the U-boot console command fpga > > loafs, > > which will wrap the cff.c and acting as upper layer driver > > for user > > console interface. I plan to enhance this after having a complete > > boot > > from sdmmc, qspi and nand because this require considering a lot > > use > > case scenarios, and some workaround on PLL clock glitch issue. You > > know > > our DDR IOs is part of the fpga periph rbf, simply calling fpga > > loadfs > > to reconfigure fpga can corrupt the DDR IOs configuration, and > > board > > may hang if it is not handle properly, so i need a workable > > complete > > boot to console environment for testing out the enhancement. > > > > Let me know what you think about this patchset, and can i continue > > process with this patchset? > I think cff.c is not even needed. Otherwise, submit patches and we'll > see how that looks. > sure. we can discuss again on new patches. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sf: add support for GD25Q256
On Fri, Aug 4, 2017 at 3:03 PM, Andy Yan wrote:
> Add support for GD25Q256, a 32MiB SPI Nor
> flash from Gigadevice.
>
> Signed-off-by: Andy Yan
> ---
>
> drivers/mtd/spi/sf_internal.h | 1 +
> drivers/mtd/spi/spi_flash.c | 7 ---
> drivers/mtd/spi/spi_flash_ids.c | 1 +
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 839cdbe..357b3bc 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -37,6 +37,7 @@ enum spi_nor_option_flags {
> #define SPI_FLASH_CFI_MFR_SST 0xbf
> #define SPI_FLASH_CFI_MFR_WINBOND 0xef
> #define SPI_FLASH_CFI_MFR_ATMEL0x1f
> +#define SPI_FLASH_CIF_MFR_GIGADEVICE 0xc8
>
> /* Erase commands */
> #define CMD_ERASE_4K 0x20
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 0034a28..cf23077 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -74,7 +74,7 @@ static int write_sr(struct spi_flash *flash, u8 ws)
> return 0;
> }
>
> -#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
> +#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
> || defined(CONFIG_SPI_FLASH_GIGADEVICE)
> static int read_cr(struct spi_flash *flash, u8 *rc)
> {
> int ret;
> @@ -807,7 +807,7 @@ int stm_unlock(struct spi_flash *flash, u32 ofs, size_t
> len)
> #endif
>
>
> -#ifdef CONFIG_SPI_FLASH_MACRONIX
> +#if defined(CONFIG_SPI_FLASH_MACRONIX) ||
> defined(CONFIG_SPI_FLASH_GIGADEVICE)
So GB and Macronix has same procedure bit for Quadenable? in that case
why you need read_cr bcz it is part of spansion.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368
Hi PHilipp: On 2017年08月07日 16:39, Dr. Philipp Tomsich wrote: Hm, ok: let me check again, maybe I can spot this now. I wonder why this didn’t show for me when I tried earlier. I also didn't found it in the early times build. When I run the "buildman rockchip" today, It show the warnings in red color, Then I go back check the manual build (make _defconfig all), I found the warning message also hide in it.:-) On 07 Aug 2017, at 10:38, Andy Yan wrote: Hi Philipp: On 2017年08月07日 16:24, Dr. Philipp Tomsich wrote: Andy, Doing a non-buildman defconfig + make works fine. I’ve seen this too (I did a full buildman for all arm, x86 and powerpc boards) and it seems as if a shell-script is trying to source the generated auto.config file. I couldn’t spot where in buildman that happens, so I’ll need to leave this to someone with more insight into buildman to figure out… I build with : make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- firefly-rk3288_defconfig all Also can see the waring: inclue/config/auto.conf: line 209: ARCH: command not found. Regards, Phil. On 07 Aug 2017, at 03:19, Andy Yan wrote: Hi : When run buildman rockchip on the master branch of current u-boot-rockchip tree, I got warnings about 16 rockchip arm32 based boards: include/config/auto.config: line x: ARCH: command not found. the line x is the definition of the: SPL_LDSCRITP "arch/$(ARCH)/cpu/u-boot-spl.lds" not sure is there somethings wrong about this series change. On 2017年08月07日 01:18, Philipp Tomsich wrote: Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our header file. Signed-off-by: Philipp Tomsich Reviewed-by: Simon Glass --- Changes in v4: - (added) sets TPL_LDSCRIPT via Kconfig Changes in v3: None Changes in v2: None arch/arm/mach-rockchip/Kconfig | 7 +++ include/configs/rk3368_common.h | 2 -- 2 files changed, 7 insertions(+), 2 deletions(-) Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368
+Tom
Ok, so the problem is 'scripts/setlocalversion’, which does the following:
> if test -e include/config/auto.conf; then
> . include/config/auto.conf
> else
> echo "Error: kernelrelease not valid - run 'make prepare' to update
> it"
> exit 1
> fi
in order to access the variables needed for:
> # CONFIG_LOCALVERSION and LOCALVERSION (if set)
> res="${res}${CONFIG_LOCALVERSION}${LOCALVERSION}"
>
> # scm version string if not at a tagged commit
> if test "$CONFIG_LOCALVERSION_AUTO" = "y"; then
> # full scm version string
> res="$res$(scm_version)"
> else
> # append a plus sign if the repository is not in a clean
> # annotated or signed tagged state (as git describe only
> # looks at signed or annotated tags - git tag -a/-s) and
> # LOCALVERSION= is not specified
> if test "${LOCALVERSION+set}" != "set"; then
> scm=$(scm_version --short)
> res="$res${scm:++}"
> fi
> fi
So nothing wrong with the changes to Kconfig, but we’re triggering a weakness
in our
build infrastructure here.
I guess we’ll have to implement a save version of scripts/localversion that
does not
allow for the execution of arbitrary script code from auto.conf ...
> On 07 Aug 2017, at 10:38, Andy Yan wrote:
>
> Hi Philipp:
>
>
> On 2017年08月07日 16:24, Dr. Philipp Tomsich wrote:
>> Andy,
>>
>> Doing a non-buildman defconfig + make works fine.
>> I’ve seen this too (I did a full buildman for all arm, x86 and powerpc
>> boards) and it seems as if a shell-script is trying to source the generated
>> auto.config file.
>> I couldn’t spot where in buildman that happens, so I’ll need to leave this
>> to someone with more insight into buildman to figure out…
>
>
>I build with : make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> firefly-rk3288_defconfig all
> Also can see the waring: inclue/config/auto.conf: line 209: ARCH: command not
> found.
>>
>> Regards,
>> Phil.
>>
>>> On 07 Aug 2017, at 03:19, Andy Yan wrote:
>>>
>>> Hi :
>>>
>>>When run buildman rockchip on the master branch of current
>>> u-boot-rockchip tree, I got warnings about 16 rockchip arm32 based boards:
>>>
>>> include/config/auto.config: line x: ARCH: command not found.
>>>
>>> the line x is the definition of the: SPL_LDSCRITP
>>> "arch/$(ARCH)/cpu/u-boot-spl.lds"
>>>
>>> not sure is there somethings wrong about this series change.
>>>
>>>
>>> On 2017年08月07日 01:18, Philipp Tomsich wrote:
> Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our
> header file.
>
> Signed-off-by: Philipp Tomsich
> Reviewed-by: Simon Glass
> ---
>
> Changes in v4:
> - (added) sets TPL_LDSCRIPT via Kconfig
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/mach-rockchip/Kconfig | 7 +++
> include/configs/rk3368_common.h | 2 --
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
Applied to u-boot-rockchip, thanks!
>>>
>>
>>
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/5] mmc: uniphier-sd: Factor out register IO
This patch prepares the driver to support controller(s) with registers
at locations shifted by constant. Pull out the readl()/writel() from
the driver into separate functions, where the adjustment of the register
offset can be easily contained.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
Cc: Jaehoon Chung
---
V2: Use unsigned int for the reg argument
---
drivers/mmc/uniphier-sd.c | 115 +-
1 file changed, 63 insertions(+), 52 deletions(-)
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index e272b14153..b5c608d866 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -134,6 +134,17 @@ struct uniphier_sd_priv {
#define UNIPHIER_SD_CAP_DIV1024BIT(2) /* divisor 1024 is
available */
};
+static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, unsigned int reg)
+{
+ return readl(priv->regbase + reg);
+}
+
+static void uniphier_sd_writel(struct uniphier_sd_priv *priv,
+ const u32 val, unsigned int reg)
+{
+ writel(val, priv->regbase + reg);
+}
+
static dma_addr_t __dma_map_single(void *ptr, size_t size,
enum dma_data_direction dir)
{
@@ -157,7 +168,7 @@ static void __dma_unmap_single(dma_addr_t addr, size_t size,
static int uniphier_sd_check_error(struct udevice *dev)
{
struct uniphier_sd_priv *priv = dev_get_priv(dev);
- u32 info2 = readl(priv->regbase + UNIPHIER_SD_INFO2);
+ u32 info2 = uniphier_sd_readl(priv, UNIPHIER_SD_INFO2);
if (info2 & UNIPHIER_SD_INFO2_ERR_RTO) {
/*
@@ -195,7 +206,7 @@ static int uniphier_sd_wait_for_irq(struct udevice *dev,
unsigned int reg,
long wait = 100;
int ret;
- while (!(readl(priv->regbase + reg) & flag)) {
+ while (!(uniphier_sd_readl(priv, reg) & flag)) {
if (wait-- < 0) {
dev_err(dev, "timeout\n");
return -ETIMEDOUT;
@@ -227,14 +238,14 @@ static int uniphier_sd_pio_read_one_block(struct udevice
*dev, u32 **pbuf,
* Clear the status flag _before_ read the buffer out because
* UNIPHIER_SD_INFO2_BRE is edge-triggered, not level-triggered.
*/
- writel(0, priv->regbase + UNIPHIER_SD_INFO2);
+ uniphier_sd_writel(priv, 0, UNIPHIER_SD_INFO2);
if (likely(IS_ALIGNED((unsigned long)*pbuf, 4))) {
for (i = 0; i < blocksize / 4; i++)
- *(*pbuf)++ = readl(priv->regbase + UNIPHIER_SD_BUF);
+ *(*pbuf)++ = uniphier_sd_readl(priv, UNIPHIER_SD_BUF);
} else {
for (i = 0; i < blocksize / 4; i++)
- put_unaligned(readl(priv->regbase + UNIPHIER_SD_BUF),
+ put_unaligned(uniphier_sd_readl(priv, UNIPHIER_SD_BUF),
(*pbuf)++);
}
@@ -253,15 +264,15 @@ static int uniphier_sd_pio_write_one_block(struct udevice
*dev,
if (ret)
return ret;
- writel(0, priv->regbase + UNIPHIER_SD_INFO2);
+ uniphier_sd_writel(priv, 0, UNIPHIER_SD_INFO2);
if (likely(IS_ALIGNED((unsigned long)*pbuf, 4))) {
for (i = 0; i < blocksize / 4; i++)
- writel(*(*pbuf)++, priv->regbase + UNIPHIER_SD_BUF);
+ uniphier_sd_writel(priv, *(*pbuf)++, UNIPHIER_SD_BUF);
} else {
for (i = 0; i < blocksize / 4; i++)
- writel(get_unaligned((*pbuf)++),
- priv->regbase + UNIPHIER_SD_BUF);
+ uniphier_sd_writel(priv, get_unaligned((*pbuf)++),
+ UNIPHIER_SD_BUF);
}
return 0;
@@ -292,22 +303,22 @@ static void uniphier_sd_dma_start(struct uniphier_sd_priv
*priv,
{
u32 tmp;
- writel(0, priv->regbase + UNIPHIER_SD_DMA_INFO1);
- writel(0, priv->regbase + UNIPHIER_SD_DMA_INFO2);
+ uniphier_sd_writel(priv, 0, UNIPHIER_SD_DMA_INFO1);
+ uniphier_sd_writel(priv, 0, UNIPHIER_SD_DMA_INFO2);
/* enable DMA */
- tmp = readl(priv->regbase + UNIPHIER_SD_EXTMODE);
+ tmp = uniphier_sd_readl(priv, UNIPHIER_SD_EXTMODE);
tmp |= UNIPHIER_SD_EXTMODE_DMA_EN;
- writel(tmp, priv->regbase + UNIPHIER_SD_EXTMODE);
+ uniphier_sd_writel(priv, tmp, UNIPHIER_SD_EXTMODE);
- writel(dma_addr & U32_MAX, priv->regbase + UNIPHIER_SD_DMA_ADDR_L);
+ uniphier_sd_writel(priv, dma_addr & U32_MAX, UNIPHIER_SD_DMA_ADDR_L);
/* suppress the warning "right shift count >= width of type" */
dma_addr >>= min_t(int, 32, 8 * sizeof(dma_addr));
- writel(dma_addr & U32_MAX, priv->regbase + UNIPHIER_SD_DMA_ADDR_H);
+ uniphier_sd_writel(priv, dma_addr & U32_MAX, UNIPHIER_SD_DMA_ADDR_H);
- writel(UNIPHIER_SD_DMA_CTL_START, priv->regbase + UNIPHIER_SD_DMA_CTL);
+ un
[U-Boot] [PATCH V2 3/5] mmc: uniphier-sd: Add support for 64bit FIFO
The Renesas RCar Gen3 contains the same controller, originally
Matsushita. This patch adds support for handling of the 64bit
FIFO on this controller.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
Cc: Jaehoon Chung
---
V2: - Use unsigned int for the reg argument of IO accessors
- Rework the handling of aligned and unaligned data
---
drivers/mmc/uniphier-sd.c | 101 +-
1 file changed, 83 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 742d936d98..12b2f1f38f 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -135,6 +135,23 @@ struct uniphier_sd_priv {
#define UNIPHIER_SD_CAP_64BIT BIT(3) /* Controller is 64bit */
};
+static u64 uniphier_sd_readq(struct uniphier_sd_priv *priv, unsigned int reg)
+{
+ if (priv->caps & UNIPHIER_SD_CAP_64BIT)
+ return readq(priv->regbase + (reg << 1));
+ else
+ return readq(priv->regbase + reg);
+}
+
+static void uniphier_sd_writeq(struct uniphier_sd_priv *priv,
+ const u64 val, unsigned int reg)
+{
+ if (priv->caps & UNIPHIER_SD_CAP_64BIT)
+ writeq(val, priv->regbase + (reg << 1));
+ else
+ writeq(val, priv->regbase + reg);
+}
+
static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, unsigned int reg)
{
if (priv->caps & UNIPHIER_SD_CAP_64BIT)
@@ -229,7 +246,7 @@ static int uniphier_sd_wait_for_irq(struct udevice *dev,
unsigned int reg,
return 0;
}
-static int uniphier_sd_pio_read_one_block(struct udevice *dev, u32 **pbuf,
+static int uniphier_sd_pio_read_one_block(struct udevice *dev, char *pbuf,
uint blocksize)
{
struct uniphier_sd_priv *priv = dev_get_priv(dev);
@@ -247,20 +264,42 @@ static int uniphier_sd_pio_read_one_block(struct udevice
*dev, u32 **pbuf,
*/
uniphier_sd_writel(priv, 0, UNIPHIER_SD_INFO2);
- if (likely(IS_ALIGNED((unsigned long)*pbuf, 4))) {
- for (i = 0; i < blocksize / 4; i++)
- *(*pbuf)++ = uniphier_sd_readl(priv, UNIPHIER_SD_BUF);
+ if (priv->caps & UNIPHIER_SD_CAP_64BIT) {
+ u64 *buf = (u64 *)pbuf;
+ if (likely(IS_ALIGNED((uintptr_t)buf, 8))) {
+ for (i = 0; i < blocksize / 8; i++) {
+ *buf++ = uniphier_sd_readq(priv,
+ UNIPHIER_SD_BUF);
+ }
+ } else {
+ for (i = 0; i < blocksize / 8; i++) {
+ u64 data;
+ data = uniphier_sd_readq(priv,
+UNIPHIER_SD_BUF);
+ put_unaligned(data, buf++);
+ }
+ }
} else {
- for (i = 0; i < blocksize / 4; i++)
- put_unaligned(uniphier_sd_readl(priv, UNIPHIER_SD_BUF),
- (*pbuf)++);
+ u32 *buf = (u32 *)pbuf;
+ if (likely(IS_ALIGNED((uintptr_t)buf, 4))) {
+ for (i = 0; i < blocksize / 4; i++) {
+ *buf++ = uniphier_sd_readl(priv,
+ UNIPHIER_SD_BUF);
+ }
+ } else {
+ for (i = 0; i < blocksize / 4; i++) {
+ u32 data;
+ data = uniphier_sd_readl(priv, UNIPHIER_SD_BUF);
+ put_unaligned(data, buf++);
+ }
+ }
}
return 0;
}
static int uniphier_sd_pio_write_one_block(struct udevice *dev,
- const u32 **pbuf, uint blocksize)
+ const char *pbuf, uint blocksize)
{
struct uniphier_sd_priv *priv = dev_get_priv(dev);
int i, ret;
@@ -273,13 +312,34 @@ static int uniphier_sd_pio_write_one_block(struct udevice
*dev,
uniphier_sd_writel(priv, 0, UNIPHIER_SD_INFO2);
- if (likely(IS_ALIGNED((unsigned long)*pbuf, 4))) {
- for (i = 0; i < blocksize / 4; i++)
- uniphier_sd_writel(priv, *(*pbuf)++, UNIPHIER_SD_BUF);
+ if (priv->caps & UNIPHIER_SD_CAP_64BIT) {
+ const u64 *buf = (const u64 *)pbuf;
+ if (likely(IS_ALIGNED((uintptr_t)buf, 8))) {
+ for (i = 0; i < blocksize / 8; i++) {
+ uniphier_sd_writeq(priv, *buf++,
+ UNIPHIER_SD_BUF);
+ }
+ } else {
+ for (i = 0; i < blocksize / 8; i++) {
+ u64 data = get_una
[U-Boot] [PATCH 2/5] mmc: uniphier-sd: Add support for 64bit controller
The Renesas RCar Gen3 contains the same controller, originally
Matsushita, yet the register addresses are shifted by 1 to the
left. The whole controller is also 64bit, including the data
FIFOs and RSP registers. This patch adds support for handling
the register IO by shifting the register offset by 1 in the IO
accessor functions.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
Cc: Jaehoon Chung
---
drivers/mmc/uniphier-sd.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index b5c608d866..742d936d98 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -132,17 +132,24 @@ struct uniphier_sd_priv {
#define UNIPHIER_SD_CAP_NONREMOVABLE BIT(0) /* Nonremovable e.g. eMMC */
#define UNIPHIER_SD_CAP_DMA_INTERNAL BIT(1) /* have internal DMA engine */
#define UNIPHIER_SD_CAP_DIV1024BIT(2) /* divisor 1024 is
available */
+#define UNIPHIER_SD_CAP_64BIT BIT(3) /* Controller is 64bit */
};
static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, unsigned int reg)
{
- return readl(priv->regbase + reg);
+ if (priv->caps & UNIPHIER_SD_CAP_64BIT)
+ return readl(priv->regbase + (reg << 1));
+ else
+ return readl(priv->regbase + reg);
}
static void uniphier_sd_writel(struct uniphier_sd_priv *priv,
const u32 val, unsigned int reg)
{
- writel(val, priv->regbase + reg);
+ if (priv->caps & UNIPHIER_SD_CAP_64BIT)
+ writel(val, priv->regbase + (reg << 1));
+ else
+ writel(val, priv->regbase + reg);
}
static dma_addr_t __dma_map_single(void *ptr, size_t size,
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] mmc: uniphier-sd: Add support for quirks
Check if the OF match has any associated data and if so, use those
data as the controller quirks, otherwise fallback to the old method
of reading the controller version register to figure out the quirks.
This allows us to supply controller quirks on controllers which ie.
do not have version register.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
Cc: Jaehoon Chung
---
drivers/mmc/uniphier-sd.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 12b2f1f38f..4d0c032f92 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -752,6 +752,7 @@ static int uniphier_sd_probe(struct udevice *dev)
struct uniphier_sd_plat *plat = dev_get_platdata(dev);
struct uniphier_sd_priv *priv = dev_get_priv(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ const u32 quirks = dev_get_driver_data(dev);
fdt_addr_t base;
struct clk clk;
int ret;
@@ -803,18 +804,22 @@ static int uniphier_sd_probe(struct udevice *dev)
return -EINVAL;
}
+ if (quirks) {
+ priv->caps = quirks;
+ } else {
+ priv->version = uniphier_sd_readl(priv, UNIPHIER_SD_VERSION) &
+ UNIPHIER_SD_VERSION_IP;
+ dev_dbg(dev, "version %x\n", priv->version);
+ if (priv->version >= 0x10) {
+ priv->caps |= UNIPHIER_SD_CAP_DMA_INTERNAL;
+ priv->caps |= UNIPHIER_SD_CAP_DIV1024;
+ }
+ }
+
if (fdt_get_property(gd->fdt_blob, dev_of_offset(dev), "non-removable",
NULL))
priv->caps |= UNIPHIER_SD_CAP_NONREMOVABLE;
- priv->version = uniphier_sd_readl(priv, UNIPHIER_SD_VERSION) &
- UNIPHIER_SD_VERSION_IP;
- dev_dbg(dev, "version %x\n", priv->version);
- if (priv->version >= 0x10) {
- priv->caps |= UNIPHIER_SD_CAP_DMA_INTERNAL;
- priv->caps |= UNIPHIER_SD_CAP_DIV1024;
- }
-
uniphier_sd_host_init(priv);
plat->cfg.voltages = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34;
@@ -829,7 +834,7 @@ static int uniphier_sd_probe(struct udevice *dev)
}
static const struct udevice_id uniphier_sd_match[] = {
- { .compatible = "socionext,uniphier-sdhc" },
+ { .compatible = "socionext,uniphier-sdhc", .data = 0 },
{ /* sentinel */ }
};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] mmc: uniphier-sd: Add support for R8A7795 and R7A7796
Add OF match entries and quirks for Renesas RCar Gen3 controllers
into the driver. The IP this driver handles is in fact Matsushita
one and in used both in Socionext and Renesas chips.
Signed-off-by: Marek Vasut
Cc: Masahiro Yamada
Cc: Jaehoon Chung
---
drivers/mmc/Kconfig | 7 ---
drivers/mmc/uniphier-sd.c | 2 ++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 51a87cdd77..7a83975c6e 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -182,12 +182,13 @@ config SH_SDHI
Support for the on-chip SDHI host controller on SuperH/Renesas ARM
SoCs platform
config MMC_UNIPHIER
- bool "UniPhier SD/MMC Host Controller support"
- depends on ARCH_UNIPHIER
+ bool "UniPhier/RCar SD/MMC Host Controller support"
+ depends on ARCH_UNIPHIER || ARCH_RMOBILE
depends on BLK && DM_MMC_OPS
depends on OF_CONTROL
help
- This selects support for the SD/MMC Host Controller on UniPhier SoCs.
+ This selects support for the Matsushita SD/MMC Host Controller on
+ SocioNext UniPhier and Renesas RCar SoCs.
config MMC_SANDBOX
bool "Sandbox MMC support"
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 4d0c032f92..798c0fbaaa 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -834,6 +834,8 @@ static int uniphier_sd_probe(struct udevice *dev)
}
static const struct udevice_id uniphier_sd_match[] = {
+ { .compatible = "renesas,sdhi-r8a7795", .data = UNIPHIER_SD_CAP_64BIT },
+ { .compatible = "renesas,sdhi-r8a7796", .data = UNIPHIER_SD_CAP_64BIT },
{ .compatible = "socionext,uniphier-sdhc", .data = 0 },
{ /* sentinel */ }
};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Fix CONFIG_SUNXI_GMAC references
On Sun, Aug 6, 2017 at 10:45 AM, Simon Glass wrote: > On 26 July 2017 at 05:26, Dave Prue wrote: >> GMAC Initialization for sun7i targets has been broken since v2017.05-rc3 >> due to the renaming of CONFIG_SUNXI_GMAC to CONFIG_SUN7I_GMAC in Kconfig >> without propogating the name change throughout the code. >> >> Signed-off-by: Dave Prue >> --- >> >> arch/arm/include/asm/arch-sunxi/sys_proto.h | 2 +- >> board/sunxi/Makefile| 2 +- >> include/configs/sunxi-common.h | 2 +- >> scripts/build-whitelist.sh | 2 +- >> scripts/config_whitelist.txt| 2 +- >> 5 files changed, 5 insertions(+), 5 deletions(-) > > Reviewed-by: Simon Glass Reviewed-by: Jagan Teki thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Sinovoip Bananapi M1+ defconfig
On Sat, Jul 8, 2017 at 11:06 AM, wrote: > From aa8cd8708d71ef302e78474af6713477263bdd6f Mon Sep 17 00:00:00 2001 > From: Richard Kojedzinszky > Date: Fri, 18 Nov 2016 19:25:50 +0100 > Subject: [PATCH 2/2] sun20i: added config for Sinovoip Bananapi M1 plus > > According to linux-sunxi.org, the m1 plus is very similar to Lemaker's > Banana Pro, so the config is the very same for this board. > > Signed-off-by: Richard Kojedzinszky > Tested-by: Richard Kojedzinszky > --- > configs/Sinovoip_BPI_M1_plus_defconfig | 26 ++ Update MAINTAINERS file? thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Fix CONFIG_SUNXI_GMAC references
> From: Jagan Teki > Date: Mon, 7 Aug 2017 14:56:58 +0530 > > On Sun, Aug 6, 2017 at 10:45 AM, Simon Glass wrote: > > On 26 July 2017 at 05:26, Dave Prue wrote: > >> GMAC Initialization for sun7i targets has been broken since v2017.05-rc3 > >> due to the renaming of CONFIG_SUNXI_GMAC to CONFIG_SUN7I_GMAC in Kconfig > >> without propogating the name change throughout the code. > >> > >> Signed-off-by: Dave Prue > >> --- > >> > >> arch/arm/include/asm/arch-sunxi/sys_proto.h | 2 +- > >> board/sunxi/Makefile| 2 +- > >> include/configs/sunxi-common.h | 2 +- > >> scripts/build-whitelist.sh | 2 +- > >> scripts/config_whitelist.txt| 2 +- > >> 5 files changed, 5 insertions(+), 5 deletions(-) > > > > Reviewed-by: Simon Glass > > Reviewed-by: Jagan Teki And makes the interface work again under OpenBSD, so: Reviewed-by: Mark Kettenis Tested-by: Mark Kettenis ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Fix CONFIG_SUNXI_GMAC references
Am 07.08.2017 um 11:26 schrieb Jagan Teki: > On Sun, Aug 6, 2017 at 10:45 AM, Simon Glass wrote: >> On 26 July 2017 at 05:26, Dave Prue wrote: >>> GMAC Initialization for sun7i targets has been broken since v2017.05-rc3 "initialization", but more importantly: >>> due to the renaming of CONFIG_SUNXI_GMAC to CONFIG_SUN7I_GMAC in Kconfig >>> without propogating the name change throughout the code. "propagating" please :) Cheers, Andreas >>> >>> Signed-off-by: Dave Prue >>> --- >>> >>> arch/arm/include/asm/arch-sunxi/sys_proto.h | 2 +- >>> board/sunxi/Makefile| 2 +- >>> include/configs/sunxi-common.h | 2 +- >>> scripts/build-whitelist.sh | 2 +- >>> scripts/config_whitelist.txt| 2 +- >>> 5 files changed, 5 insertions(+), 5 deletions(-) >> >> Reviewed-by: Simon Glass > > Reviewed-by: Jagan Teki > > thanks! -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] regulator: pbias: Add PBIAS regulator for proper voltage switching on MMC1
In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1
IO cells. Without this bias voltage these I/O cells can not function
properly. The PBIAS cell is controlled by software.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
Reviewed-by: Simon Glass
---
Hi Jaehoon,
Here is the patch for the PBIAS regulator. I modified the KConfig to select
the REGMAP and SYSCON features as you suggested.
Thanks.
JJ
changes since v2:
- automatically select REGMAP and SYSCON if PBIAS is selected.
changes since v1:
- automatically select the PBIAS driver if DM_REGULATOR, DM_MMC and
MMC_OMAP_HS are set
- use the dev_read_*() API to access the DT
drivers/mmc/Kconfig | 1 +
drivers/power/regulator/Kconfig | 13 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/pbias_regulator.c | 302 ++
4 files changed, 317 insertions(+)
create mode 100644 drivers/power/regulator/pbias_regulator.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 588e118..63e1122 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -158,6 +158,7 @@ config MMC_PCI
config MMC_OMAP_HS
bool "TI OMAP High Speed Multimedia Card Interface support"
select DM_MMC_OPS if DM_MMC
+ select DM_REGULATOR_PBIAS if DM_MMC && DM_REGULATOR
help
This selects the TI OMAP High Speed Multimedia card Interface.
If you have an omap2plus board with a Multimedia Card slot,
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index f213487..cb5ea08 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -142,6 +142,19 @@ config DM_REGULATOR_PALMAS
features for REGULATOR PALMAS and the family of PALMAS PMICs.
The driver implements get/set api for: value and enable.
+config DM_REGULATOR_PBIAS
+ bool "Enable driver for PBIAS regulator"
+ depends on DM_REGULATOR
+ select REGMAP
+ select SYSCON
+ ---help---
+ This enables implementation of driver-model regulator uclass
+ features for pseudo-regulator PBIAS found in the OMAP SOCs.
+ This pseudo-regulator is used to provide a BIAS voltage to MMC1
+ signal pads and must be configured properly during a voltage switch.
+ Voltage switching is required by some operating modes of SDcards and
+ eMMC.
+
config DM_REGULATOR_LP873X
bool "Enable driver for LP873X PMIC regulators"
depends on PMIC_LP873X
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index ce14d08..75d611a 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -17,5 +17,6 @@ obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_PALMAS) += palmas_regulator.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_PBIAS) += pbias_regulator.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP873X) += lp873x_regulator.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP87565) += lp87565_regulator.o
diff --git a/drivers/power/regulator/pbias_regulator.c
b/drivers/power/regulator/pbias_regulator.c
new file mode 100644
index 000..303eca9
--- /dev/null
+++ b/drivers/power/regulator/pbias_regulator.c
@@ -0,0 +1,302 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Jean-Jacques Hiblot
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct pbias_reg_info {
+ u32 enable;
+ u32 enable_mask;
+ u32 disable_val;
+ u32 vmode;
+ unsigned int enable_time;
+ char *name;
+};
+
+struct pbias_priv {
+ struct regmap *regmap;
+ int offset;
+};
+
+static const struct pmic_child_info pmic_children_info[] = {
+ { .prefix = "pbias", .driver = "pbias_regulator"},
+ { },
+};
+
+static int pbias_write(struct udevice *dev, uint reg, const uint8_t *buff,
+ int len)
+{
+ struct pbias_priv *priv = dev_get_priv(dev);
+ uint32_t val = *(uint32_t *)buff;
+
+ if (len != 4)
+ return -EINVAL;
+
+ return regmap_write(priv->regmap, priv->offset, val);
+}
+
+static int pbias_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+ struct pbias_priv *priv = dev_get_priv(dev);
+
+ if (len != 4)
+ return -EINVAL;
+
+ return regmap_read(priv->regmap, priv->offset, (uint32_t *)buff);
+}
+
+static int pbias_ofdata_to_platdata(struct udevice *dev)
+{
+ struct pbias_priv *priv = dev_get_priv(dev);
+ struct udevice *syscon;
+ struct regmap *regmap;
+ struct resource res;
+ int err;
+
+ err = uclass_get_device_by_phandle(UCLASS_SYSCON, dev,
+
Re: [U-Boot] [PATCH] sunxi: Fix CONFIG_SUNXI_GMAC references
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de > X-Spam-Level: > X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable > autolearn_force=no version=3.4.0 > Date: Mon, 7 Aug 2017 11:35:52 +0200 (CEST) > From: Mark Kettenis > Cc: albert.u.b...@aribaud.net, jernej.skra...@siol.net, u-boot@lists.denx.de, > andre.przyw...@arm.com, hdego...@redhat.com, icen...@aosc.xyz, > maxime.rip...@free-electrons.com, ja...@openedev.com, afaer...@suse.de > Sender: "U-Boot" > X-XS4ALL-DNSBL-Checked: mxdrop302.xs4all.net checked 81.169.180.215 against > DNS blacklists > X-CNFS-Analysis: v=2.2 cv=V9A/6qvi c=1 sm=0 tr=0 > a=ONADgqKa62I6zSSZ3CeWOA==:117 a=ONADgqKa62I6zSSZ3CeWOA==:17 > a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=WiVod9pSvdkA:10 > a=pGLkceIS:8 a=cm27Pg_U:8 a=yTmaW2Wv:8 a=8flm3Zim:8 > a=3tcz3bTJ:8 a=YfCOm-Dy:8 a=ulZhkHzn2l8uUku_rLcA:9 a=QEXdDO2ut3YA:10 > a=6kGIvZw6iX1k4Y-7sg4_:22 a=xmb-EsYY8bH0VWELuYED:22 > a=JtT7V0wkIbYGGTrklAfD:22 a=bqseOZt422ZGMqA63K3A:22 > a=4EbjBm0RLgFgoQzmu6QD:22 a=zQLMK8awuJ6_Hvp-_9Ux:22 > X-Virus-Scanned: by XS4ALL Virus Scanner > X-XS4ALL-Spam-Score: -0.5 () RP_MATCHES_RCVD, T_HEADER_FROM_DIFFERENT_DOMAINS > X-XS4ALL-Spam: NO > Envelope-To: mark.kette...@xs4all.nl > X-MIME-Autoconverted: from base64 to 8bit by sibelius.xs4all.nl id > v779cZ2M003524 > > > From: Jagan Teki > > Date: Mon, 7 Aug 2017 14:56:58 +0530 > > > > On Sun, Aug 6, 2017 at 10:45 AM, Simon Glass wrote: > > > On 26 July 2017 at 05:26, Dave Prue wrote: > > >> GMAC Initialization for sun7i targets has been broken since v2017.05-rc3 > > >> due to the renaming of CONFIG_SUNXI_GMAC to CONFIG_SUN7I_GMAC in Kconfig > > >> without propogating the name change throughout the code. > > >> > > >> Signed-off-by: Dave Prue > > >> --- > > >> > > >> arch/arm/include/asm/arch-sunxi/sys_proto.h | 2 +- > > >> board/sunxi/Makefile| 2 +- > > >> include/configs/sunxi-common.h | 2 +- > > >> scripts/build-whitelist.sh | 2 +- > > >> scripts/config_whitelist.txt| 2 +- > > >> 5 files changed, 5 insertions(+), 5 deletions(-) > > > > > > Reviewed-by: Simon Glass > > > > Reviewed-by: Jagan Teki > > And makes the interface work again under OpenBSD, so: > > Reviewed-by: Mark Kettenis > Tested-by: Mark Kettenis Actually the scripts/build-whitelist.sh change isn't right. It should also either be dropped or SUNXI_GMAC on the line above should be changed into SUN7I_GMAC. It's in a comment, but with the change the comment doesn't make sense anymore ;). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/10] mips: bmips: add SPI support
Hi Jagan, Am 07.08.2017 um 10:35 schrieb Jagan Teki: > Hi, > > On Sun, Jul 30, 2017 at 5:43 PM, Álvaro Fernández Rojas > wrote: >> BCM63xx SPI controller is a bit tricky since it doesn't allow keeping CS >> active between transfers, so I had to modify the spi_flash driver in order >> to allow limiting reads. >> >> v5: Introduce changes suggested by Jagan Teki: >> - Use long structs for registers >> v4: Introduce changes suggested by Jagan Teki: >> - Add data for each HW controller instead of having two separate configs. >> v3: Fix bug introduced in v2: sizeof(cmd) vs len. >> Also rename BCM6338 SPI driver to BCM6348 SPI since BCM6338 is a stripped >> down version of the BCM6348. >> Switch to devfdt_get_addr_size_index(). >> v2: Introduce changes requested by Simon Glass: >> - Always include command bytes when determining max write size. >> Also move SPI aliases from .dts to .dtsi files. > > Did you sent the latest changes? I couldn't find it on patchwork even > with status "any" > > thanks! > someone assigned all patches to me. I reassigned them to you. Please apply them, thanks. -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/9] dts: renamed FIT_EMBED to MULTI_DTB_FIT and moved it to the dts Kconfig
CONFIG_FIT_EMBED might be confused with CONFIG_OF_EMBED, rename it
MULTI_DTB_FIT as it is able to get a DTB from a FIT image containing
multiple DTBs. Also move the option to the Kconfig dedicated to the DTS
options and create a README for this feature.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
Reviewed-by: Simon Glass
---
no change since v3
Makefile | 2 +-
board/ti/ks2_evm/board_k2e.c | 2 +-
board/ti/ks2_evm/board_k2g.c | 2 +-
board/ti/ks2_evm/board_k2hk.c | 2 +-
board/ti/ks2_evm/board_k2l.c | 2 +-
common/Kconfig| 16
common/Makefile | 2 +-
configs/k2e_evm_defconfig | 2 +-
configs/k2g_evm_defconfig | 2 +-
configs/k2hk_evm_defconfig| 2 +-
configs/k2l_evm_defconfig | 2 +-
doc/README.multi-dtb-fit | 9 +
dts/Kconfig | 20 +++-
lib/fdtdec.c | 2 +-
14 files changed, 39 insertions(+), 28 deletions(-)
create mode 100644 doc/README.multi-dtb-fit
diff --git a/Makefile b/Makefile
index 50a002e..d5869e1 100644
--- a/Makefile
+++ b/Makefile
@@ -876,7 +876,7 @@ dts/dt.dtb: checkdtc u-boot
quiet_cmd_copy = COPY$@
cmd_copy = cp $< $@
-ifeq ($(CONFIG_FIT_EMBED),y)
+ifeq ($(CONFIG_MULTI_DTB_FIT),y)
fit-dtb.blob: dts/dt.dtb FORCE
$(call if_changed,mkimage)
diff --git a/board/ti/ks2_evm/board_k2e.c b/board/ti/ks2_evm/board_k2e.c
index 266a66b..6c77d91 100644
--- a/board/ti/ks2_evm/board_k2e.c
+++ b/board/ti/ks2_evm/board_k2e.c
@@ -166,7 +166,7 @@ int get_num_eth_ports(void)
}
#endif
-#if defined(CONFIG_FIT_EMBED)
+#if defined(CONFIG_MULTI_DTB_FIT)
int board_fit_config_name_match(const char *name)
{
if (!strcmp(name, "keystone-k2e-evm"))
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 2160576..b1dd606 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -216,7 +216,7 @@ int board_mmc_init(bd_t *bis)
}
#endif
-#if defined(CONFIG_FIT_EMBED)
+#if defined(CONFIG_MULTI_DTB_FIT)
int board_fit_config_name_match(const char *name)
{
bool eeprom_read = board_ti_was_eeprom_read();
diff --git a/board/ti/ks2_evm/board_k2hk.c b/board/ti/ks2_evm/board_k2hk.c
index c733099..e99e635 100644
--- a/board/ti/ks2_evm/board_k2hk.c
+++ b/board/ti/ks2_evm/board_k2hk.c
@@ -150,7 +150,7 @@ int board_early_init_f(void)
}
#endif
-#if defined(CONFIG_FIT_EMBED)
+#if defined(CONFIG_MULTI_DTB_FIT)
int board_fit_config_name_match(const char *name)
{
if (!strcmp(name, "keystone-k2hk-evm"))
diff --git a/board/ti/ks2_evm/board_k2l.c b/board/ti/ks2_evm/board_k2l.c
index 166367b..c65f331 100644
--- a/board/ti/ks2_evm/board_k2l.c
+++ b/board/ti/ks2_evm/board_k2l.c
@@ -138,7 +138,7 @@ int board_early_init_f(void)
}
#endif
-#if defined(CONFIG_FIT_EMBED)
+#if defined(CONFIG_MULTI_DTB_FIT)
int board_fit_config_name_match(const char *name)
{
if (!strcmp(name, "keystone-k2l-evm"))
diff --git a/common/Kconfig b/common/Kconfig
index 0983891..3c7e3a2 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -810,22 +810,6 @@ config SYS_STDIO_DEREGISTER
endmenu
-config DTB_RESELECT
- bool "Support swapping dtbs at a later point in boot"
- depends on FIT_EMBED
- help
- It is possible during initial boot you may need to use a generic
- dtb until you can fully determine the board your running on. This
- config allows boards to implement a function at a later point
- during boot to switch to the "correct" dtb.
-
-config FIT_EMBED
- bool "Support a FIT image embedded in the U-boot image"
- help
- This option provides hooks to allow U-boot to parse an
- appended FIT image and enable board specific code to then select
- the correct DTB to be used.
-
config DEFAULT_FDT_FILE
string "Default fdt file"
help
diff --git a/common/Makefile b/common/Makefile
index 60681c8..3bff64f 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -148,7 +148,7 @@ obj-y += image.o
obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
obj-$(CONFIG_$(SPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_)FIT) += image-fit.o
-obj-$(CONFIG_FIT_EMBED) += boot_fit.o common_fit.o
+obj-$(CONFIG_$(SPL_)MULTI_DTB_FIT) += boot_fit.o common_fit.o
obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += image-sig.o
obj-$(CONFIG_IO_TRACE) += iotrace.o
obj-y += memsize.o
diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig
index b3763e4..291b377 100644
--- a/configs/k2e_evm_defconfig
+++ b/configs/k2e_evm_defconfig
@@ -13,7 +13,7 @@ CONFIG_OF_BOARD_SETUP=y
CONFIG_ENV_IS_IN_NAND=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_DTB_RESELECT=y
-CONFIG_FIT_EMBED=y
+CONFIG_MULTI_DTB_FIT=y
CONFIG_VERSION_VARIABLE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL=y
diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index 1eed605..3ac5905 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_
[U-Boot] [PATCH v4 3/9] fit: fixed bug in locate_dtb_in_fit()
If the dtb is the first data of the FIT, the its offset is 0x0. Change the test to '<' instead of '<=' Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini Reviewed-by: Simon Glass --- no change since v3 common/boot_fit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/boot_fit.c b/common/boot_fit.c index 3767c63..8e81745 100644 --- a/common/boot_fit.c +++ b/common/boot_fit.c @@ -73,7 +73,7 @@ void *locate_dtb_in_fit(const void *fit) ret = fdt_offset(fit); - if (ret <= 0) + if (ret < 0) return NULL; else return (void *)fit+size+ret; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/9] lzo: add a function to check the validity of the header
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
Reviewed-by: Simon Glass
---
no change since v3
include/linux/lzo.h| 3 +++
lib/lzo/lzo1x_decompress.c | 21 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/include/linux/lzo.h b/include/linux/lzo.h
index 88687fa..8981d04 100644
--- a/include/linux/lzo.h
+++ b/include/linux/lzo.h
@@ -31,6 +31,9 @@ int lzo1x_decompress_safe(const unsigned char *src, size_t
src_len,
int lzop_decompress(const unsigned char *src, size_t src_len,
unsigned char *dst, size_t *dst_len);
+/* check if the header is valid (based on magic numbers) */
+bool lzop_is_valid_header(const unsigned char *src);
+
/*
* Return values (< 0 = Error)
*/
diff --git a/lib/lzo/lzo1x_decompress.c b/lib/lzo/lzo1x_decompress.c
index ccc90b8..65fef0b 100644
--- a/lib/lzo/lzo1x_decompress.c
+++ b/lib/lzo/lzo1x_decompress.c
@@ -30,16 +30,29 @@ static const unsigned char lzop_magic[] = {
#define HEADER_HAS_FILTER 0x0800L
-static inline const unsigned char *parse_header(const unsigned char *src)
+
+bool lzop_is_valid_header(const unsigned char *src)
{
- u16 version;
int i;
-
/* read magic: 9 first bytes */
for (i = 0; i < ARRAY_SIZE(lzop_magic); i++) {
if (*src++ != lzop_magic[i])
- return NULL;
+ return false;
}
+ return true;
+}
+
+static inline const unsigned char *parse_header(const unsigned char *src)
+{
+ u16 version;
+ int i;
+
+ if (!lzop_is_valid_header(src))
+ return NULL;
+
+ /* skip header */
+ src += 9;
+
/* get version (2bytes), skip library version (2),
* 'need to be extracted' version (2) and
* method (1) */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/9] fit: use 'const' for the input of fdt_offset() and locate_dtb_in_fit()
Those 2 functions don't modify their input, we can mark it const.
This prevents compilation warnings when they are provided const input.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
Reviewed-by: Simon Glass
---
change since v3: updated the description of locate_dtb_in_fit()
common/boot_fit.c | 4 ++--
include/boot_fit.h | 9 +++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/common/boot_fit.c b/common/boot_fit.c
index 51440a6..3767c63 100644
--- a/common/boot_fit.c
+++ b/common/boot_fit.c
@@ -13,7 +13,7 @@
#include
#include
-int fdt_offset(void *fit)
+static int fdt_offset(const void *fit)
{
int images, node, fdt_len, fdt_node, fdt_offset;
const char *fdt_name;
@@ -55,7 +55,7 @@ int fdt_offset(void *fit)
return fdt_offset;
}
-void *locate_dtb_in_fit(void *fit)
+void *locate_dtb_in_fit(const void *fit)
{
struct image_header *header;
int size;
diff --git a/include/boot_fit.h b/include/boot_fit.h
index b7d2462..e16ae5b 100644
--- a/include/boot_fit.h
+++ b/include/boot_fit.h
@@ -5,5 +5,10 @@
* SPDX-License-Identifier: GPL-2.0+
*/
-int fdt_offset(void *fit);
-void *locate_dtb_in_fit(void *fit);
+/**
+ * locate_dtb_in_fit - Find a DTB matching the board in a FIT image
+ * @fit: pointer to the FIT image
+ *
+ * @return a pointer to a matching DTB blob if found, NULL otherwise
+ */
+void *locate_dtb_in_fit(const void *fit);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/9] fit: If no matching config is found in fit_find_config_node(), use the default one
If board_fit_config_name_match() doesn't match any configuration node,
then use the default one (if provided).
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
Reviewed-by: Simon Glass
---
change since v3: fixed spelling mistakes reported by Simon G.
common/common_fit.c | 20
include/image.h | 13 +
2 files changed, 33 insertions(+)
diff --git a/common/common_fit.c b/common/common_fit.c
index 5f5f3f9..85b33d8 100644
--- a/common/common_fit.c
+++ b/common/common_fit.c
@@ -32,6 +32,9 @@ int fit_find_config_node(const void *fdt)
{
const char *name;
int conf, node, len;
+ const char *dflt_conf_name;
+ const char *dflt_conf_desc = NULL;
+ int dflt_conf_node = -ENOENT;
conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
if (conf < 0) {
@@ -39,6 +42,9 @@ int fit_find_config_node(const void *fdt)
conf);
return -EINVAL;
}
+
+ dflt_conf_name = fdt_getprop(fdt, conf, "default", &len);
+
for (node = fdt_first_subnode(fdt, conf);
node >= 0;
node = fdt_next_subnode(fdt, node)) {
@@ -50,6 +56,15 @@ int fit_find_config_node(const void *fdt)
#endif
return -EINVAL;
}
+
+ if (dflt_conf_name) {
+ const char *node_name = fdt_get_name(fdt, node, NULL);
+ if (strcmp(dflt_conf_name, node_name) == 0) {
+ dflt_conf_node = node;
+ dflt_conf_desc = name;
+ }
+ }
+
if (board_fit_config_name_match(name))
continue;
@@ -58,5 +73,10 @@ int fit_find_config_node(const void *fdt)
return node;
}
+ if (dflt_conf_node != -ENOENT) {
+ debug("Selecting default config '%s'", dflt_conf_desc);
+ return dflt_conf_node;
+ }
+
return -ENOENT;
}
diff --git a/include/image.h b/include/image.h
index c6f1513..d52d112 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1273,6 +1273,19 @@ void board_fit_image_post_process(void **p_image, size_t
*p_size);
#define FDT_ERROR ((ulong)(-1))
ulong fdt_getprop_u32(const void *fdt, int node, const char *prop);
+
+/**
+ * fit_find_config_node() - Find the node for the best DTB in a FIT image
+ *
+ * A FIT image contains one or more DTBs. This function parses the
+ * configurations described in the FIT images and returns the node of
+ * the first matching DTB. To check if a DTB matches a board, this function
+ * calls board_fit_config_name_match(). If no matching DTB is found, it returns
+ * the node described by the default configuration if it exists.
+ *
+ * @fdt: pointer to flat device tree
+ * @return the node if found, -ve otherwise
+ */
int fit_find_config_node(const void *fdt);
/**
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 6/9] gzip: add a function to parse the header
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tom Rini
Reviewed-by: Simon Glass
---
no change since v3
include/common.h | 1 +
lib/gunzip.c | 15 ---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/common.h b/include/common.h
index c8fb277..8678275 100644
--- a/include/common.h
+++ b/include/common.h
@@ -568,6 +568,7 @@ ulong usec2ticks(unsigned long usec);
ulong ticks2usec(unsigned long ticks);
/* lib/gunzip.c */
+int gzip_parse_header(const unsigned char *src, unsigned long len);
int gunzip(void *, int, unsigned char *, unsigned long *);
int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
int stoponerr, int offset);
diff --git a/lib/gunzip.c b/lib/gunzip.c
index 832b306..adb86c7 100644
--- a/lib/gunzip.c
+++ b/lib/gunzip.c
@@ -42,7 +42,7 @@ void gzfree(void *x, void *addr, unsigned nb)
free (addr);
}
-int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp)
+int gzip_parse_header(const unsigned char *src, unsigned long len)
{
int i, flags;
@@ -63,12 +63,21 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
;
if ((flags & HEAD_CRC) != 0)
i += 2;
- if (i >= *lenp) {
+ if (i >= len) {
puts ("Error: gunzip out of data in header\n");
return (-1);
}
+ return i;
+}
+
+int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp)
+{
+ int offset = gzip_parse_header(src, *lenp);
+
+ if (offset < 0)
+ return offset;
- return zunzip(dst, dstlen, src, lenp, 1, i);
+ return zunzip(dst, dstlen, src, lenp, 1, offset);
}
#ifdef CONFIG_CMD_UNZIP
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 7/9] lib: allow building lzo and gunzip for the SPL
Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini Reviewed-by: Simon Glass --- no change since v3 lib/Kconfig | 17 - lib/Makefile | 6 +++--- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/lib/Kconfig b/lib/Kconfig index 2f5a210..5b90a91 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -159,7 +159,22 @@ config LZMA config LZO bool "Enable LZO decompression support" help - This enables support for LZO compression algorithm.r + This enables support for LZO compression algorithm. + +config SPL_LZO + bool "Enable LZO decompression support in SPL" + help + This enables support for LZO compression algorithm in the SPL. + +config SPL_GZIP + bool "Enable GZIP decompression support in SPL" + select SPL_ZLIB + help + This enables support for GZIP compression algorithm in the SPL. + +config SPL_ZLIB + bool + endmenu config ERRNO_STR diff --git a/lib/Makefile b/lib/Makefile index eacc7d6..21cd4e2 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -4,14 +4,15 @@ # # SPDX-License-Identifier: GPL-2.0+ # +obj-$(CONFIG_$(SPL_)ZLIB) += zlib/ +obj-$(CONFIG_$(SPL_)GZIP) += gunzip.o +obj-$(CONFIG_$(SPL_)LZO) += lzo/ ifndef CONFIG_SPL_BUILD obj-$(CONFIG_EFI) += efi/ obj-$(CONFIG_EFI_LOADER) += efi_loader/ obj-$(CONFIG_LZMA) += lzma/ -obj-$(CONFIG_LZO) += lzo/ -obj-$(CONFIG_ZLIB) += zlib/ obj-$(CONFIG_BZIP2) += bzip2/ obj-$(CONFIG_TIZEN) += tizen/ obj-$(CONFIG_FIT) += libfdt/ @@ -26,7 +27,6 @@ obj-y += crc16.o obj-$(CONFIG_ERRNO_STR) += errno_str.o obj-$(CONFIG_FIT) += fdtdec_common.o obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o -obj-$(CONFIG_GZIP) += gunzip.o obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o obj-y += initcall.o -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 8/9] spl: dm: Make it possible for the SPL to pick its own DTB from a FIT
u-boot can be embedded within a FIT image with multiple DTBs. It then
selects at run-time which one is best suited for the platform.
Use the same principle here for the SPL: put the DTBs in a FIT image,
compress it (LZO, GZIP, or no compression) and append it at the end of the
SPL.
Signed-off-by: Jean-Jacques Hiblot
---
change since v3: updated the help in Kconfig to take in account commit f1896c
("spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN")
doc/README.multi-dtb-fit | 44 +++--
dts/Kconfig | 83 ++
lib/fdtdec.c | 85 +++-
scripts/Makefile.spl | 35 +++-
4 files changed, 235 insertions(+), 12 deletions(-)
diff --git a/doc/README.multi-dtb-fit b/doc/README.multi-dtb-fit
index d182d4e..5e593c8 100644
--- a/doc/README.multi-dtb-fit
+++ b/doc/README.multi-dtb-fit
@@ -1,9 +1,49 @@
MULTI DTB FIT
-The purpose of this feature is to enable u-boot to select its DTB from a FIT
-image appended at the end of the binary.
+The purpose of this feature is to enable u-boot or the SPL to select its DTB
+from a FIT image appended at the end of the binary.
+It comes in two flavor: u-boot (CONFIG_MULTI_DTB_FIT) and SPL
+(CONFIG_SPL_MULTI_DTB_FIT)
+u-boot flavor:
Usually the DTB is selected by the SPL and passed down to u-boot. But some
platforms don't use the SPL. In this case MULTI_DTB_FIT can used to provide
u-boot with a choice of DTBs. The FIT image is automatically image at the end
of the compilation and appended to u-boot.bin
+
+
+
+SPL flavor:
+the SPL uses only a small subset of the DTB and it usually depends more
+on the SOC than on the board. So it's usually fine to include a DTB in the
+SPL that doesn't exactly match the board. There are howerver somes cases
+where it's not possible. In the later case, in order to support multiple
+boards (or board revisions) with the same SPL binary, SPL_MULTI_DTB_FIT
+can be used. The list of DTB is given in CONFIG_SPL_OF_LIST which by default
+is the same list as CONFIG_OF_LIST
+The FIT image is automatically generated at the end of the compilation,
+compressed and appended to u-boot-spl.bin
+
+The impact of this option is relatively small. Here are some numbers measured
+for a TI DRA7 platform:
+
+ ++
+ | Size|delta |boot-time| delta |
+ | (bytes) |(bytes) |(ms) | (ms) |
++---+
+| reference| 120185 | | 1331 ||
++---+
+| feature | | | ||
+| deactiVated | 120185 | 0 | 1330 | -1|
++---+
+| 1 DTB LZO | 120208 | 23 | 1331 | 0 |
++---+
+| 4 DTB LZO | 120810 | 625| 1336 | 5 |
++---+
+| 4 DTB LZO | | | ||
+| no malloc| 120746 | 561| 1343 | 12|
++---+
+| 4 DTB GZIP | 128552 | 8367 | 1353 | 22|
++---+
+| 4 DTB No comp | 132352 | 12167 | 1351 | 20|
++--+--+--+-++
diff --git a/dts/Kconfig b/dts/Kconfig
index c78438a..ec91a71 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -118,6 +118,89 @@ config MULTI_DTB_FIT
the correct DTB to be used. Use this if you need to support
multiple DTBs but don't use the SPL.
+
+config SPL_MULTI_DTB_FIT
+ depends on SPL_LOAD_FIT && SPL_OF_CONTROL && !SPL_OF_PLATDATA
+ bool "support embedding several DTBs in a FIT image for the SPL"
+ help
+ This option provides the SPL with the ability to select its own
+ DTB at runtime from an appended FIT image containing several DTBs.
+ This allows using the same SPL binary on multiple platforms.
+ The primary purpose is to handle different versions of
+ the same platform without tweaking the platform code if the
+ differences can be expressed in the DTBs (common examples are: bus
+ capabilities, pad configurations).
+
+config SPL_OF_LIST
+ string "List of device tree files to include for DT control in SPL"
+ depends on SPL_MULTI_DTB_FIT
+ default OF_LIST
+ help
+ This option specifies a list of device tree files to use for DT
+ control in the SPL. These will be packaged into a FIT. At run-time,
+ the SPL will select the correct DT t
[U-Boot] [PATCH v4 9/9] omap: detect board before spl_early_init()
In order to be able to select the right DTB, we need to have identified the board before spl_early_init() is called. Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini Reviewed-by: Simon Glass --- no change since v3 arch/arm/mach-omap2/hwinit-common.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/hwinit-common.c b/arch/arm/mach-omap2/hwinit-common.c index 7324d52..56890a0 100644 --- a/arch/arm/mach-omap2/hwinit-common.c +++ b/arch/arm/mach-omap2/hwinit-common.c @@ -165,9 +165,11 @@ void early_system_init(void) * to prevent overwrites. */ save_omap_boot_params(); - spl_early_init(); #endif do_board_detect(); +#ifdef CONFIG_SPL_BUILD + spl_early_init(); +#endif vcores_init(); #ifdef CONFIG_DEBUG_UART_OMAP debug_uart_init(); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/9] spl: dm: Make it possible for the SPL to pick its own DTB from a FIT
Following the RFC, here is the series implementing the mechanism in a cleaner
way. The idea is that the SPL may take advantage of selecting its DTB from a
pool of available DTBs. To do that several DTBs are embedded in a compressed
FIT image appended at the end of the SPL. The patch is done in such way that
this mechanism can easily be extended to other ways of loading the DTBs.
Here are some numbers:
++
| Size|delta |boot-time| delta |
| (bytes) |(bytes) |(ms) | (ms) |
+---+
| reference| 120185 | | 1331 ||
+---+
| feature | | | ||
| deactiVated | 120185 | 0 | 1330 | -1|
+---+
| 1 DTB LZO | 120208 | 23 | 1331 | 0 |
+---+
| 4 DTB LZO | 120810 | 625| 1336 | 5 |
+---+
| 4 DTB LZO | | | ||
| no malloc| 120746 | 561| 1343 | 12|
+---+
| 4 DTB GZIP | 128552 | 8367 | 1353 | 22|
+---+
| 4 DTB No comp | 132352 | 12167 | 1351 | 20|
+--+--+--+-++
changes since v3:
- Added reviewed-by tags
- Fixed nits and spelling mistakes reported by Simon G.
- updated the help in Kconfig to take in account commit f1896c ("spl: make SPL
and normal u-boot stage use independent SYS_MALLOC_F_LEN")
changes since v2:
- rebased on u-boot/master
- improved help in Kconfig for the compression options in SPL
- improved commit message for patch #1
- Added some comments to describe locate_dtb_in_fit() and
fit_find_config_node()
- Added a description of the mecanism in a README
changes since v1:
- improved help in Kconfig for the SPL_MULTI_DTB_FIT option
- Added "reviewed-by" tags
changes since RFC:
- split the RFC patch in several patches.
- leverage work from Cooper Jr., Franklin (CONFIG_FIT_EMBED) as a big part
of the code is similar. Rename CONFIG_FIT_EMBED as CONFIG_MULTI_DTB_FIT
to prevent confusion with CONFIG_OF_EMBED.
- use the default configuration if no match is provided by
board_fit_config_name_match(). note that this is generic not just for this
feature.
- provide an option to not use dynamic memory allocation.
- added a patch related to board detection on omap that's required to take
advantage of this feature.
Jean-Jacques Hiblot (9):
dts: renamed FIT_EMBED to MULTI_DTB_FIT and moved it to the dts
Kconfig
fit: use 'const' for the input of fdt_offset() and locate_dtb_in_fit()
fit: fixed bug in locate_dtb_in_fit()
fit: If no matching config is found in fit_find_config_node(), use the
default one
lzo: add a function to check the validity of the header
gzip: add a function to parse the header
lib: allow building lzo and gunzip for the SPL
spl: dm: Make it possible for the SPL to pick its own DTB from a FIT
omap: detect board before spl_early_init()
Makefile| 2 +-
arch/arm/mach-omap2/hwinit-common.c | 4 +-
board/ti/ks2_evm/board_k2e.c| 2 +-
board/ti/ks2_evm/board_k2g.c| 2 +-
board/ti/ks2_evm/board_k2hk.c | 2 +-
board/ti/ks2_evm/board_k2l.c| 2 +-
common/Kconfig | 16 --
common/Makefile | 2 +-
common/boot_fit.c | 6 +--
common/common_fit.c | 20 +++
configs/k2e_evm_defconfig | 2 +-
configs/k2g_evm_defconfig | 2 +-
configs/k2hk_evm_defconfig | 2 +-
configs/k2l_evm_defconfig | 2 +-
doc/README.multi-dtb-fit| 49 +
dts/Kconfig | 103 +++-
include/boot_fit.h | 9 +++-
include/common.h| 1 +
include/image.h | 13 +
include/linux/lzo.h | 3 ++
lib/Kconfig | 17 +-
lib/Makefile| 6 +--
lib/fdtdec.c| 85 +
lib/gunzip.c| 15 --
lib/lzo/lzo1x_decompress.c | 21 ++--
scripts/Makefile.spl| 35 +++-
26 files changed, 369 insertions(+), 54 deletions(-)
create mode 100644 doc/README.multi-dtb-fit
--
1.9.1
___
U-Boot mailing list
[U-Boot] spi flash env and driver model
Hi,
I'm looking at a problem on the db-88f6820-amc board (which has it's
env on spi flash). Somewhere in the init sequence we get a crash.
git bisect leads me to commit 8fee8845e7 ("enf_sf: reuse
setup_flash_device instead of open coding it") but I don't think
that's actually the problem. The real problem seems to be the way
setup_spi_device() relies on the speed to come from the device-tree.
Even when I specify a speed for the spi-flash in the device tree it
doesn't seem to stick. The only thing that seems to work is restoring
the CONFIG_ENV_SPI_MAX_HZ in the DM_SPI_FLASH case.
I can submit that as a patch but it seems contrary to the intentions
of commit 96907c0fe5 ("dm: spi: Read default speed and mode values
from DT").
Does anyone have any thoughts as to where to go with this?
Thanks,
Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] spl: moveconfig: remove SPL_LDSCRIPT definitions for header-files
> With the hierarchical defaults set up, we remove these from the header > files. To do so, I've run moveconfig on SPL_LDSCRIPT and this commits > the changes. > > Signed-off-by: Philipp Tomsich > Reviewed-by: Simon Glass > --- > > include/configs/am335x_evm.h | 2 -- > include/configs/am335x_igep003x.h | 1 - > include/configs/am335x_shc.h | 2 -- > include/configs/am335x_sl50.h | 2 -- > include/configs/am3517_crane.h | 1 - > include/configs/am3517_evm.h | 1 - > include/configs/am43xx_evm.h | 2 -- > include/configs/apf27.h| 1 - > include/configs/at91sam9m10g45ek.h | 1 - > include/configs/at91sam9n12ek.h| 1 - > include/configs/at91sam9x5ek.h | 1 - > include/configs/baltos.h | 2 -- > include/configs/bav335x.h | 2 -- > include/configs/bur_am335x_common.h| 1 - > include/configs/chiliboard.h | 2 -- > include/configs/cm_t335.h | 1 - > include/configs/cm_t35.h | 1 - > include/configs/cm_t43.h | 2 -- > include/configs/da850evm.h | 1 - > include/configs/edminiv2.h | 1 - > include/configs/exynos5-common.h | 1 - > include/configs/imx6_spl.h | 1 - > include/configs/ipam390.h | 1 - > include/configs/kc1.h | 2 -- > include/configs/ls1021aiot.h | 1 - > include/configs/ls1021aqds.h | 2 -- > include/configs/ls1021atwr.h | 1 - > include/configs/ls1043a_common.h | 2 -- > include/configs/ls1046a_common.h | 2 -- > include/configs/ls2080a_common.h | 1 - > include/configs/ma5d4evk.h | 1 - > include/configs/mcx.h | 1 - > include/configs/microblaze-generic.h | 2 -- > include/configs/mx31pdk.h | 1 - > include/configs/mxs.h | 1 - > include/configs/omap3_evm.h| 1 - > include/configs/omapl138_lcdk.h| 1 - > include/configs/origen.h | 1 - > include/configs/pcm051.h | 2 -- > include/configs/pengwyn.h | 2 -- > include/configs/pepper.h | 1 - > include/configs/picosam9g45.h | 1 - > include/configs/sama5d2_xplained.h | 1 - > include/configs/sama5d3_xplained.h | 1 - > include/configs/sama5d3xek.h | 1 - > include/configs/sama5d4_xplained.h | 1 - > include/configs/sama5d4ek.h| 1 - > include/configs/siemens-am33x-common.h | 2 -- > include/configs/smartweb.h | 1 - > include/configs/smdkv310.h | 1 - > include/configs/sniper.h | 2 -- > include/configs/sunxi-common.h | 4 > include/configs/tam3517-common.h | 1 - > include/configs/tao3530.h | 1 - > include/configs/ti814x_evm.h | 1 - > include/configs/ti816x_evm.h | 2 -- > include/configs/ti_omap3_common.h | 1 - > include/configs/ti_omap4_common.h | 1 - > include/configs/ti_omap5_common.h | 1 - > include/configs/tricorder.h| 1 - > include/configs/woodburn_sd.h | 1 - > include/configs/x600.h | 1 - > include/configs/zynq-common.h | 2 -- > 63 files changed, 85 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove STM32F1 support ?
On Sat, Aug 5, 2017 at 11:35 AM, Tom Rini wrote: > On Fri, Aug 04, 2017 at 04:05:58PM +, Patrice CHOTARD wrote: >> Hi Matt, Kamil >> >> I currently doing some work on STM32 SoCs on U-boot, more >> precisely code factorization between STYM32F4, STM32F7 and STM32H7 >> >> I noticed you added STM32F1 SoCs support few years ago : >> >> 0144caf22ce6acd5c gpio: stm32: add stm32f1 support >> 2d18ef2364fd3561a ARMv7M: add STM32F1 support >> >> But neither STM32F1 dedicated defconfig nor board was associated to >> these commits. >> >> In order to facilitate the cleaning work i am currently doing, can i >> removed STM32F1 support ? (ie all files located in >> arch/arm/mach-stm32/stm32f1 and in arch/arm/include/asm/arch-stm32f1) > > I know for Matt's side, a few more changes were needed in some of the > board code, and then the particular project we were working on wrapped > up, and he's moved on to other things for fun-time projects. Unless > Kamil wants to step up and fix / clean-up STM32F1 stuff as needed for > your clean-ups, yes, lets go with removal. Thanks! Agreed, works for me. If I have time again for STM32F1 I can always resubmit the whole thing. Thanks, Matt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: LocateHandle should return EFI_NOT_FOUND if none found
On 08/06/2017 06:23 PM, Rob Clark wrote:
> Spotted this debugging OpenBSD's bootloader in qemu. (Wouldn't really
> fix anything, the problem was not having any disks, but we should
> probably return the correct error code.)
>
> Signed-off-by: Rob Clark
> ---
> lib/efi_loader/efi_boottime.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 5ff2d2d4b0..ada119325c 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -643,6 +643,9 @@ static efi_status_t EFIAPI efi_locate_handle(
> }
>
> *buffer_size = size;
> + if (size == 0)
> + return EFI_NOT_FOUND;
> +
> return EFI_SUCCESS;
> }
>
>
Thanks for spotting this.
We can do the test earlier, if we move
*buffer_size = size;
to another line.
test:
...
size += sizeof(void*);
}
}
if (*buffer_size < size) {
*buffer_size = size;
return EFI_BUFFER_TOO_SMALL;
}
*buffer_size = size;
if (size == 0)
return EFI_NOT_FOUND;
/* Then fill the array */
...
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: disable alignment fault checking with EFI_LOADER
Device-path structures in UEFI are only byte aligned, which can result in unaligned access faults (either in u-boot or the efi payload which is loaded). From the UEFI spec (sect 10.3.1 in UEFI spec v2.7): A Device Path is a series of generic Device Path nodes. The first Device Path node starts at byte offset zero of the Device Path. The next Device Path node starts at the end of the previous Device Path node. Therefore all nodes are byte-packed data structures that may appear on any byte boundary. All code references to device path notes must assume all fields are unaligned. Since every Device Path node contains a length field in a known place, it is possible to traverse Device Path nodes that are of an unknown type. There is no limit to the number, type, or sequence of nodes in a Device Path. This isn't a matter of "just fix u-boot", it is baked into the spec. Not enabling alignment faults is consistent with what TianoCore edk2 does. For armv6 and earlier, we probably still need hacks to pad the device- path nodes, which isn't quite in line with the spec, and sanitize device-paths passed in from the efi payload. But we can at least dtrt on armv7 (and aarch64 which already doesn't enable alignment faults). Probably we can skip clearing the bit when EFI_LOADER is enabled, since '0' is the reset value. But I guess safest to clear it just in case an early stage in the boot chain set it. Signed-off-by: Rob Clark --- Only tested in qemu, and it is unclear if alignment faults are even trapped in qemu. If someone wants to test, then try (on top of the "enough UEFI for standard distro boot" patchset[1]) either fallback.efi (which uses gnu-efi lib to parse device-paths to string) or any efi payload that uses the device-path-to-text protocol. Either of those should trigger unaligned accesses. Grub's lsefi command should also trigger unaligned faults. arch/arm/cpu/armv7/start.S | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index f06fd28940..c1cec30af6 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -149,7 +149,11 @@ ENTRY(cpu_init_cp15) mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x2000 @ clear bits 13 (--V-) bic r0, r0, #0x0007 @ clear bits 2:0 (-CAM) +#ifdef EFI_LOADER + bic r0, r0, #0x0002 @ clear bit 1 (--A-) Align +#else orr r0, r0, #0x0002 @ set bit 1 (--A-) Align +#endif orr r0, r0, #0x0800 @ set bit 11 (Z---) BTB #ifdef CONFIG_SYS_ICACHE_OFF bic r0, r0, #0x1000 @ clear bit 12 (I) I-cache -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods
wrote:
> Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function")
>
> The control status register value is embedded in a structure somewhere
> in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM
> (TMDSEVM3530) to boot again using the known control register base and
> offset for 'readl', for the OMAP34XX case.
>
> Signed-off-by: Derald D. Woods
>
> ---
> Changes in v2:
> - Added 'signed-off-by'
> - Updated description
>
> ---
> arch/arm/mach-omap2/sysinfo-common.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/sysinfo-common.c
> b/arch/arm/mach-omap2/sysinfo-common.c
> index 1dc7051ab3..3955e803ad 100644
> --- a/arch/arm/mach-omap2/sysinfo-common.c
> +++ b/arch/arm/mach-omap2/sysinfo-common.c
> @@ -16,6 +16,10 @@
> */
> u32 get_device_type(void)
> {
> +#if defined(CONFIG_OMAP34XX)
> + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) >>
> + DEVICE_TYPE_SHIFT;
> +#endif
> return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >>
> DEVICE_TYPE_SHIFT;
> }
> --
> 2.13.3
>
>
Is there any comment or concern with this patch? It was the simplest
means to get OMAP35XX booting again and still keep the original patch.
Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL located
structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". OMAP3
has a larger active SOC base than just OMAP36XX and greater. Was there
anything really broken with 'get_device_type()' previously?
Derald
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote:
> On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods
> wrote:
>
> > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function")
> >
> > The control status register value is embedded in a structure somewhere
> > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM
> > (TMDSEVM3530) to boot again using the known control register base and
> > offset for 'readl', for the OMAP34XX case.
> >
> > Signed-off-by: Derald D. Woods
> >
> > ---
> > Changes in v2:
> > - Added 'signed-off-by'
> > - Updated description
> >
> > ---
> > arch/arm/mach-omap2/sysinfo-common.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/sysinfo-common.c
> > b/arch/arm/mach-omap2/sysinfo-common.c
> > index 1dc7051ab3..3955e803ad 100644
> > --- a/arch/arm/mach-omap2/sysinfo-common.c
> > +++ b/arch/arm/mach-omap2/sysinfo-common.c
> > @@ -16,6 +16,10 @@
> > */
> > u32 get_device_type(void)
> > {
> > +#if defined(CONFIG_OMAP34XX)
> > + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) >>
> > + DEVICE_TYPE_SHIFT;
> > +#endif
> > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >>
> > DEVICE_TYPE_SHIFT;
> > }
>
> Is there any comment or concern with this patch? It was the simplest
> means to get OMAP35XX booting again and still keep the original patch.
> Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL located
> structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". OMAP3
> has a larger active SOC base than just OMAP36XX and greater. Was there
> anything really broken with 'get_device_type()' previously?
Is the pointer value wrong for 35xx? The problem, such as it was, was
having the same function duplicated in a number of places, and needing
to make it more easily / readily available (rather than duplicated
again) for some additional patches. I'd really rather not introduce
an #if here unless we really have no other choice. Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] pci: tegra: make tegra_pcie_port_reset weak function with explicit index
Hi Stephen On Fri, 2017-08-04 at 10:33 -0600, Stephen Warren wrote: > On 08/04/2017 10:10 AM, Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > > > Make tegra_pcie_port_reset() a weak function with an explicit index > > parameter. This allows overriding the PCIe port reset functionality > > from board specific code as e.g. required for Apalis TK1. > > I think this change should be implemented differently. > > Does the patch description mean that: > > a) This change allows the board code to know which port is being > reset. > > If so, simply have the board-specific implementation access port- > >index > since it's already being passed port, and all callers are passing > port->index as the index parameter. If the type isn't available, > then > you can add a tegra_pcie_port_index_of_port() function to retrieve > it > through the opaque type. I did of course know that the port struct already contained that information but did not think of any such elegant way to do it as you describe outside of adding an explicit index. So I agree and will just implement and make use of such a new tegra_pcie_port_index_of_port() function. > or: > > b) That by changing the function signature code is able to choose > between calling the board-specific reset override function and the > PCIe > driver low-level reset function? > > If so, let's just have two different function names, have all > callers > call the board-specific function only, and have the board-specific > function call the driver function. There can be a weak default > board-specific implementation that simply calls the driver function. Initially that was not really my intention but I believe you bring up a very valid point and it could be useful to use the default reset behaviour on certain ports while using a custom one on others. This would e.g. be the case on Apalis T30 where the on-module PCIe gigabit Ethernet chip is using the standard out-of-band signalling while the PCIe switch on the Apalis Evaluation board requires the same special reset work-around as optionally implemented for Apalis TK1. I will therefore implement it this way as well leaving it completely up to board code which way to go. Thanks again for your valuable input. Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: disable alignment fault checking with EFI_LOADER
> Am 07.08.2017 um 13:19 schrieb Rob Clark : > > Device-path structures in UEFI are only byte aligned, which can result > in unaligned access faults (either in u-boot or the efi payload which is > loaded). From the UEFI spec (sect 10.3.1 in UEFI spec v2.7): > > A Device Path is a series of generic Device Path nodes. The first > Device Path node starts at byte offset zero of the Device Path. > The next Device Path node starts at the end of the previous Device > Path node. Therefore all nodes are byte-packed data structures that > may appear on any byte boundary. All code references to device path > notes must assume all fields are unaligned. Since every Device Path > node contains a length field in a known place, it is possible to > traverse Device Path nodes that are of an unknown type. There is > no limit to the number, type, or sequence of nodes in a Device Path. > > This isn't a matter of "just fix u-boot", it is baked into the spec. > Not enabling alignment faults is consistent with what TianoCore edk2 > does. > > For armv6 and earlier, we probably still need hacks to pad the device- > path nodes, which isn't quite in line with the spec, and sanitize > device-paths passed in from the efi payload. But we can at least dtrt > on armv7 (and aarch64 which already doesn't enable alignment faults). > > Probably we can skip clearing the bit when EFI_LOADER is enabled, since > '0' is the reset value. But I guess safest to clear it just in case an > early stage in the boot chain set it. > > Signed-off-by: Rob Clark > --- > Only tested in qemu, and it is unclear if alignment faults are even > trapped in qemu. If someone wants to test, then try (on top of the > "enough UEFI for standard distro boot" patchset[1]) either fallback.efi > (which uses gnu-efi lib to parse device-paths to string) or any efi > payload that uses the device-path-to-text protocol. Either of those > should trigger unaligned accesses. Grub's lsefi command should also > trigger unaligned faults. It's unfortunately much harder. To have working hardware alignment fixups, you need to enable the MMU as well. That's why I rewrote the MMU management for AArch64 back then. The reason it worked out so far for me at least is that grub on 32bit as well as u-boot are compiled with unaligned checks. Alex > > arch/arm/cpu/armv7/start.S | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index f06fd28940..c1cec30af6 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -149,7 +149,11 @@ ENTRY(cpu_init_cp15) >mrcp15, 0, r0, c1, c0, 0 >bicr0, r0, #0x2000@ clear bits 13 (--V-) >bicr0, r0, #0x0007@ clear bits 2:0 (-CAM) > +#ifdef EFI_LOADER > +bicr0, r0, #0x0002@ clear bit 1 (--A-) Align > +#else >orrr0, r0, #0x0002@ set bit 1 (--A-) Align > +#endif >orrr0, r0, #0x0800@ set bit 11 (Z---) BTB > #ifdef CONFIG_SYS_ICACHE_OFF >bicr0, r0, #0x1000@ clear bit 12 (I) I-cache > -- > 2.13.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 8/9] spl: dm: Make it possible for the SPL to pick its own DTB from a FIT
On Mon, Aug 07, 2017 at 12:07:53PM +0200, Jean-Jacques Hiblot wrote: > u-boot can be embedded within a FIT image with multiple DTBs. It then > selects at run-time which one is best suited for the platform. > Use the same principle here for the SPL: put the DTBs in a FIT image, > compress it (LZO, GZIP, or no compression) and append it at the end of the > SPL. > > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: disable alignment fault checking with EFI_LOADER
On Mon, Aug 7, 2017 at 9:16 AM, Alexander Graf wrote: > > >> Am 07.08.2017 um 13:19 schrieb Rob Clark : >> >> Device-path structures in UEFI are only byte aligned, which can result >> in unaligned access faults (either in u-boot or the efi payload which is >> loaded). From the UEFI spec (sect 10.3.1 in UEFI spec v2.7): >> >> A Device Path is a series of generic Device Path nodes. The first >> Device Path node starts at byte offset zero of the Device Path. >> The next Device Path node starts at the end of the previous Device >> Path node. Therefore all nodes are byte-packed data structures that >> may appear on any byte boundary. All code references to device path >> notes must assume all fields are unaligned. Since every Device Path >> node contains a length field in a known place, it is possible to >> traverse Device Path nodes that are of an unknown type. There is >> no limit to the number, type, or sequence of nodes in a Device Path. >> >> This isn't a matter of "just fix u-boot", it is baked into the spec. >> Not enabling alignment faults is consistent with what TianoCore edk2 >> does. >> >> For armv6 and earlier, we probably still need hacks to pad the device- >> path nodes, which isn't quite in line with the spec, and sanitize >> device-paths passed in from the efi payload. But we can at least dtrt >> on armv7 (and aarch64 which already doesn't enable alignment faults). >> >> Probably we can skip clearing the bit when EFI_LOADER is enabled, since >> '0' is the reset value. But I guess safest to clear it just in case an >> early stage in the boot chain set it. >> >> Signed-off-by: Rob Clark >> --- >> Only tested in qemu, and it is unclear if alignment faults are even >> trapped in qemu. If someone wants to test, then try (on top of the >> "enough UEFI for standard distro boot" patchset[1]) either fallback.efi >> (which uses gnu-efi lib to parse device-paths to string) or any efi >> payload that uses the device-path-to-text protocol. Either of those >> should trigger unaligned accesses. Grub's lsefi command should also >> trigger unaligned faults. > > It's unfortunately much harder. To have working hardware alignment fixups, > you need to enable the MMU as well. That's why I rewrote the MMU management > for AArch64 back then. > > The reason it worked out so far for me at least is that grub on 32bit as well > as u-boot are compiled with unaligned checks. > hmm, sadness.. well then, back to -DBROKEN_UNALIGNED for armv7 then until someone enables mmu.. BR, -R > > Alex > >> >> arch/arm/cpu/armv7/start.S | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S >> index f06fd28940..c1cec30af6 100644 >> --- a/arch/arm/cpu/armv7/start.S >> +++ b/arch/arm/cpu/armv7/start.S >> @@ -149,7 +149,11 @@ ENTRY(cpu_init_cp15) >>mrcp15, 0, r0, c1, c0, 0 >>bicr0, r0, #0x2000@ clear bits 13 (--V-) >>bicr0, r0, #0x0007@ clear bits 2:0 (-CAM) >> +#ifdef EFI_LOADER >> +bicr0, r0, #0x0002@ clear bit 1 (--A-) Align >> +#else >>orrr0, r0, #0x0002@ set bit 1 (--A-) Align >> +#endif >>orrr0, r0, #0x0800@ set bit 11 (Z---) BTB >> #ifdef CONFIG_SYS_ICACHE_OFF >>bicr0, r0, #0x1000@ clear bit 12 (I) I-cache >> -- >> 2.13.0 >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] test: Port FIT test to a pytest
On Sat, Aug 05, 2017 at 10:28:38AM -0600, Simon Glass wrote: > We have a few tests still not part of the pytest framework. This means > that they do not run automatically with 'make tests'. > > This series converts the FIT test to the new framework. > > > Simon Glass (3): > test: Indent test-fit.py to match the next patch > test: Convert the FIT test to test/py > test: Move the FIT test into the correct place > > test/image/test-fit.py| 481 > -- > test/py/tests/test_fit.py | 428 + > 2 files changed, 428 insertions(+), 481 deletions(-) > delete mode 100755 test/image/test-fit.py > create mode 100755 test/py/tests/test_fit.py Thanks! This reminded me that I should be using make tests not invoking test.py directly for sandbox, so I'm increasing my local test coverage at least. For travis-ci, we should add those other sandbox configurations in, I'll take a kick at that shortly. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v7, 2/9] disk_partition: introduce macros for description string lengths
On Sun, Jun 25, 2017 at 04:43:18PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE
On Thu, Aug 03, 2017 at 12:48:30PM -0400, Rob Clark wrote:
> Similar to CONFIG_OF_BOARD, but in this case the fdt is still built by
> u-boot build. This allows the board to patch the fdt, etc.
>
> In the specific case of dragonboard 410c, we pass the u-boot generated
> fdt to the previous stage of bootloader (by embedding it in the
> u-boot.img that is loaded by lk/aboot), which patches the fdt and passes
> it back to u-boot.
>
> Signed-off-by: Rob Clark
> ---
> include/fdtdec.h | 3 ++-
> lib/fdtdec.c | 45 ++---
> 2 files changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 4a0947c626..b9acec735a 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -986,7 +986,8 @@ int fdtdec_setup(void);
>
> /**
> * Board-specific FDT initialization. Returns the address to a device tree
> blob.
> - * Called when CONFIG_OF_BOARD is defined.
> + * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is
> defined
> + * and the board implements it.
> */
> void *board_fdt_blob_setup(void);
>
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index d2dbd0f122..07c458673c 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1203,34 +1203,41 @@ int fdtdec_setup_memory_banksize(void)
> }
> #endif
>
> -int fdtdec_setup(void)
> +#ifdef CONFIG_OF_SEPARATE
> +/*
> + * For CONFIG_OF_SEPARATE, the board may optionally implement this to
> + * provide and/or fixup the fdt.
> + */
> +__weak void *board_fdt_blob_setup(void)
> {
> -#if CONFIG_IS_ENABLED(OF_CONTROL)
> -# ifdef CONFIG_OF_EMBED
> - /* Get a pointer to the FDT */
> - gd->fdt_blob = __dtb_dt_begin;
> -# elif defined CONFIG_OF_SEPARATE
> -# ifdef CONFIG_SPL_BUILD
> + void *fdt_blob = NULL;
> +#ifdef CONFIG_SPL_BUILD
> /* FDT is at end of BSS unless it is in a different memory region */
> if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
> - gd->fdt_blob = (ulong *)&_image_binary_end;
> + fdt_blob = (ulong *)&_image_binary_end;
> else
> - gd->fdt_blob = (ulong *)&__bss_end;
> + fdt_blob = (ulong *)&__bss_end;
>
> -# elif defined CONFIG_FIT_EMBED
> - gd->fdt_blob = locate_dtb_in_fit(&_end);
> +#elif defined CONFIG_FIT_EMBED
> + fdt_blob = locate_dtb_in_fit(&_end);
>
> - if (gd->fdt_blob == NULL || gd->fdt_blob <= ((void *)&_end)) {
> + if (fdt_blob == NULL || fdt_blob <= ((void *)&_end))
> puts("Failed to find proper dtb in embedded FIT Image\n");
> - return -1;
> - }
> -
> -# else
> +#else
> /* FDT is at end of image */
> - gd->fdt_blob = (ulong *)&_end;
> + fdt_blob = (ulong *)&_end;
> # endif
> -# elif defined(CONFIG_OF_BOARD)
> - /* Allow the board to override the fdt address. */
> + return fdt_blob;
> +}
> +#endif
> +
> +int fdtdec_setup(void)
> +{
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> +# ifdef CONFIG_OF_EMBED
> + /* Get a pointer to the FDT */
> + gd->fdt_blob = __dtb_dt_begin;
> +# elif defined(CONFIG_OF_SEPARATE) || defined(CONFIG_OF_BOARD)
> gd->fdt_blob = board_fdt_blob_setup();
> # elif defined(CONFIG_OF_HOSTFILE)
> if (sandbox_read_fdt_from_file()) {
Reviewed-by: Tom Rini
Simon, what do you think? Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v7, 1/9] EFI: replace number with UUID_STR_LEN macro
On Sun, Jun 25, 2017 at 04:43:17PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v7, 3/9] GPT: fix error in partitions string doc
On Sun, Jun 25, 2017 at 04:43:19PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > The existing partitions-list parsing in cmd/gpt.c passes a value > from gpt_default() to set_gpt_info() that README.gpt suggests > should begin with 'partitions='. Partition-list strings should > in fact begin with 'uuid_disk', as otherwise the call from > set_gpt_info() to extract_val() to find 'uuid_disk' will fail. > Change README.gpt accordingly. > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v7,5/9] cmd gpt: test in sandbox
On Sun, Jun 25, 2017 at 04:43:21PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > Make minor changes to README.gpt and sandbox_defconfig to support > testing of the gpt command's functionality in the sandbox. > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v8, 08/10] GPT: read partition table from device into a data structure
On Tue, Jul 04, 2017 at 11:18:50AM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > Make the partition table available for modification by reading it from > the user-specified device into a linked list. Provide an accessor > function for command-line testing. > > Signed-off-by: Alison Chaiken After changing this to only be adding significant code when CMD_GPT_RENAME is enabled, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v7, 7/9] GPT: add accessor function for disk GUID
On Sun, Jun 25, 2017 at 04:43:23PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > In order to read the GPT, modify the partition name strings, and then > write out a new GPT, the disk GUID is needed. While there is an > existing accessor for the partition UUIDs, there is none yet for the > disk GUID. > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] common/env_embedded.c: rename PPCENV/PPCTEXT macros
On Fri, Jul 28, 2017 at 11:46:38PM +0200, Thomas Petazzoni wrote: > The environment has pretty much nothing to do with just "PPC", so > rename the macros to just __UBOOT_ENV_SECTION__ which is more > readable. > > In addition, only a single macro is needed: the environment now goes > either to the default section (USE_HOSTCC is defined) or in the .text > section. > > Signed-off-by: Thomas Petazzoni Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v7, 6/9] partitions: increase MAX_SEARCH_PARTITIONS and move to part.h
On Sun, Jun 25, 2017 at 04:43:22PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > Move MAX_SEARCH_PARTITIONS to part.h so that functions in cmd > directory can find it. At the same time, increase the value to > 64 since some operating systems use many, and the resources > consumed by a larger value are minimal. > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: sama5d2_xplained: Make SPL work on spiflash
On Thu, Jul 20, 2017 at 04:28:47PM +0800, wenyou.y...@microchip.com wrote: > Because before switching to a lower clock source, we must switch > the clock source first instead of last. So before configuring the > PMC_MCKR register, invoke at91_mck_init_down() first. > > As said in datasheet, the the size of SPL must not exceed the maximum > size allowed(64Kbytes). > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass > --- > The patch is based on > [PATCH 0/6] board: atmel: Add new board: SAMA5D27-SOM1-EK board > https://lists.denx.de/pipermail/u-boot/2017-July/298815.html > > board/atmel/sama5d2_xplained/sama5d2_xplained.c | 10 ++ > include/configs/sama5d2_xplained.h | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/board/atmel/sama5d2_xplained/sama5d2_xplained.c > b/board/atmel/sama5d2_xplained/sama5d2_xplained.c > index 48f45b35ce..8fd7eb8af1 100644 > --- a/board/atmel/sama5d2_xplained/sama5d2_xplained.c > +++ b/board/atmel/sama5d2_xplained/sama5d2_xplained.c > @@ -285,6 +285,16 @@ void at91_pmc_init(void) > struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC; > u32 tmp; > > + /* > + * while coming from the ROM code, we run on PLLA @ 492 MHz / 164 MHz > + * so we need to slow down and configure MCKR accordingly. > + * This is why we have a special flavor of the switching function. > + */ > + tmp = AT91_PMC_MCKR_PLLADIV_2 | > + AT91_PMC_MCKR_MDIV_3 | > + AT91_PMC_MCKR_CSS_MAIN; > + at91_mck_init_down(tmp); What patch adds the at91_mck_init_down function? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 10/10] gpt: harden set_gpt_info() against non NULL-terminated strings
On Tue, Jul 04, 2017 at 11:19:46AM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > Strings read from devices may sometimes fail to be > NULL-terminated. The functions in lib/string.c are subject to > failure in this case. Protect against observed failures in > set_gpt_info() by switching to length-checking variants with a length > limit of the maximum possible partition table length. At the same > time, add a few checks for NULL string pointers. > > Here is an example as observed in sandbox under GDB: > > => gpt verify host 0 $partitions > Program received signal SIGSEGV, Segmentation fault. > 0x00477747 in strlen (s=0x0) at lib/string.c:267 > 267 for (sc = s; *sc != '\0'; ++sc) > (gdb) bt > #0 0x00477747 in strlen (s=0x0) at lib/string.c:267 > #1 0x004140b2 in set_gpt_info (str_part=, > str_disk_guid=str_disk_guid@entry=0x7fffdbe8, > partitions=partitions@entry=0x7fffdbd8, > parts_count=parts_count@entry=0x7fffdbcf "", dev_desc= out>) at cmd/gpt.c:415 > #2 0x004145b9 in gpt_verify (str_part=, > blk_dev_desc=0x7fffef09a9d0) at cmd/gpt.c:580 > #3 do_gpt (cmdtp=, flag=, argc= out>, argv=0x7fffef09a8f0) > at cmd/gpt.c:783 > #4 0x004295b0 in cmd_call (argv=0x7fffef09a8f0, argc=0x5, > flag=, > cmdtp=0x714e20 <_u_boot_list_2_cmd_2_gpt>) at common/command.c:500 > #5 cmd_process (flag=, argc=0x5, argv=0x7fffef09a8f0, > repeatable=repeatable@entry=0x726c04 , > ticks=ticks@entry=0x0) at common/command.c:539 > > Suggested-by: Lothar Waßmann > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: pm9263: Update to support DT and DM
On Fri, Jul 21, 2017 at 02:04:47PM +0800, wenyou.y...@microchip.com wrote: > Update the configuration files to support the device tree and driver > model. The peripheral clock and pins configuration are handled by > the clock and the pinctrl drivers respectively. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v8, 09/10] GPT: provide commands to selectively rename partitions
On Tue, Jul 04, 2017 at 11:19:18AM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > This patch provides support in u-boot for renaming GPT > partitions. The renaming is accomplished via new 'gpt swap' > and 'gpt rename' commands. > > The 'swap' mode returns an error if no matching partition names > are found, or if the number of partitions with one name does not equal > the number with the second name. The 'rename' variant always > succeeds as long as a partition with the provided number exists. > > Rewriting the partition table has the side-effect that all partitions > end up with "msftdata" flag set. The reason is that partition type > PARTITION_BASIC_DATA_GUID is hard-coded in the gpt_fill_pte() > function. This does not appear to cause any harm. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: ethernut5: Update to support DT and DM
On Fri, Jul 21, 2017 at 02:30:57PM +0800, wenyou.y...@microchip.com wrote: > Add the dts files to support deivce tree, update the configuration > files to support the device tree and driver model. The peripheral > clock and pins configuration are handled by the clock and the pinctrl > drivers respectively. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master. However: Warning (reg_format): "reg" property in /i2c-gpio-0/pcf8563@50 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /i2c-gpio-0/pcf8563@50 Warning (avoid_default_addr_size): Relying on default #size-cells value for /i2c-gpio-0/pcf8563@50 Please fix and push to the kernel as well as U-Boot, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v7, 4/9] sandbox: README: fix partition command invocation
On Sun, Jun 25, 2017 at 04:43:20PM -0700, Alison Chaiken wrote: > From: Alison Chaiken > > The instructions for creating a disk image that are presently in > README.sandbox fail because sfdisk doesn't know about GPT. > > Changes since v6: none. > > Signed-off-by: Alison Chaiken Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] configs: sama5d4_xplained: Fix input clock for debug UART
On Fri, Jul 28, 2017 at 11:37:26AM +0800, wenyou.y...@microchip.com wrote: > Fix the UART input clock for the early debug UART, it should be > 100MHz, instead of 88MHz. > > Signed-off-by: Wenyou Yang Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] common/env_embedded.c: drop support for CONFIG_SYS_USE_PPCENV
On Fri, Jul 28, 2017 at 11:46:37PM +0200, Thomas Petazzoni wrote: > CONFIG_SYS_USE_PPCENV is no longer used anywhere. It was used to put > the environment in the special .ppcenv section, but the last > architecture using this section (SuperH) has been changed to not use > it. > > Therefore, this commit drops support for CONFIG_SYS_USE_PPCENV > entirely. We only handle two cases: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] board: at91sam9rlek: Use SPI-flash-based AT45xxx DataFlash
On Fri, Jul 21, 2017 at 01:40:10PM +0800, wenyou.y...@microchip.com wrote: > To support driver model and device tree, use the SPI-flash-based > AT45xxx DataFlash driver, DataFlash is a kind of SPI flash. > Instead of ATMEL_DATAFLASH_SPI DataFlash older driver that will > be removed in the future. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/1] stmf32f4: soc: fix buildman compilation error
On Fri, Jul 28, 2017 at 11:54:14AM +0200, Patrice Chotard wrote: > From: Patrice Chotard > > fix the following compilation error reported by buidlman: > >arm: + stm32f429-discovery > +arch/arm/mach-stm32/stm32f4/soc.c: In function 'arch_cpu_init': > +arch/arm/mach-stm32/stm32f4/soc.c:30:2: error: 'for' loop initial > declarations are only allowed in C99 or C11 mode > + for (int i = 0; i < ARRAY_SIZE(stm32_region_config); i++) > + ^ > +arch/arm/mach-stm32/stm32f4/soc.c:30:2: note: use option -std=c99, > -std=gnu99, -std=c11 or -std=gnu11 to compile your code > +make[3]: *** [arch/arm/mach-stm32/stm32f4/soc.o] Error 1 > +make[2]: *** [arch/arm/mach-stm32/stm32f4] Error 2 > +make[1]: *** [arch/arm/mach-stm32] Error 2 > +make: *** [sub-make] Error 2 > > Signed-off-by: Patrice Chotard > Acked-by: Vikas Manocha Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: usb_a9263: Update to support DT and DM
On Fri, Jul 21, 2017 at 05:07:46PM +0800, wenyou.y...@microchip.com wrote: > Add the dts files to support deivce tree, update the configuration > files to support the device tree and driver model. The peripheral > clock and pins configuration are handled by the clock and the pinctrl > drivers respectively. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: pm9261: Update to support DT and DM
On Fri, Jul 21, 2017 at 05:04:56PM +0800, wenyou.y...@microchip.com wrote: > Add the dts files to support deivce tree, update the configuration > files to support the device tree and driver model. The peripheral > clock and pins configuration are handled by the clock and the pinctrl > drivers respectively. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: at91sam9261ek: Update to support DT and DM
On Fri, Jul 21, 2017 at 01:28:40PM +0800, wenyou.y...@microchip.com wrote: > Add the dts files to support deivce tree, update the configuration > files to support the device tree and driver model. The peripheral > clock and pins configuration are handled by the clock and the pinctrl > drivers respectively. > > Enable the early debug UART to debug problems when an ICE or other > debug mechanism is not available. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] board: at91sam9263ek: Use SPI-flash-based AT45xxx DataFlash
On Fri, Jul 21, 2017 at 01:40:09PM +0800, wenyou.y...@microchip.com wrote: > To support driver model and device tree, use the SPI-flash-based > AT45xxx DataFlash driver, DataFlash is a kind of SPI flash. > Instead of ATMEL_DATAFLASH_SPI DataFlash older driver that will > be removed in the future. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass After migrating the env location change to Kconfig (and in all that followed,) applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: meesc: Update to support DT and DM
On Fri, Jul 21, 2017 at 05:06:40PM +0800, wenyou.y...@microchip.com wrote: > Add the dts files to support deivce tree, update the configuration > files to support the device tree and driver model. The peripheral > clock and pins configuration are handled by the clock and the pinctrl > drivers respectively. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] board: at91sam9260ek: Use SPI-flash-based AT45xxx DataFlash
On Fri, Jul 21, 2017 at 01:40:11PM +0800, wenyou.y...@microchip.com wrote: > To support driver model and device tree, use the SPI-flash-based > AT45xxx DataFlash driver, DataFlash is a kind of SPI flash. > Instead of ATMEL_DATAFLASH_SPI DataFlash older driver that will > be removed in the future. > > Signed-off-by: Wenyou Yang > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] Convert ARCH_OMAP2PLUS boards' CONFIG_SYS_TEXT_BASE to Kconfig
On Fri, Jul 28, 2017 at 08:32:52AM -0500, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_SYS_TEXT_BASE > > The includes, whitelist, etc. were left for now but I don't get any > build errors or warnings on the omap3_logic_defconfig or > am3517_evm_defconfig builds I tried. > > Signed-off-by: Adam Ford Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368
On Mon, Aug 07, 2017 at 10:48:12AM +0200, Dr. Philipp Tomsich wrote:
> +Tom
>
> Ok, so the problem is 'scripts/setlocalversion’, which does the following:
> > if test -e include/config/auto.conf; then
> > . include/config/auto.conf
> > else
> > echo "Error: kernelrelease not valid - run 'make prepare' to update
> > it"
> > exit 1
> > fi
> in order to access the variables needed for:
> > # CONFIG_LOCALVERSION and LOCALVERSION (if set)
> > res="${res}${CONFIG_LOCALVERSION}${LOCALVERSION}"
> >
> > # scm version string if not at a tagged commit
> > if test "$CONFIG_LOCALVERSION_AUTO" = "y"; then
> > # full scm version string
> > res="$res$(scm_version)"
> > else
> > # append a plus sign if the repository is not in a clean
> > # annotated or signed tagged state (as git describe only
> > # looks at signed or annotated tags - git tag -a/-s) and
> > # LOCALVERSION= is not specified
> > if test "${LOCALVERSION+set}" != "set"; then
> > scm=$(scm_version --short)
> > res="$res${scm:++}"
> > fi
> > fi
>
> So nothing wrong with the changes to Kconfig, but we’re triggering a weakness
> in our
> build infrastructure here.
>
> I guess we’ll have to implement a save version of scripts/localversion that
> does not
> allow for the execution of arbitrary script code from auto.conf ...
Masahiro, do you have any ideas here? Thanks!
>
> > On 07 Aug 2017, at 10:38, Andy Yan wrote:
> >
> > Hi Philipp:
> >
> >
> > On 2017年08月07日 16:24, Dr. Philipp Tomsich wrote:
> >> Andy,
> >>
> >> Doing a non-buildman defconfig + make works fine.
> >> I’ve seen this too (I did a full buildman for all arm, x86 and powerpc
> >> boards) and it seems as if a shell-script is trying to source the
> >> generated auto.config file.
> >> I couldn’t spot where in buildman that happens, so I’ll need to leave this
> >> to someone with more insight into buildman to figure out…
> >
> >
> >I build with : make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> > firefly-rk3288_defconfig all
> > Also can see the waring: inclue/config/auto.conf: line 209: ARCH: command
> > not found.
> >>
> >> Regards,
> >> Phil.
> >>
> >>> On 07 Aug 2017, at 03:19, Andy Yan wrote:
> >>>
> >>> Hi :
> >>>
> >>>When run buildman rockchip on the master branch of current
> >>> u-boot-rockchip tree, I got warnings about 16 rockchip arm32 based boards:
> >>>
> >>> include/config/auto.config: line x: ARCH: command not found.
> >>>
> >>> the line x is the definition of the: SPL_LDSCRITP
> >>> "arch/$(ARCH)/cpu/u-boot-spl.lds"
> >>>
> >>> not sure is there somethings wrong about this series change.
> >>>
> >>>
> >>> On 2017年08月07日 01:18, Philipp Tomsich wrote:
> > Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our
> > header file.
> >
> > Signed-off-by: Philipp Tomsich
> > Reviewed-by: Simon Glass
> > ---
> >
> > Changes in v4:
> > - (added) sets TPL_LDSCRIPT via Kconfig
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> > arch/arm/mach-rockchip/Kconfig | 7 +++
> > include/configs/rk3368_common.h | 2 --
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> Applied to u-boot-rockchip, thanks!
>
>
>
> >>>
> >>
> >>
> >>
> >
> >
>
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert CONFIG_SYS_I2C_OMAP24XX et al to Kconfig
On Sun, Aug 06, 2017 at 01:27:15PM -0500, Adam Ford wrote: > On Thu, Jul 27, 2017 at 6:55 AM, Tom Rini wrote: > > On Wed, Jul 26, 2017 at 09:22:06PM -0500, Adam Ford wrote: > >> On Wed, Jul 26, 2017 at 8:52 PM, Tom Rini wrote: > >> > On Wed, Jul 26, 2017 at 09:03:37AM -0500, Adam Ford wrote: > >> > > >> >> This converts the following to Kconfig: > >> >>CONFIG_SYS_I2C_OMAP24XX > >> >>CONFIG_SYS_I2C_OMAP34XX > >> >> > >> >> Signed-off-by: Adam Ford > >> > > >> > This needs some manual attention. We should just drop > >> > CONFIG_SYS_I2C_OMAP24XX as it's meaningless now. Also: > >> > > >> I thought the same thing, but I looked at the driver and the driver > >> has some explicit differences that are unique to the > >> CONFIG_SYS_I2C_OMAP34XX. > >> > >> As an example: > >> #if defined(CONFIG_OMAP34XX) > >> /* > >> * Have to enable interrupts for OMAP2/3, these IPs don't have > >> * an 'irqstatus_raw' register and we shall have to poll 'stat' > >> */ > >> writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE | > >> I2C_IE_NACK_IE | I2C_IE_AL_IE, &i2c_base->ie); > >> #endif > >> > >> > >> > >> The comment in the code even states there are some minor differences: > >> "Status functions now read irqstatus_raw as per TRM guidelines > >> (except for OMAP243X and OMAP34XX)" > >> > >> So I think we need both. > >> Looking at the ti_omap4_common.h, it defines CONFIG_SYS_I2C_OMAP24XX, > >> but not OMAP34XX, so it appears to me like we might want a naming > >> convention change. > > > > But nothing toggles off of SYS_I2C_OMAP24XX vs SYS_I2C_OMAP34XX is the > > key. It might have back when we supported omap1/2 systems as well, but > > it doesn't today. Everything inside the driver keys off of > > OMAP34XX/AM33XX/etc/etc now. > > > > Got it. That makes sense. Since the name of the source files is > omap24xx_i2c.c/.h , would you object to dumping the > CONFIG_SYS_I2C_OMAP34XX in favor of keeping the > CONFIG_SYS_I2C_OMAP24XX for consistency? That seems the most reasonable course, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK
On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote: > The CONFIG_BLK conversion involves quite invasive changes in the U-Boot > code, with #ifdefs and different code paths. We should try to move over to > this soon so we can drop the old code. > > Set a deadline of 9 months for this work, rounded up to the next release. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini And I've gone and made a calendar reminder to make v2018.01 have a scary build warning about this conversion too. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions
On Sun, Aug 06, 2017 at 11:34:15AM -0400, Rob Clark wrote:
> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark wrote:
> >
> > I've started trying to hack up test_efi_loader.py to add a test that
> > loads OpenBSD's bootloader.. kinda muddling through it at this point,
> > since not a py expert or too familiar w/ u-boot's test framework. But
> > I'll see if I can get to the point where I can run the same thing on
> > various arm7 and aarch64 devices in qemu.
> >
>
> Making a bit of progress on this (running it on a vexpress_ca15_tc2
> board in qemu).. any hint where I can find BOOTARM.EFI src code?
>
> => tftpboot 8040 obsdboot.efi
> smc911x: MAC 52:54:00:12:34:56
> smc911x: detected LAN9118 controller
> smc911x: phy initialized
> smc911x: MAC 52:54:00:12:34:56
> Using smc911x-0 device
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> Filename 'obsdboot.efi'.
> Load address: 0x8040
> Loading: *%08#
> 12.4 MiB/s
> done
> Bytes transferred = 64908 (fd8c hex)
> smc911x: MAC 52:54:00:12:34:56
> => crc32 8040 $filesize
> CRC32 for 8040 ... 8040fd8b ==> a9ac4fcf
> => bootefi 8040
> ## Starting EFI application at 8040 ...
> WARNING: Invalid device tree, expect boot to fail
> BS->LocateHandle() returns 0
> undefined instruction
> pc : [<9eec65c4>] lr : [<9eeca390>]
> sp : 9fed7a18 ip : 003f fp : 9fed7a2c
> r10: r9 : 9eed4658 r8 :
> r7 : 9eed1ce4 r6 : 9eed3538 r5 : 9fed7a6c r4 : 9eed4658
> r3 : r2 : 9eed2f8e r1 : 9eed1ee0 r0 :
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Resetting CPU ...
>
> resetting ...
>
>
> U-Boot 2017.09-rc1-00025-g534695d189 (Aug 06 2017 - 06:58:16 -0400)
>
> DRAM: 1 GiB
> WARNING: Caches not enabled
> Flash: 128 MiB
> MMC: MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:serial
> Out: serial
> Err: serial
> Net: smc911x-0
> Hit any key to stop autoboot: 2
Why does U-Boot not set fdt_addr_r or fdtfile for vexpress? Worse yet
trying to load to the default kernel_addr_r fails. So it requires a
script or manual commands to boot instead of the usual distro boot
arrangement?
There is some kind of hard hang on OpenBSD with vexpress at the moment
and there is no driver for the sd/mmc but getting to that point seemed
quite a bit more painful than using U-Boot on real hardware.
After adding vexpress-v2p-ca15-tc1.dtb to the FAT16 on miniroot-panda-61.fs:
$ qemu-system-arm -M vexpress-a15 -kernel vexpress_ca15_tc2/u-boot -nographic
-sd miniroot-panda-61.fs
U-Boot 2017.09-rc1 (Aug 02 2017 - 10:55:19 +1000)
DRAM: 128 MiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC: MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: smc911x-0
Hit any key to stop autoboot: 0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc0 is current device
env - environment handling commands
Usage:
env default [-f] -a - [forcibly] reset default environment
env default [-f] var [...] - [forcibly] reset variable(s) to their default
values
env delete [-f] var [...] - [forcibly] delete variable(s)
env export [-t | -b | -c] [-s size] addr [var ...] - export environment
env import [-d] [-t [-r] | -b | -c] addr [size] - import environment
env print [-a | name ...] - print environment
env run var [...] - run commands in an environment variable
env save - save environment
env set [-f] name [arg ...]
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
64908 bytes read in 52 ms (1.2 MiB/s)
## Starting EFI application at a0008000 ...
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 2147483646
EFI LOAD FAILED: continuing...
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (3 ms)
*** Warning: no boot file name; using '0A00020F.img'
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename '0A00020F.img'.
Load address: 0xa0008000
Loading: *
TFTP error: 'Access violation' (2)
...
=> setenv fdt_addr_r 0x8100
=> setenv fdtfile vexpress-v2p-ca15-tc1.dtb
reading vexpress-v2p-ca15-tc1.dtb
13384 bytes read in 22 ms (593.8 KiB/s)
=> load mmc 0:1 ${kernel_addr_r} efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
64908 bytes read in 51 ms (1.2 MiB/s)
=> bootefi ${kernel_addr_r} ${fdt_addr_r}
## Starting EFI application at a0008000 ...
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 2147483646
=> printenv kernel_addr_r
kernel_addr_r=0xa0008000
=> setenv kernel_addr_r 0x8200
=> load mmc 0:1 ${kernel_addr_r} efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
64908 bytes read in 49 ms (1.3 MiB/s)
=> bootefi ${kernel_addr_r} ${fdt_addr_r}
## Starting EFI application at 8200 ...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 no
Re: [U-Boot] [RFC] move booti_setup to arch/arm/lig/image.c
On Fri, Jul 28, 2017 at 06:04:11PM +1000, Bin Chen wrote:
> Follow bootz's pattern by moving the booti_setup to arch/arm/lib.
> This allows to use that function in other path, e.g booting
> an android image contains Image format.
>
> Note that kernel relocation is move out of booti_setup and it is the
> caller's responsibility to do it and allows them do it differently. say,
> cmd/booti.c just do a manually, while in the bootm path, we can use
> bootm_load_os(with some changes).
Just to be clear, did you boot test this path on hardware?
And, a minor comment:
> - ih = (struct Image_header *)map_sysmem(images->ep, 0);
> -
> - lmb_reserve(&images->lmb, images->ep, le32_to_cpu(ih->image_size));
> + /* Handle BOOTM_STATE_LOADOS */
> + if (relocated_addr != ld) {
> +debug("Moving Image from 0x%lx to 0x%lx\n", ld, relocated_addr);
> +memmove((void *)relocated_addr, (void *)ld, image_size);
> +}
Please correct the indentation here.
Otherwise, and assuming you've booted the kernel with this patch, fix
the above, post as v2 instead and:
Reviewed-by: Tom Rini
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions
On Mon, Aug 7, 2017 at 11:47 AM, Jonathan Gray wrote:
> On Sun, Aug 06, 2017 at 11:34:15AM -0400, Rob Clark wrote:
>> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark wrote:
>> >
>> > I've started trying to hack up test_efi_loader.py to add a test that
>> > loads OpenBSD's bootloader.. kinda muddling through it at this point,
>> > since not a py expert or too familiar w/ u-boot's test framework. But
>> > I'll see if I can get to the point where I can run the same thing on
>> > various arm7 and aarch64 devices in qemu.
>> >
>>
>> Making a bit of progress on this (running it on a vexpress_ca15_tc2
>> board in qemu).. any hint where I can find BOOTARM.EFI src code?
>>
>> => tftpboot 8040 obsdboot.efi
>> smc911x: MAC 52:54:00:12:34:56
>> smc911x: detected LAN9118 controller
>> smc911x: phy initialized
>> smc911x: MAC 52:54:00:12:34:56
>> Using smc911x-0 device
>> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
>> Filename 'obsdboot.efi'.
>> Load address: 0x8040
>> Loading: *%08#
>> 12.4 MiB/s
>> done
>> Bytes transferred = 64908 (fd8c hex)
>> smc911x: MAC 52:54:00:12:34:56
>> => crc32 8040 $filesize
>> CRC32 for 8040 ... 8040fd8b ==> a9ac4fcf
>> => bootefi 8040
>> ## Starting EFI application at 8040 ...
>> WARNING: Invalid device tree, expect boot to fail
>> BS->LocateHandle() returns 0
>> undefined instruction
>> pc : [<9eec65c4>] lr : [<9eeca390>]
>> sp : 9fed7a18 ip : 003f fp : 9fed7a2c
>> r10: r9 : 9eed4658 r8 :
>> r7 : 9eed1ce4 r6 : 9eed3538 r5 : 9fed7a6c r4 : 9eed4658
>> r3 : r2 : 9eed2f8e r1 : 9eed1ee0 r0 :
>> Flags: nZCv IRQs off FIQs off Mode SVC_32
>> Resetting CPU ...
>>
>> resetting ...
>>
>>
>> U-Boot 2017.09-rc1-00025-g534695d189 (Aug 06 2017 - 06:58:16 -0400)
>>
>> DRAM: 1 GiB
>> WARNING: Caches not enabled
>> Flash: 128 MiB
>> MMC: MMC: 0
>> *** Warning - bad CRC, using default environment
>>
>> In:serial
>> Out: serial
>> Err: serial
>> Net: smc911x-0
>> Hit any key to stop autoboot: 2
>
> Why does U-Boot not set fdt_addr_r or fdtfile for vexpress? Worse yet
> trying to load to the default kernel_addr_r fails. So it requires a
> script or manual commands to boot instead of the usual distro boot
> arrangement?
I suspect this is specific to the test framework (probably not
enabling distro-boot-cmd so that the test framework can run the cmds
it wants??)
BR,
-R
> There is some kind of hard hang on OpenBSD with vexpress at the moment
> and there is no driver for the sd/mmc but getting to that point seemed
> quite a bit more painful than using U-Boot on real hardware.
>
> After adding vexpress-v2p-ca15-tc1.dtb to the FAT16 on miniroot-panda-61.fs:
>
> $ qemu-system-arm -M vexpress-a15 -kernel vexpress_ca15_tc2/u-boot -nographic
> -sd miniroot-panda-61.fs
>
> U-Boot 2017.09-rc1 (Aug 02 2017 - 10:55:19 +1000)
>
> DRAM: 128 MiB
> WARNING: Caches not enabled
> Flash: 128 MiB
> MMC: MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:serial
> Out: serial
> Err: serial
> Net: smc911x-0
> Hit any key to stop autoboot: 0
> MMC Device 1 not found
> no mmc device at slot 1
> switch to partitions #0, OK
> mmc0 is current device
> env - environment handling commands
>
> Usage:
> env default [-f] -a - [forcibly] reset default environment
> env default [-f] var [...] - [forcibly] reset variable(s) to their default
> values
> env delete [-f] var [...] - [forcibly] delete variable(s)
> env export [-t | -b | -c] [-s size] addr [var ...] - export environment
> env import [-d] [-t [-r] | -b | -c] addr [size] - import environment
> env print [-a | name ...] - print environment
> env run var [...] - run commands in an environment variable
> env save - save environment
> env set [-f] name [arg ...]
>
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootarm.efi
> reading efi/boot/bootarm.efi
> 64908 bytes read in 52 ms (1.2 MiB/s)
> ## Starting EFI application at a0008000 ...
> WARNING: Invalid device tree, expect boot to fail
> efi_load_pe: Invalid DOS Signature
> ## Application terminated, r = 2147483646
> EFI LOAD FAILED: continuing...
> smc911x: MAC 52:54:00:12:34:56
> smc911x: detected LAN9118 controller
> smc911x: phy initialized
> smc911x: MAC 52:54:00:12:34:56
> BOOTP broadcast 1
> DHCP client bound to address 10.0.2.15 (3 ms)
> *** Warning: no boot file name; using '0A00020F.img'
> Using smc911x-0 device
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> Filename '0A00020F.img'.
> Load address: 0xa0008000
> Loading: *
> TFTP error: 'Access violation' (2)
>
> ...
>
> => setenv fdt_addr_r 0x8100
> => setenv fdtfile vexpress-v2p-ca15-tc1.dtb
> reading vexpress-v2p-ca15-tc1.dtb
> 13384 bytes read in 22 ms (593.8 KiB/s)
> => load mmc 0:1 ${kernel_addr_r} efi/boot/bootarm.efi
> reading efi/boot/bootarm.efi
> 64908 bytes read in 51 ms (1.2 MiB/s)
> => bootefi ${kernel_addr_r} ${fdt_addr_r}
> ## Starting EFI application at a0008000 ...
> efi_load_pe: Invalid DOS
Re: [U-Boot] [PATCH 1/4] video: Drop the l5f31188 driver
Hi Bin, On Thu, 3 Aug 2017 21:56:47 -0700 Bin Meng bmeng...@gmail.com wrote: > This is not used in U-Boot. > > Signed-off-by: Bin Meng > --- > > drivers/video/Makefile | 1 - > drivers/video/l5f31188.c | 192 > --- > 2 files changed, 193 deletions(-) > delete mode 100644 drivers/video/l5f31188.c applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] video: Drop the sed156x driver
On Thu, 3 Aug 2017 21:56:48 -0700 Bin Meng bmeng...@gmail.com wrote: > This is not used in U-Boot. > > Signed-off-by: Bin Meng > --- > > drivers/video/Makefile | 1 - > drivers/video/sed156x.c | 546 > > include/sed156x.h | 26 --- > 3 files changed, 573 deletions(-) > delete mode 100644 drivers/video/sed156x.c > delete mode 100644 include/sed156x.h applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] video: Drop the sm501 driver
On Thu, 3 Aug 2017 21:56:49 -0700 Bin Meng bmeng...@gmail.com wrote: > This is not used in U-Boot. > > Signed-off-by: Bin Meng > --- > > drivers/video/Makefile | 1 - > drivers/video/sm501.c| 225 > --- > include/sm501.h | 35 --- > scripts/config_whitelist.txt | 1 - > 4 files changed, 262 deletions(-) > delete mode 100644 drivers/video/sm501.c > delete mode 100644 include/sm501.h applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] video: Drop the ct69000 driver
On Thu, 3 Aug 2017 21:56:50 -0700 Bin Meng bmeng...@gmail.com wrote: > This is not used in U-Boot. > > Signed-off-by: Bin Meng > --- > > drivers/video/Kconfig | 31 +- > drivers/video/Makefile |1 - > drivers/video/cfb_console.c | 10 - > drivers/video/ct69000.c | 1168 > --- > 4 files changed, 2 insertions(+), 1208 deletions(-) > delete mode 100644 drivers/video/ct69000.c applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] efi_loader: Add test to boot OpenBSD's efi bootloader
On 08/06/2017 10:10 AM, Rob Clark wrote:
Signed-off-by: Rob Clark
---
Kinda works, but since we don't have an 'exit' command like grub, we
have to reboot, which leaves the "board" in a bad state (I guess,
since the next test fails). I haven't tackled the travis bits to get
travis to download OpenBSD's bootloader, or other little details like
that.
+# There is no exit, but there is a reboot cmd.. maybe we need to do
+# more than this to get u-boot running again??
+u_boot_console.run_command('reboot', wait_for_prompt=False,
wait_for_echo=False)
Assuming that 'reboot' works here, and actually resets the system, it'll
probably end up booting whatever code is in flash/storage, which isn't
necessarily the version of U-Boot that's being tested; the version under
test may not be in flash, but might be downloaded at boot time e.g. over
serial/USB to avoid flash wear. So yes, this test certainly needs to do
something different to restart U-Boot if the test can't simply exit back
to the previous running instance.
There's a core test/py function cons.restart_uboot() that should do
everything required to restart the target system. test/test_vboot.py
already uses it, in particular at the tail end of test_with_algo() in
order to return the target back to the expected state that the next test
expects.
I also recall writing down some ideas about how to add Linux-booting
testing into U-Boot, along with actually running some tests in Linux
mode to validate the boot without having to manually code up all the
command-line request/response logic. That was in an email to the U-Boot
list, perhaps during a conversation with Heiko. However, Google can't
find it right now:-( Still, I don't think it would improve things for
the test you're proposing right now since it's so simple, and it was
mostly just thinking about how to do it rather than actual code anyway.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/51] phy: Support Marvell 88X2242
On Sun, Aug 6, 2017 at 12:16 AM, Simon Glass wrote: > Hi Joe, > > On 27 July 2017 at 15:23, Joe Hershberger wrote: >> On Tue, Jul 25, 2017 at 3:22 AM, Mario Six wrote: >>> Hi Simon, >>> >>> On Tue, Jul 18, 2017 at 4:01 PM, Simon Glass wrote: Hi Mario, On 14 July 2017 at 05:54, Mario Six wrote: > From: Dirk Eibach > > Implement support for the Marvell Alaska X 88X2242P Integrated Dual-port > and Quad-port Multi-speed Ethernet Transceivers. > > Signed-off-by: Dirk Eibach > Signed-off-by: Mario Six > --- > > drivers/net/phy/Kconfig | 67 > drivers/net/phy/Makefile | 1 + > drivers/net/phy/marvell.c | 1 - > drivers/net/phy/mv88x2.c | 846 > ++ > drivers/net/phy/mv88x2.h | 12 + > drivers/net/phy/phy.c | 3 + > include/phy.h | 1 + > 7 files changed, 930 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/phy/mv88x2.c > create mode 100644 drivers/net/phy/mv88x2.h > We should really be using driver model here. Is the generic phy uclass good enough (generic-phy.h), or do we need a new uclass for Ethernet PHY? >>> >>> Wouldn't we also need a uclass for MDIO/MII interfaces then? I don't know >>> the >>> network subsystem too well, so I can't really tell where a ethernet phy >>> uclass >>> (or a MDIO uclass for that matter) would interface with the rest of it. >> >> The reason I've avoided implementing the uclass for phys so far is >> that the DTs of various boards are quite different in how they relate >> MDIO, PHY, and ETH. I suspect we'll end up needing some sort of ETH / >> platform / board specific DT parsing code and some way to hook into >> that. >> > > Do you mean that we cannot have plain PHY driver (e.g. for MII) that > works with multiple bords? Don't we have something similar already? > What can we do to move this forward. I think the driver is not the issue. If we want to be able to leverage the same DT bindings that Linux does, then it's not going to be generic. How the MDIO driver is associated to an ETH driver and how that ETH driver is associated with a PHY driver will all be unique to each ETH driver. By that I mean the drivers can be shared for the PHYs, but how they are bound will be unique. We can't have global PHY binding code in the PHY uclass. Do we do something like this elsewhere? Maybe in PCI or something? I haven't gone looking so far. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses
On Sat, Aug 5, 2017 at 1:06 PM, Rob Clark wrote: > On Sat, Aug 5, 2017 at 12:52 PM, Heinrich Schuchardt > wrote: >> On 08/05/2017 06:16 PM, Rob Clark wrote: >>> On Sat, Aug 5, 2017 at 12:12 PM, Heinrich Schuchardt >>> wrote: On 08/05/2017 05:58 PM, Rob Clark wrote: > Some arch's have trouble with unaligned accesses. Technically > EFI device-path structs should be byte aligned, and the next node > in the path starts immediately after the previous. Meaning that > a pointer to an 'struct efi_device_path' is not necessarily word > aligned. See section 10.3.1 in v2.7 of UEFI spec. > > This causes problems not just for u-boot, but also most/all EFI > payloads loaded by u-boot on these archs. Fortunately the common > practice for traversing a device path is to rely on the length > field in the header, rather than the specified length of the > particular device path type+subtype. So the EFI_DP_PAD() macro > will add the specified number of bytes to the tail of device path > structs to pad them to word alignment. > > Technically this is non-compliant, BROKEN_UNALIGNED should *only* > be defined on archs that cannot do unaligned accesses. > > Signed-off-by: Rob Clark > --- > I'm not sure if there are other arch's that need -DBROKEN_UNALIGNED > > Mark, this is untested but I think it should solve your crash on the > Banana Pi. Could you give it a try when you get a chance? > > arch/arm/config.mk | 2 +- > include/efi_api.h| 30 ++ > lib/efi_loader/efi_device_path.c | 3 +++ > 3 files changed, 34 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/config.mk b/arch/arm/config.mk > index 1a9db4..067dc93a9d 100644 > --- a/arch/arm/config.mk > +++ b/arch/arm/config.mk > @@ -28,7 +28,7 @@ LLVMS_RELFLAGS := $(call > cc-option,-mllvm,) \ > $(call cc-option,-arm-use-movt=0,) > PLATFORM_RELFLAGS+= $(LLVM_RELFLAGS) > > -PLATFORM_CPPFLAGS += -D__ARM__ > +PLATFORM_CPPFLAGS += -D__ARM__ -DBROKEN_UNALIGNED NAK We have more then ARM. And other architectures also create exceptions for unaligned access. I hate platform specific code. It should not be used outside /arch. To play it save you should not use _packed at all! Use memcpy to transfer between aligned and unaligned memory. >>> >>> except for reasons I explained in the thread on the patch that added >>> the __packed in the first place. Sorry, this is ugly but we have to >>> do it. >>> >>> BR, >>> -R >> >> According to the UEFI standard the nodes in paths are not to be assumed >> to be aligned. >> >> So even if you use padding bytes in paths that you pass to the EFI >> application you should not expect that the EFI application does the >> same. Expect the EFI application either to remove them or send new nodes >> without padding. >> >> To the idea of padding bytes and __packed does not make sense. > > Ok, to be fair, you are right about device-paths passed too u-boot. > On BROKEN_UNALIGNED archs, we should sanitise with a copy to an > aligned device-path in *addition* to what I proposed. I can make a > patch to add a helper to do this a bit later. > > But the padding bytes + __packed does make total sense because it > avoids breaking efi payloads that already exist in the field. The > crash that Mark saw was not in u-boot, but in openbsd's bootaa64.efi. > (It is possibly that we just get lucky here in u-boot since I add the > /End node after the mac address by something the compiler turns into a > memcpy.) > > My proposal simply preserves the bug that we already have on > BROKEN_UNALIGNED archs (but makes the improvement that it fixes the > bug on aarch64 and any other arch that can do unaligned access), to > keep existing efi payloads working. > Ok, so I took a closer look at the assembly generated, and I realized that with __packed structs, gcc seems to be generating ldrb+orr's for *all* the fields, in other words it isn't assuming alignment of the device-path pointer. The only potential problem right now is that we are missing __packed on 'struct efi_device_path' itself, so dereferencing the length field could cause unaligned access. Adding the missing __packed annotation turns the generated code into a pair of ldrb's plus an orr. I'll add the missing __packed on efi_device_path to my patchset. (I'm basing this on the asm generated for vexpress_ca15_tc2 build.) That is the good news.. the bad news is this probably still ends up being a problem in a few places w/ utf16 strings (ie. ascii2unicode()'ing into a filepath node, or converting filenames passed from efi payload from utf16..).. I'll have to think a bit about how best to handle that. But at least this is all stuff that never worked before in the first place, so I guess we don't hav
Re: [U-Boot] [PATCH v3 1/3] rockchip: defconfig: Increase max video resolution for mipi panel
Hi Eric, On Wed, 21 Jun 2017 11:20:32 +0800 Eric Gao eric@rock-chips.com wrote: > The mipi panel used on evb-rk3399 has a 1920x1200 resolution. But now > the max resolution is 1920x1080. So increase it. > > Signed-off-by: Eric Gao > > --- > > Changes in v2: None > Changes in v1: > -Add title. > > configs/evb-rk3399_defconfig | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) Applied to u-boot-video/master after dropping already committed hunks. Thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses
On Sat, Aug 05, 2017 at 06:52:59PM +0200, Heinrich Schuchardt wrote:
> On 08/05/2017 06:16 PM, Rob Clark wrote:
> > On Sat, Aug 5, 2017 at 12:12 PM, Heinrich Schuchardt
> > wrote:
> >> On 08/05/2017 05:58 PM, Rob Clark wrote:
> >>> Some arch's have trouble with unaligned accesses. Technically
> >>> EFI device-path structs should be byte aligned, and the next node
> >>> in the path starts immediately after the previous. Meaning that
> >>> a pointer to an 'struct efi_device_path' is not necessarily word
> >>> aligned. See section 10.3.1 in v2.7 of UEFI spec.
> >>>
> >>> This causes problems not just for u-boot, but also most/all EFI
> >>> payloads loaded by u-boot on these archs. Fortunately the common
> >>> practice for traversing a device path is to rely on the length
> >>> field in the header, rather than the specified length of the
> >>> particular device path type+subtype. So the EFI_DP_PAD() macro
> >>> will add the specified number of bytes to the tail of device path
> >>> structs to pad them to word alignment.
> >>>
> >>> Technically this is non-compliant, BROKEN_UNALIGNED should *only*
> >>> be defined on archs that cannot do unaligned accesses.
> >>>
> >>> Signed-off-by: Rob Clark
> >>> ---
> >>> I'm not sure if there are other arch's that need -DBROKEN_UNALIGNED
> >>>
> >>> Mark, this is untested but I think it should solve your crash on the
> >>> Banana Pi. Could you give it a try when you get a chance?
> >>>
> >>> arch/arm/config.mk | 2 +-
> >>> include/efi_api.h| 30 ++
> >>> lib/efi_loader/efi_device_path.c | 3 +++
> >>> 3 files changed, 34 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> >>> index 1a9db4..067dc93a9d 100644
> >>> --- a/arch/arm/config.mk
> >>> +++ b/arch/arm/config.mk
> >>> @@ -28,7 +28,7 @@ LLVMS_RELFLAGS := $(call
> >>> cc-option,-mllvm,) \
> >>> $(call cc-option,-arm-use-movt=0,)
> >>> PLATFORM_RELFLAGS+= $(LLVM_RELFLAGS)
> >>>
> >>> -PLATFORM_CPPFLAGS += -D__ARM__
> >>> +PLATFORM_CPPFLAGS += -D__ARM__ -DBROKEN_UNALIGNED
> >>
> >> NAK
> >>
> >> We have more then ARM. And other architectures also create exceptions
> >> for unaligned access.
> >>
> >> I hate platform specific code. It should not be used outside /arch.
> >>
> >> To play it save you should not use _packed at all!
> >> Use memcpy to transfer between aligned and unaligned memory.
> >
> > except for reasons I explained in the thread on the patch that added
> > the __packed in the first place. Sorry, this is ugly but we have to
> > do it.
> >
> > BR,
> > -R
>
> According to the UEFI standard the nodes in paths are not to be assumed
> to be aligned.
>
> So even if you use padding bytes in paths that you pass to the EFI
> application you should not expect that the EFI application does the
> same. Expect the EFI application either to remove them or send new nodes
> without padding.
Well, you do need it to be packed though. We've tried in recent years
to make sure all the fields pack naturally in new device paths types,
but unfortunately some of the ones that have been in use for more than a
decade were defined poorly; in particular, Hard Drive device paths do
not pack naturally. In Rob's patch he's got this:
struct efi_device_path_hard_drive_path {
struct efi_device_path dp;
u32 partition_number;
u64 partition_start;
u64 partition_end;
u8 partition_signature[16];
u8 partmap_type;
u8 signature_type;
EFI_DP_PAD(1);
} __packed;
If it's not packed, there's no circumstance that partition_number and
partition_start will ever both be correctly aligned. Without the
padding (which is questionable under the spec), the next header won't
be. That implies any code that's given this structure will have to do
fixups when checking the length, just to traverse the device path, even
when you don't do anything with the payload data.
Here's a quick test case that shows the different ways it can be packed
wrong, as well as the right way (I wrote this before looking at Rob's
definition above, but they're materially the same):
https://pjones.fedorapeople.org/efidp_packed/dp.c
https://pjones.fedorapeople.org/efidp_packed/output
There are a couple of different ways to get partition_number correct,
but only if both the header and the payload are packed does
payload.start ever get aligned correctly.
> To the idea of padding bytes and __packed does not make sense.
Padding I'm not so sure about; if everything is packed, the compiler
should generate direct accesses correctly. So the only cases we
actually have to worry about are when a pointer to a field >u8 is passed
some place that dereferences it.
--
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] rockchip: video: mipi: Split mipi driver into common and specific parts
On Wed, 21 Jun 2017 11:20:33 +0800 Eric Gao eric@rock-chips.com wrote: > To compatible with different rockchip soc, we split the mipi dirver into > common and soc specific parts, and all the soc share the common > functions from common driver part. > > Signed-off-by: Eric Gao > > --- > > Changes in v2: > -Use dev_read_addr to replace devfdt_get_addr. > > Changes in v1: > -Delete the unused variable. > > drivers/video/rockchip/rk3399_mipi.c | 183 > +++ > drivers/video/rockchip/rk_mipi.c | 170 ++-- > drivers/video/rockchip/rk_mipi.h | 32 ++ > 3 files changed, 221 insertions(+), 164 deletions(-) > create mode 100644 drivers/video/rockchip/rk3399_mipi.c > create mode 100644 drivers/video/rockchip/rk_mipi.h Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] rockchop: video: mipi: Makefile: Add soc specfic driver for rk3399 mipi dsi
On Wed, 21 Jun 2017 11:20:34 +0800 Eric Gao eric@rock-chips.com wrote: > Add Makefile item for soc specific driver for rk3399 mipi dsi. > > Signed-off-by: Eric Gao > --- > > Changes in v2: None > Changes in v1: None > > drivers/video/rockchip/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] wdt: Update uclass to make clear that the timeout is in ms
On Fri, Aug 4, 2017 at 2:48 PM, Simon Glass wrote:
> From: Andy Shevchenko
>
> Convert name to show explicitly that we are using milliseconds. For a
> watchdog timer this is precise enough.
>
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Use milliseconds since microseconds seems too fine a control
> - Update commit message to suit
>
> drivers/watchdog/wdt-uclass.c | 4 ++--
> include/wdt.h | 8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
> index bb9ae80866..8a30f024fd 100644
> --- a/drivers/watchdog/wdt-uclass.c
> +++ b/drivers/watchdog/wdt-uclass.c
> @@ -13,14 +13,14 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -int wdt_start(struct udevice *dev, u64 timeout, ulong flags)
> +int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
> {
> const struct wdt_ops *ops = device_get_ops(dev);
>
> if (!ops->start)
> return -ENOSYS;
>
> - return ops->start(dev, timeout, flags);
> + return ops->start(dev, timeout_ms, flags);
> }
>
> int wdt_stop(struct udevice *dev)
> diff --git a/include/wdt.h b/include/wdt.h
> index 0b5f05851a..9b90fbeeb3 100644
> --- a/include/wdt.h
> +++ b/include/wdt.h
> @@ -21,12 +21,12 @@
> * Start the timer
> *
> * @dev: WDT Device
> - * @timeout: Number of ticks before timer expires
> + * @timeout_ms: Number of ticks (milliseconds) before timer expires
These are not the same and this is definitely a functional change. The
length of a single tick depends on frequency of the clock that feeds
WDT. It might not be the same as 1/SYS_HZ. For example ast_wdt driver
uses 1MHz clock, so this parameter means microseconds for it.
> * @flags: Driver specific flags. This might be used to specify
> * which action needs to be executed when the timer expires
> * @return: 0 if OK, -ve on error
> */
> -int wdt_start(struct udevice *dev, u64 timeout, ulong flags);
> +int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags);
>
> /*
> * Stop the timer, thus disabling the Watchdog. Use wdt_start to start it
> again.
> @@ -67,12 +67,12 @@ struct wdt_ops {
> * Start the timer
> *
> * @dev: WDT Device
> -* @timeout: Number of ticks before the timer expires
> +* @timeout_ms: Number of ticks (milliseconds) before the timer
> expires
> * @flags: Driver specific flags. This might be used to specify
> * which action needs to be executed when the timer expires
> * @return: 0 if OK, -ve on error
> */
> - int (*start)(struct udevice *dev, u64 timeout, ulong flags);
> + int (*start)(struct udevice *dev, u64 timeout_ms, ulong flags);
> /*
> * Stop the timer
> *
> --
> 2.14.0.rc1.383.gd1ce394fe2-goog
>
--
Maxim Sloyko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions
On Fri, Aug 04, 2017 at 10:41:32PM +0200, Mark Kettenis wrote: [...] > ..and what you're sketching out here should work with recent enough > versions of our bootloader. > > However, to me having an ACPI Device Path component in there doesn't > make much sense on a board without ACPI. It certainly doesn't help > mapping a boot path back to an actual hardware device. Wouldn't it be > more logical to a Hardware Device Path there instead? In particular a > Memory Mapped Device Path would make a lot of sense as the start > address would make it fairly easy to do the mapping. It was really an arbitrary choice, as Rob said. I don't think there's any big problem with changing it, but I'm not sure Memory Mapped is correct. As I read it, StartingAddress and EndingAddress in that class should be pointing at some window into a memory map entry that is holding the thing described /by/ the node, but there's really nothing here. It's just an arbitrary root node. If we want something other than the ACPI path I made up, we should probably just go with a Vendor Specific Device Path with a constant well-known GUID of our choosing. e61d73b9-a384-4acc-aeab-82e828f3628b, say. -- Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
Hi Eric, On 2017-08-06 08:19, Eric Nelson wrote: > Hi Stefan, > > On 08/04/2017 04:38 PM, Stefan Agner wrote: >> From: Stefan Agner >> >> This series adds NXP's Serial Download Protocol (SDP) support via >> USB for SPL/U-Boot. It allows to download U-Boot via USB from a >> (recovered) SPL using the same tools used to download SPL itself >> (specifically imx_usb, but also sb_loader seems to work). >> > > Nice! > >> The idea has been brought up when the first targets started to make >> use of SPL for DDR initialization, see: >> https://lists.denx.de/pipermail/u-boot/2015-July/220330.html >> > > There have been lots of discussions surrounding the use of SDP, > and this seems to be a nice alternative to using the i.MX "plugin" > mode that I explored a while back: > > https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#298266 > Hm, wasn't aware of that particular effort, thanks for pointing to it. From a quick glance, it did not work out so far, is this correct? I looked into plugin mode also a little bit, but I did not continue to look into it after reading this sentence in the i.MX 6 RM: 8.7 Plugin Image The boot ROM detects the image type using the plugin flag of the boot data structure (see Boot Data Structure). If the plugin flag is 1, then the ROM uses the image as a plugin function. The function must initialize the boot device and copy the program image to the final location. At the end the plugin function must return with the program image parameters. (See High level boot sequence for details about boot flow). So if SPL should work as a plugin as NXP defines it, SPL is supposed to load the image from somewhere. The boot ROM then only takes care about image verification and further boot steps, but it's the plugins job to get the image from somewhere and store it in RAM. Afact this is not really helpful in our case. We would want the boot ROM to go through the boot sequence (again). Unless returning an error/invalid image causes the boot ROM to go through boot sequence again? The nice thing with our own SDP implementation is we can reuse it even from within U-Boot again, e.g. to download a kernel/initramfs >> The initial SDP implementation (patch 2) requires the payload to >> have the imx specific headers (hence the move of the imx header >> file in patch 1). >> >> Patch 3 extends image header support beyond the SDP specification, >> specifically implements also support for U-Boot headers. This >> allows to use the same SPL/U-Boot binaries for recovery as used on >> the regular boot device (SD/eMMC). For that to work also the host >> side imx_usb tools needed an extension, currently available here: >> >> https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored >> >> The full patchset allows to download SPL and U-Boot over USB to a >> target in recovery mode using the same usb_imx utility: > > imx_usb? > Yeah right, sorry. >> The usb_imx utility also has a batch mode which allows to download >> multiple artifacts with a single invocation. The details are >> outlined in the imx_usb commit message: >> https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60 >> >> In case this patchset gets accepted in U-Boot, I plan to push the >> imx_usb changes upstream as well. >> > > Do you have numbers for how much code/data size this adds to SPL? > Besides the protocol implementation also general USB (gadget) support is required, hence it adds quite a bit. Without USB Gadget/SDP support (Apalis iMX6 SPL): $ arm-linux-gnueabihf-size spl/u-boot-spl textdata bss dec hex filename 245523808 92 284526f24 spl/u-boot-spl With USB Gadget/SDP support: $ arm-linux-gnueabihf-size spl/u-boot-spl textdata bss dec hex filename 4254946791984 49212c03c spl/u-boot-spl > I believe some i.MX users have struggled to stay within the > size of internal RAM. Hm, I think the limit is somewhere around 64kiB? In our case we are still well below... -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] Configs: Migrate CONFIG_SYS_I2C_OMAP34XX to CONFIG_SYS_I2C_OMAP24XX
The driver is for all boards 24XX and up, so let's eliminate the
extra option called CONFIG_SYS_I2C_OMAP34XX since the driver checks
for CONFIG_OMAP34XX we don't need CONFIG_SYS_I2C_OMAP34XX.
Signed-off-by: Adam Ford
---
arch/arm/mach-omap2/omap3/clock.c | 2 +-
board/compulab/cm_t35/cm_t35.c | 2 +-
board/logicpd/am3517evm/am3517evm.c | 2 +-
board/ti/am3517crane/am3517crane.c | 2 +-
board/ti/evm/evm.c | 2 +-
drivers/i2c/Makefile| 1 -
include/configs/am3517_crane.h | 2 +-
include/configs/am3517_evm.h| 2 +-
include/configs/cm_t35.h| 2 +-
include/configs/cm_t3517.h | 2 +-
include/configs/cm_t54.h| 2 +-
include/configs/devkit8000.h| 2 +-
include/configs/mcx.h | 2 +-
include/configs/nokia_rx51.h| 2 +-
include/configs/omap3_evm.h | 2 +-
include/configs/omap3_logic.h | 2 +-
include/configs/omap3_overo.h | 2 +-
include/configs/omap3_pandora.h | 2 +-
include/configs/omap3_zoom1.h | 2 +-
include/configs/sniper.h| 2 +-
include/configs/tam3517-common.h| 2 +-
include/configs/tao3530.h | 2 +-
include/configs/tricorder.h | 2 +-
scripts/config_whitelist.txt| 1 -
24 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3/clock.c
b/arch/arm/mach-omap2/omap3/clock.c
index 006969e..3daae61 100644
--- a/arch/arm/mach-omap2/omap3/clock.c
+++ b/arch/arm/mach-omap2/omap3/clock.c
@@ -772,7 +772,7 @@ void per_clocks_enable(void)
setbits_le32(&prcm_base->iclken_per, 0x0002);
#endif
-#ifdef CONFIG_SYS_I2C_OMAP34XX
+#ifdef CONFIG_SYS_I2C_OMAP24XX
/* Turn on all 3 I2C clocks */
setbits_le32(&prcm_base->fclken1_core, 0x00038000);
setbits_le32(&prcm_base->iclken1_core, 0x00038000); /* I2C1,2,3 = on */
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index f169125..da67098 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -398,7 +398,7 @@ void board_mmc_power_init(void)
}
#endif
-#ifdef CONFIG_SYS_I2C_OMAP34XX
+#ifdef CONFIG_SYS_I2C_OMAP24XX
/*
* Routine: reset_net_chip
* Description: reset the Ethernet controller via TPS65930 GPIO
diff --git a/board/logicpd/am3517evm/am3517evm.c
b/board/logicpd/am3517evm/am3517evm.c
index 5d2d997..c18a5a3 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -105,7 +105,7 @@ int misc_init_r(void)
volatile unsigned int ctr;
u32 reset;
-#ifdef CONFIG_SYS_I2C_OMAP34XX
+#ifdef CONFIG_SYS_I2C_OMAP24XX
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
#endif
diff --git a/board/ti/am3517crane/am3517crane.c
b/board/ti/am3517crane/am3517crane.c
index 5fa319d..136cc43 100644
--- a/board/ti/am3517crane/am3517crane.c
+++ b/board/ti/am3517crane/am3517crane.c
@@ -43,7 +43,7 @@ int board_init(void)
*/
int misc_init_r(void)
{
-#ifdef CONFIG_SYS_I2C_OMAP34XX
+#ifdef CONFIG_SYS_I2C_OMAP24XX
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
#endif
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index fe8e793..a6c5a3d 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -147,7 +147,7 @@ void get_board_mem_timings(struct board_sdrc_timings
*timings)
int misc_init_r(void)
{
-#ifdef CONFIG_SYS_I2C_OMAP34XX
+#ifdef CONFIG_SYS_I2C_OMAP24XX
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
#endif
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 4bbf0c9..4f75419 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -31,7 +31,6 @@ obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
obj-$(CONFIG_SYS_I2C_MXS) += mxs_i2c.o
obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
-obj-$(CONFIG_SYS_I2C_OMAP34XX) += omap24xx_i2c.o
obj-$(CONFIG_SYS_I2C_RCAR) += rcar_i2c.o
obj-$(CONFIG_SYS_I2C_ROCKCHIP) += rk_i2c.o
obj-$(CONFIG_SYS_I2C_S3C24X0) += s3c24x0_i2c.o exynos_hs_i2c.o
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 36adea7..eb1fa5f 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -103,7 +103,7 @@
#define CONFIG_SYS_I2C
#define CONFIG_SYS_OMAP24_I2C_SPEED10
#define CONFIG_SYS_OMAP24_I2C_SLAVE1
-#define CONFIG_SYS_I2C_OMAP34XX
+#define CONFIG_SYS_I2C_OMAP24XX
/*
* Board NAND Info.
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 2f2e13c..42e4053 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -91,7 +91,7 @@
#define CONFIG_SYS_I2C
#define CONFIG_SYS_OMAP24_I2C_SPEED10
#define CONFIG_SYS_OMAP24_I2C_SLAVE1
-#define CONFIG_SYS_I2C_OMAP34XX
+#define CONFIG_SYS_I2C_OMAP24XX
/* Ethernet */
#define CONFIG_DRIVER_TI_EMAC
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index bdbbfdd..1fae294
