[PATCH] arm: mvebu: Add Allied Telesis x250 board

[Chris Packham]

Hi Tom,

Thanks for the quick response

On Wed, Nov 20, 2024 at 2:23 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Nov 20, 2024 at 01:16:00PM +1300, Chris Packham wrote:
>
> > The x250 and SE240 are series of 10G L2+ switches from Allied Telesis.
> > There are a number of them in the range but as far as U-Boot is
> > concerned all the CPU block components are the same so there's only one
> > board defined.
> >
> > Signed-off-by: Chris Packham <judge.packham at gmail.com>
> [snip]
> > diff --git a/include/configs/x250.h b/include/configs/x250.h
> > new file mode 100644
> > index 000000000000..5a3f445e218c
> > --- /dev/null
> > +++ b/include/configs/x250.h
> > @@ -0,0 +1,54 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2024 Allied Telesis
> > + */
> > +
> > +#ifndef __X250_H_
> > +#define __X250_H_
> > +
> > +/*
> > + * High Level Configuration Options (easy to change)
> > + */
> > +#define CFG_SYS_TCLK         250000000       /* 250MHz */
> > +
> > +/* additions for new ARM relocation support */
> > +#define CFG_SYS_SDRAM_BASE   0x00000000
> > +
> > +/* auto boot */
> > +
> > +#define CFG_SYS_BAUDRATE_TABLE   { 9600, 19200, 38400, 57600, \
> > +                                   115200, 230400, 460800, 921600 }
>
> We really can't use the default table?
>
> > +
> > +/*
> > + * Other required minimal configurations
> > + */
> > +
> > +/* When runtime detection fails this is the default */
> > +
> > +/* USB ethernet */
>
> Dead comments.
>
> > +
> > +/*
> > + * PCI configuration
> > + */
>
> Probably doesn't apply to this section..
>

All copy and paste. Infact I'm not sure I can use the baud rates
>115200. I'll drop them

> > +#ifdef CONFIG_DISTRO_DEFAULTS
> > +#define BOOT_TARGET_DEVICES(func) \
> > +     func(USB, usb, 0) \
> > +     func(SCSI, scsi, 0) \
> > +     func(PXE, pxe, na) \
> > +     func(DHCP, dhcp, na)
> > +
> > +#include <config_distro_bootcmd.h>
> > +#else
> > +#define BOOTENV
> > +#endif
>
> And you should move to bootstd.
>

I'll look into that. For our internal purposes we don't actually use
this as we have some legacy things we do to boot our images. For my
own testing I tend to just use bootm directly.