BMC/Intel-BMC/linux.git/arch/m32r/boot/compressed/Makefile, branch dev

m32r: consistently use "suffix-$(...)"

2012-07-17T23:21:30+00:00

Commit a556bec9955c ("m32r: fix arch/m32r/boot/compressed/Makefile") changed "$(suffix_y)" to "$(suffix-y)", but didn't update any location where "suffix_y" is set, causing: make[5]: *** No rule to make target `arch/m32r/boot/compressed/vmlinux.bin.', needed by `arch/m32r/boot/compressed/piggy.o'. Stop. make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2 make[3]: *** [zImage] Error 2 Correct the other locations to fix this. Signed-off-by: Geert Uytterhoeven Cc: Hirokazu Takata Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

m32r: fix arch/m32r/boot/compressed/Makefile

2009-11-09T00:00:50+00:00

- Fix a comment string - Fix a typo of $(suffix-y) Signed-off-by: Hirokazu Takata

m32r: bzip2/lzma kernel compression support

2009-11-03T23:37:33+00:00

- Support bzip2 and lzma kernel compression for m32r. - Clean up arch/m32r/boot/compressed/misc.c. Signed-off-by: Hirokazu Takata

m32r: build fix for __stringify macro

2009-05-02T12:43:26+00:00

This patch fixes the following build error of 2.6.30-rc3-git2: AS arch/m32r/kernel/head.o In file included from /include/linux/init.h:7, from /arch/m32r/kernel/head.S:11: /include/linux/stringify.h:9: error: syntax error in macro parameter list /include/linux/stringify.h:10: error: syntax error in macro parameter list This build error was caused at __HEAD macro in arch/m32r/kernel/head.S, which uses __stringify() macro. Remove -traditional option from EXTRA_AFLAGS for the m32r, because the __stringify() macro depends on the gcc's variadic macro extension function, due to commit: Make __stringify support variable argument macros too commit: 8f7c2c37319a81ef4c2bfdec67b1ccd5744d97e4 Signed-off-by: Hirokazu Takata

Linux-2.6.12-rc2

2005-04-16T22:20:36+00:00

Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!