April 2020 - U-Boot

Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
by Rick Chen 18 Apr '20

18 Apr '20

<rick(a)andestech.com> 於 2020年4月17日週五上午8:39寫道： > > > > -----Original Message----- > From: Atish Patra [mailto:atishp@atishpatra.org] > Sent: Wednesday, April 15, 2020 7:18 AM > To: Bin Meng > Cc: Ard Biesheuvel; Heinrich Schuchardt; U-Boot Mailing List; Anup Patel; Lukas Auer; Alexander Graf; Rick Jian-Zhi Chen(陳建志); Palmer Dabbelt > Subject: Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI > > On Mon, Apr 13, 2020 at 3:42 PM Bin Meng <bmeng.cn(a)gmail.com> wrote: > > > > Hi Atish, > > > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra <atishp(a)atishpatra.org> wrote: > > > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra <atishp(a)atishpatra.org> wrote: > > > > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > > > <ard.biesheuvel(a)linaro.org> wrote: > > > > > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt <xypron.glpk(a)gmx.de> wrote: > > > > > > > > > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote: > > > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra <atish.patra(a)wdc.com> wrote: > > > > > > >> > > > > > > >> This series adds few DT related fixes required for Linux > > > > > > >> EFI stub to work on RISC-V. > > > > > > >> > > > > > > > > > > > > > > I'm not sure how this is supposed to work, since DT reserved > > > > > > > memory regions are not used by EFI. If you want to reserve > > > > > > > memory on a UEFI system, you have to reserve it in the UEFI memory map from firmware. > > > > > > > The DT reserved-memory node is taken into account too late, > > > > > > > the /memreserve/ entries are ignored entirely. > > > > > > > > > > > > Hello Ard, > > > > > > > > > > > > thanks for reviewing. > > > > > > > > > > > > What do you mean by "The DT reserved-memory node is taken into > > > > > > account too late"? > > > > > > > > > > > > Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory > > > > > > node from DT") > > > > > > > > > > > > > > > > What I mean is that the EFI stub in Linux uses memory allocation > > > > > functions, expecting the firmware to ensure that those > > > > > allocations do not conflict with memory descriptions and > > > > > reservations in DT. So if the firmware wants to express this > > > > > redundantly, by passing reservations in both reserved-memory and > > > > > in the EFI memory map, that is probably fine. > > > > > > > > > > Also, I must sheepishly admit that I only realize now that this > > > > > patch set is against u-boot not Linux :-) > > > > > > > > > :) > > > > > > > > > So if fixed reserved-memory regions are only being used to seed > > > > > the reserved regions in the EFI memory map, you can safely ignore me. > > > > > > > > Yeah. That's the purpose. Having reserved memory nodes in the > > > > final DT used by linux also ensures that proper Linux adds a > > > > reserved memory block or removes it from memblock entries > > > > depending on "no-map" property. > > > > > > > > > Apologies for the noise. > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > Atish > > > > > > Any other comments on the series ? It would be great if this series > > > could be merged before > > > v2020.07 release. > > > > I hope so if no one objects the proposed solution here in U-Boot vs. > > the PMP SBI extension. I need have another look at the latest version > > of patches though. > > > > Thanks. As far as I know, there is no opposition to the current approach adopted in U-Boot. > I am hoping EFI stub series can be merged before 5.8. If this series can go in v2020.07, RISC-V will have all required support to boot via EFI from Linux kernel v5.8 and U-Boot v2020.07. OK! I will pull and send a PR ASAP. Thanks, Rick

3 6

[PATCH] net: tulip: Remove CONFIG_TULIP_*
by Marek Vasut 18 Apr '20

18 Apr '20

