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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
