Re: [PATCH] spi: prevent overriding established bus settings
Hi,
Any comments on the patch?
Best regards,
Marcin
czw., 21 lis 2019 o 10:29 Marcin Wojtas napisał(a):
> + Simon
>
> czw., 21 lis 2019 o 05:39 Marcin Wojtas napisał(a):
>
>> The SPI stack relies on a proper bus speed/mode configuration
>> by calling dm_spi_claim_bus(). However the hitherto code
>> allowed to accidentally override those settings in
>> the spi_get_bus_and_cs() routine.
>>
>> The initially established speed could be discarded by using
>> the slave platdata, which turned out to be an issue on
>> the platforms whose slave maximum supported frequency
>> is not on par with the maximum frequency of the bus controller.
>>
>> This patch fixes above issue by configuring the bus from
>> spi_get_bus_and_cs() only in case it was not done before.
>>
>> Signed-off-by: Marcin Wojtas
>> ---
>> drivers/spi/spi-uclass.c | 20 +++-
>> 1 file changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
>> index 76c4b53..fcbe532 100644
>> --- a/drivers/spi/spi-uclass.c
>> +++ b/drivers/spi/spi-uclass.c
>> @@ -296,6 +296,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed,
>> int mode,
>> {
>> struct udevice *bus, *dev;
>> struct dm_spi_slave_platdata *plat;
>> + struct spi_slave *slave;
>> bool created = false;
>> int ret;
>>
>> @@ -351,19 +352,20 @@ int spi_get_bus_and_cs(int busnum, int cs, int
>> speed, int mode,
>> slave->dev = dev;
>> }
>>
>> - plat = dev_get_parent_platdata(dev);
>> + slave = dev_get_parent_priv(dev);
>>
>> - /* get speed and mode from platdata when available */
>> - if (plat->max_hz) {
>> - speed = plat->max_hz;
>> - mode = plat->mode;
>> + /*
>> +* In case the operation speed is not yet established by
>> +* dm_spi_claim_bus() ensure the bus is configured properly.
>> +*/
>> + if (!slave->speed) {
>> + ret = spi_claim_bus(slave);
>> + if (ret)
>> + goto err;
>> }
>> - ret = spi_set_speed_mode(bus, speed, mode);
>> - if (ret)
>> - goto err;
>>
>> *busp = bus;
>> - *devp = dev_get_parent_priv(dev);
>> + *devp = slave;
>> debug("%s: bus=%p, slave=%p\n", __func__, bus, *devp);
>>
>> return 0;
>> --
>> 2.7.4
>>
>>
[PATCH] imx: imx8mq: handle ESDHC in mxc_get_clock
fsl_esdhc_imx driver will call "mxc_get_clock(MXC_ESDHC_CLK +
dev->seq)", however mxc_get_clock wrongly handle MXC_ESDHC_CLK
as root clk and cause sd card could not be detected in U-Boot proper,
as below:
"Loading Environment from MMC... unable to select a mode"
Handle MXC_ESDHC_CLK in mxc_get_clock to fix the issue.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/imx8m/clock_imx8mq.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
index 2db5bde211..878f2be166 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
@@ -326,16 +326,20 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
{
u32 val;
- if (clk == MXC_ARM_CLK)
+ switch(clk) {
+ case MXC_ARM_CLK:
return get_root_clk(ARM_A53_CLK_ROOT);
-
- if (clk == MXC_IPG_CLK) {
+ case MXC_IPG_CLK:
clock_get_target_val(IPG_CLK_ROOT, );
val = val & 0x3;
return get_root_clk(AHB_CLK_ROOT) / (val + 1);
+ case MXC_ESDHC_CLK:
+ return get_root_clk(USDHC1_CLK_ROOT);
+ case MXC_ESDHC2_CLK:
+ return get_root_clk(USDHC2_CLK_ROOT);
+ default:
+ return get_root_clk(clk);
}
-
- return get_root_clk(clk);
}
u32 imx_get_uartclk(void)
--
2.16.4
Re: [PATCH] i2c: i2c_cdns: fix write timeout on fifo boundary
Hello Michael,
Am 09.12.2019 um 19:16 schrieb Michael Auchter:
This fixes an issue that would cause I2C writes to timeout when the
number of bytes is a multiple of the FIFO depth (i.e. 16 bytes).
Within the transfer loop, after writing the data register with a new
byte to transfer, if the transfer size equals the FIFO depth, the loop
pauses until the INTERRUPT_COMP bit asserts to indicate data has been
sent. This same check is performed after the loop as well to ensure data
has been transferred prior to returning.
In the case where the amount of data to be written is a multiple of the
FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to
assert after writing the final byte, and then wait for this bit to
assert once more. However, since the transfer has finished at this
point, no new data has been written to the data register, and hence
INTERRUPT_COMP will never assert.
Fix this by only waiting for INTERRUPT_COMP in the transfer loop if
there's still data to be written.
Signed-off-by: Michael Auchter
---
drivers/i2c/i2c-cdns.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index 2c0301ad08..ff3956d8c2 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -265,7 +265,7 @@ static int cdns_i2c_write_data(struct i2c_cdns_bus
*i2c_bus, u32 addr, u8 *data,
while (len-- && !is_arbitration_lost(regs)) {
writel(*(cur_data++), >data);
- if (readl(>transfer_size) == CDNS_I2C_FIFO_DEPTH) {
+ if (len && readl(>transfer_size) == CDNS_I2C_FIFO_DEPTH) {
ret = cdns_i2c_wait(regs, CDNS_I2C_INTERRUPT_COMP |
CDNS_I2C_INTERRUPT_ARBLOST);
if (ret & CDNS_I2C_INTERRUPT_ARBLOST)
Thanks for detecting this!
I soon send a pull request for Tom, if travis build is fine.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v8 02/17] i2c: designware: Add Apollo Lake support
For Apollo Lake we need to take the I2C bus controller out of reset before
using this. Add this functionality to the driver.
Signed-off-by: Simon Glass
Reviewed-by: Heiko Schocher
Reviewed-by: Bin Meng
---
Changes in v8:
- Add .data in compatible array
Changes in v7: None
Changes in v6:
- Add .driver_data in the designware_pci_supported array
- Add a comment about VANILLA
- Move lpss_reset_release() to this commit
Changes in v5:
- Drop unrelated change metioned by Heiko
Changes in v4:
- apollolake -> Apollo Lake
Changes in v3:
- Add a weak function to avoid errors on other platforms
Changes in v2: None
drivers/i2c/designware_i2c_pci.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/i2c/designware_i2c_pci.c b/drivers/i2c/designware_i2c_pci.c
index bb1f809af3..7f0625df66 100644
--- a/drivers/i2c/designware_i2c_pci.c
+++ b/drivers/i2c/designware_i2c_pci.c
@@ -8,8 +8,14 @@
#include
#include
#include
+#include
#include "designware_i2c.h"
+enum {
+ VANILLA = 0,/* standard I2C with no tweaks */
+ INTEL_APL, /* Apollo Lake I2C */
+};
+
/* BayTrail HCNT/LCNT/SDA hold time */
static struct dw_scl_sda_cfg byt_config = {
.ss_hcnt = 0x200,
@@ -19,6 +25,9 @@ static struct dw_scl_sda_cfg byt_config = {
.sda_hold = 0x6,
};
+/* Have a weak function for now - possibly should be a new uclass */
+__weak void lpss_reset_release(void *regs);
+
static int designware_i2c_pci_ofdata_to_platdata(struct udevice *dev)
{
struct dw_i2c *priv = dev_get_priv(dev);
@@ -59,6 +68,15 @@ static int designware_i2c_pci_ofdata_to_platdata(struct
udevice *dev)
static int designware_i2c_pci_probe(struct udevice *dev)
{
+ struct dw_i2c *priv = dev_get_priv(dev);
+
+ if (dev_get_driver_data(dev) == INTEL_APL) {
+ /* Ensure controller is in D0 state */
+ lpss_set_power_state(dev, STATE_D0);
+
+ lpss_reset_release(priv->regs);
+ }
+
return designware_i2c_probe(dev);
}
@@ -88,6 +106,7 @@ static int designware_i2c_pci_bind(struct udevice *dev)
static const struct udevice_id designware_i2c_pci_ids[] = {
{ .compatible = "snps,designware-i2c-pci" },
+ { .compatible = "intel,apl-i2c", .data = INTEL_APL },
{ }
};
@@ -113,6 +132,12 @@ static struct pci_device_id designware_pci_supported[] = {
{ PCI_VDEVICE(INTEL, 0x0f45) },
{ PCI_VDEVICE(INTEL, 0x0f46) },
{ PCI_VDEVICE(INTEL, 0x0f47) },
+ { PCI_VDEVICE(INTEL, 0x5aac), .driver_data = INTEL_APL },
+ { PCI_VDEVICE(INTEL, 0x5aae), .driver_data = INTEL_APL },
+ { PCI_VDEVICE(INTEL, 0x5ab0), .driver_data = INTEL_APL },
+ { PCI_VDEVICE(INTEL, 0x5ab2), .driver_data = INTEL_APL },
+ { PCI_VDEVICE(INTEL, 0x5ab4), .driver_data = INTEL_APL },
+ { PCI_VDEVICE(INTEL, 0x5ab6), .driver_data = INTEL_APL },
{},
};
--
2.24.0.525.g8f36a354ae-goog
RE: [PATCHv2 0/2] Intel Stratix10/Agilex Additions
> -Original Message- > From: Marek Vasut > Sent: Saturday, December 7, 2019 8:24 AM > To: thor.tha...@linux.intel.com; simon.k.r.goldschm...@gmail.com; Tan, > Ley Foon > Cc: albert.u.b...@aribaud.net; Ang, Chee Hong > ; Chee, Tien Fong ; > u-boot@lists.denx.de > Subject: Re: [PATCHv2 0/2] Intel Stratix10/Agilex Additions > > On 12/6/19 8:47 PM, thor.tha...@linux.intel.com wrote: > > From: Thor Thayer > > > > This patchset is rebased on top of [1] and adds SMMU support for > > Stratix10 and fixes an ECC access issue with Stratix10 and Agilex. > > > > [1] [U-Boot,v8,00/19] Add Intel Agilex SoC support > > https://patchwork.ozlabs.org/cover/1201373/ > > OK, I will let Ley handle this and prepare a PR for -next. Simon already sent PR for Agilex series. https://lists.denx.de/pipermail/u-boot/2019-December/393430.html Regards Ley Foon
Re: [U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on
Hi Peng, On Tue, Dec 10, 2019 at 11:50 PM Peng Fan wrote: > Update your scfw/atf and they try again. Please update board/freescale/imx8qm_mek/README to point to the correct ATF/SCFW versions.
Re: i.MX8MM-EVK Boot failure
Hi Peng, On Wed, Dec 11, 2019 at 12:05 AM Peng Fan wrote: > > Does it work if you follow the README steps? > > I not download that, just use my local ATF/DDR, Yes, this is what I suspected: the ATF/DDR firmware versions from the README are not working with mainline U-Boot. Could you please update the README to point to the correct versions, please? Otherwise nobody will be able to run U-Boot mainline on i.MX8MM/i.MX8MQ. Thanks
RE: i.MX8MM-EVK Boot failure
> Subject: Re: i.MX8MM-EVK Boot failure > > Hi Peng, > > On Tue, Dec 10, 2019 at 10:48 PM Peng Fan wrote: > > > What you modified? It boots well with Tom's tree. > > Does imx8mq-evk also boot for you? > > I followed the imx8mq-evk README instructions and it does not boot here. > > Maybe you are using different ATF/DDR firmware versions? > > Does it work if you follow the README steps? I not download that, just use my local ATF/DDR, U-Boot SPL 2020.01-rc4-00208-g520f955902 (Dec 11 2019 - 11:22:53 +0800) PMIC: PFUZE100 ID=0x10 DDRINFO: start DRAM init DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done Normal Boot Trying to boot from MMC2 NOTICE: Configuring TZASC380 NOTICE: RDC off NOTICE: BL31: v2.0(release):rel_imx_4.14.98_2.3.0_rc1-1-g8138ffe5c-dirty NOTICE: BL31: Built : 03:17:34, Dec 11 2019 NOTICE: sip svc init U-Boot 2020.01-rc4-00208-g520f955902 (Dec 11 2019 - 11:22:53 +0800) CPU: Freescale i.MX8MQ rev2.1 at 1000 MHz Reset cause: POR Model: NXP i.MX8MQ EVK DRAM: 3 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... unable to select a mode *** Warning - No block device, using default environment In:serial Out: serial Err: serial Net: Warning: ethernet@30be using MAC address from ROM eth0: ethernet@30be Hit any key to stop autoboot: 0 But there is true a mmc env issue here, I am checking. Thanks, Peng. > > Thanks
RE: [U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on
> Subject: [U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on > > Hello Peng, > > this patch broke my u-boot on a IMX8 QM ROM 7720a1 board. > > f0cc4eae9a1702a768817ea25d9f23cece69d021 > > I bisect it and that is the first broken commit. The commits before are > working > fine. > > I tried to remove your changes but then I run into this errrors: > > sc_rm_get_memreg_info: mr:38 res:22 > Memreg get info failed, -110 > mu_hal_sendmsg timeout > sc_rm_is_memreg_owned: mr:39 res:21 > sc_rm_is_memreg_owned: mr:39 res:21 > mu_hal_sendmsg timeout > > Some clue whats wrong here? Do I need to adapt my imx8qm board file? Update your scfw/atf and they try again. Regards, Peng. > > Best regards, > > Oliver
Re: [PATCH] rockchip: make_fit_atf: explicitly use python3【请注意，邮件由u-boot-boun...@lists.denx.de代发】
On 2019/12/10 下午9:07, m...@embed.me.uk wrote: From: Jack Mitchell On a distribution with no python2 installed and no python->python3 symlink the script will fail to execute. Specify python3 explicitly as it's already a requirement to build u-boot. Signed-off-by: Jack Mitchell Reviewed-by: Kever Yang Thanks, - Kever --- arch/arm/mach-rockchip/make_fit_atf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/make_fit_atf.py b/arch/arm/mach-rockchip/make_fit_atf.py index 3c045a5e17..c79317d6c5 100755 --- a/arch/arm/mach-rockchip/make_fit_atf.py +++ b/arch/arm/mach-rockchip/make_fit_atf.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python3 """ # SPDX-License-Identifier: GPL-2.0+ #
Re: [PATCH v2 00/16] efi_loader: add secure boot support
On Tue, Dec 10, 2019 at 08:54:12PM -0500, Tom Rini wrote: > On Wed, Dec 11, 2019 at 09:41:56AM +0900, AKASHI Takahiro wrote: > > Simon, > > > > On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote: > > > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote: > > > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote: > > > > >Tom, Simon, Heinrich, > > > > > > > > > >I have submitted three major patch sets for UEFI secure boot: > > > > >* x509/pkcs7 parser > > > > >* RSA library extension > > > > >* UEFI secure boot > > > > > > > > > >I have no technical issues to fix now and have seen only a few minor > > > > >comments on them (if I confirm that you have no more comments, > > > > >I can submit new version almost immediately). > > > > >Considering those, can I expect that those patches be merged > > > > >in v2020.01? > > > > > > > > > >If not, do you need to have more time for your reviewing? > > > > >What else do you expect from my side to accelerate the upstream? > > > > > > > > We are reaching the end of the release cycle. So do not expect any of > > > > these patch series to be merged in v2020.01. > > > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle > > > > > > I have often seen several patches (not bug fix) merged > > > even after "merge window". > > > Anyway, > > > > > > > To my understanding the UEFI secure boot series depends on the other two > > > > so it must be merged last. > > > > > > So once the first two patch set are accepted by the maintainers, > > > do you agree to merging the third one (i.e. secure boot patch itself) > > > promptly? > > > -> Heinrich > > > > > > As I said, I have had no technical issues on the first two patches > > > and haven't heard any comments/objections from the maintainers so far. > > > Are you willing to accept them for the next release? > > > -> Tom, Simon > > > > Can you confirm that you have queued my "RSA library extension" patch > > in your -next(?) branch, please? > > Please note that I raised a concern with the RSA patch series that needs > to be addressed. There's unexplained / unexpected size growth on > platforms that aren't otherwise enabling new features. Thanks! I misunderstood your statement there. Questions: 1) How did you measure the size growth? Please specify the exact command(s). 2) Did you use T1042RDB_PI_NAND_SECURE_BOOT_defconfig without any change? I want to reproduce your result on my side. Thanks, -Takahiro Akashi > -- > Tom
Re: i.MX8MM-EVK Boot failure
Hi Peng, On Tue, Dec 10, 2019 at 10:48 PM Peng Fan wrote: > What you modified? It boots well with Tom's tree. Does imx8mq-evk also boot for you? I followed the imx8mq-evk README instructions and it does not boot here. Maybe you are using different ATF/DDR firmware versions? Does it work if you follow the README steps? Thanks
Re: [PATCH v2 00/16] efi_loader: add secure boot support
On Wed, Dec 11, 2019 at 09:41:56AM +0900, AKASHI Takahiro wrote: > Simon, > > On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote: > > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote: > > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote: > > > >Tom, Simon, Heinrich, > > > > > > > >I have submitted three major patch sets for UEFI secure boot: > > > >* x509/pkcs7 parser > > > >* RSA library extension > > > >* UEFI secure boot > > > > > > > >I have no technical issues to fix now and have seen only a few minor > > > >comments on them (if I confirm that you have no more comments, > > > >I can submit new version almost immediately). > > > >Considering those, can I expect that those patches be merged > > > >in v2020.01? > > > > > > > >If not, do you need to have more time for your reviewing? > > > >What else do you expect from my side to accelerate the upstream? > > > > > > We are reaching the end of the release cycle. So do not expect any of > > > these patch series to be merged in v2020.01. > > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle > > > > I have often seen several patches (not bug fix) merged > > even after "merge window". > > Anyway, > > > > > To my understanding the UEFI secure boot series depends on the other two > > > so it must be merged last. > > > > So once the first two patch set are accepted by the maintainers, > > do you agree to merging the third one (i.e. secure boot patch itself) > > promptly? > > -> Heinrich > > > > As I said, I have had no technical issues on the first two patches > > and haven't heard any comments/objections from the maintainers so far. > > Are you willing to accept them for the next release? > > -> Tom, Simon > > Can you confirm that you have queued my "RSA library extension" patch > in your -next(?) branch, please? Please note that I raised a concern with the RSA patch series that needs to be addressed. There's unexplained / unexpected size growth on platforms that aren't otherwise enabling new features. Thanks! -- Tom signature.asc Description: PGP signature
RE: i.MX8MM-EVK Boot failure
> Subject: i.MX8MM-EVK Boot failure > > I am trying to run the latest master > > 4b19b89ca4a866b7baa642533e6dbd67cd832d27 > with the clock patches applied for 8mm, but I am getting a boot failure when I > follow the instructions in the README, which are also a bit wrong. (the > firmware versions don't match, and the ./firmware command is missing the > trailing '.bin', but it's trivial.) > > What comes out of the kit with DEBUG enabled is: > > (bunch of stuff deleted) > > [PMU Major message = 0x00fe] > [PMU Major message = 0x0007] > Training PASS > DDRINFO: ddrphy config done > DDRINFO:ddrphy calibration done > DDRINFO: ddrmix config done > >>SPL: board_init_r() > using memory lx-lx for malloc() > spl_init > Normal Boot > Trying to boot from MMC1 > common/dlmalloc.c:792: do_check_inuse_chunk: Assertion `inuse(p)' failed. > resetting ... > > The above sequence repeats again and again. I didn't put all the junk into > the log because it looked like everything seemed OK until the dlmalloc failure > at the end. If someone has any suggestions, I'd like to try the 8mm-evk with > a modern U-Boot. What you modified? It boots well with Tom's tree. U-Boot SPL 2020.01-rc4-00208-g520f955902 (Dec 11 2019 - 10:03:52 +0800) DDRINFO: start DRAM init DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done Normal Boot Trying to boot from MMC1 U-Boot SPL 2020.01-rc4-00208-g520f955902 (Dec 11 2019 - 10:05:20 +0800) DDRINFO: start DRAM init DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done Normal Boot Trying to boot from MMC1 U-Boot 2020.01-rc4-00208-g520f955902 (Dec 11 2019 - 10:05:20 +0800) CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz Reset cause: POR Model: FSL i.MX8MM EVK board DRAM: 2 GiB MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK In:serial Out: serial Err: serial Net: eth0: ethernet@30be Hit any key to stop autoboot: 0 Thanks, Peng. > > thank you, > > > adam
Re: [PATCH v2 00/16] efi_loader: add secure boot support
Simon, On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote: > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote: > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote: > > >Tom, Simon, Heinrich, > > > > > >I have submitted three major patch sets for UEFI secure boot: > > >* x509/pkcs7 parser > > >* RSA library extension > > >* UEFI secure boot > > > > > >I have no technical issues to fix now and have seen only a few minor > > >comments on them (if I confirm that you have no more comments, > > >I can submit new version almost immediately). > > >Considering those, can I expect that those patches be merged > > >in v2020.01? > > > > > >If not, do you need to have more time for your reviewing? > > >What else do you expect from my side to accelerate the upstream? > > > > We are reaching the end of the release cycle. So do not expect any of > > these patch series to be merged in v2020.01. > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle > > I have often seen several patches (not bug fix) merged > even after "merge window". > Anyway, > > > To my understanding the UEFI secure boot series depends on the other two > > so it must be merged last. > > So once the first two patch set are accepted by the maintainers, > do you agree to merging the third one (i.e. secure boot patch itself) > promptly? > -> Heinrich > > As I said, I have had no technical issues on the first two patches > and haven't heard any comments/objections from the maintainers so far. > Are you willing to accept them for the next release? > -> Tom, Simon Can you confirm that you have queued my "RSA library extension" patch in your -next(?) branch, please? -Takahiro Akashi > Thanks, > -Takahiro Akashi > > > > > Heinrich
FOSDEM Hardware Enablement Devroom: call for speakers.
Hi, At FOSDEM on sunday the 2nd of february 2020, there will be another hardware enablement DevRoom. URL: https://fosdem.org/2020/ This devroom covers topics related to hardware support and enablement with free software. It includes the following topics: * peripheral/controller firmwares * hw support and drivers in bootloaders * kernel drivers and hardware interfaces * hardware-related adaptation in operating systems * tools for firmware flashing * tools for low-level development FOSDEM is very much an open source community event, please refrain from turning in a talk that is meant to be purely corporate or a product commercial. Also, this is a highly technical devroom on a conference aimed at developers and advanced users, so only submit a talk on a subject you actually are involved with. Finally, this devrooms focus is the technical aspects of the hardware and its enablement in free projects, rather than the specific applications and use cases that benefit from it. With the return of the Embedded and Automotive DevRoom, we have the ability to schedule full hour talks again, and to go in-depth. If you however only need half an hour, then this is of course also possible. Talk Submission: The venerable pentabarf system will once again be used for talk submission. https://penta.fosdem.org/submission/FOSDEM20 When in pentabarf, spend some time on the abstract and description, for both the event and the speaker. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. As soon as your talk is scheduled by the devroom managers, you can see the result of your handiwork on the main website. Please re-use your old pentabarf account instead of creating a new one: lost password: https://penta.fosdem.org/user/forgot_password Talks are either 50 minutes or 20 minutes long, plus 5 minutes for questions. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY, sometimes minutes after your talk has finished. As for deadlines, the fosdem organizers want to have a finished schedule by the 15th of december, but do not count on that deadline, there are only a limited number of slots available. Given my belatedness in sending out this CFP, i might get a few more days if i am really really nice to the core FOSDEM organizers, but again, do not count on that (extra hugs only go so far when you're built like i am). On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Hardware Enablement Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Schedule: * select your preferred talk length, either 55 or 25 minutes. * Links: * Add relevant links. The mobile phone number is the hardest requirement, so you can be contacted on-the-day when something comes up. Speakers will all receive my mobile number in return. Neither email nor phonenumber are publicy visible, nor will this information be used for anything outside of devroom organization. After your talk has been scheduled, i usually only send out a single email with some organizational details in the days before the event. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email (hardware-devroom-mana...@fosdem.org). That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen.
Re: [PATCH v2 1/4] image: Add IH_OS_EFI for EFI chain-load boot
On Tue, Dec 10, 2019 at 6:30 PM Heinrich Schuchardt wrote:
>
> On 12/10/19 9:56 AM, Cristian Ciocaltea wrote:
> > Add a new OS type to be used for chain-loading an EFI compatible
> > firmware or boot loader like GRUB2, possibly in a verified boot
> > scenario.
> >
> > Bellow is sample ITS file that generates a FIT image supporting
> > secure boot. Please note the presence of 'os = "efi";' line, which
> > identifies the currently introduced OS type:
> >
> > / {
> > #address-cells = <1>;
> >
> > images {
> > efi-grub {
> > description = "GRUB EFI";
> > data = /incbin/("EFI/BOOT/bootarm.efi");
>
> According to UEFI Spec 2.8 the default file name for 32 bit ARM is
> BOOTARM.EFI. But GRUB calls the file grubarm.efi.
In Linux the boot.efi file is provided by shim [1] and used for
secure boot etc, I believe the default is also the fall back boot
method. I'm unaware of shim currently being built for armv7.
[1] https://github.com/rhboot/shim/
> So shouldn't we use grubarm.efi here as filename?
>
> You use EFI/BOOT as directory name. I think this path does not add
> benefit to the example. The other *.its files also come without any
> specific path.
>
> Best regards
>
> Heinrich
>
> > type = "kernel_noload";
> > arch = "arm";
> > os = "efi";
> > compression = "none";
> > load = <0x0>;
> > entry = <0x0>;
> > hash-1 {
> > algo = "sha256";
> > };
> > };
> > };
> >
> > configurations {
> > default = "config-grub";
> > config-grub {
> > kernel = "efi-grub";
> > signature-1 {
> > algo = "sha256,rsa2048";
> > sign-images = "kernel";
> > };
> > };
> > };
> > };
> >
> > Signed-off-by: Cristian Ciocaltea
> > ---
> > common/image-fit.c | 3 ++-
> > common/image.c | 1 +
> > include/image.h| 1 +
> > 3 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/image-fit.c b/common/image-fit.c
> > index 5c63c769de..19e313bf41 100644
> > --- a/common/image-fit.c
> > +++ b/common/image-fit.c
> > @@ -1925,7 +1925,8 @@ int fit_image_load(bootm_headers_t *images, ulong
> > addr,
> > image_type == IH_TYPE_FPGA ||
> > fit_image_check_os(fit, noffset, IH_OS_LINUX) ||
> > fit_image_check_os(fit, noffset, IH_OS_U_BOOT) ||
> > - fit_image_check_os(fit, noffset, IH_OS_OPENRTOS);
> > + fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
> > + fit_image_check_os(fit, noffset, IH_OS_EFI);
> >
> > /*
> >* If either of the checks fail, we should report an error, but
> > diff --git a/common/image.c b/common/image.c
> > index f17fa40c49..2e0e2b0e7f 100644
> > --- a/common/image.c
> > +++ b/common/image.c
> > @@ -134,6 +134,7 @@ static const table_entry_t uimage_os[] = {
> > { IH_OS_OPENRTOS, "openrtos", "OpenRTOS", },
> > #endif
> > { IH_OS_OPENSBI, "opensbi", "RISC-V OpenSBI", },
> > + { IH_OS_EFI, "efi", "EFI Firmware" },
> >
> > { -1, "", "", },
> > };
> > diff --git a/include/image.h b/include/image.h
> > index f4d2aaf53e..4a280b78e7 100644
> > --- a/include/image.h
> > +++ b/include/image.h
> > @@ -157,6 +157,7 @@ enum {
> > IH_OS_ARM_TRUSTED_FIRMWARE, /* ARM Trusted Firmware */
> > IH_OS_TEE, /* Trusted Execution Environment */
> > IH_OS_OPENSBI, /* RISC-V OpenSBI */
> > + IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
> >
> > IH_OS_COUNT,
> > };
> >
>
Re: [PATCH v2] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
Am 2019-12-10 15:55, schrieb Alex Marginean:
Passes on the primary address used by u-boot to Linux. The code does a
DT
fix-up for ENETC PFs and sets the primary MAC address in IERB. The
address
in IERB is restored on ENETC PCI functions at FLR.
I don't get the reason why this is done in a proprietary way. What is
the
difference between any other network interface whose hardware address is
set up in the generic u-boot code.
Also, shouldn't write_hwaddr callback be implemented instead of the
enetc_set_ierb_primary_mac()?
-michael
Signed-off-by: Alex Marginean
---
The code is called fom ft_board_setup in
board/freescale/ls1028a/ls1028a.c
mostly for consistency with other LS parts. I'm open to suggestions
though.
Changes in v2:
- fixed warning for fdt_fixup_enetc_mac being implicitly declared
board/freescale/ls1028a/ls1028a.c | 5 +++
drivers/net/fsl_enetc.c | 65 ++-
drivers/net/fsl_enetc.h | 3 ++
3 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index a9606b8865..1a82c95402 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -25,6 +25,7 @@
#include
#include
#include "../common/qixis.h"
+#include "../drivers/net/fsl_enetc.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -150,6 +151,10 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_icid(blob);
+#ifdef CONFIG_FSL_ENETC
+ fdt_fixup_enetc_mac(blob);
+#endif
+
return 0;
}
#endif
diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index 0ca7e838a8..3c043888db 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -14,6 +14,69 @@
#include "fsl_enetc.h"
+#define ENETC_DRIVER_NAME "enetc_eth"
+
+/*
+ * sets the MAC address in IERB registers, this setting is persistent
and
+ * carried over to Linux.
+ */
+static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn,
+ const u8 *enetaddr)
+{
+#ifdef CONFIG_ARCH_LS1028A
+/*
+ * LS1028A is the only part with IERB at this time and there are
plans to change
+ * its structure, keep this LS1028A specific for now
+ */
+#define IERB_BASE 0x1f080ULL
+#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 +
(vf) * 8 \
++ (n) * 4)
+
+static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3};
wrong indendation
+
+ u16 lower = *(const u16 *)(enetaddr + 4);
+ u32 upper = *(const u32 *)enetaddr;
+
+ if (ierb_fn_to_pf[devfn] < 0)
+ return;
it would be easier to read if ierb_fn_to_pf[devfn] would be assigned to
a local variable.
+
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper);
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower);
+#endif
+}
+
+/* sets up primary MAC addresses in DT/IERB */
+void fdt_fixup_enetc_mac(void *blob)
+{
+ struct pci_child_platdata *ppdata;
+ struct eth_pdata *pdata;
+ struct udevice *dev;
+ struct uclass *uc;
+ char path[256];
+ int offset;
+ int devfn;
+
+ uclass_get(UCLASS_ETH, );
+ uclass_foreach_dev(dev, uc) {
+ if (!dev->driver || !dev->driver->name ||
+ strcmp(dev->driver->name, ENETC_DRIVER_NAME))
+ continue;
+
+ pdata = dev_get_platdata(dev);
+ ppdata = dev_get_parent_platdata(dev);
+ devfn = PCI_FUNC(ppdata->devfn);
+
+ enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr);
+
+ snprintf(path, 256, "/soc/pcie@1f000/ethernet@%x,%x",
+PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn));
+ offset = fdt_path_offset(blob, path);
+ if (offset < 0)
+ continue;
+ fdt_setprop(blob, offset, "mac-address", pdata->enetaddr, 6);
+ }
+}
+
/*
* Bind the device:
* - set a more explicit name on the interface
@@ -583,7 +646,7 @@ static const struct eth_ops enetc_ops = {
};
U_BOOT_DRIVER(eth_enetc) = {
- .name = "enetc_eth",
+ .name = ENETC_DRIVER_NAME,
.id = UCLASS_ETH,
.bind = enetc_bind,
.probe = enetc_probe,
diff --git a/drivers/net/fsl_enetc.h b/drivers/net/fsl_enetc.h
index 0bb4cdff47..e441891468 100644
--- a/drivers/net/fsl_enetc.h
+++ b/drivers/net/fsl_enetc.h
@@ -226,4 +226,7 @@ int enetc_mdio_read_priv(struct enetc_mdio_priv
*priv, int addr, int devad,
int enetc_mdio_write_priv(struct enetc_mdio_priv *priv, int addr, int
devad,
int reg, u16 val);
+/* sets up primary MAC addresses in DT/IERB */
+void fdt_fixup_enetc_mac(void *blob);
+
#endif /* _ENETC_H */
Please pull u-boot-video
Hi Tom, please pull fixes for v2020.01. gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/1599 Travis-CI: https://travis-ci.org/vdsao/u-boot-video/builds/623099426 Thanks, Anatolij The following changes since commit 28a4516cf154d6f7e738f8e0519b41eccef5af5c: Merge branch '2019-12-05-master-imports' (2019-12-05 16:37:36 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/fixes-for-2020.01 for you to fetch changes up to 2cc393f32fd9ffcf47f4877e8d1345a7981a0d02: video: make BPP and ANSI configs optional (2019-12-06 16:38:51 +0100) - fix crash and board reset when drawing RLE8 bitmaps bigger than the framebuffer resolution - reduce dead code in video and console uclass routines (tested on mx53cx9020, sama5d2_xplained, stm32mp157c-ev1, stm32f746-disco, stm32f769-disco and wandboard) Anatolij Gustschin (2): video: add guards around 16bpp/32bbp code video: make BPP and ANSI configs optional Patrice Chotard (2): video: bmp: Fix video_splash_align_axis() video: bmp: Fix video_display_rle8_bitmap() configs/apalis_imx6_defconfig | 1 + configs/at91sam9x5ek_dataflash_defconfig | 1 + configs/at91sam9x5ek_mmc_defconfig | 1 + configs/at91sam9x5ek_nandflash_defconfig | 1 + configs/at91sam9x5ek_spiflash_defconfig| 1 + configs/chromebit_mickey_defconfig | 2 ++ configs/chromebook_jerry_defconfig | 2 ++ configs/chromebook_minnie_defconfig| 2 ++ configs/chromebook_speedy_defconfig| 2 ++ configs/colibri-imx6ull_defconfig | 3 +++ configs/colibri_imx6_defconfig | 1 + configs/colibri_imx7_defconfig | 3 +++ configs/colibri_imx7_emmc_defconfig| 3 +++ configs/colibri_t20_defconfig | 2 ++ configs/colibri_vf_defconfig | 1 + configs/evb-px30_defconfig | 3 +++ configs/evb-rk3288_defconfig | 2 ++ configs/evb-rk3399_defconfig | 2 ++ configs/firefly-rk3288_defconfig | 2 ++ configs/gazerbeam_defconfig| 3 +++ configs/ge_bx50v3_defconfig| 1 + configs/gurnard_defconfig | 2 ++ configs/harmony_defconfig | 2 ++ configs/imx6dl_icore_nand_defconfig| 1 + configs/imx6q_icore_nand_defconfig | 1 + configs/imx6qdl_icore_mmc_defconfig| 1 + configs/imx6qdl_icore_nand_defconfig | 1 + configs/libretech-ac_defconfig | 1 + configs/libretech-cc_defconfig | 1 + configs/m53menlo_defconfig | 1 + configs/medcom-wide_defconfig | 2 ++ configs/miqi-rk3288_defconfig | 2 ++ configs/mx53cx9020_defconfig | 1 + configs/mx6sabreauto_defconfig | 1 + configs/mx6sabresd_defconfig | 1 + configs/mx6ul_14x14_evk_defconfig | 3 +++ configs/mx6ul_9x9_evk_defconfig| 3 +++ configs/novena_defconfig | 1 + configs/nyan-big_defconfig | 1 + configs/opos6uldev_defconfig | 1 + configs/paz00_defconfig| 2 ++ configs/peach-pi_defconfig | 2 ++ configs/peach-pit_defconfig| 2 ++ configs/pico-dwarf-imx7d_defconfig | 3 +++ configs/pico-hobbit-imx7d_defconfig| 3 +++ configs/pico-imx7d_bl33_defconfig | 3 +++ configs/pico-imx7d_defconfig | 3 +++ configs/pico-nymph-imx7d_defconfig | 3 +++ configs/pico-pi-imx7d_defconfig| 3 +++ configs/pm9261_defconfig | 2 ++ configs/pm9263_defconfig | 2 ++ configs/puma-rk3399_defconfig | 2 ++ configs/rock2_defconfig| 2 ++ configs/rpi_0_w_defconfig | 1 + configs/rpi_2_defconfig| 1 + configs/rpi_3_32b_defconfig| 1 + configs/rpi_3_b_plus_defconfig | 1 + configs/rpi_3_defconfig| 1 + configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 1 + configs/rpi_arm64_defconfig| 1 + configs/rpi_defconfig | 1 + configs/sama5d27_som1_ek_mmc1_defconfig| 1 + configs/sama5d27_som1_ek_mmc_defconfig | 1 + configs/sama5d27_som1_ek_qspiflash_defconfig | 1 + configs/sama5d27_wlsom1_ek_mmc_defconfig | 1 + configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 1 +
RE: [PATCH v2 1/4] serial: ns16550: Support run-time configuration
Hi Simon,
> -Original Message-
> From: U-Boot On Behalf Of Simon Glass
> Sent: Monday, December 9, 2019 8:59 AM
> To: U-Boot Mailing List
> Cc: Stefan Roese ; Angelo Dureghello
> Subject: [PATCH v2 1/4] serial: ns16550: Support run-time configuration
>
> At present this driver uses an assortment of CONFIG options to control how
> it accesses the hardware. This is painful for platforms that are supposed to
> be
> controlled by a device tree or a previous-stage bootloader.
>
> Add a new CONFIG option to enable fully dynamic configuration. This
> controls register spacing, size, offset and endianness.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - runtime -> run-time
> - Enable run-time config for slimbootloader too
> - Improve Kconfig help based on Bin's comments
> - Use ns16550 in patch subject
>
> drivers/serial/Kconfig | 21 +++
> drivers/serial/ns16550.c | 57 ++
> --
> include/ns16550.h| 13 +
> 3 files changed, 83 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index
> ece7d87d4c..472a9f0929 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -598,6 +598,27 @@ config SYS_NS16550
> be used. It can be a constant or a function to get clock, eg,
> get_serial_clock().
>
> +config NS16550_DYNAMIC
> + bool "Allow NS16550 to be configured at runtime"
> + default y if SYS_COREBOOT || SYS_SLIMBOOTLOADER
> + help
> + Enable this option to allow device-tree control of the driver.
> +
> + Normally this driver is controlled by the following options:
> +
> + CONFIG_SYS_NS16550_PORT_MAPPED - indicates that port I/O is
> used for
> + access. If not enabled, then the UART is memory-mapped.
> + CONFIG_SYS_NS16550_MEM32 - if memory-mapped, indicates that
> 32-bit
> + access should be used (instead of 8-bit)
> + CONFIG_SYS_NS16550_REG_SIZE - indicates register width and also
> + endianness. If positive, big-endian access is used. If negative,
> + little-endian is used.
> +
> + It is not a good practice for a driver to be statically configured,
> + since it prevents the same driver being used for different types of
> + UARTs in a system. This option avoids this problem at the cost of a
> + slightly increased code size.
> +
> config INTEL_MID_SERIAL
> bool "Intel MID platform UART support"
> depends on DM_SERIAL && OF_CONTROL
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index
> 754b6e9921..96c4471efd 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -92,19 +92,57 @@ static inline int serial_in_shift(void *addr, int shift)
> #define CONFIG_SYS_NS16550_CLK 0 #endif
>
> +static void serial_out_dynamic(struct ns16550_platdata *plat, u8 *addr,
> +int value)
> +{
> + if (plat->flags & NS16550_FLAG_BE) {
> + if (plat->reg_width == 1)
> + writeb(value, addr + (1 << plat->reg_shift) - 1);
> + else if (plat->flags & NS16550_FLAG_IO)
> + out_be32(addr, value);
> + else
> + writel(value, addr);
> + } else {
> + if (plat->reg_width == 1)
> + writeb(value, addr);
> + else if (plat->flags & NS16550_FLAG_IO)
> + out_le32(addr, value);
> + else
> + writel(value, addr);
> + }
> +}
IO needs to use outb(). It breaks QEMU 0x3f8 IO (reg_width = 1, flags=IO).
I have verified 0x3f8 IO on QEMU and MMIO32 on APL with below code.
if (plat->flags & NS16550_FLAG_IO) {
outb(value, addr);
} else {
if (plat->flags & NS16550_FLAG_BE) {
if (plat->reg_width == 1)
writeb(value, addr + (1 << plat->reg_shift) -
1);
else
out_be32(addr, value);
} else {
if (plat->reg_width == 1)
writeb(value, addr);
else
out_le32(addr, value);
}
}
> +
> +static int serial_in_dynamic(struct ns16550_platdata *plat, u8 *addr) {
> + if (plat->flags & NS16550_FLAG_BE) {
> + if (plat->reg_width == 1)
> + return readb(addr + (1 << plat->reg_shift) - 1);
> + else if (plat->flags & NS16550_FLAG_IO)
> + return in_be32(addr);
> + else
> + return readl(addr);
> + } else {
> + if (plat->reg_width == 1)
> + return readb(addr);
> + else if (plat->flags & NS16550_FLAG_IO)
> + return in_le32(addr);
> + else
> + return
Re: [PATCH v2 2/4] bootm: Add a bootm command for type IH_OS_EFI
On 12/10/19 9:56 AM, Cristian Ciocaltea wrote: Add support for booting EFI binaries contained in FIT images. A typical usage scenario is chain-loading GRUB2 in a verified boot environment. Signed-off-by: Cristian Ciocaltea Reading through the code it looks good. What I really need to do is analyze the address usage on the sandbox. To me it is unclear if images->fdt_addr is a physical address or an address in the address space of the sandbox. Did you test this on the sandbox? You can use lib/efi_loader/helloworld.efi as a binary and the 'host load hostfs' command for loading the FIT image. Shouldn't we add booting a UEFI FIT image to the Python test in test/py/tests/test_fit.py? doc/uImage.FIT/signature.txt describes that several properties of the RSA public key should be stored in the control device tree. Unfortunately no example is supplied in which format they should be stored. Could you send me an example, please. I found the following https://github.com/bn121rajesh/ipython-notebooks/blob/master/BehindTheScene/RSAPublicKeyParamsUBoot/rsa_public_key_params_uboot.ipynb Is this an accurate description? Or how do you get the parameters from your RSA public key? Best regards Heinrich
serial_bcm283x_mu driver crashes on RPi CM 1
Hi all,
I've been working on a project recently that uses a Raspberry Pi Compute Module
1, and it uses U-Boot as a bootloader. The main UART port is required for the
project, so the mini-UART is required to be used for the console. Unfortunately
I've not been able to get U-Boot to boot when enabling the mini-UART port, and
I'm only greeted by a rainbow splash screen when I enable it and select it for
use as the console.
Some background on the work I've done to get to this point:
- I'm using U-Boot 2019.10 as a base.
- I made a copy of /arch/arm/dts/bcm2835-rpi-cm1-io1.dts and appended the
following line to the end to enable the secondary UART port:
{
pinctrl-names = "default";
pinctrl-0 = <_gpio14>;
status = "okay";
};
This new dts file is added to the Makefile and selected in KConfig.
- I modified /drivers/serial/serial_bcm283x_mu.c to remove the checks for pin
MUXing. Since this only checks GPIO14, it wasn't going to work when the pin is
actually on GPIO 40 and the check was useless for my purposes anyway.
- I set CONSOLE_CONS_INDEX to 2 (selecting serial1) in KConfig. This selects
the mini-UART which is set as serial1 in the aliases in
/arch/arc/dts/bcm283x.dtsi.
The result of this is that the rainbow splash screen comes up and nothing is
sent from either serial port. However if I set CONFIG_CONS_INDEX to 1, I get
output on the main UART port as normal.
Setting CONFIG_OF_BOARD instead of CONFIG_OF_EMBED makes no difference. There
was a time where I was able to get some early boot messages, and setting
CONFIG_CONS_INDEX to 2 did cause U-Boot to select the mini-UART, but the
messages stopped just before relocation. Again, changing the console index back
to 1 would select the main UART and the messages would continue all the way to
boot. I haven't been able to get these early messages to work recently however.
I have a slight suspicion that it may be something to do with pin MUXing, since
changing the uart0 pins in the device-tree to GPIO 32 causes the console to TX
over both GPIO 32 and GPIO 14, but nothing can be received on either port. This
doesn't seem like the correct behaviour.
At this point I'm really stuck. I'm able to modify the DTS to set the pin
MUXings (I hope anyway), and I can select the correct serial port, however I
can't debug this any further since the crash prevents any debug info from
coming out of the board on 2019.10, even if I enable early UART debugging.
Has anyone successfully managed to get this UART port working on the Compute
Modules? Or have any tips on how to debug it?
I'm very appreciative of any help I can get.
Kindest regards,
Ed
Re: [PATCH v2 1/4] image: Add IH_OS_EFI for EFI chain-load boot
On 12/10/19 9:56 AM, Cristian Ciocaltea wrote:
Add a new OS type to be used for chain-loading an EFI compatible
firmware or boot loader like GRUB2, possibly in a verified boot
scenario.
Bellow is sample ITS file that generates a FIT image supporting
secure boot. Please note the presence of 'os = "efi";' line, which
identifies the currently introduced OS type:
/ {
#address-cells = <1>;
images {
efi-grub {
description = "GRUB EFI";
data = /incbin/("EFI/BOOT/bootarm.efi");
According to UEFI Spec 2.8 the default file name for 32 bit ARM is
BOOTARM.EFI. But GRUB calls the file grubarm.efi.
So shouldn't we use grubarm.efi here as filename?
You use EFI/BOOT as directory name. I think this path does not add
benefit to the example. The other *.its files also come without any
specific path.
Best regards
Heinrich
type = "kernel_noload";
arch = "arm";
os = "efi";
compression = "none";
load = <0x0>;
entry = <0x0>;
hash-1 {
algo = "sha256";
};
};
};
configurations {
default = "config-grub";
config-grub {
kernel = "efi-grub";
signature-1 {
algo = "sha256,rsa2048";
sign-images = "kernel";
};
};
};
};
Signed-off-by: Cristian Ciocaltea
---
common/image-fit.c | 3 ++-
common/image.c | 1 +
include/image.h| 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index 5c63c769de..19e313bf41 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1925,7 +1925,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
image_type == IH_TYPE_FPGA ||
fit_image_check_os(fit, noffset, IH_OS_LINUX) ||
fit_image_check_os(fit, noffset, IH_OS_U_BOOT) ||
- fit_image_check_os(fit, noffset, IH_OS_OPENRTOS);
+ fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
+ fit_image_check_os(fit, noffset, IH_OS_EFI);
/*
* If either of the checks fail, we should report an error, but
diff --git a/common/image.c b/common/image.c
index f17fa40c49..2e0e2b0e7f 100644
--- a/common/image.c
+++ b/common/image.c
@@ -134,6 +134,7 @@ static const table_entry_t uimage_os[] = {
{ IH_OS_OPENRTOS, "openrtos", "OpenRTOS", },
#endif
{ IH_OS_OPENSBI, "opensbi","RISC-V OpenSBI", },
+ { IH_OS_EFI, "efi","EFI Firmware" },
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index f4d2aaf53e..4a280b78e7 100644
--- a/include/image.h
+++ b/include/image.h
@@ -157,6 +157,7 @@ enum {
IH_OS_ARM_TRUSTED_FIRMWARE, /* ARM Trusted Firmware */
IH_OS_TEE, /* Trusted Execution Environment */
IH_OS_OPENSBI, /* RISC-V OpenSBI */
+ IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
IH_OS_COUNT,
};
Re: [PATCH v2 4/4] doc: uefi.rst: Document launching UEFI binaries from FIT images
On 12/10/19 9:56 AM, Cristian Ciocaltea wrote: This patch adds a new section "Launching a UEFI binary from a FIT image" documenting the usage of the CONFIG_BOOTM_EFI extension to bootm command that offers a secure boot alternative for UEFI binaries such as GRUB2. Signed-off-by: Cristian Ciocaltea Reviewed-by: Heinrich Schuchardt
Re: [PATCH 2/2] configs: sandbox: enable CONFIG_CMD_BOOTEFI_SELFTEST
On 12/10/19 1:58 PM, Simon Glass wrote: Hi Heinrich, On Sat, 9 Nov 2019 at 01:44, Heinrich Schuchardt wrote: Activate UEFI unit tests on the sandbox. Signed-off-by: Heinrich Schuchardt --- configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + 4 files changed, 4 insertions(+) Unfortunately this slows down the testing too much, nearly doubling the time in my tests. I think the EFI console tests need to be modified to run in C instead of all the drain_console() and p.timeout stuff. We need an effort to speed up the tests, but certainly cannot make them any slower. Hello Simon, thanks for pointing at the excessive timeout. In test_efi_selftest_text_input() and test_efi_selftest_text_input_ex() we call drain_console() a lot indeed. I am using the Python tests on real hardware. The text input and output on the test systems uses the serial console. Whether you use C or Python code to feed the serial adapter will not change the time needed to drain the console. We expect less then 50 characters of output per test step. At 9600 baud draining 50 characters would require 52 ms. So I would suggest that we add a parameter timeout to drain_console() which defaults to 1000 ms as currently. But in the test we can set it to 50 ms. p.timeout could be changed likewise. What are your thoughts? Best regards Heinrich
Re: gtlab slow?
Hi Simon, On Tue, 2019-12-10 at 05:48 -0700, Simon Glass wrote: > Hi, > > I sometimes find that gitlab.denx.de is very slow. Just now is is > worse than usual - it has taken almost 10 minutes to push a branch and > still not finished. I am getting a 503 error on the web site. > > Any ideas? Yes, we noticed that as well but so far have failed to find out the exact reason. Server-side we see horrible load spikes while the CPU is essentially in idle and no notable IO is happening. I personally believe it might have something to do with the virtualization technology but we don't have a certain answer yet. I added Claudius in CC, he might know more ... > Regards, > Simon -- Harald
Re: [PATCH 1/5] remoteproc: elf_loader: Add elf resource table load support
Btw, I sent a v2 for this patch: https://www.mail-archive.com/u-boot@lists.denx.de/msg346085.html On 10/12/2019 4:18 PM, Simon Glass wrote: > Hi Fabien, > > On Wed, 30 Oct 2019 at 03:50, Fabien DESSENNE wrote: >> Hi Simon >> >> On 30/10/2019 2:49 AM, Simon Glass wrote: >>> Hi Fabien, >>> >>> On Tue, 22 Oct 2019 at 03:08, Fabien DESSENNE >>> wrote: Hi Simon, On 22/10/2019 1:47 AM, Simon Glass wrote: > Hi Fabien, > > On Wed, 9 Oct 2019 at 09:36, Fabien Dessenne > wrote: >> Add rproc_elf_load_rsc_table(), which searches for a resource table in >> an elf64/elf32 image, and if found, copies it to device memory. >> Add also the elf32 and elf64 variants of this API. >> Add a test for this. >> >> Signed-off-by: Fabien Dessenne >> --- >> drivers/remoteproc/rproc-elf-loader.c | 269 >> ++ >> include/remoteproc.h | 70 + >> test/dm/remoteproc.c | 91 ++-- >> 3 files changed, 419 insertions(+), 11 deletions(-) >> > If you are putting stuff in the image, should you use binman to build > the image, then find the contents using the binman tables? The "resource table" may be located anywhere, there is no strict rule defining where it is expected to be. Nevertheless the Linux remoteproc[1] and OpenAmp (running RTOS) [2] frameworks expect the resource table to be stored in a dedicated ELF section. Both of them run some ELF scanning to find out this section. The proposed patch is for the "ELF section" variant of the resource table. Other variants like binman packing may be proposed as well, both implementations can coexist alongside. >>> So why not use binman to pack the image and find the components? This >>> is U-Boot, after all. >>> >> Packing the firmware together with the other U-Boot components is >> acceptable if the firmware is controlled only by U-Boot. >> My requirement is that the coprocessor firmware shall be loaded by >> U-Boot or by Linux. >> >> You can have a look at [1] for more details on the way this is handled >> on STM32 MPU. In that case, the .elf firmware is stored in a in File >> System that can be read by both U-Boot and Linux. >> > Where is the coprocessor firmware stored, then? > >> If we have the firmware packed in the image (for U-Boot), we need to >> have a copy in the FileSystem (for Linux) which would not be a good idea. > What type of filesystem do you use? I don't see any filesystem access > in this patch though. > >> BR >> Fabien >> >> [1] https://wiki.st.com/stm32mpu/index.php/Boot_chains_overview > Regards, > Simon
Re: [PATCH 1/5] remoteproc: elf_loader: Add elf resource table load support
Hi Simon, On 10/12/2019 4:18 PM, Simon Glass wrote: > Hi Fabien, > > On Wed, 30 Oct 2019 at 03:50, Fabien DESSENNE wrote: >> Hi Simon >> >> On 30/10/2019 2:49 AM, Simon Glass wrote: >>> Hi Fabien, >>> >>> On Tue, 22 Oct 2019 at 03:08, Fabien DESSENNE >>> wrote: Hi Simon, On 22/10/2019 1:47 AM, Simon Glass wrote: > Hi Fabien, > > On Wed, 9 Oct 2019 at 09:36, Fabien Dessenne > wrote: >> Add rproc_elf_load_rsc_table(), which searches for a resource table in >> an elf64/elf32 image, and if found, copies it to device memory. >> Add also the elf32 and elf64 variants of this API. >> Add a test for this. >> >> Signed-off-by: Fabien Dessenne >> --- >> drivers/remoteproc/rproc-elf-loader.c | 269 >> ++ >> include/remoteproc.h | 70 + >> test/dm/remoteproc.c | 91 ++-- >> 3 files changed, 419 insertions(+), 11 deletions(-) >> > If you are putting stuff in the image, should you use binman to build > the image, then find the contents using the binman tables? The "resource table" may be located anywhere, there is no strict rule defining where it is expected to be. Nevertheless the Linux remoteproc[1] and OpenAmp (running RTOS) [2] frameworks expect the resource table to be stored in a dedicated ELF section. Both of them run some ELF scanning to find out this section. The proposed patch is for the "ELF section" variant of the resource table. Other variants like binman packing may be proposed as well, both implementations can coexist alongside. >>> So why not use binman to pack the image and find the components? This >>> is U-Boot, after all. >>> >> Packing the firmware together with the other U-Boot components is >> acceptable if the firmware is controlled only by U-Boot. >> My requirement is that the coprocessor firmware shall be loaded by >> U-Boot or by Linux. >> >> You can have a look at [1] for more details on the way this is handled >> on STM32 MPU. In that case, the .elf firmware is stored in a in File >> System that can be read by both U-Boot and Linux. >> > Where is the coprocessor firmware stored, then? Please have a look to [STM32MP15_Flash_mapping] which describes how u-boot, linux and the coprocessor firmwares can be stored in flash memory. Both U-boot and Linux use an EXT4 filesystem (eg bootfs partition) to read the coprocessor .elf firmware file. When it is read (it is then in DDR), U-boot or Linux parses it, in order to copy the resource table and the different ELF segments into appropriate memory addresses. [STM32MP15_Flash_mapping] https://wiki.st.com/stm32mpu/wiki/STM32MP15_Flash_mapping > >> If we have the firmware packed in the image (for U-Boot), we need to >> have a copy in the FileSystem (for Linux) which would not be a good idea. > What type of filesystem do you use? I don't see any filesystem access > in this patch though. As described above, an EXT4 filesystem is a good example. This patch is not about filesystem but about how the .elf contents available in DDR memory (after is has been loaded from somewhere) is parsed. > >> BR >> Fabien >> >> [1] https://wiki.st.com/stm32mpu/index.php/Boot_chains_overview > Regards, > Simon
Re: [PATCH v3 0/4] arm64: sun50i: Add support for Orange Pi 3
On 03/12/2019 09:45, Andre Heider wrote: Changes since v2: * drop "sunxi: board: Use eth_env_set_enetaddr_by_index()" as it breaks compilation without CONFIG_NET * add "sunxi: board: extract creating a unique sid into a helper function" and use it for the the bdaddr so that it work without ethernet devices * use `if (CONFIG_FIXUP_BDADDR[0])` as suggested by Ondřej to give the compiler a better chance of discarding the function if the knob isn't set Jagan, Maxime, does v3 look okay to you guys? Anything I need to address to get this in? Thanks! Andre Changes since v1: * add CONFIG_FIXUP_BDADDR so fixing up a bdaddr is reusable * try to use "bdaddr" first, then fall back to generating an address Notes: * the kernel patch for btbcm to accept the "local-bd-address" property is on master and will be in v5.5-rc1 Andre Heider (4): sunxi: board: extract creating a unique sid into a helper function arm: sunxi: add a config option to fixup a Bluetooth address arm64: dts: sync Allwinner H6 files arm64: dts: sun50i: Add support for Orange Pi 3 arch/arm/dts/Makefile | 1 + arch/arm/dts/sun50i-h6-beelink-gs1.dts | 27 +++ arch/arm/dts/sun50i-h6-orangepi-3.dts | 287 + arch/arm/dts/sun50i-h6-orangepi.dtsi | 4 + arch/arm/dts/sun50i-h6-pine-h64.dts| 4 + arch/arm/dts/sun50i-h6.dtsi| 137 ++-- arch/arm/mach-sunxi/Kconfig| 11 + board/sunxi/MAINTAINERS| 5 + board/sunxi/board.c| 139 configs/orangepi_3_defconfig | 18 ++ 10 files changed, 569 insertions(+), 64 deletions(-) create mode 100644 arch/arm/dts/sun50i-h6-orangepi-3.dts create mode 100644 configs/orangepi_3_defconfig
[PATCH 1/2] menu: Make some parts of the menu available to other components
From: Frieder Schrempf
In order to iterate over the menu entries and match for a specific
name in the pxe boot, we need to properly export the needed structs
and functions.
Signed-off-by: Frieder Schrempf
---
common/menu.c | 31 +--
include/menu.h | 34 +-
2 files changed, 34 insertions(+), 31 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index 7b66d199a9..82b03f17f7 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -12,36 +12,7 @@
#include "menu.h"
-/*
- * Internally, each item in a menu is represented by a struct menu_item.
- *
- * These items will be alloc'd and initialized by menu_item_add and destroyed
- * by menu_item_destroy, and the consumer of the interface never sees that
- * this struct is used at all.
- */
-struct menu_item {
- char *key;
- void *data;
- struct list_head list;
-};
-/*
- * The menu is composed of a list of items along with settings and callbacks
- * provided by the user. An incomplete definition of this struct is available
- * in menu.h, but the full definition is here to prevent consumers from
- * relying on its contents.
- */
-struct menu {
- struct menu_item *default_item;
- int timeout;
- char *title;
- int prompt;
- void (*item_data_print)(void *);
- char *(*item_choice)(void *);
- void *item_choice_data;
- struct list_head items;
- int item_cnt;
-};
/*
* An iterator function for menu items. callback will be called for each item
@@ -51,7 +22,7 @@ struct menu {
* used for search type operations. It is also safe for callback to remove the
* item from the list of items.
*/
-static inline void *menu_items_iter(struct menu *m,
+inline void *menu_items_iter(struct menu *m,
void *(*callback)(struct menu *, struct menu_item *, void *),
void *extra)
{
diff --git a/include/menu.h b/include/menu.h
index 2d227c20bd..b3f8db87e4 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -6,8 +6,40 @@
#ifndef __MENU_H__
#define __MENU_H__
-struct menu;
+/*
+ * Internally, each item in a menu is represented by a struct menu_item.
+ *
+ * These items will be alloc'd and initialized by menu_item_add and destroyed
+ * by menu_item_destroy, and the consumer of the interface never sees that
+ * this struct is used at all.
+ */
+struct menu_item {
+ char *key;
+ void *data;
+ struct list_head list;
+};
+
+/*
+ * The menu is composed of a list of items along with settings and callbacks
+ * provided by the user. An incomplete definition of this struct is available
+ * in menu.h, but the full definition is here to prevent consumers from
+ * relying on its contents.
+ */
+struct menu {
+ struct menu_item *default_item;
+ int timeout;
+ char *title;
+ int prompt;
+ void (*item_data_print)(void *);
+ char *(*item_choice)(void *);
+ void *item_choice_data;
+ struct list_head items;
+ int item_cnt;
+};
+void *menu_items_iter(struct menu *m,
+ void *(*callback)(struct menu *, struct menu_item *, void *),
+ void *extra);
struct menu *menu_create(char *title, int timeout, int prompt,
void (*item_data_print)(void *),
char *(*item_choice)(void *),
--
2.17.1
[PATCH 2/2] pxe: Get default selection from board type if label matches
From: Frieder Schrempf
In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.
This is useful in combination with SPL that loads a FIT image with
U-Boot and multiple DTBs. SPL can detect the board and choose the
matching configuration in the FIT by using
board_fit_config_name_match().
Signed-off-by: Frieder Schrempf
---
cmd/pxe_utils.c | 62 +
1 file changed, 62 insertions(+)
diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index a636346bb5..510957e68f 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1219,6 +1219,61 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp,
unsigned long menucfg)
return cfg;
}
+#ifdef CONFIG_OF_CONTROL
+/*
+ * Check if an item's name matches a provided string, pointed to by extra.
+ *
+ * This is called via menu_items_iter, so it returns a pointer to the item if
+ * the name matches, and returns NULL otherwise.
+ */
+static inline void *pxe_item_name_match(struct menu *m, struct menu_item *item,
+ void *extra)
+{
+ char *name = extra;
+ struct pxe_label *label;
+
+ if (!name || !item->key)
+ return NULL;
+
+ label = (struct pxe_label *)item->data;
+
+ if (strcmp(label->name, name) == 0)
+ return item;
+
+ return NULL;
+}
+
+/*
+ * Find the first item with a name matching the given name, if any exists.
+ */
+inline struct menu_item *menu_item_by_pxe_name(struct menu *m, char *name)
+{
+ return menu_items_iter(m, pxe_item_name_match, name);
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ struct menu_item *item = NULL;
+ const char *model;
+
+ model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+ if (!model)
+ return 0;
+
+ item = menu_item_by_pxe_name(m, model);
+
+ if (item) {
+ printf("Menu entry %s fits detected board. " \
+ "Use as default selection...\n", item->key);
+ m->default_item = item;
+ }
+
+ return 0;
+}
+#endif
+
/*
* Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
* menu code.
@@ -1257,6 +1312,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
/*
* After we've created items for each label in the menu, set the
* menu's default label if one was specified.
+* If OF_CONTROL is enabled and we don't have a default specified,
+* we try to use an entry that matches the board/model name as default.
*/
if (default_num) {
err = menu_default_set(m, default_num);
@@ -1268,6 +1325,11 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu
*cfg)
printf("Missing default: %s\n", cfg->default_label);
}
+#ifdef CONFIG_OF_CONTROL
+ } else if (pxe_runtime_select_menu_default(m)) {
+ menu_destroy(m);
+ return NULL;
+#endif
}
return m;
--
2.17.1
Re: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
On Tue, Dec 10, 2019 at 04:24:09PM +0100, Michal Simek wrote: > On 10. 12. 19 14:56, Tom Rini wrote: > > On Tue, Dec 10, 2019 at 01:40:42PM +0100, Michal Simek wrote: > >> Hi Tom, > >> > >> On 09. 12. 19 16:19, Michal Simek wrote: > >>> Hi, > >>> > >>> over years a lot of new Xilinx ZynqMP board have been added to U-Boot with > >>> corresponding defconfigs. Also a lot of drivers have been moved to DM that > >>> we can make one generic configuration with one defconfig. > >>> Nand still needs to be validated that's why dc2/dc3 are not moved yet. > >>> > >>> Boards can be build like this: > >>> export DEVICE_TREE="avnet-ultra96-rev1" > >>> make xilinx_zynqmp_virt_defconfig > >>> make -j > >>> > >>> Series depends on patches sent before that's why here is full tree: > >>> https://github.com/michalsimek/u-boot/tree/20191209-mainline > >> > >> This series will require some changes in CI loops because right now > >> I didn't setup default device tree (CONFIG_DEFAULT_DEVICE_TREE) to > >> "force" everybody to properly pass DEVICE_TREE via command line. > >> I can't use OF_BOARD because then SPL is built without DT at all. > >> > >> How do you think I should handle it for CI loops? > >> 1. I can remove this configuration but it will be only one at the end > >> that's why not a good solution. > >> 2. Add generic option to run some commands before tests like export > >> DEVICE_TREE above > >> 3. provide different options for SPL/full u-boot how > >> OF_SEPARATE/OF_BOARD is handled. > > > > So, for CI are you wanting to test most device trees, or just one? > > All zynqmp dtses are built by default. Right, but for what I thought you're saying the real use is, you pass just a single device tree, right? If so, do you think we should loop over each, or just build one? > > Are > > we able to run one of these device trees via QEMU? > > zynqmp is covered just by buildman not by pytest. I have this on my todo > list for some time but there will be other issues with mainline qemu to > do so. OK, so something to improve for the future, and after we handle this "today" problem. > > If we can run the > > virt defconfig via qemu, we should just update/extend that stanza in the > > CI files to set DEVICE_TREE and exclude building it from the normal > > jobs. > > Based on next generation Xilinx Versal where we use OF_BOARD qemu is > generated DT for model self to ensure that only stuff which are emulated > are provided to SW. Logic for dt selection is quite simply. > https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/mach-versal/cpu.c#L112 > But Versal is not using SPL and SPL needs initial DT. Also standard > Xilinx boot flow on zynq/zynqmp is not using SPL and SPL is community > driven effort. > > At the end of the day I would like to use the same functionality across > boards. It means full u-boot should check one fixed location for DT > first with priority. For this OF_SEPARATE can be also used because > board_fdt_blob_setup can be overwritten for these cases too. > https://gitlab.denx.de/u-boot/u-boot/blob/master/lib/fdtdec.c#L1190 > > > If we can't run via qemu then yes, something like option #2 and > > we set DEVICE_TREE in one job and export it if set in the build job. > > It means for qemu there is no real need to build dts from source tree at > all. > Let me look at #2 for CI. OK, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
On 10. 12. 19 14:56, Tom Rini wrote: > On Tue, Dec 10, 2019 at 01:40:42PM +0100, Michal Simek wrote: >> Hi Tom, >> >> On 09. 12. 19 16:19, Michal Simek wrote: >>> Hi, >>> >>> over years a lot of new Xilinx ZynqMP board have been added to U-Boot with >>> corresponding defconfigs. Also a lot of drivers have been moved to DM that >>> we can make one generic configuration with one defconfig. >>> Nand still needs to be validated that's why dc2/dc3 are not moved yet. >>> >>> Boards can be build like this: >>> export DEVICE_TREE="avnet-ultra96-rev1" >>> make xilinx_zynqmp_virt_defconfig >>> make -j >>> >>> Series depends on patches sent before that's why here is full tree: >>> https://github.com/michalsimek/u-boot/tree/20191209-mainline >> >> This series will require some changes in CI loops because right now >> I didn't setup default device tree (CONFIG_DEFAULT_DEVICE_TREE) to >> "force" everybody to properly pass DEVICE_TREE via command line. >> I can't use OF_BOARD because then SPL is built without DT at all. >> >> How do you think I should handle it for CI loops? >> 1. I can remove this configuration but it will be only one at the end >> that's why not a good solution. >> 2. Add generic option to run some commands before tests like export >> DEVICE_TREE above >> 3. provide different options for SPL/full u-boot how >> OF_SEPARATE/OF_BOARD is handled. > > So, for CI are you wanting to test most device trees, or just one? All zynqmp dtses are built by default. > Are > we able to run one of these device trees via QEMU? zynqmp is covered just by buildman not by pytest. I have this on my todo list for some time but there will be other issues with mainline qemu to do so. > If we can run the > virt defconfig via qemu, we should just update/extend that stanza in the > CI files to set DEVICE_TREE and exclude building it from the normal > jobs. Based on next generation Xilinx Versal where we use OF_BOARD qemu is generated DT for model self to ensure that only stuff which are emulated are provided to SW. Logic for dt selection is quite simply. https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/mach-versal/cpu.c#L112 But Versal is not using SPL and SPL needs initial DT. Also standard Xilinx boot flow on zynq/zynqmp is not using SPL and SPL is community driven effort. At the end of the day I would like to use the same functionality across boards. It means full u-boot should check one fixed location for DT first with priority. For this OF_SEPARATE can be also used because board_fdt_blob_setup can be overwritten for these cases too. https://gitlab.denx.de/u-boot/u-boot/blob/master/lib/fdtdec.c#L1190 > If we can't run via qemu then yes, something like option #2 and > we set DEVICE_TREE in one job and export it if set in the build job. It means for qemu there is no real need to build dts from source tree at all. Let me look at #2 for CI. Thanks, Michal
Re: [PATCH] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
On Tue, 10 Dec 2019 at 17:03, Alexandru Marginean
wrote:
>
> On 12/10/2019 3:54 PM, Vladimir Oltean wrote:
> > Hi Alex,
> >
> > On Tue, 10 Dec 2019 at 16:21, Alex Marginean
> > wrote:
> >>
> >> Passes on the primary address used by u-boot to Linux. The code does a DT
> >> fix-up for ENETC PFs and sets the primary MAC address in IERB. The address
> >> in IERB is restored on ENETC PCI functions at FLR.
> >>
> >> Signed-off-by: Alex Marginean
> >> ---
> >>
> >> The code is called fom ft_board_setup in board/freescale/ls1028a/ls1028a.c
> >> mostly for consistency with other LS parts. I'm open to suggestions
> >> though.
> >>
> >> board/freescale/ls1028a/ls1028a.c | 4 ++
> >> drivers/net/fsl_enetc.c | 65 ++-
> >> 2 files changed, 68 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/board/freescale/ls1028a/ls1028a.c
> >> b/board/freescale/ls1028a/ls1028a.c
> >> index 3977ecf896..fac03f55e9 100644
> >> --- a/board/freescale/ls1028a/ls1028a.c
> >> +++ b/board/freescale/ls1028a/ls1028a.c
> >> @@ -150,6 +150,10 @@ int ft_board_setup(void *blob, bd_t *bd)
> >>
> >> fdt_fixup_icid(blob);
> >>
> >> +#ifdef CONFIG_FSL_ENETC
> >> + fdt_fixup_enetc_mac(blob);
> >> +#endif
> >> +
> >> return 0;
> >> }
> >> #endif
> >> diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
> >> index 02c1ee70d9..f8fe7d4d8d 100644
> >> --- a/drivers/net/fsl_enetc.c
> >> +++ b/drivers/net/fsl_enetc.c
> >> @@ -14,6 +14,69 @@
> >>
> >> #include "fsl_enetc.h"
> >>
> >> +#define ENETC_DRIVER_NAME "enetc_eth"
> >> +
> >> +/*
> >> + * sets the MAC address in IERB registers, this setting is persistent and
> >> + * carried over to Linux.
> >> + */
> >> +static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn,
> >> + const u8 *enetaddr)
> >> +{
> >> +#ifdef CONFIG_ARCH_LS1028A
> >> +/*
> >> + * LS1028A is the only part with IERB at this time and there are plans to
> >> change
> >> + * its structure, keep this LS1028A specific for now
> >> + */
> >> +#define IERB_BASE 0x1f080ULL
> >> +#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 + (vf)
> >> * 8 \
> >> ++ (n) * 4)
> >> +
> >> +static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3};
> >> +
> >> + u16 lower = *(const u16 *)(enetaddr + 4);
> >> + u32 upper = *(const u32 *)enetaddr;
> >> +
> >> + if (ierb_fn_to_pf[devfn] < 0)
> >> + return;
> >> +
> >> + out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper);
> >> + out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower);
> >> +#endif
> >> +}
> >> +
> >> +/* sets up primary MAC addresses in DT/IERB */
> >> +void fdt_fixup_enetc_mac(void *blob)
> >> +{
> >> + struct pci_child_platdata *ppdata;
> >> + struct eth_pdata *pdata;
> >> + struct udevice *dev;
> >> + struct uclass *uc;
> >> + char path[256];
> >> + int offset;
> >> + int devfn;
> >> +
> >> + uclass_get(UCLASS_ETH, );
> >> + uclass_foreach_dev(dev, uc) {
> >> + if (!dev->driver || !dev->driver->name ||
> >> + strcmp(dev->driver->name, ENETC_DRIVER_NAME))
> >> + continue;
> >> +
> >> + pdata = dev_get_platdata(dev);
> >> + ppdata = dev_get_parent_platdata(dev);
> >> + devfn = PCI_FUNC(ppdata->devfn);
> >> +
> >> + enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr);
> >> +
> >> + snprintf(path, 256, "/soc/pcie@1f000/ethernet@%x,%x",
> >> +PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn));
> >> + offset = fdt_path_offset(blob, path);
> >> + if (offset < 0)
> >> + continue;
> >> + fdt_setprop(blob, offset, "mac-address", pdata->enetaddr,
> >> 6);
> >
> > The Linux Documentation/devicetree/bindings/net/ethernet.txt says:
> >
> > - local-mac-address: array of 6 bytes, specifies the MAC address that was
> >assigned to the network device;
> > - mac-address: array of 6 bytes, specifies the MAC address that was last
> > used by
> >the boot program; should be used in cases where the MAC address assigned
> > to
> >the device by the boot program is different from the "local-mac-address"
> >property;
> >
> > I'm not sure which property should be used here, but I think
> > local-mac-address.
>
>
> U-Boot does use (well, if needed) that address, if that is of any
> importance.
> of_get_mac_address in Linux has this comment:
> /**
> * Search the device tree for the best MAC address to use.
> 'mac-address' is
> * checked first, because that is supposed to contain to "most recent" MAC
> * address. If that isn't set, then 'local-mac-address' is checked next,
> * because that is the default address. If that isn't set, then the
> obsolete
> * 'address' is
Re: [PATCH V2 4/4] pytest: aes: add test for aes192 and aes256
Hi Philippe, On Thu, 31 Oct 2019 at 07:33, Philippe REYNES wrote: > > Hi Simonn > > > Hi Philippe, > > > > On Tue, 29 Oct 2019 at 11:29, Philippe Reynes > > wrote: > >> > >> This commit update the aes tests to check the > >> aes192 and aes256. > >> > >> Signed-off-by: Philippe Reynes > >> --- > >> test/py/tests/test_aes.py | 118 > >> +++--- > >> 1 file changed, 91 insertions(+), 27 deletions(-) > > > > Any way we could write these tests in C? > > I'm not sure to understand. Do you mean > - write this code in C and then call it from python (in pytest) ? > - write this test in C to implement a ut command (like UT_TIME) ? I think I mean both. Write the test in C as a 'ut ae' command, for example, then call it from a pytest. It should be much faster. Regards, Simon
Re: [PATCH v2 2/4] regmap: Allow providing read/write callbacks through struct regmap_config
Hi Jean-Jacques,
On Tue, 5 Nov 2019 at 04:47, Jean-Jacques Hiblot wrote:
>
> Some linux drivers provide their own read/write functions to access data
> from/of the regmap. Adding support for it.
>
> Signed-off-by: Jean-Jacques Hiblot
>
> ---
>
> Changes in v2:
> - Only use custom accessors if {,SPL,TPL}_REGMAP_ACCESSORS is enabled
>
> drivers/core/Kconfig | 25 +
> drivers/core/regmap.c | 22 --
> include/regmap.h | 28 +---
> 3 files changed, 70 insertions(+), 5 deletions(-)
Coming back to the discussion on driver model
How do you specify the fields? I would expect that this would be done
in the driver tree? Perhaps in a subnode of the device?
Just to state what I see as the advantages of using a separate device
for access:
- Remove the #ifdef in the regmap struct
- Easy to specify the behaviour in a device-tree node
- Easy to extend as the child device can do what it likes with respect to access
Disadvantage is that it takes a bit more space.
Regards,
Simon
Re: dm: rtc: random Gitlab results for dm_test_rtc_dual()
Hi Heinrich, On Wed, 30 Oct 2019 at 22:10, Heinrich Schuchardt wrote: > > Hello Simon, > > the gitlab 'sandbox test.py' job seems to be kind of a lottery: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/25678 > > Job succeeded > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/25499 > > /u-boot-efi/test/dm/rtc.c:167, dm_test_rtc_dual(): > -EINVAL == cmp_times(, , false): > Expected -22, got 0\r\r\nFailures: 1'.endswith > > dm_test_rtc_dual() fails or succeeds for the same code. > > @Tom: > Did you also see such spurious results? > > At first sight I could not anything wrong in the dm_test_rtc_dual() test > assuming that the Gitlab environment provides a monotonic clock for the > time() function. > > The findings below do not explain the problem: > > now2 is read but never used. We are testing that we can get the time > from emul2 later on. So I think this line is not needed. > > The offset of emul1 is not set before reading now1. If it were -2 (but I > would not know why it should get to that value), than setting offset + 1 > for emul2 would be a NOP. So shouldn't we set the offset of emul1 to a > well defined value before reading now1? > > Shouldn't dm_test_rtc_dual() reset the offset of emul2 to 0 before > returning? I have never seen this problem. But I notice that the timers are probed one after the other. Although use_system_time is changed to false (for testing purposes) that still retains the base_time value which comes from os_localtime(). So the two timers can have a different time value if the next second ticks over between the two uclass_get_device() calls and I wonder if the difference is exactly 1 then you will see the error you mention. I suspect instead that we need a way to set the actually base_time of a timer. Then it can be set to the same value for each, at the start of the test. Regards, Simon
Re: [PATCH 1/5] remoteproc: elf_loader: Add elf resource table load support
Hi Fabien, On Wed, 30 Oct 2019 at 03:50, Fabien DESSENNE wrote: > > Hi Simon > > On 30/10/2019 2:49 AM, Simon Glass wrote: > > Hi Fabien, > > > > On Tue, 22 Oct 2019 at 03:08, Fabien DESSENNE > > wrote: > >> Hi Simon, > >> > >> > >> On 22/10/2019 1:47 AM, Simon Glass wrote: > >>> Hi Fabien, > >>> > >>> On Wed, 9 Oct 2019 at 09:36, Fabien Dessenne > >>> wrote: > Add rproc_elf_load_rsc_table(), which searches for a resource table in > an elf64/elf32 image, and if found, copies it to device memory. > Add also the elf32 and elf64 variants of this API. > Add a test for this. > > Signed-off-by: Fabien Dessenne > --- > drivers/remoteproc/rproc-elf-loader.c | 269 > ++ > include/remoteproc.h | 70 + > test/dm/remoteproc.c | 91 ++-- > 3 files changed, 419 insertions(+), 11 deletions(-) > > >>> If you are putting stuff in the image, should you use binman to build > >>> the image, then find the contents using the binman tables? > >> > >> The "resource table" may be located anywhere, there is no strict rule > >> defining where it is expected to be. > >> > >> Nevertheless the Linux remoteproc[1] and OpenAmp (running RTOS) [2] > >> frameworks expect the resource table to be stored in a dedicated ELF > >> section. Both of them run some ELF scanning to find out this section. > >> > >> The proposed patch is for the "ELF section" variant of the resource table. > >> Other variants like binman packing may be proposed as well, both > >> implementations can coexist alongside. > > So why not use binman to pack the image and find the components? This > > is U-Boot, after all. > > > > Packing the firmware together with the other U-Boot components is > acceptable if the firmware is controlled only by U-Boot. > My requirement is that the coprocessor firmware shall be loaded by > U-Boot or by Linux. > > You can have a look at [1] for more details on the way this is handled > on STM32 MPU. In that case, the .elf firmware is stored in a in File > System that can be read by both U-Boot and Linux. > Where is the coprocessor firmware stored, then? > If we have the firmware packed in the image (for U-Boot), we need to > have a copy in the FileSystem (for Linux) which would not be a good idea. What type of filesystem do you use? I don't see any filesystem access in this patch though. > > BR > Fabien > > [1] https://wiki.st.com/stm32mpu/index.php/Boot_chains_overview Regards, Simon
Re: [PATCH] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
On 12/10/2019 3:54 PM, Vladimir Oltean wrote:
Hi Alex,
On Tue, 10 Dec 2019 at 16:21, Alex Marginean
wrote:
Passes on the primary address used by u-boot to Linux. The code does a DT
fix-up for ENETC PFs and sets the primary MAC address in IERB. The address
in IERB is restored on ENETC PCI functions at FLR.
Signed-off-by: Alex Marginean
---
The code is called fom ft_board_setup in board/freescale/ls1028a/ls1028a.c
mostly for consistency with other LS parts. I'm open to suggestions though.
board/freescale/ls1028a/ls1028a.c | 4 ++
drivers/net/fsl_enetc.c | 65 ++-
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index 3977ecf896..fac03f55e9 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -150,6 +150,10 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_icid(blob);
+#ifdef CONFIG_FSL_ENETC
+ fdt_fixup_enetc_mac(blob);
+#endif
+
return 0;
}
#endif
diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index 02c1ee70d9..f8fe7d4d8d 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -14,6 +14,69 @@
#include "fsl_enetc.h"
+#define ENETC_DRIVER_NAME "enetc_eth"
+
+/*
+ * sets the MAC address in IERB registers, this setting is persistent and
+ * carried over to Linux.
+ */
+static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn,
+ const u8 *enetaddr)
+{
+#ifdef CONFIG_ARCH_LS1028A
+/*
+ * LS1028A is the only part with IERB at this time and there are plans to
change
+ * its structure, keep this LS1028A specific for now
+ */
+#define IERB_BASE 0x1f080ULL
+#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 + (vf) * 8 \
++ (n) * 4)
+
+static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3};
+
+ u16 lower = *(const u16 *)(enetaddr + 4);
+ u32 upper = *(const u32 *)enetaddr;
+
+ if (ierb_fn_to_pf[devfn] < 0)
+ return;
+
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper);
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower);
+#endif
+}
+
+/* sets up primary MAC addresses in DT/IERB */
+void fdt_fixup_enetc_mac(void *blob)
+{
+ struct pci_child_platdata *ppdata;
+ struct eth_pdata *pdata;
+ struct udevice *dev;
+ struct uclass *uc;
+ char path[256];
+ int offset;
+ int devfn;
+
+ uclass_get(UCLASS_ETH, );
+ uclass_foreach_dev(dev, uc) {
+ if (!dev->driver || !dev->driver->name ||
+ strcmp(dev->driver->name, ENETC_DRIVER_NAME))
+ continue;
+
+ pdata = dev_get_platdata(dev);
+ ppdata = dev_get_parent_platdata(dev);
+ devfn = PCI_FUNC(ppdata->devfn);
+
+ enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr);
+
+ snprintf(path, 256, "/soc/pcie@1f000/ethernet@%x,%x",
+PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn));
+ offset = fdt_path_offset(blob, path);
+ if (offset < 0)
+ continue;
+ fdt_setprop(blob, offset, "mac-address", pdata->enetaddr, 6);
The Linux Documentation/devicetree/bindings/net/ethernet.txt says:
- local-mac-address: array of 6 bytes, specifies the MAC address that was
assigned to the network device;
- mac-address: array of 6 bytes, specifies the MAC address that was last used by
the boot program; should be used in cases where the MAC address assigned to
the device by the boot program is different from the "local-mac-address"
property;
I'm not sure which property should be used here, but I think local-mac-address.
U-Boot does use (well, if needed) that address, if that is of any
importance.
of_get_mac_address in Linux has this comment:
/**
* Search the device tree for the best MAC address to use.
'mac-address' is
* checked first, because that is supposed to contain to "most recent" MAC
* address. If that isn't set, then 'local-mac-address' is checked next,
* because that is the default address. If that isn't set, then the
obsolete
* 'address' is checked, just in case we're using an old device tree.
If any
* of the above isn't set, then try to get MAC address from nvmem cell
named
* 'mac-address'.
I think mac-address is fine, we can leave local-mac-address to be used
with some default in Linux DT, in case mac-address is missing.
I don't have a strong opinion either way though.
Thanks!
Alex
+ }
+}
+
/*
* Bind the device:
* - set a more explicit name on the interface
@@ -551,7 +614,7 @@ static const struct eth_ops enetc_ops = {
};
U_BOOT_DRIVER(eth_enetc) = {
- .name = "enetc_eth",
+ .name = ENETC_DRIVER_NAME,
.id = UCLASS_ETH,
[PATCH v2] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
Passes on the primary address used by u-boot to Linux. The code does a DT
fix-up for ENETC PFs and sets the primary MAC address in IERB. The address
in IERB is restored on ENETC PCI functions at FLR.
Signed-off-by: Alex Marginean
---
The code is called fom ft_board_setup in board/freescale/ls1028a/ls1028a.c
mostly for consistency with other LS parts. I'm open to suggestions though.
Changes in v2:
- fixed warning for fdt_fixup_enetc_mac being implicitly declared
board/freescale/ls1028a/ls1028a.c | 5 +++
drivers/net/fsl_enetc.c | 65 ++-
drivers/net/fsl_enetc.h | 3 ++
3 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index a9606b8865..1a82c95402 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -25,6 +25,7 @@
#include
#include
#include "../common/qixis.h"
+#include "../drivers/net/fsl_enetc.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -150,6 +151,10 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_icid(blob);
+#ifdef CONFIG_FSL_ENETC
+ fdt_fixup_enetc_mac(blob);
+#endif
+
return 0;
}
#endif
diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index 0ca7e838a8..3c043888db 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -14,6 +14,69 @@
#include "fsl_enetc.h"
+#define ENETC_DRIVER_NAME "enetc_eth"
+
+/*
+ * sets the MAC address in IERB registers, this setting is persistent and
+ * carried over to Linux.
+ */
+static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn,
+ const u8 *enetaddr)
+{
+#ifdef CONFIG_ARCH_LS1028A
+/*
+ * LS1028A is the only part with IERB at this time and there are plans to
change
+ * its structure, keep this LS1028A specific for now
+ */
+#define IERB_BASE 0x1f080ULL
+#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 + (vf) * 8 \
++ (n) * 4)
+
+static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3};
+
+ u16 lower = *(const u16 *)(enetaddr + 4);
+ u32 upper = *(const u32 *)enetaddr;
+
+ if (ierb_fn_to_pf[devfn] < 0)
+ return;
+
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper);
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower);
+#endif
+}
+
+/* sets up primary MAC addresses in DT/IERB */
+void fdt_fixup_enetc_mac(void *blob)
+{
+ struct pci_child_platdata *ppdata;
+ struct eth_pdata *pdata;
+ struct udevice *dev;
+ struct uclass *uc;
+ char path[256];
+ int offset;
+ int devfn;
+
+ uclass_get(UCLASS_ETH, );
+ uclass_foreach_dev(dev, uc) {
+ if (!dev->driver || !dev->driver->name ||
+ strcmp(dev->driver->name, ENETC_DRIVER_NAME))
+ continue;
+
+ pdata = dev_get_platdata(dev);
+ ppdata = dev_get_parent_platdata(dev);
+ devfn = PCI_FUNC(ppdata->devfn);
+
+ enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr);
+
+ snprintf(path, 256, "/soc/pcie@1f000/ethernet@%x,%x",
+PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn));
+ offset = fdt_path_offset(blob, path);
+ if (offset < 0)
+ continue;
+ fdt_setprop(blob, offset, "mac-address", pdata->enetaddr, 6);
+ }
+}
+
/*
* Bind the device:
* - set a more explicit name on the interface
@@ -583,7 +646,7 @@ static const struct eth_ops enetc_ops = {
};
U_BOOT_DRIVER(eth_enetc) = {
- .name = "enetc_eth",
+ .name = ENETC_DRIVER_NAME,
.id = UCLASS_ETH,
.bind = enetc_bind,
.probe = enetc_probe,
diff --git a/drivers/net/fsl_enetc.h b/drivers/net/fsl_enetc.h
index 0bb4cdff47..e441891468 100644
--- a/drivers/net/fsl_enetc.h
+++ b/drivers/net/fsl_enetc.h
@@ -226,4 +226,7 @@ int enetc_mdio_read_priv(struct enetc_mdio_priv *priv, int
addr, int devad,
int enetc_mdio_write_priv(struct enetc_mdio_priv *priv, int addr, int devad,
int reg, u16 val);
+/* sets up primary MAC addresses in DT/IERB */
+void fdt_fixup_enetc_mac(void *blob);
+
#endif /* _ENETC_H */
--
2.17.1
Re: [PATCH] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
Hi Alex,
On Tue, 10 Dec 2019 at 16:21, Alex Marginean
wrote:
>
> Passes on the primary address used by u-boot to Linux. The code does a DT
> fix-up for ENETC PFs and sets the primary MAC address in IERB. The address
> in IERB is restored on ENETC PCI functions at FLR.
>
> Signed-off-by: Alex Marginean
> ---
>
> The code is called fom ft_board_setup in board/freescale/ls1028a/ls1028a.c
> mostly for consistency with other LS parts. I'm open to suggestions though.
>
> board/freescale/ls1028a/ls1028a.c | 4 ++
> drivers/net/fsl_enetc.c | 65 ++-
> 2 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/board/freescale/ls1028a/ls1028a.c
> b/board/freescale/ls1028a/ls1028a.c
> index 3977ecf896..fac03f55e9 100644
> --- a/board/freescale/ls1028a/ls1028a.c
> +++ b/board/freescale/ls1028a/ls1028a.c
> @@ -150,6 +150,10 @@ int ft_board_setup(void *blob, bd_t *bd)
>
> fdt_fixup_icid(blob);
>
> +#ifdef CONFIG_FSL_ENETC
> + fdt_fixup_enetc_mac(blob);
> +#endif
> +
> return 0;
> }
> #endif
> diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
> index 02c1ee70d9..f8fe7d4d8d 100644
> --- a/drivers/net/fsl_enetc.c
> +++ b/drivers/net/fsl_enetc.c
> @@ -14,6 +14,69 @@
>
> #include "fsl_enetc.h"
>
> +#define ENETC_DRIVER_NAME "enetc_eth"
> +
> +/*
> + * sets the MAC address in IERB registers, this setting is persistent and
> + * carried over to Linux.
> + */
> +static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn,
> + const u8 *enetaddr)
> +{
> +#ifdef CONFIG_ARCH_LS1028A
> +/*
> + * LS1028A is the only part with IERB at this time and there are plans to
> change
> + * its structure, keep this LS1028A specific for now
> + */
> +#define IERB_BASE 0x1f080ULL
> +#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 + (vf) * 8
> \
> ++ (n) * 4)
> +
> +static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3};
> +
> + u16 lower = *(const u16 *)(enetaddr + 4);
> + u32 upper = *(const u32 *)enetaddr;
> +
> + if (ierb_fn_to_pf[devfn] < 0)
> + return;
> +
> + out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper);
> + out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower);
> +#endif
> +}
> +
> +/* sets up primary MAC addresses in DT/IERB */
> +void fdt_fixup_enetc_mac(void *blob)
> +{
> + struct pci_child_platdata *ppdata;
> + struct eth_pdata *pdata;
> + struct udevice *dev;
> + struct uclass *uc;
> + char path[256];
> + int offset;
> + int devfn;
> +
> + uclass_get(UCLASS_ETH, );
> + uclass_foreach_dev(dev, uc) {
> + if (!dev->driver || !dev->driver->name ||
> + strcmp(dev->driver->name, ENETC_DRIVER_NAME))
> + continue;
> +
> + pdata = dev_get_platdata(dev);
> + ppdata = dev_get_parent_platdata(dev);
> + devfn = PCI_FUNC(ppdata->devfn);
> +
> + enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr);
> +
> + snprintf(path, 256, "/soc/pcie@1f000/ethernet@%x,%x",
> +PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn));
> + offset = fdt_path_offset(blob, path);
> + if (offset < 0)
> + continue;
> + fdt_setprop(blob, offset, "mac-address", pdata->enetaddr, 6);
The Linux Documentation/devicetree/bindings/net/ethernet.txt says:
- local-mac-address: array of 6 bytes, specifies the MAC address that was
assigned to the network device;
- mac-address: array of 6 bytes, specifies the MAC address that was last used by
the boot program; should be used in cases where the MAC address assigned to
the device by the boot program is different from the "local-mac-address"
property;
I'm not sure which property should be used here, but I think local-mac-address.
> + }
> +}
> +
> /*
> * Bind the device:
> * - set a more explicit name on the interface
> @@ -551,7 +614,7 @@ static const struct eth_ops enetc_ops = {
> };
>
> U_BOOT_DRIVER(eth_enetc) = {
> - .name = "enetc_eth",
> + .name = ENETC_DRIVER_NAME,
> .id = UCLASS_ETH,
> .bind = enetc_bind,
> .probe = enetc_probe,
> --
> 2.17.1
>
Thanks,
-Vladimir
[PATCH] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
Passes on the primary address used by u-boot to Linux. The code does a DT
fix-up for ENETC PFs and sets the primary MAC address in IERB. The address
in IERB is restored on ENETC PCI functions at FLR.
Signed-off-by: Alex Marginean
---
The code is called fom ft_board_setup in board/freescale/ls1028a/ls1028a.c
mostly for consistency with other LS parts. I'm open to suggestions though.
board/freescale/ls1028a/ls1028a.c | 4 ++
drivers/net/fsl_enetc.c | 65 ++-
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index 3977ecf896..fac03f55e9 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -150,6 +150,10 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_icid(blob);
+#ifdef CONFIG_FSL_ENETC
+ fdt_fixup_enetc_mac(blob);
+#endif
+
return 0;
}
#endif
diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index 02c1ee70d9..f8fe7d4d8d 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -14,6 +14,69 @@
#include "fsl_enetc.h"
+#define ENETC_DRIVER_NAME "enetc_eth"
+
+/*
+ * sets the MAC address in IERB registers, this setting is persistent and
+ * carried over to Linux.
+ */
+static void enetc_set_ierb_primary_mac(struct udevice *dev, int devfn,
+ const u8 *enetaddr)
+{
+#ifdef CONFIG_ARCH_LS1028A
+/*
+ * LS1028A is the only part with IERB at this time and there are plans to
change
+ * its structure, keep this LS1028A specific for now
+ */
+#define IERB_BASE 0x1f080ULL
+#define IERB_PFMAC(pf, vf, n) (IERB_BASE + 0x8000 + (pf) * 0x100 + (vf) * 8 \
++ (n) * 4)
+
+static int ierb_fn_to_pf[] = {0, 1, 2, -1, -1, -1, 3};
+
+ u16 lower = *(const u16 *)(enetaddr + 4);
+ u32 upper = *(const u32 *)enetaddr;
+
+ if (ierb_fn_to_pf[devfn] < 0)
+ return;
+
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 0), upper);
+ out_le32(IERB_PFMAC(ierb_fn_to_pf[devfn], 0, 1), (u32)lower);
+#endif
+}
+
+/* sets up primary MAC addresses in DT/IERB */
+void fdt_fixup_enetc_mac(void *blob)
+{
+ struct pci_child_platdata *ppdata;
+ struct eth_pdata *pdata;
+ struct udevice *dev;
+ struct uclass *uc;
+ char path[256];
+ int offset;
+ int devfn;
+
+ uclass_get(UCLASS_ETH, );
+ uclass_foreach_dev(dev, uc) {
+ if (!dev->driver || !dev->driver->name ||
+ strcmp(dev->driver->name, ENETC_DRIVER_NAME))
+ continue;
+
+ pdata = dev_get_platdata(dev);
+ ppdata = dev_get_parent_platdata(dev);
+ devfn = PCI_FUNC(ppdata->devfn);
+
+ enetc_set_ierb_primary_mac(dev, devfn, pdata->enetaddr);
+
+ snprintf(path, 256, "/soc/pcie@1f000/ethernet@%x,%x",
+PCI_DEV(ppdata->devfn), PCI_FUNC(ppdata->devfn));
+ offset = fdt_path_offset(blob, path);
+ if (offset < 0)
+ continue;
+ fdt_setprop(blob, offset, "mac-address", pdata->enetaddr, 6);
+ }
+}
+
/*
* Bind the device:
* - set a more explicit name on the interface
@@ -551,7 +614,7 @@ static const struct eth_ops enetc_ops = {
};
U_BOOT_DRIVER(eth_enetc) = {
- .name = "enetc_eth",
+ .name = ENETC_DRIVER_NAME,
.id = UCLASS_ETH,
.bind = enetc_bind,
.probe = enetc_probe,
--
2.17.1
Re: [PATCH v2 1/4] serial: ns16550: Support run-time configuration
On Tue, Dec 10, 2019 at 12:59 AM Simon Glass wrote: > > At present this driver uses an assortment of CONFIG options to control > how it accesses the hardware. This is painful for platforms that are > supposed to be controlled by a device tree or a previous-stage bootloader. > > Add a new CONFIG option to enable fully dynamic configuration. This > controls register spacing, size, offset and endianness. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - runtime -> run-time > - Enable run-time config for slimbootloader too > - Improve Kconfig help based on Bin's comments > - Use ns16550 in patch subject > > drivers/serial/Kconfig | 21 +++ > drivers/serial/ns16550.c | 57 ++-- > include/ns16550.h| 13 + > 3 files changed, 83 insertions(+), 8 deletions(-) > Reviewed-by: Bin Meng
[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on
Hello Peng, this patch broke my u-boot on a IMX8 QM ROM 7720a1 board. f0cc4eae9a1702a768817ea25d9f23cece69d021 I bisect it and that is the first broken commit. The commits before are working fine. I tried to remove your changes but then I run into this errrors: sc_rm_get_memreg_info: mr:38 res:22 Memreg get info failed, -110 mu_hal_sendmsg timeout sc_rm_is_memreg_owned: mr:39 res:21 sc_rm_is_memreg_owned: mr:39 res:21 mu_hal_sendmsg timeout Some clue whats wrong here? Do I need to adapt my imx8qm board file? Best regards, Oliver
Re: [PATCH v7 13/17] x86: apl: Add P2SB driver
On Mon, Dec 9, 2019 at 8:41 AM Simon Glass wrote: > > Adds a driver for the Apollo Lake Primary-to-sideband bus. This supports > various child devices. It supposed both device tree and of-platdata. > > Signed-off-by: Simon Glass > --- > > Changes in v7: > - Update comment in apl_p2sb_early_init() > > Changes in v6: None > Changes in v5: None > Changes in v4: > - Detect zero mmio address > - Use BIT() macro bit more > - apollolake -> Apollo Lake > > Changes in v3: > - Use pci_get_devfn() > > Changes in v2: None > > arch/x86/cpu/apollolake/Makefile | 1 + > arch/x86/cpu/apollolake/p2sb.c | 166 +++ > 2 files changed, 167 insertions(+) > create mode 100644 arch/x86/cpu/apollolake/p2sb.c > Reviewed-by: Bin Meng
Re: [PATCH v7 02/17] i2c: designware: Add Apollo Lake support
On Mon, Dec 9, 2019 at 8:32 AM Simon Glass wrote:
>
> For Apollo Lake we need to take the I2C bus controller out of reset before
> using this. Add this functionality to the driver.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Heiko Schocher
> ---
>
> Changes in v7: None
> Changes in v6:
> - Add .driver_data in the designware_pci_supported array
> - Add a comment about VANILLA
> - Move lpss_reset_release() to this commit
>
> Changes in v5:
> - Drop unrelated change metioned by Heiko
>
> Changes in v4:
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Add a weak function to avoid errors on other platforms
>
> Changes in v2: None
>
> drivers/i2c/designware_i2c_pci.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/i2c/designware_i2c_pci.c
> b/drivers/i2c/designware_i2c_pci.c
> index bb1f809af3..a3586371dc 100644
> --- a/drivers/i2c/designware_i2c_pci.c
> +++ b/drivers/i2c/designware_i2c_pci.c
> @@ -8,8 +8,14 @@
> #include
> #include
> #include
> +#include
> #include "designware_i2c.h"
>
> +enum {
> + VANILLA = 0,/* standard I2C with no tweaks */
> + INTEL_APL, /* Apollo Lake I2C */
> +};
> +
> /* BayTrail HCNT/LCNT/SDA hold time */
> static struct dw_scl_sda_cfg byt_config = {
> .ss_hcnt = 0x200,
> @@ -19,6 +25,9 @@ static struct dw_scl_sda_cfg byt_config = {
> .sda_hold = 0x6,
> };
>
> +/* Have a weak function for now - possibly should be a new uclass */
> +__weak void lpss_reset_release(void *regs);
> +
> static int designware_i2c_pci_ofdata_to_platdata(struct udevice *dev)
> {
> struct dw_i2c *priv = dev_get_priv(dev);
> @@ -59,6 +68,15 @@ static int designware_i2c_pci_ofdata_to_platdata(struct
> udevice *dev)
>
> static int designware_i2c_pci_probe(struct udevice *dev)
> {
> + struct dw_i2c *priv = dev_get_priv(dev);
> +
> + if (dev_get_driver_data(dev) == INTEL_APL) {
> + /* Ensure controller is in D0 state */
> + lpss_set_power_state(dev, STATE_D0);
> +
> + lpss_reset_release(priv->regs);
> + }
> +
> return designware_i2c_probe(dev);
> }
>
> @@ -88,6 +106,7 @@ static int designware_i2c_pci_bind(struct udevice *dev)
>
> static const struct udevice_id designware_i2c_pci_ids[] = {
> { .compatible = "snps,designware-i2c-pci" },
> + { .compatible = "intel,apl-i2c", INTEL_APL },
nits: .data = INTEL_APL to make it clear
> { }
> };
>
> @@ -113,6 +132,12 @@ static struct pci_device_id designware_pci_supported[] =
> {
> { PCI_VDEVICE(INTEL, 0x0f45) },
> { PCI_VDEVICE(INTEL, 0x0f46) },
> { PCI_VDEVICE(INTEL, 0x0f47) },
> + { PCI_VDEVICE(INTEL, 0x5aac), .driver_data = INTEL_APL },
> + { PCI_VDEVICE(INTEL, 0x5aae), .driver_data = INTEL_APL },
> + { PCI_VDEVICE(INTEL, 0x5ab0), .driver_data = INTEL_APL },
> + { PCI_VDEVICE(INTEL, 0x5ab2), .driver_data = INTEL_APL },
> + { PCI_VDEVICE(INTEL, 0x5ab4), .driver_data = INTEL_APL },
> + { PCI_VDEVICE(INTEL, 0x5ab6), .driver_data = INTEL_APL },
> {},
> };
>
Reviewed-by: Bin Meng
Re: [PATCH v7 03/17] x86: apl: Add systemagent driver
On Mon, Dec 9, 2019 at 8:32 AM Simon Glass wrote: > > This driver handles communication with the systemagent which needs to be > told when U-Boot has completed its init. > > Signed-off-by: Simon Glass > > --- > > Changes in v7: > - Add a comment to enable_bios_reset_cpl() > > Changes in v6: None > Changes in v5: None > Changes in v4: > - Add a comment for enable_bios_reset_cpl() > - Tidy up header guards > - use GENMASK() for VTBAR_MASK > > Changes in v3: None > Changes in v2: None > > arch/x86/cpu/apollolake/Makefile | 2 + > arch/x86/cpu/apollolake/systemagent.c | 23 > .../include/asm/arch-apollolake/systemagent.h | 37 +++ > 3 files changed, 62 insertions(+) > create mode 100644 arch/x86/cpu/apollolake/systemagent.c > create mode 100644 arch/x86/include/asm/arch-apollolake/systemagent.h > Reviewed-by: Bin Meng
Re: [PATCH v7 01/17] x86: apl: Add pinctrl driver
On Mon, Dec 9, 2019 at 8:32 AM Simon Glass wrote: > > Add a driver for the Apollo Lake pinctrl. This mostly makes use of the > common Intel pinctrl support. > > Signed-off-by: Simon Glass > --- > > Changes in v7: > - Drop Glacier Lake code > - Fix value of GPIO_28_IRQ > - Update Kconfig to avoid using def_bool > > Changes in v6: None > Changes in v5: None > Changes in v4: > - Allow pinctrl nodes to have subnodes (i.e. GPIO nodes) > - Drop GPIO_NUM_PAD_CFG_REGS > - Switch over to use pinctrl for pad init/config > - Tidy up the header file a little > - apollolake -> Apollo Lake > > Changes in v3: > - Add various minor tidy-ups > - Fix mixed case in GPIO defines > - Rework how pads configuration is defined in TPL and SPL > - Use the IRQ uclass instead of ITSS > > Changes in v2: None > > arch/x86/include/asm/arch-apollolake/gpio.h | 485 > drivers/pinctrl/intel/Kconfig | 16 +- > drivers/pinctrl/intel/Makefile | 1 + > drivers/pinctrl/intel/pinctrl_apl.c | 192 > 4 files changed, 691 insertions(+), 3 deletions(-) > create mode 100644 arch/x86/include/asm/arch-apollolake/gpio.h > create mode 100644 drivers/pinctrl/intel/pinctrl_apl.c > Reviewed-by: Bin Meng
Re: [PATCH v2] arm64: zynqmp: Add support for u-boot.itb generation with ATF
On Tue, Dec 10, 2019 at 01:03:29PM +0100, Michal Simek wrote:
> On 09. 12. 19 16:49, Tom Rini wrote:
> > On Mon, Dec 09, 2019 at 03:21:02PM +0100, Michal Simek wrote:
> >> On 05. 12. 19 15:33, Tom Rini wrote:
> >>> On Thu, Dec 05, 2019 at 09:46:57AM +0100, Michal Simek wrote:
> Follow i.MX, Sunxi, RISC-V and Rockchip to generate u-boot.itb which
> includes U-Boot proper, ATF and DTBs in FIT format. ZynqMP supports FIT
> for
> quite a long time but with using out of tree solution. The patch is
> filling
> this gap.
>
> Tested on zcu102, zcu104 and zcu100/Ultra96.
>
> zcu100/Ultra96 v2.2 ATF build by:
> make DEBUG=0 ZYNQMP_CONSOLE=cadence1 RESET_TO_BL31=1 PLAT=zynqmp bl31
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Exchange u-boot/atf in config section
> - Use default ATF baseaddr from mainline
> - Update commit message
>
> Kconfig | 3 +-
> arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 99 +
> >>>
> >>> My only complaint here is adding and N'th version of mkimage_fit_atf.sh
> >>> that varies seemingly only in addresses. Can we not abstract this
> >>> enough to make it for everyone to use and pass in the needed values?
> >>
> >> First of all I will be sending v3 because of other things I found.
> >>
> >> Adding more folks to this.
> >>
> >> I have went through all versions and here is sort of stat:
> >>
> >> board/sunxi/mksunxi_fit_atf.sh - firmware is uboot, atf loadables (not
> >> standard)
> >>
> >> board/theobroma-systems/puma_rk3399/fit_spl_atf.sh - license present
> >> atf, uboot, pmufw (only present here)
> >>
> >> arch/arm/mach-rockchip/make_fit_atf.py - python (only one) and read
> >> addresses from elfs
> >>
> >> arch/arm/mach-rockchip/fit_spl_optee.sh - firmware is tee(no ATF)
> >>
> >> arch/riscv/lib/mkimage_fit_opensbi.sh - reads stuff from .config and
> >> also handles non DT case
> >>
> >> arch/arm/mach-imx/mkimage_fit_atf.sh - optee, atf, incorrect dt nodes names
> >>
> >> And of course this one.
> >
> > Thanks for looking more here.
> >
> >> ---
> >>
> >> I think the key point here is to start talk about how this should be done.
> >> Language? One is python others are shell scripts.
> >
> > I don't have a hard preference here. I think the reason we have one in
> > Python is for ease of working with ELF. Restrictions / issues like that
> > probably mean it would be best to make sure we pick a language that
> > allows for peeking at ELFs but I have not confirmed if we could easily
> > re-do the rockchip python tool in shell by using a standard tool
> > (objdump or similar from binutils, so we'll certainly have it).
>
>
> I expect that all addresses are just entry points of these elfs
> It means something like this should be enough.
> readelf -l bl31.elf | awk '/Entry point/ { print $3 }'
OK. Then we should probably stick to shell.
> >> Should it stop when ATF/TEE is not found?
> >
> > For CI it must non-fatally complete, but should also be verbose in that
> > the resulting binary is non-functional.
>
> ok.
>
> >
> >> What file to read to get information from u-boot? .config or
> >> include/generated/autoconf.h?
> >
> > Honestly? I'd like to start looking at something better if we can here
> > as these are not really user-configurable values, but system values.
> > Some property under a -u-boot.dtsi file?
>
> I still have one ancient branch to get rid of all u-boot,dm* variables
> from nodes and move them to chosen node where they should be.
> Can you please elaborate on this more?
Well, it's been pointed out before, and I agree, that a lot of things we
have had historically in CONFIG_xxx symbols are things that just aren't
appropriate for Kconfig (users shouldn't change them, putting N default
values in Kconfig is ugly, etc). While devicetree-the-in-kernel-file is
to describe the hardware, devicetree-the-syntax is something we use for
other things (FIT images) and other projects take even farther. So I've
been thinking that devicetree-the-syntax seems like a good way to handle
this particular problem. Where it all goes, I don't know.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
On Tue, Dec 10, 2019 at 01:40:42PM +0100, Michal Simek wrote: > Hi Tom, > > On 09. 12. 19 16:19, Michal Simek wrote: > > Hi, > > > > over years a lot of new Xilinx ZynqMP board have been added to U-Boot with > > corresponding defconfigs. Also a lot of drivers have been moved to DM that > > we can make one generic configuration with one defconfig. > > Nand still needs to be validated that's why dc2/dc3 are not moved yet. > > > > Boards can be build like this: > > export DEVICE_TREE="avnet-ultra96-rev1" > > make xilinx_zynqmp_virt_defconfig > > make -j > > > > Series depends on patches sent before that's why here is full tree: > > https://github.com/michalsimek/u-boot/tree/20191209-mainline > > This series will require some changes in CI loops because right now > I didn't setup default device tree (CONFIG_DEFAULT_DEVICE_TREE) to > "force" everybody to properly pass DEVICE_TREE via command line. > I can't use OF_BOARD because then SPL is built without DT at all. > > How do you think I should handle it for CI loops? > 1. I can remove this configuration but it will be only one at the end > that's why not a good solution. > 2. Add generic option to run some commands before tests like export > DEVICE_TREE above > 3. provide different options for SPL/full u-boot how > OF_SEPARATE/OF_BOARD is handled. So, for CI are you wanting to test most device trees, or just one? Are we able to run one of these device trees via QEMU? If we can run the virt defconfig via qemu, we should just update/extend that stanza in the CI files to set DEVICE_TREE and exclude building it from the normal jobs. If we can't run via qemu then yes, something like option #2 and we set DEVICE_TREE in one job and export it if set in the build job. -- Tom signature.asc Description: PGP signature
Re: tpm / measured boot in u-boot
Hi Stuart, On Thu, 31 Oct 2019 at 09:29, Stuart Yoder wrote: > > On Tue, Oct 29, 2019 at 8:49 PM Simon Glass wrote: > > > > Hi Stuart, > > > > On Mon, 28 Oct 2019 at 17:27, Stuart Yoder wrote: > > > > > > I saw Simon's write-up here: https://lwn.net/Articles/571031/, which > > > references TPM > > > and trusted boot support using the TPM. > > > > > > I've started looking at the TPM support code in u-boot, and am trying > > > to understand > > > it. Before getting too far I wanted to check if there were any > > > pointers anyone might > > > have around any documentation or material that provides more detail on > > > what the > > > u-boot TPM support does and does not do. I didn't see any .txt files in > > > u-boot. > > > > > > The supports seems oriented around using commands and scripts to > > > measure images. One > > > specific thing I'm interested is how the u-boot script itself that takes > > > the TPM > > > measurements is protected against tampering. > > > > Actually verified boot does not use the TPM at all. > > > > What do you want the TPM to do? If you want measured boot then you > > would need to call measure / extend before/after loading each stage. > > Yes, interested in the TPM for measured boot. Right, understand that you > need to do the measurements and extend for each loaded image. > > But, it's critical that you trust the code doing the measurements. If I > understand it's the u-boot commands implemented in ./cmd/tpm-v2.c > that you could use to script the measuring/extending. How do you > ensure that the script doing the measurements isn't tampered with > by an attacker? Anything loaded must be measured. So if you are using a U-Boot script this needs to be checked. Or you could write a command that does what you want that is part of U-Boot itself. Regards, Simon
[PATCH] rockchip: make_fit_atf: explicitly use python3
From: Jack Mitchell On a distribution with no python2 installed and no python->python3 symlink the script will fail to execute. Specify python3 explicitly as it's already a requirement to build u-boot. Signed-off-by: Jack Mitchell --- arch/arm/mach-rockchip/make_fit_atf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/make_fit_atf.py b/arch/arm/mach-rockchip/make_fit_atf.py index 3c045a5e17..c79317d6c5 100755 --- a/arch/arm/mach-rockchip/make_fit_atf.py +++ b/arch/arm/mach-rockchip/make_fit_atf.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python3 """ # SPDX-License-Identifier: GPL-2.0+ # -- 2.24.0
Re: [U-Boot] [PATCH 1/1] serial: sandbox: support Unicode
On Sat, 9 Nov 2019 at 03:35, Andy Shevchenko wrote: > > On Sat, Nov 9, 2019 at 11:59 AM Heinrich Schuchardt > wrote: > > > > Due to a conversion error the sandbox does not accept byte values 0x80-0xff > > from the keyboard. The UEFI extended text input unit test requires Unicode > > support. > > > > Use unsigned char for the serial buffer. > > > > FWIW, > Reviewed-by: Andy Shevchenko > Reviewed-by: Simon Glass
Re: [U-Boot] [PATCH] binman: README: fix default filename of u-boot-with-ucode-ptr
Hi, On Wed, 4 Dec 2019 at 21:28, Simon Glass wrote: > > On Sun, 24 Nov 2019 at 18:48, Bin Meng wrote: > > > > On Mon, Nov 25, 2019 at 9:45 AM Masahiro Yamada > > wrote: > > > > > > The suffix should be ".bin" instead of ".dtb" . > > > > > > Signed-off-by: Masahiro Yamada > > > --- > > > > > > tools/binman/README.entries | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > Reviewed-by: Bin Meng > > Reviewed-by: Simon Glass Actually I take that back...this should be modified in the source .py file, from which this README is generated. Regards, Simon
Re: [PATCH 1/1] buildman: Improve [make-flags] section parser to allow quoted strings
On Sun, 24 Nov 2019 at 13:30, Cristian Ciocaltea wrote: > > The parser responsible for the '[make-flags]' section in > the '.buildman' settings file is currently not able to > handle quoted strings, as given in the sample bellow: > > [make-flags] > qemu_arm=HOSTCC="cc -isystem /add/include" HOSTLDFLAGS="-L/add/lib" > > This patch replaces the simple string splitter based on the > delimiter with a regex tokenizer that preserves spaces inside double > quoted strings. > > Signed-off-by: Cristian Ciocaltea > --- > tools/buildman/toolchain.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 1/2] sandbox: add missing compatible property in device tree
On Sat, 9 Nov 2019 at 01:39, Heinrich Schuchardt wrote: > > In the device tree UEFI unit test the compatible property of the device is > read. > > Provide the missing property. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/dts/sandbox.dts | 1 + > arch/sandbox/dts/sandbox64.dts | 1 + > 2 files changed, 2 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH] i2c: i2c_cdns: fix write timeout on fifo boundary
On Mon, 9 Dec 2019 at 11:19, Michael Auchter wrote:
>
> This fixes an issue that would cause I2C writes to timeout when the
> number of bytes is a multiple of the FIFO depth (i.e. 16 bytes).
>
> Within the transfer loop, after writing the data register with a new
> byte to transfer, if the transfer size equals the FIFO depth, the loop
> pauses until the INTERRUPT_COMP bit asserts to indicate data has been
> sent. This same check is performed after the loop as well to ensure data
> has been transferred prior to returning.
>
> In the case where the amount of data to be written is a multiple of the
> FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to
> assert after writing the final byte, and then wait for this bit to
> assert once more. However, since the transfer has finished at this
> point, no new data has been written to the data register, and hence
> INTERRUPT_COMP will never assert.
>
> Fix this by only waiting for INTERRUPT_COMP in the transfer loop if
> there's still data to be written.
>
> Signed-off-by: Michael Auchter
> ---
> drivers/i2c/i2c-cdns.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
> index 2c0301ad08..ff3956d8c2 100644
> --- a/drivers/i2c/i2c-cdns.c
> +++ b/drivers/i2c/i2c-cdns.c
> @@ -265,7 +265,7 @@ static int cdns_i2c_write_data(struct i2c_cdns_bus
> *i2c_bus, u32 addr, u8 *data,
>
> while (len-- && !is_arbitration_lost(regs)) {
> writel(*(cur_data++), >data);
> - if (readl(>transfer_size) == CDNS_I2C_FIFO_DEPTH) {
> + if (len && readl(>transfer_size) ==
> CDNS_I2C_FIFO_DEPTH) {
> ret = cdns_i2c_wait(regs, CDNS_I2C_INTERRUPT_COMP |
> CDNS_I2C_INTERRUPT_ARBLOST);
> if (ret & CDNS_I2C_INTERRUPT_ARBLOST)
> --
> 2.23.0
>
Reviewed-by: Simon Glass
Re: [PATCH 2/2] configs: sandbox: enable CONFIG_CMD_BOOTEFI_SELFTEST
Hi Heinrich, On Sat, 9 Nov 2019 at 01:44, Heinrich Schuchardt wrote: > > Activate UEFI unit tests on the sandbox. > > Signed-off-by: Heinrich Schuchardt > --- > configs/sandbox64_defconfig| 1 + > configs/sandbox_defconfig | 1 + > configs/sandbox_flattree_defconfig | 1 + > configs/sandbox_spl_defconfig | 1 + > 4 files changed, 4 insertions(+) Unfortunately this slows down the testing too much, nearly doubling the time in my tests. I think the EFI console tests need to be modified to run in C instead of all the drain_console() and p.timeout stuff. We need an effort to speed up the tests, but certainly cannot make them any slower. Regards, Simon
Re: [U-Boot] [PATCH] ARM: DRA7: Fixup DSP OPP_HIGH clock rate on DRA76P/DRA77P SoCs
On Mon, Dec 02, 2019 at 04:34:21PM -0600, Suman Anna wrote:
> The commit 1b42ab3eda8a ("ARM: DRA7: Fixup DSPEVE, IVA and GPU clock
> frequencies based on OPP") added the core logic to update the kernel
> device-tree blob to adjust the DSP, IVA and GPU DPLL clocks based on
> a one-time OPP choice selected in U-Boot for most of the DRA7xx/AM57xx
> family of SoCs.
>
> The DSPs on DRA76xP/DRA77xP SoCs (DRA76x ACD package SoCs) though
> provide a higher performance and can run at a higher clock frequency
> of 850 MHz at OPP_HIGH instead of 750 MHz. Fix up the logic to use the
> correct clock rates on these SoCs. Note that this higher clock rate is
> not applicable to other Jacinto 6 Plus SoCs (DRA75xP/DRA74xP SoCs or
> AM574x SoCs) that follow the ABZ package.
>
> Signed-off-by: Suman Anna
> Reviewed-by: Lokesh Vutla
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
gtlab slow?
Hi, I sometimes find that gitlab.denx.de is very slow. Just now is is worse than usual - it has taken almost 10 minutes to push a branch and still not finished. I am getting a 503 error on the web site. Any ideas? Regards, Simon
Re: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs
Hi Tom, On 09. 12. 19 16:19, Michal Simek wrote: > Hi, > > over years a lot of new Xilinx ZynqMP board have been added to U-Boot with > corresponding defconfigs. Also a lot of drivers have been moved to DM that > we can make one generic configuration with one defconfig. > Nand still needs to be validated that's why dc2/dc3 are not moved yet. > > Boards can be build like this: > export DEVICE_TREE="avnet-ultra96-rev1" > make xilinx_zynqmp_virt_defconfig > make -j > > Series depends on patches sent before that's why here is full tree: > https://github.com/michalsimek/u-boot/tree/20191209-mainline This series will require some changes in CI loops because right now I didn't setup default device tree (CONFIG_DEFAULT_DEVICE_TREE) to "force" everybody to properly pass DEVICE_TREE via command line. I can't use OF_BOARD because then SPL is built without DT at all. How do you think I should handle it for CI loops? 1. I can remove this configuration but it will be only one at the end that's why not a good solution. 2. Add generic option to run some commands before tests like export DEVICE_TREE above 3. provide different options for SPL/full u-boot how OF_SEPARATE/OF_BOARD is handled. Thanks for your suggestions, Michal
Re: [PATCH v2 2/2] env: Access Environment in SPI flashes before relocation
Hi Heiko,
On Fri, 15 Nov 2019 at 00:28, Heiko Schocher wrote:
>
> Enable the new Kconfig option ENV_SPI_EARLY if you want
> to use Environment in SPI flash before relocation.
> Call env_init() and than you can use env_get_f() for
> accessing Environment variables.
>
> Signed-off-by: Heiko Schocher
>
> ---
>
> Changes in v2:
> - env_sf_init_early() always return 0 now. If we do not return
> 0 in this function, env_set_inited() never get called,
> which has the consequence that env_load/save/erase never
> work, because they check if the init bit is set.
>
> env/Kconfig | 8 ++
> env/sf.c| 81 +
> 2 files changed, 89 insertions(+)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index 090cc795f9..76e4f30839 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -370,6 +370,14 @@ config ENV_SPI_MODE
> Value of the SPI work mode for environment.
> See include/spi.h for value.
>
> +config ENV_SPI_EARLY
> + bool "Access Environment in SPI flashes before relocation"
> + depends on ENV_IS_IN_SPI_FLASH
> + help
> + Enable this if you want to use Environment in SPI flash
> + before relocation. Call env_init() and than you can use
> + env_get_f() for accessing Environment variables.
> +
> config ENV_IS_IN_UBI
> bool "Environment in a UBI volume"
> depends on !CHAIN_OF_TRUST
> diff --git a/env/sf.c b/env/sf.c
> index 590d0cedd8..be2e7fc01c 100644
> --- a/env/sf.c
> +++ b/env/sf.c
> @@ -308,6 +308,85 @@ static int env_sf_init(void)
> }
> #endif
>
> +#if defined(CONFIG_ENV_SPI_EARLY)
> +static int env_sf_init_early(void)
Function comment to explain what it does?
> +{
> + int ret;
> + int read1_fail;
> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
> + int read2_fail;
> +#else
> + int crc1_ok;
> +#endif
> +
> + /*
> +* if malloc is not ready yet, we cannot use
> +* this part yet.
> +*/
> + if (!gd->malloc_limit)
> + return -ENOENT;
> +
> + env_t *tmp_env2 = NULL;
> + env_t *tmp_env1;
> +
> + tmp_env1 = (env_t *)memalign(ARCH_DMA_MINALIGN,
> + CONFIG_ENV_SIZE);
> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
Can the #ifdefs in this function be if(IS_ENABLED...) instead?
> + tmp_env2 = (env_t *)memalign(ARCH_DMA_MINALIGN,
> + CONFIG_ENV_SIZE);
> +#endif
> + if (!tmp_env1 || !tmp_env2)
> + goto out;
> +
> + ret = setup_flash_device();
> + if (ret)
> + goto out;
> +
> + read1_fail = spi_flash_read(env_flash, CONFIG_ENV_OFFSET,
> + CONFIG_ENV_SIZE, tmp_env1);
> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
> + read2_fail = spi_flash_read(env_flash, CONFIG_ENV_OFFSET_REDUND,
> + CONFIG_ENV_SIZE, tmp_env2);
> + ret = env_check_redund((char *)tmp_env1, read1_fail,
> + (char *)tmp_env2, read2_fail);
> +
> + if ((ret == -EIO) || (ret == -ENOMSG))
Can drop extra brackets
> + goto err_read;
> +
> + if (gd->env_valid == ENV_VALID)
> + gd->env_addr = (unsigned long)_env1->data;
> + else
> + gd->env_addr = (unsigned long)_env2->data;
> +
> +#else
> + if (read1_fail)
> + goto err_read;
> +
> + crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) ==
> + tmp_env1->crc;
> + if (!crc1_ok)
> + goto err_read;
> +
> + /* if valid -> this is our env */
> + gd->env_valid = ENV_VALID;
> + gd->env_addr = (unsigned long)_env1->data;
> +#endif
> +
> + return 0;
> +err_read:
> + spi_flash_free(env_flash);
> + env_flash = NULL;
> + free(tmp_env1);
> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
Unrelated to your patch, but should that be REDUNDANT?
> + free(tmp_env2);
> +#endif
> +out:
> + /* env is not valid. always return 0 */
> + gd->env_valid = ENV_INVALID;
> + return 0;
> +}
> +#endif
> +
> U_BOOT_ENV_LOCATION(sf) = {
> .location = ENVL_SPI_FLASH,
> ENV_NAME("SPI Flash")
> @@ -317,5 +396,7 @@ U_BOOT_ENV_LOCATION(sf) = {
> #endif
> #if defined(INITENV) && defined(CONFIG_ENV_ADDR)
> .init = env_sf_init,
> +#elif defined(CONFIG_ENV_SPI_EARLY)
> + .init = env_sf_init_early,
> #endif
It seems like we should have two drivers here, only one of which is
enabled. Perhaps for testing sandbox would want to enable both?
Alternatively I think env_sf_init() should decide which init function to call.
Regards,
Simon
Re: [PATCH] bdinfo: show multi_dtb_fit
On Fri, 8 Nov 2019 at 20:56, Heiko Schocher wrote: > > if MULTI_DTB_FIT is enabled it is helpful to display > the value of gd->multi_dtb_fit in bdinfo. > > Signed-off-by: Heiko Schocher > > --- > travis build: > https://travis-ci.org/hsdenx/u-boot-test/builds/609100901 > > cmd/bdinfo.c | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH] gpio: search for gpio label if gpio is not found through bank name
Hi Heiko, On Wed, 30 Oct 2019 at 04:29, Heiko Schocher wrote: > > dm_gpio_lookup_name() searches for a gpio through > the bank name. But we have also gpio labels, and it > makes sense to search for a gpio also in the labels > we have defined, if no gpio is found through the > bank name definition. > > This is useful for example if you have a wp pin on > different gpios on different board versions. > > If dm_gpio_lookup_name() searches also for the gpio labels, > you can give the gpio an unique label name and search > for this label, and do not need to differ between > board revisions. > > Signed-off-by: Heiko Schocher > --- > > Example on the aristainetos board: > > => gpio clear wp_spi_nor.gpio-hog > gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0 > => > > before this patch, you need to know where your > pin is: > > => gpio clear GPIO2_15 > gpio: pin GPIO2_15 (gpio 47) value is 0 > => > > travis build: > https://travis-ci.org/hsdenx/u-boot-test/builds/604290746 > > drivers/gpio/gpio-uclass.c | 20 > 1 file changed, 20 insertions(+) Thanks for making this so clear. I have been wondering whether this should be enabled by a CONFIG but in fact it doesn't add much and the lookup function is only called by those who are not using the device-tree phandle mechanism. But I think it needs two changes: - Move code into a separate function called from dm_gpio_lookup_name() - Add a sandbox test for both cases Regards, Simon
Re: [PATCH v2] arm64: zynqmp: Add support for u-boot.itb generation with ATF
On 09. 12. 19 16:49, Tom Rini wrote:
> On Mon, Dec 09, 2019 at 03:21:02PM +0100, Michal Simek wrote:
>> On 05. 12. 19 15:33, Tom Rini wrote:
>>> On Thu, Dec 05, 2019 at 09:46:57AM +0100, Michal Simek wrote:
Follow i.MX, Sunxi, RISC-V and Rockchip to generate u-boot.itb which
includes U-Boot proper, ATF and DTBs in FIT format. ZynqMP supports FIT for
quite a long time but with using out of tree solution. The patch is filling
this gap.
Tested on zcu102, zcu104 and zcu100/Ultra96.
zcu100/Ultra96 v2.2 ATF build by:
make DEBUG=0 ZYNQMP_CONSOLE=cadence1 RESET_TO_BL31=1 PLAT=zynqmp bl31
Signed-off-by: Michal Simek
---
Changes in v2:
- Exchange u-boot/atf in config section
- Use default ATF baseaddr from mainline
- Update commit message
Kconfig | 3 +-
arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 99 +
>>>
>>> My only complaint here is adding and N'th version of mkimage_fit_atf.sh
>>> that varies seemingly only in addresses. Can we not abstract this
>>> enough to make it for everyone to use and pass in the needed values?
>>
>> First of all I will be sending v3 because of other things I found.
>>
>> Adding more folks to this.
>>
>> I have went through all versions and here is sort of stat:
>>
>> board/sunxi/mksunxi_fit_atf.sh - firmware is uboot, atf loadables (not
>> standard)
>>
>> board/theobroma-systems/puma_rk3399/fit_spl_atf.sh - license present
>> atf, uboot, pmufw (only present here)
>>
>> arch/arm/mach-rockchip/make_fit_atf.py - python (only one) and read
>> addresses from elfs
>>
>> arch/arm/mach-rockchip/fit_spl_optee.sh - firmware is tee(no ATF)
>>
>> arch/riscv/lib/mkimage_fit_opensbi.sh - reads stuff from .config and
>> also handles non DT case
>>
>> arch/arm/mach-imx/mkimage_fit_atf.sh - optee, atf, incorrect dt nodes names
>>
>> And of course this one.
>
> Thanks for looking more here.
>
>> ---
>>
>> I think the key point here is to start talk about how this should be done.
>> Language? One is python others are shell scripts.
>
> I don't have a hard preference here. I think the reason we have one in
> Python is for ease of working with ELF. Restrictions / issues like that
> probably mean it would be best to make sure we pick a language that
> allows for peeking at ELFs but I have not confirmed if we could easily
> re-do the rockchip python tool in shell by using a standard tool
> (objdump or similar from binutils, so we'll certainly have it).
I expect that all addresses are just entry points of these elfs
It means something like this should be enough.
readelf -l bl31.elf | awk '/Entry point/ { print $3 }'
>
>> Should it stop when ATF/TEE is not found?
>
> For CI it must non-fatally complete, but should also be verbose in that
> the resulting binary is non-functional.
ok.
>
>> What file to read to get information from u-boot? .config or
>> include/generated/autoconf.h?
>
> Honestly? I'd like to start looking at something better if we can here
> as these are not really user-configurable values, but system values.
> Some property under a -u-boot.dtsi file?
I still have one ancient branch to get rid of all u-boot,dm* variables
from nodes and move them to chosen node where they should be.
Can you please elaborate on this more?
>> Read information about locations from ELFs?
>>
>> Should we handle non DT case? Yes?
>
> Sorry, non-DT case in this instance meaning what? We're talking about
> FIT and FIT uses a DT.
With OF_BOARD configurations where DT can be stored somewhere else there
could be use cases that you want to have FIT without DT.
>> Move just DT generation to common location and keep VARs, file checking
>> in board/arch scripts?
>
> High level, this sounds right. Thanks!
I would like to get more feedback from others to agreed how this should
be done before anybody invest time for doing it.
Thanks,
Michal
[U-boot,v2,07/10] mmc: add mmc and sd support for MT7622
This patch add mmc and sd support for Mediatek MT7622 SoCs
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
drivers/mmc/mtk-sd.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index eaa584a4df..a3ede3070a 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -1568,6 +1568,15 @@ static const struct msdc_compatible mt7620_compat = {
.enhance_rx = false
};
+static const struct msdc_compatible mt7622_compat = {
+ .clk_div_bits = 12,
+ .pad_tune0 = true,
+ .async_fifo = true,
+ .data_tune = true,
+ .busy_check = true,
+ .stop_clk_fix = true,
+};
+
static const struct msdc_compatible mt7623_compat = {
.clk_div_bits = 12,
.sclk_cycle_shift = 20,
@@ -1601,6 +1610,7 @@ static const struct msdc_compatible mt8183_compat = {
static const struct udevice_id msdc_ids[] = {
{ .compatible = "mediatek,mt7620-mmc", .data = (ulong)_compat },
+ { .compatible = "mediatek,mt7622-mmc", .data = (ulong)_compat },
{ .compatible = "mediatek,mt7623-mmc", .data = (ulong)_compat },
{ .compatible = "mediatek,mt8516-mmc", .data = (ulong)_compat },
{ .compatible = "mediatek,mt8183-mmc", .data = (ulong)_compat },
--
2.17.1
[U-boot,v2,01/10] ARM: MediaTek: Add support for MediaTek MT7622 SoC
Add support for MediaTek MT7622 SoC. This include the file
that will initialize the SoC after boot and its device tree.
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
arch/arm/dts/mt7622-u-boot.dtsi| 29
arch/arm/dts/mt7622.dtsi | 185 +
arch/arm/mach-mediatek/Kconfig | 9 ++
arch/arm/mach-mediatek/Makefile| 1 +
arch/arm/mach-mediatek/mt7622/Makefile | 3 +
arch/arm/mach-mediatek/mt7622/init.c | 51 +++
6 files changed, 278 insertions(+)
create mode 100644 arch/arm/dts/mt7622-u-boot.dtsi
create mode 100644 arch/arm/dts/mt7622.dtsi
create mode 100644 arch/arm/mach-mediatek/mt7622/Makefile
create mode 100644 arch/arm/mach-mediatek/mt7622/init.c
diff --git a/arch/arm/dts/mt7622-u-boot.dtsi b/arch/arm/dts/mt7622-u-boot.dtsi
new file mode 100644
index 00..b14b1d4344
--- /dev/null
+++ b/arch/arm/dts/mt7622-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/mt7622.dtsi b/arch/arm/dts/mt7622.dtsi
new file mode 100644
index 00..7dcca5c6af
--- /dev/null
+++ b/arch/arm/dts/mt7622.dtsi
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt7622";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ clock-frequency = <13>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1>;
+ clock-frequency = <13>;
+ };
+ };
+
+ snfi: snfi@1100d000 {
+ compatible = "mediatek,mtk-snfi-spi";
+ reg = <0x1100d000 0x2000>;
+ clocks = < CLK_PERI_NFI_PD>,
+< CLK_PERI_SNFI_PD>;
+ clock-names = "nfi_clk", "pad_clk";
+ assigned-clocks = < CLK_TOP_AXI_SEL>,
+ < CLK_TOP_NFI_INFRA_SEL>;
+
+ assigned-clock-parents = < CLK_TOP_SYSPLL1_D2>,
+< CLK_TOP_UNIVPLL2_D8>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <>;
+ interrupts = ,
+,
+,
+;
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ timer0: timer@10004000 {
+ compatible = "mediatek,timer";
+ reg = <0x10004000 0x80>;
+ interrupts = ;
+ clocks = <_clk>;
+ clock-names = "system-clk";
+ };
+
+ system_clk: dummy13m {
+ compatible = "fixed-clock";
+ clock-frequency = <1300>;
+ #clock-cells = <0>;
+ };
+
+ infracfg: infracfg@1000 {
+ compatible = "mediatek,mt7622-infracfg",
+"syscon";
+ reg = <0x1000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ pericfg: pericfg@10002000 {
+ compatible = "mediatek,mt7622-pericfg", "syscon";
+ reg = <0x10002000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ scpsys: scpsys@10006000 {
+ compatible = "mediatek,mt7622-scpsys",
+"syscon";
+ #power-domain-cells = <1>;
+ reg = <0x10006000 0x1000>;
+ interrupts = ,
+,
+,
+;
+ infracfg = <>;
+ clocks = < CLK_TOP_HIF_SEL>;
+ clock-names = "hif_sel";
+ };
+
+ sysirq: interrupt-controller@10200620 {
+ compatible = "mediatek,sysirq";
+ reg = <0x10200620 0x20>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <>;
+ };
+
+ apmixedsys: apmixedsys@10209000 {
+ compatible = "mediatek,mt7622-apmixedsys";
+ reg = <0x10209000
[U-boot,v2,10/10] configs: mediatek: fix mt7623n bpir2 defconfig
This patch add CONFIG_TARGET_MT7623 into mt7623n_bpir2_defconfig to fix the mt7623 compile error after building others mediatek target platform Signed-off-by: Sam Shih Reviewed-by: Ryder Lee --- configs/mt7623n_bpir2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig index 58e93d5da6..d6ccae1942 100644 --- a/configs/mt7623n_bpir2_defconfig +++ b/configs/mt7623n_bpir2_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MEDIATEK=y +CONFIG_TARGET_MT7623=y CONFIG_SYS_TEXT_BASE=0x81e0 CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_ENV_SIZE=0x1000 -- 2.17.1
[U-boot,v2,08/10] Add support for MT7622 reference board
This adds a general board file based on MT7622 SoCs from MediaTek.
This commit is adding the basic boot support for the MT7622 rfb.
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/mt7622-rfb.dts| 180 +
board/mediatek/mt7622/Kconfig | 17 +++
board/mediatek/mt7622/MAINTAINERS | 6 +
board/mediatek/mt7622/Makefile | 4 +
board/mediatek/mt7622/mt7622_rfb.c | 23
configs/mt7622_rfb_defconfig | 55 +
include/configs/mt7622.h | 46
8 files changed, 332 insertions(+)
create mode 100644 arch/arm/dts/mt7622-rfb.dts
create mode 100644 board/mediatek/mt7622/Kconfig
create mode 100644 board/mediatek/mt7622/MAINTAINERS
create mode 100644 board/mediatek/mt7622/Makefile
create mode 100644 board/mediatek/mt7622/mt7622_rfb.c
create mode 100644 configs/mt7622_rfb_defconfig
create mode 100644 include/configs/mt7622.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3dc9c4d41c..b92980bd76 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -833,6 +833,7 @@ dtb-$(CONFIG_SOC_K3_J721E) +=
k3-j721e-common-proc-board.dtb \
k3-j721e-r5-common-proc-board.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += \
+ mt7622-rfb.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
mt8516-pumpkin.dtb \
diff --git a/arch/arm/dts/mt7622-rfb.dts b/arch/arm/dts/mt7622-rfb.dts
new file mode 100644
index 00..ec30f5c6eb
--- /dev/null
+++ b/arch/arm/dts/mt7622-rfb.dts
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+/dts-v1/;
+#include "mt7622.dtsi"
+#include "mt7622-u-boot.dtsi"
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "mt7622-rfb";
+ compatible = "mediatek,mt7622", "mediatek,mt7622-rfb";
+ chosen {
+ stdout-path =
+ tick-timer =
+ };
+
+ aliases {
+ spi0 =
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0x4000 0x1000>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+
+ {
+ snfi_pins: snfi-pins {
+ mux {
+ function = "flash";
+ groups = "snfi";
+ };
+ };
+
+ snor_pins: snor-pins {
+ mux {
+ function = "flash";
+ groups = "spi_nor";
+ };
+ };
+
+ uart0_pins: uart0 {
+ mux {
+ function = "uart";
+ groups = "uart0_0_tx_rx" ;
+ };
+ };
+
+ watchdog_pins: watchdog-default {
+ mux {
+ function = "watchdog";
+ groups = "watchdog";
+ };
+ };
+
+ mmc0_pins_default: mmc0default {
+ mux {
+ function = "emmc";
+ groups = "emmc";
+ };
+
+ /* "NDL0","NDL1","NDL2","NDL3","NDL4","NDL5","NDL6","NDL7",
+* "NRB","NCLE" pins are used as DAT0,DAT1,DAT2,DAT3,DAT4,
+* DAT5,DAT6,DAT7,CMD,CLK for eMMC respectively
+*/
+ conf-cmd-dat {
+ pins = "NDL0", "NDL1", "NDL2",
+ "NDL3", "NDL4", "NDL5",
+ "NDL6", "NDL7", "NRB";
+ input-enable;
+ bias-pull-up;
+ };
+
+ conf-clk {
+ pins = "NCLE";
+ bias-pull-down;
+ };
+
+ };
+
+ mmc1_pins_default: mmc1default {
+ mux {
+ function = "sd";
+ groups = "sd_0";
+ };
+ /* "I2S2_OUT, "I2S4_IN"", "I2S3_IN", "I2S2_IN",
+* "I2S4_OUT", "I2S3_OUT" are used as DAT0, DAT1,
+* DAT2, DAT3, CMD, CLK for SD respectively.
+*/
+ conf-cmd-data {
+ pins = "I2S2_OUT", "I2S4_IN", "I2S3_IN",
+ "I2S2_IN","I2S4_OUT";
+ input-enable;
+
[U-boot, v2, 09/10] arm: dts: mediatek: move u-boot properties to -u-boot.dtsi file
This patch move u-boot properties to -u-boot.dtsi file.
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
arch/arm/dts/mt7623-u-boot.dtsi | 29 +++
arch/arm/dts/mt7623.dtsi | 6
arch/arm/dts/mt7623n-bananapi-bpi-r2.dts | 1 +
arch/arm/dts/mt7629-rfb-u-boot.dtsi | 36
arch/arm/dts/mt7629-rfb.dts | 1 +
arch/arm/dts/mt7629.dtsi | 9 --
6 files changed, 67 insertions(+), 15 deletions(-)
create mode 100644 arch/arm/dts/mt7623-u-boot.dtsi
diff --git a/arch/arm/dts/mt7623-u-boot.dtsi b/arch/arm/dts/mt7623-u-boot.dtsi
new file mode 100644
index 00..832c16dca8
--- /dev/null
+++ b/arch/arm/dts/mt7623-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/mt7623.dtsi b/arch/arm/dts/mt7623.dtsi
index 1135b1e1ae..1f45dea575 100644
--- a/arch/arm/dts/mt7623.dtsi
+++ b/arch/arm/dts/mt7623.dtsi
@@ -101,21 +101,18 @@
compatible = "mediatek,mt7623-topckgen";
reg = <0x1000 0x1000>;
#clock-cells = <1>;
- u-boot,dm-pre-reloc;
};
infracfg: syscon@10001000 {
compatible = "mediatek,mt7623-infracfg", "syscon";
reg = <0x10001000 0x1000>;
#clock-cells = <1>;
- u-boot,dm-pre-reloc;
};
pericfg: syscon@10003000 {
compatible = "mediatek,mt7623-pericfg", "syscon";
reg = <0x10003000 0x1000>;
#clock-cells = <1>;
- u-boot,dm-pre-reloc;
};
pinctrl: pinctrl@10005000 {
@@ -155,7 +152,6 @@
interrupts = ;
clocks = <_clk>;
clock-names = "system-clk";
- u-boot,dm-pre-reloc;
};
sysirq: interrupt-controller@10200100 {
@@ -170,7 +166,6 @@
compatible = "mediatek,mt7623-apmixedsys";
reg = <0x10209000 0x1000>;
#clock-cells = <1>;
- u-boot,dm-pre-reloc;
};
gic: interrupt-controller@10211000 {
@@ -215,7 +210,6 @@
< CLK_PERI_UART2>;
clock-names = "baud", "bus";
status = "disabled";
- u-boot,dm-pre-reloc;
};
uart3: serial@11005000 {
diff --git a/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts
b/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts
index b0c86219b6..bcedcf20f1 100644
--- a/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/dts/mt7623n-bananapi-bpi-r2.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "mt7623.dtsi"
+#include "mt7623-u-boot.dtsi"
/ {
model = "Bananapi BPI-R2";
diff --git a/arch/arm/dts/mt7629-rfb-u-boot.dtsi
b/arch/arm/dts/mt7629-rfb-u-boot.dtsi
index 1ef5568518..164afd633b 100644
--- a/arch/arm/dts/mt7629-rfb-u-boot.dtsi
+++ b/arch/arm/dts/mt7629-rfb-u-boot.dtsi
@@ -22,3 +22,39 @@
#endif
};
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/mt7629-rfb.dts b/arch/arm/dts/mt7629-rfb.dts
index 0981f9b3b1..687fe1c029 100644
--- a/arch/arm/dts/mt7629-rfb.dts
+++ b/arch/arm/dts/mt7629-rfb.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "mt7629.dtsi"
+#include "mt7629-rfb-u-boot.dtsi"
/ {
model = "MediaTek MT7629 RFB";
diff --git a/arch/arm/dts/mt7629.dtsi b/arch/arm/dts/mt7629.dtsi
index b0c843bafd..a33a74a556 100644
--- a/arch/arm/dts/mt7629.dtsi
+++ b/arch/arm/dts/mt7629.dtsi
@@ -68,14 +68,12 @@
compatible = "mediatek,mt7629-infracfg", "syscon";
reg = <0x1000 0x1000>;
#clock-cells = <1>;
- u-boot,dm-pre-reloc;
};
pericfg: syscon@10002000 {
compatible = "mediatek,mt7629-pericfg", "syscon";
reg = <0x10002000 0x1000>;
#clock-cells = <1>;
- u-boot,dm-pre-reloc;
};
timer0: timer@10004000 {
@@ -85,7 +83,6 @@
clocks = < CLK_TOP_CLKXTAL_D4>,
< CLK_TOP_10M_SEL>;
clock-names = "mux", "src";
- u-boot,dm-pre-reloc;
};
scpsys: scpsys@10006000 {
@@ -103,7 +100,6 @@
compatible = "mediatek,mt7629-mcucfg", "syscon";
reg = <0x1020 0x1000>;
#clock-cells = <1>;
-
[U-boot,v2,06/10] power: domain: add power domain support for MT7622
This patch add power domain support for Mediatek MT7622 SoCs
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
---
drivers/power/domain/mtk-power-domain.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/power/domain/mtk-power-domain.c
b/drivers/power/domain/mtk-power-domain.c
index c67e8804b1..0bf8a16447 100644
--- a/drivers/power/domain/mtk-power-domain.c
+++ b/drivers/power/domain/mtk-power-domain.c
@@ -60,6 +60,7 @@
#define DCM_TOP_EN BIT(0)
enum scp_domain_type {
+ SCPSYS_MT7622,
SCPSYS_MT7623,
SCPSYS_MT7629,
};
@@ -328,6 +329,7 @@ static int mtk_power_domain_hook(struct udevice *dev)
case SCPSYS_MT7623:
scpd->data = scp_domain_mt7623;
break;
+ case SCPSYS_MT7622:
case SCPSYS_MT7629:
scpd->data = scp_domain_mt7629;
break;
@@ -378,6 +380,10 @@ static int mtk_power_domain_probe(struct udevice *dev)
}
static const struct udevice_id mtk_power_domain_ids[] = {
+ {
+ .compatible = "mediatek,mt7622-scpsys",
+ .data = SCPSYS_MT7622,
+ },
{
.compatible = "mediatek,mt7623-scpsys",
.data = SCPSYS_MT7623,
--
2.17.1
[U-boot,v2,04/10] clk: mediatek: add driver for MT7622
This patch add clock driver for MediaTek MT7622 SoC.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt7622.c | 678 +
include/dt-bindings/clock/mt7622-clk.h | 271 ++
3 files changed, 950 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt7622.c
create mode 100644 include/dt-bindings/clock/mt7622-clk.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index e92bcd4efe..755e24c651 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_MEDIATEK) += clk-mtk.o
# SoC Drivers
obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
+obj-$(CONFIG_TARGET_MT7622) += clk-mt7622.o
obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
diff --git a/drivers/clk/mediatek/clk-mt7622.c
b/drivers/clk/mediatek/clk-mt7622.c
new file mode 100644
index 00..a5b61a190b
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7622.c
@@ -0,0 +1,678 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT7622 SoC
+ *
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+
+#define MT7622_CLKSQ_STB_CON0 0x20
+#define MT7622_PLL_ISO_CON00x2c
+#define MT7622_PLL_FMAX(2500UL * MHZ)
+#define MT7622_CON0_RST_BARBIT(24)
+
+#define MCU_AXI_DIV0x640
+#define AXI_DIV_MSKGENMASK(4, 0)
+#define AXI_DIV_SEL(x) (x)
+
+#define MCU_BUS_MUX0x7c0
+#define MCU_BUS_MSKGENMASK(10, 9)
+#define MCU_BUS_SEL(x) ((x) << 9)
+
+/* apmixedsys */
+#define PLL(_id, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg, \
+ _pd_shift, _pcw_reg, _pcw_shift) { \
+ .id = _id, \
+ .reg = _reg,\
+ .pwr_reg = _pwr_reg,\
+ .en_mask = _en_mask,\
+ .rst_bar_mask = MT7622_CON0_RST_BAR,\
+ .fmax = MT7622_PLL_FMAX,\
+ .flags = _flags,\
+ .pcwbits = _pcwbits,\
+ .pd_reg = _pd_reg, \
+ .pd_shift = _pd_shift, \
+ .pcw_reg = _pcw_reg,\
+ .pcw_shift = _pcw_shift,\
+ }
+
+static const struct mtk_pll_data apmixed_plls[] = {
+ PLL(CLK_APMIXED_ARMPLL, 0x200, 0x20c, 0x1, 0,
+ 21, 0x204, 24, 0x204, 0),
+ PLL(CLK_APMIXED_MAINPLL, 0x210, 0x21c, 0x1, HAVE_RST_BAR,
+ 21, 0x214, 24, 0x214, 0),
+ PLL(CLK_APMIXED_UNIV2PLL, 0x220, 0x22c, 0x1, HAVE_RST_BAR,
+ 7, 0x224, 24, 0x224, 14),
+ PLL(CLK_APMIXED_ETH1PLL, 0x300, 0x310, 0x1, 0,
+ 21, 0x300, 1, 0x304, 0),
+ PLL(CLK_APMIXED_ETH2PLL, 0x314, 0x320, 0x1, 0,
+ 21, 0x314, 1, 0x318, 0),
+ PLL(CLK_APMIXED_AUD1PLL, 0x324, 0x330, 0x1, 0,
+ 31, 0x324, 1, 0x328, 0),
+ PLL(CLK_APMIXED_AUD2PLL, 0x334, 0x340, 0x1, 0,
+ 31, 0x334, 1, 0x338, 0),
+ PLL(CLK_APMIXED_TRGPLL, 0x344, 0x354, 0x1, 0,
+ 21, 0x344, 1, 0x348, 0),
+ PLL(CLK_APMIXED_SGMIPLL, 0x358, 0x368, 0x1, 0,
+ 21, 0x358, 1, 0x35c, 0),
+};
+
+/* topckgen */
+#define FACTOR0(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
+
+#define FACTOR1(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
+
+#define FACTOR2(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, 0)
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+ FIXED_CLK(CLK_TOP_TO_U2_PHY, CLK_XTAL, 3125),
+ FIXED_CLK(CLK_TOP_TO_U2_PHY_1P, CLK_XTAL, 3125),
+ FIXED_CLK(CLK_TOP_PCIE0_PIPE_EN, CLK_XTAL, 12500),
+ FIXED_CLK(CLK_TOP_PCIE1_PIPE_EN, CLK_XTAL, 12500),
+ FIXED_CLK(CLK_TOP_SSUSB_TX250M, CLK_XTAL, 25000),
+ FIXED_CLK(CLK_TOP_SSUSB_EQ_RX250M, CLK_XTAL, 25000),
+ FIXED_CLK(CLK_TOP_SSUSB_CDR_REF, CLK_XTAL, ),
+ FIXED_CLK(CLK_TOP_SSUSB_CDR_FB, CLK_XTAL, 5000),
+ FIXED_CLK(CLK_TOP_SATA_ASIC, CLK_XTAL, 5000),
+ FIXED_CLK(CLK_TOP_SATA_RBC, CLK_XTAL, 5000),
+};
+
+static const struct mtk_fixed_factor top_fixed_divs[] = {
+ FACTOR0(CLK_TOP_TO_USB3_SYS,
[U-boot,v2,00/10] Add support for MediaTek MT7622 SoC
This patch series adds basic boot support on eMMC/SD/spi-nor for the MediaTek MT7622 SoC based boards. This series add the clock, pinctrl drivers and the SoC initializaton code. Change since V1: - move mt7622/23/29 u-boot properties to -u-boot.dtsi files - pinctrl: mediatek: add support for different pinctrl: - use gpio_mode to replace gpio_func for easier understanding - fix mt7623n bpir2 defconfig - ARM: MediaTek: Add support for MediaTek MT7622 SoC - fix dram size in mm_region Sam Shih (10): ARM: MediaTek: Add support for MediaTek MT7622 SoC pinctrl: mediatek: add driver for MT7622 pinctrl: mediatek: add support for different pinctrl clk: mediatek: add driver for MT7622 clk: mediatek: fix clock-rate overflow problem power: domain: add power domain support for MT7622 mmc: add mmc and sd support for MT7622 Add support for MT7622 reference board arm: dts: mediatek: move u-boot properties to -u-boot.dtsi file configs: mediatek: fix mt7623n bpir2 defconfig arch/arm/dts/Makefile | 1 + arch/arm/dts/mt7622-rfb.dts | 180 + arch/arm/dts/mt7622-u-boot.dtsi | 29 + arch/arm/dts/mt7622.dtsi | 185 + arch/arm/dts/mt7623-u-boot.dtsi | 29 + arch/arm/dts/mt7623.dtsi | 6 - arch/arm/dts/mt7623n-bananapi-bpi-r2.dts | 1 + arch/arm/dts/mt7629-rfb-u-boot.dtsi | 36 + arch/arm/dts/mt7629-rfb.dts | 1 + arch/arm/dts/mt7629.dtsi | 9 - arch/arm/mach-mediatek/Kconfig| 9 + arch/arm/mach-mediatek/Makefile | 1 + arch/arm/mach-mediatek/mt7622/Makefile| 3 + arch/arm/mach-mediatek/mt7622/init.c | 51 ++ board/mediatek/mt7622/Kconfig | 17 + board/mediatek/mt7622/MAINTAINERS | 6 + board/mediatek/mt7622/Makefile| 4 + board/mediatek/mt7622/mt7622_rfb.c| 23 + configs/mt7622_rfb_defconfig | 55 ++ configs/mt7623n_bpir2_defconfig | 1 + drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt7622.c | 678 drivers/clk/mediatek/clk-mtk.c| 6 +- drivers/mmc/mtk-sd.c | 10 + drivers/pinctrl/mediatek/Kconfig | 4 + drivers/pinctrl/mediatek/Makefile | 1 + drivers/pinctrl/mediatek/pinctrl-mt7622.c | 754 ++ drivers/pinctrl/mediatek/pinctrl-mt7623.c | 2 + drivers/pinctrl/mediatek/pinctrl-mt7629.c | 2 + drivers/pinctrl/mediatek/pinctrl-mt8516.c | 2 + drivers/pinctrl/mediatek/pinctrl-mt8518.c | 2 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 122 ++- drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 12 +- drivers/power/domain/mtk-power-domain.c | 6 + include/configs/mt7622.h | 46 ++ include/dt-bindings/clock/mt7622-clk.h| 271 +++ 36 files changed, 2529 insertions(+), 37 deletions(-) create mode 100644 arch/arm/dts/mt7622-rfb.dts create mode 100644 arch/arm/dts/mt7622-u-boot.dtsi create mode 100644 arch/arm/dts/mt7622.dtsi create mode 100644 arch/arm/dts/mt7623-u-boot.dtsi create mode 100644 arch/arm/mach-mediatek/mt7622/Makefile create mode 100644 arch/arm/mach-mediatek/mt7622/init.c create mode 100644 board/mediatek/mt7622/Kconfig create mode 100644 board/mediatek/mt7622/MAINTAINERS create mode 100644 board/mediatek/mt7622/Makefile create mode 100644 board/mediatek/mt7622/mt7622_rfb.c create mode 100644 configs/mt7622_rfb_defconfig create mode 100644 drivers/clk/mediatek/clk-mt7622.c create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c create mode 100644 include/configs/mt7622.h create mode 100644 include/dt-bindings/clock/mt7622-clk.h -- 2.17.1
[U-boot,v2,02/10] pinctrl: mediatek: add driver for MT7622
This patch add Pinctrl driver for MediaTek MT7622 SoC.
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
drivers/pinctrl/mediatek/Kconfig | 4 +
drivers/pinctrl/mediatek/Makefile | 1 +
drivers/pinctrl/mediatek/pinctrl-mt7622.c | 752 ++
3 files changed, 757 insertions(+)
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7622.c
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 22ee62362b..b5d0baee38 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -4,6 +4,10 @@ config PINCTRL_MTK
depends on PINCTRL_GENERIC
bool
+config PINCTRL_MT7622
+ bool "MT7622 SoC pinctrl driver"
+ select PINCTRL_MTK
+
config PINCTRL_MT7623
bool "MT7623 SoC pinctrl driver"
select PINCTRL_MTK
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -3,6 +3,7 @@
obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
# SoC Drivers
+obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -0,0 +1,752 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author: Sam Shih
+ */
+
+#include
+
+#include "pinctrl-mtk-common.h"
+
+#define MT7622_PIN(_number, _name) MTK_PIN(_number, _name, DRV_GRP1)
+
+#define PIN_FIELD(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits) \
+ PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, \
+ _x_bits, 32, 0)
+
+#define PINS_FIELD(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits) \
+ PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, \
+ _x_bits, 32, 1)
+
+static const struct mtk_pin_field_calc mt7622_pin_mode_range[] = {
+ PIN_FIELD(0, 0, 0x320, 0x10, 16, 4),
+ PIN_FIELD(1, 4, 0x3a0, 0x10, 16, 4),
+ PIN_FIELD(5, 5, 0x320, 0x10, 0, 4),
+ PINS_FIELD(6, 7, 0x300, 0x10, 4, 4),
+ PIN_FIELD(8, 9, 0x350, 0x10, 20, 4),
+ PINS_FIELD(10, 13, 0x300, 0x10, 8, 4),
+ PIN_FIELD(14, 15, 0x320, 0x10, 4, 4),
+ PIN_FIELD(16, 17, 0x320, 0x10, 20, 4),
+ PIN_FIELD(18, 21, 0x310, 0x10, 16, 4),
+ PIN_FIELD(22, 22, 0x380, 0x10, 16, 4),
+ PINS_FIELD(23, 24, 0x300, 0x10, 24, 4),
+ PINS_FIELD(25, 36, 0x300, 0x10, 12, 4),
+ PINS_FIELD(37, 50, 0x300, 0x10, 20, 4),
+ PIN_FIELD(51, 70, 0x330, 0x10, 4, 4),
+ PINS_FIELD(71, 72, 0x300, 0x10, 16, 4),
+ PIN_FIELD(73, 76, 0x310, 0x10, 0, 4),
+ PIN_FIELD(77, 77, 0x320, 0x10, 28, 4),
+ PIN_FIELD(78, 78, 0x320, 0x10, 12, 4),
+ PIN_FIELD(79, 82, 0x3a0, 0x10, 0, 4),
+ PIN_FIELD(83, 83, 0x350, 0x10, 28, 4),
+ PIN_FIELD(84, 84, 0x330, 0x10, 0, 4),
+ PIN_FIELD(85, 90, 0x360, 0x10, 4, 4),
+ PIN_FIELD(91, 94, 0x390, 0x10, 16, 4),
+ PIN_FIELD(95, 97, 0x380, 0x10, 20, 4),
+ PIN_FIELD(98, 101, 0x390, 0x10, 0, 4),
+ PIN_FIELD(102, 102, 0x360, 0x10, 0, 4),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_dir_range[] = {
+ PIN_FIELD(0, 102, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_di_range[] = {
+ PIN_FIELD(0, 102, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_do_range[] = {
+ PIN_FIELD(0, 102, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_smt_range[] = {
+ PIN_FIELD(0, 31, 0x920, 0x10, 0, 1),
+ PIN_FIELD(32, 50, 0xa20, 0x10, 0, 1),
+ PIN_FIELD(51, 70, 0x820, 0x10, 0, 1),
+ PIN_FIELD(71, 72, 0xb20, 0x10, 0, 1),
+ PIN_FIELD(73, 86, 0xb20, 0x10, 4, 1),
+ PIN_FIELD(87, 90, 0xc20, 0x10, 0, 1),
+ PIN_FIELD(91, 102, 0xb20, 0x10, 18, 1),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_pu_range[] = {
+ PIN_FIELD(0, 31, 0x930, 0x10, 0, 1),
+ PIN_FIELD(32, 50, 0xa30, 0x10, 0, 1),
+ PIN_FIELD(51, 70, 0x830, 0x10, 0, 1),
+ PIN_FIELD(71, 72, 0xb30, 0x10, 0, 1),
+ PIN_FIELD(73, 86, 0xb30, 0x10, 4, 1),
+ PIN_FIELD(87, 90, 0xc30, 0x10, 0, 1),
+ PIN_FIELD(91, 102, 0xb30, 0x10, 18, 1),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_pd_range[] = {
+ PIN_FIELD(0, 31, 0x940, 0x10, 0, 1),
+ PIN_FIELD(32, 50, 0xa40, 0x10, 0, 1),
+ PIN_FIELD(51, 70, 0x840, 0x10, 0, 1),
+ PIN_FIELD(71, 72, 0xb40, 0x10, 0, 1),
+ PIN_FIELD(73, 86, 0xb40, 0x10, 4, 1),
+ PIN_FIELD(87, 90, 0xc40, 0x10, 0, 1),
+ PIN_FIELD(91, 102, 0xb40, 0x10, 18, 1),
+};
+
+static const struct mtk_pin_field_calc mt7622_pin_e4_range[] = {
+ PIN_FIELD(0, 31, 0x960, 0x10, 0, 1),
+ PIN_FIELD(32, 50, 0xa60, 0x10, 0, 1),
+ PIN_FIELD(51, 70, 0x860, 0x10, 0, 1),
+ PIN_FIELD(71, 72, 0xb60, 0x10, 0, 1),
+ PIN_FIELD(73, 86,
[U-boot, v2, 03/10] pinctrl: mediatek: add support for different pinctrl
Due to the pinctrl hardware of MT7622 is difference from others
SoC which using the common part of mediatek pinctrl.
So we need to modify the common part of mediatek pinctrl.
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
drivers/pinctrl/mediatek/pinctrl-mt7622.c | 2 +
drivers/pinctrl/mediatek/pinctrl-mt7623.c | 2 +
drivers/pinctrl/mediatek/pinctrl-mt7629.c | 2 +
drivers/pinctrl/mediatek/pinctrl-mt8516.c | 2 +
drivers/pinctrl/mediatek/pinctrl-mt8518.c | 2 +
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 122 +++---
drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 12 +-
7 files changed, 125 insertions(+), 19 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
index 2a4bf43c32..1aa323c009 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -728,6 +728,8 @@ static struct mtk_pinctrl_soc mt7622_data = {
.ngrps = ARRAY_SIZE(mt7622_groups),
.funcs = mt7622_functions,
.nfuncs = ARRAY_SIZE(mt7622_functions),
+ .gpio_mode = 1,
+ .rev = MTK_PINCTRL_V0,
};
static int mtk_pinctrl_mt7622_probe(struct udevice *dev)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c
b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
index fd37dfa442..d58d840e08 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7623.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
@@ -1242,6 +1242,8 @@ static struct mtk_pinctrl_soc mt7623_data = {
.ngrps = ARRAY_SIZE(mt7623_groups),
.funcs = mt7623_functions,
.nfuncs = ARRAY_SIZE(mt7623_functions),
+ .gpio_mode = 0,
+ .rev = MTK_PINCTRL_V1,
};
/*
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7629.c
b/drivers/pinctrl/mediatek/pinctrl-mt7629.c
index aa6d1c2d91..37640dd2b6 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7629.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7629.c
@@ -387,6 +387,8 @@ static struct mtk_pinctrl_soc mt7629_data = {
.ngrps = ARRAY_SIZE(mt7629_groups),
.funcs = mt7629_functions,
.nfuncs = ARRAY_SIZE(mt7629_functions),
+ .gpio_mode = 0,
+ .rev = MTK_PINCTRL_V1,
};
static int mtk_pinctrl_mt7629_probe(struct udevice *dev)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8516.c
b/drivers/pinctrl/mediatek/pinctrl-mt8516.c
index 829b30e5a2..62e339e931 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8516.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8516.c
@@ -369,6 +369,8 @@ static struct mtk_pinctrl_soc mt8516_data = {
.ngrps = ARRAY_SIZE(mt8516_groups),
.funcs = mt8516_functions,
.nfuncs = ARRAY_SIZE(mt8516_functions),
+ .gpio_mode = 0,
+ .rev = MTK_PINCTRL_V1,
};
static int mtk_pinctrl_mt8516_probe(struct udevice *dev)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8518.c
b/drivers/pinctrl/mediatek/pinctrl-mt8518.c
index 8d2cd948f6..91427aed4b 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8518.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8518.c
@@ -389,6 +389,8 @@ static struct mtk_pinctrl_soc mt8518_data = {
.ngrps = ARRAY_SIZE(mt8518_groups),
.funcs = mt8518_functions,
.nfuncs = ARRAY_SIZE(mt8518_functions),
+ .gpio_mode = 0,
+ .rev = MTK_PINCTRL_V1,
};
static int mtk_pinctrl_mt8518_probe(struct udevice *dev)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 3004335c57..c7351f32bb 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -294,7 +294,72 @@ static const struct pinconf_param mtk_conf_params[] = {
{ "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 0 },
};
-int mtk_pinconf_drive_set(struct udevice *dev, u32 pin, u32 arg)
+
+int mtk_pinconf_bias_set_v0(struct udevice *dev, u32 pin, u32 arg)
+{
+ int err, disable, pullup;
+
+ disable = (arg == PIN_CONFIG_BIAS_DISABLE);
+ pullup = (arg == PIN_CONFIG_BIAS_PULL_UP);
+
+ if (disable) {
+ err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PU, 0);
+ if (err)
+ return err;
+ err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PD, 0);
+ if (err)
+ return err;
+
+ } else {
+ err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PU, pullup);
+ if (err)
+ return err;
+ err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PD, !pullup);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin, u32 arg)
+{
+ int err, disable, pullup;
+
+ disable = (arg == PIN_CONFIG_BIAS_DISABLE);
+ pullup = (arg == PIN_CONFIG_BIAS_PULL_UP);
+
+ if (disable) {
+ err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PULLEN, 0);
+ if (err)
+
[U-boot,v2,05/10] clk: mediatek: fix clock-rate overflow problem
This patch fix clock-rate overflow problem in mediatek
clock driver common part.
Signed-off-by: Sam Shih
Reviewed-by: Ryder Lee
---
drivers/clk/mediatek/clk-mtk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 6c6b500d9b..9c30be994e 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -39,7 +39,7 @@
* this function is recursively called to find the parent to calculate
* the accurate frequency.
*/
-static int mtk_clk_find_parent_rate(struct clk *clk, int id,
+static ulong mtk_clk_find_parent_rate(struct clk *clk, int id,
const struct driver *drv)
{
struct clk parent = { .id = id, };
@@ -265,7 +265,7 @@ static ulong mtk_factor_recalc_rate(const struct
mtk_fixed_factor *fdiv,
return rate;
}
-static int mtk_topckgen_get_factor_rate(struct clk *clk, u32 off)
+static ulong mtk_topckgen_get_factor_rate(struct clk *clk, u32 off)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_fixed_factor *fdiv = >tree->fdivs[off];
@@ -287,7 +287,7 @@ static int mtk_topckgen_get_factor_rate(struct clk *clk,
u32 off)
return mtk_factor_recalc_rate(fdiv, rate);
}
-static int mtk_topckgen_get_mux_rate(struct clk *clk, u32 off)
+static ulong mtk_topckgen_get_mux_rate(struct clk *clk, u32 off)
{
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_composite *mux = >tree->muxes[off];
--
2.17.1
Re: Wandboard - I2C error when booting with HDMI cable
Hi Heiko,
On Tue, Dec 10, 2019 at 2:26 AM Heiko Schocher wrote:
> May you increase timeout in "arch/arm/mach-imx/i2c-mxv7.c"
>
> 49 elapsed = get_timer(start_time);
> 50 if (elapsed > (CONFIG_SYS_HZ / 5)) {/* .2 seconds */
> 51 ret = -EBUSY;
Thanks for your email.
Unfortunately increasing the timeout does not help.
I will investigate more.
Thanks
Re: [PATCH] configs: sama5d27_som1_ek: Add default config to read ENV from QSPI
On 02.12.2019 23:06, Swapna Gurumani - C40450 wrote: > From: Swapna Gurumani > > In the initial SPI flash setup, the default bus mode being used was 3, > which is incorrect, causing a CRC error when the ENV was being read from > QSPI. Setting the default bus mode to 0 which is the correct mode. > > Signed-off-by: Swapna Gurumani Applied to u-boot-atmel/master, thanks !
Re: [PATCH 2/2] video: make BPP and ANSI configs optional
On Thu, 5 Dec 2019 18:15:49 +0100 Anatolij Gustschin ag...@denx.de wrote: ... > drivers/video/Kconfig | 8 > drivers/video/console_normal.c | 10 +- > 105 files changed, 180 insertions(+), 9 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 1/2] video: add guards around 16bpp/32bbp code
On Thu, 5 Dec 2019 18:15:48 +0100 Anatolij Gustschin ag...@denx.de wrote: ... > drivers/video/vidconsole-uclass.c | 6 ++ > drivers/video/video-uclass.c | 4 > 2 files changed, 10 insertions(+) Applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH v2 2/2] video: bmp: Fix video_display_rle8_bitmap()
On Wed, 20 Nov 2019 14:11:16 +0100 Patrice Chotard patrice.chot...@st.com wrote: ... > Changes in v2: None > > drivers/video/video_bmp.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH v2 1/2] video: bmp: Fix video_splash_align_axis()
On Wed, 20 Nov 2019 14:11:15 +0100 Patrice Chotard patrice.chot...@st.com wrote: ... > Changes in v2: > - Convert panel_picture_delta from unsigned long to long > > drivers/video/video_bmp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Also changed 'axis_alignment' to long and applied to u-boot-video/master, thanks! -- Anatolij
Pull request: socfpga-next
Hi Marek,
after fixing Stratix10 build warnings, please pull this updated Agilex
series for next.
Travis ran successfully this time:
https://travis-ci.org/goldsimon/u-boot/builds/622657322
Regards,
Simon
The following changes since commit b38c3a641fc01fcd4eda5fa107ae3c247baa0196:
Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86
(2019-12-08 10:51:00 -0500)
are available in the git repository at:
https://github.com/goldsimon/u-boot.git socfpga-next
for you to fetch changes up to ea3dd6e26aadf03f4a182d3350d74d8dc5a19c51:
arm: socfpga: agilex: Enable Agilex SoC build (2019-12-09 14:10:56 +0100)
Ley Foon Tan (24):
spl: Allow cache drivers to be used in SPL
arm: dts: socfpga: Add u-boot, dm-pre-reloc for sysmgr and clkmgr nodes
arm: socfpga: Convert reset manager from struct to defines
arm: socfpga: Convert system manager from struct to defines
arm: socfpga: Convert clock manager from struct to defines
arm: socfpga: agilex: Add base address for Intel Agilex SoC
arm: socfpga: Move firewall code to firewall file
arm: socfpga: Move Stratix10 and Agilex reset manager common code
arm: socfpga: agilex: Add reset manager support
arm: socfpga: Move Stratix10 and Agilex system manager common code
arm: socfpga: agilex: Add system manager support
arm: socfpga: Move Stratix10 and Agilex clock manager common code
arm: socfpga: Fix CLKMGR_INTOSC_HZ to 400MHz
clk: agilex: Add clock driver for Agilex
arm: socfpga: agilex: Add clock wrapper functions
cache: Add Arteris Ncore cache coherent unit driver
arm: agilex: Add clock handoff offset for Agilex
ddr: altera: Restructure Stratix 10 SDRAM driver
ddr: altera: agilex: Add SDRAM driver for Agilex
board: intel: agilex: Add socdk board support for Intel Agilex SoC
arm: socfpga: agilex: Add SPL for Agilex SoC
arm: dts: agilex: Add base dtsi and devkit dts
configs: socfpga: Move Stratix10 and Agilex common CONFIGs
arm: socfpga: agilex: Enable Agilex SoC build
arch/arm/Kconfig | 4 +-
arch/arm/dts/Makefile | 1 +
arch/arm/dts/socfpga-common-u-boot.dtsi | 8 ++
arch/arm/dts/socfpga.dtsi | 2 +-
arch/arm/dts/socfpga_agilex-u-boot.dtsi |
96 +
arch/arm/dts/socfpga_agilex.dtsi |
622
+
arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 39 ++
arch/arm/dts/socfpga_agilex_socdk.dts |
141 +++
arch/arm/dts/socfpga_arria10.dtsi | 2 +-
arch/arm/dts/socfpga_arria10_socdk.dtsi | 8 ++
arch/arm/dts/socfpga_stratix10.dtsi | 2 +-
arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 8 ++
arch/arm/mach-socfpga/Kconfig | 16 +++
arch/arm/mach-socfpga/Makefile| 17 +++
arch/arm/mach-socfpga/clock_manager.c | 14 +-
arch/arm/mach-socfpga/clock_manager_agilex.c |
85 +++
arch/arm/mach-socfpga/clock_manager_arria10.c |
155 +++-
arch/arm/mach-socfpga/clock_manager_gen5.c|
211
arch/arm/mach-socfpga/clock_manager_s10.c |
218 +
arch/arm/mach-socfpga/firewall.c |
107 ++
arch/arm/mach-socfpga/include/mach/base_addr_s10.h| 4 +
arch/arm/mach-socfpga/include/mach/clock_manager.h| 4 +
arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h | 14 ++
arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h|
133 +++---
arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h |
112 +++
arch/arm/mach-socfpga/include/mach/clock_manager_s10.h|
131 +++--
arch/arm/mach-socfpga/include/mach/clock_manager_soc64.h | 21 +++
arch/arm/mach-socfpga/include/mach/{firewall_s10.h => firewall.h} | 10 +-
arch/arm/mach-socfpga/include/mach/handoff_s10.h | 9 +-
arch/arm/mach-socfpga/include/mach/misc.h | 1 +
arch/arm/mach-socfpga/include/mach/reset_manager.h| 7 +-
arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h| 43 ++
arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h | 22 ++-
arch/arm/mach-socfpga/include/mach/reset_manager_s10.h|
118
Re: [U-Boot] [PATCH] net: eth-uclass: Remove warning about ROM MAC address
Hi Joe, On Fri, Oct 11, 2019 at 12:06 AM Joe Hershberger wrote: > > Hi Soeren, > > On Thu, Oct 10, 2019 at 6:01 PM Soeren Moch wrote: > > > > Using a MAC address from ROM storage is the normal case for most > > ethernet hardware. Why should we warn about this? > > Most hardware that U-Boot runs on is an SoC and the boards rarely have > a ROM associated with the Ethernet MAC. Usually the storage for the > ethaddr is the U-Boot environment itself. That's the reason it warns. On i.MX SoCs the MAC usually is stored in fuses via On-Chip OTP Controller (OCOTP). Should we at least change the message to debug() level instead? As Soeren says there is nothing wrong with the fact that the MAC addresses are retrieved from fuses and there is nothing the user can do about this warning message. IMHO it is causing pure noise. Thanks
Re: [U-Boot] [PATCH] net: eth-uclass: Remove warning about ROM MAC address
Hi Soeren,
On Thu, Oct 10, 2019 at 8:01 PM Soeren Moch wrote:
>
> Using a MAC address from ROM storage is the normal case for most
> ethernet hardware. Why should we warn about this?
>
> Signed-off-by: Soeren Moch
> ---
> Cc: Joe Hershberger
> Cc: u-boot@lists.denx.de
> ---
> net/eth-uclass.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 3bd98b01ad..8b29de37bb 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -538,8 +538,6 @@ static int eth_post_probe(struct udevice *dev)
> memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
> } else if (is_valid_ethaddr(pdata->enetaddr)) {
> eth_env_set_enetaddr_by_index("eth", dev->seq,
> pdata->enetaddr);
> - printf("\nWarning: %s using MAC address from ROM\n",
> - dev->name);
I also find this warning misleading:
Reviewed-by: Fabio Estevam
Re: [PATCH] arm: dts: bcm283x: Allow UARTs to work before relocation
Hi Simon,
On 02/12/2019 16:45, Tom Rini wrote:
> On Sun, Dec 01, 2019 at 07:33:56PM -0700, Simon Glass wrote:
>
>> At present the pinctrl nodes are not enabled in pre-relocation U-Boot so
>> the UARTs do not correctly select the pinconfig to enable the UART pins.
>> Fix this so that the U-Boot banner is printed.
>>
>> Signed-off-by: Simon Glass
>> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
>> ---
>>
>> arch/arm/dts/bcm283x-u-boot.dtsi | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi
>> b/arch/arm/dts/bcm283x-u-boot.dtsi
>> index 36548dad62..68d03627f4 100644
>> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
>> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
>> @@ -19,3 +19,11 @@
>> {
>> u-boot,dm-pre-reloc;
>> };
>> +
>> +_gpio14 {
>> +u-boot,dm-pre-reloc;
>> +};
>> +
>> +_gpio14 {
>> +u-boot,dm-pre-reloc;
>> +};
>
> I think this is superseded by the RPi PR that I had been testing and
> just now pushed. Can you confirm that master is fine on your Pis as
> well? I gather you hit this failure doing pytest on the board, which is
> also how I found it. Thanks!
>
Can you confirm if this is working with master branch or if we still need your
patch. In which situation would we need your patch then?
Regards,
Matthias
[PATCH v3 1/2] wandboard: Fix the DM_PMIC conversion
Commit ec837c82d709 ("imx6: wandboard: convert to DM_PMIC")
caused the following pmic_get() error:
CPU: Freescale i.MX6QP rev1.0 at 792 MHz
Reset cause: POR
DRAM: 2 GiB
PMIC: pmic_get() ret -19
...
and since the PMIC presence is used to determine the board D1 revision,
the following error is seen when booting a board rev D1:
WARNING: Could not determine dtb to use
and the kernel does not boot at all.
Fix the regression by passing "pfuze100@8" as the correct parameter
to the pmic_get() function in the DM case.
Fixes: ec837c82d709 ("imx6: wandboard: convert to DM_PMIC")
Signed-off-by: Fabio Estevam
---
Changes since v2:
- None
board/wandboard/wandboard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index 6c1e4ef27d..b2f961a7f0 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -363,7 +363,7 @@ int power_init_board(void)
puts("PMIC: ");
- ret = pmic_get("pfuze100", );
+ ret = pmic_get("pfuze100@8", );
if (ret < 0) {
printf("pmic_get() ret %d\n", ret);
return 0;
--
2.17.1
[PATCH v3 2/2] wandboard: Remove repeated PMIC string
After the conversion to DM_PMIC the following output is seen:
PMIC: PMIC: PFUZE100 ID=0x10
Remove the unnecessary PMIC string from the board file to
avoid the repetead string.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- None
board/wandboard/wandboard.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index 7209cc8211..e386ad2cc1 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -361,8 +361,6 @@ int power_init_board(void)
struct udevice *dev;
int reg, ret;
- puts("PMIC: ");
-
ret = pmic_get("pfuze100@8", );
if (ret < 0) {
printf("pmic_get() ret %d\n", ret);
--
2.17.1
Re: [PATCH v2 2/3] wandboard: Propagate the error on PMIC function failure
On Mon, Dec 9, 2019 at 9:20 PM Fabio Estevam wrote:
> diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
> index b2f961a7f0..7209cc8211 100644
> --- a/board/wandboard/wandboard.c
> +++ b/board/wandboard/wandboard.c
> @@ -366,13 +366,13 @@ int power_init_board(void)
> ret = pmic_get("pfuze100@8", );
> if (ret < 0) {
> printf("pmic_get() ret %d\n", ret);
> - return 0;
> + return ret;
Ops, we can't return error here because this causes issues on the
boards without PMIC.
I will resend the series without this patch.
> }
>
> reg = pmic_reg_read(dev, PFUZE100_DEVICEID);
> if (reg < 0) {
> printf("pmic_reg_read() ret %d\n", reg);
> - return 0;
> + return ret;
> }
> printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
> with_pmic = true;
> --
> 2.17.1
>
[PATCH v2 4/4] doc: uefi.rst: Document launching UEFI binaries from FIT images
This patch adds a new section "Launching a UEFI binary from a FIT image"
documenting the usage of the CONFIG_BOOTM_EFI extension to bootm command
that offers a secure boot alternative for UEFI binaries such as GRUB2.
Signed-off-by: Cristian Ciocaltea
---
doc/uefi/uefi.rst | 34 ++
1 file changed, 34 insertions(+)
diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index db942df694..a8fd886d6b 100644
--- a/doc/uefi/uefi.rst
+++ b/doc/uefi/uefi.rst
@@ -63,6 +63,40 @@ The environment variable 'bootargs' is passed as load
options in the UEFI system
table. The Linux kernel EFI stub uses the load options as command line
arguments.
+Launching a UEFI binary from a FIT image
+
+
+A signed FIT image can be used to securely boot a UEFI image via the
+bootm command. This feature is available if U-Boot is configured with::
+
+CONFIG_BOOTM_EFI=y
+
+A sample configuration is provided as file doc/uImage.FIT/uefi.its.
+
+Below you find the output of an example session starting GRUB::
+
+=> load mmc 0:1 ${kernel_addr_r} image.fit
+4620426 bytes read in 83 ms (53.1 MiB/s)
+=> bootm ${kernel_addr_r}#config-grub-nofdt
+## Loading kernel from FIT Image at 4040 ...
+ Using 'config-grub-nofdt' configuration
+ Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
+ Trying 'efi-grub' kernel subimage
+ Description: GRUB EFI Firmware
+ Created: 2019-11-20 8:18:16 UTC
+ Type: Kernel Image (no loading done)
+ Compression: uncompressed
+ Data Start: 0x404000d0
+ Data Size:450560 Bytes = 440 KiB
+ Hash algo:sha256
+ Hash value:
4dbee00021112df618f58b3f7cf5e1595533d543094064b9ce991e8b054a9eec
+ Verifying Hash Integrity ... sha256+ OK
+ XIP Kernel Image (no loading done)
+## Transferring control to EFI (at address 404000d0) ...
+Welcome to GRUB!
+
+See doc/uImage.FIT/howto.txt for an introduction to FIT images.
+
Executing the boot manager
~~
--
2.17.1
[PATCH v2 3/4] doc: Add sample uefi.its image description file
This patch adds an example FIT image description file demonstrating
the usage of bootm command to securely launch UEFI binaries.
Signed-off-by: Cristian Ciocaltea
---
doc/uImage.FIT/uefi.its | 67 +
1 file changed, 67 insertions(+)
create mode 100644 doc/uImage.FIT/uefi.its
diff --git a/doc/uImage.FIT/uefi.its b/doc/uImage.FIT/uefi.its
new file mode 100644
index 00..e336ad938d
--- /dev/null
+++ b/doc/uImage.FIT/uefi.its
@@ -0,0 +1,67 @@
+/*
+ * Example FIT image description file demonstrating the usage of
+ * bootm command to launch UEFI binaries.
+ *
+ * Two boot configurations are available to enable booting GRUB2 on QEMU,
+ * the former uses a FDT blob contained in the FIT image, while the later
+ * relies on the FDT provided by the board emulator.
+ */
+
+/dts-v1/;
+
+/ {
+ description = "GRUB2 EFI and QEMU FDT blob";
+ #address-cells = <1>;
+
+ images {
+ efi-grub {
+ description = "GRUB EFI Firmware";
+ data = /incbin/("efi-part/EFI/BOOT/bootarm.efi");
+ type = "kernel_noload";
+ arch = "arm";
+ os = "efi";
+ compression = "none";
+ load = <0x0>;
+ entry = <0x0>;
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+
+ fdt-qemu {
+ description = "QEMU DTB";
+ data = /incbin/("qemu-arm.dtb");
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ hash-1 {
+ algo = "sha256";
+ };
+ };
+ };
+
+ configurations {
+ default = "config-grub-fdt";
+
+ config-grub-fdt {
+ description = "GRUB EFI Boot with FDT";
+ kernel = "efi-grub";
+ fdt = "fdt-qemu";
+ signature-1 {
+ algo = "sha256,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "kernel", "fdt";
+ };
+ };
+
+ config-grub-nofdt {
+ description = "GRUB EFI Boot w/o FDT";
+ kernel = "efi-grub";
+ signature-1 {
+ algo = "sha256,rsa2048";
+ key-name-hint = "dev";
+ sign-images = "kernel";
+ };
+ };
+ };
+};
--
2.17.1
[PATCH v2 2/4] bootm: Add a bootm command for type IH_OS_EFI
Add support for booting EFI binaries contained in FIT images.
A typical usage scenario is chain-loading GRUB2 in a verified
boot environment.
Signed-off-by: Cristian Ciocaltea
---
cmd/Kconfig | 7 ++
common/bootm_os.c | 61 +++
2 files changed, 68 insertions(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index cf982ff65e..39fa87082d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -263,6 +263,13 @@ config CMD_BOOTI
help
Boot an AArch64 Linux Kernel image from memory.
+config BOOTM_EFI
+ bool "Support booting EFI OS images"
+ depends on CMD_BOOTEFI
+ default y
+ help
+ Support booting EFI images via the bootm command.
+
config BOOTM_LINUX
bool "Support booting Linux OS images"
depends on CMD_BOOTM || CMD_BOOTZ || CMD_BOOTI
diff --git a/common/bootm_os.c b/common/bootm_os.c
index 6fb7d658da..7aa76052b9 100644
--- a/common/bootm_os.c
+++ b/common/bootm_os.c
@@ -6,10 +6,12 @@
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -462,6 +464,62 @@ static int do_bootm_tee(int flag, int argc, char * const
argv[],
}
#endif
+#ifdef CONFIG_BOOTM_EFI
+static int do_bootm_efi(int flag, int argc, char * const argv[],
+ bootm_headers_t *images)
+{
+ int ret;
+ efi_status_t efi_ret;
+ uintptr_t fdt_addr;
+ void *image_buf;
+
+ if (flag != BOOTM_STATE_OS_GO)
+ return 0;
+
+ /* Locate EFI binary and FDT, if provided */
+ ret = bootm_find_images(flag, argc, argv);
+ if (ret)
+ return ret;
+
+ /* Initialize EFI drivers */
+ efi_ret = efi_init_obj_list();
+ if (efi_ret != EFI_SUCCESS) {
+ printf("## Error: Cannot initialize UEFI sub-system, r = %lu\n",
+ efi_ret & ~EFI_ERROR_MASK);
+ return 1;
+ }
+
+ /* Install device tree */
+ if (images->ft_len)
+ fdt_addr = (uintptr_t)images->ft_addr;
+ else
+ fdt_addr = EFI_FDT_USE_INTERNAL;
+
+ efi_ret = efi_install_fdt(fdt_addr);
+ if (efi_ret != EFI_SUCCESS) {
+ printf("## Error: Cannot install device tree, r = %lu\n",
+ efi_ret & ~EFI_ERROR_MASK);
+ return 1;
+ }
+
+ /* Run EFI image */
+ printf("## Transferring control to EFI (at address %08lx) ...\n",
+ images->ep);
+ bootstage_mark(BOOTSTAGE_ID_RUN_OS);
+
+ image_buf = map_sysmem(images->ep, images->os.image_len);
+
+ efi_ret = efi_run_image(image_buf, images->os.image_len);
+ if (efi_ret != EFI_SUCCESS) {
+ printf("## Error: Cannot run EFI image, r = %lu\n",
+ efi_ret & ~EFI_ERROR_MASK);
+ return 1;
+ }
+
+ return 0;
+}
+#endif
+
static boot_os_fn *boot_os[] = {
[IH_OS_U_BOOT] = do_bootm_standalone,
#ifdef CONFIG_BOOTM_LINUX
@@ -498,6 +556,9 @@ static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_OPTEE
[IH_OS_TEE] = do_bootm_tee,
#endif
+#ifdef CONFIG_BOOTM_EFI
+ [IH_OS_EFI] = do_bootm_efi,
+#endif
};
/* Allow for arch specific config before we boot */
--
2.17.1
[PATCH v2 0/4] Add support for booting EFI FIT images
Currently the only way to run an EFI binary like GRUB2 is via the
'bootefi' command, which cannot be used in a verified boot scenario.
The obvious solution to this limitation is to add support for
booting FIT images containing those EFI binaries.
The implementation relies on a new image type - IH_OS_EFI - which
can be created by using 'os = "efi"' inside an ITS file:
/ {
#address-cells = <1>;
images {
efi-grub {
description = "GRUB EFI";
data = /incbin/("EFI/BOOT/bootarm.efi");
type = "kernel_noload";
arch = "arm";
os = "efi";
compression = "none";
load = <0x0>;
entry = <0x0>;
hash-1 {
algo = "sha256";
};
};
};
configurations {
default = "config-grub";
config-grub {
kernel = "efi-grub";
signature-1 {
algo = "sha256,rsa2048";
sign-images = "kernel";
};
};
};
};
The bootm command has been extended to handle the IH_OS_EFI images.
To enable this feature, a new configuration option has been added:
BOOTM_EFI
I tested the solution using the 'qemu_arm' board:
=> load scsi 0:1 ${kernel_addr_r} efi-image.fit
=> bootm ${kernel_addr_r}#config-grub
Changes since v1:
* Rebase patches on Heinrich Schuchardt's patch series:
efi_loader: prepare for FIT images
https://lists.denx.de/pipermail/u-boot/2019-December/393192.html
* Add sample configuration: doc/uImage.FIT/uefi.its
* Update uefi documentation: doc/uefi/uefi.rst
Cristian Ciocaltea (4):
image: Add IH_OS_EFI for EFI chain-load boot
bootm: Add a bootm command for type IH_OS_EFI
doc: Add sample uefi.its image description file
doc: uefi.rst: Document launching UEFI binaries from FIT images
cmd/Kconfig | 7 +
common/bootm_os.c | 61 +
common/image-fit.c | 3 +-
common/image.c | 1 +
doc/uImage.FIT/uefi.its | 67 +
doc/uefi/uefi.rst | 34 +
include/image.h | 1 +
7 files changed, 173 insertions(+), 1 deletion(-)
create mode 100644 doc/uImage.FIT/uefi.its
--
2.17.1
[PATCH v2 1/4] image: Add IH_OS_EFI for EFI chain-load boot
Add a new OS type to be used for chain-loading an EFI compatible
firmware or boot loader like GRUB2, possibly in a verified boot
scenario.
Bellow is sample ITS file that generates a FIT image supporting
secure boot. Please note the presence of 'os = "efi";' line, which
identifies the currently introduced OS type:
/ {
#address-cells = <1>;
images {
efi-grub {
description = "GRUB EFI";
data = /incbin/("EFI/BOOT/bootarm.efi");
type = "kernel_noload";
arch = "arm";
os = "efi";
compression = "none";
load = <0x0>;
entry = <0x0>;
hash-1 {
algo = "sha256";
};
};
};
configurations {
default = "config-grub";
config-grub {
kernel = "efi-grub";
signature-1 {
algo = "sha256,rsa2048";
sign-images = "kernel";
};
};
};
};
Signed-off-by: Cristian Ciocaltea
---
common/image-fit.c | 3 ++-
common/image.c | 1 +
include/image.h| 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index 5c63c769de..19e313bf41 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1925,7 +1925,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
image_type == IH_TYPE_FPGA ||
fit_image_check_os(fit, noffset, IH_OS_LINUX) ||
fit_image_check_os(fit, noffset, IH_OS_U_BOOT) ||
- fit_image_check_os(fit, noffset, IH_OS_OPENRTOS);
+ fit_image_check_os(fit, noffset, IH_OS_OPENRTOS) ||
+ fit_image_check_os(fit, noffset, IH_OS_EFI);
/*
* If either of the checks fail, we should report an error, but
diff --git a/common/image.c b/common/image.c
index f17fa40c49..2e0e2b0e7f 100644
--- a/common/image.c
+++ b/common/image.c
@@ -134,6 +134,7 @@ static const table_entry_t uimage_os[] = {
{ IH_OS_OPENRTOS, "openrtos", "OpenRTOS", },
#endif
{ IH_OS_OPENSBI, "opensbi", "RISC-V OpenSBI", },
+ { IH_OS_EFI, "efi", "EFI Firmware" },
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index f4d2aaf53e..4a280b78e7 100644
--- a/include/image.h
+++ b/include/image.h
@@ -157,6 +157,7 @@ enum {
IH_OS_ARM_TRUSTED_FIRMWARE, /* ARM Trusted Firmware */
IH_OS_TEE, /* Trusted Execution Environment */
IH_OS_OPENSBI, /* RISC-V OpenSBI */
+ IH_OS_EFI, /* EFI Firmware (e.g. GRUB2) */
IH_OS_COUNT,
};
--
2.17.1
Re: [PATCH 1/1] common: remove duplicate typedef for uchar
Hi Heinrich,
On Tue, Dec 10, 2019 at 12:44 AM Heinrich Schuchardt wrote:
>
> With commit 37db55b7e9db ("linux/types.h: fix typo unchar") we have a
> duplicate typedef for uchar. As linux/types.h is included in common.h we
> don't need another typedef for uchar there.
>
> Fixes: 37db55b7e9db ("linux/types.h: fix typo unchar")
> Signed-off-by: Heinrich Schuchardt
Reviewed-by: Joe Hershberger
