Re: [U-Boot] [PATCH 2/2] fdt: fdtdec_setup_memory_banksize() use livetree
Hi Simon, On Tue, Sep 18, 2018 at 4:05 AM, Simon Glass wrote: > Hi Jen, > > On 17 August 2018 at 14:48, Simon Glass wrote: >> >> On 10 August 2018 at 06:54, Jens Wiklander wrote: >> > Converts fdtdec_setup_memory_banksize() to use ofnode functions instead. >> > >> > Signed-off-by: Jens Wiklander >> > --- >> > lib/fdtdec.c | 46 +- >> > 1 file changed, 21 insertions(+), 25 deletions(-) >> > >> >> Reviewed-by: Simon Glass > > > Can you please rebase this on u-boot-dm/testing and resent? It seems > to conflict with an existing patch. I'm sorry, missed this one. It seems it's already been done by now. Thanks, Jens ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level
On 09/25/2018 02:21 AM, Joel Stanley wrote:
> On Fri, 21 Sep 2018 at 16:09, Cédric Le Goater wrote:
>>
>> This is a large update of the AST2500 Soc DTS file bringing it to the
>> level of commit 927c2fc2db19 :
>>
>> Author: Joel Stanley
>> Date:Sat Jun 2 01:18:53 2018 -0700
>>
>> ARM: dts: aspeed: Fix hwrng register address
>>
>> There are some differences on the compatibility property names. scu,
>> reset and clock drivers are also different.
>
> You made the required changes in this patch? We should document those
> so we know how to sync it next time.
I only changed where the nodes were defined in the u-boot DTS file. As
for the sync, it is necessarily manual :/ See below for the differences.
The clocks are defined in another DTS file in u-boot. May be there is
room for improvements on both sides tough.
Syncing the "compatible" strings would be a good thing.
> If it's possible, we can also add compatible properties to the Linux
> version of the device tree to make syncing easier.
>
>> Signed-off-by: Cédric Le Goater
>
> Reviewed-by: Joel Stanley
Thanks,
C.
--- linux/arch/arm/boot/dts/aspeed-g5.dtsi 2018-06-14 16:30:01.790506371
+0200
+++ u-boot/arch/arm//dts/ast2500.dtsi 2018-09-22 17:35:14.302476829 +0200
@@ -1,5 +1,8 @@
-// SPDX-License-Identifier: GPL-2.0+
-#include
+/*
+ * This device tree is copied from
+ *
https://raw.githubusercontent.com/torvalds/linux/34ea5c9d/arch/arm/boot/dts/aspeed-g5.dtsi
+ */
+#include "skeleton.dtsi"
/ {
model = "Aspeed BMC";
@@ -59,7 +62,6 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-fmc";
- clocks = < ASPEED_CLK_AHB>;
status = "disabled";
interrupts = <19>;
flash@0 {
@@ -85,7 +87,6 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-spi";
- clocks = < ASPEED_CLK_AHB>;
status = "disabled";
flash@0 {
reg = < 0 >;
@@ -105,7 +106,6 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-spi";
- clocks = < ASPEED_CLK_AHB>;
status = "disabled";
flash@0 {
reg = < 0 >;
@@ -131,7 +131,6 @@
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e66 0x180>;
interrupts = <2>;
- clocks = < ASPEED_CLK_GATE_MAC1CLK>;
status = "disabled";
};
@@ -139,7 +138,6 @@
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e68 0x180>;
interrupts = <3>;
- clocks = < ASPEED_CLK_GATE_MAC2CLK>;
status = "disabled";
};
@@ -147,7 +145,6 @@
compatible = "aspeed,ast2500-ehci", "generic-ehci";
reg = <0x1e6a1000 0x100>;
interrupts = <5>;
- clocks = < ASPEED_CLK_GATE_USBPORT1CLK>;
status = "disabled";
};
@@ -155,7 +152,6 @@
compatible = "aspeed,ast2500-ehci", "generic-ehci";
reg = <0x1e6a3000 0x100>;
interrupts = <13>;
- clocks = < ASPEED_CLK_GATE_USBPORT2CLK>;
status = "disabled";
};
@@ -164,7 +160,6 @@
reg = <0x1e6b 0x100>;
interrupts = <14>;
#ports = <2>;
- clocks = < ASPEED_CLK_GATE_USBUHCICLK>;
status = "disabled";
};
@@ -175,10 +170,8 @@
ranges;
syscon: syscon@1e6e2000 {
- compatible = "aspeed,ast2500-scu", "syscon",
"simple-mfd";
+ compatible = "aspeed,g5-scu", "syscon",
"simple-mfd";
reg = <0x1e6e2000 0x1a8>;
- #address-cells = <1>;
- #size-cells = <0>;
#clock-cells = <1>;
#reset-cells = <1>;
@@ -189,6 +182,39 @@
};
};
+ clk_clkin: clk_clkin@1e6e2070 {
+ #clock-cells = <0>;
+ compatible = "aspeed,g5-clkin-clock";
+ reg = <0x1e6e2070
Re: [U-Boot] [PATCH v6 08/14] regmap: Add raw read/write functions
On Sat, Sep 22, 2018 at 3:55 AM Simon Glass wrote:
>
> Hi Mario,
>
> On 21 September 2018 at 01:02, Mario Six wrote:
> >
> > Hi Simon,
> >
> > On Fri, Aug 17, 2018 at 2:52 PM Simon Glass wrote:
> > >
> > > Hi Mario,
> > >
> > > On 13 August 2018 at 00:09, Mario Six wrote:
> > > > The regmap functions currently assume that all register map accesses
> > > > have a data width of 32 bits, but there are maps that have different
> > > > widths.
> > > >
> > > > To rectify this, implement the regmap_raw_read and regmap_raw_write
> > > > functions from the Linux kernel API that specify the width of a desired
> > > > read or write operation on a regmap.
> > > >
> > > > Implement the regmap_read and regmap_write functions using these raw
> > > > functions in a backwards-compatible manner.
> > > >
> > > > Reviewed-by: Anatolij Gustschin
> > > > Signed-off-by: Mario Six
> > > >
> > > > ---
> > > >
> > > > v5 -> v6:
> > > > * Corrected format specifier
> > > > * Added support for 64-bit reads/writes
> > > >
> > > > v4 -> v5:
> > > > No changes
> > > >
> > > > v3 -> v4:
> > > > * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> > > > * Explained the difference between the raw and non-raw read/write
> > > > functions better in the docs
> > > >
> > > > v2 -> v3:
> > > > * Implement the "raw" functions from Linux instead of adding a size
> > > > parameter to the regmap_{read,write} functions
> > > > * Fixed style violation
> > > > * Improved error handling
> > > >
> > > > v1 -> v2:
> > > > New in v2
> > > >
> > > > ---
> > > > drivers/core/regmap.c | 59
> > > > +--
> > > > include/regmap.h | 58
> > > > ++
> > > > 2 files changed, 110 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> > > > index 154426269d9..a2f82091af0 100644
> > > > --- a/drivers/core/regmap.c
> > > > +++ b/drivers/core/regmap.c
> > > > @@ -188,22 +188,67 @@ int regmap_uninit(struct regmap *map)
> > > > return 0;
> > > > }
> > > >
> > > > +int regmap_raw_read(struct regmap *map, uint offset, void *valp,
> > > > size_t val_len)
> > > > +{
> > > > + void *ptr;
> > > > +
> > > > + ptr = map_physmem(map->ranges[0].start + offset, val_len,
> > > > MAP_NOCACHE);
> > > > +
> > > > + switch (val_len) {
> > > > + case REGMAP_SIZE_8:
> > > > + *((u8 *)valp) = in_8((u8 *)ptr);
> > > > + break;
> > > > + case REGMAP_SIZE_16:
> > > > + *((u16 *)valp) = in_le16((u16 *)ptr);
> > > > + break;
> > > > + case REGMAP_SIZE_32:
> > > > + *((u32 *)valp) = in_le32((u32 *)ptr);
> > > > + break;
> > > > +#if defined(in_le64) && defined(readq)
> > > > + case REGMAP_SIZE_64:
> > > > + *((u32 *)valp) = in_le64((u64 *)ptr);
> > >
> > > How come this is u32? Can you please add a comment?
> > >
> >
> > That was a development version of the patch, sorry (I was in a bit of a
> > hurry).
> >
> > I'll send a corrected version with v7.
> >
> > > Why is this using in/out rather than read/write? Does it not support
> > > memory-mapped I/O?
> > >
> >
> > It does, but I think the endianness of the read/write operations of the
> > regmap
> > should not depend on the architecture, but only on the regmap itself (which
> > is
> > little-endian for now; big-endian support can be introduced later on), so I
> > used in/out rather than read/write.
>
If regmap currently only supports little-endian, can we document this somewhere?
> What does endianness have to do with whether you use readl/writel or in/out?
>
> On x86 at least these are actually different things, so regmap() won't
> work on x86 with this change.
>
Looks so far x86's {in,out}_{8,16,32} are using MMIO.
> Adding Bin who may understand this better.
BTW: I was trying to understand why we need regmap here. Shouldn't the
driver directly call {in,out}{bwl}, or {read,write}{bwlq} APIs?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3.1 01/26] fs: fat: guard the content of include/fat.h
On Sun, Sep 23, 2018 at 04:42:17PM +0200, Alexander Graf wrote: > > > On 12.09.18 08:55, Akashi, Takahiro wrote: > > From: AKASHI Takahiro > > > > The whole content of include/fat.h should be guarded with CONFIG_FS_FAT. > > > > This is necessary specifically because fs/fs.c unconditionally includes > > fat.h, which refers to a config symbol, CONFIG_FS_FAT_MAX_CLUSTSIZE. > > So if CONFIG_FS_FAT, and thus CONFIG_FS_FAT_MAX_CLUSTSIZE, is not > > defined, fs/fs.c will fail to compile. > > I don't see that define used anywhere outside of FAT code, so I still > don't understand why we need this patch. Try to compile u-boot without CONFIG_FS_FAT. You will find out what I (and originally Heinrich) meant. Thanks, -Takahiro Akashi > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 21/23] test/py: convert fs-test.sh to pytest
Simon, Sorry for not responding soon. On Fri, Sep 14, 2018 at 12:54:57PM +0200, Simon Glass wrote: > Hi Akashi, > > On 4 September 2018 at 09:49, AKASHI Takahiro > wrote: > > In this commit, the same set of test cases as in test/fs/fs-test.sh > > is provided using pytest framework. > > Actually, fs-test.sh provides three variants:"sb" (sb command), "nonfs" > > (fatxx and etc.) and "fs" (hostfs), and this patch currently supports > > only "nonfs" variant; So it is not a replacement of fs-test.sh for now. > > > > Simple usage: > > $ py.test test/py/tests/test_fs [] > > > > You may also specify filesystem types to be tested: > > $ py.test test/py/tests/test_fs --fs-type fat32 [] > > > > Signed-off-by: AKASHI Takahiro > > --- > > test/py/tests/test_fs/conftest.py| 216 > > test/py/tests/test_fs/fstest_defs.py | 10 + > > test/py/tests/test_fs/test_basic.py | 287 +++ > > 3 files changed, 513 insertions(+) > > create mode 100644 test/py/tests/test_fs/conftest.py > > create mode 100644 test/py/tests/test_fs/fstest_defs.py > > create mode 100644 test/py/tests/test_fs/test_basic.py > > Thanks for doing this! > > Can you also please delete the old shell script? No, we can't. As I said in the commit message, my script currently supports only one of three test variants in fs-test.sh, "nonfs." "sb" and "fs" are yet to be implemented (if necessary). > Does this get automatically executed with 'make tests'? Yes, of course. > If not, is it possible to do that easily, if we reduce the size of files, etc? > > > > > diff --git a/test/py/tests/test_fs/conftest.py > > b/test/py/tests/test_fs/conftest.py > > new file mode 100644 > > index ..9155ccf84266 > > --- /dev/null > > +++ b/test/py/tests/test_fs/conftest.py > > @@ -0,0 +1,216 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# Copyright (c) 2018, Linaro Limited > > +# Author: Takahiro Akashi > > + > > +import os > > +import os.path > > +import pytest > > +import re > > +from subprocess import call, check_call, check_output, CalledProcessError > > +from fstest_defs import * > > + > > +supported_fs_basic = ['fat16', 'fat32', 'ext4'] > > + > > +# > > +# Filesystem test specific setup > > +# > > +def pytest_addoption(parser): > > Please can you add full function comments to each function? You can > see other tests or binman for the format to use. > [...] OK. -Takahiro Akashi > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: Add support for the Arm's Versatile Express I2C controller.
Hello Liviu,
Am 18.09.2018 um 06:21 schrieb Heiko Schocher:
Hello Liviu,
Am 17.09.2018 um 18:51 schrieb Liviu Dudau:
The Arm Versatile Express I2C controller is a simple register-based
controller that uses a register to control the state of the SCL and
SDA lines. Add support for it.
Signed-off-by: Liviu Dudau
---
drivers/i2c/Kconfig | 7 +
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-versatile.c | 270
3 files changed, 278 insertions(+)
create mode 100644 drivers/i2c/i2c-versatile.c
Reviewed-by: Heiko Schocher
I am unsure here, if all your patches are a patchserie, or if this
i2c patch can go seperately through i2c tree ...
I got some checkpatch errors:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#64:
new file mode 100644
WARNING: Missing a blank line after declarations
#105: FILE: drivers/i2c/i2c-versatile.c:37:
+ int v = !!(readl(priv->base + I2C_CONTROL_REG) & SDA);
+ udelay(priv->delay);
WARNING: Missing a blank line after declarations
#118: FILE: drivers/i2c/i2c-versatile.c:50:
+ int v = !!(readl(priv->base + I2C_CONTROL_REG) & SCL);
+ udelay(priv->delay);
WARNING: line over 80 characters
#187: FILE: drivers/i2c/i2c-versatile.c:119:
+static int versatile_i2c_read_byte(struct versatile_i2c_priv *priv, u8 *byte,
u8 ack)
WARNING: Missing a blank line after declarations
#260: FILE: drivers/i2c/i2c-versatile.c:192:
+ u8 ack = (msg->len - i - 1) == 0 ? 1 : 0;
+ ret = versatile_i2c_read_byte(priv, >buf[i], ack);
WARNING: line over 80 characters
#274: FILE: drivers/i2c/i2c-versatile.c:206:
+static int versatile_i2c_xfer(struct udevice *bus, struct i2c_msg *msg, int
nmsgs)
WARNING: line over 80 characters
#288: FILE: drivers/i2c/i2c-versatile.c:220:
+static int versatile_i2c_chip_probe(struct udevice *bus, uint chip, uint
chip_flags)
WARNING: line over 80 characters
#291: FILE: drivers/i2c/i2c-versatile.c:223:
+ struct i2c_msg msg = { .addr = chip, .flags = chip_flags, .len = 0,
.buf = NULL };
WARNING: line over 80 characters
#314: FILE: drivers/i2c/i2c-versatile.c:246:
+ /* U-Boot still doesn't assign automatically sequence numbers to
devices */
Please fix them, also "git am" says:
Applying: i2c: Add support for the Arm's Versatile Express I2C controller.
error: new file drivers/i2c/i2c-versatile.c depends on old contents
error: could not build fake ancestor
Could you please rebase your patch on current mainline U-Boot ?
Thanks!
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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] WIP: x86: acpi: Generate SPCR table
Hi Andy,
On Sat, Sep 22, 2018 at 9:05 PM Andy Shevchenko
wrote:
>
> TBD
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/include/asm/acpi_table.h | 25 ++
> arch/x86/lib/acpi_table.c | 82 +++
> 2 files changed, 107 insertions(+)
>
> diff --git a/arch/x86/include/asm/acpi_table.h
> b/arch/x86/include/asm/acpi_table.h
> index 95fae036f6..27435871b9 100644
> --- a/arch/x86/include/asm/acpi_table.h
> +++ b/arch/x86/include/asm/acpi_table.h
> @@ -303,6 +303,31 @@ struct acpi_mcfg_mmconfig {
> /* ACPI global NVS structure */
> struct acpi_global_nvs;
>
> +/* SPCR (Serial Port Console Redirection table) */
> +struct __packed acpi_spcr {
> + struct acpi_table_header header;/* Common ACPI table header */
> + u8 interface_type; /* 0=full 16550, 1=subset of 16550 */
> + u8 reserved[3];
> + struct acpi_gen_regaddr serial_port;/* The base address of the
> Serial Port register set */
> + u8 interrupt_type;
> + u8 pc_interrupt;
> + u32 interrupt; /* Global system interrupt */
> + u8 baud_rate;
> + u8 parity;
> + u8 stop_bits;
> + u8 flow_control;
> + u8 terminal_type;
> + u8 reserved1;
> + u16 pci_device_id; /* Must be 0x if not PCI device */
> + u16 pci_vendor_id; /* Must be 0x if not PCI device */
> + u8 pci_bus;
> + u8 pci_device;
> + u8 pci_function;
> + u32 pci_flags;
> + u8 pci_segment;
> + u32 reserved2;
> +};
> +
> /* These can be used by the target port */
>
> void acpi_fill_header(struct acpi_table_header *header, char *signature);
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index c6b2026613..551a78b11a 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -338,6 +339,79 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
> header->checksum = table_compute_checksum((void *)mcfg,
> header->length);
> }
>
> +static void acpi_create_spcr(struct acpi_spcr *spcr)
> +{
> + struct acpi_table_header *header = &(spcr->header);
> + struct serial_device_info info = {0};
> + int access_size;
> + int ret;
> +
> + /* Fill out header fields */
> + acpi_fill_header(header, "SPCR");
> + header->length = sizeof(struct acpi_spcr);
> + header->revision = 2;
> +
> + ret = serial_getinfo();
> + if (ret)
> + debug("Can't get information of serial device: %d\n", ret);
> +
> + /* Encode baud rate */
> + switch (info.baudrate) {
> + case 9600:
> + spcr->baud_rate = 3;
> + break;
> + case 19200:
> + spcr->baud_rate = 4;
> + break;
> + case 57600:
> + spcr->baud_rate = 6;
> + break;
> + case 115200:
> + spcr->baud_rate = 7;
> + break;
> + default:
> + spcr->baud_rate = 0;
> + break;
> + }
> +
> + /* Encode register access size */
> + switch (info.reg_shift) {
> + case 0:
> + access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS;
> + break;
> + case 1:
> + access_size = ACPI_ACCESS_SIZE_WORD_ACCESS;
> + break;
> + case 2:
> + access_size = ACPI_ACCESS_SIZE_DWORD_ACCESS;
> + break;
> + case 3:
> + access_size = ACPI_ACCESS_SIZE_QWORD_ACCESS;
> + break;
> + default:
> + access_size = ACPI_ACCESS_SIZE_UNDEFINED;
> + break;
> + }
> +
> + spcr->serial_port.space_id = ACPI_ADDRESS_SPACE_MEMORY;
> + spcr->serial_port.bit_width = info.reg_width;
> + spcr->serial_port.bit_offset = info.reg_offset;
> + spcr->serial_port.access_size = access_size;
> + spcr->serial_port.addrl = info.addr >> 0;
> + spcr->serial_port.addrh = info.addr >> 32;
> +
> + /* Hard coded values for now */
> + spcr->parity = 0;
> + spcr->stop_bits = 1;
> +
> + /* No PCI devices for now */
> + spcr->pci_device_id = 0x;
> + spcr->pci_vendor_id = 0x;
> +
I see not every member of 'struct __packed acpi_spcr' is populated.
Are they not used by kernel? If kernel does not use it, it is used by
Windows?
> + /* Fix checksum */
> + header->checksum = table_compute_checksum((void *)spcr,
> header->length);
> +}
> +
> /*
> * QEMU's version of write_acpi_tables is defined in drivers/misc/qfw.c
> */
> @@ -352,6 +426,7 @@ ulong write_acpi_tables(ulong start)
> struct acpi_fadt *fadt;
> struct acpi_mcfg *mcfg;
> struct acpi_madt *madt;
> + struct acpi_spcr *spcr;
> int i;
>
> current = start;
> @@ -440,6 +515,13 @@ ulong
Re: [U-Boot] [PATCH v1 1/2] WIP: serial: Introduce ->getinfo() callback
Hi Andy,
On Sat, Sep 22, 2018 at 9:05 PM Andy Shevchenko
wrote:
>
> TBD
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/serial/ns16550.c | 14 ++
> drivers/serial/serial-uclass.c | 21 +
> include/common.h | 3 +++
> include/serial.h | 14 ++
> 4 files changed, 52 insertions(+)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index f9041aa626..a996446936 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -334,6 +334,19 @@ static int ns16550_serial_setbrg(struct udevice *dev,
> int baudrate)
> return 0;
> }
>
> +static int ns16550_serial_getinfo(struct udevice *dev, struct
> serial_device_info *info)
> +{
> + struct NS16550 *const com_port = dev_get_priv(dev);
> + struct ns16550_platdata *plat = com_port->plat;
> +
> + info->addr_space = 0;
This one is tricky. Looks current 8250 DT binding does not have a
property to describe the address space to be MMIO or PIO. I am not
sure what's the best option here.
> + info->reg_width = 8;
For this one, I believe we can use "reg-io-width" property from device tree.
> + info->reg_shift = plat->reg_shift;
> + info->reg_offset = plat->reg_offset;
> + info->addr = plat->base;
> + return 0;
> +}
> +
> int ns16550_serial_probe(struct udevice *dev)
> {
> struct NS16550 *const com_port = dev_get_priv(dev);
> @@ -440,6 +453,7 @@ const struct dm_serial_ops ns16550_serial_ops = {
> .pending = ns16550_serial_pending,
> .getc = ns16550_serial_getc,
> .setbrg = ns16550_serial_setbrg,
> + .getinfo = ns16550_serial_getinfo,
> };
>
> #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index ffdcae0931..4778302e8f 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -304,6 +304,25 @@ int serial_setconfig(uint config)
> return 0;
> }
>
> +int serial_getinfo(struct serial_device_info *info)
> +{
> + struct dm_serial_ops *ops;
> +
> + if (!gd->cur_serial_dev)
> + return -ENODEV;
> +
> + if (!info)
> + return -EINVAL;
> +
> + info->baudrate = gd->baudrate;
> +
> + ops = serial_get_ops(gd->cur_serial_dev);
> + if (ops->getinfo)
> + return ops->getinfo(gd->cur_serial_dev, info);
> +
> + return -EINVAL;
> +}
> +
> void serial_stdio_init(void)
> {
> }
> @@ -421,6 +440,8 @@ static int serial_post_probe(struct udevice *dev)
> if (ops->loop)
> ops->loop += gd->reloc_off
> #endif
> + if (ops->getinfo)
> + ops->getinfo += gd->reloc_off;
> #endif
> /* Set the baud rate */
> if (ops->setbrg) {
> diff --git a/include/common.h b/include/common.h
> index 83b3bdc58d..0479f3eac1 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -349,6 +349,8 @@ void smp_set_core_boot_addr(unsigned long addr, int
> corenr);
> void smp_kick_all_cpus(void);
>
> /* $(CPU)/serial.c */
> +struct serial_device_info;
> +
> intserial_init (void);
> void serial_setbrg (void);
> void serial_putc (const char);
> @@ -357,6 +359,7 @@ voidserial_puts (const char *);
> intserial_getc (void);
> intserial_tstc (void);
> intserial_setconfig(uint config);
> +intserial_getinfo(struct serial_device_info *info);
>
> /* $(CPU)/speed.c */
> intget_clocks (void);
> diff --git a/include/serial.h b/include/serial.h
> index 020cd392e8..c73477b079 100644
> --- a/include/serial.h
> +++ b/include/serial.h
> @@ -111,6 +111,16 @@ enum serial_stop {
> SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
> SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
>
> +/* REVISIT: ACPI GAS specification implied */
> +struct serial_device_info {
> + unsigned int baudrate;
> + u8 addr_space; /* 0 - MMIO, 1 - IO */
> + u8 reg_width;
> + u8 reg_offset;
> + u8 reg_shift;
> + u64 addr;
> +};
> +
> /**
> * struct struct dm_serial_ops - Driver model serial operations
> *
> @@ -201,6 +211,10 @@ struct dm_serial_ops {
> * @return 0 if OK, -ve on error
> */
> int (*setconfig)(struct udevice *dev, uint serial_config);
> + /**
> +* getinfo() - Get serial device information
> +*/
> + int (*getinfo)(struct udevice *dev, struct serial_device_info *info);
> };
Generally this patch looks OK to me.
BTW: why doesn't the kernel use the 'earlycon' command line?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] qe: kconfig: U QE kconfig
Hi York, > -Original Message- > From: York Sun > Sent: Saturday, September 22, 2018 02:50 > To: Ran Wang ; Alison Wang > ; Sumit Garg > Cc: Qiang Zhao ; u-boot@lists.denx.de > Subject: Re: [PATCH 1/3] qe: kconfig: U QE kconfig > > On 08/09/2018 02:56 AM, Ran Wang wrote: > > add Kconfig option for U QUICC Engine. > > > > Signed-off-by: Ran Wang > > --- > > drivers/Kconfig| 2 ++ > > drivers/qe/Kconfig | 8 > > 2 files changed, 10 insertions(+) > > create mode 100644 drivers/qe/Kconfig > > > > diff --git a/drivers/Kconfig b/drivers/Kconfig index c2e813f..da2f811 > > 100644 > > --- a/drivers/Kconfig > > +++ b/drivers/Kconfig > > @@ -68,6 +68,8 @@ source "drivers/power/Kconfig" > > > > source "drivers/pwm/Kconfig" > > > > +source "drivers/qe/Kconfig" > > + > > source "drivers/ram/Kconfig" > > > > source "drivers/remoteproc/Kconfig" > > diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig new file mode > > 100644 index 000..e2dd2e7 > > --- /dev/null > > +++ b/drivers/qe/Kconfig > > @@ -0,0 +1,8 @@ > > +# > > +# QUICC Engine Drivers > > +# > > +config U_QE > > + bool "Enable support for U QUICC Engine" > > + default y if ARCH_LS1021A && !SD_BOOT && !NAND_BOOT > && !QSPI_BOOT > > + help > > + Choose this option to add support for U QUICC Engine. > > > > Since you add Kconfig option, you should migrate all existing #define > CONFIG_U_QE to Kconfig/defconfig. So far only T102x, T1040, LS1021, > LS1043 have this option defined. OK, will cover this in next version. Regards, Ran > York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/13] x86: Fix signed shift overflow in MSR_IA32_APICBASE_BASE
Hi Eugeniu,
On Sun, Sep 23, 2018 at 7:10 AM Eugeniu Rosca wrote:
>
> Hi Bin,
>
> jFYI, I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392
> ("UBSAN behavior on left-shifting 1 into the sign bit is dependent on C
> standard"), to get some recommendation from GCC guys how to handle
> these warnings in U-Boot.
Thank you very much for following up with the gcc folks! Let's see how
they respond.
BTW: your bug report is elaborate. Well done on the research!
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level
On Fri, 21 Sep 2018 at 16:09, Cédric Le Goater wrote: > > This is a large update of the AST2500 Soc DTS file bringing it to the > level of commit 927c2fc2db19 : > > Author: Joel Stanley > Date:Sat Jun 2 01:18:53 2018 -0700 > > ARM: dts: aspeed: Fix hwrng register address > > There are some differences on the compatibility property names. scu, > reset and clock drivers are also different. You made the required changes in this patch? We should document those so we know how to sync it next time. If it's possible, we can also add compatible properties to the Linux version of the device tree to make syncing easier. > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley Cheers, Joel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] aspeed: Activate SPI support on the ast2500 Eval Board
On Fri, 21 Sep 2018 at 16:09, Cédric Le Goater wrote: > > Signed-off-by: Cédric Le Goater > Reviewed-by: Jagan Teki Reviewed-by: Joel Stanley ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] efi_selftest: use CR LF in helloworld
The UEFI spec defines that a line feed moves the cursor to the next line
and (only) a carriage return moves the cursor to the beginning of the line.
So we should issue CR LF when we want to get to the start of the next line.
Add some comments.
Signed-off-by: Heinrich Schuchardt
---
v2
correct Sphinx comments %s/Result/Return/
---
lib/efi_loader/helloworld.c | 40 +
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 3b8de5b4ea..93d4cec1f4 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -17,6 +17,16 @@ static const efi_guid_t fdt_guid = EFI_FDT_GUID;
static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
+/**
+ * hw_memcmp() - compare memory areas
+ *
+ * @buf1: pointer to first area
+ * @buf2: pointer to second area
+ * @length:number of bytes to compare
+ * Return: 0 if both memory areas are the same, otherwise the sign of the
+ * result value is the same as the sign of ghe difference between
+ * the first differing pair of bytes taken as u8.
+ */
static int hw_memcmp(const void *buf1, const void *buf2, size_t length)
{
const u8 *pos1 = buf1;
@@ -31,12 +41,12 @@ static int hw_memcmp(const void *buf1, const void *buf2,
size_t length)
return 0;
}
-/*
- * Entry point of the EFI application.
+/**
+ * efi_main() - entry point of the EFI application.
*
- * @handle handle of the loaded image
- * @systable system table
- * @return status code
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:status code
*/
efi_status_t EFIAPI efi_main(efi_handle_t handle,
struct efi_system_table *systable)
@@ -48,7 +58,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
efi_uintn_t i;
u16 rev[] = L"0.0.0";
- con_out->output_string(con_out, L"Hello, world!\n");
+ /* UEFI requires CR LF */
+ con_out->output_string(con_out, L"Hello, world!\r\n");
/* Print the revision number */
rev[0] = (systable->hdr.revision >> 16) + '0';
@@ -65,27 +76,30 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
con_out->output_string(con_out, L"Running on UEFI ");
con_out->output_string(con_out, rev);
- con_out->output_string(con_out, L"\n");
+ con_out->output_string(con_out, L"\r\n");
/* Get the loaded image protocol */
ret = boottime->handle_protocol(handle, _image_guid,
(void **)_image);
if (ret != EFI_SUCCESS) {
- con_out->output_string(con_out,
- L"Cannot open loaded image protocol\n");
+ con_out->output_string
+ (con_out, L"Cannot open loaded image protocol\r\n");
goto out;
}
/* Find configuration tables */
for (i = 0; i < systable->nr_tables; ++i) {
if (!hw_memcmp(>tables[i].guid, _guid,
sizeof(efi_guid_t)))
- con_out->output_string(con_out, L"Have device tree\n");
+ con_out->output_string
+ (con_out, L"Have device tree\r\n");
if (!hw_memcmp(>tables[i].guid, _guid,
sizeof(efi_guid_t)))
- con_out->output_string(con_out, L"Have ACPI 2.0
table\n");
+ con_out->output_string
+ (con_out, L"Have ACPI 2.0 table\r\n");
if (!hw_memcmp(>tables[i].guid, _guid,
sizeof(efi_guid_t)))
- con_out->output_string(con_out, L"Have SMBIOS table\n");
+ con_out->output_string
+ (con_out, L"Have SMBIOS table\r\n");
}
/* Output the load options */
con_out->output_string(con_out, L"Load options: ");
@@ -94,7 +108,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
(u16 *)loaded_image->load_options);
else
con_out->output_string(con_out, L"");
- con_out->output_string(con_out, L"\n");
+ con_out->output_string(con_out, L"\r\n");
out:
boottime->exit(handle, ret, 0, NULL);
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_selftest: use CR LF in helloworld
The UEFI spec defines that a line feed moves the cursor to the next line
and (only) a carriage return moves the cursor to the beginning of the line.
So we should issue CR LF when we want to get to the start of the next line.
Add some comments.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/helloworld.c | 40 +
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 3b8de5b4ea..93d4cec1f4 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -17,6 +17,16 @@ static const efi_guid_t fdt_guid = EFI_FDT_GUID;
static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
+/**
+ * hw_memcmp() - compare memory areas
+ *
+ * @buf1: pointer to first area
+ * @buf2: pointer to second area
+ * @length:number of bytes to compare
+ * Result: 0 if both memory areas are the same, otherwise the sign of the
+ * result value is the same as the sign of ghe difference between
+ * the first differing pair of bytes taken as u8.
+ */
static int hw_memcmp(const void *buf1, const void *buf2, size_t length)
{
const u8 *pos1 = buf1;
@@ -31,12 +41,12 @@ static int hw_memcmp(const void *buf1, const void *buf2,
size_t length)
return 0;
}
-/*
- * Entry point of the EFI application.
+/**
+ * efi_main() - entry point of the EFI application.
*
- * @handle handle of the loaded image
- * @systable system table
- * @return status code
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:status code
*/
efi_status_t EFIAPI efi_main(efi_handle_t handle,
struct efi_system_table *systable)
@@ -48,7 +58,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
efi_uintn_t i;
u16 rev[] = L"0.0.0";
- con_out->output_string(con_out, L"Hello, world!\n");
+ /* UEFI requires CR LF */
+ con_out->output_string(con_out, L"Hello, world!\r\n");
/* Print the revision number */
rev[0] = (systable->hdr.revision >> 16) + '0';
@@ -65,27 +76,30 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
con_out->output_string(con_out, L"Running on UEFI ");
con_out->output_string(con_out, rev);
- con_out->output_string(con_out, L"\n");
+ con_out->output_string(con_out, L"\r\n");
/* Get the loaded image protocol */
ret = boottime->handle_protocol(handle, _image_guid,
(void **)_image);
if (ret != EFI_SUCCESS) {
- con_out->output_string(con_out,
- L"Cannot open loaded image protocol\n");
+ con_out->output_string
+ (con_out, L"Cannot open loaded image protocol\r\n");
goto out;
}
/* Find configuration tables */
for (i = 0; i < systable->nr_tables; ++i) {
if (!hw_memcmp(>tables[i].guid, _guid,
sizeof(efi_guid_t)))
- con_out->output_string(con_out, L"Have device tree\n");
+ con_out->output_string
+ (con_out, L"Have device tree\r\n");
if (!hw_memcmp(>tables[i].guid, _guid,
sizeof(efi_guid_t)))
- con_out->output_string(con_out, L"Have ACPI 2.0
table\n");
+ con_out->output_string
+ (con_out, L"Have ACPI 2.0 table\r\n");
if (!hw_memcmp(>tables[i].guid, _guid,
sizeof(efi_guid_t)))
- con_out->output_string(con_out, L"Have SMBIOS table\n");
+ con_out->output_string
+ (con_out, L"Have SMBIOS table\r\n");
}
/* Output the load options */
con_out->output_string(con_out, L"Load options: ");
@@ -94,7 +108,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
(u16 *)loaded_image->load_options);
else
con_out->output_string(con_out, L"");
- con_out->output_string(con_out, L"\n");
+ con_out->output_string(con_out, L"\r\n");
out:
boottime->exit(handle, ret, 0, NULL);
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Kconfig: move CONFIG_STANDALONE_LOAD_ADDR to Kconfig
On 24.09.2018 19:55, Max Filippov wrote: > On Sun, Sep 23, 2018 at 1:02 PM, Daniel Schwierzeck > wrote: >> Create a new Kconfig menu called 'Standalone programs' with >> 'Program load address' as menu entry. It's possible now to build without >> the standalone example. Anyway the default value for CONFIG_STANDALONE >> is 'y' to maintain the current behavior. >> >> Signed-off-by: Daniel Schwierzeck > > [...] > >> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig >> index 2ba7132c20..e228f15660 100644 >> --- a/arch/xtensa/Kconfig >> +++ b/arch/xtensa/Kconfig >> @@ -8,6 +8,9 @@ config SYS_ARCH >> config SYS_CPU >> string "Xtensa Core Variant" >> >> +config STANDALONE_LOAD_ADDR >> + default 0x0080 >> + > > This doesn't preserve current address assignment for xtensa > XTFPGA boards: > >> --- a/include/configs/xtfpga.h >> +++ b/include/configs/xtfpga.h >> @@ -74,22 +74,6 @@ >> #define CONFIG_SYS_MEMTEST_START MEMADDR(0x0100) >> #define CONFIG_SYS_MEMTEST_END MEMADDR(0x0200) >> >> -/* Load address for stand-alone applications. >> - * MEMADDR cannot be used here, because the definition needs to be >> - * a plain number as it's used as -Ttext argument for ld in standalone >> - * example makefile. >> - * Handle noMMU vs MMUv2 vs MMUv3 distinction here manually. >> - */ >> -#if XCHAL_HAVE_PTP_MMU >> -#if XCHAL_VECBASE_RESET_VADDR == XCHAL_VECBASE_RESET_PADDR >> -#define CONFIG_STANDALONE_LOAD_ADDR0x0080 >> -#else >> -#define CONFIG_STANDALONE_LOAD_ADDR0xd080 >> -#endif >> -#else >> -#define CONFIG_STANDALONE_LOAD_ADDR0x6080 >> -#endif > > OTOH I don't see any way to express this in Kconfig. > I see you set the SYS_CPU string manually. I think this is error-prone and not user-friendly. I suggest to convert this to Kconfig symbols like this: config SYS_CPU default "dc232b" if CPU_DC232B default "dc233c" if CPU_DC233C default "de212" if CPU_DE212 choice prompt "Xtensa Core Variant" default CPU_DC233C config CPU_DC232B bool "dc232b" config CPU_DC233C bool "dc233c" config CPU_DE212 bool "de212" endchoice Then the user can only choose between the three supported cores and SYS_CPU will be automatically updated. The default value for STANDALONE_LOAD_ADDR could be set like this: config STANDALONE_LOAD_ADDR default 0xd080 if CPU_DC232B default 0x0080 if CPU_DC233C default 0x6080 if CPU_DE212 Alternatively you model the MMU configuration also as Kconfig symbol which can be selected by those CPU_* symbols. Then you set the default value of STANDALONE_LOAD_ADDR dependent on that MMU setting. What do you think? -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] U-Boot generates unusable x86_64 EFI binaries
Hello neither the helloworld.efi of qemu-x86_64_defconfig nor the u-boot-payload.efi of efi-x86_payload64_defconfig can be started from the firmware of my Thinkpad 585 while grubx64.efi works fine. Looking at the generated PE header I found the following abnormality: coff.PointerToSymbolTable != 0 coff.NumberOfSymbols != 0 (using https://github.com/xypron/efi_analyzer) According to the Microsoft Portable Executable and Common Object File Format Specification - rev 11 - 2017-01-17 these fields should be 0. The U-Boot executables have these sections which do not exist in grubx64.efi, the EFI shell, and the Windows loader: Section[3] .dynamic Section[4] .dynsym So I think we have to change something in the linking to get usable EFI binaries. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] efi_loader: typedef struct efi_object *efi_handle_t
All our handles point to a struct efi_object. So let's define the
efi_handle_t accordingly. This helps us to discover coding errors much
more easily. This becomes evident by the corrections to the usage of
handles in this patch.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 4 ++--
include/efi.h | 2 +-
include/efi_api.h | 8
lib/efi/efi.c | 2 +-
lib/efi_loader/efi_boottime.c | 18 +-
lib/efi_selftest/efi_selftest_devicepath.c | 2 +-
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 9c51a2cbd1..05eb168e4a 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -447,7 +447,7 @@ static efi_status_t do_bootefi_exec(void *efi,
}
#endif
- ret = efi_do_enter(image_handle, , entry);
+ ret = efi_do_enter(_handle->parent, , entry);
exit:
/* image has returned, loaded-image obj goes *poof*: */
@@ -561,7 +561,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
/* Transfer environment variable efi_selftest as load options */
set_load_options(loaded_image_info, "efi_selftest");
/* Execute the test */
- r = efi_selftest(image_handle, );
+ r = efi_selftest(_handle->parent, );
efi_restore_gd();
free(loaded_image_info->load_options);
efi_delete_handle(_handle->parent);
diff --git a/include/efi.h b/include/efi.h
index b1deb609b4..b5e2c64f38 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -96,7 +96,7 @@ typedef struct {
typedef unsigned long efi_status_t;
typedef u64 efi_physical_addr_t;
typedef u64 efi_virtual_addr_t;
-typedef void *efi_handle_t;
+typedef struct efi_object *efi_handle_t;
#define EFI_GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, \
diff --git a/include/efi_api.h b/include/efi_api.h
index c42df6900a..e6566bb358 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -86,10 +86,10 @@ struct efi_boot_services {
efi_status_t (EFIAPI *check_event)(struct efi_event *event);
#define EFI_NATIVE_INTERFACE 0x
efi_status_t (EFIAPI *install_protocol_interface)(
- void **handle, const efi_guid_t *protocol,
+ efi_handle_t *handle, const efi_guid_t *protocol,
int protocol_interface_type, void *protocol_interface);
efi_status_t (EFIAPI *reinstall_protocol_interface)(
- void *handle, const efi_guid_t *protocol,
+ efi_handle_t handle, const efi_guid_t *protocol,
void *old_interface, void *new_interface);
efi_status_t (EFIAPI *uninstall_protocol_interface)(
efi_handle_t handle, const efi_guid_t *protocol,
@@ -165,9 +165,9 @@ struct efi_boot_services {
efi_status_t (EFIAPI *locate_protocol)(const efi_guid_t *protocol,
void *registration, void **protocol_interface);
efi_status_t (EFIAPI *install_multiple_protocol_interfaces)(
- void **handle, ...);
+ efi_handle_t *handle, ...);
efi_status_t (EFIAPI *uninstall_multiple_protocol_interfaces)(
- void *handle, ...);
+ efi_handle_t handle, ...);
efi_status_t (EFIAPI *calculate_crc32)(const void *data,
efi_uintn_t data_size,
u32 *crc32);
diff --git a/lib/efi/efi.c b/lib/efi/efi.c
index c6639f96cc..2c6a50824f 100644
--- a/lib/efi/efi.c
+++ b/lib/efi/efi.c
@@ -69,7 +69,7 @@ int efi_init(struct efi_priv *priv, const char *banner,
efi_handle_t image,
efi_putc(priv, ' ');
ret = boot->open_protocol(priv->parent_image, _image_guid,
- (void **)_image, >parent_image,
+ (void **)_image, priv->parent_image,
NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
if (ret) {
efi_puts(priv, "Failed to get loaded image protocol\n");
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 3bb7b70e08..20974f98f6 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1019,7 +1019,7 @@ efi_status_t efi_add_protocol(const efi_handle_t handle,
* Return: status code
*/
static efi_status_t EFIAPI efi_install_protocol_interface(
- void **handle, const efi_guid_t *protocol,
+ efi_handle_t *handle, const efi_guid_t *protocol,
int protocol_interface_type, void *protocol_interface)
{
efi_status_t r;
@@ -2279,8 +2279,8 @@ out:
*
* Return: status code
[U-Boot] [PATCH 0/2] efi_loader: eliminate handle member
Up to now we have treated handles as separate objects to EFI objects. This confusion has lead to hidden bugs like those corrected by the first patch. By changing the efi_handle_t typedef we can avoid this problem in future. As handles are pointers to EFI objects there is no need for a handle member in struct efi_object. This allows to simplify our coding. Heinrich Schuchardt (2): efi_loader: typedef struct efi_object *efi_handle_t efi_loader: eliminate handle member cmd/bootefi.c | 4 +- include/efi.h | 2 +- include/efi_api.h | 8 +-- include/efi_loader.h | 26 +--- lib/efi/efi.c | 2 +- lib/efi_loader/efi_boottime.c | 77 +++--- lib/efi_loader/efi_console.c | 20 +++--- lib/efi_loader/efi_device_path.c | 2 +- lib/efi_loader/efi_disk.c | 8 +-- lib/efi_loader/efi_gop.c | 2 +- lib/efi_loader/efi_net.c | 6 +- lib/efi_selftest/efi_selftest_devicepath.c | 2 +- 12 files changed, 83 insertions(+), 76 deletions(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] efi_loader: eliminate handle member
A pointer to a struct efi_object is a handle. We do not need any handle
member in this structure. Let's eliminate it.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 26 +-
lib/efi_loader/efi_boottime.c| 59
lib/efi_loader/efi_console.c | 20 +--
lib/efi_loader/efi_device_path.c | 2 +-
lib/efi_loader/efi_disk.c| 8 ++---
lib/efi_loader/efi_gop.c | 2 +-
lib/efi_loader/efi_net.c | 6 ++--
7 files changed, 65 insertions(+), 58 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 74df070316..6846bb03f3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -173,20 +173,28 @@ struct efi_handler {
struct list_head open_infos;
};
-/*
- * UEFI has a poor man's OO model where one "object" can be polymorphic and
have
- * multiple different protocols (classes) attached to it.
+/**
+ * struct efi_object - dereferenced EFI handle
+ *
+ * @link: pointers to put the handle into a linked list
+ * @protocols: linked list with the protocol interfaces installed on this
+ * handle
+ *
+ * UEFI offers a flexible and expandable object model. The objects in the UEFI
+ * API are devices, drivers, and loaded images. struct efi_object is our
storage
+ * structure for these objects.
+ *
+ * When including this structure into a larger structure always put it first so
+ * that when deleting a handle the whole encompassing structure can be freed.
*
- * This struct is the parent struct for all of our actual implementation
objects
- * that can include it to make themselves an EFI object
+ * A pointer to this structure is referred to as a handle. Typedef efi_handle_t
+ * has been created for such pointers.
*/
struct efi_object {
/* Every UEFI object is part of a global object list */
struct list_head link;
/* The list of protocols */
struct list_head protocols;
- /* The object spawner can either use this for data or as identifier */
- void *handle;
};
/**
@@ -296,11 +304,11 @@ void efi_runtime_relocate(ulong offset, struct
efi_mem_desc *map);
/* Call this to set the current device name */
void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
/* Add a new object to the object list. */
-void efi_add_handle(struct efi_object *obj);
+void efi_add_handle(efi_handle_t obj);
/* Create handle */
efi_status_t efi_create_handle(efi_handle_t *handle);
/* Delete handle */
-void efi_delete_handle(struct efi_object *obj);
+void efi_delete_handle(efi_handle_t obj);
/* Call this to validate a handle and find the EFI object for it */
struct efi_object *efi_search_obj(const efi_handle_t handle);
/* Find a protocol on a handle */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 20974f98f6..d1c4b26297 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -416,13 +416,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
*
* The protocols list is initialized. The object handle is set.
*/
-void efi_add_handle(struct efi_object *obj)
+void efi_add_handle(efi_handle_t handle)
{
- if (!obj)
+ if (!handle)
return;
- INIT_LIST_HEAD(>protocols);
- obj->handle = obj;
- list_add_tail(>link, _obj_list);
+ INIT_LIST_HEAD(>protocols);
+ list_add_tail(>link, _obj_list);
}
/**
@@ -440,7 +439,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle)
return EFI_OUT_OF_RESOURCES;
efi_add_handle(obj);
- *handle = obj->handle;
+ *handle = obj;
return EFI_SUCCESS;
}
@@ -536,13 +535,13 @@ efi_status_t efi_remove_all_protocols(const efi_handle_t
handle)
*
* @obj: handle to delete
*/
-void efi_delete_handle(struct efi_object *obj)
+void efi_delete_handle(efi_handle_t handle)
{
- if (!obj)
+ if (!handle)
return;
- efi_remove_all_protocols(obj->handle);
- list_del(>link);
- free(obj);
+ efi_remove_all_protocols(handle);
+ list_del(>link);
+ free(handle);
}
/**
@@ -927,7 +926,7 @@ struct efi_object *efi_search_obj(const efi_handle_t handle)
struct efi_object *efiobj;
list_for_each_entry(efiobj, _obj_list, link) {
- if (efiobj->handle == handle)
+ if (efiobj == handle)
return efiobj;
}
@@ -1052,7 +1051,7 @@ out:
/**
* efi_get_drivers() - get all drivers associated to a controller
- * @efiobj: handle of the controller
+ * @handle: handle of the controller
* @protocol: protocol GUID (optional)
* @number_of_drivers:number of child controllers
* @driver_handle_buffer: handles of the the drivers
@@ -1061,7 +1060,7 @@ out:
*
* Return: status code
*/
-static efi_status_t efi_get_drivers(struct efi_object *efiobj,
+static
Re: [U-Boot] [PATCH] efi_loader: Disable efi selftest on sandbox for now
On 23 September 2018 at 07:24, Alexander Graf wrote: > > The EFI selftest does not succeed on Sandbox yet. The network support > seems to need some love to actually make our current tests succeed. > > So let's disable running the selftest on sandbox for now until "make > tests" just works. Then we can have more amazing CI than ever. > > Signed-off-by: Alexander Graf > --- > lib/efi_selftest/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: UninstallMultipleProtocolInterfaces error code
If UninstallMultipleProtocolInterfaces fails, we sometimes return the wrong
status code. The UEFI spec mandates to always return EFI_INVALID_PARAMETER.
Update unit test.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_boottime.c | 3 ++-
.../efi_selftest_manageprotocols.c | 18 +++---
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index ac724b17fd..554997f44a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2409,7 +2409,8 @@ static efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(
}
efi_va_end(argptr);
- return EFI_EXIT(r);
+ /* In case of an error always return EFI_INVALID_PARAMETER */
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
}
/**
diff --git a/lib/efi_selftest/efi_selftest_manageprotocols.c
b/lib/efi_selftest/efi_selftest_manageprotocols.c
index b09e4cdcfa..0ff35cec8a 100644
--- a/lib/efi_selftest/efi_selftest_manageprotocols.c
+++ b/lib/efi_selftest/efi_selftest_manageprotocols.c
@@ -189,7 +189,14 @@ static int execute(void)
/*
* Test error handling in UninstallMultipleProtocols
*
-* Try to uninstall more protocols than there are installed.
+* These are the installed protocol interfaces on handle 2:
+*
+* guid1 interface4
+* guid2 interface2
+*
+* Try to uninstall more protocols than there are installed. This
+* should return an error EFI_INVALID_PARAMETER. All deleted protocols
+* should be reinstalled.
*/
ret = boottime->uninstall_multiple_protocol_interfaces(
handle2,
@@ -197,13 +204,18 @@ static int execute(void)
, ,
, ,
NULL);
- if (ret == EFI_SUCCESS) {
+ if (ret != EFI_INVALID_PARAMETER) {
+ printf("%lx", ret);
efi_st_error("UninstallMultipleProtocolInterfaces did not catch
error\n");
return EFI_ST_FAILURE;
}
/*
* Test LocateHandleBuffer with ByProtocol
+*
+* These are the handles with a guid1 protocol interface installed:
+*
+* handle1, handle2
*/
count = buffer_size;
ret = boottime->locate_handle_buffer(BY_PROTOCOL, , NULL,
@@ -213,7 +225,7 @@ static int execute(void)
return EFI_ST_FAILURE;
}
if (count != 2) {
- efi_st_error("LocateHandleBuffer failed to locate new
handles\n");
+ efi_st_error("UninstallMultipleProtocolInterfaces deleted
handle\n");
return EFI_ST_FAILURE;
}
ret = find_in_buffer(handle1, count, buffer);
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Kconfig: move CONFIG_STANDALONE_LOAD_ADDR to Kconfig
On Sun, Sep 23, 2018 at 1:02 PM, Daniel Schwierzeck wrote: > Create a new Kconfig menu called 'Standalone programs' with > 'Program load address' as menu entry. It's possible now to build without > the standalone example. Anyway the default value for CONFIG_STANDALONE > is 'y' to maintain the current behavior. > > Signed-off-by: Daniel Schwierzeck [...] > diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig > index 2ba7132c20..e228f15660 100644 > --- a/arch/xtensa/Kconfig > +++ b/arch/xtensa/Kconfig > @@ -8,6 +8,9 @@ config SYS_ARCH > config SYS_CPU > string "Xtensa Core Variant" > > +config STANDALONE_LOAD_ADDR > + default 0x0080 > + This doesn't preserve current address assignment for xtensa XTFPGA boards: > --- a/include/configs/xtfpga.h > +++ b/include/configs/xtfpga.h > @@ -74,22 +74,6 @@ > #define CONFIG_SYS_MEMTEST_START MEMADDR(0x0100) > #define CONFIG_SYS_MEMTEST_END MEMADDR(0x0200) > > -/* Load address for stand-alone applications. > - * MEMADDR cannot be used here, because the definition needs to be > - * a plain number as it's used as -Ttext argument for ld in standalone > - * example makefile. > - * Handle noMMU vs MMUv2 vs MMUv3 distinction here manually. > - */ > -#if XCHAL_HAVE_PTP_MMU > -#if XCHAL_VECBASE_RESET_VADDR == XCHAL_VECBASE_RESET_PADDR > -#define CONFIG_STANDALONE_LOAD_ADDR0x0080 > -#else > -#define CONFIG_STANDALONE_LOAD_ADDR0xd080 > -#endif > -#else > -#define CONFIG_STANDALONE_LOAD_ADDR0x6080 > -#endif OTOH I don't see any way to express this in Kconfig. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/15] test/py: Fix unicode handling for log filtering
On 09/23/2018 04:47 PM, Simon Glass wrote: At present the unicode filtering seems to get confused at times with this error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 32: ordinal not in range(128) It seems to be due to self._nonprint being interpreted as UTF-8. Fix it by using ordinals instead of characters, changing the string to set. Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] [RESEND] Improvements for the dwc3_generic driver
On 21/09/2018 15:02, Jean-Jacques Hiblot wrote: On 21/09/2018 12:43, Lukasz Majewski wrote: Hi Jean-Jacques, On 21/09/2018 11:24, Lukasz Majewski wrote: Hi Jean-Jacques, On 21/09/2018 10:50, Lukasz Majewski wrote: Hi Jean-Jacques, Hi Marek, I haven't heard of you on this series. It is already a resend and has been tested on 2 platforms (zcu100 and dra7/am57). Can you please consider it for inclusion? This is not Marek to blame for the delay - I had some non open source tasks to finish (and I do apologise for this situation). Thanks. I am not blaming anyone. :-) Could you check the build result? https://travis-ci.org/lmajewski/u-boot-dfu/builds/431388980 I do see some issues with "Freescale ARM32/ARM64". I can reproduce the problem. The root cause is that I moved the phy handling operation from the host (xhci-dwc3.c) to the core dwc3/core.c thinking that all users of the dwc3 would have the core code. Well that is not the case. Maybe a silly question - how those boards work as they do not use/include the DWC3 core? It looks like the host side of the dwc3 is mostly self-contained and that the code in dwc3/core.c is mostly used by the gadget side. It seems that the PHY code is not used by the platforms that failed to build, so it can be compiled out. I'll send a v3 shortly. JJ They use xhci PHY handling code and what code on top? I see 2 solutions: * move the phy code back to xhci-dwc3 * enable the core code for dwc3 (CONFIG_USB_DWC3) for the failing platforms Any preference ? I just wanted to make sure that this wasn't lost in limbo. Your patches are now under build testing on travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu/builds/431388980 I will send the PR after CI finish. Thanks, JJ On 04/09/2018 15:42, Jean-Jacques Hiblot wrote: Resending this series after rebasing on top of latest u-boot. This series aims at bringing improvements to the dwc3_generic driver so that it can be used by most of the platforms using the dwc3 controller. I tested this on with DRA7 and AM57x platforms for both Peripheral and Host operations. The code to enable DM USB host & dev support for those platforms will be submitted in a separate series. Michal Simek has tested this series: " I have tested it on zcu100 with usb stick, usb to ethernet converter and also dfu. Tested-by: Michal Simek " Enhancements: - use separate Kconfig option for DM USB Periphal and DM USB Host. This allow platforms to keep their non-DM USB peripheral code and use the DM USB host. - fixes the bind/probe confusion in dwc3_generic. The probe is done when the USB device is first needed. - handles PHYs when in the peripheral mode. The code to handle the PHYs is shared with the host side - handles clock and reset - bind host controller to the more generic driver 'xhci-dwc3' Changes in v2: - Updated commit log - Fixed typo in thordown.c - select DM_USB_DEV by default for zynqmp platforms Jean-Jacques Hiblot (7): usb: gadget: Do not call board_usb_xxx() directly in USB gadget drivers usb: introduce a separate config option for DM USB device usb: udc: implement DM versions of usb_gadget_initialize()/_release()/_handle_interrupt() dwc3_generic: do not probe the USB device driver when it's bound dwc3: move phy operation to core.c dwc3-generic: Handle the PHYs, the clocks and the reset lines dwc3-generic: Add select_dr_mode operation arch/arm/Kconfig | 2 + cmd/fastboot.c | 4 +- cmd/rockusb.c | 4 +- cmd/thordown.c | 4 +- cmd/usb_gadget_sdp.c | 4 +- cmd/usb_mass_storage.c | 4 +- common/dfu.c | 6 +- drivers/usb/Kconfig | 6 ++ drivers/usb/dwc3/Kconfig | 7 +- drivers/usb/dwc3/core.c | 86 +++- drivers/usb/dwc3/dwc3-generic.c | 207 +- drivers/usb/dwc3/ep0.c | 1 - drivers/usb/gadget/ether.c | 38 +-- drivers/usb/gadget/udc/udc-core.c | 44 +++- drivers/usb/host/xhci-dwc3.c | 93 ++--- include/dwc3-uboot.h | 7 ++ include/linux/usb/gadget.h | 18 17 files changed, 351 insertions(+), 184 deletions(-) Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5,
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
Hi
On Mon., 24 Sep. 2018, 5:15 pm Stefan Agner, wrote:
> On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, wrote:
> >
> >> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> >>> Hi
> >>>
> >>> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner,
> >> wrote:
> >>>
> On 13.08.2018 09:30, Gerard Salvatella wrote:
> > Some boards require specific configuration prior to booting the
> kernel.
> > For instance, our boards require shutting down the display to
> avoid
> > fading transitions before the drivers are reloaded by the
> >> kernel.
> This
> > could be facilitated by adding an extra hook during the os
> >> booting
> > process.
>
> Maybe I can extend on what we are trying to achieve here:
>
> We enable display backlight using board code.
> >>>
> >>> You can make it works almost easily.
> >>>
> >>> I enable simple fb, inject allocated display parameters in dts to
> >>> reserve area, pass the area to the graphics controller and dismiss
> >> it
> >>> during probing
> >>>
> >>> This is mainline in linux support.
> >>>
> >>> I have couple of patches need to clean up for imx architecture
> >>> (imx6ull and imx25)
> >>
> >> Definitely interested in those patches! Of course using this
> >> approach
> >> leads to the most seamless booting experience.
> >
> > Yes but there are a lot of reason to have when you deal multi-image
> > update and so on.
> >
> >> But as far as I know it also needs proper (driver specific) Linux
> >> support, is that correct?
> >
> > No that is wrong. imx6ull need a small patches right now I have
> > applied in kernel in legacy driver and not in drm one.
> >
>
> In what way is that different to what I wrote above?
>
> In the end, the OS needs support for this.
>
I said that Linux support but not all the specic SoC. I don't against the
proposal but on my side I think that create some label and some way to
register them and go through a list instead of continue create weak make
more sense
> > sunxi already implement everything in their side
> >
> >> So, I think its anyway worth having an option to properly disable
> >> the
> >> display and backlight for older kernels/non-Linux OS.
> >
> > gpio clear gpio-6 ; bootm ?
>
> That is very board specific scripting required. We enable the backlight
> in code, so we should disable it, especially if we disable the
> controller (which we do currently).
>
Your function is board specific anyway but ok I understand the asymmetric
situation. I suggest it before migrate to the latest solution
Michael
>
> --
> Stefan
>
> >
> > Michael
> >
> >> --
> >> Stefan
> >>
> >>>
> >>> You can still scripting it using cmd interface
> >>>
> >>> Michael
> >>>
> The architecture code then shuts down the display controller just
> before
> booting Linux (e.g. on i.MX, by calling
> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
>
> This leads to a display which has backlight enabled, but no data
> driven... Depending on display this leads to noisy/fading
> transitions
> between U-Boot and Linux.
>
> So we would like to disable the backlight in board code.
>
> In a first version we used a weak display_shutdown() function,
> >> but
> with
> that we would have to add it to every architecture.
>
> This approach uses a generic board specific preeboot_os callback
> which
> can be used for different purpose too.
>
> Does this sound like an approach which is acceptable upstream?
>
> --
> Stefan
>
> >
> > Signed-off-by: Gerard Salvatella
> > ---
> > common/bootm_os.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/common/bootm_os.c b/common/bootm_os.c
> > index f4bd905909..1e7af56b64 100644
> > --- a/common/bootm_os.c
> > +++ b/common/bootm_os.c
> > @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> > /* please define platform specific arch_preboot_os() */
> > }
> >
> > +/* Allow for board specific config before we boot */
> > +__weak void board_preboot_os(void)
> > +{
> > + /* please define board specific board_preboot_os() */
> > +}
> > +
> > int boot_selected_os(int argc, char * const argv[], int state,
> > bootm_headers_t *images, boot_os_fn *boot_fn)
> > {
> > + board_preboot_os();
> > arch_preboot_os();
> > boot_fn(state, argc, argv, images);
> >
> > --
> > 2.18.0
> >
> >
> > [Toradex Logo] Global Leader in Arm®
> > Embedded Computer Modules
> >
> > Choose
> >
>
> >>>
> >>
> > Us<
> https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
> > | Products | Developer
> > Center
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
On 24.09.2018 16:56, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, wrote:
>
>> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
>>> Hi
>>>
>>> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner,
>> wrote:
>>>
On 13.08.2018 09:30, Gerard Salvatella wrote:
> Some boards require specific configuration prior to booting the
kernel.
> For instance, our boards require shutting down the display to
avoid
> fading transitions before the drivers are reloaded by the
>> kernel.
This
> could be facilitated by adding an extra hook during the os
>> booting
> process.
Maybe I can extend on what we are trying to achieve here:
We enable display backlight using board code.
>>>
>>> You can make it works almost easily.
>>>
>>> I enable simple fb, inject allocated display parameters in dts to
>>> reserve area, pass the area to the graphics controller and dismiss
>> it
>>> during probing
>>>
>>> This is mainline in linux support.
>>>
>>> I have couple of patches need to clean up for imx architecture
>>> (imx6ull and imx25)
>>
>> Definitely interested in those patches! Of course using this
>> approach
>> leads to the most seamless booting experience.
>
> Yes but there are a lot of reason to have when you deal multi-image
> update and so on.
>
>> But as far as I know it also needs proper (driver specific) Linux
>> support, is that correct?
>
> No that is wrong. imx6ull need a small patches right now I have
> applied in kernel in legacy driver and not in drm one.
>
In what way is that different to what I wrote above?
In the end, the OS needs support for this.
> sunxi already implement everything in their side
>
>> So, I think its anyway worth having an option to properly disable
>> the
>> display and backlight for older kernels/non-Linux OS.
>
> gpio clear gpio-6 ; bootm ?
That is very board specific scripting required. We enable the backlight
in code, so we should disable it, especially if we disable the
controller (which we do currently).
--
Stefan
>
> Michael
>
>> --
>> Stefan
>>
>>>
>>> You can still scripting it using cmd interface
>>>
>>> Michael
>>>
The architecture code then shuts down the display controller just
before
booting Linux (e.g. on i.MX, by calling
ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
This leads to a display which has backlight enabled, but no data
driven... Depending on display this leads to noisy/fading
transitions
between U-Boot and Linux.
So we would like to disable the backlight in board code.
In a first version we used a weak display_shutdown() function,
>> but
with
that we would have to add it to every architecture.
This approach uses a generic board specific preeboot_os callback
which
can be used for different purpose too.
Does this sound like an approach which is acceptable upstream?
--
Stefan
>
> Signed-off-by: Gerard Salvatella
> ---
> common/bootm_os.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/common/bootm_os.c b/common/bootm_os.c
> index f4bd905909..1e7af56b64 100644
> --- a/common/bootm_os.c
> +++ b/common/bootm_os.c
> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> /* please define platform specific arch_preboot_os() */
> }
>
> +/* Allow for board specific config before we boot */
> +__weak void board_preboot_os(void)
> +{
> + /* please define board specific board_preboot_os() */
> +}
> +
> int boot_selected_os(int argc, char * const argv[], int state,
> bootm_headers_t *images, boot_os_fn *boot_fn)
> {
> + board_preboot_os();
> arch_preboot_os();
> boot_fn(state, argc, argv, images);
>
> --
> 2.18.0
>
>
> [Toradex Logo] Global Leader in Arm®
> Embedded Computer Modules
>
> Choose
>
>>>
>>
> Us
> | Products | Developer
> Center |
> Careers:
> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> - NXP Technology Days 2018, United States, Aug 28, 2018
> - IoT Latin America, Brazil, Aug 29-30, 2018
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
[U-Boot] [PATCH v2] misc: Add support for the Arm Versatile Express config bus
Add support for the Arm Versatile Express config bus that is
being used for exposing various subsystems via a generic
configuration bus. This driver adds support for generating
transactions on this configuration bus and can be used by
other drivers to abstract the communication with the actual
function providers.
Signed-off-by: Liviu Dudau
---
Changelog:
- v2: removed #define DEBUG line leftover
drivers/misc/Kconfig | 8 +++
drivers/misc/Makefile | 1 +
drivers/misc/vexpress_config.c | 126 +
3 files changed, 136 insertions(+)
create mode 100644 drivers/misc/vexpress_config.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c2b7cc15db..468a5682e3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -41,6 +41,14 @@ config ROCKCHIP_EFUSE
extended (by porting the read function from the Linux kernel sources)
to support other recent Rockchip devices.
+config VEXPRESS_CONFIG
+ bool "Enable support for Arm Versatile Express config bus"
+ depends on MISC
+ help
+ If you say Y here, you will get support for accessing the
+ configuration bus on the Arm Versatile Express boards via
+ a sysreg driver.
+
config CMD_CROS_EC
bool "Enable crosec command"
depends on CROS_EC
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 32ef4a53c7..6d3418efc7 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
obj-$(CONFIG_GDSYS_IOEP) += gdsys_ioep.o
obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress_config.o
diff --git a/drivers/misc/vexpress_config.c b/drivers/misc/vexpress_config.c
new file mode 100644
index 00..2cd433d01e
--- /dev/null
+++ b/drivers/misc/vexpress_config.c
@@ -0,1 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Arm Ltd
+ * Author: Liviu Dudau
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SYS_CFGDATA0xa0
+
+#define SYS_CFGCTRL0xa4
+#define SYS_CFGCTRL_START BIT(31)
+#define SYS_CFGCTRL_WRITE BIT(30)
+
+#define SYS_CFGSTAT0xa8
+#define SYS_CFGSTAT_ERRBIT(1)
+#define SYS_CFGSTAT_COMPLETE BIT(0)
+
+struct vexpress_config_sysreg {
+ phys_addr_t addr;
+ u32 site;
+};
+
+static int vexpress_config_exec(struct vexpress_config_sysreg *syscfg,
+ bool write, void *buf, int size)
+{
+ u32 cmd, status, tries = 100;
+
+ cmd = (*(u32 *)buf) | SYS_CFGCTRL_START | (syscfg->site << 16);
+
+ if (!write) {
+ /* write a canary in the data register for reads */
+ writel(0xdeadbeef, syscfg->addr + SYS_CFGDATA);
+ } else {
+ cmd |= SYS_CFGCTRL_WRITE;
+ writel(((u32 *)buf)[1], syscfg->addr + SYS_CFGDATA);
+ }
+ writel(0, syscfg->addr + SYS_CFGSTAT);
+ writel(cmd, syscfg->addr + SYS_CFGCTRL);
+
+ /* completion of command takes ages, go to sleep (150us) */
+ do {
+ udelay(150);
+ status = readl(syscfg->addr + SYS_CFGSTAT);
+ if (status & SYS_CFGSTAT_ERR)
+ return -EFAULT;
+ } while (--tries && !(status & SYS_CFGSTAT_COMPLETE));
+
+ if (!tries)
+ return -ETIMEDOUT;
+
+ if (!write)
+ (*(u32 *)buf) = readl(syscfg->addr + SYS_CFGDATA);
+
+ return 0;
+}
+
+static int vexpress_config_read(struct udevice *dev, int offset, void *buf,
int size)
+{
+ struct vexpress_config_sysreg *priv = dev_get_uclass_priv(dev);
+
+ if (size != sizeof(u32))
+ return -EINVAL;
+
+ return vexpress_config_exec(priv, false, buf, size);
+}
+
+static int vexpress_config_write(struct udevice *dev, int offset, const void
*buf, int size)
+{
+ struct vexpress_config_sysreg *priv = dev_get_uclass_priv(dev);
+
+ if (size != sizeof(u32) * 2)
+ return -EINVAL;
+
+ return vexpress_config_exec(priv, true, (void *)buf, size);
+}
+
+static struct misc_ops vexpress_config_ops = {
+ .read = vexpress_config_read,
+ .write = vexpress_config_write,
+};
+
+static int vexpress_config_probe(struct udevice *dev)
+{
+ struct ofnode_phandle_args args;
+ struct vexpress_config_sysreg *priv;
+ const char *prop;
+ int err, prop_size;
+
+ err = dev_read_phandle_with_args(dev, "arm,vexpress,config-bridge",
+NULL, 0, 0, );
+ if (err)
+ return err;
+
+ prop = ofnode_get_property(args.node, "compatible", _size);
+ if (!prop || (strncmp(prop, "arm,vexpress-sysreg", 19) != 0))
+ return -ENOENT;
+
+ priv = calloc(1, sizeof(*priv));
+ if (!priv)
+
Re: [U-Boot] [PATCH v8 8/8] Enable CONFIG_BLK and CONFIG_DM_MMC to Kconfig
On 08/27/2018 07:56 PM, Yinbo Zhu wrote: > This enables the folowing to Kconfig: > CONFIG_BLK > CONFIG_DM_MMC > > Signed-off-by: Yinbo Zhu > --- > configs/ls1021atwr_nor_SECURE_BOOT_defconfig |2 ++ > configs/ls1021atwr_nor_defconfig |2 ++ > configs/ls1021atwr_nor_lpuart_defconfig|2 ++ > configs/ls1021atwr_qspi_defconfig |2 ++ > .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig|2 ++ ls1021atwr_sdcard_ifc_SECURE_BOOT has a compiling errors. I think it is in building SPL. Please test and fix. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/master
On Sun, Sep 23, 2018 at 06:58:25PM +0200, Daniel Schwierzeck wrote: > Hi Tom, > > Travis-CI: https://travis-ci.org/danielschwierzeck/u-boot/builds/432133437 > > > The following changes since commit 9dc8d155d4e88563f572ee79aab758eb4272f3fd: > > Merge git://git.denx.de/u-boot-imx (2018-09-19 20:35:27 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-mips.git master > > for you to fetch changes up to fdd1a9ff781cda82696f8971e540e475fd1e9933: > > mips: mt7628a.dtsi: Add SPI clock-frequency property (2018-09-23 14:27:51 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
Hi
On Mon., 24 Sep. 2018, 4:51 pm Stefan Agner, wrote:
> On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, wrote:
> >
> >> On 13.08.2018 09:30, Gerard Salvatella wrote:
> >>> Some boards require specific configuration prior to booting the
> >> kernel.
> >>> For instance, our boards require shutting down the display to
> >> avoid
> >>> fading transitions before the drivers are reloaded by the kernel.
> >> This
> >>> could be facilitated by adding an extra hook during the os booting
> >>> process.
> >>
> >> Maybe I can extend on what we are trying to achieve here:
> >>
> >> We enable display backlight using board code.
> >
> > You can make it works almost easily.
> >
> > I enable simple fb, inject allocated display parameters in dts to
> > reserve area, pass the area to the graphics controller and dismiss it
> > during probing
> >
> > This is mainline in linux support.
> >
> > I have couple of patches need to clean up for imx architecture
> > (imx6ull and imx25)
>
> Definitely interested in those patches! Of course using this approach
> leads to the most seamless booting experience.
>
Yes but there are a lot of reason to have when you deal multi-image update
and so on.
> But as far as I know it also needs proper (driver specific) Linux
> support, is that correct?
>
No that is wrong. imx6ull need a small patches right now I have applied in
kernel in legacy driver and not in drm one.
sunxi already implement everything in their side
> So, I think its anyway worth having an option to properly disable the
> display and backlight for older kernels/non-Linux OS.
>
gpio clear gpio-6 ; bootm ?
Michael
>
> --
> Stefan
>
> >
> > You can still scripting it using cmd interface
> >
> > Michael
> >
> >> The architecture code then shuts down the display controller just
> >> before
> >> booting Linux (e.g. on i.MX, by calling
> >> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
> >>
> >> This leads to a display which has backlight enabled, but no data
> >> driven... Depending on display this leads to noisy/fading
> >> transitions
> >> between U-Boot and Linux.
> >>
> >> So we would like to disable the backlight in board code.
> >>
> >> In a first version we used a weak display_shutdown() function, but
> >> with
> >> that we would have to add it to every architecture.
> >>
> >> This approach uses a generic board specific preeboot_os callback
> >> which
> >> can be used for different purpose too.
> >>
> >> Does this sound like an approach which is acceptable upstream?
> >>
> >> --
> >> Stefan
> >>
> >>>
> >>> Signed-off-by: Gerard Salvatella
> >>> ---
> >>> common/bootm_os.c | 7 +++
> >>> 1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/common/bootm_os.c b/common/bootm_os.c
> >>> index f4bd905909..1e7af56b64 100644
> >>> --- a/common/bootm_os.c
> >>> +++ b/common/bootm_os.c
> >>> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> >>> /* please define platform specific arch_preboot_os() */
> >>> }
> >>>
> >>> +/* Allow for board specific config before we boot */
> >>> +__weak void board_preboot_os(void)
> >>> +{
> >>> + /* please define board specific board_preboot_os() */
> >>> +}
> >>> +
> >>> int boot_selected_os(int argc, char * const argv[], int state,
> >>> bootm_headers_t *images, boot_os_fn *boot_fn)
> >>> {
> >>> + board_preboot_os();
> >>> arch_preboot_os();
> >>> boot_fn(state, argc, argv, images);
> >>>
> >>> --
> >>> 2.18.0
> >>>
> >>>
> >>> [Toradex Logo] Global Leader in Arm®
> >>> Embedded Computer Modules
> >>>
> >>> Choose
> >>>
> >>
> > Us<
> https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
> >>> | Products | Developer
> >>> Center |
> >>> Careers:
> >>> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> >>> - NXP Technology Days 2018, United States, Aug 28, 2018
> >>> - IoT Latin America, Brazil, Aug 29-30, 2018
> >>>
> >>>
> >>>
> >>> ___
> >>> U-Boot mailing list
> >>> U-Boot@lists.denx.de
> >>> https://lists.denx.de/listinfo/u-boot
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb board.
On 09/24/2018 02:29 AM, Pramod Kumar wrote:
>
>
>> -Original Message-
>> From: York Sun
>> Sent: Friday, September 21, 2018 8:20 PM
>> To: Pramod Kumar
>> Cc: u-boot@lists.denx.de
>> Subject: Re: [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb
>> board.
>>
>> On 08/21/2018 02:18 AM, Pramod Kumar wrote:
>>> ls1088ardb-pb is another varinat of the ls1088ardb.
>>> This board support two m.2 x2 gen 3 pcie card slot.
>>> There is no support of sata, pcie standard slot, miniPCIE slot and TDM
>>> in this board.
>>>
>>> Signed-off-by: Pramod Kumar
>>> ---
>>> Changes in v2:
>>> - Fix the compilation issue when building u-boot for SD boot.
>>>
>>> arch/arm/Kconfig | 14 +++
>>> arch/arm/cpu/armv8/Kconfig| 1 +
>>> board/freescale/ls1088a/Kconfig | 43 +++
>>> board/freescale/ls1088a/MAINTAINERS | 18 +++
>>> board/freescale/ls1088a/Makefile | 1 +
>>> board/freescale/ls1088a/ddr.h | 6 +-
>>> board/freescale/ls1088a/ls1088a.c | 25 +++-
>>> ... ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} | 2 +-
>>> ...defconfig => ls1088ardb_pb_qspi_defconfig} | 2 +-
>>> ...ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} | 2 +-
>>> ...ig => ls1088ardb_pb_sdcard_qspi_defconfig} | 2 +-
>>> include/configs/ls1088ardb_pb.h | 113 ++
>>> 12 files changed, 219 insertions(+), 10 deletions(-) copy
>>> configs/{ls1088ardb_qspi_SECURE_BOOT_defconfig =>
>>> ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} (97%) copy
>>> configs/{ls1088ardb_qspi_defconfig => ls1088ardb_pb_qspi_defconfig}
>>> (97%) copy configs/{ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig =>
>>> ls1088ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} (98%) copy
>>> configs/{ls1088ardb_sdcard_qspi_defconfig =>
>>> ls1088ardb_pb_sdcard_qspi_defconfig} (98%) create mode 100644
>>> include/configs/ls1088ardb_pb.h
>>>
>>
>> Is it possible to reuse ls1088ardb and detect the board at runtime?
>>>
>>> For distro boot we need diffrent board variable for ls1088ardb and
>>> ls1088ardb_pb, which can only be
>>> achieved by using config tagets CONFIG_TARGET_LS1088ARDB and
>>> CONFIG_TARGET_LS1088ARDB_PB respectively
> f>> or both the boards.
First, please use proper prefix for quotation and reply. It makes
reading easier.
If your only concern is default variable for distroboot, you can update
the default variable at runtime.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
On 24.09.2018 16:43, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, wrote:
>
>> On 13.08.2018 09:30, Gerard Salvatella wrote:
>>> Some boards require specific configuration prior to booting the
>> kernel.
>>> For instance, our boards require shutting down the display to
>> avoid
>>> fading transitions before the drivers are reloaded by the kernel.
>> This
>>> could be facilitated by adding an extra hook during the os booting
>>> process.
>>
>> Maybe I can extend on what we are trying to achieve here:
>>
>> We enable display backlight using board code.
>
> You can make it works almost easily.
>
> I enable simple fb, inject allocated display parameters in dts to
> reserve area, pass the area to the graphics controller and dismiss it
> during probing
>
> This is mainline in linux support.
>
> I have couple of patches need to clean up for imx architecture
> (imx6ull and imx25)
Definitely interested in those patches! Of course using this approach
leads to the most seamless booting experience.
But as far as I know it also needs proper (driver specific) Linux
support, is that correct?
So, I think its anyway worth having an option to properly disable the
display and backlight for older kernels/non-Linux OS.
--
Stefan
>
> You can still scripting it using cmd interface
>
> Michael
>
>> The architecture code then shuts down the display controller just
>> before
>> booting Linux (e.g. on i.MX, by calling
>> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
>>
>> This leads to a display which has backlight enabled, but no data
>> driven... Depending on display this leads to noisy/fading
>> transitions
>> between U-Boot and Linux.
>>
>> So we would like to disable the backlight in board code.
>>
>> In a first version we used a weak display_shutdown() function, but
>> with
>> that we would have to add it to every architecture.
>>
>> This approach uses a generic board specific preeboot_os callback
>> which
>> can be used for different purpose too.
>>
>> Does this sound like an approach which is acceptable upstream?
>>
>> --
>> Stefan
>>
>>>
>>> Signed-off-by: Gerard Salvatella
>>> ---
>>> common/bootm_os.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/common/bootm_os.c b/common/bootm_os.c
>>> index f4bd905909..1e7af56b64 100644
>>> --- a/common/bootm_os.c
>>> +++ b/common/bootm_os.c
>>> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
>>> /* please define platform specific arch_preboot_os() */
>>> }
>>>
>>> +/* Allow for board specific config before we boot */
>>> +__weak void board_preboot_os(void)
>>> +{
>>> + /* please define board specific board_preboot_os() */
>>> +}
>>> +
>>> int boot_selected_os(int argc, char * const argv[], int state,
>>> bootm_headers_t *images, boot_os_fn *boot_fn)
>>> {
>>> + board_preboot_os();
>>> arch_preboot_os();
>>> boot_fn(state, argc, argv, images);
>>>
>>> --
>>> 2.18.0
>>>
>>>
>>> [Toradex Logo] Global Leader in Arm®
>>> Embedded Computer Modules
>>>
>>> Choose
>>>
>>
> Us
>>> | Products | Developer
>>> Center |
>>> Careers:
>>> - Linux Developer Conference, Brazil, Aug 25-26, 2018
>>> - NXP Technology Days 2018, United States, Aug 28, 2018
>>> - IoT Latin America, Brazil, Aug 29-30, 2018
>>>
>>>
>>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
Hi
On Thu., 16 Aug. 2018, 3:09 pm Stefan Agner, wrote:
> On 13.08.2018 09:30, Gerard Salvatella wrote:
> > Some boards require specific configuration prior to booting the kernel.
> > For instance, our boards require shutting down the display to avoid
> > fading transitions before the drivers are reloaded by the kernel. This
> > could be facilitated by adding an extra hook during the os booting
> > process.
>
> Maybe I can extend on what we are trying to achieve here:
>
> We enable display backlight using board code.
>
You can make it works almost easily.
I enable simple fb, inject allocated display parameters in dts to reserve
area, pass the area to the graphics controller and dismiss it during probing
This is mainline in linux support.
I have couple of patches need to clean up for imx architecture (imx6ull and
imx25)
You can still scripting it using cmd interface
Michael
>
> The architecture code then shuts down the display controller just before
> booting Linux (e.g. on i.MX, by calling
> ipuv3_fb_shutdown/lcdif_power_down in arch_preboot_os).
>
> This leads to a display which has backlight enabled, but no data
> driven... Depending on display this leads to noisy/fading transitions
> between U-Boot and Linux.
>
> So we would like to disable the backlight in board code.
>
> In a first version we used a weak display_shutdown() function, but with
> that we would have to add it to every architecture.
>
> This approach uses a generic board specific preeboot_os callback which
> can be used for different purpose too.
>
> Does this sound like an approach which is acceptable upstream?
>
> --
> Stefan
>
>
> >
> > Signed-off-by: Gerard Salvatella
> > ---
> > common/bootm_os.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/common/bootm_os.c b/common/bootm_os.c
> > index f4bd905909..1e7af56b64 100644
> > --- a/common/bootm_os.c
> > +++ b/common/bootm_os.c
> > @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> > /* please define platform specific arch_preboot_os() */
> > }
> >
> > +/* Allow for board specific config before we boot */
> > +__weak void board_preboot_os(void)
> > +{
> > + /* please define board specific board_preboot_os() */
> > +}
> > +
> > int boot_selected_os(int argc, char * const argv[], int state,
> > bootm_headers_t *images, boot_os_fn *boot_fn)
> > {
> > + board_preboot_os();
> > arch_preboot_os();
> > boot_fn(state, argc, argv, images);
> >
> > --
> > 2.18.0
> >
> >
> > [Toradex Logo] Global Leader in Arm®
> > Embedded Computer Modules
> >
> > Choose
> > Us<
> https://www.toradex.com/how-to-choose-system-computer-on-module-partner>
> > | Products | Developer
> > Center |
> > Careers:
> > - Linux Developer Conference, Brazil, Aug 25-26, 2018
> > - NXP Technology Days 2018, United States, Aug 28, 2018
> > - IoT Latin America, Brazil, Aug 29-30, 2018
> >
> >
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
On 13.08.2018 09:30, Gerard Salvatella wrote:
> Some boards require specific configuration prior to booting the kernel.
> For instance, our boards require shutting down the display to avoid
> fading transitions before the drivers are reloaded by the kernel. This
> could be facilitated by adding an extra hook during the os booting
> process.
>
> Signed-off-by: Gerard Salvatella
Tom, any thoughts on this? I guess it would get merged directly by you?
FWIW, I suggested this approach, and Gerards implementation looks good
to me, so:
Reviewed-by: Stefan Agner
--
Stefan
> ---
> common/bootm_os.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/common/bootm_os.c b/common/bootm_os.c
> index f4bd905909..1e7af56b64 100644
> --- a/common/bootm_os.c
> +++ b/common/bootm_os.c
> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> /* please define platform specific arch_preboot_os() */
> }
>
> +/* Allow for board specific config before we boot */
> +__weak void board_preboot_os(void)
> +{
> + /* please define board specific board_preboot_os() */
> +}
> +
> int boot_selected_os(int argc, char * const argv[], int state,
> bootm_headers_t *images, boot_os_fn *boot_fn)
> {
> + board_preboot_os();
> arch_preboot_os();
> boot_fn(state, argc, argv, images);
>
> --
> 2.18.0
>
>
> [Toradex Logo] Global Leader in Arm®
> Embedded Computer Modules
>
> Choose
> Us
> | Products | Developer
> Center |
> Careers:
> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> - NXP Technology Days 2018, United States, Aug 28, 2018
> - IoT Latin America, Brazil, Aug 29-30, 2018
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb board.
>-Original Message-
>From: York Sun
>Sent: Friday, September 21, 2018 8:20 PM
>To: Pramod Kumar
>Cc: u-boot@lists.denx.de
>Subject: Re: [PATCH v2] ls1088ardb_pb: Add support for ls1088ardb_pb
>board.
>
>On 08/21/2018 02:18 AM, Pramod Kumar wrote:
>> ls1088ardb-pb is another varinat of the ls1088ardb.
>> This board support two m.2 x2 gen 3 pcie card slot.
>> There is no support of sata, pcie standard slot, miniPCIE slot and TDM
>> in this board.
>>
>> Signed-off-by: Pramod Kumar
>> ---
>> Changes in v2:
>> - Fix the compilation issue when building u-boot for SD boot.
>>
>> arch/arm/Kconfig | 14 +++
>> arch/arm/cpu/armv8/Kconfig| 1 +
>> board/freescale/ls1088a/Kconfig | 43 +++
>> board/freescale/ls1088a/MAINTAINERS | 18 +++
>> board/freescale/ls1088a/Makefile | 1 +
>> board/freescale/ls1088a/ddr.h | 6 +-
>> board/freescale/ls1088a/ls1088a.c | 25 +++-
>> ... ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} | 2 +-
>> ...defconfig => ls1088ardb_pb_qspi_defconfig} | 2 +-
>> ...ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} | 2 +-
>> ...ig => ls1088ardb_pb_sdcard_qspi_defconfig} | 2 +-
>> include/configs/ls1088ardb_pb.h | 113 ++
>> 12 files changed, 219 insertions(+), 10 deletions(-) copy
>> configs/{ls1088ardb_qspi_SECURE_BOOT_defconfig =>
>> ls1088ardb_pb_qspi_SECURE_BOOT_defconfig} (97%) copy
>> configs/{ls1088ardb_qspi_defconfig => ls1088ardb_pb_qspi_defconfig}
>> (97%) copy configs/{ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig =>
>> ls1088ardb_pb_sdcard_qspi_SECURE_BOOT_defconfig} (98%) copy
>> configs/{ls1088ardb_sdcard_qspi_defconfig =>
>> ls1088ardb_pb_sdcard_qspi_defconfig} (98%) create mode 100644
>> include/configs/ls1088ardb_pb.h
>>
>
>Is it possible to reuse ls1088ardb and detect the board at runtime?
>>
>>For distro boot we need diffrent board variable for ls1088ardb and
>>ls1088ardb_pb, which can only be
>>achieved by using config tagets CONFIG_TARGET_LS1088ARDB and
>>CONFIG_TARGET_LS1088ARDB_PB respectively
f>> or both the boards.
>
>
>> diff --git a/board/freescale/ls1088a/ddr.h
>> b/board/freescale/ls1088a/ddr.h index b35c4ae2da..7a76f6bd50 100644
>> --- a/board/freescale/ls1088a/ddr.h
>> +++ b/board/freescale/ls1088a/ddr.h
>> @@ -1,6 +1,8 @@
>> /* SPDX-License-Identifier: GPL-2.0+ */
>> /*
>> - * Copyright 2017 NXP
>> + * Copyright 2017-2018 NXP
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>
>Do not add another SPDX line.
>
>> Will fix and send patch again.
>York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: lsch3: Add support of serdes3 module
> -Original Message- > From: York Sun > Sent: Saturday, September 22, 2018 2:40 AM > To: Priyanka Jain > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] armv8: lsch3: Add support of serdes3 module > > On 08/23/2018 11:43 PM, Priyanka Jain wrote: > > Some lsch3 based SoCs like lx2160a contains three serdes modules. > > Add support for third serdes protocol in lsch3 > > > > Signed-off-by: Priyanka Jain > > --- > > > > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h > > b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h > > index 6981076..bec35e8 100644 > > --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h > > +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h > > @@ -1,5 +1,6 @@ > > /* SPDX-License-Identifier: GPL-2.0+ */ > > /* > > + * Copyright 2018 NXP > > * Copyright 2015 Freescale Semiconductor, Inc. > > */ > > > > Let's not to leave a gap in the copyright year. We have been NXP since 2016. > > York OK, I will update the copyright in next version. Thanks Priyanka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed
On Mon, 2018-09-24 at 08:42 +0100, Alex Kiernan wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Wed, Sep 5, 2018 at 8:23 PM Rasmus Villemoes > wrote: > > > > In the case where one deletes an already-non-existing variable, or sets > > a variable to the value it already has, there is no point in writing the > > environment back, thus reducing wear on the underlying storage > > device. > > > > Signed-off-by: Rasmus Villemoes > > If you were running with a redundant env, and you were trying to sync > both copies, wouldn't you want a non-changing write to happen? That is a valid point, I have sometimes used this property to make sure I have a valid env. in both copies. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] WIP: serial: Introduce ->getinfo() callback
On Mon, Sep 24, 2018 at 10:44 AM Patrice CHOTARD wrote:
>
> Hi Andy
>
> On 09/22/2018 03:05 PM, Andy Shevchenko wrote:
> > TBD
>
> You forgot to add a commit message ;-)
Yes, cover letter explains why.
It's a halfbaked stuff in case someone is interested to continue.
For your convenience:
patch 1: introduces a hook to retrieve necessary data from UART driver
(in particular ns16550)
patch 2: adds SPCR data structures and uses hook from patch 1 to
generate the table
>
> >
> > Signed-off-by: Andy Shevchenko
> > ---
> > drivers/serial/ns16550.c | 14 ++
> > drivers/serial/serial-uclass.c | 21 +
> > include/common.h | 3 +++
> > include/serial.h | 14 ++
> > 4 files changed, 52 insertions(+)
> >
> > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> > index f9041aa626..a996446936 100644
> > --- a/drivers/serial/ns16550.c
> > +++ b/drivers/serial/ns16550.c
> > @@ -334,6 +334,19 @@ static int ns16550_serial_setbrg(struct udevice *dev,
> > int baudrate)
> > return 0;
> > }
> >
> > +static int ns16550_serial_getinfo(struct udevice *dev, struct
> > serial_device_info *info)
> > +{
> > + struct NS16550 *const com_port = dev_get_priv(dev);
> > + struct ns16550_platdata *plat = com_port->plat;
> > +
> > + info->addr_space = 0;
> > + info->reg_width = 8;
> > + info->reg_shift = plat->reg_shift;
> > + info->reg_offset = plat->reg_offset;
> > + info->addr = plat->base;
> > + return 0;
> > +}
> > +
> > int ns16550_serial_probe(struct udevice *dev)
> > {
> > struct NS16550 *const com_port = dev_get_priv(dev);
> > @@ -440,6 +453,7 @@ const struct dm_serial_ops ns16550_serial_ops = {
> > .pending = ns16550_serial_pending,
> > .getc = ns16550_serial_getc,
> > .setbrg = ns16550_serial_setbrg,
> > + .getinfo = ns16550_serial_getinfo,
> > };
> >
> > #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> > diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> > index ffdcae0931..4778302e8f 100644
> > --- a/drivers/serial/serial-uclass.c
> > +++ b/drivers/serial/serial-uclass.c
> > @@ -304,6 +304,25 @@ int serial_setconfig(uint config)
> > return 0;
> > }
> >
> > +int serial_getinfo(struct serial_device_info *info)
> > +{
> > + struct dm_serial_ops *ops;
> > +
> > + if (!gd->cur_serial_dev)
> > + return -ENODEV;
> > +
> > + if (!info)
> > + return -EINVAL;
> > +
> > + info->baudrate = gd->baudrate;
> > +
> > + ops = serial_get_ops(gd->cur_serial_dev);
> > + if (ops->getinfo)
> > + return ops->getinfo(gd->cur_serial_dev, info);
> > +
> > + return -EINVAL;
> > +}
> > +
> > void serial_stdio_init(void)
> > {
> > }
> > @@ -421,6 +440,8 @@ static int serial_post_probe(struct udevice *dev)
> > if (ops->loop)
> > ops->loop += gd->reloc_off
> > #endif
> > + if (ops->getinfo)
> > + ops->getinfo += gd->reloc_off;
> > #endif
> > /* Set the baud rate */
> > if (ops->setbrg) {
> > diff --git a/include/common.h b/include/common.h
> > index 83b3bdc58d..0479f3eac1 100644
> > --- a/include/common.h
> > +++ b/include/common.h
> > @@ -349,6 +349,8 @@ void smp_set_core_boot_addr(unsigned long addr, int
> > corenr);
> > void smp_kick_all_cpus(void);
> >
> > /* $(CPU)/serial.c */
> > +struct serial_device_info;
> > +
> > int serial_init (void);
> > void serial_setbrg (void);
> > void serial_putc (const char);
> > @@ -357,6 +359,7 @@ void serial_puts (const char *);
> > int serial_getc (void);
> > int serial_tstc (void);
> > int serial_setconfig(uint config);
> > +int serial_getinfo(struct serial_device_info *info);
> >
> > /* $(CPU)/speed.c */
> > int get_clocks (void);
> > diff --git a/include/serial.h b/include/serial.h
> > index 020cd392e8..c73477b079 100644
> > --- a/include/serial.h
> > +++ b/include/serial.h
> > @@ -111,6 +111,16 @@ enum serial_stop {
> > SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
> > SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
> >
> > +/* REVISIT: ACPI GAS specification implied */
> > +struct serial_device_info {
> > + unsigned int baudrate;
> > + u8 addr_space; /* 0 - MMIO, 1 - IO */
> > + u8 reg_width;
> > + u8 reg_offset;
> > + u8 reg_shift;
> > + u64 addr;
> > +};
> > +
> > /**
> > * struct struct dm_serial_ops - Driver model serial operations
> > *
> > @@ -201,6 +211,10 @@ struct dm_serial_ops {
> >* @return 0 if OK, -ve on error
> >*/
> > int (*setconfig)(struct udevice *dev, uint serial_config);
> > + /**
> > + * getinfo() - Get serial device information
> > + */
> > + int (*getinfo)(struct udevice *dev, struct serial_device_info *info);
> > };
> >
> > /**
> >
> ___
>
Re: [U-Boot] [PATCH v1 2/2] WIP: x86: acpi: Generate SPCR table
On 09/22/2018 03:05 PM, Andy Shevchenko wrote:
> TBD
Same remark as Patch 1
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/include/asm/acpi_table.h | 25 ++
> arch/x86/lib/acpi_table.c | 82 +++
> 2 files changed, 107 insertions(+)
>
> diff --git a/arch/x86/include/asm/acpi_table.h
> b/arch/x86/include/asm/acpi_table.h
> index 95fae036f6..27435871b9 100644
> --- a/arch/x86/include/asm/acpi_table.h
> +++ b/arch/x86/include/asm/acpi_table.h
> @@ -303,6 +303,31 @@ struct acpi_mcfg_mmconfig {
> /* ACPI global NVS structure */
> struct acpi_global_nvs;
>
> +/* SPCR (Serial Port Console Redirection table) */
> +struct __packed acpi_spcr {
> + struct acpi_table_header header;/* Common ACPI table header */
> + u8 interface_type; /* 0=full 16550, 1=subset of 16550 */
> + u8 reserved[3];
> + struct acpi_gen_regaddr serial_port;/* The base address of the
> Serial Port register set */
> + u8 interrupt_type;
> + u8 pc_interrupt;
> + u32 interrupt; /* Global system interrupt */
> + u8 baud_rate;
> + u8 parity;
> + u8 stop_bits;
> + u8 flow_control;
> + u8 terminal_type;
> + u8 reserved1;
> + u16 pci_device_id; /* Must be 0x if not PCI device */
> + u16 pci_vendor_id; /* Must be 0x if not PCI device */
> + u8 pci_bus;
> + u8 pci_device;
> + u8 pci_function;
> + u32 pci_flags;
> + u8 pci_segment;
> + u32 reserved2;
> +};
> +
> /* These can be used by the target port */
>
> void acpi_fill_header(struct acpi_table_header *header, char *signature);
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index c6b2026613..551a78b11a 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -338,6 +339,79 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
> header->checksum = table_compute_checksum((void *)mcfg, header->length);
> }
>
> +static void acpi_create_spcr(struct acpi_spcr *spcr)
> +{
> + struct acpi_table_header *header = &(spcr->header);
> + struct serial_device_info info = {0};
> + int access_size;
> + int ret;
> +
> + /* Fill out header fields */
> + acpi_fill_header(header, "SPCR");
> + header->length = sizeof(struct acpi_spcr);
> + header->revision = 2;
> +
> + ret = serial_getinfo();
> + if (ret)
> + debug("Can't get information of serial device: %d\n", ret);
> +
> + /* Encode baud rate */
> + switch (info.baudrate) {
> + case 9600:
> + spcr->baud_rate = 3;
> + break;
> + case 19200:
> + spcr->baud_rate = 4;
> + break;
> + case 57600:
> + spcr->baud_rate = 6;
> + break;
> + case 115200:
> + spcr->baud_rate = 7;
> + break;
> + default:
> + spcr->baud_rate = 0;
> + break;
> + }
> +
> + /* Encode register access size */
> + switch (info.reg_shift) {
> + case 0:
> + access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS;
> + break;
> + case 1:
> + access_size = ACPI_ACCESS_SIZE_WORD_ACCESS;
> + break;
> + case 2:
> + access_size = ACPI_ACCESS_SIZE_DWORD_ACCESS;
> + break;
> + case 3:
> + access_size = ACPI_ACCESS_SIZE_QWORD_ACCESS;
> + break;
> + default:
> + access_size = ACPI_ACCESS_SIZE_UNDEFINED;
> + break;
> + }
> +
> + spcr->serial_port.space_id = ACPI_ADDRESS_SPACE_MEMORY;
> + spcr->serial_port.bit_width = info.reg_width;
> + spcr->serial_port.bit_offset = info.reg_offset;
> + spcr->serial_port.access_size = access_size;
> + spcr->serial_port.addrl = info.addr >> 0;
> + spcr->serial_port.addrh = info.addr >> 32;
> +
> + /* Hard coded values for now */
> + spcr->parity = 0;
> + spcr->stop_bits = 1;
> +
> + /* No PCI devices for now */
> + spcr->pci_device_id = 0x;
> + spcr->pci_vendor_id = 0x;
> +
> + /* Fix checksum */
> + header->checksum = table_compute_checksum((void *)spcr, header->length);
> +}
> +
> /*
> * QEMU's version of write_acpi_tables is defined in drivers/misc/qfw.c
> */
> @@ -352,6 +426,7 @@ ulong write_acpi_tables(ulong start)
> struct acpi_fadt *fadt;
> struct acpi_mcfg *mcfg;
> struct acpi_madt *madt;
> + struct acpi_spcr *spcr;
> int i;
>
> current = start;
> @@ -440,6 +515,13 @@ ulong write_acpi_tables(ulong start)
> acpi_add_table(rsdp, mcfg);
> current = ALIGN(current, 16);
>
> + debug("ACPI:* SPCR\n");
> + spcr = (struct acpi_spcr *)current;
> + acpi_create_spcr(spcr);
> + current += spcr->header.length;
> + acpi_add_table(rsdp, spcr);
> + current =
Re: [U-Boot] [PATCH v1 1/2] WIP: serial: Introduce ->getinfo() callback
Hi Andy
On 09/22/2018 03:05 PM, Andy Shevchenko wrote:
> TBD
You forgot to add a commit message ;-)
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/serial/ns16550.c | 14 ++
> drivers/serial/serial-uclass.c | 21 +
> include/common.h | 3 +++
> include/serial.h | 14 ++
> 4 files changed, 52 insertions(+)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index f9041aa626..a996446936 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -334,6 +334,19 @@ static int ns16550_serial_setbrg(struct udevice *dev,
> int baudrate)
> return 0;
> }
>
> +static int ns16550_serial_getinfo(struct udevice *dev, struct
> serial_device_info *info)
> +{
> + struct NS16550 *const com_port = dev_get_priv(dev);
> + struct ns16550_platdata *plat = com_port->plat;
> +
> + info->addr_space = 0;
> + info->reg_width = 8;
> + info->reg_shift = plat->reg_shift;
> + info->reg_offset = plat->reg_offset;
> + info->addr = plat->base;
> + return 0;
> +}
> +
> int ns16550_serial_probe(struct udevice *dev)
> {
> struct NS16550 *const com_port = dev_get_priv(dev);
> @@ -440,6 +453,7 @@ const struct dm_serial_ops ns16550_serial_ops = {
> .pending = ns16550_serial_pending,
> .getc = ns16550_serial_getc,
> .setbrg = ns16550_serial_setbrg,
> + .getinfo = ns16550_serial_getinfo,
> };
>
> #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index ffdcae0931..4778302e8f 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -304,6 +304,25 @@ int serial_setconfig(uint config)
> return 0;
> }
>
> +int serial_getinfo(struct serial_device_info *info)
> +{
> + struct dm_serial_ops *ops;
> +
> + if (!gd->cur_serial_dev)
> + return -ENODEV;
> +
> + if (!info)
> + return -EINVAL;
> +
> + info->baudrate = gd->baudrate;
> +
> + ops = serial_get_ops(gd->cur_serial_dev);
> + if (ops->getinfo)
> + return ops->getinfo(gd->cur_serial_dev, info);
> +
> + return -EINVAL;
> +}
> +
> void serial_stdio_init(void)
> {
> }
> @@ -421,6 +440,8 @@ static int serial_post_probe(struct udevice *dev)
> if (ops->loop)
> ops->loop += gd->reloc_off
> #endif
> + if (ops->getinfo)
> + ops->getinfo += gd->reloc_off;
> #endif
> /* Set the baud rate */
> if (ops->setbrg) {
> diff --git a/include/common.h b/include/common.h
> index 83b3bdc58d..0479f3eac1 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -349,6 +349,8 @@ void smp_set_core_boot_addr(unsigned long addr, int
> corenr);
> void smp_kick_all_cpus(void);
>
> /* $(CPU)/serial.c */
> +struct serial_device_info;
> +
> int serial_init (void);
> void serial_setbrg (void);
> void serial_putc (const char);
> @@ -357,6 +359,7 @@ void serial_puts (const char *);
> int serial_getc (void);
> int serial_tstc (void);
> int serial_setconfig(uint config);
> +int serial_getinfo(struct serial_device_info *info);
>
> /* $(CPU)/speed.c */
> int get_clocks (void);
> diff --git a/include/serial.h b/include/serial.h
> index 020cd392e8..c73477b079 100644
> --- a/include/serial.h
> +++ b/include/serial.h
> @@ -111,6 +111,16 @@ enum serial_stop {
> SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
> SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
>
> +/* REVISIT: ACPI GAS specification implied */
> +struct serial_device_info {
> + unsigned int baudrate;
> + u8 addr_space; /* 0 - MMIO, 1 - IO */
> + u8 reg_width;
> + u8 reg_offset;
> + u8 reg_shift;
> + u64 addr;
> +};
> +
> /**
> * struct struct dm_serial_ops - Driver model serial operations
> *
> @@ -201,6 +211,10 @@ struct dm_serial_ops {
>* @return 0 if OK, -ve on error
>*/
> int (*setconfig)(struct udevice *dev, uint serial_config);
> + /**
> + * getinfo() - Get serial device information
> + */
> + int (*getinfo)(struct udevice *dev, struct serial_device_info *info);
> };
>
> /**
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed
On Wed, Sep 5, 2018 at 8:23 PM Rasmus Villemoes
wrote:
>
> In the case where one deletes an already-non-existing variable, or sets
> a variable to the value it already has, there is no point in writing the
> environment back, thus reducing wear on the underlying storage
> device.
>
> Signed-off-by: Rasmus Villemoes
If you were running with a redundant env, and you were trying to sync
both copies, wouldn't you want a non-changing write to happen?
> ---
> tools/env/fw_env.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
> index a5d75958e1..87aaa15198 100644
> --- a/tools/env/fw_env.c
> +++ b/tools/env/fw_env.c
> @@ -110,6 +110,7 @@ struct environment {
> unsigned char *flags;
> char *data;
> enum flag_scheme flag_scheme;
> + int dirty;
> };
>
> static struct environment environment = {
> @@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts)
> if (!opts)
> opts = _opts;
>
> + if (!environment.dirty)
> + return 0;
> +
> /*
> * Update CRC
> */
> @@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value)
>
> deleting = (oldval && !(value && strlen(value)));
> creating = (!oldval && (value && strlen(value)));
> - overwriting = (oldval && (value && strlen(value)));
> + overwriting = (oldval && (value && strlen(value) &&
> + strcmp(oldval, value)));
>
> /* check for permission */
> if (deleting) {
> @@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value)
> /* Nothing to do */
> return 0;
>
> + environment.dirty = 1;
> if (deleting || overwriting) {
> if (*++nxt == '\0') {
> *env = '\0';
> @@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts)
> "Warning: Bad CRC, using default
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> + environment.dirty = 1;
> }
> } else {
> flag0 = *environment.flags;
> @@ -1503,6 +1510,7 @@ int fw_env_open(struct env_opts *opts)
> "Warning: Bad CRC, using default
> environment\n");
> memcpy(environment.data, default_environment,
>sizeof(default_environment));
> + environment.dirty = 1;
> dev_current = 0;
> } else {
> switch (environment.flag_scheme) {
> --
> 2.16.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/15] sandbox: Unprotect DATA regions in bus tests
On 24.09.18 00:47, Simon Glass wrote: > On my Ubuntu 18.04.1 machine two driver-model bus tests have started > failing recently. The problem appears to be that the DATA region of the Are you sure it's .data and not .rodata? The linker script should really put all those lists into its own section, so I'm not sure how you end up with them getting write protected. Can you please run $ objdump -h u-boot on your broken binary? Also do $ nm u-boot | grep .u_boot_list so we can correlate whether the symbols ended up in the correct section. Thanks, Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6 v4] mips: Add basic MediaTek MT7620/88 support
On 23.09.2018 15:37, Daniel Schwierzeck wrote: On 05.09.2018 15:12, Stefan Roese wrote: This patch adds basic support for the MediaTek MT7620/88 SoCs. Parts of the code is copied from the MediaTek GitHub repository: https://github.com/MediaTek-Labs/linkit-smart-uboot.git The mt7628a.dtsi file is imported from Linux v4.17. Support for the LinkIt Smart 7688 module and the Gardena Smart Gateway both based on the MT7688 will be added in further patches. Signed-off-by: Stefan Roese Cc: Daniel Schwierzeck --- v4: - Remove dead code from debug version in lowlevel_init - Use sX registers now for real - Increase cache line size in ddr_calibrate() to 128 as done in the original code v3: - Added dtsi file with this platforms support as suggested by Daniel - Rebased on top of Daniels I-cache startup patches -> removed magic with KSEG0 call of ddr_calibrate. Its now called directly and the bootup is much faster - Some improvements to print_cpuinfo(), use ioremap_nocache etc - Added .set noreorder to lowlevel_init.S - Multiple improvements to lowlevel_init.S as suggested by Daniel v2: - Sort Kconfig symbols alphabetically - Use MIPS_TUNE_24KC - Use imply for SPI support - Dont' add LinkIt module support yet (is added with the board support) - Move SKIP_LOWLEVEL_INIT from Kconfig to config header - Use DT to get the base address of the system controller (for display_cpuinfo) - Remove _machine_restart - a separate driver is provided in a new patch - Remove cachop_op() and cal_invalidate_dcache_range and use the generic invalidate_dcache_range function instead arch/mips/Kconfig | 16 ++ arch/mips/Makefile| 1 + arch/mips/dts/mt7628a.dtsi| 135 +++ arch/mips/mach-mt7620/Kconfig | 113 + arch/mips/mach-mt7620/Makefile| 8 + arch/mips/mach-mt7620/cpu.c | 69 ++ arch/mips/mach-mt7620/ddr_calibrate.c | 308 arch/mips/mach-mt7620/lowlevel_init.S | 322 ++ arch/mips/mach-mt7620/mt76xx.h| 32 +++ 9 files changed, 1004 insertions(+) create mode 100644 arch/mips/dts/mt7628a.dtsi create mode 100644 arch/mips/mach-mt7620/Kconfig create mode 100644 arch/mips/mach-mt7620/Makefile create mode 100644 arch/mips/mach-mt7620/cpu.c create mode 100644 arch/mips/mach-mt7620/ddr_calibrate.c create mode 100644 arch/mips/mach-mt7620/lowlevel_init.S create mode 100644 arch/mips/mach-mt7620/mt76xx.h applied to u-boot-mips, thanks. Stefan, because CONFIG_NR_DRAM_BANKS was converted to Kconfig in mainline, I needed to run moveconfig.py on your patch series. I committed all changes on the defconfig files which removes things like your SPI driver and SPI-NAND support. I think a "make savedefconfig" should always produce the same result. You should send follow-up patches to enable those features after they are merged to mainline. Yes, will do in a few days. Most likely I will wait until the SPI changes are in mainline as well (MT7621 SPI driver and SPI NAND infrastructure). Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed
Hi On Mon., 24 Sep. 2018, 8:19 am Rasmus Villemoes, wrote: > On 2018-09-05 21:22, Rasmus Villemoes wrote: > > In the case where one deletes an already-non-existing variable, or sets > > a variable to the value it already has, there is no point in writing the > > environment back, thus reducing wear on the underlying storage > > device. > > ping > Sorry I will give a try and make sense in my use cases Michael > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed
On 2018-09-05 21:22, Rasmus Villemoes wrote: > In the case where one deletes an already-non-existing variable, or sets > a variable to the value it already has, there is no point in writing the > environment back, thus reducing wear on the underlying storage > device. ping ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
