| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
|
|
|
|
|
|
|
|
|
| |
If the SPL_BINARY value is not empty, then the class will use
an alternative code path for copying U-Boot on the SD card.
u-boot.img is used (not .imx), and the SPL binary is prepended.
With empty SPL_BINARY values, the behavior is just like before.
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
|
|
|
|
| |
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
|
|
|
|
|
|
|
|
|
|
|
| |
FSL_EULA_FILE is defined with :=, which means it contains a full absolute path
to the layer directory. If this is allowed to make it into the task checksum,
it becomes impossible to use the shared states for these recipes without
having meta-fsl-arm in the exact same path in the filesystem it was in when
the sstate archives were created. Add FSL_EULA_FILE to
do_unpack[vardepsexclude].
Signed-off-by: Christopher Larson <kergoth@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allow to easy reuse of binary packages among similar SoCs. The
usual use for this is to share SoC specific packages among different
boards. The class can be used to share GPU packages for i.MX53 boards
(as all them share the AMD GPU) and i.MX6 based boards (as all them
share Vivante GPU).
It inspects the database and identify if the package provides or
depends on one of subarch provided values and if it does, it sets the
PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
machine specific filter, it sets it to MACHINE_ARCH.
This reduces the amount of packages we build, for example in case of
core-image-x11 we:
$ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
75
So we reuse 75 binaries; these would be build otherwise.
It being dynamically set or statically set it has following benefits:
* correctness: it is easier to ensure the system behaves as expected
* correctness for non-tracked recipes: new recipes, if depending on
virtual/kernel or GPU has the right architecture choosen, without a
.bbappend file for them
* safeness: non-expert users get a more adequate behavior as the
complexity of choosing the right architecture is simplified for them
* easy maintenance: it is easier for me, as maintainer, to maintain a
code which decides what to do than having hundreds of bbappend files
for it
Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
| |
Change-Id: Ibe7afdd6e4c2f5db73b42cf6b39df9756bdb9fb8
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
|
|
|
|
|
| |
The Vybrid SoCs use same image layout as other i.MX so use it.
Change-Id: I0e1de1b917aed249196bef463ae1017c65254ef5
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
| |
Use the KERNEL_IMAGETYPE variable, making the class configurable for all
supported kernel image types.
This patch is tested with a 3rd-party board and a sabrelite board.
Signed-off-by: S. Fricke <sfricke@data-modul.com>
|
|
|
|
|
|
|
|
| |
Create first partition on SD card as fat32. As boot.img is formatted
as vfat, this will ensure information in partition table matches
actual partition type.
Signed-off-by: Vladan Jovanovic <vladan.jovanovic@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mxsboot-sdcard image is the current way we use to generate the
U-Boot bootstream blob during image generation however Yocto image
system enforces some naming schema so the symbolic links does work and
we weren't following those. This patch uses the '${IMAGE_NAME}'
variable and the proper image suffix so the symbolic links now fully
work.
Fixes [YOCTO #3871].
Change-Id: I7f96dcdd58e0a726b8084c1f87ff10732fe259df
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
|
| |
.dtb file is copied to 'Boot' partition, the same partition
uImage is placed.
Now, more than one .dtb can be copied, if board conf file
determinates more than one .dts file.
Signed-off-by: Daiane Angolini <daiane.angolini@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some machines might want to provide boot scripts for use. This now can
be accomplished using BOOT_SCRIPTS variable in following format:
<source>:<destination>
Thus any file in deploy directory can be installed in the boot
partition of the sdcard, easily.
Change-Id: Ic1eafd2be3559b5c9da43dcc6f54f1b480dbc647
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
| |
Some machines might come with a bootloader in an internal flash (a SPI
NOR, for example) so not requiring a boot loader in the image.
Change-Id: Id1a69c6c6b60639694a64b2b7badd16ee4b0d2f7
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
| |
This commit fixes an unbound local exception caused by save_cwd not
being defined when fsl-eula is not true.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
| |
The imx-bootlets (and per design elftosb) enforce the use of offset so
we skip the first 1024KiB from the disk and start from there instead
of 4MiB as done for other SoCs.
Change-Id: I51e2989ef2007aa752e67f7d1b38a9de5c1ff9c8
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SD image file was 4G in size but actually the rootfs partition was only
60MB (in some images).
The image file size is not fixed anymore but calculated inside this
class. In this way we will setup the partition for rootfs to fit the
ext file used as SDIMG_ROOTFS. By default the free space is calculated
with IMAGE_OVERHEAD_FACTOR which is by default 1.3. If more free space
is needed this can be overwritten.
IMAGE_ROOTFS_ALIGNMENT set at 4096. This should be the best value for a
SD card.
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
|
|
|
|
|
|
|
|
|
| |
This class provides the mechanism used for unpacking
the .bin file downloaded by HTTP and handle the EULA acceptance.
Change-Id: I88857c7dac94568c5bced4e712744087638de68a
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Daiane Angolini <daiane.angolini@freescale.com>
|
|
|
|
|
|
|
|
|
| |
The code where failing if used with no dtb files available in deploy
directory.
Change-Id: Ib08e23f3d7761b0991fcce009fb93290d698f7c3
Reported-by: Tim Michals <tcmichals@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|\
| |
| |
| |
| |
| |
| | |
* freescale/denzil:
image_types_fsl.bbclass: Calculate BOOT_BLOCKS for new boot partition num
linux-imx (2.6.35.3): Kernel patches from Freescale GIT
linux-imx (2.6.35.3): reduce delta against kernel source mx5_defconfig
|
| |
| |
| |
| |
| |
| |
| |
| | |
The empty 1K at the beginning of the disk is no longer a partition, so
the numbers reported by parted have shifted by one.
Signed-off-by: Jeremy Stashluk <jstashluk@dekaresearch.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The bootrom boots from a fixed 1K offset so we don't need a partition
there and having one makes udev or kernel to probe for it and output
error messages in bootlog:
,----[ boot error messages ]
| ...
| EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
| EXT3-fs (mmcblk0p1): error: can't find ext3 filesystem on dev mmcblk0p1.
| EXT2-fs (mmcblk0p1): error: can't find an ext2 filesystem on dev mmcblk0p1.
| FAT: bogus number of reserved sectors
| VFS: Can't find a valid FAT filesystem on dev mmcblk0p1.
| cramfs: wrong magic
| FAT: bogus number of reserved sectors
| VFS: Can't find a valid FAT filesystem on dev mmcblk0p1.
| ...
`----
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The bootrom boots from a fixed 1K offset so we don't need a partition
there and having one makes udev or kernel to probe for it and output
error messages in bootlog:
,----[ boot error messages ]
| ...
| EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
| EXT3-fs (mmcblk0p1): error: can't find ext3 filesystem on dev mmcblk0p1.
| EXT2-fs (mmcblk0p1): error: can't find an ext2 filesystem on dev mmcblk0p1.
| FAT: bogus number of reserved sectors
| VFS: Can't find a valid FAT filesystem on dev mmcblk0p1.
| cramfs: wrong magic
| FAT: bogus number of reserved sectors
| VFS: Can't find a valid FAT filesystem on dev mmcblk0p1.
| ...
`----
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|/
|
|
|
|
|
|
|
|
| |
To support new kernel, which use Device Tree for description of
hardware and machine, the image generation needs to be reworked.
U-Boot supports it out of box, so it just need to be available for
reading while the imx-bootlets we need to append the dtb file on the
very end of the zImage file.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
| |
linux_ivt.bd module is dependant of mx25 and cannot be used by i.MXS
family.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
| |
When updating to imx-bootlets 10.12.01 a leftover configuration from
previous release has been left by mistake.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i.MXS SoC family has support to boot with imx-bootlets (the default
when using LTIB) and the only current supported way of booting i.MX23
machines.
The imx-bootlets has some quite specific requirements regaring the
partition layout and includes the kernel binary appended to the boot
stream so we drop the third partition reducing the wasted space of SD
card.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
| |
i.MXS generation is now handled completely separated so i.MX doesn't
every gets called for 'mxs' SoC family.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
| |
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
| |
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
| |
It looks like mkfs.vfat is using 1024B block size. The returned value
of BOOT_BLOCKS was in blocks of 512B. This needs to be changed in blocks
of 1024B.
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
|
|
|
|
|
|
|
| |
In awk the first cell/item is $1 not $0 in this way the size
of the partition from parted is actually $4 not $3.
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
|
|
|
|
| |
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
| |
i.MXS and i.MX SoC families has enough partition layout differences
that justify to have a specific code for each SoC family to easy
maintenance and readability of code.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
| |
The SoC image fstypes needs to be assigned in the machine definition
or the default ones are not used.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
| |
The 'sed' might fail in some systems due user right and restrictions
so we use 'dd' and 'echo' to do the same trick.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reported-by: "John Passaniti" <jpassaniti@ashly.com>
|
|
|
|
|
|
|
|
| |
This speeds up the generation of the sdcard and reduces the amount of
space used for it.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reported-by: "John Passaniti" <jpassaniti@ashly.com>
|
|
|
|
|
|
|
|
|
| |
The mxs SoC family requires use of a bootstream in bootloader but at
this moment only SDCard format is supported. The image for use is
'u-boot.mxsboot-sdcard' and this is also the file extension of the
generated file beside of regular u-boot binary.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
| |
u-boot-imx has padding by default and machines using it need to skip
it when generating the sdcard.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
| |
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generation of SDCard has been completely refactored to work out of
box; now to use it you have to set, e.g:
SDCARD_ROOTFS = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3"
SDCARD_SIZE = "128"
IMAGE_TYPES += "ext3 sdcard"
Now the sdcard has following layout:
0 - 1M - reserved to bootloader and other data
1M - BOOT_SPACE - kernel
BOOT_SPACE - SDCARD_SIZE - rootfs
All current supported machines on BSP will work out of box and
generate a 2GB SDCard with an ext3 rootfs on it.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
| |
The IMAGE_BOOTLOADER variable allows to specific the bootloader to be
used. Currently it supports 'u-boot' and 'barebox' as option. Images
using the bbsdcard_image.bbclass need to change the image definition
to adapt to this.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this class allows the generation of a ready to use SDCard image
using barebox bootloader.
example on how to use it (with angstrom distro) :
1- add these 3 lines to your local.conf :
ROOTFS = "${DEPLOY_DIR_IMAGE}/console-image-imx53qsb.ext3"
INHERIT += "bbsdcard_image"
BBSDIMG_SIZE = "512"
2- build the image
bitbake console-image
3- copy it to the sdcard (update device for you sdcard, take care to not erase your hard drive ;-)
sudo dd if=build/tmp-angstrom_2010_x-eglibc/deploy/images/imx53qsb/console-image-imx53qsb.bbsdimg of=/dev/mmcblk0
Signed-off-by: Eric Bénard <eric@eukrea.com>
|
|
This creates an image suitable for writting onto a SD card and use on
i.MX53 boards allowing for easy image testing.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|