[BUG] sandbox: './u-boot -l ' fails

Tue Sep 29 03:21:05 CEST 2020

On 9/29/20 1:59 AM, Heinrich Schuchardt wrote:
> On 9/29/20 12:19 AM, Simon Glass wrote:
>> Hi Heinrich,
>>
>> On Mon, 28 Sep 2020 at 15:23, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>
>>> On 9/28/20 3:42 PM, Simon Glass wrote:
>>>> Hi Heinrich,
>>>>
>>>> On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>>>
>>>>> On 28.09.20 15:22, Simon Glass wrote:
>>>>>> Hi Heinrich,
>>>>>>
>>>>>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>>>>>
>>>>>>> On 28.09.20 06:46, Heinrich Schuchardt wrote:
>>>>>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg at chromium.org>:
>>>>>>>>> Hi Heinrich,
>>>>>>>>>
>>>>>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Simon,
>>>>>>>>>>
>>>>>>>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>>>>>>>>> out
>>>>>>>>>> of the box?
>>>>>>>>>>
>>>>>>>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>>>>>>>>>
>>>>>>>>> For the record you should be able to use -D to get the same effect as
>>>>>>>>> your -d above.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>>>>>>>>> +0200)
>>>>>>>>>>
>>>>>>>>>> Model: sandbox
>>>>>>>>>> DRAM:  128 MiB
>>>>>>>>>>
>>>>>>>>>> Warning: host_lo MAC addresses don't match:
>>>>>>>>>> Address in ROM is               26:4b:ca:6c:98:f4
>>>>>>>>>> Address in environment is       00:00:11:22:33:44
>>>>>>>>>>
>>>>>>>>>> Warning: host_virbr0 MAC addresses don't match:
>>>>>>>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
>>>>>>>>>> Address in environment is       00:00:11:22:33:45
>>>>>>>>>>
>>>>>>>>>> Warning: host_docker0 MAC addresses don't match:
>>>>>>>>>> Address in ROM is               c2:85:07:7b:9a:18
>>>>>>>>>> Address in environment is       00:00:11:22:33:46
>>>>>>>>>> WDT:   Not found!
>>>>>>>>>> MMC:
>>>>>>>>>>
>>>>>>>>>> No output after this point.
>>>>>>>>>>
>>>>>>>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>>>>>>>>>
>>>>>>>>>> CONFIG_SANDBOX_SDL=y
>>>>>>>>>>
>>>>>>>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
>>>>>>>>> U-Boot's
>>>>>>>>>> __serial_getc(). I wonder how it gets there without returning from
>>>>>>>>> the
>>>>>>>>>> function.
>>>>>>>>>>
>>>>>>>>>> I compiled SDL2.cpp from
>>>>>>>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>>>>>>>>>
>>>>>>>>>> and it runs fine showing an X11 windows with red background.
>>>>>>>>>>
>>>>>>>>>> So there seems to be no general problem with the SDL2 library.
>>>>>>>>>
>>>>>>>>> I hit this myself on another computer and it turned out to be that SDL
>>>>>>>>> defined getc(), as does U-Boot, and things get confused. At least I
>>>>>>>>> think it is getc.
>>>>>>>>>
>>>>>>>>> I hacked around with changing the name of getc (I think it was getc)
>>>>>>>>> in U-Boot and the problem went away.
>>>>>>>>
>>>>>>>> Should we include a patched SDL2 with U-Boot for static linking?
>>>>>>>>
>>>>>>>
>>>>>>> I cannot find a symbol getc() nor a reference to it in the SDL
>>>>>>> repository. getc() is defined in stdio.h.
>>>>>>>
>>>>>>> Our getc() takes no argument, while the stdio one wants a FILE *.
>>>>>>>
>>>>>>> But changing the U-Boot definition to "int getc(void *)" does not solve
>>>>>>> the issue.
>>>>>>
>>>>>> I just tried it on the machine where it doesn't work:
>>>>>>
>>>>>> $ gdb --args /tmp/b/sandbox/u-boot -l -D
>>>>>> GNU gdb (Debian 9.2-1) 9.2
>>>>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>>>>> This is free software: you are free to change and redistribute it.
>>>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>>> Type "show copying" and "show warranty" for details.
>>>>>> This GDB was configured as "x86_64-linux-gnu".
>>>>>> Type "show configuration" for configuration details.
>>>>>> For bug reporting instructions, please see:
>>>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>>>> Find the GDB manual and other documentation resources online at:
>>>>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>>>>>
>>>>>> For help, type "help".
>>>>>> Type "apropos word" to search for commands related to "word"...
>>>>>> Reading symbols from /tmp/b/sandbox/u-boot...
>>>>>> (gdb) br getc
>>>>>> Breakpoint 1 at 0x5b6d6: getc. (2 locations)
>>>>>> (gdb) r
>>>>>> Starting program: /tmp/b/sandbox/u-boot -l -D
>>>>>> [Thread debugging using libthread_db enabled]
>>>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>>>>
>>>>>>
>>>>>> U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
>>>>>>
>>>>>> Model: sandbox
>>>>>> DRAM:  128 MiB
>>>>>>
>>>>>> Warning: host_lo MAC addresses don't match:
>>>>>> Address in ROM is 1a:34:9b:48:aa:53
>>>>>> Address in environment is 00:00:11:22:33:44
>>>>>> WDT:   Not found!
>>>>>> MMC:
>>>>>>
>>>>>> Breakpoint 1, getc () at
>>>>>> /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
>>>>>> 414 if (!gd->have_console)
>>>>>> (gdb) up
>>>>>> #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
>>>>>> (gdb)
>>>>>>
>>>>>>
>>>>>> So it seems that it is libX11 causing the problem.
>>>>>>
>>>>>> I don't think the best fix is to remove getc() from that library,
>>>>>> although I do wonder if it is a bug. Renaming the symbol in U-Boot
>>>>>> with #define (only on sandbox) might be one option.
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>>
>>>>> #define getc _uboot_getc
>>>>>
>>>>> is what I tried but it runs you into the trouble that many other symbols
>>>>> contain the getc substring.
>>>>>
>>>>> As we always try to use the same definition in U-Boot as in glibc we
>>>>> should really replace getc() by another symbol, e.g. chget() so that we
>>>>> avoid confusion.
>>>>
>>>> Well the first question is whether this is a bug with x11.
>>>>
>>>> I'm not sure that renaming is a good idea. getc() is a pretty standard name.
>>>>
>>>> Try
>>>>
>>>> #define getc(x) _sandbox_get(x)
>>>>
>>>> which might get you closer.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commit/7b302bedb21f94b9eb619cb38ef985f7bbb9be1f
>>>
>>> seems to fix the crash. I get an output window.
>>>
>>> But there are still problems:
>>>
>>> * The shift key does not work on the keyboard.
>>
>> What is shift supposed to do? Do you mean you cannot get capital
>> letters or symbols?
>>
>>> * The output is black and white only.
>>
>> That's odd. I haven't tried it recently but earlier in the year I was
>> able to write a colour BMP.
>>
>>>
>>> What I would like to have is a 32bit color framebuffer on which I can
>>> draw with the EFI graphical output protocol.
>>
>> Well that should work. I adds Nuklear support a while back and
>> everything seemed good. Perhaps there has been a regression? But there
>> is a test for colour bitmaps. Perhaps it is just the SDL display side
>> which is not working?
>>
>> I just tried this and got a colour image:
>>
>> => host load hostfs - 0 tools/logos/denx.bmp
>> => bmp display 0
>>
>> Regards,
>> Simon
>>
>
> Hello Simon,
>
> the background of characters is not set correctly. I thought it was
> black and white.
>
> To see what I mean:
>
> CONFIG_EFI_SELFTEST=y
>
> ./u-boot -D -l
>
> => setenv efi_selftest block image transfer
> => bootefi selftest
>
> You will need my two patches.
>
> Things that are still wrong:
>
> * We start with black on white instead white on black.
> * Background for characters.
> * The font in not mono-spaced.
> * When typing a backslash you get always two of them.

* White on black is customizing.
Can we change that for the sandbox_defconfig to fit to Linux standards?

* The truetype console does not yet understand the escape sequences for
colors. The normal console does.

* The normal console has a mono-space font. We also have alternative
fonts for the truetype console.

* Both consoles fail on Unicode characters. But we probably do not want
larger font files.

So the only problem I do not understood yet is the duplicate backspace.

Best regards

Heinrich