These macros are not used by any board, remove them to simplify the driver. The EEPROM accessors are still retained however, as those might still be useful. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)gmail.com> Cc: Joe Hershberger <joe.hershberger(a)ni.com> --- README | 2 - drivers/net/dc2114x.c | 88 ++---------------------------------- scripts/config_whitelist.txt | 3 -- 3 files changed, 5 insertions(+), 88 deletions(-) diff --git a/README b/README index 19dae14ac0..aeae97d50f 100644 --- a/README +++ b/README @@ -896,8 +896,6 @@ The following options need to be configured: CONFIG_TULIP Support for Digital 2114x chips. - Optional CONFIG_TULIP_SELECT_MEDIA for board specific - modem chip initialisation (KS8761/QS6611). CONFIG_NATSEMI Support for National dp83815 chips. diff --git a/drivers/net/dc2114x.c b/drivers/net/dc2114x.c index 43c2253f10..40bfc5281b 100644 --- a/drivers/net/dc2114x.c +++ b/drivers/net/dc2114x.c @@ -77,15 +77,6 @@ #define POLL_DEMAND 1 -#ifdef CONFIG_TULIP_FIX_DAVICOM -#define RESET_DM9102(dev) {\ - unsigned long i;\ - i=INL(dev, 0x0);\ - udelay(1000);\ - OUTL(dev, i | BMR_SWR, DE4X5_BMR);\ - udelay(1000);\ -} -#else #define RESET_DE4X5(dev) {\ int i;\ i=INL(dev, DE4X5_BMR);\ @@ -97,7 +88,6 @@ for (i=0;i<5;i++) {INL(dev, DE4X5_BMR); udelay(10000);}\ udelay(1000);\ } -#endif #define START_DE4X5(dev) {\ s32 omr; \ @@ -114,11 +104,7 @@ } #define NUM_RX_DESC PKTBUFSRX -#ifndef CONFIG_TULIP_FIX_DAVICOM - #define NUM_TX_DESC 1 /* Number of TX descriptors */ -#else - #define NUM_TX_DESC 4 -#endif +#define NUM_TX_DESC 1 /* Number of TX descriptors */ #define RX_BUFF_SZ PKTSIZE_ALIGN #define TOUT_LOOP 1000000 @@ -140,29 +126,22 @@ static int tx_new; /* TX descriptor ring pointer */ static char rxRingSize; static char txRingSize; -#if defined(UPDATE_SROM) || !defined(CONFIG_TULIP_FIX_DAVICOM) static void sendto_srom(struct eth_device* dev, u_int command, u_long addr); static int getfrom_srom(struct eth_device* dev, u_long addr); static int do_eeprom_cmd(struct eth_device *dev, u_long ioaddr,int cmd,int cmd_len); static int do_read_eeprom(struct eth_device *dev,u_long ioaddr,int location,int addr_len); -#endif /* UPDATE_SROM || !CONFIG_TULIP_FIX_DAVICOM */ #ifdef UPDATE_SROM static int write_srom(struct eth_device *dev, u_long ioaddr, int index, int new_value); static void update_srom(struct eth_device *dev, bd_t *bis); #endif -#ifndef CONFIG_TULIP_FIX_DAVICOM static int read_srom(struct eth_device *dev, u_long ioaddr, int index); static void read_hw_addr(struct eth_device* dev, bd_t * bis); -#endif /* CONFIG_TULIP_FIX_DAVICOM */ static void send_setup_frame(struct eth_device* dev, bd_t * bis); static int dc21x4x_init(struct eth_device* dev, bd_t* bis); static int dc21x4x_send(struct eth_device *dev, void *packet, int length); static int dc21x4x_recv(struct eth_device* dev); static void dc21x4x_halt(struct eth_device* dev); -#ifdef CONFIG_TULIP_SELECT_MEDIA -extern void dc21x4x_select_media(struct eth_device* dev); -#endif #if defined(CONFIG_E500) #define phys_to_bus(a) (a) @@ -183,9 +162,6 @@ static void OUTL(struct eth_device* dev, int command, u_long addr) static struct pci_device_id supported[] = { { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_TULIP_FAST }, { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21142 }, -#ifdef CONFIG_TULIP_FIX_DAVICOM - { PCI_VENDOR_ID_DAVICOM, PCI_DEVICE_ID_DAVICOM_DM9102A }, -#endif { } }; @@ -209,35 +185,22 @@ int dc21x4x_initialize(bd_t *bis) /* Get the chip configuration revision register. */ pci_read_config_dword(devbusfn, PCI_REVISION_ID, &cfrv); -#ifndef CONFIG_TULIP_FIX_DAVICOM if ((cfrv & CFRV_RN) < DC2114x_BRK ) { printf("Error: The chip is not DC21143.\n"); continue; } -#endif pci_read_config_word(devbusfn, PCI_COMMAND, &status); status |= -#ifdef CONFIG_TULIP_USE_IO - PCI_COMMAND_IO | -#else PCI_COMMAND_MEMORY | -#endif PCI_COMMAND_MASTER; pci_write_config_word(devbusfn, PCI_COMMAND, status); pci_read_config_word(devbusfn, PCI_COMMAND, &status); -#ifdef CONFIG_TULIP_USE_IO - if (!(status & PCI_COMMAND_IO)) { - printf("Error: Can not enable I/O access.\n"); - continue; - } -#else if (!(status & PCI_COMMAND_MEMORY)) { printf("Error: Can not enable MEMORY access.\n"); continue; } -#endif if (!(status & PCI_COMMAND_MASTER)) { printf("Error: Can not enable Bus Mastering.\n"); @@ -251,15 +214,9 @@ int dc21x4x_initialize(bd_t *bis) pci_write_config_byte(devbusfn, PCI_LATENCY_TIMER, 0x60); } -#ifdef CONFIG_TULIP_USE_IO - /* read BAR for memory space access */ - pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, &iobase); - iobase &= PCI_BASE_ADDRESS_IO_MASK; -#else /* read BAR for memory space access */ pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_1, &iobase); iobase &= PCI_BASE_ADDRESS_MEM_MASK; -#endif debug ("dc21x4x: DEC 21142 PCI Device @0x%x\n", iobase); dev = (struct eth_device*) malloc(sizeof *dev); @@ -270,17 +227,9 @@ int dc21x4x_initialize(bd_t *bis) } memset(dev, 0, sizeof(*dev)); -#ifdef CONFIG_TULIP_FIX_DAVICOM - sprintf(dev->name, "Davicom#%d", card_number); -#else sprintf(dev->name, "dc21x4x#%d", card_number); -#endif -#ifdef CONFIG_TULIP_USE_IO - dev->iobase = pci_io_to_phys(devbusfn, iobase); -#else dev->iobase = pci_mem_to_phys(devbusfn, iobase); -#endif dev->priv = (void*) devbusfn; dev->init = dc21x4x_init; dev->halt = dc21x4x_halt; @@ -292,9 +241,8 @@ int dc21x4x_initialize(bd_t *bis) udelay(10 * 1000); -#ifndef CONFIG_TULIP_FIX_DAVICOM read_hw_addr(dev, bis); -#endif + eth_register(dev); card_number++; @@ -311,46 +259,28 @@ static int dc21x4x_init(struct eth_device* dev, bd_t* bis) /* Ensure we're not sleeping. */ pci_write_config_byte(devbusfn, PCI_CFDA_PSM, WAKEUP); -#ifdef CONFIG_TULIP_FIX_DAVICOM - RESET_DM9102(dev); -#else RESET_DE4X5(dev); -#endif if ((INL(dev, DE4X5_STS) & (STS_TS | STS_RS)) != 0) { printf("Error: Cannot reset ethernet controller.\n"); return -1; } -#ifdef CONFIG_TULIP_SELECT_MEDIA - dc21x4x_select_media(dev); -#else OUTL(dev, OMR_SDP | OMR_PS | OMR_PM, DE4X5_OMR); -#endif for (i = 0; i < NUM_RX_DESC; i++) { rx_ring[i].status = cpu_to_le32(R_OWN); rx_ring[i].des1 = cpu_to_le32(RX_BUFF_SZ); rx_ring[i].buf = cpu_to_le32( phys_to_bus((u32)net_rx_packets[i])); -#ifdef CONFIG_TULIP_FIX_DAVICOM - rx_ring[i].next = cpu_to_le32( - phys_to_bus((u32)&rx_ring[(i + 1) % NUM_RX_DESC])); -#else rx_ring[i].next = 0; -#endif } for (i=0; i < NUM_TX_DESC; i++) { tx_ring[i].status = 0; tx_ring[i].des1 = 0; tx_ring[i].buf = 0; - -#ifdef CONFIG_TULIP_FIX_DAVICOM - tx_ring[i].next = cpu_to_le32(phys_to_bus((u32) &tx_ring[(i+1) % NUM_TX_DESC])); -#else tx_ring[i].next = 0; -#endif } rxRingSize = NUM_RX_DESC; @@ -520,9 +450,7 @@ Done: return; } -#if defined(UPDATE_SROM) || !defined(CONFIG_TULIP_FIX_DAVICOM) -/* SROM Read and write routines. - */ +/* SROM Read and write routines. */ static void sendto_srom(struct eth_device* dev, u_int command, u_long addr) { @@ -594,13 +522,12 @@ static int do_read_eeprom(struct eth_device *dev, u_long ioaddr, int location, i return retval; } -#endif /* UPDATE_SROM || !CONFIG_TULIP_FIX_DAVICOM */ -/* This executes a generic EEPROM command, typically a write or write +/* + * This executes a generic EEPROM command, typically a write or write * enable. It returns the data output from the EEPROM, and thus may * also be used for reads. */ -#if defined(UPDATE_SROM) || !defined(CONFIG_TULIP_FIX_DAVICOM) static int do_eeprom_cmd(struct eth_device *dev, u_long ioaddr, int cmd, int cmd_len) { unsigned retval = 0; @@ -636,9 +563,7 @@ static int do_eeprom_cmd(struct eth_device *dev, u_long ioaddr, int cmd, int cmd return retval; } -#endif /* UPDATE_SROM || !CONFIG_TULIP_FIX_DAVICOM */ -#ifndef CONFIG_TULIP_FIX_DAVICOM static int read_srom(struct eth_device *dev, u_long ioaddr, int index) { int ee_addr_size = do_read_eeprom(dev, ioaddr, 0xff, 8) & 0x40000 ? 8 : 6; @@ -647,7 +572,6 @@ static int read_srom(struct eth_device *dev, u_long ioaddr, int index) (((SROM_READ_CMD << ee_addr_size) | index) << 16) | 0xffff, 3 + ee_addr_size + 16); } -#endif /* CONFIG_TULIP_FIX_DAVICOM */ #ifdef UPDATE_SROM static int write_srom(struct eth_device *dev, u_long ioaddr, int index, int new_value) @@ -695,7 +619,6 @@ static int write_srom(struct eth_device *dev, u_long ioaddr, int index, int new_ } #endif -#ifndef CONFIG_TULIP_FIX_DAVICOM static void read_hw_addr(struct eth_device *dev, bd_t *bis) { u_short tmp, *p = (u_short *)(&dev->enetaddr[0]); @@ -721,7 +644,6 @@ Done: #endif return; } -#endif /* CONFIG_TULIP_FIX_DAVICOM */ #ifdef UPDATE_SROM static void update_srom(struct eth_device *dev, bd_t *bis) diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 7e08c563cd..7e784b1c96 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4079,9 +4079,6 @@ CONFIG_TSECV2_1 CONFIG_TSEC_TBI CONFIG_TSEC_TBICR_SETTINGS CONFIG_TULIP -CONFIG_TULIP_FIX_DAVICOM -CONFIG_TULIP_SELECT_MEDIA -CONFIG_TULIP_USE_IO CONFIG_TWL6030_INPUT CONFIG_TWL6030_POWER CONFIG_TWR -- 2.25.1

