[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Marek Belisko]

Add support for raspberrypi bootloader and VideoCore.

Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>

Added changes from Arnout comments:
(http://lists.busybox.net/pipermail/buildroot/2012-September/058565.html)
- add rasberrypi-firmware as separate package
- change Config.in handling to have separate bootloader and
  VideoCore packages (handled in same mk file)
- various other fixes

New features:
- add possibility to choose ARM - GPU memory split by user
- download package in tar.gz instead git method

---
 package/Config.in                                  |    1 +
 package/raspberrypi-firmware/Config.in             |   53 ++++++++++++++++++++
 .../raspberrypi-firmware/raspberrypi-firmware.mk   |   48 ++++++++++++++++++
 3 files changed, 102 insertions(+)
 create mode 100644 package/raspberrypi-firmware/Config.in
 create mode 100644 package/raspberrypi-firmware/raspberrypi-firmware.mk

diff --git a/package/Config.in b/package/Config.in
index 58dd5e8..36635cd 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -232,6 +232,7 @@ source "package/owl-linux/Config.in"
 source "package/parted/Config.in"
 source "package/pciutils/Config.in"
 source "package/picocom/Config.in"
+source "package/raspberrypi-firmware/Config.in"
 source "package/read-edid/Config.in"
 source "package/rng-tools/Config.in"
 source "package/sane-backends/Config.in"
diff --git a/package/raspberrypi-firmware/Config.in b/package/raspberrypi-firmware/Config.in
new file mode 100644
index 0000000..55abd68
--- /dev/null
+++ b/package/raspberrypi-firmware/Config.in
@@ -0,0 +1,53 @@
+config BR2_PACKAGE_RASPBERRYPI_FIRMWARE
+	bool
+
+config BR2_PACKAGE_RASPBERRYPI_BOOTLOADER
+        bool "Raspberry Pi bootloader files"
+	select BR2_PACKAGE_RASPBERRYPI_FIRMWARE
+        help
+          These are the binary bootloader files from Broadcom.
+
+          https://github.com/raspberrypi/firmware
+
+if BR2_PACKAGE_RASPBERRYPI_BOOTLOADER
+choice
+
+prompt "Memory & GPU split"
+	default BR2_PACKAGE_BOOTLOADER_ARM192
+	help
+         Select how much memory use for system and
+	 how much for GPU.
+
+config BR2_PACKAGE_BOOTLOADER_ARM128
+        bool "arm128"
+        help
+	   128M ARM, 128M GPU split (use this for heavy 3D work, possibly also
+	   required for some video decoding)
+
+config BR2_PACKAGE_BOOTLOADER_ARM192
+        bool "arm192"
+        help
+	  192M ARM, 64M GPU split (this is the default)
+
+config BR2_PACKAGE_BOOTLOADER_ARM224
+        bool "arm224"
+        help
+	  224M ARM, 32M GPU split (use this for Linux only with no 3D or video
+	  processing. Its enough for the 1080p framebuffer, but not much else)
+
+config BR2_PACKAGE_BOOTLOADER_ARM240
+        bool "arm240"
+        help
+	  240M ARM, 16M GPU split (use this for headless mode only. It is enough
+	  to boot the system, but you can not use video at all.)
+endchoice
+
+endif #BR2_PACKAGE_RASPBERRYPI_BOOTLOADER
+
+config BR2_PACKAGE_RASPBERRYPI_VIDEOCORE
+        bool "Raspberry Pi VideoCore drivers"
+	select BR2_PACKAGE_RASPBERRYPI_FIRMWARE
+        help
+          These are the binary VideoCore drivers from Broadcom.
+
+          https://github.com/raspberrypi/firmware
diff --git a/package/raspberrypi-firmware/raspberrypi-firmware.mk b/package/raspberrypi-firmware/raspberrypi-firmware.mk
new file mode 100644
index 0000000..1ebf67c
--- /dev/null
+++ b/package/raspberrypi-firmware/raspberrypi-firmware.mk
@@ -0,0 +1,48 @@
+RASPBERRYPI_FIRMWARE_VERSION = d29291e
+RASPBERRYPI_FIRMWARE_SOURCE = raspberrypi-firmware-$(RASPBERRYPI_FIRMWARE_VERSION).tar.gz
+RASPBERRYPI_FIRMWARE_SITE = http://github.com/raspberrypi/firmware/tarball/master
+
+ifeq ($(BR2_PACKAGE_RASPBERRYPI_VIDEOCORE),y)
+RASPBERRYPI_FIRMWARE_INSTALL_STAGING = YES
+
+define RASPBERRYPI_FIRMWARE_INSTALL_STAGING_CMDS
+	cp -r $(@D)/hardfp/opt $(STAGING_DIR)/
+endef
+
+define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_VIDEOCORE
+	cp -r $(@D)/hardfp/opt/vc/bin $(TARGET_DIR)/usr/bin
+	cp -r $(@D)/hardfp/opt/vc/lib $(TARGET_DIR)/usr/lib
+	cp -r $(@D)/hardfp/opt/vc/sbin $(TARGET_DIR)/usr/sbin
+endef
+endif
+
+ifeq ($(BR2_PACKAGE_RASPBERRYPI_BOOTLOADER),y)
+BOOT_FILE := #empty
+ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM128),y)
+BOOT_FILE += arm128_start.elf
+else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM192),y)
+BOOT_FILE += arm192_start.elf
+else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM224),y)
+BOOT_FILE += arm224_start.elf
+else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM240),y)
+BOOT_FILE += arm240_start.elf
+endif
+
+define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER
+	if [ ! -d "$(TARGET_DIR)/boot" ]; then \
+		mkdir $(TARGET_DIR)/boot; \
+	fi; \
+	cp $(@D)/boot/$(subst $(space),$(comma),$(strip $(BOOT_FILE))) \
+		$(TARGET_DIR)/boot/start.elf
+	cp $(@D)/boot/bootcode.bin $(TARGET_DIR)/boot/bootcode.bin
+	cp $(@D)/boot/loader.bin $(TARGET_DIR)/boot/loader.bin
+endef
+endif
+
+define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_CMDS
+	$(RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER)
+	$(RASPBERRYPI_FIRMWARE_INSTALL_TARGET_VIDEOCORE)
+endef
+
+$(eval $(generic-package))
+
-- 
1.7.9.5

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Thomas Petazzoni]

