From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wills Wang Date: Thu, 21 Jan 2016 10:58:44 +0800 Subject: [U-Boot] [PATCH v7 0/7] add support for atheros ath79 based SOCs In-Reply-To: <201601210232.53143.marex@denx.de> References: <201601210232.53143.marex@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 : >>>> 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? My board work fine when i use DDR or SRAM for stack. > 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. > 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? 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. > 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. > Best regards, > Marek Vasut -- Best Regards Wills