| Message ID | 20200213060400.26709-1-sr@denx.de |
|---|---|
| State | Accepted |
| Commit | fb9acad30562177287d8cffec19e5dfa6f072de7 |
| Headers | show |
| Series | [v3] mips: cmd: go: Flush cache before jumping to app/image | expand |
Hi Daniel, On 13.02.20 07:04, Stefan Roese wrote: > It has been noticed on MT7628/88 platforms, that booting the RAM image > does not work reliably. Sometimes it works and sometimes not. Debugging > showed that this "might" be a cache related issue as very strange > errors occurred (e.g. output corrupted etc). > > This patch adds a cache flush for the complete SDRAM area to the go cmd > before jumping to the entry point for the MIPS architecture. The > complete area is flushed as we don't know at this point, how big the > area of the "application" really is. > > Signed-off-by: Stefan Roese <sr at denx.de> > Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> > Tested-by: Mauro Condarelli <mc5686 at mclink.it> > Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> > Cc: Mauro Condarelli <mc5686 at mclink.it> > Cc: Weijie Gao <weijie.gao at mediatek.com> Just checking. What is the status of this patch? I don't see it in your "next" branch. Thanks, Stefan > --- > v3: > - Use gd->ram_top instead of gd->bd->bi_memsize for memory size > calculation as suggested by Daniel > > v2: > - Moved cache flush into weak do_go_exec() to make this changed > mips only > > arch/mips/lib/Makefile | 1 + > arch/mips/lib/boot.c | 23 +++++++++++++++++++++++ > 2 files changed, 24 insertions(+) > create mode 100644 arch/mips/lib/boot.c > > diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile > index 589bc651f9..24a72d9c97 100644 > --- a/arch/mips/lib/Makefile > +++ b/arch/mips/lib/Makefile > @@ -11,5 +11,6 @@ obj-y += stack.o > obj-y += traps.o > > obj-$(CONFIG_CMD_BOOTM) += bootm.o > +obj-$(CONFIG_CMD_GO) += boot.o > > lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o > diff --git a/arch/mips/lib/boot.c b/arch/mips/lib/boot.c > new file mode 100644 > index 0000000000..db862f6379 > --- /dev/null > +++ b/arch/mips/lib/boot.c > @@ -0,0 +1,23 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2020 Stefan Roese <sr at denx.de> > + */ > + > +#include <common.h> > +#include <command.h> > +#include <cpu_func.h> > + > +DECLARE_GLOBAL_DATA_PTR; > + > +unsigned long do_go_exec(ulong (*entry)(int, char * const []), > + int argc, char * const argv[]) > +{ > + /* > + * Flush cache before jumping to application. Let's flush the > + * whole SDRAM area, since we don't know the size of the image > + * that was loaded. > + */ > + flush_cache(gd->bd->bi_memstart, gd->ram_top - gd->bd->bi_memstart); > + > + return entry(argc, argv); > +} > Viele Gr??e, Stefan
Hi Stefan, Am 06.04.20 um 12:06 schrieb Stefan Roese: > Hi Daniel, > > On 13.02.20 07:04, Stefan Roese wrote: >> It has been noticed on MT7628/88 platforms, that booting the RAM image >> does not work reliably. Sometimes it works and sometimes not. Debugging >> showed that this "might" be a cache related issue as very strange >> errors occurred (e.g. output corrupted etc). >> >> This patch adds a cache flush for the complete SDRAM area to the go cmd >> before jumping to the entry point for the MIPS architecture. The >> complete area is flushed as we don't know at this point, how big the >> area of the "application" really is. >> >> Signed-off-by: Stefan Roese <sr at denx.de> >> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> >> Tested-by: Mauro Condarelli <mc5686 at mclink.it> >> Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> >> Cc: Mauro Condarelli <mc5686 at mclink.it> >> Cc: Weijie Gao <weijie.gao at mediatek.com> > > Just checking. What is the status of this patch? I don't see it in your > "next" branch. > sorry for the inactivity, but for the last six weeks I was quite busy with business travel and day job. I'll rebuild the next branch and go through patchwork when the merge window opens. I guess it's to late for 2020.04 to squeeze some fixes in ;)
Hi Daniel, On 06.04.20 12:47, Daniel Schwierzeck wrote: >> On 13.02.20 07:04, Stefan Roese wrote: >>> It has been noticed on MT7628/88 platforms, that booting the RAM image >>> does not work reliably. Sometimes it works and sometimes not. Debugging >>> showed that this "might" be a cache related issue as very strange >>> errors occurred (e.g. output corrupted etc). >>> >>> This patch adds a cache flush for the complete SDRAM area to the go cmd >>> before jumping to the entry point for the MIPS architecture. The >>> complete area is flushed as we don't know at this point, how big the >>> area of the "application" really is. >>> >>> Signed-off-by: Stefan Roese <sr at denx.de> >>> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> >>> Tested-by: Mauro Condarelli <mc5686 at mclink.it> >>> Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> >>> Cc: Mauro Condarelli <mc5686 at mclink.it> >>> Cc: Weijie Gao <weijie.gao at mediatek.com> >> >> Just checking. What is the status of this patch? I don't see it in your >> "next" branch. >> > > sorry for the inactivity, but for the last six weeks I was quite busy > with business travel and day job. No problem. I was just checking. ;) > I'll rebuild the next branch and go > through patchwork when the merge window opens. I guess it's to late for > 2020.04 to squeeze some fixes in ;) I don't have a hard need for this patch in the upcoming 2020.04 release. So feel free to include it in the next merge window instead. Thanks, Stefan
Am 13.02.20 um 07:04 schrieb Stefan Roese: > It has been noticed on MT7628/88 platforms, that booting the RAM image > does not work reliably. Sometimes it works and sometimes not. Debugging > showed that this "might" be a cache related issue as very strange > errors occurred (e.g. output corrupted etc). > > This patch adds a cache flush for the complete SDRAM area to the go cmd > before jumping to the entry point for the MIPS architecture. The > complete area is flushed as we don't know at this point, how big the > area of the "application" really is. > > Signed-off-by: Stefan Roese <sr at denx.de> > Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> > Tested-by: Mauro Condarelli <mc5686 at mclink.it> > Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com> > Cc: Mauro Condarelli <mc5686 at mclink.it> > Cc: Weijie Gao <weijie.gao at mediatek.com> > --- > v3: > - Use gd->ram_top instead of gd->bd->bi_memsize for memory size > calculation as suggested by Daniel > > v2: > - Moved cache flush into weak do_go_exec() to make this changed > mips only > > arch/mips/lib/Makefile | 1 + > arch/mips/lib/boot.c | 23 +++++++++++++++++++++++ > 2 files changed, 24 insertions(+) > create mode 100644 arch/mips/lib/boot.c > applied to u-boot-mips/next, thanks.
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 589bc651f9..24a72d9c97 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -11,5 +11,6 @@ obj-y += stack.o obj-y += traps.o obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_CMD_GO) += boot.o lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o diff --git a/arch/mips/lib/boot.c b/arch/mips/lib/boot.c new file mode 100644 index 0000000000..db862f6379 --- /dev/null +++ b/arch/mips/lib/boot.c @@ -0,0 +1,23 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 Stefan Roese <sr at denx.de> + */ + +#include <common.h> +#include <command.h> +#include <cpu_func.h> + +DECLARE_GLOBAL_DATA_PTR; + +unsigned long do_go_exec(ulong (*entry)(int, char * const []), + int argc, char * const argv[]) +{ + /* + * Flush cache before jumping to application. Let's flush the + * whole SDRAM area, since we don't know the size of the image + * that was loaded. + */ + flush_cache(gd->bd->bi_memstart, gd->ram_top - gd->bd->bi_memstart); + + return entry(argc, argv); +}