[PATCH V4 2/2] riscv: board: Support OpenPiton SoC

Tianrui Wei tianrui-wei at outlook.com
Sat May 8 06:59:05 CEST 2021


Hi Bin,


On 5/7/2021 9:43 PM, Bin Meng wrote:
> On Fri, May 7, 2021 at 9:17 PM Sean Anderson <seanga2 at gmail.com> wrote:
>> On 5/7/21 9:11 AM, Bin Meng wrote:
>>> On Fri, May 7, 2021 at 9:03 PM Sean Anderson <seanga2 at gmail.com> wrote:
>>>> On 5/6/21 11:48 PM, Tianrui Wei wrote:
>>>>> On 5/7/2021 11:41 AM, Sean Anderson wrote:
>>>>>> On 5/6/21 11:28 PM, Tianrui Wei wrote:
>>>>>>> On 5/7/2021 11:15 AM, Sean Anderson wrote:
>>>>>>>> On 5/6/21 11:06 PM, Tianrui Wei wrote:
>>>>>>>>> Hi Sean,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Many thanks again for reviewing our code! We really appreciate it. Will fix the things you're suggesting ;p Though I have a few questions in line in the comment. Also, checkpatch didn't catch any of the identation issues. I was wondering if there are some specific flags to enable some of the checks? I'm running ./utils/checkpatch.pl this.patch right now.
>>>>>>>>>
>>> [snip]
>>>
>>>>>>>>>
>>>>>>>>> No we don't support fit yet for some hardware reasons.
>>>>>>>> Can you elaborate on that? I wasn't aware of any restrictions in this
>>>>>>>> area.
>>>>>>>
>>>>>>> So OpenPiton is actually some kind of SoC generator that generates
>>>>>>> different SoC on FPGA. The device tree was generated at bitstream
>>>>>>> creation time to facilitate different configurations, so each board
>>>>>>> can have different device trees. We're aware of any way to do this in
>>>>>>> FIT.
>>>>>> Oh, so you're saying that the devicetree is placed at a specific address
>>>>>> in hardware? Does it need any fixups?
>>>>>
>>>>> No for now we just embed it in SPL, will be converted into the bootrom for the chip with a small ZSBL.
>>>> Well, atm you are using the DTS embedded in U-Boot.
>>>>
>>>> I don't know what the correct way to do this is...
>>>>
>>>> +CC Bin, Heinrich: Do you have a comment on this?
>>> I am not sure I followed this correctly. Ideally we should use OF_SEPARATE.
>> As I understand it, Tianrui would like to use the same FDT that U-Boot
>> uses for Linux as well. Is doing something like
>>
>>>> +    "fdt addr ${fdtcontroladdr}; " \
>>>> +    "fdt move ${fdtcontroladdr} ${fdt_addr_r}; " \
>>>> +    "booti ${loadaddr} - ${fdt_addr_r}; "
> Does "booti loadaddr - fdtcontroladdr" work? Or we have to do "fdt move"?


Yes that would work, many thanks for pointing that out.


>
>> the right way to go about this? Can any other platforms be used as a
>> reference here (perhaps qemu)?
> I think this way is okay, as long as U-Boot's device tree is the
> superset of the Linux one.
>
> Regards,
> Bin


Many thanks for your time and feedback, we really appreciate it!

Tianrui



More information about the U-Boot mailing list