Major change: auto-generate bsp code

[ucb-bar]

Major change: auto-generate bsp code

[ethanwu10]

For the actual HAL code, I think it would be better to build a single shared library and then link against it from each board's BSP, and only generate a header file containing info about what peripheral is at what address. I don't really like the idea of generating actual library source code, since then we'd lose good IDE support on editing the library implementations.

To deal with differing hardware revisions, we should probably #ifdef hardware-specific portions and set configuration flags during compilation.

[T-K-233]

I think a valid approach is this:

under /bsp/common, we store the files for common periphery devices, like CORE, UART, GPIO etc.. If the SoC has custom periphery devices, it will be stored under /bsp/<chipname>, but still with name hal_<peripheryname>.h and hal_<peripheryname>.h.

For the main hal.h and hal.c, it should be moved into user program, under /core. Reasons being:

1. In hal.h we will define settings like the system clock frequency, clock tree muxes etc. This is application-dependent, and therefore should be controlled by user.
2. The HAL_init() routine will also differ by chips, and therefore should be put in /core/hal.c, and user can modify the init routine.
3. hal.h controls which peripheral devices are included in the final program. To reduce code size, user can exclude the code for unused periphery devices.

As a result, in /core/inc/main.h, user will do

#include "hal.h"

and in /core/inc/hal.h, it will be

#include "<chipname>.h"

#include "hal_core.h"
#include "hal_clint.h"
#include "hal_gpio.h"
#include "hal_i2c.h"
...

#define HXTAL_FREQ     20000000                   // Hz
// #define HXTAL_FREQ    100000000                   // Hz
#define SYS_CLK_FREQ  HXTAL_FREQ / 2              // Hz
#define MTIME_FREQ    (SYS_CLK_FREQ / 100000)     // tick per milliseconds