[U-Boot] [PATCH v7 0/7] add support for atheros ath79 based SOCs

[Wills Wang]

On Thursday, January 21, 2016 01:35 PM, Marek Vasut wrote:
> On Thursday, January 21, 2016 at 03:58:44 AM, Wills Wang wrote:
>> On Thursday, January 21, 2016 09:32 AM, Marek Vasut wrote:
>>> On Sunday, January 17, 2016 at 01:21:29 PM, Wills Wang wrote:
>>>> On 01/17/2016 06:24 PM, Daniel Schwierzeck wrote:
>>>>> 2016-01-17 6:49 GMT+01:00 Wills Wang <wills.wang at live.com>:
>>>>>> On 01/17/2016 03:05 AM, Marek Vasut wrote:
>>>>>>> On Saturday, January 16, 2016 at 07:13:46 PM, Wills Wang wrote:
>>>>>>>> These series of patch add support for atheros ath79 based SOCs in
>>>>>>>> u-boot, at the present moment it's just available for ar933x and
>>>>>>>> qca953x chip.
>>>>>>>>
>>>>>>>> This patch serises is based on mips_io_v4 branch on u-boot-mips
>>>>>>>> repository
>>>>>>>> [1] and tested on ar933x and qca953x board.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> http://git.denx.de/?p=u-boot/u-boot-mips.git;a=shortlog;h=refs/heads
>>>>>>>> /m ips_ io_v4
>>>>>>> So if I didn't complain about this being sent as separate emails this
>>>>>>> morning.
>>>>>>> Please, do send your patches as a series, not as separate emails.
>>>>>> How to send a patch series by patman?
>>>>> If your git-sendmail config is correctly set up, patman automatically
>>>>> sends the cover letter and then all patches as response to that cover
>>>>> letter.
>>>>>
>>>>> You have to enable mail threading in git-sendmail. Check that with:
>>>>>
>>>>> $ git config --get sendemail.thread
>>>>>
>>>>> To enable it globally:
>>>>>
>>>>> $ git config --global sendemail.thread true
>>>> Thanks, i will try it for the coming v8.
>>> I got as far as booting my ar9330 rev 1 machine, though it did take
>>> considerably amount of hackery. I also had to use locked cachelines for
>>> stack, because it is far faster than using the SRAM on ar9331 . You can
>>> find my hacks in the attachment, most of the stuff there is because
>>> arduino yun is repugnant crappy piece of hardware and needs some extra
>>> treatment.
>> My board is also ar9330 rev 1, but i can boot well without any change for
>> start.s and cache, is it possible about hardware?
> No clue.
>
>> My board work fine when i use DDR or SRAM for stack.
> I remember you weren't able to boot if you used SRAM for stack.
> Did something change ?
What i mean is that my board can't boot if drop the whole lowlevel_init.S
when use SRAM for stack. we need lowlevel_init.S to handle RTC, PLL and
some chip issues.

>>> You should mostly care about the hacks in start.S , in particular the one
>>> setting bit 3 in CP0 in setup_c0_status seems important on mips 24kc
>>> core. Daniel seems to have some ideas on this too I think, he helped me
>>> finding out there's a problem.
>>>
>>> Also, mips_cache_lock_24k does the job for locking the cachelines, but
>>> (!) it is clearly a dirty hack. The start.S needs to be modularized in
>>> some way for this to be properly integrat(ed|able).
>>>
>>> In case I select SYS_MIPS_CACHE_INIT_RAM_LOAD , the machine hangs. No
>>> idea why, but I suspect it makes no sense on a machine which has no
>>> running DRAM anyway, so I removed this option.
>> My hardware can work no matter if i select SYS_MIPS_CACHE_INIT_RAM_LOAD.
>> I doubt whether there are same exceptions for your memory subsystem, or
>> some DDR parameters are not for your DDR chip.
> DDR is not started at the point where INIT_RAM_LOAD comes into play, so
> it has nothing to do with it. Instead, refilling the cache from DDR makes
> no sense if DDR is not running, therefore this should be disabled to make
> sure we don't run into problems.
>
>>> Change to ddr.c seems correct, the values for DDR1 and DDR2 were swapped,
>>> but I suggest you double-check it.
>> Did your board use DDR1?
> DDR2
>
>> I check the original u-boot code again, this value 0xa33 is for DDR2,
>> 0x33 for DDR1. The 0 value for WR filed in DDR2 MRS is reserved.
> That's correct, so I suspect there's something swapped somewhere, since my
> register ends up configured with 0x33 and not 0xa33 . That's why I hacked
> this change for now.
>
>>> Ignore my AHB hack in lowlevel_init.S , it's necessary to keep my SPI NOR
>>> running at low speed, since I am using an FPGA instead of real SPI NOR
>>> and the FPGA implementation of the SPI NOR emulator cannot run at tens
>>> of MHz.
>>>
>>> I am now looking into implementing ethernet and USB support for ar9331,
>>> did you look into it at all or not ? I'd like to avoid duplicating
>>> efforts.
>> At present, i have no plan to involve ethernet and USB, i want to work
>> done first for this patch.
> OK, I am looking into the ethernet part now, no luck so far. I cannot even
> read the PHY ID yet, probably missing some register bit somewhere.

-- 
Best Regards
Wills