barebox PBL question

barebox PBL question

[Wadim Egorov]

Hi,

I would like to add SPL support for the RK3288 SoC to barebox. But I am
facing
a few problems.

The maximum size of the SPL image which the ROM code will read is 32KB.
I was thinking to use the PBL feature for the SPL part. But using the
the pbl code (with decompression) seems to be not a good idea, because
it's size
is already about 30K. I think this is an overhead.

But now I wonder how to generate two different images with a single build.
A SPL image, which should not exceed 32K and a barebox.

I have problems to fully understand the PBL mechanism.
Why are the builds always adding the barebox.bin images to the PBL part?

Here is an example, cat .zbarebox.cmd

ld -EL  -Map arch/arm/pbl/zbarebox.map --gc-sections -static -o
arch/arm/pbl/zbarebox -e pbl_start -T arch/arm/pbl/zbarebox.lds
--start-group  common/built-in-pbl.o [...]  arch/arm/pbl/piggy.shipped.o
--end-group

piggy.shipped.o is barebox.bin, which is added in piggy.shipped.S:

.incbin "arch/arm/pbl/piggy.shipped"

So my question is, how do I generate a seperate PBL image without the
piggy stuff?
My SPL code for RK3288 should just init the SDRAM an then jump back to
ROM code to load the barebox.

Regards,
Wadim

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[Sascha Hauer]

On Mon, Feb 13, 2017 at 04:13:48PM +0100, Wadim Egorov wrote:
> Hi,
> 
> I would like to add SPL support for the RK3288 SoC to barebox. But I am
> facing
> a few problems.
> 
> The maximum size of the SPL image which the ROM code will read is 32KB.
> I was thinking to use the PBL feature for the SPL part. But using the
> the pbl code (with decompression) seems to be not a good idea, because
> it's size
> is already about 30K. I think this is an overhead.

In a test build here the pbl code is 6KiB. The rest is the devicetree
included in the binary (which I disabled in the test build). The dtb can
be compressed which should give you enough space even in 32KiB.

> 
> But now I wonder how to generate two different images with a single build.
> A SPL image, which should not exceed 32K and a barebox.
> 
> I have problems to fully understand the PBL mechanism.
> Why are the builds always adding the barebox.bin images to the PBL part?

The idea is to create an image that contains the PBL and attached to it
the compressed barebox image. If your ROM only allows a certain image
size then make sure the PBL is small enough and tell the ROM to only
load the PBL part of the image. Ideally the PBL then detects from where
the PBL is loaded (by reading back the bootsource the SoC provides) and
reads the rest of the image into SDRAM (or, for sake of simplicity, the
whole image inculding PBL again)

> 
> Here is an example, cat .zbarebox.cmd
> 
> ld -EL  -Map arch/arm/pbl/zbarebox.map --gc-sections -static -o
> arch/arm/pbl/zbarebox -e pbl_start -T arch/arm/pbl/zbarebox.lds
> --start-group  common/built-in-pbl.o [...]  arch/arm/pbl/piggy.shipped.o
> --end-group
> 
> piggy.shipped.o is barebox.bin, which is added in piggy.shipped.S:
> 
> .incbin "arch/arm/pbl/piggy.shipped"

You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
port already does this.

I think your entry function should look something like:

ENTRY_FUNCTION(start_rk3288_phycore_som, r0, r1, r2)
{
	arm_cpu_lowlevel_init();

	if (inside_sdram(get_pc()))
		barebox_arm_entry(0x0, SZ_1G, fdt);

	rk3288_phycore_setup_sdram();

	jump_back_to_rom();
}

I don't know how jump_back_to_rom() should be implemented. Do you have
to return from the entry function to the ROM or does the ROM provide some API
which can be used to chainload the rest of the image?

What you'll need additionally is a tool which encapsulates the image into
a SoC specific container suitable for the ROM.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

RE: barebox PBL question

[Trent Piepho]

