This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Older Armada SoCs have custom ARMv5te compatible core which does not
support movt instruction. So replace mov + movt instruction pair used for
immediate move construction by mov + orr instructions which are supported
also by ARMv5te.

After this change kwboot ARM code should be compatible with any 32-bit ARM
core compatible by ARMv2 or new. At least GNU AS does not throw any error
or warning.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Increase loop cycles from 600000 to 2998272, which should increase delay
from 1ms to about 5ms on 1200 MHz CPU.

The Number 2998272 was chosen as the nearest value around 3000000 which can
be encoded into one ARM mov instruction. It avoids usage of movt instruction
which is not supported by ARMv5te cores.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Kwboot puts each xmodem packet to kernel queue, then waits until all bytes
of that packet are transmitted over UART and then waits for xmodem reply
until it is received into kernel queue.

If some reply is received during the time we are waiting until all bytes
are transmitted, then kernel puts them into the queue and returns it to
kwboot in next read() call.

So there is no need to wait (with tcdrain() function) until all bytes from
xmodem packet are transmitted over UART, since any reply received either
during that time or after is returned to kwboot with the next read().

Therefore do not call tcdrain() after each xmodem packet sent. Instead
directly wait for any reply after putting xmodem packet into write kernel
queue.

This change could speed up xmodem transfer in case tcdrain() function waits
for a longer time.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

After the trasfer of last header packet, it is possible that baudrate
change pattern is received, and also that NAK byte is received so that
the packet should be sent again.

Thus we should not clear the baudrate change state when sending retry
of that packet.

Move code for initializing state variables from kwboot_xm_recv_reply()
to kwboot_xm_sendblock().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Currently when kwboot receive some garbage reply which does not understand,
it waits 1s before it tries to resend packet again.

The most common error on UART is that receiver sees some bit flipped which
results in invalid reply.

This behavior slows down xmodem transfer over UART as basically on every
error kwboot is waiting one second.

To fix this, try to resend xmodem packet for first 3 attempts immediately
without any delay. If broken reply is received also after the 3 attempts,
continue retrying with 1s delay like it was before.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

This patch does not change behavior of the code, just allows to implement
new changes more easily.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Size of the header stored in kwbimage may be larger than real used size in
the kwbimage header. If there is unused space in kwbimage header then use
it for growing it. So update code to calculate used space of kwbimage
header.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

This ensures that kwboot_img_grow_hdr() function still sees valid kwbimage
header.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Expression (hdrsz % KWBOOT_XM_BLKSZ) is non-zero therefore expression
(KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) is always less than value
KWBOOT_XM_BLKSZ. So there is no need to add another modulo. Also rename
variable `offset` to `grow` which better describes what is stored in
this variable.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

It is hard to debug why kwboot is failing when the last message is
'Finishing transfer' and no additional output. So show verbose message when
kwboot finished transfer and is waiting for baudrate change magic sequence.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

For kwbimage v1, tell BootROM to send BootROM messages to UART port number
0 (used also for UART booting) with default baudrate (which should be
115200) and do not touch UART MPP configuration.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

If data part of image is modified, update 4-byte data checksum.

It looks like A385 BootROM does not verify this checksum for image
loaded via UART, but we do not know if other BootROMs are also ignoring
it. It is always better to provide correct checksum.

Signed-off-by: Pali Rohár <pali@kernel.org>
[ refactored ]
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Some vendor U-Boot kwbimage binaries (e.g. those for A375) have load
address set to zero. Therefore it is not possible to inject code which
changes baudrate back to 115200 Bd before the data part.

So instead inject it after the data part and change kwbimage execution
address to that offset. Also store original execution address into
baudrate change code, so after it changes baudrate back to 115200 Bd, it
can jump to orignal address.

Signed-off-by: Pali Rohár <pali@kernel.org>
[ refactored ]
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Data part of the image contains 4-byte checksum. Validate it when
processing the image.

Signed-off-by: Pali Rohár <pali@kernel.org>
[ refactored ]
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

