-----Original Message----- From: Daniel Schwierzeck [mailto:daniel.schwierzeck@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 drasal@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 andclock_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 Cyclevalue (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