Hi,
Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks
Which nice copy of our approach. :-)
Hmmm... is it true? This approach being used since few years back at NIOS soft processor. Besides that, we are utilizing the SPL framework for our second stage boot loader. I believe you guys are not using SPL right? It seems you guys would need tools to generate and even build you guys own version of boot loader. It creates high dependency for user to your tools.
Interesting discussion. :-) I believe we will use SPL at some point in future for Microblaze just because of easier maintenance . But will see.
Yup, utilizing SPL will gain you the power of open source :)
I don't understand your point regarding to tool dependency. For DTSes I believe you are also generating this structure from design tools or you can write it by hand. We are also generating U-boot configuration but if someone wants to write it by hand they can.
I believe we have misalignment on the term used. For us, second stage bootloader is referring to the bootloader loaded by BootROM. I believe you guys are referring that as FSBL.
For our solution, customer can just grab the code from git and build it using the normal U-Boot way (if they don't want to use the tools). With the SPL also, we are taking advantage of open source community power to make our second stage boot loader more powerful and user friendly to user. Our user can grab any drivers or leverage the supports from the open community too. I believe that is the power of open source :)
We have the same for Microblaze and Zynq.
Same as above, I believe both of us are using U-Boot. But for bootloader before U-Boot, we are using SPL while you guys using FSBL which is not SPL framework, right? With that, I believe you guys would need a proprietary tools to compile and build the FSBL. We would not have this dependency when building the SPL code.
Thanks Chin Liang
Cheers, Michal