SPI image header and data parts do not have to be aligned to 128 byte
xmodem block size. So reserve additional memory for aligning header part
and additional memory for aligning data part.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Explicitly disable 2 stop bits by clearing CSTOPB flag, disable modem
control flow by clearing CRTSCTS flag and do not send hangup after closing
device by clearing HUPCL flag.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Explicitly zero out the rfds fd_set with FD_ZERO() before using it.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

This is a pci driver, not an eth driver.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Root Complex should be the default mode, let's set it explicitly.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Now that PCI Bridge is working, U-Boot's CONFIG_PCI_PNP code automatically
enables memory access and bus mastering when it is needed. So do not
prematurely enable memory access and bus mastering.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

PCI Bridge is always accessible also when link is down. So move detection
of link up from mvebu_pcie_of_to_plat() function to mvebu_pcie_valid_addr()
function which is used when accessing PCI config space.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Functions mvebu_pcie_get_local_bus_nr() and mvebu_pcie_get_local_dev_nr()
are not used, so remove them.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

The mysterious "Memory controller" PCI device which is present in PCI
config space is improperly configured and crippled PCI Bridge which acts
as PCIe Root Port for endpoint PCIe card.

This PCI Bridge reports in PCI config space incorrect Class Code (Memory
Controller) and incorrect Header Type (Type 0). It looks like HW bug in
mvebu PCIe controller but apparently it can be changed via mvebu registers
to correct values.

The worst thing is that this PCI Bridge is crippled and its PCI config
registers in range 0x10-0x34 alias access to internal mvebu registers which
have different functionality as PCI Bridge registers. Moreover,
configuration of PCI primary and secondary bus numbers (registers 0x18
and 0x19) is done via totally different mvebu registers via totally strange
method and cannot be done via PCI Bridge config space.

Due to above fact about PCI config range 0x10-0x34, allocate a private
cfgcache[] buffer in the driver, to which PCI config access requests to
the 0x10-0x34 space will be redirected in mvebu_pcie_read_config() and
mvebu_pcie_write_config() functions. Function mvebu_pcie_write_config()
will also catch writes to PCI_PRIMARY_BUS (0x18) and PCI_SECONDARY_BUS
(0x19) registers and set PCI Bridge primary and secondary bus numbers via
mvebu's own method.

Also, Expansion ROM Base Address register (0x38) is available, but at
different offset 0x30. So recalculate register offset before accessing PCI
config space.

After these steps U-Boot sees working PCI Bridge and CONFIG_PCI_PNP code
can finally start enumerating all PCIe devices correctly, even with more
complicated PCI topology. So update also mvebu_pcie_valid_addr() function
to reflect state of the real device topology.

Each PCIe port is de-facto isolated and every PCI Bridge which is part of
PCIe Root Complex is also isolated, so put them on separate PCI buses as
(local) device 0.

U-Boot already supports enumerating separate PCI buses, real (HW) bus
number can be retrieved by "PCI_BUS(bdf) - dev_seq(bus)" code, so update
config read/write functions to properly handle more complicated tree
topologies (e.g. when a PCIe switch with multiple PCI buses is connected
to the PCIe port).

Local bus number and local device number on mvebu are used for determining
which config request type is used (Type 0 vs Type 1). On normal non-broken
PCIe hardware it is done by primary and secondary bus numbers. So correctly
translate settings between these numbers to ensure that correct config
requests are sent over the PCIe bus.

As bus numbers are correctly re-configured, it does not make sense to print
some initial bogus configuration during probe, so remove this debug code.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

When reading 8 or 16 bits from config space, use appropriate readb() or
readw() calls. This ensures that PCIe controller does not read more bits
from endpoint card as asked by read_config() function.

Technically there should not be an issue with reading data from config
space which are not later used as there are no clear-by-read registers.
But it is better to use correct read operation based on requested size.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

This contributor prefers not to receive mails authored 3 years ago and Stefan Roese committed 3 years ago

