Here at SiFive, we take documentation seriously and have been working to improve our offering. The Freedom U540-C000 Manual and Getting started guide are of particular importance because they represent the first documents released under a new, internally developed, documentation flow which gives us improved capabilities in both documentation generation and publication.
It is still a work in process, so please let us know if you find any mistakes.
Hi, nice manual!
So far I’ve noticed the following small errors and omissions in the FU540 manual v1p0:
Chapter 1, Introduction
“and is a(n) 16-way set-associative cache.” <- this should probably be “a 16…”
Chapter 2, List of Abbreviations and Terms
ChipLink could be added
Chapter 6, Boot process
“Then, the entire contents of this partition, the FSBL, are downloaded into the L2 LIM at address 0x0800_0000. Execution then branches to the FSBL.” -> are there any size size limits?
Chapter 13, UART
txdata.full is marked as RW. Is this intended? What effects do writes of a one vs. a zero into the the full flag have?
Chapter 18, OTP
“serial_n = read_otp_word(i+);”, s/i+/i+1/, i guess?
Chapter 20, DDR Subsystem
“The DDR Subsystem is ready to service memory accesses at base address
0x0800_0000.” <-- This should probably be 0x8000_0000.
The paragraphs about flash-based boot modes have phrases like “When the core is running at 33.3 MHz, this means 8.3 MHz. At 1 GHz, this means exactly 10 MHz.”, but section 6.5.4 (SD Card Bit-Banged x1) simply says “Set the QSPI controller to 20 MHz.”, without considering different speeds of coreclk.
As far as I understand it, the QSPI block can’t run at 20MHz if coreclk runs at 33.33… MHz, and consequently tlclk at 16.66… MHz. So, how does ZSBL configure the QSPI clock in this case?
Chapter 13 (UART) says: "The input clock is the bus clock tlclk. The reset value of the register is set to div_init, which is tuned to provide a 115200 baud output out of reset given the expected frequency of tlclk."
And indeed div_init=289 seems to be the reset value, but it doesn’t give 115200 baud, but 57600 baud. If f_in was hfclk=33.333MHz, we’d get f_baud = 33333333 / (289 + 1) = 114942 ≈ 115200; but f_in is tlclk=hfclk/2, so the baud rate is halved as well.
I tested this with boot mode 1 (jump to SPI flash) and some code that prints text on the UART and either sets the divisor to 289 or not at all; the result was the same in both cases, I had to configure the FTDI to 57600 baud to read the output correctly.
ZSBL does seem to set the divisor to the right value to get 115200 baud.
Firstly, thanks for your detailed comments on the spec. We have not posted here, but we have been including your corrections for the next revision.
As to your specific concern wrt. the UART, you are correct that tlclk is the clock which is divided by div_int. You may also be correct that the reset value is 289 (I’ve not checked). However, the chip has a TLCLKSEL pin which allows you to set tlclk to either hfclk or hfclk/2, so there is no way to pick a value on reset that works for all cases. The ZSBL inspects this pin when it configures div_int on power up.
Ok, I didn’t know about TLCLKSEL, as it isn’t mentioned in Chapter 7 (Clocking and Reset). The block diagram for PRCI only shows a fixed “/2” between coreclk and tlclk.
Want to ask developers a couple of questions:
1 Why Altium was used for developing of the schematics (not open software, i.e. KiCAD)?
2 Which license are schematic files published under?
Table 57 in section 13.2 indicates div_width=20 for both instances of the UART.
Table 66 in section 13.9 shows the div field as bits 15:0, while the description says “Baud rate divisor. div_width bits wide.” If Table 57 is correct then this field should be bits 19:0.
The LIM and the zero device are not the same. The LIM is directly backed by a fixed amount of SRAM controlled by the L2 way enable register. The zero device is a device which … returns 0s on read and discards writes. However, the zero device is cached, so you can use way locking on the L2 to prevent eviction and turn it into a scratchpad.
The description of the PRCI hfxosccfg register in table 12 in chapter 7 is missing a description for bit 31, which I assume should just be described as Reserved.
The same applies to bits 31:25 for the ddrpllcfg1 and gemgxlpllcfg1 registers in tables 15 and 17 respectively, and bits 31:6 for the devicesresetreg in table 19.