1 0

[PATCH] net: pcnet: Remove CONFIG_PCNET_79C97x
by Marek Vasut 18 Apr '20

18 Apr '20

These macros guard one switch-case statement, which grows mips malta by some 20 bytes if debug is enabled, and even less if it is not. To make the code simpler, just support all the NICs and be done with it. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)gmail.com> Cc: Joe Hershberger <joe.hershberger(a)ni.com> --- drivers/net/pcnet.c | 8 -------- include/configs/malta.h | 1 - scripts/config_whitelist.txt | 2 -- 3 files changed, 11 deletions(-) diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c index b4ad11d3fa..59241c95bc 100644 --- a/drivers/net/pcnet.c +++ b/drivers/net/pcnet.c @@ -21,10 +21,6 @@ #define PCNET_DEBUG2(fmt,args...) \ debug_cond(PCNET_DEBUG_LEVEL > 1, fmt ,##args) -#if !defined(CONF_PCNET_79C973) && defined(CONF_PCNET_79C975) -#error "Macro for PCnet chip version is not defined!" -#endif - /* * Set the number of Tx and Rx buffers, using Log_2(# buffers). * Reasonable default values are 4 Tx buffers, and 16 Rx buffers. @@ -254,16 +250,12 @@ static int pcnet_probe(struct eth_device *dev, bd_t *bis, int dev_nr) case 0x2621: chipname = "PCnet/PCI II 79C970A"; /* PCI */ break; -#ifdef CONFIG_PCNET_79C973 case 0x2625: chipname = "PCnet/FAST III 79C973"; /* PCI */ break; -#endif -#ifdef CONFIG_PCNET_79C975 case 0x2627: chipname = "PCnet/FAST III 79C975"; /* PCI */ break; -#endif default: printf("%s: PCnet version %#x not supported\n", dev->name, chip_version); diff --git a/include/configs/malta.h b/include/configs/malta.h index bb8a44433e..d41b80c7dc 100644 --- a/include/configs/malta.h +++ b/include/configs/malta.h @@ -16,7 +16,6 @@ #define CONFIG_PCI_GT64120 #define CONFIG_PCI_MSC01 #define CONFIG_PCNET -#define CONFIG_PCNET_79C973 #define PCNET_HAS_PROM #define CONFIG_SYS_ISA_IO_BASE_ADDRESS 0 diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 6908431d03..7e08c563cd 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -1295,8 +1295,6 @@ CONFIG_PCI_SYS_BUS CONFIG_PCI_SYS_PHYS CONFIG_PCI_SYS_SIZE CONFIG_PCNET -CONFIG_PCNET_79C973 -CONFIG_PCNET_79C975 CONFIG_PEN_ADDR_BIG_ENDIAN CONFIG_PERIF1_FREQ CONFIG_PERIF2_FREQ -- 2.25.1

