From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kever Yang Date: Tue, 19 Dec 2017 10:03:55 +0800 Subject: [U-Boot] [PATCH] spl: atf: fix the plat_params In-Reply-To: <43FAC397-0BE4-4C67-8DD2-B3EAD31F1DF7@theobroma-systems.com> References: <1513308437-32162-1-git-send-email-kever.yang@rock-chips.com> <43FAC397-0BE4-4C67-8DD2-B3EAD31F1DF7@theobroma-systems.com> Message-ID: <88032790-95b5-fc7b-afef-b9a5c54c2f2f@rock-chips.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Philipp, On 12/15/2017 05:07 PM, Dr. Philipp Tomsich wrote: > Kever, > > If you need/want to disable this, could you make this conditional on a new > Kconfig option? That way we can disable it for those boards that still ship > with an old ATF That's not an "old" ATF, it's the latest upstream version and wildly used by all the open source community. Many people get from upstream first, and then other forks. > (note that passing NULL also broke the upstream ATF for > quite a number of versions…). A NULL pointer means no parameter for plat_params, and it will not broke upstream ATF. Well, what make me crazy is that every time I update a version from upstream U-Boot, I have to debug for different issues on different boards:( > Alternatively, you could add a board-specific wrapper function that allows > modifying the parameters (as they are plat_params, anyway), e.g.: > atf_entry((void *)bl31_params, board_atf_plat_params(fdt_addr)) > > This would allow you to suppress this for boards that are known to ship > with a ATF that does not yet support this. We should do this before previous patch, right? > > Note that the ATF shipped by us has already been updated, so we can’t > just remove this as it will break functionality for people in the field... You customer should get a complete version with all functionality work from your server, right? It's not totally the same as the upstream version, just like Rockchip have a version on github for evbs, which have been test by our QA. BUT, open source community always get a BROKEN version from upstream :( The upstream source code should have a good support for the boards already upstream, but it broken very frequently. Thanks, - Kever > > Thanks, > Philipp. > >> On 15 Dec 2017, at 04:27, Kever Yang wrote: >> >> The latest upstream ATF still not support using a fdt base as plat_params, >> I get error like this: >> "ERROR: not expected type found 6410029648624618960" >> >> The reason is the ATF source code parse the plat_param, and can not >> decode the type in: >> /* common header for all plat parameter type */ >> struct bl31_plat_param { >> uint64_t type; >> void *next; >> }; >> void params_early_setup(void *plat_param_from_bl2) >> plat/rockchip/common/params_setup.c >> >> We can only use the fdt_addr as plat_params after upstream ATF able to >> parse it. >> >> BUGFIX to: >> 1d37909 spl: atf: introduce spl_invoke_atf and make bl31_entry private >> >> Signed-off-by: Kever Yang >> --- >> >> common/spl/spl_atf.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c >> index 63557c0..a65d603 100644 >> --- a/common/spl/spl_atf.c >> +++ b/common/spl/spl_atf.c >> @@ -96,7 +96,7 @@ static void bl31_entry(uintptr_t bl31_entry, uintptr_t bl33_entry, >> raw_write_daif(SPSR_EXCEPTION_MASK); >> dcache_disable(); >> >> - atf_entry((void *)bl31_params, (void *)fdt_addr); >> + atf_entry((void *)bl31_params, NULL); >> } >> >> static int spl_fit_images_find_uboot(void *blob) >> -- >> 1.9.1 >> >