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

[Marek Vasut]

On Thursday, January 21, 2016 at 10:31:50 AM, Wills Wang wrote:
> 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/hea
> >>>>>>>> ds /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.

Aha , okay. That's unfortunate indeed.

> >>> 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.