On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a command that shows the individual blocks of data generated by each
> device, effectively splitting the full table into its component parts.
> This can be helpful for debugging.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> For many device types it is possible to figure out the name just by
> looking at its uclass or parent. Add a function to handle this, since it
> allows us to cover the vast majority of cases automatically.
>
> However it is
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Some devices need to inject extra code into the Differentiated System
> Descriptor Table (DSDT). Add a method to handle this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix 'THe'
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Call the new core function to inject ASL programmatically into the DSDT.
> This is made up of fragments generated by devices that have the
> inject_dsdt() method. The normal, compiled ASL file is added after this.
>
> Signed-off-by: Simon
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> This function cannot currently be called on the root node. Add a check
> for this as well as a test.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/dm/device.h | 2 +-
>
On 29/06/20 10:20 am, Jan Kiszka wrote:
> On 29.06.20 04:26, Lokesh Vutla wrote:
>> +Tom
>>
>> On 23/06/20 8:11 pm, Jan Kiszka wrote:
>>> On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
>
>
> On 23/06/20 4:45 pm, Jan Kiszka wrote:
>> From: Jan
Hi Alex,
Am 29.06.2020 um 05:23 schrieb David Wu:
Hi Alexander,
Thank you for your patch, the grf header file is missing for rk3066, the GRF_SOC_CON1 offset of 3066
is 0x154, the corresponding bit of i2c0~i2c4 is also bit11 ~ bit15.
There is currently no support for rk3066 at mainline,
On 29.06.20 04:26, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a /chosen property to control the order in which the data appears
> in the SSDT. This allows matching up U-Boot's output from a dump of the
> known-good data obtained from within Linux.
>
> Signed-off-by: Simon Glass
> ---
>
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> It is useful to be able to control the order of data written to the SSDT
> so that we can compare the output against known-good kernel dumps.
>
> Add code to record each item that is added along with the device that
> added it. That allows
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Call the new core function to write the SSDT. This is made up of fragments
> generated by devices that have the fill_ssdt() method.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> Drop coreboot_acpi_ids enum
>
> Changes in v1:
> -
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Put this table before MCFG so that it matches the order that coreboot uses
> when passing tables to Linux. This is a cosmetic change since the order of
> the tables does not otherwise matter.
>
> Signed-off-by: Simon Glass
> Reviewed-by:
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Some devices need to generate code for the Secondary System Descriptor
> Table (SSDT). Add a method to handle this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix 'THe' typo
>
> Changes in
Hi Alexander,
Thank you for your patch, the grf header file is missing for rk3066, the
GRF_SOC_CON1 offset of 3066 is 0x154, the corresponding bit of i2c0~i2c4
is also bit11 ~ bit15.
There is currently no support for rk3066 at mainline, rk3066 is not
handled here, I think it’s okay, so,
Hi Simon,
On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote:
>
> Hi Rayagonda,
>
> On Wed, 10 Jun 2020 at 05:15, Rayagonda Kokatanur
> wrote:
> >
> > From: Vikas Gupta
> >
> > Add optee based bnxt fw load driver.
> > bnxt is Broadcom NetXtreme controller Ethernet card.
> > This driver is used
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> These are used in ACPI to disable power to various pats of the system when
> in sleep. Add a way to create a power resource, with the caller finishing
> off the details.
>
> Reviewed-by: Wolfgang Wallner
> Signed-off-by: Simon Glass
> ---
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Power to some devices is controlled by GPIOs. Add a way to generate ACPI
> code to enable and disable a GPIO so that this can be handled within an
> ACPI method.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Some drivers in Linux support both device tree and ACPI. U-Boot itself
> uses Linux device-tree bindings for its own configuration but does not use
> ACPI.
>
> It is convenient to copy these values over to the device tree for
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add more functions to handle some miscellaneous ACPI opcodes.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix function name in comment for acpigen_write_not()
> - Use #defines for
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 046c6ab283..8090cb27fe 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -687,7 +687,11 @@ static int ehci_usb_bind(struct udevice *dev)
>
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> @@ -23,6 +25,9 @@
> #include
>
> #include "ehci.h"
> +#if CONFIG_IS_ENABLED(POWER_DOMAIN)
> +#include
> +#endif
The ifdef here should not be needed.
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -590,6 +595,18 @@ static int ehci_usb_phy_mode(struct
On 6/29/20 4:13 AM, Peng Fan wrote:
Hi,
> The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
> previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers
> are same as i.MX7D. So add its support in ehci-mx6 driver.
>
> Also the driver is updated to remove build warning
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> @@ -366,7 +366,7 @@ static void usb_oc_config(int index)
> struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
> USB_OTHERREGS_OFFSET);
> void __iomem *ctrl = (void __iomem *)(>ctrl[index]);
> -#elif
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> +static void ehci_mx6_powerup_fixup(struct ehci_ctrl *ctrl, uint32_t
> *status_reg,
> +uint32_t *reg)
> +{
> + u32 result;
> + int usec = 2000;
> +
> + mdelay(50);
> +
> + do {
> + result =
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
> On 23.06.20 14:37, Jan Kiszka wrote:
>> On 23.06.20 13:50, Lokesh Vutla wrote:
>>>
>>>
>>> On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware,
On 25/06/20 12:13 pm, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Signed-off-by: Jan Kiszka
Thanks for cleaning it up Jan. May be a small commit message would be really
useful.
Other than that:
Acked-by: Lokesh Vutla
Thanks and regards,
Lokesh
On 25/06/20 12:13 pm, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Signed-off-by: Jan Kiszka
Thanks for cleaning ti up Jan. May be a small commit message would help.
Other that that:
Acked-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
> arch/arm/mach-k3/config.mk | 17
From: Sherry Sun
EP0 has been used to transfer file data in sdp before, but the max
packetsize of ep0 is 64 bytes. So in order to improve the file transfer
speed, here add the EP1_OUT interrupt endpoint which max packetsize is
set to 1024 byte.
After testing, it turns out that using ep1out is
From: Sherry Sun
Since the USB HID limits the maximum bandwidth(3072) for interrupt
endpoint transfers, when the bInterval set to 1, we can only support 3
boards to run sdp at the same time. In order to support more boards,
change the bInterval of interrupt endpoint to 3, which will not affect
Add support to f_sdp to search and load iMX8 container image or iMX8M
FIT image by new UUU command SDPV.
When using the SDPV, the uuu will continue to send out data after first
level boot loader used by ROM. This means uuu won't skip to the offset
of the second boot loader, and the padding data
Add g_dnl_get_board_bcd_device_number, the new BCD value is used by uuu to
distinguish
if the SPL supports the SDPV.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/spl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index
From: Ye Li
Add HS endpoint descriptor for SDP. So that we can use high speed endpoint,
and the SDP device can send packet with 512 byte size.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 30 --
1 file changed, 28 insertions(+), 2
From: Ye Li
Because the buffer length of sdp usb request is 65, we have to allocate
65 bytes not 64 bytes. Otherwise there is potential buffer overflow.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Frank Li
Need initialize UDC before run sdp download
Signed-off-by: Frank Li
Signed-off-by: Peng Fan
---
common/spl/spl_sdp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index e7f7b68411..ae9c09883a 100644
--- a/common/spl/spl_sdp.c
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> ACPI supports writing a UUID in a special format. Add a function to handle
> this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 13 +
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> More complex device properties can be provided to drivers via a
> device-specific data (_DSD) object.
>
> To create this we need to build it up in a separate data structure and
> then generate the ACPI code, due to its recursive
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Allowing writing out a reference to a GPIO within the ACPI output. This
> can be used by ACPI code to access a GPIO at runtime.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Use an enum for the GPIO priority
> - Add error
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> ACPI supports storing names which are made up of multiple path components.
> Several special cases are supported. Add a function to emit a name.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> ACPI supports storing a simple nul-terminated string. Add support for
nits: null
> this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 10
From: Ye Li
Since the i.MX8MM reuses the otg controllers on i.MX7D. We can use
CONFIG_USB_EHCI_MX7 for them.
Due the TCPC and load switch are used on Typec circuit. Add the
board_usb_init and board_usb_cleanup to ehci-mx6 DM driver. So
we can implement the TCPC settings in these board
From: Ye Li
Add the IMX8MN to the EHCI-MX7 kconfig dependency.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/ehci-mx6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/Kconfig
From: Ye Li
The bind codes calculate the address offset for controller index, but
it is wrong for imx8m and imx8. It causes secondary controller fails to
work. So fix this problem, and also change all seq to req_seq.
There is another issue here for imx8, the codes use runtime CPU type check.
When moving to support partition reboot or android auto on XEN,
linux kernel will runs into runtime suspend state, and the usb
will be configured to low power suspend state by Linux.
Then we reboot and runs into U-Boot, however the usb already in
suspended state and uboot not able to lock the phy
From: Ye Li
Since there is no uclass for USB PHY. The device won't be setup for the USB PHY
node in DTB. And its associated power domain device won't be turned on neither
by DM framework.
This patch modifies the ehci-mx6 driver to enable the power domain device before
access the USB PHY. This
From: Ye Li
The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers
are same as i.MX7D. So add its support in ehci-mx6 driver.
Also the driver is updated to remove build warning for 64 bits CPU.
Signed-off-by: Ye Li
From: Ye Li
When doing port reset, the PR bit of PORTSC1 will be automatically
cleared by our IP, but standard EHCI needs explicit clear by software. The
EHCI-HCD driver follow the EHCI specification, so after 50ms wait, it
clear the PR bit by writting to the PORTSC1 register with value loaded
From: Ye Li
The usb mass storage (f_mass_storage.c) uses fixed usb index 0,
this causes problem while CDNS3 USB controller index is 1.
Modify the API of fsg to pass the controller index.
Reviewed-by: Jun Li
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
cmd/usb_mass_storage.c
From: Ye Li
When unregister gadget driver in ci_udc, the usb device is not
removed or stop. This causes next "usb start" fails to work.
Add a new interface "usb_remove_ehci_gadget" in usb-uclass to
remove the usb device for DM driver. Using "usb_lowlevel_stop" for
non-DM driver.
Signed-off-by:
On Sun, Jun 28, 2020 at 02:27:57PM +0200, Anatolij Gustschin wrote:
> Hi Tom,
>
> please pull some fixes for v2020.07. Thanks!
>
> gitlab CI:
> https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3806
>
> The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603:
> -0400)
>
> are available in the Git repository at:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git
> tags/u-boot-rockchip-20200628
>
> for you to fetch changes up to 673eb44e91bc0c06cb1e3f353f5d07b4f9e5a586:
>
> rockchip: correctly set vop0 o
On Fri, Jun 26, 2020 at 04:02:32AM +, Tan, Ley Foon wrote:
> Hi Tom
>
> Please pull one fix for uboot socfpga.
> Thanks.
>
> Regards
> Ley Foon
>
> The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603:
>
> Merge tag 'efi-2020-07-rc6' of
>
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> ACPI supports storing integers in various ways. Add a function to handle
> this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 17 ++
>
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> It is convenient to write a length value for preceding a block of data.
> Of course the length is not known or is hard to calculate a priori. So add
> a way to mark the start on a stack, so the length can be updated when
> known.
>
>
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> A package collects together several elements. Add an easy way of writing
> a package header and updating its length later.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix 'easy of testing'
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write a SPI descriptor to the generated ACPI code.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Make acpi_device_write_spi() static
> - Add an extra comment about scope to acpi_device_set_spi()
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write a GPIO descriptor to the generated ACPI code.
>
> Reviewed-by: Wolfgang Wallner
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Update comment in acpi_device_set_i2c() to talk about scope
Hi Heinrich,
On Sun, Jun 28, 2020 at 8:23 PM Heinrich Schuchardt wrote:
>
> On 6/28/20 3:03 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > test_efi_fit tests fail on RISC-V currently. This is due to the
> > RISC-V arch_fixup_fdt() checks the #size-cells of the root node
> > in order to
On Sun, 28 Jun 2020 20:36:46 +0530
Jagan Teki ja...@amarulasolutions.com wrote:
...
> Any comments on this fix? it needs to be in the release in order to
> work 4K HDMI. I did tests lower than 4K resolution as well.
I'm afraid that this is not the right fix, so I skipped this
patch in the video
Hi Jagan,
On Wed, 24 Jun 2020 20:48:43 +0530
Jagan Teki ja...@amarulasolutions.com wrote:
...
> @@ -425,7 +425,7 @@ int rk_vop_bind(struct udevice *dev)
> {
> struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
>
> - plat->size = 4 * (CONFIG_VIDEO_ROCKCHIP_MAX_XRES *
> +
On Sun, Jun 28, 2020 at 07:00:27PM +0200, Simon Guinot wrote:
> The spi0 alias is needed by the environment code to retrieve the SPI
> flash. This patch adds some -u-boot.dtsi files, providing the spi0
> aliases, for all the following Kirkwood-based LaCie boards:
>
> - d2 Network v2
> - Internet
This patch enables DM_ETH for the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot
---
board/LaCie/net2big_v2/net2big_v2.c | 2 +-
This patch switches the SATA driver from mvsata_ide to sata_mv for the
following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot
---
This patch enables DM_USB and USB_STORAGE for the following
Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
Signed-off-by: Simon Guinot
---
configs/d2net_v2_defconfig | 2 ++
This patch converts the following Kirkwood-based LaCie boards to DM,
DM_SPI and DM_SPI_FLASH:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot
---
The spi0 alias is needed by the environment code to retrieve the SPI
flash. This patch adds some -u-boot.dtsi files, providing the spi0
aliases, for all the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
-
This patch series converts the following LaCie boards (Marvell
Kirkwood-based) to use DM drivers:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Changes in v2:
- Move spi0 DT aliases into per boards
On Fri, Jun 26, 2020 at 03:40:51PM -0400, Tom Rini wrote:
> On Thu, Jun 25, 2020 at 12:28:56AM +0200, Simon Guinot wrote:
>
> > This patch converts the following Kirkwood-based LaCie boards to DM,
> > DM_SPI and DM_SPI_FLASH:
> >
> > - d2 Network v2
> > - Internet Space v2
> > - 2Big Network v2
On Wed, Jun 24, 2020 at 11:07 AM Volodymyr Babchuk
wrote:
>
> ARM Architecture reference manual clearly states that PE pipeline
> should be flushed after any change to system registers. Refer to
> paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture
> Reference Manual ARMv8 for
On Wed, Jun 24, 2020 at 8:48 PM Jagan Teki wrote:
>
> Video framework would use plat size as a frame buffer
> pointer in rockchip video drivers.
>
> Typical frame buffer pointer would compute based on
> maximum resolutions supporting followed by bits per
> pixel value. Right now the value 4
All cpu cores within FU540-C000 having split I/D caches.
Set the L1 cache feature bit using the i-cache-size or d-cache-size
as one of the property from device tree indicating that L1 cache is
present on the cpu core.
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 999.100 MHz: L1
The conditional check to read "mmu-type" from the device tree
is not rightly handled due to which the cpu feature doesn't include
CPU_FEAT_MMU even if it's corresponding entry is present in the device
tree.
The initialization of cpu features is now taken care in cpu-uclass
driver, so no need to
Add cpu aliases to U-Boot specific dtsi for hifive-unleashed.
Without aliases we see that the CPU device sequence numbers are set
randomly and the cpu list/detail command will show it as follows:
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
0:
The cmd "cpu detail" fetches uninitialized cpu feature information
and thus displays wrong / inconsitent details as below.
For eg: FU540-C000 doesn't have any microcode, yet the cmd display's it.
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 999.100 MHz: L1 cache, MMU,
U-Boot cmd "cpu detail" shows inconsistent CPU features.
The current "cpu detail" sometimes shows "Microcode" as a feature, which
is not the case with FU540-C000 on HiFive Unleashed board.
Patch 1: add cpu node aliases.
Patch 2: Init CPU information to avoid inconsistent cpu information.
Patch
Hi Tom,
please pull some fixes for v2020.07. Thanks!
gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3806
The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603:
Merge tag 'efi-2020-07-rc6' of
On 6/28/20 3:03 AM, Bin Meng wrote:
> From: Bin Meng
>
> test_efi_fit tests fail on RISC-V currently. This is due to the
> RISC-V arch_fixup_fdt() checks the #size-cells of the root node
> in order to correctly fix up the reserved memory node.
>
> Per the DT binding, the /reserved-memory node
eae62ae8de1893f7cf08e276ab841d3f99245603:
Merge tag 'efi-2020-07-rc6' of
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-25 13:33:15 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git
tags/u-boot-rockchip-20200628
for you to fetch
pycrypto is needed for script to generate correct its.
Signed-off-by: Kever Yang
---
.gitlab-ci.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f2e491c117..4841e7afbe 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -67,7
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Some devices use interrupts but some use GPIOs. Since these are fully
> specified in the device tree we can automatically produce the correct ACPI
> descriptor for a device.
>
> Add a function to handle this.
>
> Signed-off-by: Simon Glass
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add support for output of strings and streams of bytes.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 19 +++
> lib/acpi/acpigen.c
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write an interrupt descriptor to the generated ACPI
> code.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpi_device.h | 15 +
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> When generating ACPI tables we need to convert GPIOs in U-Boot to the ACPI
> structures required by ACPI. This is a SoC-specific conversion and cannot
> be handled by generic code, so add a new GPIO method to do the conversion.
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write a GPIO descriptor to the generated ACPI code.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpi_device.h | 22 ++
>
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> When generating ACPI tables we need to convert IRQs in U-Boot to the ACPI
> structures required by ACPI. This is a SoC-specific conversion and cannot
> be handled by generic code, so add a new IRQ method to do the conversion.
>
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a new file to handle generating ACPI code programatically. This is
> used when information must be dynamically added to the tables, e.g. the
> SSDT.
>
> Initial support is just for writing simple values. Also add a 'base'
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> At present U-Boot does not support the different ACPI status values, but
> it is best to put this logic in a central place. Add a function to get the
> device status.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
>
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Add a -c option to mtrr to allow any CPU to be updated with this command.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> cmd/x86/mtrr.c | 18 --
> 1 file changed, 16
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> At present do_mtrr() does the 'list' subcommand at the top and the rest
> below. Update it to do them all in the same place so we can (in a later
> patch) add parsing of the CPU number for all subcommands.
>
> Signed-off-by: Simon Glass
>
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Add a description of how this module works and also some missing function
> comments.
>
> Drop struct cpu_map since it is not used.
"struct cpu_map" was already dropped in patch "[v2,10/25] x86: mp:
Support APs waiting for
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Use the multi-CPU calls to set the MTRR values. This still supports only
> the boot CPU for now.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v2:
> - Drop the renamed mtrr_set_valid_() instead of
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> To enable support for the 'mtrr' command, add a way to perform MTRR
> operations on selected CPUs.
>
> This works by setting up a little 'operation' structure and sending it
> around the CPUs for action.
>
> Signed-off-by: Simon Glass
> ---
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> When the boot CPU MTRRs are updated, perform the same update on all other
> CPUs so they are kept in sync.
>
> This avoids kernel warnings about mismatched MTRRs.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
>
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> SMP should be set up in U-Boot where possible, not SPL. Disable it in SPL.
> For 64-bit U-Boot we should find a way to allow SMP operations in U-Boot,
> but this is somewhat more complicated. For now that is disabled too.
>
> Signed-off-by:
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> This currently excludes the temporary memory used to start up the APs.
> Add it.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add new patch to add AP_DEFAULT_BASE to coral's memory map
>
>
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Update the mtrr command to use mp_run_on_cpus() to obtain its information.
> Since the selected CPU is the boot CPU this does not change the result,
> but it sets the stage for supporting other CPUs.
>
> Signed-off-by: Simon Glass
>
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> It is convenient to iterate through the CPUs performing work on each one
> and processing the result. Add a few iterator functions which handle this.
> These can be used by any client code. It can call mp_run_on_cpus() on
> each
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Set this flag so we can track when it is safe to use CPUs other than the
> main one.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/mp_init.c | 1 +
> 1 file changed, 1
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> With the new MP features the CPUs are no-longer parked when the OS is run.
> Fix this by calling a special function to park them, just before the OS is
> started.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
>
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Add a way to run a function on a selection of CPUs. This supports either
> a single CPU, all CPUs, just the main CPU or just the 'APs', in Intel
> terminology.
>
> It works by writing into a mailbox and then waiting for the CPUs to
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Allow keeping track of whether all CPUs have been enabled yet. This allows
> us to know whether other CPUs need to be considered when updating
> CPU-specific settings such as MTRRs on x86.
>
> Signed-off-by: Simon Glass
>
1 - 100 of 105 matches
Mail list logo