1 0

[PATCH v2 00/28] buildman: Improve summary output
by Simon Glass 18 Apr '20

18 Apr '20

This series makes the output produced by buildman a little more useful and easier to read: - when using -l to see which errors relate to which board, it shows the boards in a different colour so they can be distinguished from the errors - uses yellow consistently for warning lines - shows the number of remaining builds - shows a summary when the build completes, including the time taken - adds a few messages to indicate what is happening while starting up It also refactors a few tests a little to make them easier to follow, makes -I the default and improves the documentation a little. Finally it changes the exit codes to something acceptable to git bisect. Changes in v2: - Move the 'boards' variables to the start of _CheckOutput() - Add new patch to use spaces in the board list - Drop use of temporary 'line' variable - Add new patch to ignore migration warnings - Add patch to udpate TODO items - Add new patch to change the exit codes Simon Glass (28): buildman: Refactor error-line output int a function buildman: Add test coverage for error/warning colour buildman: Use an iterator to check test output buildman: Create temp directory in test setup buildman: Split out testOutput() into separate functions buildman: Add a test helper for creating a line prefix buildman: Test the output with --list-error-boards buildman: Use yellow consistently for warning lines buildman: Use an object to hold error lines buildman: Show the list of boards in magenta buildman: Use spaces in the board list patman: Update flushing Print() for Python 3 patman: Support erasing a previously unfinished text line patman: Support limiting output to a single line buildman: Drop the line-clearing code in Builder buildman: Show a message when fetching a repo buildman: Drop unused output code buildman: Show the number of builds remaining buildman: Limit the length of progress messages buildman: Show a summary of the build result buildman: Update the 'theory of operation' a little buildman: Add the abbreviation for --boards buildman: Update workflow documentation with more detail buildman: Make -I the default buildman: Add an option to ignore device-tree warnings buildman: Add an option to ignore migration warnings buildman: Update the TODO items buildman: Change the exit codes tools/buildman/README | 171 +++++++++++------- tools/buildman/builder.py | 216 ++++++++++++++-------- tools/buildman/builderthread.py | 6 +- tools/buildman/cmdline.py | 11 +- tools/buildman/control.py | 22 ++- tools/buildman/func_test.py | 28 ++- tools/buildman/test.py | 305 +++++++++++++++++++++++--------- tools/patman/patman.py | 2 +- tools/patman/terminal.py | 110 +++++++++++- 9 files changed, 614 insertions(+), 257 deletions(-) -- 2.26.0.110.g2183baf09c-goog

