On the more sophisticated (i.e. deeper FIFO) serial controllers,
flow-control might be needed to avoid dropping output.

Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>

Prior to commit 1496b95a ("x86: clean up default grub baudrate
settings") we had three different baud rates for the Geode targets:
19200 for net5501, 38400 for alix2, and 115200 for Geos.

It doesn't seem that there's a very good reason for varying from our
default 115200 baud, so let's make the Geode target do that instead.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

2 GB is overkill and was only added to allow unlimited ext4 resizing,
which is a pretty rare use case. 256 MB allows resizing up to 256 GB,
which should be good enough for almost all users.

A lot of this is mostly irrelevant anyway, since you can just use
squashfs + ext4 overlay.

Signed-off-by: Felix Fietkau <nbd@nbd.name>

Replaces plain ext4 images

Signed-off-by: Felix Fietkau <nbd@nbd.name>

This leaves more room for sysupgrade config data or for having multiple
kernel images to choose from

Signed-off-by: Felix Fietkau <nbd@nbd.name>

The current default rootfs size of 256MB in conjunction with 4K blocks
produces an ext4 filesystem which lacks the appropriate amount of backup GDT
entries to support online-resizing.

For x86 targets, increase the default rootfs size to 2048MB which allows
online resizing the filesystem to up to 2TB which is the current theoretical
maximum for LEDE, due to missing GPT support on the root block device.

Note that the filesystem artefact will not occupy 2GB on the build system as
the make_ext4fs utility uses sparse files to generate the filesystem images,
so the actual disk usage is much lower. Furthermore the filesystem images
are gzip compressed, shrinking them to only a few megabytes on the download
server.

Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: Michael Heimpold <mhei@heimpold.de>

There is very little practical use to limit the number of available inodes on
an ext4 filesystem and the make_ext4fs utility is able to calculate useful
defaults by itself.

Drop the option to make resulting ext4 filesystems more flexible by default.

Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: Michael Heimpold <mhei@heimpold.de>

Signed-off-by: Felix Fietkau <nbd@nbd.name>

Added gen_mvebu_sdcard_img.sh to facilitate creating an fixed-size sdcard image,
adding the bootloader and populating it with actual data.

Added the required rules for creating a 4GB sdcard image according to this layout:
p0: boot (fat32)
p1: rootfs (squashfs)
p2: rootfs_data (ext4)
This should be generic to any mvebu boards that can boot from block storage.

Added the new sdcard image to the Clearfog image profile.

Signed-off-by: Josua Mayer <josua.mayer97@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cleanup]

The MR24's u-boot takes it sweet time decompressing the
LZMA-packed initramfs image. A user reported that
compared to the old gzip method in v2: it "takes a ton
longer to decompress like 4\x the old boot time for
decompression".

This patch also fixes a issue with the WNDR4700's initramfs
image getting to big and causing the following u-boot crash
during the decompression:

"Uncompressing Multi-File Image ... Error: inflate() returned -5
out-of-mem or overwrite error - must RESET board to recover"

This patch fixes both issues by reverting the MR24's initramfs
compression method back to gzip. And choosing to compress the
initramfs within the initramfs image as LZMA by default.

Cc: chrisrblake93@gmail.com
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

These options were a big design flaw to begin with

Signed-off-by: Felix Fietkau <nbd@nbd.name>

If jffs2 support was not enabled by the target, jffs2 are quite likely
to be broken, so we shouldn't build them.

Signed-off-by: Felix Fietkau <nbd@nbd.name>

Signed-off-by: Felix Fietkau <nbd@nbd.name>

Signed-off-by: Felix Fietkau <nbd@openwrt.org>

SVN-Revision: 45113

Signed-off-by: Felix Fietkau <nbd@openwrt.org>

SVN-Revision: 45084

This changes the x86 image generation to match x86_64, using the PARTUUID for
the rootfs instead of explicitly configuring the device.

It unbreaks KVM with VirtIO, which uses /dev/vda2 instead of /dev/sda2.

Tested in QEMU/KVM with VirtIO, VirtualBox and VMware.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>

SVN-Revision: 44966

Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>

SVN-Revision: 43086

Non-functional changes to config/Config-*.in files, including:

* spelling mistakes
* inconsistent terminology
* grammar
* overly long lines in "help" components

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

SVN-Revision: 42519

Signed-off-by: Felix Fietkau <nbd@openwrt.org>

SVN-Revision: 41764

x86: remove the arbitrary limitation of vmware/virtualbox images to ext4, select TARGET_IMAGES_PAD instead

Signed-off-by: Felix Fietkau <nbd@openwrt.org>

SVN-Revision: 41763

http://patchwork.openwrt.org/patch/5686/



Signed-off-by: John Crispin <blogic@openwrt.org>

SVN-Revision: 41329

Signed-off-by: Felix Fietkau <nbd@openwrt.org>

SVN-Revision: 40981

Signed-off-by: Felix Fietkau <nbd@openwrt.org>

SVN-Revision: 40979

Signed-off-by: John Crispin <blogic@openwrt.org>

SVN-Revision: 40951

Signed-off-by: Michael Heimpold <mhei@heimpold.de>

SVN-Revision: 40926

Signed-off-by: Michael Heimpold <mhei@heimpold.de>

SVN-Revision: 40925

Signed-off-by: Michael Heimpold <mhei@heimpold.de>

SVN-Revision: 40924

Signed-off-by: Michael Heimpold <mhei@heimpold.de>

SVN-Revision: 40923

SVN-Revision: 40756

Signed-off-by: Imre Kaloz <kaloz@openwrt.org>

SVN-Revision: 39208

Signed-off-by: Imre Kaloz <kaloz@openwrt.org>

SVN-Revision: 39207

Signed-off-by: Imre Kaloz <kaloz@openwrt.org>

SVN-Revision: 39206

Signed-off-by: Imre Kaloz <kaloz@openwrt.org>

SVN-Revision: 38895