summaryrefslogtreecommitdiff
path: root/common/dlmalloc.c
Commit message (Collapse)AuthorAgeLines
* Move initf_malloc() to a common placeSimon Glass2015-04-23-0/+11
| | | | | | | To allow this function to be used from SPL, move it to the malloc() code. Signed-off-by: Simon Glass <sjg@chromium.org>
* dlmalloc: do memset in malloc init as new default configPrzemyslaw Marczak2015-03-09-3/+7
| | | | | | | | | | | | | | | | | | | | | | | 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>
* dm: Split the simple malloc() implementation into its own fileSimon Glass2014-11-21-14/+5
| | | | | | | | | | | | | | | | | | | | 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>
* malloc: Output region when debuggingThierry Reding2014-11-12-0/+3
| | | | | | | 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>
* dlmalloc: ensure gd is set for early allocRabin Vincent2014-11-07-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* sandbox: Always enable malloc debugSimon Glass2014-07-23-0/+4
| | | | | | | | 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>
* Add a simple malloc() implementation for pre-relocationSimon Glass2014-07-23-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove form-feeds from dlmalloc.cSimon Glass2014-07-23-23/+23
| | | | | | | | | | 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>
* Consolidate bool typeYork Sun2013-04-01-1/+1
| | | | | | | | | | | | | '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>
* malloc: make malloc_bin_reloc staticGabor Juhos2013-02-19-1/+5
| | | | | | | | | | | | | | | | | | | 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>
* common/misc: sparse fixesKim Phillips2012-11-04-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix strict-aliasing warning in dlmallocSimon Glass2012-09-13-5/+5
| | | | | | | | | | | | | | | 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>
* utx8245: fix build breakage due to assert()Wolfgang Denk2011-09-10-6/+0
| | | | | | | | | | | | | | | | | | 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>
* Add assert() for debug assertionsSimon Glass2011-09-10-7/+0
| | | | | | | | | | | | | | | 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>
* malloc: Fix issue with calloc memory possibly being non-zeroKumar Gala2010-11-17-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Replace CONFIG_RELOC_FIXUP_WORKS by CONFIG_NEEDS_MANUAL_RELOCWolfgang Denk2010-10-29-1/+1
| | | | | | | | | | | 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>
* dlmalloc.c: Fix gcc alias warningJoakim Tjernlund2010-10-18-1/+1
| | | | | | | | | | | | | | 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>
* New implementation for internal handling of environment variables.Wolfgang Denk2010-09-19-14/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* malloc: sbrk() should return MORECORE_FAILURE instead of NULL on failurekarl.beldan@gmail.com2010-04-10-1/+1
| | | | Signed-off-by: Karl Beldan <karl.beldan@gmail.com>
* malloc: return NULL if not initialized yetWolfgang Denk2010-01-15-0/+6
| | | | | | | | | | | 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>
* i386: Fix malloc initializationGraeme Russ2009-12-05-6/+0
| | | | Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
* Conditionally perform common relocation fixupsPeter Tyser2009-10-03-0/+2
| | | | | | | | | | | 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>
* Consolidate arch-specific mem_malloc_init() implementationsPeter Tyser2009-09-04-0/+15
| | | | Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
* Consolidate arch-specific sbrk() implementationsPeter Tyser2009-09-04-1/+17
| | | | Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
* Fix merge problemsStefan Roese2008-08-06-10/+11
| | | | Signed-off-by: Stefan Roese <sr@denx.de>
* Make sure common.h is the first include.Kumar Gala2008-06-03-1/+2
| | | | | | | | | 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>
* GCC-4.x fixes: clean up global data pointer initialization for all boards.Wolfgang Denk2006-03-31-2/+2
|
* * Code cleanup:wdenk2003-06-27-289/+274
| | | | | | | | | - 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)
* Initial revisionwdenk2002-10-25-0/+3317
generated by cgit v1.1 at 2024-11-05 05:50:22 +0000