bcm63xx/u-boot/arch/sandbox/cpu, branch master

sandbox: Drop the printf() in setup_ram_buf()

2019-04-24T02:26:43Z

This was really intended for debugging. Drop it. Signed-off-by: Simon Glass

sandbox: Correct maths in allocation routines

2019-04-24T02:26:43Z

Allocation routines were adjusted to ensure that the returned addresses are a multiple of the page size, but the header code was not updated to take account of this. These routines assume that the header size is the same as the page size which is unlikely. At present os_realloc() does not work correctly due to this bug. The only user is the hostfs 'ls' command, and only if the directory contains a unusually long filename, which likely explains why this bug was not caught earlier. Fix this by doing the calculations using the obtained page size. Signed-off-by: Simon Glass

sandbox: Improve debugging in initcall_run_list()

2019-04-24T02:26:43Z

At present if one of the initcalls fails on sandbox the address printing is not help, e.g.: initcall sequence 0000557678967c80 failed at call 00005576709dfe1f (err=-96) This is because U-Boot gets relocated high into memory and the relocation offset (gd->reloc_off) does not work correctly for sandbox. Add support for finding the base address of the text region (at least on Linux) and use that to set the relocation offset. This makes the output better: initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96) Then you use can use grep to see which init call failed, e.g.: $ grep 0000000000048134 u-boot.map stdio_add_devices Of course another option is to run it with a debugger such as gdb: $ gdb u-boot ... (gdb) br initcall.h:41 Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations) Note that two locations are reported, since this function is used in both board_init_f() and board_init_r(). (gdb) r Starting program: /tmp/b/sandbox/u-boot [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600) DRAM: 128 MiB MMC: Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 ) at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41 41 printf("initcall sequence %p failed at call %p (err=%d)\n", (gdb) print *init_fnc_ptr $1 = (const init_fnc_t) 0x55555559c114 (gdb) Signed-off-by: Simon Glass

sandbox: Correct SDL build flags

2019-01-15T00:47:13Z

The check for CONFIG_SANDBOX_SDL in config.mk does not work since the build config is not available by the time that file is included. Remove it so that we always call sdl-config except when NO_SDL is used. Signed-off-by: Simon Glass

dm: sandbox: Allow selection of sample rate and channels

2018-12-13T23:37:09Z

At present these parameters are hard-coded in the sdl interface code. Allow them to be specified by the driver instead. Signed-off-by: Simon Glass

dm: sound: Complete migration to driver model

2018-12-13T23:36:41Z

All users of sound are converted to use driver model. Drop the old code and the CONFIG_DM_SOUND option. Signed-off-by: Simon Glass

dm: sandbox: sound: Convert to use driver model

2018-12-13T23:36:30Z

Update sandbox's device tree and config to use driver model for sound. Use the double buffer for sound output so that we don't need to wait for the sound to complete before returning. Signed-off-by: Simon Glass

dm: sandbox: Update sound to use two buffers

2018-12-13T23:32:49Z

At present we use a single buffer for sound which means we cannot be playing one sound while queueing up the next. This wouldn't matter except that a long sound (more than a second) has to be created as a single buffer, thus using a lot of memory. To better mimic what real sound drivers do, add support for double buffering in sandbox. Signed-off-by: Simon Glass

sandbox: Use 'extras' to specify 'head' files

2018-12-05T13:01:34Z

At present sandbox has a start.o in the 'start' target but also includes it in the normal target list. This is not how this is normally handled. It is needed because sandbox does not include the u-boot-init variable in its link rule. Update the rule and move start.o from the normal target list to the 'extras' list. Signed-off-by: Simon Glass

sandbox: Zero the ram buffer on startup

2018-12-05T13:01:34Z

At present the RAM buffer is not inited unless it is read from a file, likely produced by an earlier phase of U-Boot. This causes valgrind warnings whenever the RAM buffer is used. Correct this by initing it if needed. Signed-off-by: Simon Glass