2 56

[PATCH 1/1] imx: Kconfig: fix references to doc/README.mxc_hab
by Heinrich Schuchardt 17 Apr '20

17 Apr '20

doc/README.mxc_hab was moved to doc/imx/habv4/guides/encrypted_boot.txt by commit df11b0c4d4e3 ("doc: imx: reorganize i.MX documentation"), commit dfe9ff9cc79b ("doc: imx: hab: Reorganize High Assurance Boot documentation"), commit 8a23fc9c94bf ("doc: imx: habv4: Remove extra hab, directory for a cleaner documentation structure"), and commit 364c0a89bcfa ("doc: imx: habv4: Move encrypted boot guide"). Fixes: df11b0c4d4e3 ("doc: imx: reorganize i.MX documentation") Fixes: dfe9ff9cc79b ("doc: imx: hab: Reorganize High Assurance Boot documentation") Fixes: 8a23fc9c94bf ("doc: imx: habv4: Remove extra hab, directory for a cleaner documentation structure") Fixes: commit 364c0a89bcfa ("doc: imx: habv4: Move encrypted boot guide"). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- arch/arm/mach-imx/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index aa140c4798..44b47780ee 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -41,7 +41,7 @@ config IMX_HAB imply CMD_DEKBLOB help This option enables the support for secure boot (HAB). - See doc/README.mxc_hab for more details. + See doc/imx/habv4/guides/encrypted_boot.txt for more details. config CSF_SIZE hex "Maximum size for Command Sequence File (CSF) binary" @@ -69,8 +69,8 @@ config CMD_DEKBLOB help This enables the 'dek_blob' command which is used with the Freescale secure boot mechanism. This command encapsulates and - creates a blob of data. See also CMD_BLOB and doc/README.mxc_hab for - more information. + creates a blob of data. See also CMD_BLOB and + doc/imx/habv4/guides/encrypted_boot.txt for more information. config CMD_HDMIDETECT bool "Support the 'hdmidet' command" -- 2.20.1

