Hi.
I’m working on the Unleashed board bare-metal using a Segger J-Link.
I’ve downloaded the Linux source code so I have some reference material to allow me to create a bare-metal bsp.
However, there are registers which Linux is using which aren’t even mentioned in the FU540-C000-v1.0.pdf document.
How can this be?
How can I get an up to date version of the document FU540-C000-v?.?.pdf?
Thanks
Andy
What exactly do you mean by “register”? A csr? A memory mapped I/O location? And which exact registers do you think are missing? It is possible that there are problems with the docs, but we can’t fix them if we don’t know what is wrong. I believe that we have only published one version of the FU540-C000 docs so you do have the latest version.
Hi Jim. Thanks for getting back. I’m looking at the PRCI registers. On p40 of FU540-C000-v1.0.pdf after the reg corepllcfg0 at offset 0x4 there is nothing at offset 0x8, yet in the Linux bsp code there is corepllout which is used in the Linux call arch_cpu_init(). Also, in the Linux bsp at offset 0xf0 there is the reg procmoncfg, where in the doc there is nothing. I realise these registers may not be very important, but trying to put this together in bare-metal is fairly challenging for me, and when I find some reg which obviously exist for a purpose and are not documented, I wonder how many others might there be? Thanks in advence for any comments you can give me. Andy
I’m not an expert in this area. I don’t know what you mean by linux bsp. Is that Segger code you are looking at?
Maybe there is more than one version of the prci, the u540 shipped with an early version, and current versions have a different memory map. The latest ASIC is the FE310-G002. If you look at that manual, you can find the pllcfg reg at offset 8, and procmoncfg at 0xf0. In the u540 docs, the pllcfg reg is at offset 4, suggesting that these are different prci versions. If you are looking at source code for the hifive1 revb segger support, then the memory map may be different than the hifive1 unleashed.
Or maybe the u540 docs are wrong, and the FE310-G002 docs are correct.
Hi Jim.
By Linux bsp I mean I downloaded the Linux the Unleashed ships with from Git and looked through the source as a starting point for creating my own bare-metal bsp. So the registers I mentioned must have been in the Unleashed from day 1.
Then when I went through the Linux bsp source and compared it with the contents of FU540-C000-v1.0.pdf I realised the source was referring to reg which were not in the .pdf.
So this really has nothing to do with the HiFive1 or the FE310-G002.
I’d just like to be able to find a pdf which accurately represents the reg which are in the Unleashed.
What are my chances? :0)
Thanks
Andy
What git hash (commit id) of the linux code are you looking at?
Please file a bug/issue in the corresponding github linux repository (or freedom-u-sdk) and I can lobby to get resources to look at it and update our documentation.
Hi Andy,
This is the current FU540 PRCI driver for Linux:
There shouldn’t be anything else in upstream Linux that reads or writes PRCI registers directly. That driver should be a good basis for your bare-metal BSP. As far as my recollection goes, all of the registers in that driver were documented in the user manual PDF.
I would suggest using the upstream Linux kernel, rather than the freedom-u-sdk Linux kernel, for your bare-metal SDK work.
Something to bear in mind is that the Linux driver doesn’t configure all of the PRCI. The driver requires, for example, that the DDRPLL has been set up by the bootloader. Otherwise Linux wouldn’t be able to boot at all.
This is confusing, as we don’t have a “linux bsp”. I tried looking at the current and v1_0 branch freedom-u-sdk sources and found nothing relevant. But then it occurred to me to check the boot loader sources, and in there I found a file that mentions undocumented prci registers. See for instance
But I’m still confused, because arch_cpu_init is apparently a linux kernel call, and I can find no corepllout in the linux kernel sources, either current or original.
Andy, you need to be much more precise about what exactly you are talking about. Please stop saying “linux bsp” because we don’t have one. Use the actual names of the projects and files that you are looking at. And mentioning a git commit id as Troy suggested would be a good idea too. If you can point at a line of code that we can find and look at, then we can give a better answer. But right now we are guessing because we don’t know what you are talking about.
Thanks everyone for your comments.
Jim, I’ll go through exactly the steps I went through and give you exact file names and line numbers.
From the HiFive Unleashed page on the sifive site: “https://www.sifive.com/boards/hifive-unleashed”
I chose the “Freedom U SDK” link, which took me to: “https://github.com/sifive/freedom-u-sdk”
Then I downloaded and unzipped the .zip file: freedom-u-sdk-master.zip
Then I ran “git submodule update --recursive --init” from the command line.
Afaik, this downloaded all the Linux source which is used to build the Linux which is supplied with the HiFive Unleashed. That’s why I thought it was ok to call the bsp code within it, the “Linux bsp”.
I then searched within the Linux project for “hifive” which led me to the file: “HiFive_U-Boot\arch\riscv\cpu\HiFive\cpu.c”
In this file at L 16 I found the struct “hifive_prci_regs”
I then compared it’s contents with the PRCI register map on page 40, section 7.3 of the .pdf FU540-C000-v1.0 and found some differences.
One differences is:
At line 20 of cpu.c there is a register COREPLLOUT. This is at offset 0x8 within the struct. In the register map there is nothing at offset 0x8.
When I looked in cpu.c at the code setting up the core PLL I found this register was set to 0x80000000 at line 56 in the function “arch_cpu_init()”, so clearly it’s important.
Hence I realised there was code being used in the default Linux image which was not described in the Unleashed manual U540-C000-v1.0.pdf
This led me to conclude I didn’t have the latest version of the manual.
So, however many incorrect conclusions I may have made, that’s how I got to where I am now.
Thanks everyone for your help
Andy
You are not looking at the source tree that shipped with the board. That is found on the v1_0 branch, and is now considered obsolete. This has old versions of everything. freedom-u-sdk has since been refreshed with newer versions of everything, and is very different than the original source that gets shipped with the board.
Those are u-boot sources you are looking at, specifically the m-mode u-boot port originally done at Microsemi. u-boot is an alternate boot loader, to replace bbl, which is the one currently on your board. Though there is already a different s-mode u-boot port upstream, and so this one will either be merged into the upstream one (preferably) or dropped. The boot loader is something separate from the linux kernel, and there are also other boot loaders like coreboot.
This u-boot port is probably based on our opensource fsbl sources, and the fsbl sources did have a header file that listed lots of undocumented registers.
OK, so now we know what you are talking about, and we can see about getting docs updated, but that could take a while.
Thanks for your very clear explanation Jim.
I’d no idea there was so much going on behing the scenes. It seems the booting is still in a state of flux, and as such I’d not expect a new doc until the booting has been settled on. In any case, I don’t really need a new doc, I just made the incorrect assumption that there would be one.
I hope the ongoing development of the Unleashed board goes well.
Thanks
Andy
Upstream linux does not currently support running in M-mode, so it maybe not be the best starting point for ‘bare metal’ machine-mode development.
It does appear we have an undocumented register we use in the FSBL