Dear Otavio Salvador, > On Sat, Jan 12, 2013 at 2:16 PM, Marek Vasut <[email protected]> wrote: > > Dear Otavio Salvador, > > > >> On Fri, Jan 11, 2013 at 9:27 PM, Marek Vasut <[email protected]> wrote: > >> > This patch adds support for MX23-based Olinuxino board. > >> > > >> > Signed-off-by: Marek Vasut <[email protected]> > >> > Cc: Fabio Estevam <[email protected]> > >> > Cc: Otavio Salvador <[email protected]> > >> > Cc: Stefano Babic <[email protected]> > >> > --- > >> > > >> > MAINTAINERS | 1 + > >> > board/olimex/mx23_olinuxino/Makefile | 47 +++++++++ > >> > board/olimex/mx23_olinuxino/mx23_olinuxino.c | 51 ++++++++++ > >> > board/olimex/mx23_olinuxino/spl_boot.c | 90 +++++++++++++++++ > >> > boards.cfg | 1 + > >> > include/configs/mx23_olinuxino.h | 133 > >> > ++++++++++++++++++++++++++ 6 files changed, 323 insertions(+) > >> > create mode 100644 board/olimex/mx23_olinuxino/Makefile > >> > create mode 100644 board/olimex/mx23_olinuxino/mx23_olinuxino.c > >> > create mode 100644 board/olimex/mx23_olinuxino/spl_boot.c > >> > create mode 100644 include/configs/mx23_olinuxino.h > >> > > >> > V2: Add MAINTAINERS entry > >> > > >> > Remove CONFIG_MACH_TYPE (as this board is DT-only) > >> > >> In fact it is not DT-only; we support it in linux-imx inside of OE and > >> the images provided by Olinex are also based 2.6.35 so it seems better > >> to define the machine type. > > > > Can be added in a subsequent patch. > > [...] > > I don't think it is the way to go for several reasons, mainly: > > * your v1 had this support
0xffffffff is DT boot ID really. > * all sdcards provided by olimex use 2.6.35 kernel (until now) > * the FSL supported kernel is non-DT > > So I see no reason to not fix the patch, seriously. Can you provide pointer to olinuxino machine entry in RMK's ID database then please? > >> > +/* > >> > + * U-Boot general configurations > >> > + */ > >> > +#define CONFIG_SYS_LONGHELP > >> > +#define CONFIG_SYS_PROMPT "=> " > >> > +#define CONFIG_SYS_CBSIZE 1024 /* Console I/O > >> > buffer size */ > >> > >> The SYS_CBSIZE might be smaller I think; we use 256 in sabresd and > >> others which have a much bigger environment so I think it could be > >> reduced. > > > > Can you elaborate what issues this causes please? > > It causes nothing except more memory allocation than need. As other > bords work fine with less it seems a good option to move to a smaller > value. Just it. It reduces the size of console buffer, right? Best regards, Marek Vasut _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
