Chapter 6: Mapping peripherals to a specific board

With the SoC support of the BSP ready, we can start working on hardware adoption. Since I want this BSP to be as universal as possible, I tried to bring out as many digital peripherals as possible. My final target use is HMI, but I might add some control features, so let’s bring all possible SPI, I2C and UART ports. I will not be interested in multimedia, so I2S, TVIN/OUT and audio codec will not be considered. Due to limitation of RTOS, I will also not be supporting USB.

After consulting the datasheet and a few reference designs, I found that port D is essentially all occupied by LCD interface, therefore all digital communication peripherals must be brought out on port A/B/C/E/F. Since port B is not bonded on QFN88 package, we will leave it alone. Because the goal is to build a minimum system, we will use the touchscreen interface built-in with the chip, therefore port A is off limit too. Similarly, port C is occupied by SPI NOR flash, thus it is off limit for other uses. Despite I do not plan to support SD card, considering it is such a popular feature, I will reserve port F for it. So, all in all, we only have port E at our disposal. Even for port E, PE0 and PE1 are occupied by startup console and I have no intention on remapping them as doing so will require modification of many codes in the existing BSP.

Considering all pin conflicts, I decided to being out I2C0 on PE11~PE12, SPI1 on PE7~PE10, or alternatively UART2 on PE7~PE8. I also plan to bring out PWM1 on PE6 for LCD backlight dimming, and 4 GPIOs on PE2~PE5. Many existing boards use PE2 as USB OTG, but since we do not have USB support other than debugging, we do not have to support USB host, thus no OTG.

Remember the json file we renamed before in BSP/romdisk/boot? Let’s go back to it and see what it has. If it looks like an ascii device tree file in Linux, then you are right. It is the XBoot version of device tree, and it gets parsed every time the kernel boots. By modifying it, we can change how kernel probes drivers upon booting. Skip everything before line 191, as anything before are not supposed to be touched – clock, reset and interrupt controllers. The first thing we need to get familiarized is GPIO definitions, here we can see port A/C/D/E/F are defined with their logical base address. Write those numbers down as we will be needing those. PA is 0, PC is 64, PD is 96, PE is 128 and PF is 160.

In the PWM section we can see PWM0 defined to use GPIO 0, which is PA0. We intend to use PA0 for touchscreen, but we can leave it as is as anyway we will not be using PWM0. PWM1 is set to use GPIO 134, which is 128+6, or PE6, which is what we intended, thus we can leave this one untouched too. Ignore the times as they don not occupy GPIOs. For I2C0, we can leave the settings as is as GPIO 139 and 140 are PE11 and PE12, exactly what we wanted. Ignore I2C1 and I2C2 as we will never use them. We will also leave UART0 untouched for previously mentioned reasons. UART1 is not used, so let it be. UART2 was set to use GPIO 135 and 136, which are PE7 and PE8, again, what we anticipated, so nothing needs to be done ere either. SPI0 was mapped to PC0~PC3, which is what my hardware uses, and SPI1 was mapped to PE7~PE10, so nothing needs to change here. We will also leave SD as is since there is only one set of SD pins, and they cannot be changed. SPINOR is set to use SPI0, which is correct. We will not change WDT as it does not have pins, and we will leave LRADC as is since we will not be using it. You can remove or just leave led-gpio and ledtrigger there as we do not really need them and really cannot care about them.

Finally, it is time for porting the LCD interface. First, in ts section we need to take a look at calibration term. The tuple dictates how ADC readings are translated to on-screen coordinates. The calibration is based on 2D linear functions, where:

X(x, y)=(k0+k1*x+k2*y)/k6Y(x, y)=(k3+k4*x+k5*y)/k6

All k factors are stored in coefficient tuple in k0~k6 order. This will be modified once we have real data from an actual touchscreen. We will just leave the default numbers there. Then we move to led-pwm-bl section, where it specifies PWM controller, minimum/maximum duty cycle and default states. The default can be used as is. Lastly, in fb section we can see parameters for the framebuffer, and what we really care are width, height, vertical and horizontal front/back porch times and pixel clock. In this case, I will be using a 480*272 LCD. After consulting the datasheet, I stuffed all correct timing values in fb section. Since I anticipate up to 60fps refresh rate, the pixel clock has to be at least 60*(480+8+43)*(272+4+12)=9.2MHz. The default 33MHz will do just fine, so I left it as is and saved the file. In addition, I also changed length and offset in spinor section since I anticipate my program will be no more than 1MB, so I figured I would save an extra 3MB for custom file storage.

After modifying the device tree file, we can then work on modifying CPU clock. The CPU clock frequency is defined in BSP/sys-clock.c, sys_clock_init(). Change the literal 408000000 to 600000 or 720000. There is a limit of 720MHz in clock_set_pll_cpu(), which you can override to allow the CPU to be overclocked to up to 900MHz, but it is not recommended due to excessive heating and reduced reliability. To reliably operate at 900MHz, core voltage has to be raised from 1.1V to at least 1.2V. It is recommended to operate the CPU at below 600MHz for maximum reliability at 1.1V, and no more than 720MHz at 1.2V.

Despite both XBoot and F1C200S support dynamic CPU clock, the BSP did not have such implementation. To add such feature, populate clk_f1c100s_pll_set_rate() in BSP/drivers/clk-f1c100s-pll.c with:

Then copy clock_set_pll_cpu() and wait_pll_stable() from BSP/sys-clock.c. They have to be declared as static in BSP/sys-clock.c to save a few bytes in order to pack SPL down to 7680 bytes.

At this step, low level porting has been finished, and app development can begin.

最近编辑记录 Blueskull (2020-02-22 00:17:32)