[U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs

[Marek Vasut]

On Saturday, December 26, 2015 at 04:48:57 PM, Wills Wang wrote:

[...]

> > The SPI flash is an IP block which just maps the SPI NOR into the address
> > space, it doesn't use the CPU cache at all.
> > 
> > Maybe you don't even need to lock cachelines though, the AR9331 should
> > have some internal SRAM, so just use that for stack. Do you have a
> > proper datasheet for the Atheros MIPS chips ? I have some 320 pages
> > datasheet for AR9331.
> 
> I don't find any description about internal SRAM in public datasheet.
> About mapping SPI flash, there is a doubt, who fetch the instruction from
> the SPI Nor flash to CPU pipe line when chip boot from SPI flash?
> I guess that ROM code handle cache exception and load instruction/date from
> SPI flash into cache.

I just pulled out the SPI NOR from the Arduino Yun I have here and connected
an FPGA with SPI NOR emulator in there. All the chip does is it issues the
fastread opcode to the SPI NOR when it boots. It does the same thing if you
access the 0x9f000000..0x9fxxxxxx address range from the ancient U-Boot 1.1.x. 

My impression is that the SPI NOR controller in the chip does a mapping between 
the SPI NOR and the memory mapped access to the 0x9fxxxxxx range. There is no 
caching involved in that, all of this is done internally in the SPI NOR block.

The mips24kc core should support locking cache lines , so if the SRAM is not
available, this would have to do.

> >>> [...]
> >>> 
> >>>>>> +phys_size_t initdram(int board_type)
> >>>>>> +{
> >>>>>> +	uint8_t *addr, *p;
> >>>>>> +	int i;
> >>>>>> +
> >>>>>> +	ddr_tap_init();
> >>>>>> +	addr = (uint8_t *)KSEG1;
> >>>>>> +	*addr = 0x77;
> >>>>>> +	for (i = 0, p = addr; p < (uint8_t *)KSEG2; i++) {
> >>>>>> +		p += 0x1000000;
> >>>>>> +		*p = i;
> >>>>>> +		if (*addr != 0x77)
> >>>>>> +			break;
> >>>>>> +	}
> >>>>> 
> >>>>> What is this and how does it work ?
> >>>> 
> >>>> Physical memory was mapped circularly for this chip.
> >>> 
> >>> Can you please expand on that ? I am not as deep in this chip as you
> >>> are, so please explain it to me in a bit more detail.
> > 
> > Well ... ?
> 
> There is 64MB DDR on my board, the 64MB memory was mapped circularly into
> 0x00000000-0x03ffffff, 0x04000000-0x07ffffff, 0x08000000-0x0bffffff,...
> the address 0x00000000, 0x04000000 and 0x08000000 was mapped to the same
> physical memory. their corresponding KSEG1 address is 0xA0000000,
> 0xA4000000,
> 0xA8000000, when write a value into 0xA0000000, we can read the same value
> from address 0xA4000000 and 0xA8000000.

So this is some sort of poor man's memory size detection mechanism ?

See common/memsize.c , function get_ram_size() . That might help instead.

> >>>>>> +	return (phys_size_t)(p - addr);
> >>>>>> +}
> >>> 
> >>> [...]
> >>> 
> >>>>>> +	if (reg) {
> >>>>>> +		val = RST_READ(reg);
> >>>>>> +		val |= AR71XX_RESET_FULL_CHIP;
> >>>>>> +		RST_WRITE(reg, val);
> >>>>> 
> >>>>> setbits_le32() please.
> >>>> 
> >>>> Macro setbits_le32() is not available for MIPS architecture.
> >>> 
> >>> You can always add them :)
> >>> 
> >>>> Other, I don't think there is better in being so explicit and using
> >>>> little-endian.
> >>> 
> >>> I believe your register accesses should have correct endianness exactly
> >>> beause mips can be both endian.
> >> 
> >> What is the advantage of using setbits_le32()?
> > 
> > You don't have these constant repeating patterns of:
> > 
> > var = read()
> > var |= BIT
> > write(var)
> > 
> > It makes things a bit less confusing.
> 
> ok, AR9331 use big-endian.

setbits_be32() then, same thing.