> From: barebox [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> Sascha Hauer
> Sent: Monday, February 13, 2017 11:23 AM
> >
> > The maximum size of the SPL image which the ROM code will read is 32KB.
> > I was thinking to use the PBL feature for the SPL part. But using the
> > the pbl code (with decompression) seems to be not a good idea, because
> > it's size is already about 30K. I think this is an overhead.
> 
> In a test build here the pbl code is 6KiB. The rest is the devicetree included in
> the binary (which I disabled in the test build). The dtb can be compressed
> which should give you enough space even in 32KiB.

On socfpga I have 23kB PBL.  But this has code to support multiple board variations
and a memory test function.  A PBL that doesn't need to initialize the board is 18kB.

> > But now I wonder how to generate two different images with a single
> build.
> > A SPL image, which should not exceed 32K and a barebox.
> >
> > I have problems to fully understand the PBL mechanism.
> > Why are the builds always adding the barebox.bin images to the PBL part?
> 
> The idea is to create an image that contains the PBL and attached to it the
> compressed barebox image. If your ROM only allows a certain image size
> then make sure the PBL is small enough and tell the ROM to only load the PBL
> part of the image. Ideally the PBL then detects from where the PBL is loaded
> (by reading back the bootsource the SoC provides) and reads the rest of the
> image into SDRAM (or, for sake of simplicity, the whole image inculding PBL
> again)

The way socfpga does it, which is in some ways easier to implement, is to build
barebox twice.  The first build is minimized with no DT support, no console, etc. to
fit into 64 kB.  It has only drivers needed to load another barebox.  I.e. eMMC bus
driver, code to init SDRAM, etc.
 
The second barebox loaded by this one has SDRAM working when it starts and has
no ROM loader size limit, since it was loaded by barebox.  One can enable all barebox
features without worry about size limits.

But now you have the deal with two copies of barebox to build and install.

> You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
> port already does this.

Is there any advantage to the single image pbl system?  It seems like multi image
with one image achieves the same result.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[Sascha Hauer]

On Mon, Feb 13, 2017 at 08:53:19PM +0000, Trent Piepho wrote:
> > From: barebox [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> > Sascha Hauer
> > Sent: Monday, February 13, 2017 11:23 AM
> > >
> > > The maximum size of the SPL image which the ROM code will read is 32KB.
> > > I was thinking to use the PBL feature for the SPL part. But using the
> > > the pbl code (with decompression) seems to be not a good idea, because
> > > it's size is already about 30K. I think this is an overhead.
> > 
> > In a test build here the pbl code is 6KiB. The rest is the devicetree included in
> > the binary (which I disabled in the test build). The dtb can be compressed
> > which should give you enough space even in 32KiB.
> 
> On socfpga I have 23kB PBL.  But this has code to support multiple board variations
> and a memory test function.  A PBL that doesn't need to initialize the board is 18kB.
> 
> > > But now I wonder how to generate two different images with a single
> > build.
> > > A SPL image, which should not exceed 32K and a barebox.
> > >
> > > I have problems to fully understand the PBL mechanism.
> > > Why are the builds always adding the barebox.bin images to the PBL part?
> > 
> > The idea is to create an image that contains the PBL and attached to it the
> > compressed barebox image. If your ROM only allows a certain image size
> > then make sure the PBL is small enough and tell the ROM to only load the PBL
> > part of the image. Ideally the PBL then detects from where the PBL is loaded
> > (by reading back the bootsource the SoC provides) and reads the rest of the
> > image into SDRAM (or, for sake of simplicity, the whole image inculding PBL
> > again)
> 
> The way socfpga does it, which is in some ways easier to implement, is to build
> barebox twice.  The first build is minimized with no DT support, no console, etc. to
> fit into 64 kB.  It has only drivers needed to load another barebox.  I.e. eMMC bus
> driver, code to init SDRAM, etc.
>  
> The second barebox loaded by this one has SDRAM working when it starts and has
> no ROM loader size limit, since it was loaded by barebox.  One can enable all barebox
> features without worry about size limits.
> 
> But now you have the deal with two copies of barebox to build and install.

Indeed. And this is the main downside of this approach.

> 
> > You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
> > port already does this.
> 
> Is there any advantage to the single image pbl system?  It seems like multi image
> with one image achieves the same result.

The advantage is that the same config and only one build step is used
to build images for multiple boards/projects. This greatly increases the
chance that the existing configs are actually tested. Also it makes it
easy to test the same software on different boards. Another thing is
that I can currently built test every commit in every defconfig,
something I couldn't do if every board had its own defconfig, possibly
in a xload and a regular variant. Defconfig files also have the tendency
to bitrot very fast. Most defconfigs are committed once and never
touched again which means you never get the new features and whenever
you change the board you possibly find a defconfig that needs many
adjustments before you feel home.


Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[Trent Piepho]

On Tue, 2017-02-14 at 08:27 +0100, Sascha Hauer wrote:
> > > You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
> > > port already does this.
> > 
> > Is there any advantage to the single image pbl system?  It seems like multi image
> > with one image achieves the same result.
> 
> The advantage is that the same config and only one build step is used
> to build images for multiple boards/projects. This greatly increases the
> chance that the existing configs are actually tested. Also it makes it
> easy to test the same software on different boards. Another thing is
> that I can currently built test every commit in every defconfig,
> something I couldn't do if every board had its own defconfig, possibly
> in a xload and a regular variant. Defconfig files also have the tendency
> to bitrot very fast. Most defconfigs are committed once and never
> touched again which means you never get the new features and whenever
> you change the board you possibly find a defconfig that needs many
> adjustments before you feel home.

These all sounds like advantages for the multi-pbl system.  I was asking
if the single pbl system had an advantage.  It seems to be mostly a
duplication of multi-pbl that can't do as much.  I wondered if there was
a reason, besides inertia, to keeping it around.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[s.hauer]

On Tue, Feb 14, 2017 at 06:12:15PM +0000, Trent Piepho wrote:
> On Tue, 2017-02-14 at 08:27 +0100, Sascha Hauer wrote:
> > > > You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
> > > > port already does this.
> > > 
> > > Is there any advantage to the single image pbl system?  It seems like multi image
> > > with one image achieves the same result.
> > 
> > The advantage is that the same config and only one build step is used
> > to build images for multiple boards/projects. This greatly increases the
> > chance that the existing configs are actually tested. Also it makes it
> > easy to test the same software on different boards. Another thing is
> > that I can currently built test every commit in every defconfig,
> > something I couldn't do if every board had its own defconfig, possibly
> > in a xload and a regular variant. Defconfig files also have the tendency
> > to bitrot very fast. Most defconfigs are committed once and never
> > touched again which means you never get the new features and whenever
> > you change the board you possibly find a defconfig that needs many
> > adjustments before you feel home.
> 
> These all sounds like advantages for the multi-pbl system.  I was asking
> if the single pbl system had an advantage.  It seems to be mostly a
> duplication of multi-pbl that can't do as much.  I wondered if there was
> a reason, besides inertia, to keeping it around.

I would love to remove it, but grepping through the defconfigs there are
more than 50 boards using it, most of them I cannot test.
Besides this, yes, there's inertia. I just played it through for an AT91
board, see below. We would have to do this 50 times...

Sascha

-------------------------8<---------------------

From 4e81bc5db51c7d91d9fc5c1666e961be7143e09b Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Wed, 15 Feb 2017 08:49:18 +0100
Subject: [PATCH] wip

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/Kconfig                           |  2 +-
 arch/arm/boards/sama5d3xek/Makefile        |  1 +
 arch/arm/boards/sama5d3xek/lowlevel.c      | 10 ++++++++++
 arch/arm/mach-at91/Kconfig                 |  1 +
 arch/arm/mach-at91/sama5d3_lowlevel_init.c |  4 ++++
 images/Makefile                            |  1 +
 images/Makefile.at91                       |  4 ++++
 7 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boards/sama5d3xek/lowlevel.c
 create mode 100644 images/Makefile.at91

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e4663ea268..a5e431d296 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -52,7 +52,7 @@ config ARCH_AT91
 	select GPIOLIB
 	select CLKDEV_LOOKUP
 	select HAS_DEBUG_LL
-	select HAVE_MACH_ARM_HEAD
+	select HAVE_MACH_ARM_HEAD if !HAVE_PBL_MULTI_IMAGES
 	select HAVE_CLK
 	select PINCTRL_AT91
 
diff --git a/arch/arm/boards/sama5d3xek/Makefile b/arch/arm/boards/sama5d3xek/Makefile
index 32dcb4283c..55772623a5 100644
--- a/arch/arm/boards/sama5d3xek/Makefile
+++ b/arch/arm/boards/sama5d3xek/Makefile
@@ -1,3 +1,4 @@
 obj-y += init.o
 obj-$(CONFIG_W1) += hw_version.o
 bbenv-$(CONFIG_DEFAULT_ENVIRONMENT_GENERIC) += defaultenv-sama5d3xek
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/sama5d3xek/lowlevel.c b/arch/arm/boards/sama5d3xek/lowlevel.c
new file mode 100644
index 0000000000..1d52882caf
--- /dev/null
+++ b/arch/arm/boards/sama5d3xek/lowlevel.c
@@ -0,0 +1,10 @@
+#include <common.h>
+#include <asm/barebox-arm-head.h>
+#include <asm/barebox-arm.h>
+
+void __naked sama5d3_barebox_entry(void);
+
+ENTRY_FUNCTION(start_sama5d3xek, r0, r1, r2)
+{
+	sama5d3_barebox_entry();
+}
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index c45fc4d6b8..66cfb2aaae 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -472,6 +472,7 @@ choice
 
 config MACH_SAMA5D3XEK
 	bool "Atmel SAMA5D3X Evaluation Kit"
+	select HAVE_PBL_MULTI_IMAGES
 	help
 	  Select this if you are using Atmel's SAMA5D3X-EK Evaluation Kit.
 
diff --git a/arch/arm/mach-at91/sama5d3_lowlevel_init.c b/arch/arm/mach-at91/sama5d3_lowlevel_init.c
index 01d28514d1..aaff9b8b04 100644
--- a/arch/arm/mach-at91/sama5d3_lowlevel_init.c
+++ b/arch/arm/mach-at91/sama5d3_lowlevel_init.c
@@ -15,7 +15,11 @@
 #include <mach/hardware.h>
 #include <mach/at91sam9_ddrsdr.h>
 
+#ifdef CONFIG_PBL_MULTI_IMAGES
+void __naked sama5d3_barebox_entry(void)
+#else
 void __naked __bare_init barebox_arm_reset_vector(void)
+#endif
 {
 	arm_cpu_lowlevel_init();
 
diff --git a/images/Makefile b/images/Makefile
index 0537af1f6d..f8cd93c365 100644
--- a/images/Makefile
+++ b/images/Makefile
@@ -103,6 +103,7 @@ board = $(srctree)/arch/$(ARCH)/boards
 objboard = $(objtree)/arch/$(ARCH)/boards
 
 include $(srctree)/images/Makefile.am33xx
+include $(srctree)/images/Makefile.at91
 include $(srctree)/images/Makefile.imx
 include $(srctree)/images/Makefile.mvebu
 include $(srctree)/images/Makefile.mxs
diff --git a/images/Makefile.at91 b/images/Makefile.at91
new file mode 100644
index 0000000000..ccb9fef832
--- /dev/null
+++ b/images/Makefile.at91
@@ -0,0 +1,4 @@
+
+pblx-$(CONFIG_MACH_SAMA5D3XEK) += start_sama5d3xek
+FILE_barebox-sama5d3xek.img = start_sama5d3xek.pblx
+image-$(CONFIG_MACH_SAMA5D3XEK) += barebox-sama5d3xek.img
-- 
2.11.0

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[Wadim Egorov]

On 13.02.2017 20:22, Sascha Hauer wrote:
> On Mon, Feb 13, 2017 at 04:13:48PM +0100, Wadim Egorov wrote:
>> Hi,
>>
>> I would like to add SPL support for the RK3288 SoC to barebox. But I am
>> facing
>> a few problems.
>>
>> The maximum size of the SPL image which the ROM code will read is 32KB.
>> I was thinking to use the PBL feature for the SPL part. But using the
>> the pbl code (with decompression) seems to be not a good idea, because
>> it's size
>> is already about 30K. I think this is an overhead.
> In a test build here the pbl code is 6KiB. The rest is the devicetree
> included in the binary (which I disabled in the test build). The dtb can
> be compressed which should give you enough space even in 32KiB.
OK, I think I checked the wrong file size. pblb is the bare binary file

>
>> But now I wonder how to generate two different images with a single build.
>> A SPL image, which should not exceed 32K and a barebox.
>>
>> I have problems to fully understand the PBL mechanism.
>> Why are the builds always adding the barebox.bin images to the PBL part?
> The idea is to create an image that contains the PBL and attached to it
> the compressed barebox image. If your ROM only allows a certain image
> size then make sure the PBL is small enough and tell the ROM to only
> load the PBL part of the image. Ideally the PBL then detects from where
> the PBL is loaded (by reading back the bootsource the SoC provides) and
> reads the rest of the image into SDRAM (or, for sake of simplicity, the
> whole image inculding PBL again)
ty for clarification

>
>> Here is an example, cat .zbarebox.cmd
>>
>> ld -EL  -Map arch/arm/pbl/zbarebox.map --gc-sections -static -o
>> arch/arm/pbl/zbarebox -e pbl_start -T arch/arm/pbl/zbarebox.lds
>> --start-group  common/built-in-pbl.o [...]  arch/arm/pbl/piggy.shipped.o
>> --end-group
>>
>> piggy.shipped.o is barebox.bin, which is added in piggy.shipped.S:
>>
>> .incbin "arch/arm/pbl/piggy.shipped"
> You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
> port already does this.
>
> I think your entry function should look something like:
>
> ENTRY_FUNCTION(start_rk3288_phycore_som, r0, r1, r2)
> {
> 	arm_cpu_lowlevel_init();
>
> 	if (inside_sdram(get_pc()))
> 		barebox_arm_entry(0x0, SZ_1G, fdt);
>
> 	rk3288_phycore_setup_sdram();
>
> 	jump_back_to_rom();
> }
>
> I don't know how jump_back_to_rom() should be implemented. Do you have
> to return from the entry function to the ROM or does the ROM provide some API
> which can be used to chainload the rest of the image?

No, there is no API in the ROM.
In u-boot the spl will return to bootrom in board_init_f(), then bootrom
loads u-boot binary.

Regards,
Wadim

>
> What you'll need additionally is a tool which encapsulates the image into
> a SoC specific container suitable for the ROM.
>
> Sascha
>


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[Sascha Hauer]

On Tue, Feb 14, 2017 at 10:54:49AM +0100, Wadim Egorov wrote:
> 
> On 13.02.2017 20:22, Sascha Hauer wrote:
> > On Mon, Feb 13, 2017 at 04:13:48PM +0100, Wadim Egorov wrote:
> >> Hi,
> >>
> >> I would like to add SPL support for the RK3288 SoC to barebox. But I am
> >> facing
> >> a few problems.
> >>
> >> The maximum size of the SPL image which the ROM code will read is 32KB.
> >> I was thinking to use the PBL feature for the SPL part. But using the
> >> the pbl code (with decompression) seems to be not a good idea, because
> >> it's size
> >> is already about 30K. I think this is an overhead.
> > In a test build here the pbl code is 6KiB. The rest is the devicetree
> > included in the binary (which I disabled in the test build). The dtb can
> > be compressed which should give you enough space even in 32KiB.
> OK, I think I checked the wrong file size. pblb is the bare binary file
> 
> >
> >> But now I wonder how to generate two different images with a single build.
> >> A SPL image, which should not exceed 32K and a barebox.
> >>
> >> I have problems to fully understand the PBL mechanism.
> >> Why are the builds always adding the barebox.bin images to the PBL part?
> > The idea is to create an image that contains the PBL and attached to it
> > the compressed barebox image. If your ROM only allows a certain image
> > size then make sure the PBL is small enough and tell the ROM to only
> > load the PBL part of the image. Ideally the PBL then detects from where
> > the PBL is loaded (by reading back the bootsource the SoC provides) and
> > reads the rest of the image into SDRAM (or, for sake of simplicity, the
> > whole image inculding PBL again)
> ty for clarification
> 
> >
> >> Here is an example, cat .zbarebox.cmd
> >>
> >> ld -EL  -Map arch/arm/pbl/zbarebox.map --gc-sections -static -o
> >> arch/arm/pbl/zbarebox -e pbl_start -T arch/arm/pbl/zbarebox.lds
> >> --start-group  common/built-in-pbl.o [...]  arch/arm/pbl/piggy.shipped.o
> >> --end-group
> >>
> >> piggy.shipped.o is barebox.bin, which is added in piggy.shipped.S:
> >>
> >> .incbin "arch/arm/pbl/piggy.shipped"
> > You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
> > port already does this.
> >
> > I think your entry function should look something like:
> >
> > ENTRY_FUNCTION(start_rk3288_phycore_som, r0, r1, r2)
> > {
> > 	arm_cpu_lowlevel_init();
> >
> > 	if (inside_sdram(get_pc()))
> > 		barebox_arm_entry(0x0, SZ_1G, fdt);
> >
> > 	rk3288_phycore_setup_sdram();
> >
> > 	jump_back_to_rom();
> > }
> >
> > I don't know how jump_back_to_rom() should be implemented. Do you have
> > to return from the entry function to the ROM or does the ROM provide some API
> > which can be used to chainload the rest of the image?
> 
> No, there is no API in the ROM.
> In u-boot the spl will return to bootrom in board_init_f(), then bootrom
> loads u-boot binary.

The ENTRY_FUNCTION macro is not prepared for returning to the caller.

You'll have to replace it with something like:

void __section(.text_head_entry_start_rk3288_phycore_som)
start_start_imx6q_sabrelite(uint32_t r0, uint32_t r1, uint32_t r2)

This makes sure the link register is preserved and is jumped to at the
end of the function.

You could also send me some hardware, I could provide some better help
then. I know this early bringup can be tricky ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox PBL question

[Wadim Egorov]

On 14.02.2017 11:48, Sascha Hauer wrote:
> On Tue, Feb 14, 2017 at 10:54:49AM +0100, Wadim Egorov wrote:
>> On 13.02.2017 20:22, Sascha Hauer wrote:
>>> On Mon, Feb 13, 2017 at 04:13:48PM +0100, Wadim Egorov wrote:
>>>> Hi,
>>>>
>>>> I would like to add SPL support for the RK3288 SoC to barebox. But I am
>>>> facing
>>>> a few problems.
>>>>
>>>> The maximum size of the SPL image which the ROM code will read is 32KB.
>>>> I was thinking to use the PBL feature for the SPL part. But using the
>>>> the pbl code (with decompression) seems to be not a good idea, because
>>>> it's size
>>>> is already about 30K. I think this is an overhead.
>>> In a test build here the pbl code is 6KiB. The rest is the devicetree
>>> included in the binary (which I disabled in the test build). The dtb can
>>> be compressed which should give you enough space even in 32KiB.
>> OK, I think I checked the wrong file size. pblb is the bare binary file
>>
>>>> But now I wonder how to generate two different images with a single build.
>>>> A SPL image, which should not exceed 32K and a barebox.
>>>>
>>>> I have problems to fully understand the PBL mechanism.
>>>> Why are the builds always adding the barebox.bin images to the PBL part?
>>> The idea is to create an image that contains the PBL and attached to it
>>> the compressed barebox image. If your ROM only allows a certain image
>>> size then make sure the PBL is small enough and tell the ROM to only
>>> load the PBL part of the image. Ideally the PBL then detects from where
>>> the PBL is loaded (by reading back the bootsource the SoC provides) and
>>> reads the rest of the image into SDRAM (or, for sake of simplicity, the
>>> whole image inculding PBL again)
>> ty for clarification
>>
>>>> Here is an example, cat .zbarebox.cmd
>>>>
>>>> ld -EL  -Map arch/arm/pbl/zbarebox.map --gc-sections -static -o
>>>> arch/arm/pbl/zbarebox -e pbl_start -T arch/arm/pbl/zbarebox.lds
>>>> --start-group  common/built-in-pbl.o [...]  arch/arm/pbl/piggy.shipped.o
>>>> --end-group
>>>>
>>>> piggy.shipped.o is barebox.bin, which is added in piggy.shipped.S:
>>>>
>>>> .incbin "arch/arm/pbl/piggy.shipped"
>>> You should use PBL_MULTI_IMAGES instead. In fact, the existing Rockchip
>>> port already does this.
>>>
>>> I think your entry function should look something like:
>>>
>>> ENTRY_FUNCTION(start_rk3288_phycore_som, r0, r1, r2)
>>> {
>>> 	arm_cpu_lowlevel_init();
>>>
>>> 	if (inside_sdram(get_pc()))
>>> 		barebox_arm_entry(0x0, SZ_1G, fdt);
>>>
>>> 	rk3288_phycore_setup_sdram();
>>>
>>> 	jump_back_to_rom();
>>> }
>>>
>>> I don't know how jump_back_to_rom() should be implemented. Do you have
>>> to return from the entry function to the ROM or does the ROM provide some API
>>> which can be used to chainload the rest of the image?
>> No, there is no API in the ROM.
>> In u-boot the spl will return to bootrom in board_init_f(), then bootrom
>> loads u-boot binary.
> The ENTRY_FUNCTION macro is not prepared for returning to the caller.
>
> You'll have to replace it with something like:
>
> void __section(.text_head_entry_start_rk3288_phycore_som)
> start_start_imx6q_sabrelite(uint32_t r0, uint32_t r1, uint32_t r2)
>
> This makes sure the link register is preserved and is jumped to at the
> end of the function.
>
> You could also send me some hardware, I could provide some better help
> then. I know this early bringup can be tricky ;)

I will send you our hardware. After the redesign :)

>
> Sascha
>


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox