| Message ID | 1347914057-20287-1-git-send-email-marek.belisko@open-nandra.com |
|---|---|
| State | Superseded |
| Headers | show |
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
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.
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 at 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.
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, 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.
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
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
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)) > +
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?
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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
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
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
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
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
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)) +
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