4 11

[PATCH] README: remove requirement for CHANGELOG entry
by Karl Palsson 17 Apr '20

17 Apr '20

As indicated elsewhere in the README, the standalone CHANGELOG file was removed in 2010. Drop the instructions for creating patches on creating a standalone CHANGELOG entry. Signed-off-by: Karl Palsson <karlp(a)tweak.net.au> --- README | 2 -- 1 file changed, 2 deletions(-) diff --git a/README b/README index 8cfa92fac9..0f9578586f 100644 --- a/README +++ b/README @@ -4734,8 +4734,6 @@ it: * For new features: a description of the feature and your implementation. -* A CHANGELOG entry as plaintext (separate from the patch) - * For major contributions, add a MAINTAINERS file with your information and associated file and directory references. -- 2.21.1

2 1

[PATCH U-BOOT v2 0/3] fs: btrfs: Fix false LZO decompression error due to missing page boundary check
by Qu Wenruo 17 Apr '20

17 Apr '20

There is a bug that uboot can't load LZO compressed data extent while kernel can handle it without any problem. It turns out to be a page boundary case. The 3nd patch is the proper fix, cross-ported from btrfs-progs. The first patch is just to make my eyes less hurt. The second patch is to make sure the driver will reject sector size not matching PAGE_SIZE. This keeps the behavior the same as kernel, even in theory we could do better in U-boot. This is just a temporary fix, before better btrfs driver implemented. I guess it's time to backport proper code from btrfs-progs, other than using tons of immediate codes. Changelog: v2: - Fix code style problems - Add a new patch to reject non-page-sized sector size Since kernel does the same thing, and non-4K page size u-boot boards are really rare, it shouldn't be a big problem. Qu Wenruo (3): fs: btrfs: Use LZO_LEN to replace immediate number fs: btrfs: Reject fs with sector size other than PAGE_SIZE fs: btrfs: Fix LZO false decompression error caused by pending zero fs/btrfs/compression.c | 42 +++++++++++++++++++++++++++++++----------- fs/btrfs/super.c | 8 ++++++++ 2 files changed, 39 insertions(+), 11 deletions(-) -- 2.26.0

3 9

[PATCH v4 0/4] Ensure 16 alignment of reserved memory in board_f.c
by Patrick Delaunay 17 Apr '20

