[U-Boot] [PATCH v6 00/10] add support for atheros ath79 based SOCs

[Marek Vasut]

On Saturday, January 16, 2016 at 05:08:37 PM, Wills Wang wrote:
> On Saturday, January 16, 2016 11:33 PM, Marek Vasut wrote:
> > On Saturday, January 16, 2016 at 02:15:27 PM, Wills Wang wrote:
> >> On Saturday, January 16, 2016 01:26 PM, Marek Vasut wrote:
> >>> On Monday, January 04, 2016 at 12:06:17 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.
> >>>> 
> >>>> Changes in v6:
> >>>> - Remove useless "else"
> >>>> - Move ar933x as separate patch
> >>>> - Add get_bootstrap in reset.c
> >>>> - Use map_physmem instead of KSEG1ADDR
> >>>> - Add arch_cpu_init for detect SOC type for early
> >>>> - Define magic value in ddr.c
> >>>> - Remove wait loop in putc and getc
> >>>> - Use map_physmem instead of KSEG1ADDR
> >>>> - Add rrw_delay in ath79_spi_priv for more accurate timing
> >>>> - Remove ath79_spi_delay
> >>>> - Calculate delay in ath79_spi_set_speed
> >>>> - Convert SZ_XXX into hex in ap121.h
> >>>> - Remove useless CONFIG_SYS_INIT_SP_OFFSET in ap121.h
> >>>> - Add board_early_init_f for DDR and pin initialization
> >>>> - Select UART and SPI in ap121_defconfig
> >>>> - Add support for qca953x
> >>> 
> >>> I wanted to try this patchset, so I picked [1], since I didn't feel
> >>> like fishing out patches from the list. Especially since this wasn't
> >>> sent as a series, but as separate patches, which makes things
> >>> annoying.
> >>> 
> >>> The [1] does not even compile, which is surprising. I would expect that
> >>> if you submit patches, you would at least compile-test them. Sigh. I
> >>> needed this patch:
> >>> 
> >>> ---8<---
> >>> diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
> >>> index 2952679..140c65c 100644
> >>> --- a/arch/mips/mach-ath79/cpu.c
> >>> +++ b/arch/mips/mach-ath79/cpu.c
> >>> @@ -9,8 +9,8 @@
> >>> 
> >>>    #include <asm/io.h>
> >>>    #include <asm/addrspace.h>
> >>>    #include <asm/types.h>
> >>> 
> >>> -#include <asm/arch/ath79.h>
> >>> -#include <asm/arch/ar71xx_regs.h>
> >>> +#include <mach/ath79.h>
> >>> +#include <mach/ar71xx_regs.h>
> >>> 
> >>>    struct ath79_soc_desc {
> >>>    
> >>>           enum ath79_soc_type soc;
> >>> 
> >>> diff --git a/arch/mips/mach-ath79/reset.c
> >>> b/arch/mips/mach-ath79/reset.c index 410b900..fe32d80 100644
> >>> --- a/arch/mips/mach-ath79/reset.c
> >>> +++ b/arch/mips/mach-ath79/reset.c
> >>> @@ -9,7 +9,7 @@
> >>> 
> >>>    #include <asm/io.h>
> >>>    #include <asm/addrspace.h>
> >>>    #include <asm/types.h>
> >>> 
> >>> -#include <asm/arch/ath79.h>
> >>> +#include <mach/ath79.h>
> >>> 
> >>>    #include <mach/ar71xx_regs.h>
> >>>    
> >>>    void _machine_restart(void)
> >>> 
> >>> --->8---
> >> 
> >> Marek, you can try my repository at
> >> https://github.com/willswang/u-boot-ath79,
> >> I have fixed the compiling issue about headers.
> >> I'm very sorry about this compiling error, my work tree have a residual
> >> symbol
> >> link between arch/mips/include/asm/arch and
> >> arch/mips/mach-ath79/include/mach.
> >> it was not removed when i executed "make clean" to rebuild,  so, my
> >> compiling
> >> didn't discover this problem before this. now i clone this remote branch
> >> into a new
> >> location and find this issue.
> > 
> > You should do git clean -fdx to zap everything before doing the rebuild
> > and repost. This way, you can be sure that you have no residual stuff in
> > your tree.
> > 
> > Also, if make clean doesn't remove objects , there is some other problem
> > which needs attention.
> > 
> >>> Once I managed to fix things, I compiled ap121. I tried booting it on
> >>> arduino yun (ar9331), but it hung in start.S in setup_c0_status . If I
> >>> comment this out, it hangs in lowlevel_init, right at the beginning.
> >>> That's where I gave up.
> > 
> > What about this one? Did you ever boot-test these patches ? I can
> > probably understand why setup_c0_status might hang, but I don't quite
> > understand why would lowlevel_init hang so early.
> 
> Did your board still hang if compiling from my repository?

I don't see any difference in start.S and lowlevel_init.S , so probably yes.