On Thursday 22 September 2022 17:06:31 Heinrich Schuchardt wrote:
On 9/22/22 15:14, Pali Rohár wrote:
On Thursday 22 September 2022 13:27:51 Simon Glass wrote:
Hi,
On Wed, 21 Sept 2022 at 15:56, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 21, 2022 at 03:54:13PM +0200, Pali Rohár wrote:
On Wednesday 21 September 2022 09:49:24 Tom Rini wrote:
On Mon, Sep 05, 2022 at 11:31:15AM +0200, Pali Rohár wrote:
> On certain places it is required to flush output print buffers to ensure > that text strings were sent to console or serial devices. For example when > printing message that U-Boot is going to boot kernel or when U-Boot is > going to change baudrate of terminal device. > > Some console devices, like UART, have putc/puts functions which just put > characters into HW transmit queue and do not wait until all data are > transmitted. Doing some sensitive operations (like changing baudrate or > starting kernel which resets UART HW) cause that U-Boot messages are lost. > > Therefore introduce a new flush() function, implement it for all serial > devices via pending(false) callback and use this new flush() function on > sensitive places after which output device may go into reset state. > > This change fixes printing of U-Boot messages: > "## Starting application at ..." > "## Switch baudrate to ..." > > Changes in v3: > * add macro STDIO_DEV_ASSIGN_FLUSH() > * fix commit messages > * remove changes from serial.c > > Changes in v2: > * split one big patch into smaller 6 patches > * add config option to allow disabling this new function > > Pali Rohár (6): > sandbox: Add function os_flush() > console: Implement flush() function > serial: Implement flush callback > serial: Implement serial_flush() function for console flush() fallback > serial: Call flush() before changing baudrate > boot: Call flush() before booting
Including the change you suggested to 4/6 to fix that build issue, there's at least one more large issue that prevents CI from getting too far: https://source.denx.de/u-boot/u-boot/-/pipelines/13534 and they all have a failure similar to: https://source.denx.de/u-boot/u-boot/-/jobs/500794#L51
It looks like that some efi stuff overloads u-boot functions, in this case newly added flush() function.
Any idea how to handle this issue?
I think you should rename the EFI flush() function to something like efi_flush().
Ok! I renamed EFI flush() function to efi_flush().
I put all patches into github pull request which started CI test: https://github.com/u-boot/u-boot/pull/241
When merging, please, use [PATCH 1/1] efi_selftest: prefix test functions with efi_st_ https://lists.denx.de/pipermail/u-boot/2022-September/495334.html
Hello! I updated https://github.com/u-boot/u-boot/pull/241 pull request for CI test. I added there above efi_selftest patch and after that CI test passed.
So Tom, is this enough for you? Or do you need something more?
Best regards
Heinrich
The only option which I see how to address it is to revert those changes in source files which always calls flush() function and replace them by my first attempt which use guard #ifdef to ensure that flush() call is completely eliminated at preprocessor stage when efi is enabled.
Adding in Heinrich.
-- Tom
Regards, Simon