No subject

t 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 wo=
rking device, but I might not have something configured correctly.  If I kn=
ew 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 sho=
uld 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 se=
ems
> I am missing something.
>=20
> 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 thi=
nk) because it turns on the DIAG LED on the device when loaded into DRAM an=
d executed.  But, that does not mean it is not getting stuck somewhere afte=
r the LED turns on...

I guess I need a deeper understanding of what is going on during the boot p=
rocess...
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 ins=
tructions
2. The initial U-Boot bootstrap is loaded
3. This initializes some things such as the UART (for debug), DRAM controll=
er, 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, mayb=
e 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 vario=
us sources to get a complete working build.

In reality though, I would rather just use the existing working U-Boot on t=
he 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 f=
ar.

I have done work with ARM based (SheevaPlug, GuruPlug, DreamPlug) devices b=
efore, and they were easier to work with than this MIPS based device, for o=
ne I could access the flash directly through JTAG (with exception of the Dr=
eamPlug).

I can provide a copy of the working devices boot loader if this helps to fi=
gure out load addresses and such, I am not sure how the file is build, so l=
ooking 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 decompres=
s it until after loading it.

>=20
> > I am going to paste below the contents of the openocd file that I am us=
ing,
> 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 version=
s.
> > 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=3D3
> >         mww 0xb8000008 0x33             ;# set DDR mode value CAS=3D3
> >         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 val=
ue
> (16bit: 0xffff)
> >         mww 0xb800001c 0x7              ;# delay added to the DQS line
> (normal =3D 7)
> >         mww 0xb8000020 7
> >         mww 0xb8000024 7
> >         mww 0xb8000028 7
> > }
>=20
> 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.
>=20
> >
> > # 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
> >
>=20
> 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.
>=20
>=20
> --
> Best regards,
> Daniel

Thanks,
Allan=