Dear Marek Belisko,

On Mon, 17 Sep 2012 22:34:17 +0200, Marek Belisko wrote:
> +prompt "Memory & GPU split"
> +	default BR2_PACKAGE_BOOTLOADER_ARM192

When a package is named BR2_PACKAGE_FOO, then all its sub-options
*must* have name that starts with BR2_PACKAGE_FOO_

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Yann E. MORIN]

Marek, All,

On Monday 17 September 2012 22:34:17 Marek Belisko wrote:
> Add support for raspberrypi bootloader and VideoCore.

See my comments below.

> Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
> 
> Added changes from Arnout comments:
> (http://lists.busybox.net/pipermail/buildroot/2012-September/058565.html)
> - add rasberrypi-firmware as separate package
> - change Config.in handling to have separate bootloader and
>   VideoCore packages (handled in same mk file)
> - various other fixes
> 
> New features:
> - add possibility to choose ARM - GPU memory split by user
> - download package in tar.gz instead git method
> 
> ---
>  package/Config.in                                  |    1 +
>  package/raspberrypi-firmware/Config.in             |   53 ++++++++++++++++++++
>  .../raspberrypi-firmware/raspberrypi-firmware.mk   |   48 ++++++++++++++++++
>  3 files changed, 102 insertions(+)
>  create mode 100644 package/raspberrypi-firmware/Config.in
>  create mode 100644 package/raspberrypi-firmware/raspberrypi-firmware.mk
> 
> diff --git a/package/Config.in b/package/Config.in
> index 58dd5e8..36635cd 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -232,6 +232,7 @@ source "package/owl-linux/Config.in"
>  source "package/parted/Config.in"
>  source "package/pciutils/Config.in"
>  source "package/picocom/Config.in"
> +source "package/raspberrypi-firmware/Config.in"
>  source "package/read-edid/Config.in"
>  source "package/rng-tools/Config.in"
>  source "package/sane-backends/Config.in"
> diff --git a/package/raspberrypi-firmware/Config.in b/package/raspberrypi-firmware/Config.in
> new file mode 100644
> index 0000000..55abd68
> --- /dev/null
> +++ b/package/raspberrypi-firmware/Config.in
> @@ -0,0 +1,53 @@
> +config BR2_PACKAGE_RASPBERRYPI_FIRMWARE
> +	bool
> +
> +config BR2_PACKAGE_RASPBERRYPI_BOOTLOADER
> +        bool "Raspberry Pi bootloader files"

Space-damage: config option should be indented one tab, not 8 spaces,
and help entries are indented one tab plus two spaces, not 10 spaces.

> +	select BR2_PACKAGE_RASPBERRYPI_FIRMWARE

I am not too fond of this hack... :-(

The issue with this 'package' is that it's two things:
  - a package that installs the videocore library;
  - a package that installs the bootloader files.

So, I would really like to see the bootloader entries in the bootloader
sub-menu, and the library part in the "packages on target" sub-menu.

I'll look at this shortly (having recently received my rPi), and hope to
be able to come back later tonight with an alternate proposal.

The big issue is that there is no provision in BR to handle this situation,
as it is currently expected that an upstream package only provides a single
package in BR.

So, NACK from me in the state it is currently.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Yann E. MORIN]

Marek, All,

On Monday 17 September 2012 23:01:54 Yann E. MORIN wrote:
> On Monday 17 September 2012 22:34:17 Marek Belisko wrote:
> > Add support for raspberrypi bootloader and VideoCore.
[--SNIP--]
> I am not too fond of this hack... :-(
> 
> The issue with this 'package' is that it's two things:
>   - a package that installs the videocore library;
>   - a package that installs the bootloader files.

Ah, my bad, I should have paid more attention to the README. The bootloader
files are for the GPU, not the CPU. Well, that's another issue, then.

Still, I am not very fond of the 'select' hack. Why not do something like
the following (untested so far, will give it a spin shortly):

---8<--- Config.in --8<---
config BR2_PACKAGE_RASPBERRYPI_FIRMWARE
	bool "Raspberry Pi firmware blobs"
	depends on ARM    # (and even the proper CPU?)
	help
	  Install the firmware blobs for the GPU, and the userland
	  VideoCore library to use accelerated graphics on the
	  Raspberry Pi.

	  http://github/babla/...

if BR2_PACKAGE_RASPBERRYPI_FIRMWARE

choice
	bool "CPU/GPU memory split"
	default BR2_PACKAGE_RASPBERRYPI_FIRMWARE_ARM192

config BR2_PACKAGE_RASPBERRYPI_FIRMWARE_ARM128
	bool "128MiB/128MiB"

config BR2_PACKAGE_RASPBERRYPI_FIRMWARE_ARM192
	bool "192MiB/64MiB"

# And so on (your help entries are fine!)

enchoice

config BR2_PACKAGE_RASPBERRYPI_FIRMWARE_GPU_BOOT_FILE
	string
	default "arm128" if BR2_PACKAGE_RASPBERRYPI_FIRMWARE_ARM128
	default "arm192" if BR2_PACKAGE_RASPBERRYPI_FIRMWARE_ARM192
	...

endif
---8<--- Config.in --8<---

What would be the interest to install the GPU boot files, but not install
the VideoCore libraries? Or the other way around, what would be the intrest
to install the VidoeCore library without the GPU boot files?

So my proposal install both one GPU boot file and the VideoCore libraries,
or nothing@all.

---8<--- raspberrypi-firmware.mk --8<---
RASPBERRYPI_FIRMWARE_VERSION = d29291e
RASPBERRYPI_FIRMWARE_SOURCE = raspberrypi-firmware-$(RASPBERRYPI_FIRMWARE_VERSION).tar.gz
RASPBERRYPI_FIRMWARE_SITE = http://github.com/raspberrypi/firmware/tarball/master
RASPBERRYPI_FIRMWARE_INSTALL_STAGING = YES

define RASPBERRYPI_FIRMWARE_INSTALL_STAGING_CMDS
	cp -a $(@D)/hardfp/opt/vc/* $(STAGING_DIR)/usr
endef

define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_CMDS
	mkdir -p $(TARGET_DIR)/boot
	cp $(@D)/boot/$(qstrip $(BR2_PACKAGE_RASPBERRYPI_FIRMWARE_GPU_BOOT_FILE))_start.elf \
	        $(TARGET_DIR)/boot/start.elf
	cp $(@D)/boot/bootcode.bin $(TARGET_DIR)/boot/bootcode.bin
	cp $(@D)/boot/loader.bin $(TARGET_DIR)/boot/loader.bin
	cp -a $(@D)/hardfp/opt/vc/bin/* $(TARGET_DIR)/usr/bin
	cp -a $(@D)/hardfp/opt/vc/lib/* $(TARGET_DIR)/usr/lib
	cp -a $(@D)/hardfp/opt/vc/sbin/* $(TARGET_DIR)/usr/sbin
endef

$(eval $(generic-package))
---8<--- raspberrypi-firmware.mk --8<---


Also, to be noted in your original patch, you wrote:

---8<---
ifeq ($(BR2_PACKAGE_RASPBERRYPI_BOOTLOADER),y)
BOOT_FILE := #empty
ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM128),y)
BOOT_FILE += arm128_start.elf
else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM192),y)
BOOT_FILE += arm192_start.elf
else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM224),y)
BOOT_FILE += arm224_start.elf
else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM240),y)
BOOT_FILE += arm240_start.elf
endif
---8<---

But all the ARMxxx options are in a choice, so they are mutually exclusive.
In the proposal, above, I kept it as a choice, although it may make sense
to install more than one GPU bootloader.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Mon, 17 Sep 2012 23:50:27 +0200, Yann E. MORIN wrote:

> What would be the interest to install the GPU boot files, but not install
> the VideoCore libraries? Or the other way around, what would be the intrest
> to install the VidoeCore library without the GPU boot files?

The GPU boot files are needed to actually boot the ARM processor. So
technically speaking, they are some kind of first-stage bootloader for
the ARM processor, even if they get executed on the GPU.

So, if you want to use the RasberryPi, you *must* install those GPU
boot files. However, if you're not using the RasberryPi for a 3D
graphical application, you don't necessarily need the VideoCore library
files. So I think it makes sense to be able to install the GPU boot
files separately from the VideoCore library.

The underlying problem here is a fundamental weakness in Buildroot
design: the absence of separation between source packages and binary
packages. We have the same situation quite often for other things. For
example the "curl" package. It provides both a library "libcurl", and a
program "curl" that relies on that library. Should this package be
under "Libraries -> Networking" or under "Networking applications" ?
Ditto for many, many of our packages.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Yann E. MORIN]

Thomas, Marek, All,

On Tuesday 18 September 2012 07:09:34 Thomas Petazzoni wrote:
> On Mon, 17 Sep 2012 23:50:27 +0200, Yann E. MORIN wrote:
> > What would be the interest to install the GPU boot files, but not install
> > the VideoCore libraries? Or the other way around, what would be the intrest
> > to install the VidoeCore library without the GPU boot files?

> The GPU boot files are needed to actually boot the ARM processor. So
> technically speaking, they are some kind of first-stage bootloader for
> the ARM processor, even if they get executed on the GPU.
> 
> So, if you want to use the RasberryPi, you *must* install those GPU
> boot files. However, if you're not using the RasberryPi for a 3D
> graphical application, you don't necessarily need the VideoCore library
> files. So I think it makes sense to be able to install the GPU boot
> files separately from the VideoCore library.

Ah, OK, that's one more thing I learned, so I won;t have to discover the
hard way when plugging my RPI first (later tonight! :-) )

So, basically, the initial interest for this package is to provide the
bootloader files, hence I believe the package should go in the bootloader
sub-menu.

Then we can add a VideoCoreIV package in one of the "packages on target"
sub-menu ("libs -> hardware handling" sounds the most adequate AFAICS).

> The underlying problem here is a fundamental weakness in Buildroot
> design: the absence of separation between source packages and binary
> packages. We have the same situation quite often for other things. For
> example the "curl" package. It provides both a library "libcurl", and a
> program "curl" that relies on that library. Should this package be
> under "Libraries -> Networking" or under "Networking applications" ?
> Ditto for many, many of our packages.

Ok, so I'll prepare that patch of mine to add this package, so we can
compare with Marek's solution.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Tue, 18 Sep 2012 19:47:31 +0200, Yann E. MORIN wrote:

> So, basically, the initial interest for this package is to provide the
> bootloader files, hence I believe the package should go in the bootloader
> sub-menu.
> 
> Then we can add a VideoCoreIV package in one of the "packages on target"
> sub-menu ("libs -> hardware handling" sounds the most adequate AFAICS).

And so this package would "depends on" a bootloader?

Marek made it clear at the beginning: even though this
rasberrypi-firmware package contains a bootloader, he decided to put it
in package/ because it also contains userspace libraries. And Marek
wanted to avoid having two separate packages, because it would be that
you would download the same original tarball (or Git repository) twice,
have two packages to upgrade when bumping the version, etc.

Note that we however already have a relatively similar situation with
u-boot: we have boot/uboot for the bootloader and package/u-boot-tools
for the host and target utilities.

It is clearly a lack of separation between source package and binary
packages that is causing problem here. We should normally have one
source package: rasberrypi-firmware, that provides two binary packages:
rasberrypi-bootloader and rasberrypi-videocore-libs.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Two packages with the same source [was: [PATCH] Add package raspberrypi-firmware.]

[Arnout Vandecappelle]

On 09/18/12 20:06, Thomas Petazzoni wrote:
> Dear Yann E. MORIN,
>
> On Tue, 18 Sep 2012 19:47:31 +0200, Yann E. MORIN wrote:
>
>> So, basically, the initial interest for this package is to provide the
>> bootloader files, hence I believe the package should go in the bootloader
>> sub-menu.
>>
>> Then we can add a VideoCoreIV package in one of the "packages on target"
>> sub-menu ("libs ->  hardware handling" sounds the most adequate AFAICS).
>
> And so this package would "depends on" a bootloader?
>
> Marek made it clear at the beginning: even though this
> rasberrypi-firmware package contains a bootloader, he decided to put it
> in package/ because it also contains userspace libraries. And Marek
> wanted to avoid having two separate packages, because it would be that
> you would download the same original tarball (or Git repository) twice,
> have two packages to upgrade when bumping the version, etc.
>
> Note that we however already have a relatively similar situation with
> u-boot: we have boot/uboot for the bootloader and package/u-boot-tools
> for the host and target utilities.

  And also e.g. for the kernel headers - which basically means Gustavo's
patches are doubled :-)


> It is clearly a lack of separation between source package and binary
> packages that is causing problem here. We should normally have one
> source package: rasberrypi-firmware, that provides two binary packages:
> rasberrypi-bootloader and rasberrypi-videocore-libs.

  I've been thinking a bit about this problem as well.  As an intermediate
solution, I considered the concept of a "source dependency".  You'd
basically do something like:

UBOOT_TOOLS_SOURCE_PACKAGE = UBOOT

and the generic-package infrastructure will re-use uboot's download step.
This would replace the _VERSION, _SOURCE and _SITE symbols for uboot-tools.

  Unfortunately, for uboot-tools and kernel-headers it's a bit more complex,
because you have to select a version for uboot and kernel so you can't
easily add an automatic dependency on it.

  Note that I would still extract, patch and build the packages twice,
because the procedure may be different (just like for host-packages).


  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Arnout Vandecappelle]

On 09/17/12 22:34, Marek Belisko wrote:
[snip]
> diff --git a/package/raspberrypi-firmware/raspberrypi-firmware.mk b/package/raspberrypi-firmware/raspberrypi-firmware.mk
> new file mode 100644
> index 0000000..1ebf67c
> --- /dev/null
> +++ b/package/raspberrypi-firmware/raspberrypi-firmware.mk
> @@ -0,0 +1,48 @@
> +RASPBERRYPI_FIRMWARE_VERSION = d29291e
> +RASPBERRYPI_FIRMWARE_SOURCE = raspberrypi-firmware-$(RASPBERRYPI_FIRMWARE_VERSION).tar.gz

  That's the default, so it can be left out.

> +RASPBERRYPI_FIRMWARE_SITE = http://github.com/raspberrypi/firmware/tarball/master
> +
> +ifeq ($(BR2_PACKAGE_RASPBERRYPI_VIDEOCORE),y)
> +RASPBERRYPI_FIRMWARE_INSTALL_STAGING = YES
> +
> +define RASPBERRYPI_FIRMWARE_INSTALL_STAGING_CMDS
> +	cp -r $(@D)/hardfp/opt $(STAGING_DIR)/

  The same reasoning as for the target applies here as well: we want
the cross-compiler to find the headers and libraries without
requiring special -I and -L directives.  So copy them to /usr/include
and /usr/lib.

> +endef
> +
> +define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_VIDEOCORE
> +	cp -r $(@D)/hardfp/opt/vc/bin $(TARGET_DIR)/usr/bin

  Doesn't this create /usr/bin/bin ? To be safe, use -T .

> +	cp -r $(@D)/hardfp/opt/vc/lib $(TARGET_DIR)/usr/lib
> +	cp -r $(@D)/hardfp/opt/vc/sbin $(TARGET_DIR)/usr/sbin
> +endef
> +endif
> +
> +ifeq ($(BR2_PACKAGE_RASPBERRYPI_BOOTLOADER),y)
> +BOOT_FILE := #empty
> +ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM128),y)
> +BOOT_FILE += arm128_start.elf
> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM192),y)
> +BOOT_FILE += arm192_start.elf
> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM224),y)
> +BOOT_FILE += arm224_start.elf
> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM240),y)
> +BOOT_FILE += arm240_start.elf
> +endif
> +
> +define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER
> +	if [ ! -d "$(TARGET_DIR)/boot" ]; then \
> +		mkdir $(TARGET_DIR)/boot; \
> +	fi; \

  Just "mkdir -p $(TARGET_DIR)/boot".  Or even better, replace the cp
below with
	install -D -m 0644 <fromfile> <tofile>

> +	cp $(@D)/boot/$(subst $(space),$(comma),$(strip $(BOOT_FILE))) \

  I guess this must be a leftover from some earlier magic, because
BOOT_FILE can contain only a single entry, and even if there are
several bootfiles, replacing spaces by commas won't help.

  If you want to support the installation of several bootfiles, you
should use
	for bootfile in $(BOOT_FILE) bootcode.bin loader.bin; do \
		install -D -m $(@D)/boot/$$bootfile $(TARGET_DIR)/boot/$$bootfile; \
	done


  Regards,
  Arnout

> +		$(TARGET_DIR)/boot/start.elf
> +	cp $(@D)/boot/bootcode.bin $(TARGET_DIR)/boot/bootcode.bin
> +	cp $(@D)/boot/loader.bin $(TARGET_DIR)/boot/loader.bin
> +endef
> +endif
> +
> +define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_CMDS
> +	$(RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER)
> +	$(RASPBERRYPI_FIRMWARE_INSTALL_TARGET_VIDEOCORE)
> +endef
> +
> +$(eval $(generic-package))
> +

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Diego Iastrubni]

On Wed, Sep 19, 2012 at 1:01 AM, Arnout Vandecappelle <arnout@mind.be>wrote:

> +ifeq ($(BR2_PACKAGE_RASPBERRYPI_**BOOTLOADER),y)
>> +BOOT_FILE := #empty
>> +ifeq ($(BR2_PACKAGE_BOOTLOADER_**ARM128),y)
>> +BOOT_FILE += arm128_start.elf
>> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_**ARM192),y)
>> +BOOT_FILE += arm192_start.elf
>> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_**ARM224),y)
>> +BOOT_FILE += arm224_start.elf
>> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_**ARM240),y)
>> +BOOT_FILE += arm240_start.elf
>> +endif
>> +
>> +define RASPBERRYPI_FIRMWARE_INSTALL_**TARGET_BOOTLOADER
>> +       if [ ! -d "$(TARGET_DIR)/boot" ]; then \
>> +               mkdir $(TARGET_DIR)/boot; \
>> +       fi; \
>>
>
>  Just "mkdir -p $(TARGET_DIR)/boot".  Or even better, replace the cp
> below with
>         install -D -m 0644 <fromfile> <tofile>
>
>
>
Wait... this implies that /boot/ is on the rootfs... ext2... and rbpi
demands that the "boot" partition will be vfat.. right? What am I missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120919/d64eba75/attachment.html>

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Belisko Marek]

On Wed, Sep 19, 2012 at 9:59 AM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> On Wed, Sep 19, 2012 at 1:01 AM, Arnout Vandecappelle <arnout@mind.be>
> wrote:
>>>
>>> +ifeq ($(BR2_PACKAGE_RASPBERRYPI_BOOTLOADER),y)
>>> +BOOT_FILE := #empty
>>> +ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM128),y)
>>> +BOOT_FILE += arm128_start.elf
>>> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM192),y)
>>> +BOOT_FILE += arm192_start.elf
>>> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM224),y)
>>> +BOOT_FILE += arm224_start.elf
>>> +else ifeq ($(BR2_PACKAGE_BOOTLOADER_ARM240),y)
>>> +BOOT_FILE += arm240_start.elf
>>> +endif
>>> +
>>> +define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER
>>> +       if [ ! -d "$(TARGET_DIR)/boot" ]; then \
>>> +               mkdir $(TARGET_DIR)/boot; \
>>> +       fi; \
>>
>>
>>  Just "mkdir -p $(TARGET_DIR)/boot".  Or even better, replace the cp
>> below with
>>         install -D -m 0644 <fromfile> <tofile>
>>
>>
>
> Wait... this implies that /boot/ is on the rootfs... ext2... and rbpi
> demands that the "boot" partition will be vfat.. right? What am I missing?
My mistake, this shouldn't got to $(TARGET_DIR) but to $(IMAGES_DIR)
which will then can be copied by user to FAT partition of SD card
necessary for booting.
There is no need to have it in rootfs/boot.

Cheers,

marek
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Arnout Vandecappelle]

On 09/19/12 10:09, Belisko Marek wrote:
> On Wed, Sep 19, 2012 at 9:59 AM, Diego Iastrubni<diegoiast@gmail.com>  wrote:
>> On Wed, Sep 19, 2012 at 1:01 AM, Arnout Vandecappelle<arnout@mind.be>
>> wrote:
>>>>
>>>> +define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER
>>>> +       if [ ! -d "$(TARGET_DIR)/boot" ]; then \
>>>> +               mkdir $(TARGET_DIR)/boot; \
>>>> +       fi; \
>>>
>>>
>>>   Just "mkdir -p $(TARGET_DIR)/boot".  Or even better, replace the cp
>>> below with
>>>          install -D -m 0644<fromfile>  <tofile>
>>>
>>>
>>
>> Wait... this implies that /boot/ is on the rootfs... ext2... and rbpi
>> demands that the "boot" partition will be vfat.. right? What am I missing?
> My mistake, this shouldn't got to $(TARGET_DIR) but to $(IMAGES_DIR)
> which will then can be copied by user to FAT partition of SD card
> necessary for booting.
> There is no need to have it in rootfs/boot.

  Shouldn't all images be in that boot directory, then?  Or rather, doesn't
it make more sense to place the bootfiles directly in the images dir?

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Belisko Marek]

Hi,

On Wed, Sep 19, 2012 at 9:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 09/19/12 10:09, Belisko Marek wrote:
>>
>> On Wed, Sep 19, 2012 at 9:59 AM, Diego Iastrubni<diegoiast@gmail.com>
>> wrote:
>>>
>>> On Wed, Sep 19, 2012 at 1:01 AM, Arnout Vandecappelle<arnout@mind.be>
>>> wrote:
>>>>>
>>>>>
>>>>> +define RASPBERRYPI_FIRMWARE_INSTALL_TARGET_BOOTLOADER
>>>>> +       if [ ! -d "$(TARGET_DIR)/boot" ]; then \
>>>>> +               mkdir $(TARGET_DIR)/boot; \
>>>>> +       fi; \
>>>>
>>>>
>>>>
>>>>   Just "mkdir -p $(TARGET_DIR)/boot".  Or even better, replace the cp
>>>> below with
>>>>          install -D -m 0644<fromfile>  <tofile>
>>>>
>>>>
>>>
>>> Wait... this implies that /boot/ is on the rootfs... ext2... and rbpi
>>> demands that the "boot" partition will be vfat.. right? What am I
>>> missing?
>>
>> My mistake, this shouldn't got to $(TARGET_DIR) but to $(IMAGES_DIR)
>> which will then can be copied by user to FAT partition of SD card
>> necessary for booting.
>> There is no need to have it in rootfs/boot.
>
>
>  Shouldn't all images be in that boot directory, then?  Or rather, doesn't
> it make more sense to place the bootfiles directly in the images dir?
Idea behind /boot directory was to copy raspberrypi booloader files +
config file +
kernel cmdline file + kernel bzImage to  that directory and compress it
to output/images/boot.tar.gz (probably in post-build.sh script)
directory to make it
more user friendly (avoid manually copy files from different parts of
buildroot).

>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

Cheers,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Arnout Vandecappelle]

On 09/19/12 22:08, Belisko Marek wrote:
>> >    Shouldn't all images be in that boot directory, then?  Or rather, doesn't
>> >  it make more sense to place the bootfiles directly in the images dir?
> Idea behind /boot directory was to copy raspberrypi booloader files +
> config file +
> kernel cmdline file + kernel bzImage to  that directory and compress it
> to output/images/boot.tar.gz (probably in post-build.sh script)
> directory to make it
> more user friendly (avoid manually copy files from different parts of
> buildroot).

  But would the images/ dir contain anything besides the boot.tar.gz?  If not,
it makes more sense to put all the required images in the images dir.  It's
easier to copy the files from there than to untar them.

  Ah, of course, there's the rootfs files...  But OTOH, you'd also have to handle
bzImage explicitly in some way, so it's just as easy to copy everything except
rootfs.* from the images directory.

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Belisko Marek]

On Wed, Sep 19, 2012 at 11:28 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 09/19/12 22:08, Belisko Marek wrote:
>>>
>>> >    Shouldn't all images be in that boot directory, then?  Or rather,
>>> > doesn't
>>> >  it make more sense to place the bootfiles directly in the images dir?
>>
>> Idea behind /boot directory was to copy raspberrypi booloader files +
>> config file +
>> kernel cmdline file + kernel bzImage to  that directory and compress it
>> to output/images/boot.tar.gz (probably in post-build.sh script)
>> directory to make it
>> more user friendly (avoid manually copy files from different parts of
>> buildroot).
>
>
>  But would the images/ dir contain anything besides the boot.tar.gz?  If
> not,
> it makes more sense to put all the required images in the images dir.  It's
> easier to copy the files from there than to untar them.
>
>  Ah, of course, there's the rootfs files...  But OTOH, you'd also have to
> handle
> bzImage explicitly in some way, so it's just as easy to copy everything
> except
> rootfs.* from the images directory.
I would prefer to keep boot.tar.gz format. Imagine somebody who build
RPI config and in images directory he will have 6 files. How he should
know without reading
elinux.org or rpi webpage what and which should be copied where ? With
boot.tar.gz we can keep it in
consistent format and if the name will be boot.tar.gz then average
user will understand
this should go to boot SD card partition. But this is just my opinion.
>
>
>  Regards,
>  Arnout
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

Cheers,

mbe

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

[Buildroot] [PATCH] Add package raspberrypi-firmware.

[Arnout Vandecappelle]

On 09/19/12 23:50, Belisko Marek wrote:
> I would prefer to keep boot.tar.gz format. Imagine somebody who build
> RPI config and in images directory he will have 6 files. How he should
> know without reading
> elinux.org or rpi webpage what and which should be copied where ? With
> boot.tar.gz we can keep it in
> consistent format and if the name will be boot.tar.gz then average
> user will understand
> this should go to boot SD card partition. But this is just my opinion.

  Compare to any other defconfig: it will produce a number of files in the images
directory.  For instance, a typical TI OMAP will have MLO, u-boot.img, uImage
and rootfs.ext2.  The first three should go into the FAT partition, the last
on into an ext2 partition.  For RPi it's the same thing, except that the
number of images is a bit larger.

  That said, it's a good idea to have a readme.txt in the board directory to
explain how to put everything into a bootable image.

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F