17 Apr '20

Hi, It is a V4 with only cosmetics udpate (s/insure/ensure) for the V3 serie: http://patchwork.ozlabs.org/project/uboot/list/?series=162918&state=* V2 was: http://patchwork.ozlabs.org/project/uboot/list/?series=154685&state=* After the first correction, only for bootstage alignment, I remove the stm32mp1 workaround in the 2nd patch. The 4th patch is a complete solution to alignment (proposed in comment 5 of http://patchwork.ozlabs.org/patch/1201452/#2327366) I always align the reserved memory to 16 bytes with a new function reserve_stack_aligned(). But this patch causes an issue on ARM 32 bits, as the relocated gd pointer is not initialized with gd->new_gd as expected now in reserve_global_data() but is hard-coded with: relocated gd = gd->bd - GD_SIZE {with GD_SIZE = sizeof(struct global_data)} After the 4rd patch, this assumption in not more true as sizeof(struct global_data) is not always 16 bytes aligned. This issue is solved with the 3rd patch of the serie arm: set the relocated gd with gd->new_gd Only tested on STM32MP157C-EV1 board (ARM32 architecture). Changes in v4: - replace insure by ensure in comment - replace insure by ensure Changes in v3: - rename reserve_sp to reserve_stack_aligned Changes in v2: - import: [U-Boot,v3] board_f.c: Insure gd->new_bootstage alignment - fix commit message s/bits/bytes/ Patrice Chotard (1): board_f.c: Ensure gd->new_bootstage alignment Patrick Delaunay (3): Revert "stm32mp1: remove the imply BOOTSTAGE" arm: set the relocated gd with gd->new_gd board_f.c: Ensure 16 alignment of start_addr_sp and reserved memory arch/arm/lib/crt0.S | 3 +-- arch/arm/mach-stm32mp/Kconfig | 2 ++ common/board_f.c | 27 ++++++++++++++++++--------- 3 files changed, 21 insertions(+), 11 deletions(-) -- 2.17.1

2 8

[PATCH 0/7] doc: Fix some errors pointed out by 'make refcheckdocs'
by Patrick Delaunay 17 Apr '20

17 Apr '20

Fix some errors pointed out by 'make refcheckdocs'. This target is available after Heinrich patch "scripts: add documentation-file-ref-check" http://patchwork.ozlabs.org/patch/1244498/ see also patches 1/ "doc: fix references to driver-model" http://patchwork.ozlabs.org/patch/1244504/ 2/ "Kconfig: fix typos in CMD_BEDBUG description" http://patchwork.ozlabs.org/patch/1244507/ 3/ "include/ata.h: remove invalid links" http://patchwork.ozlabs.org/patch/1244637/ After this serie the only remaining errors are: $> make refcheckdocs doc/sphinx/parse-headers.pl: doc/doc-guide/parse-headers.rst doc/sphinx/rstFlatTable.py: doc/books/kernel-doc-HOWTO drivers/rtc/ds1374.c: Watchdoc/Alarm include/fsl_qe.h: doc/README.qe_firmware lib/zlib/trees.c: ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc Patrick Delaunay (7): README: update reference to *.README Kconfig: update reference to README.x86 doc: update reference to README.imximage doc: update reference to README.imx8image doc: update reference to README.board doc: device-tree-bindings: update reference to binding directory arm: imx: update reference to README.mxc_hab Kconfig | 2 +- README | 2 +- arch/arm/mach-imx/Kconfig | 4 ++-- board/advantech/dms-ba16/dms-ba16_1g.cfg | 2 +- board/advantech/dms-ba16/dms-ba16_2g.cfg | 2 +- board/aristainetos/aristainetos2.cfg | 2 +- board/bachmann/ot1200/mx6q_4x_mt41j128.cfg | 2 +- board/barco/titanium/imximage.cfg | 2 +- board/boundary/nitrogen6x/nitrogen6dl.cfg | 2 +- board/boundary/nitrogen6x/nitrogen6dl2g.cfg | 2 +- board/boundary/nitrogen6x/nitrogen6q.cfg | 2 +- board/boundary/nitrogen6x/nitrogen6q2g.cfg | 2 +- board/boundary/nitrogen6x/nitrogen6s.cfg | 2 +- board/boundary/nitrogen6x/nitrogen6s1g.cfg | 2 +- board/ccv/xpress/imximage.cfg | 2 +- board/cobra5272/README | 2 +- board/freescale/imx8qxp_mek/imximage.cfg | 2 +- board/freescale/m52277evb/README | 2 +- board/freescale/m53017evb/README | 2 +- board/freescale/m5373evb/README | 2 +- board/freescale/m54455evb/README | 2 +- board/freescale/m547xevb/README | 2 +- board/freescale/mx25pdk/imximage.cfg | 2 +- board/freescale/mx51evk/imximage.cfg | 2 +- board/freescale/mx53ard/imximage_dd3.cfg | 2 +- board/freescale/mx53evk/imximage.cfg | 2 +- board/freescale/mx53loco/imximage.cfg | 2 +- board/freescale/mx53smd/imximage.cfg | 2 +- board/freescale/mx6qarm2/imximage.cfg | 2 +- board/freescale/mx6qarm2/imximage_mx6dl.cfg | 2 +- board/freescale/mx6slevk/imximage.cfg | 2 +- board/freescale/mx6ullevk/imximage.cfg | 2 +- board/freescale/mx7dsabresd/imximage.cfg | 2 +- board/freescale/s32v234evb/s32v234evb.cfg | 2 +- board/freescale/vf610twr/imximage.cfg | 2 +- board/ge/bx50v3/bx50v3.cfg | 2 +- board/ge/mx53ppd/imximage.cfg | 2 +- board/menlo/m53menlo/imximage.cfg | 2 +- board/phytec/pcm052/imximage.cfg | 2 +- board/seco/mx6quq7/mx6quq7-2g.cfg | 2 +- board/siemens/capricorn/imximage.cfg | 2 +- board/technexion/pico-imx6ul/imximage.cfg | 2 +- board/toradex/apalis-imx8/apalis-imx8qm-imximage.cfg | 2 +- board/toradex/colibri-imx6ull/imximage.cfg | 2 +- board/toradex/colibri-imx8x/colibri-imx8qxp-imximage.cfg | 2 +- board/toradex/colibri_imx7/imximage.cfg | 2 +- board/toradex/colibri_vf/imximage.cfg | 2 +- board/tqc/tqma6/clocks.cfg | 2 +- board/tqc/tqma6/tqma6dl.cfg | 2 +- board/tqc/tqma6/tqma6q.cfg | 2 +- board/tqc/tqma6/tqma6s.cfg | 2 +- board/warp/imximage.cfg | 2 +- board/warp7/imximage.cfg | 2 +- doc/device-tree-bindings/net/ti,dp83867.txt | 2 +- doc/device-tree-bindings/video/rockchip-lvds.txt | 2 +- doc/imx/misc/sdp.txt | 2 +- include/configs/sbc8548.h | 2 +- 57 files changed, 58 insertions(+), 58 deletions(-) -- 2.17.1

4 16

Network functionality in v2020.04 on Raspberry Pi 4
by Jevtic, Sasha 17 Apr '20

17 Apr '20

Hello all, I am encountering considerable difficulty with the networking functionality on Raspberry Pi 4 on the latest release (2020.04). In particular, I have observed: * any network operation that fails renders networking functionality inoperable until reboot. * ping always fails. * TFTP download attempt of non-existent file fails (resulting in subsequent network operations failing). * TFTP download of an existing file usually works, but occasionally experiences timeouts during transfers; some are timeouts are intermittent (the transfer ultimately resumes), and some are permanent. * TFTP download of a script usually works (as above). The script will run, but any additional TFTP downloads performed by a script all fail. It is not entirely clear right now whether this is a problem in U-Boot (i.e., instead of in the execution environment set up by the Raspberry Pi firmware), but the TFTP infrastructure I am using is known to work well with other hardware running an older version of U-Boot. Also, there are also no network issues in the Linux environment that I ultimately boot, so hardware also seems unlikely. Thus, suggestions for things to check would be appreciated; I am of course also happy to provide any supporting data required to investigate. Please also be aware that I initially posted a very similar inquiry to the Raspberry Pi Forum: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=271068 Thanks. Sasha

3 4