From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 28 Sep 2020 16:19:49 -0600 Subject: [BUG] sandbox: './u-boot -l ' fails In-Reply-To: <71651c9f-1f11-b293-d037-ce2cb3cd75f6@gmx.de> References: <6fbb0eda-94ff-b8de-4c63-f4a8336ed0ce@gmx.de> <71651c9f-1f11-b293-d037-ce2cb3cd75f6@gmx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Heinrich, On Mon, 28 Sep 2020 at 15:23, Heinrich Schuchardt wrote: > > On 9/28/20 3:42 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt wrote: > >> > >> On 28.09.20 15:22, Simon Glass wrote: > >>> Hi Heinrich, > >>> > >>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt wrote: > >>>> > >>>> On 28.09.20 06:46, Heinrich Schuchardt wrote: > >>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass : > >>>>>> Hi Heinrich, > >>>>>> > >>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt > >>>>>> 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 > >>> 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: > >>> . > >>> Find the GDB manual and other documentation resources online at: > >>> . > >>> > >>> 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