summaryrefslogtreecommitdiff
path: root/lib/zlib
Commit message (Collapse)AuthorAgeFilesLines
* Move malloc_cache_aligned() to its own headerSimon Glass2015-09-111-1/+3
| | | | | | | | | | | | | | | | | | | At present malloc.h is included everywhere since it recently was added to common.h in this commit: 4519668 mtd/nand/ubi: assortment of alignment fixes This seems wasteful and unnecessary. We have been trying to trim down common.h and put separate functions into separate header files and that change goes in the opposite direction. Move malloc_cache_aligned() to a new header so that this can be avoided. The header would perhaps be better named as alignmem.h but it needs to be included after common.h and people might be confused by this. With the name memalign.h it fits nicely after malloc() in most cases. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
* mtd/nand/ubi: assortment of alignment fixesMarcel Ziswiler2015-08-281-0/+2
| | | | | | | | | | | | | | Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer alignment into account which led to failures of the following form: ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108 Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Scott Wood <scottwood@freescale.com> [trini: Add __UBOOT__ hunk to lib/zlib/zutil.c due to malloc.h in common.h] Signed-off-by: Tom Rini <trini@konsulko.com>
* Replace <compiler.h> with <linux/compiler.h>Masahiro Yamada2014-12-081-1/+1
| | | | | | Including <linux/compiler.h> is enough for general use. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* lib: descend into sub directories only when it is necessaryMasahiro Yamada2013-11-171-1/+1
| | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* lib: convert makefiles to Kbuild styleMasahiro Yamada2013-10-311-21/+1
| | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-241-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* lib/zlib: sparse fixesKim Phillips2012-11-045-43/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | define Z_NULL to (void *)0 include/u-boot/zlib.h to get rid of most of the NULL pointer warnings. inflate.c:942:1: warning: non-ANSI definition of function 'inflateEnd' inflate.c:9:1: warning: non-ANSI definition of function 'inflateReset' inflate.c:12:17: warning: Using plain integer as NULL pointer inflate.c:12:42: warning: Using plain integer as NULL pointer inflate.c:15:17: warning: Using plain integer as NULL pointer inflate.c:21:19: warning: Using plain integer as NULL pointer inflate.c:35:1: warning: non-ANSI definition of function 'inflateInit2_' inflate.c:38:20: warning: Using plain integer as NULL pointer inflate.c:41:17: warning: Using plain integer as NULL pointer inflate.c:42:17: warning: Using plain integer as NULL pointer inflate.c:50:18: warning: Using plain integer as NULL pointer inflate.c:65:23: warning: Using plain integer as NULL pointer inflate.c:69:21: warning: Using plain integer as NULL pointer inflate.c:78:1: warning: non-ANSI definition of function 'inflateInit_' inflate.c:86:1: warning: non-ANSI definition of function 'fixedtables' inflate.c:108:26: warning: Using plain integer as NULL pointer inflate.c:109:1: warning: non-ANSI definition of function 'updatewindow' inflate.c:112:30: warning: Using plain integer as NULL pointer inflate.c:339:1: warning: non-ANSI definition of function 'inflate' inflate.c:349:17: warning: Using plain integer as NULL pointer inflate.c:349:42: warning: Using plain integer as NULL pointer inflate.c:350:27: warning: Using plain integer as NULL pointer inflate.c:369:42: warning: Using plain integer as NULL pointer inflate.c:376:32: warning: Using plain integer as NULL pointer inflate.c:401:54: warning: Using plain integer as NULL pointer inflate.c:419:32: warning: Using plain integer as NULL pointer inflate.c:426:32: warning: Using plain integer as NULL pointer inflate.c:433:32: warning: Using plain integer as NULL pointer inflate.c:444:36: warning: Using plain integer as NULL pointer inflate.c:449:37: warning: Using plain integer as NULL pointer inflate.c:450:38: warning: Using plain integer as NULL pointer inflate.c:457:40: warning: Using plain integer as NULL pointer inflate.c:458:47: warning: Using plain integer as NULL pointer inflate.c:480:40: warning: Using plain integer as NULL pointer inflate.c:481:50: warning: Using plain integer as NULL pointer inflate.c:491:37: warning: Using plain integer as NULL pointer inflate.c:492:37: warning: Using plain integer as NULL pointer inflate.c:501:40: warning: Using plain integer as NULL pointer inflate.c:502:53: warning: Using plain integer as NULL pointer inflate.c:512:37: warning: Using plain integer as NULL pointer inflate.c:513:40: warning: Using plain integer as NULL pointer inflate.c:525:32: warning: Using plain integer as NULL pointer inflate.c:529:52: warning: Using plain integer as NULL pointer inflate.c:543:54: warning: Using plain integer as NULL pointer inflate.c:932:17: warning: Using plain integer as NULL pointer inflate.c:932:42: warning: Using plain integer as NULL pointer inflate.c:935:26: warning: Using plain integer as NULL pointer inflate.c:940:19: warning: Using plain integer as NULL pointer adler32.c:58:5: warning: non-ANSI definition of function 'adler32' adler32.c:81:16: warning: Using plain integer as NULL pointer zutil.c:53:9: warning: non-ANSI definition of function 'zcalloc' zutil.c:64:9: warning: non-ANSI definition of function 'zcfree' inffast.c:70:1: warning: non-ANSI definition of function 'inflate_fast' inftrees.c:33:1: warning: non-ANSI definition of function 'inflate_table' Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
* lib: zlib: remove the limitation for cannot using 0 as startLei Wen2012-09-291-3/+1
| | | | | | | | | | We often need the requirement that compressing those memory range start from 0, but the default deflate code in zlib prevent us to do this. Considering the special case of uboot, that it could access all memory range, it is reasonable to be able to also take the address space from 0 into compression. Signed-off-by: Lei Wen <leiwen@marvell.com>
* lib: zlib: include deflate into zlib buildLei Wen2012-09-293-4/+16
| | | | | | | Add a new config CONFIG_GZIP_ENABLED, if enabled, the uboot bin would include zlib's deflate method which could be used for compressing. Signed-off-by: Lei Wen <leiwen@marvell.com>
* lib: zlib: import trees file from 1.2.5Lei Wen2012-09-292-0/+1371
| | | | Signed-off-by: Lei Wen <leiwen@marvell.com>
* lib: zlib: import deflate source file from 1.2.5Lei Wen2012-09-292-0/+2176
| | | | Signed-off-by: Lei Wen <leiwen@marvell.com>
* zlib: Fix integer cast of pointerSimon Glass2011-10-281-1/+1
| | | | | | Fix to cast an integer to a pointer using uintptr_t. Signed-off-by: Simon Glass <sjg@chromium.org>
* zlib: handle overflow while calculating available stream input sizeAnatolij Gustschin2011-10-171-0/+8
| | | | | | | | | | | | | | | | | | | | | If compressed data is located in sectors at the end of the flash and it's offset + input stream size > 0xFFFFFFFF, the uncompressing time is very long, since processing of the stream is done bytewise (and not blockwise) due to overflow in inflate_fast() while calculation and checking for enough input available. Check for this overflow condition and limit the available stream input size to the actually max. possible input size. This fixes the problem. The issue is easily reproduceable by placing a gziped bitmap in flash, e.g. at FFF80000, and running 'bmp' commands like 'bmp info FFF80000' or 'bmp display FFF80000'. The uncompressing can take up to 3 sec. whereas it should normaly take a fraction of a second. If the 'splashimage' environment variable points to this address, the booting time also increases significantly. Signed-off-by: Anatolij Gustschin <agust@denx.de>
* zlib: fix DEBUG buildMike Frysinger2011-05-121-1/+2
| | | | | | | | The previous commit imported a little too much from upstream. We need to disable stdio.h when using U-Boot. Reported-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* zlib: split up to match original source treeMike Frysinger2011-04-3013-0/+2316
While looking to upgrade to zlib-1.2.5, the current mondo merge of multiple files into a single was making things way more difficult than it should have been. Hard to pick out what has been changed to port it to U-Boot, been removed as useless, and bug fixes added after the fact. So split the single file up into the original file names, and merge non-essential changes back from the original tree (for some reason, style in code in a bunch of places was changed to U-Boot style even though this isn't "U-Boot" code). The original build style is retained -- we have a single zlib.c that includes all the other files, and that is the only file we compile. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
View Lorry Controller Status