Re: Fixing low-speed USB keyboard detection
Hello Soeren! It will take me some time to prepare a proper patch, I just found the documentation of your patman tool. I am using Guix and created a package definition for U-Boot with these three fixes using regexp substitutions. My time is quite limited for this weekend. I guess that you would be much faster preparing these three simple changes as a patch. So I would be glad, if you prepare a patch. A proper commit message could be this: “This patch works around issues of low-speed USB keyboards with the dwc2 USB interface. There was a need to press a key when "USB0: scanning bus 0 for devices..." was printed or otherwise there was the error "Timeout poll on interrupt endpoint" and the keyboard was not usable. This patch reverts the workaround from 5da2dc9789abecb1b018beb0c93f4c38c2985bc6 for non-working keyboards.” Stefan > Am 29.02.2020 um 13:04 schrieb Soeren Moch : > > > > On 29.02.20 00:46, Marek Vasut wrote: >> On 2/26/20 12:04 PM, Soeren Moch wrote: >>> Adding Marek as USB maintainer. Otherwise this non-patch-email may get >>> lost when sent to the mailing list only. >> Well, can you send these as proper patches ? > Well, I can try to make a proposal for patches. But I cannot test > something since I neither own such D-Link DBT-120 Bluetooth Adapter, nor > a Raspberry Pi 3b as host system. I'm also not familiar with the details > of event polling / interrupt message NYET handling in u-boot, so > probably will not come up with a good commit message about this. I also > cannot judge which workaround or revert of such is appropriate. > > Stefan, can you convert your fixes to proper patches yourself, or do you > want me to send a first proposal? > > Thanks, > Soeren >> >>> Soeren >>> >>> On 25.02.20 18:45, Stefan wrote: Hello! I own a D-Link DBT-120 Bluetooth Adapter, which has a CSR firmware running in a so called “HID proxy mode”. This firmware pretends to be a USB keyboard (and mouse) and thus allows to use a Bluetooth keyboard in U-Boot. Unfortunately it acts as a low-speed device and there seems to be some well known troubles about low-speed USB keyboards. There is a FAQ entry for openSUSE about this: https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux I spend some effort to solve this issue. There are three tiny changes to get my Bluetooth keyboard working reliably as a low-speed USB keyboard. >> [...] > >
Re: [PATCH v5 23/33] spi: dw: Properly set rx_end when not recieving
This patch should not be included. I meant to remove it (and it gets reverted in the next patch), but I made an error during rebasing. Sorry for any confustion. --Sean
wrong email alias for Maxime Ripard
Hi, When I use patman, my MTA fails sending to one resolved email address - this entry in file `git-mailrc`: Maxime Ripard File `board/sunxi/MAINTAINERS` contains this different entry: Maxime Ripard Should `git-mailrc` be updated to match `board/sunxi/MAINTAINERS`, or am I using patman wrong somehow? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
[PATCH v2 2/2] sun50i: a64: A64-Teres-I board detect builtin keyboard
A64-Teres-I board is a laptop which comes with a builtin keyboard. The keyboard+trackpad controller pauses for 2 seconds at a firmware prompt before loading its HID interface. U-Boot needs to wait equally long to reliably enable the keyboard. Tested-by: Jonas Smedegaard Signed-off-by: Jonas Smedegaard Series-Cc: Jagan Teki --- Changes in v2: - (none) --- configs/teres_i_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/teres_i_defconfig b/configs/teres_i_defconfig index 1019dab54a..61bbf76b1e 100644 --- a/configs/teres_i_defconfig +++ b/configs/teres_i_defconfig @@ -8,6 +8,7 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_USB1_VBUS_PIN="PL7" CONFIG_I2C0_ENABLE=y CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="setenv usb_pgood_delay 2000; usb reset" # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-teres-i" -- 2.25.1
[PATCH v2 1/2] sunxi: fix support board-specific CONFIG_PREBOOT
commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to
Kconfig") intended to support CONFIG_PREBOOT, but
include/configs/sunxi-common.h hardcodes preboot as part of internally
defined CONSOLE_STDIN_SETTINGS, silently ignoring any board-specific
CONFIG_PREBOOT.
Simply moving CONFIG_PREBOOT to Kconfig does not work here,
as that would loose the logic of implicitly setting a conditional default.
This commit implements support for explicit CONFIG_PREBOOT for sunxi boards,
while keeping as fallback the implicity default preboot value.
Tested-by: Jonas Smedegaard
Signed-off-by: Jonas Smedegaard
Series-Cc: Jagan Teki
---
Changes in v2:
- Rephrase commit message to clarify relationship with KConfig entries
---
include/configs/sunxi-common.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0ef289fd64..5edde29d1c 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -428,8 +428,13 @@ extern int soft_i2c_gpio_scl;
#include
#ifdef CONFIG_USB_KEYBOARD
+#ifdef CONFIG_USE_PREBOOT
+#ifndef CONFIG_PREBOOT
+#define CONFIG_PREBOOT \
+ "usb start"
+#endif
+#endif
#define CONSOLE_STDIN_SETTINGS \
- "preboot=usb start\0" \
"stdin=serial,usbkbd\0"
#else
#define CONSOLE_STDIN_SETTINGS \
--
2.25.1
Re: Fixing low-speed USB keyboard detection
On 29.02.20 00:46, Marek Vasut wrote: > On 2/26/20 12:04 PM, Soeren Moch wrote: >> Adding Marek as USB maintainer. Otherwise this non-patch-email may get >> lost when sent to the mailing list only. > Well, can you send these as proper patches ? Well, I can try to make a proposal for patches. But I cannot test something since I neither own such D-Link DBT-120 Bluetooth Adapter, nor a Raspberry Pi 3b as host system. I'm also not familiar with the details of event polling / interrupt message NYET handling in u-boot, so probably will not come up with a good commit message about this. I also cannot judge which workaround or revert of such is appropriate. Stefan, can you convert your fixes to proper patches yourself, or do you want me to send a first proposal? Thanks, Soeren > >> Soeren >> >> On 25.02.20 18:45, Stefan wrote: >>> Hello! >>> >>> I own a D-Link DBT-120 Bluetooth Adapter, which has a CSR firmware running >>> in a so called “HID proxy mode”. This firmware pretends to be a USB >>> keyboard (and mouse) and thus allows to use a Bluetooth keyboard in U-Boot. >>> >>> Unfortunately it acts as a low-speed device and there seems to be some well >>> known troubles about low-speed USB keyboards. There is a FAQ entry for >>> openSUSE about this: >>> https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux >>> >>> I spend some effort to solve this issue. There are three tiny changes to >>> get my Bluetooth keyboard working reliably as a low-speed USB keyboard. > [...]
Re: [PATCH 1/2] common: fdt: Add a function for reserving memory without kernel linear mapping
Hi
On Wed, Feb 26, 2020 at 4:33 PM Simon Glass wrote:
>
> Hi Michael,
>
> On Mon, 24 Feb 2020 at 22:10, Michael Trimarchi
> wrote:
> >
> > The intent is to reserve memory _and_ prevent it from being included
> > in the kernel's linear map. For thos reason it is also necessary to include
> > the
> > 'no-map' property for this reserved-mem node.
> >
> > From Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt:
> >
> > no-map (optional) - empty property
> > - Indicates the operating system must not create a virtual mapping
> > of the region as part of its standard mapping of system memory,
> > nor permit speculative access to it under any circumstances other
> > than under the control of the device driver using the region.
> >
> > Signed-off-by: Michael Trimarchi
> > ---
> > Changes: RFC->v1
> > - Add a better commit message
> > ---
> > common/fdt_support.c | 40
> > include/fdt_support.h | 11 +++
> > 2 files changed, 51 insertions(+)
> >
> > diff --git a/common/fdt_support.c b/common/fdt_support.c
> > index 02cf5c6241..a3662f4358 100644
> > --- a/common/fdt_support.c
> > +++ b/common/fdt_support.c
> > @@ -410,6 +410,46 @@ static int fdt_pack_reg(const void *fdt, void *buf,
> > u64 *address, u64 *size,
> > return p - (char *)buf;
> > }
> >
> > +int fdt_fixup_reserved_memory(void *blob, const char *area, u64 start[],
> > u64 size[])
> > +{
> > + int offs, len;
> > + const char *subpath;
> > + const char *path = "/reserved-memory";
> > + fdt32_t address_cells = cpu_to_fdt32(fdt_address_cells(blob, 0));
> > + fdt32_t size_cells = cpu_to_fdt32(fdt_size_cells(blob, 0));
> > + u8 temp[16]; /* Up to 64-bit address + 64-bit size */
> > +
> > + offs = fdt_path_offset(blob, path);
> > + if (offs < 0) {
> > + debug("Node %s not found\n", path);
> > + path = "/";
> > + subpath = "reserved-memory";
> > + offs = fdt_path_offset(blob, path);
>
> Error check
>
Ok
> > + offs = fdt_add_subnode(blob, offs, subpath);
> > + if (offs < 0) {
> > + printf("Could not create %s%s node.\n", path,
> > subpath);
> > + return -1;
> > + }
> > + path = "/reserved-memory";
> > + offs = fdt_path_offset(blob, path);
> > +
> > + fdt_setprop(blob, offs, "#address-cells", _cells,
> > sizeof(address_cells));
> > + fdt_setprop(blob, offs, "#size-cells", _cells,
> > sizeof(size_cells));
> > + fdt_setprop(blob, offs, "ranges", NULL, 0);
>
> Need error-checking on these three
>
ok
> > + }
> > +
> > + offs = fdt_add_subnode(blob, offs, area ? : "private");
>
> Is this in a binding file somewhere?
>
The reserved memory is needed to avoid the linux kernel to use it and
to get a persistent framebuffer. On some SoC I have implemented the
reuse on the memory on their graphics driver. I need to check how this
is
documented in Linux. The name of the reserved memory it's not mandatory.
> > + if (offs < 0) {
> > + printf("Could not create %s%s node.\n", path, subpath);
> > + return -1;
>
> return offs
>
ok
> > + }
> > +
> > + fdt_setprop(blob, offs, "no-map", NULL, 0);
>
> and this?
>
ok
> Also needs error check
>
> > + len = fdt_pack_reg(blob, temp, start, size, 1);
> > + fdt_setprop(blob, offs, "reg", temp, len);
>
> blank line before return
>
done
> > + return 0;
> > +}
> > +
> > #if CONFIG_NR_DRAM_BANKS > 4
> > #define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
> > #else
> > diff --git a/include/fdt_support.h b/include/fdt_support.h
> > index ba14acd7f6..7c8a280f53 100644
> > --- a/include/fdt_support.h
> > +++ b/include/fdt_support.h
> > @@ -93,6 +93,17 @@ void do_fixup_by_compat_u32(void *fdt, const char
> > *compat,
> > */
> > int fdt_fixup_memory(void *blob, u64 start, u64 size);
> >
> > +/**
> > + * Setup the memory reserved node in the DT. Creates one if none was
> > existing before.
> > + *
> > + * @param blob FDT blob to update
> > + * @param area Reserved area name
> > + * @param startBegin of DRAM mapping in physical memory
> > + * @param size Size of the single memory bank
> > + * @return 0 if ok, or -1 or -FDT_ERR_... on error
>
> Really we should return an FDT_ERR always. -1 is not a good idea and
> in fact is an FDT_ERR
>
Now with the change FDT_ERR only is returned.
> > + */
> > +int fdt_fixup_reserved_memory(void *blob, const char *area, u64 start[],
> > u64 size[]);
> > +
> > /**
> > * Fill the DT memory node with multiple memory banks.
> > * Creates the node if none was existing before.
> > --
> > 2.17.1
> >
>
> Regards,
> Simon
I will post a new one
Michael
Re: [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading
Hi Simon,
On Wed, Feb 19, 2020 at 10:46 AM Simon Glass wrote:
>
> It is useful to be able to boot the same x86 image on a device with or
> without a first-stage bootloader. For example, with chromebook_coral, it
> is helpful for testing to be able to boot the same U-Boot (complete with
> FSP) on bare metal and from coreboot. It allows checking of things like
> CPU speed, comparing registers, ACPI tables and the like.
>
> When U-Boot is not the first-stage bootloader much of this code is not
> needed and can break booting. Add checks for this to the FSP code.
>
> Rather than checking for the amount of available SDRAM, just use 1GB in
> this situation, which should be safe. Using 2GB may run into a memory
> hole on some SoCs.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/lib/fsp/fsp_dram.c | 8
> arch/x86/lib/fsp/fsp_graphics.c | 3 +++
> arch/x86/lib/fsp2/fsp_dram.c| 10 ++
> arch/x86/lib/fsp2/fsp_init.c| 2 +-
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> index 9ce0ddf0d3..15e82de2fe 100644
> --- a/arch/x86/lib/fsp/fsp_dram.c
> +++ b/arch/x86/lib/fsp/fsp_dram.c
> @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> phys_addr_t low_end;
> uint bank;
>
> + if (!ll_boot_init()) {
> + gd->bd->bi_dram[0].start = 0;
> + gd->bd->bi_dram[0].size = gd->ram_size;
> +
> + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> + return 0;
> + }
> +
> low_end = 0;
> for (bank = 1, hdr = gd->arch.hob_list;
> bank < CONFIG_NR_DRAM_BANKS && !end_of_hob(hdr);
> diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c
> index 226c7e66b3..98b762209f 100644
> --- a/arch/x86/lib/fsp/fsp_graphics.c
> +++ b/arch/x86/lib/fsp/fsp_graphics.c
> @@ -78,6 +78,9 @@ static int fsp_video_probe(struct udevice *dev)
> struct vesa_mode_info *vesa = _info.vesa;
> int ret;
>
> + if (!ll_boot_init())
> + return 0;
> +
> printf("Video: ");
>
> /* Initialize vesa_mode_info structure */
> diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c
> index 90a238a224..74835eebce 100644
> --- a/arch/x86/lib/fsp2/fsp_dram.c
> +++ b/arch/x86/lib/fsp2/fsp_dram.c
> @@ -12,11 +12,18 @@
> #include
> #include
> #include
> +#include
>
> int dram_init(void)
> {
> int ret;
>
> + if (!ll_boot_init()) {
> + /* Use a small and safe amount of 1GB */
> + gd->ram_size = SZ_1G;
> +
> + return 0;
> + }
> if (spl_phase() == PHASE_SPL) {
> #ifdef CONFIG_HAVE_ACPI_RESUME
> bool s3wake = gd->arch.prev_sleep_state == ACPI_S3;
> @@ -68,6 +75,9 @@ int dram_init(void)
>
> ulong board_get_usable_ram_top(ulong total_size)
> {
> + if (!ll_boot_init())
> + return gd->ram_size;
> +
> #if CONFIG_IS_ENABLED(HANDOFF)
> struct spl_handoff *ho = gd->spl_handoff;
>
> diff --git a/arch/x86/lib/fsp2/fsp_init.c b/arch/x86/lib/fsp2/fsp_init.c
> index da9bd6b45c..c7dc2ea257 100644
> --- a/arch/x86/lib/fsp2/fsp_init.c
> +++ b/arch/x86/lib/fsp2/fsp_init.c
> @@ -23,7 +23,7 @@ int arch_cpu_init_dm(void)
> int ret;
>
> /* Make sure pads are set up early in U-Boot */
> - if (spl_phase() != PHASE_BOARD_F)
> + if (!ll_boot_init() || spl_phase() != PHASE_BOARD_F)
> return 0;
>
> /* Probe all pinctrl devices to set up the pads */
> --
I assume the proposed ll_boot_init() debug only works with FSP2, right?
I still would like to use the gd->flags instead of ll_boot_init().
Besides, I think the x86 doc need be updated to describe the purpose
and usage, using one board as an example.
Regards,
Bin
Pull request for UEFI sub-system for efi-2020-04-rc4 (2)
The following changes since commit 12fdbbe860f395575f360f0c03d84bce61a9a212:
Merge tag 'ti-v2020.04-rc4' of
https://gitlab.denx.de/u-boot/custodians/u-boot-ti (2020-02-27 08:51:01
-0500)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-04-rc4-2
for you to fetch changes up to 71a7de4467030362ef2582c355c086eb5fc4143f:
doc/efi: add load file 2 protocol to HTML documentation (2020-02-28
19:37:14 +0100)
Pull request for UEFI sub-system for efi-2020-04-rc4 (2)
In Linux next-20200228 patches have been merged to load an initial
ramdisk using an EFI_LOAD_FILE2_PROTOCOL provided by the firmware. See
commit ec93fc371f01 ("efi/libstub: Add support for loading the initrd
from a device path"). The idea behind it is that the firmware should be
responsible for validating the initrd in a secure boot setup.
This pull-request comprises a patch series which let's U-Boot provide an
initial implementation of the EFI_LOAD_FILE2_PROTOCOL providing the initrd.
Heinrich Schuchardt (1):
doc/efi: add load file 2 protocol to HTML documentation
Ilias Apalodimas (2):
efi_loader: Implement FileLoad2 for initramfs loading
efi_selftest: add selftests for loadfile2 used to load initramfs
cmd/efidebug.c | 4 +
doc/api/efi.rst | 9 ++
doc/uefi/uefi.rst | 12 ++
include/efi_api.h | 17 +++
include/efi_load_initrd.h | 25
include/efi_loader.h| 1 +
lib/efi_loader/Kconfig | 15 ++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_load_initrd.c| 198
+
lib/efi_loader/efi_setup.c | 5 +
lib/efi_selftest/Makefile | 1 +
lib/efi_selftest/efi_selftest_load_initrd.c | 220
12 files changed, 508 insertions(+)
create mode 100644 include/efi_load_initrd.h
create mode 100644 lib/efi_loader/efi_load_initrd.c
create mode 100644 lib/efi_selftest/efi_selftest_load_initrd.c
