From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tianrui Wei Date: Sat, 8 May 2021 12:59:05 +0800 Subject: [PATCH V4 2/2] riscv: board: Support OpenPiton SoC In-Reply-To: References: <5f04532e-bbe8-2ebf-5493-9e0b45a6a8ec@gmail.com> <3712f278-88d3-ae1a-03fb-04d0083d90ba@gmail.com> <40dedd43-0af7-ce90-839e-cde2b52f1486@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Bin, On 5/7/2021 9:43 PM, Bin Meng wrote: > On Fri, May 7, 2021 at 9:17 PM Sean Anderson wrote: >> On 5/7/21 9:11 AM, Bin Meng wrote: >>> On Fri, May 7, 2021 at 9:03 PM Sean Anderson 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