Skip to content
Snippets Groups Projects
Select Git revision
  • u-boot-dfu default
  • u-boot-dfu-next
  • testing
  • bkp
  • u-boot-dfu-20250321
  • u-boot-dfu-next-20250310
  • u-boot-dfu-20250211
  • u-boot-dfu-20250124
  • u-boot-dfu-20241219
  • u-boot-dfu-next-20241126
  • u-boot-dfu-20241126
  • u-boot-dfu-20241125
  • u-boot-dfu-20241025
  • u-boot-dfu-20241017
  • u-boot-dfu-next-20241003
  • u-boot-dfu-20240930
  • u-boot-dfu-20240910
  • u-boot-dfu-20240822
  • u-boot-dfu-next-20240820
  • u-boot-dfu-20240820
  • u-boot-dfu-20240711
  • u-boot-dfu-20240606
  • u-boot-dfu-20240516
  • u-boot-dfu-20240419
24 results
Search by author
  • Any Author
  • Lukasz Majewski Lukasz Majewski lukma
  • Mattijs Korpershoek Mattijs Korpershoek mkorpershoek
  • Tom Rini Tom Rini trini
3 authors
  1. Mar 04, 2022
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Fix sending and processing debug message pattern (-d option) · 93976af5
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
-d option is currently broken. In most cases BootROM does not detect this
message pattern. For sending debug message pattern it is needed to do same
steps as for boot message pattern.

Implement sending debug message pattern via same separate thread like it is
for boot message pattern.

Checking if BootROM entered into UART debug mode is different than
detecting UART boot mode. When in boot mode, BootROM sends xmodem NAK
bytes. When in debug mode, BootROM activates console echo and reply back
every written byte (extept \r\n which is interpreted as executing command
and \b which is interpreting as removing the last sent byte).

So in kwboot, check that BootROM send back at least 4 debug message
patterns as a echo reply for debug message patterns which kwboot is sending
in the loop.

Then there is another observation, if host writes too many bytes (as
command) then BootROM command line buffer may overflow after trying to
execute such long command. To workaround this overflow, it is enough to
remove bytes from the input line buffer by sending 3 \b bytes for every
sent character. So do it.

With this change, it is possbile to enter into the UART debug mode with
kwboot -d option.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Tested-by: default avatarStefan Roese <sr@denx.de>
      93976af5
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Use separate thread for sending boot message pattern · 913866af
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
After BootROM successfully detects boot message pattern on UART it waits
until host stop sending data on UART. For example Armada 385 BootROM
requires that host does not send anything on UART at least 24 ms. If host
is still sending something then BootROM waits (possibly infinitely).

BootROM successfully detects boot message pattern if it receives it in
small period of time after power on.

So to ensure that host put BootROM into UART boot mode, host must send
continuous stream of boot message pattern with a small gap (for A385 at
least 24 ms) after series of pattern. But this gap cannot be too often or
too long to ensure that it does not cover whole BootROM time window when it
is detecting for boot message pattern.

Therefore it is needed to do following steps in cycle without any delay:
1. send series of boot message pattern over UART
2. wait until kernel transmit all data
3. sleep small period of time

At the same time, host needs to monitor input queue, data received on the
UART and checking if it contains NAK byte by which BootROM informs that
xmodem transfer is ready.

But it is not possible to wait until kernel transmit all data on UART and
at the same time in the one process to also wait for input data. This is
limitation of POSIX tty API and also by linux kernel that it does not
provide asynchronous function for waiting until all data are transmitted.
There is only synchronous variant tcdrain().

So to correctly implement this handshake on systems with linux kernel, it
is needed to use tcdrain() in separate thread.

Implement sending of boot message pattern in one thread and reading of
reply in the main thread. Use pthread library for threads.

This change makes UART booting on Armada 385 more reliable. It is possible
to start kwboot and power on board after minute and kwboot correctly put
board into UART boot mode.

Old implementation without separate thread has an issue that it read just
one byte from UART input queue and then it send 128 message pattern to the
output queue. If some noise was on UART then kwboot was not able to read
BootROM response as its input queue was just overflowed and kwboot was
sending more data than receiving.

This change basically fixed above issue too.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Tested-by: default avatarStefan Roese <sr@denx.de>
      913866af
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Cleanup bootmsg and debugmsg variables · c1d911f1
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
Function kwboot_debugmsg() is always called with kwboot_msg_debug as msg
and function kwboot_bootmsg() with kwboot_msg_debug as msg. Function
kwboot_bootmsg() is never called with NULL msg.

Simplify, cleanup and remove dead code.

No functional change.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Tested-by: default avatarStefan Roese <sr@denx.de>
      c1d911f1
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Remove msg_req_delay · 132016e2
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
Variable msg_req_delay is set but never used. So completely remove it.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Tested-by: default avatarStefan Roese <sr@denx.de>
      132016e2
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Check for return value of kwboot_tty_send() and tcflush() · d8865f86
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
Failure of kwboot_tty_send() and tcflush() functions is fatal, it does not
make sense to continue. So return error back to the caller like in other
places where are called these functions.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Tested-by: default avatarStefan Roese <sr@denx.de>
      d8865f86
    • Chris Packham's avatar
      ARM: mvebu: x530: clearfog: Add ODT configuration · 0a6f0297
      Chris Packham authored and Stefan Roese's avatar Stefan Roese committed 
      
