[U-Boot] [PATCH] Add NanoBone board support

[Tom Rini]

On Tue, Apr 16, 2013 at 08:14:13PM +0100, Mark Jackson wrote:

> On 16/04/13 16:48, Tom Rini wrote:
> >On Tue, Apr 16, 2013 at 04:02:34PM +0100, Mark Jackson wrote:
> >
> >[snip]
> >>+static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
> >
> >Why are we bringing this in?
> 
> There's currently no way to enable BCH8 ECC mode.  I need this so
> that all writes to the on-board NAND have the correct ECC values.
> 
> There's a similar bunch of code in the OMAP3 board.c file, so I just
> copied that principal.
> 
> Ah ... I've just seen this changed recently (don't know why my code
> even compiles now as the headers are different !!).  I'll just back
> this out and use the existing version.

Right, for am335x we just always do BCH8 in hardware (can't easily make
SW matching BCH8).  Once we have BCH16 it'll also be automatic switching
since that's what the ROM does and we always want to be ROM-compatible.

> >>+	config_ddr(303, MT41J128MJT125_IOCTRL_VALUE, &ddr3_data,
> >>+		   &ddr3_cmd_ctrl_data, &ddr3_emif_reg_data, 0);
> >
> >And are you unable to run at 400MHz here?  Or just weren't aware /
> >having tried updating the timing parameters, etc?
> 
> Again, I just copied the EVM-SK code.
> 
> DDR3 is a new technology for us, but now the board essentially works
> I should (when I have time !!) be able do some further timing
> tweaks.

You should be able to come up with optimal ones with your DDR data sheet
and the TRM at hand.

> >>+static struct cpsw_platform_data cpsw_data = {
> >>+	.mdio_base		= CPSW_MDIO_BASE,
> >>+	.cpsw_base		= CPSW_BASE,
> >>+	.mdio_div		= 0xff,
> >>+	.channels		= 8,
> >>+	.cpdma_reg_ofs		= 0x800,
> >>+	.slaves			= 2,
> >
> >Is this all that was needed for both interfaces to work in U-Boot, along
> >with a config change or two?  If so, I should take a stab at getting
> >both working on the EVM-SK.
> 
> Yes ... the config change is just to set CONFIG_PHY_ADDR to the
> correct value.
> 
> Unfortunately, since the CONFIG_PHY_ADDR value is "hard-coded" into
> quite a bit of the uboot code, to change ports, you need to
> re-compile !!  Not ideal, and I don't suppose it's too much work to
> get both
> working together, but I don't see much demand for it.

Ah, so it's not quite right :(  Other platforms support multiple
interfaces, but I don't know how they're setup.

[snip]
> >>+#define CONFIG_SYS_NO_FLASH
> >
> >But you have NOR.  Is it not working yet?
> 
> We do have NOR and it's working, but it doesn't contain any "user
> accessible" data.  We use it as long-term storage using a custom
> layout, so there's no point in exposing it to uboot.

A comment above please, roughly to that effect?

[snip]
> >>+#define CONFIG_SYS_HZ			1000 /* 1ms clock */
> >[snip]
> >>+#define CONFIG_SYS_HZ			1000
> >
> >I see this is a copy/paste problem too from am335x_evm.h, can you fix
> >there and pcm051.h?
> 
> Sure, I'll post a "remove duplicate #defines" patch.
> 
> >>+#define CONFIG_SERIAL_MULTI
> >
> >Same (not needed anymore, not sure how it didn't get removed before).
> 
> Ok.

Thanks!

> >>+#define CONFIG_CMD_EEPROM
> >>+#define CONFIG_SYS_I2C_EEPROM_ADDR	0x50	/* Main EEPROM */
> >>+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN	2
> >>+#define CONFIG_SYS_I2C_MULTI_EEPROMS
> >
> >Do you really have the EEPROM at 0x50 like the TI boards do (and then at
> >other offets for capes/daughter cards) ?
> 
> Yes, but it doesn't contain the same TI EEPROM data structure.  In
> fact, at the moment, it doesn't contain anything (!!).
> 
> It's just there for future expansion .... in which case, should I
> remove the #defines for the time being ?

No, that's fine, just making sure it's really there.

> >>+#define	CONFIG_SYS_NAND_ECCTOTAL	(CONFIG_SYS_NAND_ECCBYTES * \
> >>+						CONFIG_SYS_NAND_ECCSTEPS)
> >>+
> >>+#define	CONFIG_SYS_NAND_U_BOOT_START	CONFIG_SYS_TEXT_BASE
> >
> >Another problem duplicated from am335x_evm.h :(
> 
> I'll add it to the "remove duplicates" patch.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130416/f42f906a/attachment.pgp>