u-boot.git/arch/x86/cpu/start.S, branch v2016.03

Fix board init code to respect the C runtime environment

2016-01-14T02:05:17Z

board_init_f_mem() alters the C runtime environment's stack it is actually already using. This is not a valid behaviour within a C runtime environment. Split board_init_f_mem into C functions which do not alter their own stack and always behave properly with respect to their C runtime environment. Signed-off-by: Albert ARIBAUD Acked-by: Thomas Chou

x86: Init the debug UART if enabled

2015-10-21T13:46:50Z

If the debug UART is enabled, get it ready for use at the earliest possible opportunity. This is not actually very early, but until we have a stack it is difficult to make it work. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: fsp: Add comments about U-Boot entering start.S twice

2015-08-26T14:54:11Z

Add some comments in start.S for the fact that with FSP U-Boot actually enters the code twice. Also change to use fsp_init() and fsp_continue for accuracy. Signed-off-by: Bin Meng Acked-by: Simon Glass

x86: fsp: Enlarge the size of malloc() pool before relocation

2015-08-26T14:54:11Z

After fsp_init() returns, the stack has already been switched to a place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR. Enlarge the size of malloc() pool before relocation since we have plenty of memory now. Signed-off-by: Bin Meng Acked-by: Simon Glass

x86: Switch to using generic global_data setup

2015-08-14T15:50:10Z

There is quite a bit of assembler code that can be removed if we use the generic global_data setup. Less arch-specific code makes it easier to add new features and maintain the start-up code. Drop the unneeded code and adjust the hooks in board_f.c to cope. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Enable debug UART for Minnowmax

2015-08-06T13:44:30Z

Enable the debug UART and emit a single 'a' early in the init sequence to show that it is working. Unfortunately the debug UART implementation needs a stack to work. I cannot seem to remove this limitation as the absolute 'jmp %eax' instruction goes off into the weeds. So this means that the character output cannot be any earlier than car_init_ret, where memory is available for a stack. Signed-off-by: Simon Glass Reviewed-by: Lukasz Majewski

x86: Add support for passing tables into U-Boot

2015-08-05T14:44:07Z

The EFI stub provides information to U-Boot in a table. This includes the memory map which is needed to decide where to relocate U-Boot. Collect this information in the early init code and store it in global_data. Fix up the BIST code at the same time since we don't have it when booting from EFI and can assume it is 0. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Tidy up global_data flags

2015-08-05T14:42:40Z

These flags now overlap some global ones. Adjust the x86-specific flags to avoid this. Since this requires a change to the start.S code, add a way for tools to find the 32-bit cold reset entry point. Previously this was at a fixed offset. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: Add various minor tidy-ups to the 32-bit startup code

2015-08-05T14:42:40Z

Fix a typo, improve some comments and add a little more detail in some cases. Signed-off-by: Simon Glass Reviewed-by: Bin Meng

x86: fsp: Move FspInitEntry call to board_init_f()

2015-07-15T00:03:15Z

The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far. It worked pretty well but looks not that good. Apart from doing too much work than just enabling CAR, it cannot read the configuration data from device tree at that time. Now we want to move it a little bit later as part of init_sequence_f[] being called by board_init_f(). This way it looks and works better in the U-Boot initialization path. Due to FSP's design, after calling FspInitEntry it will not return to its caller, instead it jumps to a continuation function which is given by bootloader with a new stack in system memory. The original stack in the CAR is gone, but its content is perserved by FSP and described by a bootloader temporary memory HOB. Technically we can recover anything we had before in the previous stack, but that is way too complicated. To make life much easier, in the FSP continuation routine we just simply call fsp_init_done() and jump back to car_init_ret() to redo the whole board_init_f() initialization, but this time with a non-zero HOB list pointer saved in U-Boot's global data so that we can bypass the FspInitEntry for the second time. Signed-off-by: Bin Meng Acked-by: Simon Glass Tested-by: Andrew Bradford Tested-by: Simon Glass