From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wills Wang Date: Thu, 21 Jan 2016 17:31:50 +0800 Subject: [U-Boot] [PATCH v7 0/7] add support for atheros ath79 based SOCs In-Reply-To: <201601210635.40046.marex@denx.de> References: <201601210232.53143.marex@denx.de> <201601210635.40046.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 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 : >>>>>> 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