From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 21 Jan 2016 11:14:30 +0100 Subject: [U-Boot] [PATCH v7 0/7] add support for atheros ath79 based SOCs In-Reply-To: References: <201601210635.40046.marex@denx.de> Message-ID: <201601211114.30148.marex@denx.de> 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 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 : > >>>>>> 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.