Implementing a check on FDT header

[Christian Mauderer]

Am 05.03.2018 um 16:03 schrieb Udit agarwal:
> Hi,
> While going through uboot docs, i found something intresting:
> Here <https://www.denx.de/wiki/DULG/UBootCmdGroupExec>(Sec: 5.9.4.2), It
> is given that if FDT is not passed as the third argument to bootm
> command then, by default a data structure called bd_info(given here
> <https://github.com/u-boot/u-boot/blob/53193a4f07c9e7a7d42493863712352cf16f1258/include/asm-generic/u-boot.h>)
> is passed instread of the pointer to fdt. Thus, the argument being
> passed to bsp_fdt_copy function during start.S shouldn't be random(or NULL).

I'm still not so sure here.

With bootm. This one calls the do_bootm_states() which in turn calls the
boot_selected_os() with a boot_fn as an argument (see [1] at the end of
the mail).

The boot_fn can be one of the do_bootm_rtems() (see [2]) or
do_bootm_linux(). The later one is architecture specific. In our case it
would be [3].

So depending on whether you have build an RTEMS style image or a Linux
style image, you might get different values in the registers.

> Now, checking for the presence of bd_info can allow us to load an empty
> FDT in case of missing bootm param. I did load media01 test with empty
> FDT and it didn't crashed(Logs:here
> <https://gist.github.com/madaari/74ba18a375e320108587a0d29cda6985>).
> In case, if the FDT is loaded by the user, now we can implement a FDT
> header check to confirm it's validity.One possible way to do that could
> be via libfdt(there's a build in function that checks for magic number)
> as given in this
> <https://github.com/RTEMS/rtems/tree/5eb769ca8b553b4378a773967f08de20847794db/testsuites/libtests/libfdt01>
> test.

Most likely libfdt would be the right way.

> Other possible way(I am not sure about it) could be a validy check
> within uboot itself(Given here
> <https://lists.denx.de/pipermail/u-boot/2012-March/121281.html>).
> 
> Moreover, I have a doubt, Why is uboot RTEMS format depreciated as per
> your discussions in previous threads?

It currently isn't. I only said that it might would be a good idea to
deprecate it somewhen in the near future. The reason for this is exactly
this kind of problem. We have multiple methods to boot and so we have to
find a solution that works for all of them. If we are fixed to one
method (like Linux style) it could be a lot simpler. One problem with
that could be that Linux seems to use a lot of formats for different
platforms. If we are running on a platform where there is no Linux
support we can't use Linux format. So a RTEMS might would be necessary
as a fallback for these platforms.

That's one of the points why I said: This topic might need some
discussion on the mailing list. It's great if you keep that discussion
running but it's purely optional for your GSoC project. So maybe you
shouldn't put too much energy into it before you have done most or all
of the mandatory things for your GSoC project. For example you should
think about a first draft for your proposal on the GSoC tracking page.

Best regards

Christian

> Thanks!
> Regards,
> Udit agarwal 

[1]
https://github.com/u-boot/u-boot/blob/53193a4f07c9e7a7d42493863712352cf16f1258/common/bootm.c#L711

[2]
https://github.com/u-boot/u-boot/blob/53193a4f07c9e7a7d42493863712352cf16f1258/common/bootm_os.c#L147

[3]
https://github.com/u-boot/u-boot/blob/53193a4f07c9e7a7d42493863712352cf16f1258/arch/arm/lib/bootm.c#L402