summaryrefslogtreecommitdiff
path: root/common/dlmalloc.c
AgeCommit message (Collapse)Author
2016-03-08malloc: remove !gd handlingStephen Warren
Following the previous patch, malloc() is never called before gd is set, so we can remove the special-case check for this condition. This reverts commit 854d2b9753e4 "dlmalloc: ensure gd is set for early alloc". Cc: Rabin Vincent <rabin@rab.in> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-02-08malloc: solve dead code issue in memalign()Stephen Warren
The recent change to memalign() caused the allocation failure detection code to be dead code; the "retry" logic is always activated under the same condition that the original failure detection code is, and also fully handles any possible failures. This patch solves the presence of dead code. Two alternatives are possible: a) Delete the now-dead test, and rely on the "retry" path to handle any allocation problems, as it does. b) Make the "retry" path fall through to the existing (currently dead) failure detection code, thus making it not-dead. (b) was chosen since it reduces the diff between U-Boot's and the upstream dlmalloc. This should make it marginally easier to import a new version of dlmalloc in the future. Reported by: Coverity Scan Fixes: 4f144a416469 ("malloc: work around some memalign fragmentation issues") Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-02-01malloc: work around some memalign fragmentation issuesStephen Warren
Use of memalign can trigger fragmentation issues such as: // Internally, this needs to find a free block quite bit larger than s. // Once the free region is found, any unaligned "padding" immediately // before and after the block is marked free, so that the allocation // takes only s bytes (plus malloc header overhead). p = memalign(a, s); // If there's little fragmentation so far, this allocation is likely // located immediately after p. p2 = malloc(x); free(p); // In theory, this should return the same value for p. However, the hole // left by the free() call is only s in size (plus malloc header overhead) // whereas memalign searches for a larger block in order to guarantee it // can adjust the returned pointer to the alignment requirements. Hence, // the pointer returned, if any, won't be p. If there's little or no space // left after p2, this allocation will fail. p = memalign(a, s); In practice, this issue occurs when running the "dfu" command repeatedly on NVIDIA Tegra boards, since DFU allocates a large 32M data buffer, and then initializes the USB controller. If this is the first time USB has been used in the U-Boot session, this causes a probe of the USB driver, which causes various allocations, including a strdup() of a GPIO name when requesting the VBUS GPIO. When DFU is torn down, the USB driver is left probed, and hence its memory is left allocated. If "dfu" is executed again, allocation of the 32M data buffer fails as described above. In practice, there is a memory hole exactly large enough to hold the 32M data buffer than DFU needs. However, memalign() can't know that in a general way. Given that, it's particularly annoying that the allocation fails! The issue is that memalign() tries to allocate something larger to guarantee the ability to align the returned pointer. This patch modifies memalign() so that if the "general case" over-sized allocation fails, another allocation is attempted, of the exact size the user desired. If that allocation just happens to be aligned in the way the user wants, (and in the case described above, it will be, since the free memory region is located where a previous identical allocation was located), the pointer can be returned. This patch is somewhat related to 806bd245b1ab "dfu: don't keep freeing/reallocating". That patch worked around the issue by removing repeated free/memalign within a single execution of "dfu". However, the same technique can't be applied across multiple invocations, since there's no reason to keep the DFU buffer allocated while DFU isn't running. This patch addresses the root-cause a bit more directly. This problem highlights some of the disadvantages of dynamic allocation and deferred probing of devices. This patch isn't checkpatch-clean, since it conforms to the existing coding style in dlmalloc.c, which is different to the rest of U-Boot. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Lukasz Majewski <l.majewski@samsung.com>
2015-04-23Move initf_malloc() to a common placeSimon Glass
To allow this function to be used from SPL, move it to the malloc() code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-09dlmalloc: do memset in malloc init as new default configPrzemyslaw Marczak
This commit introduces new config: CONFIG_SYS_MALLOC_CLEAR_ON_INIT. This config is an expert option and is enabled by default. The all amount of memory reserved for the malloc, is by default set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down. So disabling this config, is an expert option to reduce the boot time, and can be disabled by Kconfig. Note: After disable this option, only calloc() will return the pointer to the zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2014-11-21dm: Split the simple malloc() implementation into its own fileSimon Glass
The simple malloc() implementation is used when memory is tight. It provides a simple buffer with an incrementing pointer. At present the implementation is inside dlmalloc. Move it into its own file so that it is easier to find. Rather than using relocation as a signal that the full malloc() is available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the simple malloc() should no longer be used. In some cases, such as SPL, even the code space used by the full malloc() is wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple malloc. In this case the full malloc is not available at all. It saves about 1KB of code space and about 0.5KB of data on Thumb 2. Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-12malloc: Output region when debuggingThierry Reding
When DEBUG is set, output memory region used for malloc(). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-11-07dlmalloc: ensure gd is set for early allocRabin Vincent
Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized. Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point. $ gdb -q --args ./u-boot (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 2184 if (!(gd->flags & GD_FLG_RELOC)) { (gdb) p gd $1 = (gd_t *) 0x0 (gdb) bt #0 0x0000000000412b9b in malloc (bytes=bytes@entry=37) at common/dlmalloc.c:2184 #1 0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0) at bindtextdom.c:228 #2 0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350 #3 __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348 #4 0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0 #5 0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe208, env=env@entry=0x7fffffffe218) at dl-init.c:78 #6 0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36 #7 _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126 #8 0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 Signed-off-by: Rabin Vincent <rabin@rab.in> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-23sandbox: Always enable malloc debugSimon Glass
Tun on DEBUG in malloc(). This adds code space and slows things down but for sandbox this is acceptable. We gain the ability to check for memory leaks in tests. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23Add a simple malloc() implementation for pre-relocationSimon Glass
If we are to have driver model before relocation we need to support some way of calling memory allocation routines. The standard malloc() is pretty complicated: 1. It uses some BSS memory for its state, and BSS is not available before relocation 2. It supports algorithms for reducing memory fragmentation and improving performace of free(). Before relocation we could happily just not support free(). 3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since this has been loaded anyway this is not really a problem. The simplest way to support pre-relocation malloc() is to reserve an area of memory and allocate it in increasing blocks as needed. This implementation does this. To enable it, you need to define the size of the malloc() pool as described in the README. It will be located above the pre-relocation stack on supported architectures. Note that this implementation is only useful on machines which have some memory available before dram_init() is called - this includes those that do no DRAM init (like tegra) and those that do it in SPL (quite a few boards). Enabling driver model preior to relocation for the rest of the boards is left for a later exercise. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-07-23Remove form-feeds from dlmalloc.cSimon Glass
These don't really serve any purpose in the modern age. On the other hand they show up as annoying control characters in my editor, which then happily removes them. I believe we can drop these characters from the file. Signed-off-by: Simon Glass <sjg@chromium.org>
2013-04-01Consolidate bool typeYork Sun
'bool' is defined in random places. This patch consolidates them into a single header file include/linux/types.h, using stdbool.h introduced in C99. All other #define, typedef and enum are removed. They are all consistent with true = 1, false = 0. Replace FALSE, False with false. Replace TRUE, True with true. Skip *.py, *.php, lib/* files. Signed-off-by: York Sun <yorksun@freescale.com>
2013-02-19malloc: make malloc_bin_reloc staticGabor Juhos
On architectures where manual relocation is needed, the 'malloc_bin_reloc' function must be called after 'mem_malloc_init'. Make the 'malloc_bin_reloc' function static and call it directly from 'mem_malloc_init' instead of calling that from board_init_{r,f} functions of the affected architectures. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Cc: Wolfgang Denk <wd@denx.de> Cc: Andreas Bießmann <andreas.devel@gmail.com> Cc: Jason Jin <Jason.jin@freescale.com> Cc: Macpaul Lin <macpaul@andestech.com> Cc: Daniel Hellstrom <daniel@gaisler.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
2012-11-04common/misc: sparse fixesKim Phillips
command.c:44:38: error: bad constant expression dlmalloc.c:1468:2: warning: Using plain integer as NULL pointer dlmalloc.c:1468:5: warning: Using plain integer as NULL pointer dlmalloc.c:2176:12: warning: Using plain integer as NULL pointer dlmalloc.c:2179:31: warning: Using plain integer as NULL pointer dlmalloc.c:2382:14: warning: Using plain integer as NULL pointer dlmalloc.c:2436:14: warning: Using plain integer as NULL pointer dlmalloc.c:2582:31: warning: Using plain integer as NULL pointer dlmalloc.c:2585:17: warning: Using plain integer as NULL pointer dlmalloc.c:2646:14: warning: Using plain integer as NULL pointer dlmalloc.c:2659:19: warning: Using plain integer as NULL pointer dlmalloc.c:2692:19: warning: Using plain integer as NULL pointer dlmalloc.c:2707:19: warning: Using plain integer as NULL pointer dlmalloc.c:2708:14: warning: Using plain integer as NULL pointer dlmalloc.c:2786:31: warning: Using plain integer as NULL pointer dlmalloc.c:2801:12: warning: Using plain integer as NULL pointer dlmalloc.c:2801:22: warning: Using plain integer as NULL pointer dlmalloc.c:2926:27: warning: Using plain integer as NULL pointer dlmalloc.c:2928:14: warning: Using plain integer as NULL pointer dlmalloc.c:2929:12: warning: Using plain integer as NULL pointer dlmalloc.c:3075:14: warning: Using plain integer as NULL pointer hush.c:292:14: warning: symbol 'last_return_code' was not declared. Should it be static? hush.c:293:5: warning: symbol 'nesting_level' was not declared. Should it be static? hush.c:2175:20: warning: Using plain integer as NULL pointer hush.c:2175:34: warning: Using plain integer as NULL pointer hush.c:2210:41: warning: Using plain integer as NULL pointer hush.c:2216:45: warning: Using plain integer as NULL pointer hush.c:2249:25: warning: Using plain integer as NULL pointer hush.c:2332:13: warning: symbol 'new_pipe' was not declared. Should it be static? hush.c:2390:5: warning: symbol 'reserved_word' was not declared. Should it be static? hush.c:2927:5: warning: symbol 'parse_stream' was not declared. Should it be static? hush.c:3127:6: warning: symbol 'mapset' was not declared. Should it be static? hush.c:3133:6: warning: symbol 'update_ifs_map' was not declared. Should it be static? hush.c:3161:5: warning: symbol 'parse_stream_outer' was not declared. Should it be static? hush.c:3295:34: warning: Using plain integer as NULL pointer hush.c:3631:5: warning: symbol 'do_showvar' was not declared. Should it be static image.c:1282:29: warning: Using plain integer as NULL pointer image.c:1315:41: warning: Using plain integer as NULL pointer image.c:1330:25: warning: Using plain integer as NULL pointer image.c:1706:25: warning: Using plain integer as NULL pointer main.c:510:10: warning: symbol 'hist_num' was not declared. Should it be static? main.c:512:5: warning: symbol 'hist_list' was not declared. Should it be static? main.c:513:6: warning: symbol 'hist_lines' was not declared. Should it be static? usb_storage.c:195:6: warning: symbol 'usb_show_progress' was not declared. Should it be static? usb_storage.c:440:48: warning: Using plain integer as NULL pointer usb_storage.c:503:5: warning: symbol 'usb_stor_BBB_comdat' was not declared. Should it be static? usb_storage.c:551:5: warning: symbol 'usb_stor_CB_comdat' was not declared. Should it be static? usb_storage.c:629:55: warning: Using plain integer as NULL pointer usb_storage.c:620:5: warning: symbol 'usb_stor_CBI_get_status' was not declared. Should it be static? usb_storage.c:675:43: warning: Using plain integer as NULL pointer usb_storage.c:668:5: warning: symbol 'usb_stor_BBB_clear_endpt_stall' was not declared. Should it be static? usb_storage.c:679:5: warning: symbol 'usb_stor_BBB_transport' was not declared. Should it be static? usb_storage.c:801:5: warning: symbol 'usb_stor_CB_transport' was not declared. Sh xyzModem.c:104:1: warning: symbol 'CYGACC_COMM_IF_GETC_TIMEOUT' was not declared. Should it be static? xyzModem.c:122:1: warning: symbol 'CYGACC_COMM_IF_PUTC' was not declared. Should it be static? xyzModem.c:169:1: warning: symbol 'parse_num' was not declared. Should it be stat note: hush.c's nesting_level deleted because not used. Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
2012-09-13Fix strict-aliasing warning in dlmallocSimon Glass
This fixes the following warnings in dlmalloc seen with my gcc 4.6. dlmalloc.c: In function 'malloc_bin_reloc': dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1493: warning: dereferencing pointer 'p' does break strict-aliasing rules dlmalloc.c:1490: note: initialized from here dlmalloc.c:1493: note: initialized from here This version is tested on avr32 arch boards. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
2011-09-10utx8245: fix build breakage due to assert()Wolfgang Denk
Commit 21726a7 "Add assert() for debug assertions" broke building the utx8245 board: dlmalloc.c: In function 'do_check_chunk': dlmalloc.c:1660: error: 'sz' undeclared (first use in this function) dlmalloc.c:1660: error: (Each undeclared identifier is reported only once dlmalloc.c:1660: error: for each function it appears in.) dlmalloc.c: In function 'do_check_free_chunk': dlmalloc.c:1689: error: 'next' undeclared (first use in this function) dlmalloc.c: In function 'do_check_malloced_chunk': dlmalloc.c:1748: error: 'sz' undeclared (first use in this function) dlmalloc.c:1750: error: 'room' undeclared (first use in this function) Signed-off-by: Wolfgang Denk <wd@denx.de> Cc: Simon Glass <sjg@chromium.org>
2011-09-10Add assert() for debug assertionsSimon Glass
assert() is like BUG_ON() but compiles to nothing unless DEBUG is defined. This is useful when a condition is an error but a board reset is unlikely to fix it, so it is better to soldier on in hope. Assertion failures should be caught during development/test. It turns out that assert() is defined separately in a few places in U-Boot with various meanings. This patch cleans up some of these. Build errors exposed by this change (and defining DEBUG) are also fixed in this patch. Signed-off-by: Simon Glass <sjg@chromium.org>
2010-11-17malloc: Fix issue with calloc memory possibly being non-zeroKumar Gala
Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always returns zero'd out memory. However since its possible that free() returns memory back to sbrk() via malloc_trim we could possible get non-zero'd memory from sbrk(). This is a problem for when code might call calloc() and expect the memory to have been zero'd out. There are two possible solutions to this problem. 1. change #define MORECORE_CLEARS 0 2. memset to zero memory returned to sbrk. We go with the second since the sbrk being called to free up memory should be pretty rare. The following code problems an example test to show the issue. This test code was inserted right after the call to mem_malloc_init(). ... u8 *p2; int i; printf("MALLOC TEST\n"); p1 = malloc(135176); printf("P1 = %p\n", p1); memset(p1, 0xab, 135176); free(p1); p2 = calloc(4097, 1); printf("P2 = %p %p\n", p2, p2 + 4097); for (i = 0; i < 4097; i++) { if (p2[i] != 0) printf("miscompare at byte %d got %x\n", i, p2[i]); free(p2); printf("END MALLOC TEST\n\n"); ... Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Tested-by: Wolfgang Denk <wd@denx.de>
2010-10-29Replace CONFIG_RELOC_FIXUP_WORKS by CONFIG_NEEDS_MANUAL_RELOCWolfgang Denk
By now, the majority of architectures have working relocation support, so the few remaining architectures have become exceptions. To make this more obvious, we make working relocation now the default case, and flag the remaining cases with CONFIG_NEEDS_MANUAL_RELOC. Signed-off-by: Wolfgang Denk <wd@denx.de> Tested-by: Heiko Schocher <hs@denx.de> Tested-by: Reinhard Meyer <u-boot@emk-elektronik.de>
2010-10-18dlmalloc.c: Fix gcc alias warningJoakim Tjernlund
Fix these warnings: dlmalloc.c: In function 'free': dlmalloc.c:2507: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules dlmalloc.c:2507: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules dlmalloc.c:2507: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules Some page(http://blog.worldofcoding.com/2010/02/solving-gcc-44-strict-aliasing-problems.html) suggests adding __attribute__((__may_alias__)). Doing so makes the warnings go away. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Acked-by: Mike Frysinger <vapier@gentoo.org>
2010-09-19New implementation for internal handling of environment variables.Wolfgang Denk
Motivation: * Old environment code used a pessimizing implementation: - variable lookup used linear search => slow - changed/added variables were added at the end, i. e. most frequently used variables had the slowest access times => slow - each setenv() would calculate the CRC32 checksum over the whole environment block => slow * "redundant" envrionment was locked down to two copies * No easy way to implement features like "reset to factory defaults", or to select one out of several pre-defined (previously saved) sets of environment settings ("profiles") * No easy way to import or export environment settings ====================================================================== API Changes: - Variable names starting with '#' are no longer allowed I didn't find any such variable names being used; it is highly recommended to follow standard conventions and start variable names with an alphanumeric character - "printenv" will now print a backslash at the end of all but the last lines of a multi-line variable value. Multi-line variables have never been formally defined, allthough there is no reason not to use them. Now we define rules how to deal with them, allowing for import and export. - Function forceenv() and the related code in saveenv() was removed. At the moment this is causing build problems for the only user of this code (schmoogie - which has no entry in MAINTAINERS); may be fixed later by implementing the "env set -f" feature. Inconsistencies: - "printenv" will '\\'-escape the '\n' in multi-line variables, while "printenv var" will not do that. ====================================================================== Advantages: - "printenv" output much better readable (sorted) - faster! - extendable (additional variable properties can be added) - new, powerful features like "factory reset" or easy switching between several different environment settings ("profiles") Disadvantages: - Image size grows by typically 5...7 KiB (might shrink a bit again on systems with redundant environment with a following patch series) ====================================================================== Implemented: - env command with subcommands: - env print [arg ...] same as "printenv": print environment - env set [-f] name [arg ...] same as "setenv": set (and delete) environment variables ["-f" - force setting even for read-only variables - not implemented yet.] - end delete [-f] name not implemented yet ["-f" - force delete even for read-only variables] - env save same as "saveenv": save environment - env export [-t | -b | -c] addr [size] export internal representation (hash table) in formats usable for persistent storage or processing: -t: export as text format; if size is given, data will be padded with '\0' bytes; if not, one terminating '\0' will be added (which is included in the "filesize" setting so you can for exmple copy this to flash and keep the termination). -b: export as binary format (name=value pairs separated by '\0', list end marked by double "\0\0") -c: export as checksum protected environment format as used for example by "saveenv" command addr: memory address where environment gets stored size: size of output buffer With "-c" and size is NOT given, then the export command will format the data as currently used for the persistent storage, i. e. it will use CONFIG_ENV_SECT_SIZE as output block size and prepend a valid CRC32 checksum and, in case of resundant environment, a "current" redundancy flag. If size is given, this value will be used instead of CONFIG_ENV_SECT_SIZE; again, CRC32 checksum and redundancy flag will be inserted. With "-b" and "-t", always only the real data (including a terminating '\0' byte) will be written; here the optional size argument will be used to make sure not to overflow the user provided buffer; the command will abort if the size is not sufficient. Any remainign space will be '\0' padded. On successful return, the variable "filesize" will be set. Note that filesize includes the trailing/terminating '\0' byte(s). Usage szenario: create a text snapshot/backup of the current settings: => env export -t 100000 => era ${backup_addr} +${filesize} => cp.b 100000 ${backup_addr} ${filesize} Re-import this snapshot, deleting all other settings: => env import -d -t ${backup_addr} - env import [-d] [-t | -b | -c] addr [size] import external format (text or binary) into hash table, optionally deleting existing values: -d: delete existing environment before importing; otherwise overwrite / append to existion definitions -t: assume text format; either "size" must be given or the text data must be '\0' terminated -b: assume binary format ('\0' separated, "\0\0" terminated) -c: assume checksum protected environment format addr: memory address to read from size: length of input data; if missing, proper '\0' termination is mandatory - env default -f reset default environment: drop all environment settings and load default environment - env ask name [message] [size] same as "askenv": ask for environment variable - env edit name same as "editenv": edit environment variable - env run same as "run": run commands in an environment variable ====================================================================== TODO: - drop default env as implemented now; provide a text file based initialization instead (eventually using several text files to incrementally build it from common blocks) and a tool to convert it into a binary blob / object file. - It would be nice if we could add wildcard support for environment variables; this is needed for variable name auto-completion, but it would also be nice to be able to say "printenv ip*" or "printenv *addr*" - Some boards don't link any more due to the grown code size: DU405, canyonlands, sequoia, socrates. => cc: Matthias Fuchs <matthias.fuchs@esd-electronics.com>, Stefan Roese <sr@denx.de>, Heiko Schocher <hs@denx.de> - Dropping forceenv() causes build problems on schmoogie => cc: Sergey Kubushyn <ksi@koi8.net> - Build tested on PPC and ARM only; runtime tested with NOR and NAND flash only => needs testing!! Signed-off-by: Wolfgang Denk <wd@denx.de> Cc: Matthias Fuchs <matthias.fuchs@esd-electronics.com>, Cc: Stefan Roese <sr@denx.de>, Cc: Heiko Schocher <hs@denx.de> Cc: Sergey Kubushyn <ksi@koi8.net>
2010-04-10malloc: sbrk() should return MORECORE_FAILURE instead of NULL on failurekarl.beldan@gmail.com
Signed-off-by: Karl Beldan <karl.beldan@gmail.com>
2010-01-15malloc: return NULL if not initialized yetWolfgang Denk
When malloc() was called before it was properly initialized (as would happen if when used before relocation to RAM) it returned random, non-NULL values, which called all kinds of difficult to debug subsequent errors. Make sure to return NULL when initialization was not done yet. Signed-off-by: Wolfgang Denk <wd@denx.de>
2009-12-05i386: Fix malloc initializationGraeme Russ
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
2009-10-03Conditionally perform common relocation fixupsPeter Tyser
Add #ifdefs where necessary to not perform relocation fixups. This allows boards/architectures which support relocation to trim a decent chunk of code. Note that this patch doesn't add #ifdefs to architecture-specific code which does not support relocation. Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
2009-09-04Consolidate arch-specific mem_malloc_init() implementationsPeter Tyser
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
2009-09-04Consolidate arch-specific sbrk() implementationsPeter Tyser
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
2008-08-06Fix merge problemsStefan Roese
Signed-off-by: Stefan Roese <sr@denx.de>
2008-06-03Make sure common.h is the first include.Kumar Gala
If common.h isn't first we can get CONFIG_ options defined in the board config file ignored. This can cause an issue if any of those config options impact the size of types of data structures (eg CONFIG_PHYS_64BIT). Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2006-03-31GCC-4.x fixes: clean up global data pointer initialization for all boards.Wolfgang Denk
2003-06-27* Code cleanup:wdenk
- remove trailing white space, trailing empty lines, C++ comments, etc. - split cmd_boot.c (separate cmd_bdinfo.c and cmd_load.c) * Patches by Kenneth Johansson, 25 Jun 2003: - major rework of command structure (work done mostly by Michal Cendrowski and Joakim Kristiansen)
2002-10-25Initial revisionwdenk