[U-Boot] [PATCH 4/4 v3] s5pc1xx: add support SMDKC100 board
Tom
Tom.Rix at windriver.com
Tue Sep 22 18:13:16 CEST 2009
Peter Tyser wrote:
> On Tue, 2009-09-22 at 10:03 -0500, Tom wrote:
>> Minkyu Kang wrote:
>>> Adds new board SMDKC100 that uses s5pc100 SoC
>>>
>>> Signed-off-by: Minkyu Kang <mk7.kang at samsung.com>
>>> Signed-off-by: HeungJun, Kim <riverful.kim at samsung.com>
>>> ---
>>> Changes since v1:
>>> - arrange env values for more readable
>>> - make C struct instead of base+offset
>>> - use MACH_TYPE_SMDKC100 directly
>>> - fix the CONFIG_SYS_HZ to 1000
>>> - enable LOADB, LOADS, BOOTD, XIMG, FPGA
>>>
>>> Changes since v2:
>>> - remove <asm/sizes.h> and SZ_XX defines
>>> - remove the define of machine type
>>> - remove the unnecessary comment
>>>
>>> MAINTAINERS | 4 +
>>> MAKEALL | 1 +
>>> Makefile | 3 +
>>> board/samsung/smdkc100/Makefile | 55 +++++++
>>> board/samsung/smdkc100/config.mk | 16 ++
>>> board/samsung/smdkc100/lowlevel_init.S | 215 ++++++++++++++++++++++++++++
>>> board/samsung/smdkc100/mem_setup.S | 197 ++++++++++++++++++++++++++
>>> board/samsung/smdkc100/onenand.c | 83 +++++++++++
>>> board/samsung/smdkc100/smdkc100.c | 51 +++++++
>>> include/configs/smdkc100.h | 242 ++++++++++++++++++++++++++++++++
>>> 10 files changed, 867 insertions(+), 0 deletions(-)
>>> create mode 100644 board/samsung/smdkc100/Makefile
>>> create mode 100644 board/samsung/smdkc100/config.mk
>>> create mode 100644 board/samsung/smdkc100/lowlevel_init.S
>>> create mode 100644 board/samsung/smdkc100/mem_setup.S
>>> create mode 100644 board/samsung/smdkc100/onenand.c
>>> create mode 100644 board/samsung/smdkc100/smdkc100.c
>>> create mode 100644 include/configs/smdkc100.h
>>>
>> Please include a brief readme doc/README.s5pc1xx similar to README.omap
>
> Hi Tom,
> Others may disagree, but I'm personally opposed to creating
Slugfest over documentation!
I can see you point. If you have the board you likely have the user manual.
In no way do I want a user manual.
Mostly what I am looking for brief product description and a list of the
configs. Maybe some hints if the setup is tricky. README.omap3 contains
writeups on 6 boards, each get about 10 lines.
The vendor readme is also good if you want to convey board family u-boot
interfaces to other developers. See my writeup of omap gpio in omap3.
> board/vendor-specific doc/README.<board> files in most cases. My logic
> is that the people that are compiling and using U-Boot on my company's
> boards will have bought the boards from us, and we should be the ones
> providing them documentation. eg I would guess the vast majority of
> board vendors don't say "for board information consult
> doc/README.<board> in the U-Boot source code", they provide a PDF, text
> document, datasheet, etc about the board and how it can be used. Thus
> the doc/README.<board> doesn't really provide any useful info.
This is doc/README.<soc>
>
> I think the doc/README.<board> files have a tendency to get out of date,
> reference old commands, etc so are often not the best source of
> reference anyway. eg take a look at doc/README.m5373evb. I'd argue a
> lot of that info isn't necessary, and some of its duplicated in other
> places.
>
Yes this is excessive :|
> I only care because I hate having to pick through 10 board-specific
> README files every time I make a change the renames a command, adds a
> new command, changes a CONFIG_XYZ name, etc:)
>
This should be the task of the board/soc maintainer.
> I think README files are good in general, but board-specific details
> should be documented elsewhere such as a product manual.
>
> Anyway, that's my $.02.
Taking it outside over documentation,
Tom
>
> Best,
> Peter
>
More information about the U-Boot
mailing list