From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Tue, 29 Sep 2020 03:21:05 +0200 Subject: [BUG] sandbox: './u-boot -l ' fails In-Reply-To: <1fd0353d-e134-c945-4cee-9bc5c5764df1@gmx.de> References: <6fbb0eda-94ff-b8de-4c63-f4a8336ed0ce@gmx.de> <71651c9f-1f11-b293-d037-ce2cb3cd75f6@gmx.de> <1fd0353d-e134-c945-4cee-9bc5c5764df1@gmx.de> Message-ID: <94b30746-823b-3346-e4ad-aee8bc8c52ac@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 >> > > 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