When using the USB OTG FEL mode on the Allwinner H616, the BootROM
stores some data at the end of SRAM C. This is also the location where
we place the initial SPL stack, so it will overwrite this data.
We still need the BROM code after running the SPL, so should leave that
area alone.
Interestingly this does not seem to have an adverse effect, I guess on
the "way out" (when we return to FEL after the SPL has run), this data
is not needed by the BROM, for just the trailing end of the USB operation.
However this is still wrong, and we should not clobber BROM data.
Lower the SPL stack address to be situated right below the swap buffers
we use in sunxi-fel: that should be out of the way of everyone else.
This obsoletes a previous commit (eb53e7743c8f) with the same name:
that one was changing the address in an *unused* macro in sunxi_common.h,
so the previous patch didn't have any effect at all.
Fixes: eb53e7743c8f ("sunxi: h616: lower SPL stack address to avoid BROM data")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
USB UFI uses fixed 12-byte commands (as does RBC, which is not supported), but SCSI does not have this limitation. Use the correct command block lengths depending on the subclass. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Some devices like YubiKeys need more time before SET_ADDRESS. The spec says we need to wait 10ms. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Marek Vasut <marex@denx.de>
Correct this typo in the warning message shown when no more bootstage records can be added. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Make it clear that in the options for setting the console record buffer sizes that we are talking about buffers for that feature specifically and not the general console buffers. Signed-off-by: Tom Rini <trini@konsulko.com>
When debugging, one sometimes only gets partial output lines or nothing at all from the last printf, because the uart has a largish buffer, and the code after the printf() may cause the CPU to hang before the uart IP has time to actually emit all the characters. That can be very confusing, because one doesn't then know exactly where the hang happens. Introduce a config knob allowing one to wait for the uart fifo to drain whenever a newline character is printed, roughly corresponding to the effect of setvbuf(..., _IOLBF, ...) in ordinary C programs. Since this uses IS_ENABLED() instead of cpp ifdef, we can remove the ifdef around the _serial_flush() definition - if neither CONSOLE_FLUSH_SUPPORT or CONSOLE_FLUSH_ON_NEWLINE are enabled, the compiler elides _serial_flush(), but it won't warn about it being unused. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org>
Unexpected 'Esc' key presses are accumulated internally, even if it is already clear that the current escape sequence is invalid. This results in weird behaviour. For example, the next character after 'Esc' key simply disappears from input and 'Unknown command' is printed after 'Enter'. This commit fixes some issues with extra 'Esc' keys entered by user: 1. Sequence <Esc><Esc><Enter> right after autoboot stop gives: => nknown command 'ry 'help' => 2. Sequence <Esc><p><r><i><Enter> gives: => ri Unknown command 'ri' - try 'help' => 3. Extra 'Esc' key presses break backspace functionality. Signed-off-by: Yurii Monakov <monakov.y@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
u-boot-imx-20231024 ------------------- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/18211 - Fixes for MC2432 Eeprom - i.MX93 ADC - Secondary boot mode on i.MX8M
Second set of u-boot-at91 features for the 2024.01 cycle This feature set a new board named Conclusive KSTR sama5d27 with some small prerequisites patches.