* Help requested with Barebox on Globalscale Mirabox @ 2018-07-31 13:21 Leigh Brown 2018-08-06 18:36 ` Uwe Kleine-König 0 siblings, 1 reply; 4+ messages in thread From: Leigh Brown @ 2018-07-31 13:21 UTC (permalink / raw) To: Barebox Hello, I'm trying to get Barebox working on my Globalscale Mirabox, and I'm struggling. I have performed the following: 1. git clone git://git.pengutronix.de/barebox 2. cd into barebox and copy extracted binary.0 into arch/arm/boards/globalscale-mirabox/ 3. Edit arch/arm/boards/globalscale-mirabox/kwbimage.cfg and change BOOT_FROM from nand to uart 3. make ARCH=arm mvebu_defconfig 4. make ARCH=arm menuconfig -> then disable all boards except Mirabox Finally, I used kwboot to boot the image as shown below: $ scripts/kwboot -t -b images/barebox-globalscale-mirabox.img -B 115200 /dev/ttyUSB0 Sending boot message. Please reboot the target... BootROM 1.08 Pattern detected on UART0 (Boot) Got expected NAKs Sending boot image... 0 % [S.....................................................................] 2 % [......................................................................] 4 % [......................................................................] 7 % [......................................................................] 9 % [......................................................................] 11 % [..................................DDR3 Training Sequence - Ver 2.1.6 DDR3 Training Sequence - Number of DIMMs detected: 1 DDR3 Training Sequence - Ended Successfully ....................................] 14 % [......................................................................] 16 % [......................................................................] 19 % [......................................................................] 21 % [......................................................................] 23 % [......................................................................] 26 % [......................................................................] 28 % [......................................................................] 31 % [......................................................................] 33 % [......................................................................] 35 % [......................................................................] 38 % [......................................................................] 40 % [......................................................................] 43 % [......................................................................] 45 % [......................................................................] 47 % [......................................................................] 50 % [......................................................................] 52 % [......................................................................] 54 % [......................................................................] 57 % [......................................................................] 59 % [......................................................................] 62 % [......................................................................] 64 % [......................................................................] 66 % [......................................................................] 69 % [......................................................................] 71 % [......................................................................] 74 % [......................................................................] 76 % [......................................................................] 78 % [......................................................................] 81 % [......................................................................] 83 % [......................................................................] 86 % [......................................................................] 88 % [......................................................................] 90 % [......................................................................] 93 % [......................................................................] 95 % [......................................................................] 98 % [............................................................] [Type Ctrl-\ + c to quit] \x06 ..and that's it. Have I missed any steps? Any help would be greatly appreciated. Regards, Leigh. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Help requested with Barebox on Globalscale Mirabox 2018-07-31 13:21 Help requested with Barebox on Globalscale Mirabox Leigh Brown @ 2018-08-06 18:36 ` Uwe Kleine-König 2018-08-09 15:14 ` Leigh Brown 0 siblings, 1 reply; 4+ messages in thread From: Uwe Kleine-König @ 2018-08-06 18:36 UTC (permalink / raw) To: Leigh Brown; +Cc: Barebox Hello Leigh, On Tue, Jul 31, 2018 at 02:21:04PM +0100, Leigh Brown wrote: > Have I missed any steps? Any help would be greatly appreciated. Looks good. Which revision are you on (i.e. git rev-parse @ in your barebox copy)? What is currently running on the device? Do you get an U when applying this patch?: diff --git a/arch/arm/boards/globalscale-mirabox/lowlevel.c b/arch/arm/boards/globalscale-mirabox/lowlevel.c index 69786c88fb22..6abf96592496 100644 --- a/arch/arm/boards/globalscale-mirabox/lowlevel.c +++ b/arch/arm/boards/globalscale-mirabox/lowlevel.c @@ -31,5 +31,6 @@ ENTRY_FUNCTION(start_globalscale_mirabox, r0, r1, r2) fdt = __dtb_armada_370_mirabox_bb_start + get_runtime_offset(); + writel(0x55, 0xd0012000); armada_370_xp_barebox_entry(fdt); } I just tried 7ba0f2d29959256025ece9ae961a6c3421445a7f on my ReadyNAS 104 which has an armada370, too. I hangs when using second-stage booting from the Vendor U-Boot after: barebox 2018.07.0-00139-g7ba0f2d29959-dirty #50 Mon Aug 6 20:27:11 CEST 2018 Board: Marvell Armada 370/XP SoC: Marvell 6710 rev 1 mdio_bus: miibus0: probed eth1: got preset MAC address: 28:c6:8e:36:df:57 When enabling DEBUG_INITCALLS I got a prompt, hmm. Didn't debug that further. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Help requested with Barebox on Globalscale Mirabox 2018-08-06 18:36 ` Uwe Kleine-König @ 2018-08-09 15:14 ` Leigh Brown 2018-08-10 7:59 ` Uwe Kleine-König 0 siblings, 1 reply; 4+ messages in thread From: Leigh Brown @ 2018-08-09 15:14 UTC (permalink / raw) To: Uwe Kleine-König; +Cc: Barebox Hi Uwe, On 2018-08-06 19:36, Uwe Kleine-König wrote: > Hello Leigh, > > On Tue, Jul 31, 2018 at 02:21:04PM +0100, Leigh Brown wrote: >> Have I missed any steps? Any help would be greatly appreciated. > > Looks good. > > Which revision are you on (i.e. git rev-parse @ in your barebox copy)? > What is currently running on the device? I was running against the same revision as you tried (445a7f). I'm now running against the latest revision (3307e8) with the same issue. > Do you get an U when applying this patch?: [snip patch] I did. Thanks very much for that hint, it helped me debug the issue. I am booting from the UART as follows: scripts/kwboot -t -b images/barebox-globalscale-mirabox.img -B 115200 /dev/ttyUSB0 I believe the issue is that in arch/arm/mach-mvebu/common.c the function armada_370_xp_barebox_entry() calls mvebu_remap_registers() before the stack is set up (it looks like the SP points somewhere in the SRAM range). As mvebu_remap_registers() as compiled by my version of gcc uses the stack, it fails to return. Making mvebu_remap_registers() inline fixes the issue, as per the following patch: diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c index 83aeb41ae..588cef515 100644 --- a/arch/arm/mach-mvebu/common.c +++ b/arch/arm/mach-mvebu/common.c @@ -183,11 +183,15 @@ mem_initcall(mvebu_meminit); * There no way to determine internal registers base address * safely later on, as the remap register itself is within the * internal registers. + * + * As this function may be called before we have a working stack, + * make it inline to avoid the possibility of using the stack. + * */ #define MVEBU_BRIDGE_REG_BASE 0x20000 #define DEVICE_INTERNAL_BASE_ADDR (MVEBU_BRIDGE_REG_BASE + 0x80) -static void mvebu_remap_registers(void) +static inline void mvebu_remap_registers(void) { void __iomem *base = mvebu_get_initial_int_reg_base(); > I just tried 7ba0f2d29959256025ece9ae961a6c3421445a7f on my ReadyNAS > 104 > which has an armada370, too. > > I hangs when using second-stage booting from the Vendor U-Boot after: > > barebox 2018.07.0-00139-g7ba0f2d29959-dirty #50 Mon Aug 6 20:27:11 > CEST 2018 > > > Board: Marvell Armada 370/XP > SoC: Marvell 6710 rev 1 > mdio_bus: miibus0: probed > eth1: got preset MAC address: 28:c6:8e:36:df:57 > > When enabling DEBUG_INITCALLS I got a prompt, hmm. Didn't debug that > further. > > Best regards > Uwe Once I got past that issue I also had an issue in barebox_multi_pbl_start. I think the following patch is the right solution, but I'm not 100% sure. It certainly makes it work for me. diff --git a/arch/arm/cpu/uncompress.c b/arch/arm/cpu/uncompress.c index b07087e4c..5ee80da9d 100644 --- a/arch/arm/cpu/uncompress.c +++ b/arch/arm/cpu/uncompress.c @@ -50,7 +66,7 @@ void __noreturn barebox_multi_pbl_start(unsigned long membase, void *pg_start; unsigned long pc = get_pc(); - image_end = (void *)&image_end_marker + global_variable_offset(); + image_end = (void *)&image_end_marker; if (IS_ENABLED(CONFIG_PBL_RELOCATABLE)) { /* @@ -63,6 +79,8 @@ void __noreturn barebox_multi_pbl_start(unsigned long membase, else relocate_to_adr(membase); } + else + image_end += global_variable_offset(); /* * image_end is the image_end_marker defined above. It is the last location Anyway, with the following two fixes I now have it booting on my Mirabox: barebox 2018.07.0-00143-gf9fc8254b-dirty #53 Thu Aug 9 16:11:01 BST 2018 Board: Marvell Armada 370/XP SoC: Marvell 6710 rev 1 mdio_bus: miibus0: probed pci: pci_scan_bus for bus 0 pci: last_io = 0xffe00000, last_mem = 0xe0000000, last_mem_pref = 0x00000000 pci: pci_scan_bus returning with max=01 pci: pci_scan_bus for bus 1 pci: last_io = 0xffe10000, last_mem = 0xe2000000, last_mem_pref = 0x00000000 pci: pci_scan_bus returning with max=02 malloc space: 0x0fefe600 -> 0x1fdfcbff (size 255 MiB) environment load /dev/env0: No such file or directory Maybe you have to create the partition. running /env/bin/init... /env/bin/init not found barebox:/ Thanks again for your help. I'll now figure out how to get NAND support working. Regards, Leigh. _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Help requested with Barebox on Globalscale Mirabox 2018-08-09 15:14 ` Leigh Brown @ 2018-08-10 7:59 ` Uwe Kleine-König 0 siblings, 0 replies; 4+ messages in thread From: Uwe Kleine-König @ 2018-08-10 7:59 UTC (permalink / raw) To: Leigh Brown; +Cc: Barebox Hello Leigh, On Thu, Aug 09, 2018 at 04:14:48PM +0100, Leigh Brown wrote: > On 2018-08-06 19:36, Uwe Kleine-König wrote: > > Hello Leigh, > > > > On Tue, Jul 31, 2018 at 02:21:04PM +0100, Leigh Brown wrote: > > > Have I missed any steps? Any help would be greatly appreciated. > > > > Looks good. > > > > Which revision are you on (i.e. git rev-parse @ in your barebox copy)? > > What is currently running on the device? > > I was running against the same revision as you tried (445a7f). I'm now > running against the latest revision (3307e8) with the same issue. > > > Do you get an U when applying this patch?: > [snip patch] > > I did. Thanks very much for that hint, it helped me debug the issue. I am > booting from the UART as follows: > > scripts/kwboot -t -b images/barebox-globalscale-mirabox.img -B 115200 /dev/ttyUSB0 > > I believe the issue is that in arch/arm/mach-mvebu/common.c the function > armada_370_xp_barebox_entry() calls mvebu_remap_registers() before the > stack is set up (it looks like the SP points somewhere in the SRAM > range). As mvebu_remap_registers() as compiled by my version of gcc > uses the stack, it fails to return. > > Making mvebu_remap_registers() inline fixes the issue, as per the following > patch: > > diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c > index 83aeb41ae..588cef515 100644 > --- a/arch/arm/mach-mvebu/common.c > +++ b/arch/arm/mach-mvebu/common.c > @@ -183,11 +183,15 @@ mem_initcall(mvebu_meminit); > * There no way to determine internal registers base address > * safely later on, as the remap register itself is within the > * internal registers. > + * > + * As this function may be called before we have a working stack, > + * make it inline to avoid the possibility of using the stack. > + * > */ > #define MVEBU_BRIDGE_REG_BASE 0x20000 > #define DEVICE_INTERNAL_BASE_ADDR (MVEBU_BRIDGE_REG_BASE + 0x80) > > -static void mvebu_remap_registers(void) > +static inline void mvebu_remap_registers(void) > { > void __iomem *base = mvebu_get_initial_int_reg_base(); I think this makes sense. Which toolchain are you using? Can you provide (also for the problem below) your images/start_globalscale_mirabox.pbl compiled from an unchanged tree (for example 3307e8)? > > I just tried 7ba0f2d29959256025ece9ae961a6c3421445a7f on my ReadyNAS 104 > > which has an armada370, too. > > > > I hangs when using second-stage booting from the Vendor U-Boot after: > > > > barebox 2018.07.0-00139-g7ba0f2d29959-dirty #50 Mon Aug 6 20:27:11 CEST 2018 > > > > > > Board: Marvell Armada 370/XP > > SoC: Marvell 6710 rev 1 > > mdio_bus: miibus0: probed > > eth1: got preset MAC address: 28:c6:8e:36:df:57 > > Once I got past that issue I also had an issue in barebox_multi_pbl_start. I > think the following patch is the right solution, but I'm not 100% sure. It > certainly makes it work for me. I'm 100% sure, this is wrong :-) You said you're using mvebu_defconfig and just disabled some machines, right? So you have CONFIG_PBL_RELOCATABLE=y and then hit the else branch in the check if the image is in RAM? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-08-10 7:59 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-31 13:21 Help requested with Barebox on Globalscale Mirabox Leigh Brown 2018-08-06 18:36 ` Uwe Kleine-König 2018-08-09 15:14 ` Leigh Brown 2018-08-10 7:59 ` Uwe Kleine-König
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox