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

Tue Sep 29 00:19:49 CEST 2020

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