Commit 369e5326 ("ddr: marvell: a38x: allow board specific ODT
configuration") added the odt_config member to struct
mv_ddr_topology_map ahead of the clk_enable and ck_delay members. This
means that any boards that configured either of clk_enable or ck_delay
needed to have their board topology updated. This affects the x530 and
clearfog boards. Other A38x boards don't touch any of the trailing
members of mv_ddr_topology_map so don't need updating.

Fixes: 369e5326 ("ddr: marvell: a38x: allow board specific ODT configuration")
Signed-off-by: default avatarChris Packham <judge.packham@gmail.com>
Acked-by: default avatarBaruch Siach <baruch@tkos.co.il>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      0a6f0297
    • Marek Behún's avatar
      arm64: a37xx: pinctrl: Fix PWM pins indexes · 87724d5c
      Marek Behún authored and Stefan Roese's avatar Stefan Roese committed 
      
Commit 5534fb4f ("arm64: a37xx: pinctrl: Correct PWM pins
definitions") introduced bogus definitions os PWM pins: all 4 pins have
index 11, instead of having indexes 11, 12, 13, 14.

Fix this.

Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
Reviewed-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      87724d5c
    • Francois Berder's avatar
      drivers: rtc: fix null pointer access in armada38x_rtc_reset · 2454de2c
      Francois Berder authored and Stefan Roese's avatar Stefan Roese committed 
      
Replace null pointer by pointer to device registers when calling
armada38x_rtc_write.

Signed-off-by: default avatarFrancois Berder <fberder@outlook.fr>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      2454de2c
    • This contributor prefers not to receive mails's avatar
      arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function again · 1fd54253
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
The a3700_fdt_fix_pcie_regions() function still computes nonsense.

It computes the fixup offset from the PCI address taken from the first
row of the "ranges" array, which means that:
- PCI address must equal CPU address (otherwise the computed fix offset
  will be wrong),
- the first row must contain the lowest address.

This is the case for the default device-tree, which is why we didn't
notice it.

It also adds the fixup offset to all PCI and CPU addresses, which is
wrong.

Instead:
1) The fixup offset must be computed from the CPU address, not PCI
   address.

2) The fixup offset must be computed from the row containing the lowest
   CPU address, which is not necessarily contained in the first row.

3) The PCI address - the address to which the PCIe controller remaps the
   address space as seen from the point of view of the PCIe device -
   must be fixed by the fix offset in the same way as the CPU address
   only in the special case when the CPU adn PCI addresses are the same.
   Same addresses means that remapping is disabled, and thus if we
   change the CPU address, we need also to change the PCI address so
   that the remapping is still disabled afterwards.

Consider an example:
  The ranges entries contain:
    PCI address   CPU address
    70000000      EA000000
    E9000000      E9000000
    EB000000      EB000000

  By default CPU PCIe window is at:        E8000000 - F0000000
  Consider the case when TF-A moves it to: F2000000 - FA000000

  Until now the function would take the PCI address of the first entry:
  70000000, and the new base, F2000000, to compute the fix offset:
  F2000000 - 70000000 = 82000000, and then add 8200000 to all addresses,
  resulting in
    PCI address   CPU address
    F2000000      6C000000
    6B000000      6B000000
    6D000000      6D000000
  which is complete nonsense - none of the CPU addresses is in the
  requested window.

  Now it will take the lowest CPU address, which is in second row,
  E9000000, and compute the fix offset F2000000 - E9000000 = 09000000,
  and then add it to all CPU addresses and those PCI addresses which
  equal to their corresponding CPU addresses, resulting in
    PCI address   CPU address
    70000000      F3000000
    F2000000      F2000000
    F4000000      F4000000
  where all of the CPU addresses are in the needed window.

Fixes: 4a82fca8 ("arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function")
Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      1fd54253
    • Marek Behún's avatar
      arm: mvebu: turris_omnia: Enable ext4 write support in defconfig · 7f59ed68
      Marek Behún authored and Stefan Roese's avatar Stefan Roese committed 
      
Enable ext4 write support in Turris Omnia's defconfig. Some users find
it useful.

Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      7f59ed68
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Cleanup macro names · fc27e5df
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
Use "MVPCIE_" prefix instead of generic "PCIE_" prefix for pci_mvebu.c
specific macros. Define offset macros for Root Port registers and use
standard register macros from pci.h when accessing Root Port registers.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      fc27e5df
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Remove unused SELECT and lane_mask · 68285176
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
Macro SELECT() is unused and struct mvebu_pcie field lane_mask is unused
too. Remove them.

Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      68285176
    • This contributor prefers not to receive mails's avatar
      tools: kwboot: Fix quitting terminal · 7938b3be
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed 
      
Sometimes kwboot after quitting terminal prints error message:

  terminal: Bad address

This is caused by trying to call write() syscall with count of (size_t)-1
bytes.

When quit sequence is split into more read() calls then number of input
bytes (nin) at the end of cycle can underflow and be negative. Fix it.

Fixes: de751404 ("tools: kwboot: Fix detection of quit esc sequence")
Signed-off-by: default avatarPali Rohár <pali@kernel.org>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
      7938b3be
  3. Mar 03, 2022
  5. Mar 01, 2022
  7. Feb 28, 2022
  9. Feb 26, 2022

Imprint & Privacy Policy