upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
u-boot/drivers/mtd/ubispl/ubi-wrapper.h

107 lines
2.9 KiB

spl: Lightweight UBI and UBI fastmap support Booting a payload out of NAND FLASH from the SPL is a crux today, as it requires hard partioned FLASH. Not a brilliant idea with the reliability of todays NAND FLASH chips. The upstream UBI + UBI fastmap implementation which is about to brought to u-boot is too heavy weight for SPLs as it provides way more functionality than needed for a SPL and does not even fit into the restricted SPL areas which are loaded from the SoC boot ROM. So this provides a fast and lightweight implementation of UBI scanning and UBI fastmap attach. The scan and logical to physical block mapping code is developed from scratch, while the fastmap implementation is lifted from the linux kernel source and stripped down to fit the SPL needs. The text foot print on the board which I used for development is: 6854 0 0 6854 1abd drivers/mtd/ubispl/built-in.o Attaching a NAND chip with 4096 physical eraseblocks (4 blocks are reserved for the SPL) takes: In full scan mode: 1172ms In fastmap mode: 95ms The code requires quite some storage. The largest and unknown part of it is the number of fastmap blocks to read. Therefor the data structure is not put into the BSS. The code requires a pointer to free memory handed in which is initialized by the UBI attach code itself. See doc/README.ubispl for further information on how to use it. This shares the ubi-media.h and crc32 implementation of drivers/mtd/ubi There is no way to share the fastmap code, as UBISPL only utilizes the slightly modified functions ubi_attach_fastmap() and ubi_scan_fastmap() from the original kernel ubi fastmap implementation. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
9 years ago
/*
* The parts taken from the kernel implementation are:
*
* Copyright (c) International Business Machines Corp., 2006
*
* UBISPL specific defines:
*
* Copyright (c) Thomas Gleixner <tglx@linutronix.de>
*
* SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause
*/
/*
* Contains various defines copy&pasted from ubi.h and ubi-user.h to make
* the upstream fastboot code happy.
*/
#ifndef __UBOOT_UBI_WRAPPER_H
#define __UBOOT_UBI_WRAPPER_H
/*
* Error codes returned by the I/O sub-system.
*
* UBI_IO_FF: the read region of flash contains only 0xFFs
* UBI_IO_FF_BITFLIPS: the same as %UBI_IO_FF, but also also there was a data
* integrity error reported by the MTD driver
* (uncorrectable ECC error in case of NAND)
* UBI_IO_BAD_HDR: the EC or VID header is corrupted (bad magic or CRC)
* UBI_IO_BAD_HDR_EBADMSG: the same as %UBI_IO_BAD_HDR, but also there was a
* data integrity error reported by the MTD driver
* (uncorrectable ECC error in case of NAND)
* UBI_IO_BITFLIPS: bit-flips were detected and corrected
*
* UBI_FASTMAP_ANCHOR: u-boot SPL add on to tell the caller that the fastmap
* anchor block has been found
*
* Note, it is probably better to have bit-flip and ebadmsg as flags which can
* be or'ed with other error code. But this is a big change because there are
* may callers, so it does not worth the risk of introducing a bug
*/
enum {
UBI_IO_FF = 1,
UBI_IO_FF_BITFLIPS,
UBI_IO_BAD_HDR,
UBI_IO_BAD_HDR_EBADMSG,
UBI_IO_BITFLIPS,
UBI_FASTMAP_ANCHOR,
};
/*
* UBI volume type constants.
*
* @UBI_DYNAMIC_VOLUME: dynamic volume
* @UBI_STATIC_VOLUME: static volume
*/
enum {
UBI_DYNAMIC_VOLUME = 3,
UBI_STATIC_VOLUME = 4,
};
/*
* Return codes of the fastmap sub-system
*
* UBI_NO_FASTMAP: No fastmap super block was found
* UBI_BAD_FASTMAP: A fastmap was found but it's unusable
*/
enum {
UBI_NO_FASTMAP = 1,
UBI_BAD_FASTMAP,
};
/**
* struct ubi_fastmap_layout - in-memory fastmap data structure.
* @e: PEBs used by the current fastmap
* @to_be_tortured: if non-zero tortured this PEB
* @used_blocks: number of used PEBs
* @max_pool_size: maximal size of the user pool
* @max_wl_pool_size: maximal size of the pool used by the WL sub-system
*/
struct ubi_fastmap_layout {
struct ubi_wl_entry *e[UBI_FM_MAX_BLOCKS];
int to_be_tortured[UBI_FM_MAX_BLOCKS];
int used_blocks;
int max_pool_size;
int max_wl_pool_size;
};
/**
* struct ubi_fm_pool - in-memory fastmap pool
* @pebs: PEBs in this pool
* @used: number of used PEBs
* @size: total number of PEBs in this pool
* @max_size: maximal size of the pool
*
* A pool gets filled with up to max_size.
* If all PEBs within the pool are used a new fastmap will be written
* to the flash and the pool gets refilled with empty PEBs.
*
*/
struct ubi_fm_pool {
int pebs[UBI_FM_MAX_POOL_SIZE];
int used;
int size;
int max_size;
};
#endif