On 5/7/21 9:11 AM, Bin Meng wrote:
On Fri, May 7, 2021 at 9:03 PM Sean Anderson <sean...@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}; "
the right way to go about this? Can any other platforms be used as a
reference here (perhaps qemu)?
--Sean
Also, now that you mention fixups u-boot spl doesn't work at high address like
0xffffff0000 for now. Is that the case?
What happens why you try that?
Regards,
Bin
