> -----Original Message-----
> From: Daniel Schwierzeck [mailto:daniel.schwierz...@gmail.com]
> Sent: Wednesday, November 28, 2012 9:16 AM
> To: Drassal, Allan
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] U-Boot for MIPS AR7161
>
> Hi Allan,
>
> 2012/11/27 Drassal, Allan <dra...@wsu.edu>:
> > I am attempting to create a U-Boot image for a router, Buffalo
> WZR-HP-AG300H, details can be found here,
> http://wiki.openwrt.org/toh/buffalo/wzr-hp-ag300h.
> >
> > I am having trouble compiling and/or finding a pre-compiled version of
> U-Boot for it.
> >
> > I am attempting to recover a router that has its bootloader erased, I
> have an identical router that is functioning and have debug access through
> JTAG to both devices.
>
> have you tried to dump the MTD partition of U-Boot on the working device?
I have dumped all the partitions from the working device from the linux console
onto a USB memory stick.
>
> > I located one image on the internet 8Muboot_RAM_version.bin, and loaded
> it into ram and executed it, but I don't receive any serial output, but
> it does turn on one LED indicator on the board, indicating that the program
> did execute somewhat. This was built for the AR724x processor though, and
> might be why it is not functioning fully.
>
> Do you know the original text base address of that binary? If you load
> the binary to the wrong address, function calls or relocation will not
> work.
>
The original base address is mapped to flash memory, I believe it is 0xbfc03860.
This is the first address the processor looks to upon startup I believe.
>From my understanding, U-Boot itself contains a short bootstrap as well that
>configures the DRAM controller, and a few other necessary things, copies
>itself into DRAM, then transfers execution to the copy that resides in DRAM to
>continue the next step in U-Boot execution.
I have tried to copy the part in DRAM from the working device to the non
working device, but I might not have something configured correctly. If I knew
what I was looking for, it must be contained in the initial few bytes in the
U-Boot loader, the DRAM configuration, etc. Technically I think I should be
able to execute this directly in DRAM if I know what to copy over.
> >
> > I have attempted to halt the running board in the bootup, copy the ram
> contents from one board to the other, and resume the processor, but it seems
> I am missing something.
>
> maybe there are cache coherency problems or the memory controller is
> not initialized correctly
I think this might be the case, but it executes one loader correctly (I think)
because it turns on the DIAG LED on the device when loaded into DRAM and
executed. But, that does not mean it is not getting stuck somewhere after the
LED turns on...
I guess I need a deeper understanding of what is going on during the boot
process...
Generally I think the following happens, but I might be missing something, or
over simplified something...
1. Processor starts up and looks to a predetermined address for initial
instructions
2. The initial U-Boot bootstrap is loaded
3. This initializes some things such as the UART (for debug), DRAM controller,
etc
4. U-Boot is copied to DRAM then executed from there
5. The main U-Boot is executed and initializes the remaining devices
6. Control is (usually) then transferred to a Linux kernel which is loaded into
DRAM by U-Boot then executed
I am going to attempt to get my toolchain working for building U-Boot, maybe I
just need to build a clean image, however, I can't find support for the AR7161
in the mainline, so I might have to piece together parts from various sources
to get a complete working build.
In reality though, I would rather just use the existing working U-Boot on the
working device to start up the non-working device to be able to rewrite the
bootloader, however, I might need to compile a new U-Boot to get this far.
I have done work with ARM based (SheevaPlug, GuruPlug, DreamPlug) devices
before, and they were easier to work with than this MIPS based device, for one
I could access the flash directly through JTAG (with exception of the
DreamPlug).
I can provide a copy of the working devices boot loader if this helps to figure
out load addresses and such, I am not sure how the file is build, so looking at
the instructions might not make much sense to me. I am assuming it is not
compressed in any way since the processor has no way to decompress it until
after loading it.
>
> > I am going to paste below the contents of the openocd file that I am using,
> along with the initial startup of the working board. I can also provide
> any other details that are helpful.
> >
> > If I can build a working RAM startup image, that would be great, I can
> then use that to rewrite the onboard flash memory, or if I can directly
> access the flash memory through the JTAG, but so far, I have not been
> successful with that either.
> >
> > I believe I have a working toolchain to build U-Boot, but keep running
> into odd errors when building possibly due to different toolchain versions.
> > Any help or assistance would be greatly appreciated.
> >
> > Thanks,
> > Allan Drassal
> >
> > ar71xx.cfg
> >
> > # Atheros AR71xx MIPS 24Kc SoC.
> > # tested on PB44 refererence board
> >
> > adapter_nsrst_delay 100
> > jtag_ntrst_delay 100
> >
> > reset_config trst_and_srst
> >
> > set CHIPNAME ar71xx
> >
> > jtag newtap $CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f
> -expected-id 1
> >
> > set TARGETNAME $CHIPNAME.cpu
> > target create $TARGETNAME mips_m4k -endian big -chain-position
> $TARGETNAME
> >
> > $TARGETNAME configure -event reset-halt-post {
> > #setup PLL to lowest common denominator 300/300/150 setting
> > #mww 0xb8050000 0x000f40a3 ;# reset val + CPU:3 DDR:3 AHB:0
> > #mww 0xb8050000 0x800f40a3 ;# send to PLL
> > mww 0xb8050000 0x40140180 ;# reset val + CPU:3 DDR:3 AHB:0
> > mww 0xb8050000 0xc0140180 ;# send to PLL
> >
> > #next command will reset for PLL changes to take effect
> > mww 0xb8050008 3 ;# set reset_switch and
> clock_switch (resets SoC)
> > }
> >
> > $TARGETNAME configure -event reset-init {
> > #complete pll initialization
> > mww 0xb8050000 0x800f0080 ;# set sw_update bit
> > mww 0xb8050008 0 ;# clear reset_switch bit
> > mww 0xb8050000 0x800f00e8 ;# clr pwrdwn & bypass
> > mww 0xb8050008 1 ;# set clock_switch bit
> > sleep 1 ;# wait for lock
> >
> > # Setup DDR config and flash mapping
> > mww 0xb8000000 0x77b8884e ;# DDR cfg cdl val (rst:
> 0x5bfc8d0)
> > mww 0xb8000004 0x812cd6a8 ;# DDR cfg2 cdl val (rst:
> 0x80d106a8)
> > #mww 0xb8000000 0xefbc8cd0 ;# DDR cfg cdl val (rst:
> 0x5bfc8d0)
> > #mww 0xb8000004 0x8e7156a2 ;# DDR cfg2 cdl val (rst:
> 0x80d106a8)
> >
> > mww 0xb8000010 8 ;# force precharge all banks
> > mww 0xb8000010 1 ;# force EMRS update cycle
> > mww 0xb800000c 0 ;# clr ext. mode register
> > mww 0xb8000010 2 ;# force auto refresh all banks
> > mww 0xb8000010 8 ;# force precharge all banks
> > #mww 0xb8000008 0x31 ;# set DDR mode value CAS=3
> > mww 0xb8000008 0x33 ;# set DDR mode value CAS=3
> > mww 0xb8000010 1 ;# force EMRS update cycle
> > #mww 0xb8000014 0x461b ;# DDR refresh value
> > #mww 0xb8000018 0xffff ;# DDR Read Data This Cycle
> value (16bit: 0xffff)
> > mww 0xb8000014 0x44a6 ;# DDR refresh value
> > mww 0xb8000018 0x00ff ;# DDR Read Data This Cycle value
> (16bit: 0xffff)
> > mww 0xb800001c 0x7 ;# delay added to the DQS line
> (normal = 7)
> > mww 0xb8000020 7
> > mww 0xb8000024 7
> > mww 0xb8000028 7
> > }
>
> are there no registers for enabling/disabling the memory controller?
> Usually you need to disable
> a memory controller when changing its configuration and to enable it
> to start the
> initialization sequence for the DRAM device.
>
> >
> > # setup working area somewhere in RAM
> > $TARGETNAME configure -work-area-phys 0xa0600000 -work-area-size
> 0x20000
> >
> > # serial SPI capable flash
> > # flash bank <driver> <base> <size> <chip_width> <bus_width>
> >
> >
> >
> >
> > commands used in openocd through a telnet connection to 127.0.0.1 4444:
> > reset
> > halt
> > reset
> > mww 0xb8060008 3
> > mww 0xb806000c 0x12c
> > halt
> > mww 0xb8050000 0x00090828
> > mww 0xb8050000 0x00050828
> > mww 0xb8050000 0x00040828
> > mww 0xb8050008 2
> > mww 0xb8050008 3
> > halt
> > reset init
> > load_image 8Muboot_RAM_version.bin 0x80000000
> > resume 0x80000000
> >
>
> are you sure that 0x80000000 is the real text base address? The
> mainline U-Boot code
> uses 0x80000000 + CONFIG_SYS_INIT_SP_OFFSET as initial stack area
> before relocation.
>
>
> --
> Best regards,
> Daniel
Thanks,
Allan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