Current implementation of write_config() is broken for PCI_SIZE_8 or
PCI_SIZE_16 as it always uses writel(), which means that write operation
is always 32-bit, so upper 24 bits for PCI_SIZE_8 and upper 16 bits for
PCI_SIZE_16 are cleared.

Fix this by using writeb() and writew(), respectively.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

Signed-off-by: Tom Rini <trini@konsulko.com>

Rsync all defconfig files using moveconfig.py

Signed-off-by: Tom Rini <trini@konsulko.com>

- Fixes for x86 build with Clang/LLVM compiler
- Tangier ACPI changes
- Edison SD card detect pin fix
- EFI on x86 doc update with latest instructions
- PXE utility fixes to align with latest x86 zboot implementation

Andy Shevchenko authored 3 years ago and Bin Meng committed 3 years ago

Move error message to the caller of mrfld_pinconfig*() in order
to unify them in the future.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Andy Shevchenko authored 3 years ago and Bin Meng committed 3 years ago

Move is_protected assignment closer to its user.
This increases readability and makes maintenance easier.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Andy Shevchenko authored 3 years ago and Bin Meng committed 3 years ago

There are two PCB designs in the wild which use the opposite
signaling for SD card detection. This makes U-Boot working
in one case and failing in the other. Quirk this out by
disconnecting SD card detection pin from the PCB by switching
it to mode 3. In the disconnected state the read value is always
the same and inverted to what we are expecting in the code.

BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136


Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Andy Shevchenko authored 3 years ago and Bin Meng committed 3 years ago

We would need to quirk out the Card Detect case and for that we allow
configuring the SD/SDIO family of pins.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Alistair Delva authored 3 years ago and Bin Meng committed 3 years ago

When building U-Boot with clang, it notices that the i8254.h include
guard does not work correctly due to a typo. Fix it.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed the other same typo at the end of the same file]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Alistair Delva authored 3 years ago and Bin Meng committed 3 years ago

Fix a warning seen when compiling this dts file.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Andy Shevchenko authored 3 years ago and Bin Meng committed 3 years ago

There is no point to use Method() for the constant.
Replace it with Name() defined object. For the _STA
case it saves 3 bytes per each entry.

Before: 2881
After: 2833

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Zhaofeng Li authored 3 years ago and Bin Meng committed 3 years ago

Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Zhaofeng Li authored 3 years ago and Bin Meng committed 3 years ago

bootm and zboot accept different arguments:

> bootm [addr [arg ...]]
>    - boot application image stored in memory
>        passing arguments 'arg ...'; when booting a Linux kernel,
>        'arg' can be the address of an initrd image

> zboot [addr] [size] [initrd addr] [initrd size] [setup] [cmdline]
>       addr -        The optional starting address of the bzimage.
>                     If not set it defaults to the environment
>                     variable "fileaddr".
>       size -        The optional size of the bzimage. Defaults to
>                     zero.
>       initrd addr - The address of the initrd image to use, if any.
>       initrd size - The size of the initrd image to use, if any.

In the zboot flow, the current code will reuse the bootm args and attempt
to pass the initrd arg (argv[2]) as the kernel size (should be argv[3]).
zboot also expects the initrd address and size to be separate arguments.

Let's untangle them and have separate argv/argc locals.

Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The existing intructions in the U-Boot on EFI doc do not work with
the latest QEMU. Update the doc with the correct instructions, as
well as using the new OVMF URL link.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Environment tidy-ups
patman 'postfix' support
fix binman test race condition causing a timeout error

# gpg: Signature made Sun 31 Oct 2021 03:36:55 PM EDT
# gpg:                using RSA key B25C0022AF86A7CC1655B6277F173A3E9008ADE6
# gpg:                issuer "sjg@chromium.org"
# gpg: Good signature from "Simon Glass <sjg@chromium.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B25C 0022 AF86 A7CC 1655  B627 7F17 3A3E 9008 ADE6

Marek Vasut authored 3 years ago and Simon Glass committed 3 years ago

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>