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

[Wills Wang]

On 12/26/2015 02:02 PM, Marek Vasut wrote:
> On Friday, December 25, 2015 at 12:38:39 PM, Wills Wang wrote:
>> On 12/24/2015 11:12 PM, Marek Vasut wrote:
>>> On Thursday, December 24, 2015 at 02:51:06 PM, Wills Wang wrote:
>>>
>>> [...]
>>>
>>>>>> +LEAF(lowlevel_init)
>>>>>> +   /* These three WLAN_RESET will avoid original issue */
>>>>>> +    li      t3, 0x03
>>>>>> +1:
>>>>>> +    li      t0, KSEG1ADDR(AR71XX_RESET_BASE)
>>>>>> +    lw      t1, AR933X_RESET_REG_RESET_MODULE(t0)
>>>>>> +    ori     t1, t1, 0x0800
>>>>>> +    sw      t1, AR933X_RESET_REG_RESET_MODULE(t0)
>>>>>> +    nop
>>>>>> +    lw      t1, AR933X_RESET_REG_RESET_MODULE(t0)
>>>>>> +    li      t2, 0xfffff7ff
>>>>>> +    and     t1, t1, t2
>>>>>> +    sw      t1, AR933X_RESET_REG_RESET_MODULE(t0)
>>>>>> +    nop
>>>>>> +    addi    t3, t3, -1
>>>>>> +    bnez    t3, 1b
>>>>>> +     nop
>>>>> This should be also easy to rewrite into C , right ?
>>>> C runtime environment is not available.
>>>> C stack is not ready before DDR has initialized.
>>> Just point the stack into a locked cacheline or some onchip RAM and there
>>> you have a C runtime. That should be pretty easy :)
>> How to lock cacheline?
> You'd have to check the MIPS core manual, I don't know the details, sorry.
>
>> My guess is that cache memory may be use to map SPI flash at 0x9f000000
>> by ROM code.
> 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.
>>> [...]
>>>
>>>>>> +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.
>
>>>>>> +	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.

> Best regards,
> Marek Vasut
>
>