New IT forum
31 July 2014, 05:33:49 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: PiHub now in stock.
 
   Home   SHOP Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Un-Bricking the Dream on Linux  (Read 5346 times)
Confusticated
New IT customer
Hero Member
*
Posts: 659


« on: 07 October 2011, 11:17:47 am »

OpenOCD does not yet support the DreamPlug Flash/Bus, so it is not able to flash u-boot.
But u-boot can write to the flash (to save the environment variables) so it can flash itself.
But our DreamPlug is bricked, so we are in a chicken\egg situation - not quite, we can use two eggs!

1) Use OpenOCD to load a non-relocating elf u-boot into ram, run it, and then
1a) Load a flash binary u-boot from local media (FAT formatted USB flashdrive).
1b) Load a flash binary u-boot from the network (tftp)

Or

2) Use OpenOCD to load both non-relocating elf u-boot and a flash binary u-boot.

As we have to use OpenOCD, option 2 seems the most obvious to go with.

Get OpenOCD and u-Boot.

Code:
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
The current version of OpenOCD used here is 0.6.0-dev from the main git repository.

The version of u-Boot is the one originating from GTI
Code:
wget -c http://people.debian.org/~clint/dreamplug/dreamplug-uboot-gti.tar.gz

Build them both, here we assume the repositories are in our current directory
using the directory names 'openocd.git' and 'u-boot-marvell'.
(plenty of tutorials already posted on the www)
 
Edit (create) 'openocd-dreamplug.cfg' with the following contents:
Quote
# Marvell DreamPlug

source [find interface/sheevaplug.cfg]
source [find target/feroceon.cfg]

$_TARGETNAME configure \
        -work-area-phys 0x10000000 \
        -work-area-size 65536 \
        -work-area-backup 0

arm7_9 dcc_downloads enable

proc dreamplug_init { } {

        init

        # We need to assert DBGRQ while holding nSRST down.
        # However DBGACK will be set only when nSRST is released.
        # Furthermore, the JTAG interface doesn't respond at all when
        # the CPU is in the WFI (wait for interrupts) state, so it is
        # possible that initial tap examination failed.  So let's
        # re-examine the target again here when nSRST is asserted which
        # should then succeed.
        jtag_reset 0 1
        feroceon.cpu arp_examine
        halt 0
        jtag_reset 0 0
        wait_halt

        arm mcr 15 0 0 1 0 0x00052078

        mww 0xD0001400 0x43000C30 ;#  DDR SDRAM Configuration Register
        mww 0xD0001404 0x39543000 ;#  Dunit Control Low Register
        mww 0xD0001408 0x22125451 ;#  DDR SDRAM Timing (Low) Register
        mww 0xD000140C 0x00000833 ;#  DDR SDRAM Timing (High) Register
        mww 0xD0001410 0x000000CC ;#  DDR SDRAM Address Control Register
        mww 0xD0001414 0x00000000 ;#  DDR SDRAM Open Pages Control Register
        mww 0xD0001418 0x00000000 ;#  DDR SDRAM Operation Register
        mww 0xD000141C 0x00000C52 ;#  DDR SDRAM Mode Register
        mww 0xD0001420 0x00000042 ;#  DDR SDRAM Extended Mode Register
        mww 0xD0001424 0x0000F17F ;#  Dunit Control High Register
        mww 0xD0001428 0x00085520 ;#  Dunit Control High Register
        mww 0xD000147c 0x00008552 ;#  Dunit Control High Register
        mww 0xD0001504 0x0FFFFFF1 ;#  CS0n Size Register
        mww 0xD0001508 0x10000000 ;#  CS1n Base Register
        mww 0xD000150C 0x0FFFFFF5 ;#  CS1n Size Register
        mww 0xD0001514 0x00000000 ;#  CS2n Size Register
        mww 0xD000151C 0x00000000 ;#  CS3n Size Register
        mww 0xD0001494 0x003C0000 ;#  DDR2 SDRAM ODT Control (Low) Register
        mww 0xD0001498 0x00000000 ;#  DDR2 SDRAM ODT Control (High) REgister
        mww 0xD000149C 0x0000F80F ;#  DDR2 Dunit ODT Control Register
        mww 0xD0001480 0x00000001 ;#  DDR SDRAM Initialization Control Register
        mww 0xD0020204 0x00000000 ;#  Main IRQ Interrupt Mask Register
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "
        mww 0xD0020204 0x00000000 ;#              "

        mww 0xD0010000 0x01111111 ;#  MPP  0 to 7
        mww 0xD0010004 0x11113322 ;#  MPP  8 to 15
        mww 0xD0010008 0x00001111 ;#  MPP 16 to 23

        mww 0xD0010418 0x003E07CF ;#  NAND Read Parameters REgister
        mww 0xD001041C 0x000F0F0F ;#  NAND Write Parameters Register
        mww 0xD0010470 0x01C7D943 ;#  NAND Flash Control Register

}

# load u-Boot into RAM and execute it
proc dreamplug_load_uboot { } {

        dreamplug_init
        load_image ./u-boot-marvell/u-boot
        verify_image ./u-boot-marvell/u-boot
        resume 0x00600000

}

# load both elf\kwb u-Boots into RAM and execute the elf
proc dreamplug_debrick { } {

        dreamplug_init
        load_image ./u-boot-marvell/u-boot
        verify_image ./u-boot-marvell/u-boot
        load_image ./u-boot-marvell/u-boot.kwb 0x01000000
        verify_image ./u-boot-marvell/u-boot.kwb 0x01000000
        resume 0x00600000

}


With the DreamPlug, JTAG\UART Board, PC all connected, start up your preferred console application (minicom\screen).
Stop u-boot countdown to get the prompt, and in another terminal session fire off OpenOCD.

Code:
sudo openocd.git/src/openocd -s "openocd.git/tcl" -f "openocd-dreamplug.cfg"  -c dreamplug-debrick -c exit

Switch back to the DreamPlug serial console, and stop the u-boot countdown.
All we now need do is flash the uboot.kwb image that has been loaded into RAM.

Code:
Marvell>> sf probe 0
SF: Detected MX25L1605D with page size 256, total 2 MiB
2048 KiB MX25L1605D at 0:0 is now current device
Marvell>> sf erase 0x0 0x40000
...........
Marvell>> sf write 0x1000000 0 0x40000
...............
The flashing takes place really fast, blink and you will miss it.

NB: To play safe, use an original DreamPlug u-boot.kwb image from a reliable source (such as New IT), using the compiled elf image to perform the flashing.

As I have a little experience, I chose to work with the source from git://git.denx.de/u-boot-marvell.git which I tweaked a little.

Quote
U-Boot 2011.09-05158-g063adae-dirty (Oct 13 2011 - 13:41:12)
Marvell-DreamPlug

SoC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
WARNING: Caches not enabled
SF: Detected MX25L1605D with page size 64 KiB, total 2 MiB

In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1116 Initialized on egiga0
88E1116 Initialized on egiga1
Hit any key to stop autoboot:  0
Marvell>> ?
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
date    - get/set/reset date & time
dhcp    - boot image via network using DHCP/TFTP protocol
diskboot- boot from IDE device
echo    - echo args to console
editenv - edit environment variable
env     - environment handling commands
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
go      - start application at address 'addr'
help    - print command description/usage
ide     - IDE sub-system
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mtest   - simple RAM read/write test
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
sleep   - delay execution for some time
source  - run script from memory
tftpboot- boot image via network using TFTP protocol
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
Marvell>> version

U-Boot 2011.09-05158-g063adae-dirty (Oct 13 2011 - 13:41:12)
Marvell-DreamPlug
armv5tel-redhat-linux-gnueabi-gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)
GNU ld version 2.17.50.0.18-1.fa1.cross5 20070731
Marvell>>


« Last Edit: 13 October 2011, 06:27:26 pm by Confusticated » Logged

Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!
apemberton
Full Member
***
Posts: 182


« Reply #1 on: 16 October 2011, 08:48:34 am »

Does this mean that you are no longer restricted to booting from a FAT partition on the micro SD card?

It would be interesting to know the u-boot tweaks you made to the DENX original.
Logged

Tony Pemberton
Confusticated
New IT customer
Hero Member
*
Posts: 659


« Reply #2 on: 16 October 2011, 01:09:43 pm »

I currently have a three-way boot with fat\ext filesystem:
eSATA
SD
SDHC
and then DHCP\TFTP, in that order.
I want to make the ordering independent, but am having arguments with the Linux kernel at the moment (different kernels have different ideas Smiley
I also have the above optionally working over netconsole for remote monitoring\management but it has a couple of 'features' I am not yet 100% happy with.
I have one final option to implement in the u-boot variables, the use of scripting, once everything is all ironed out or I can be sure of what the caveats are I will post.
Logged

Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!
kjax
Newbie
*
Posts: 3


« Reply #3 on: 28 January 2012, 01:58:29 am »

Any updates to this?

Thanks.
Logged
Confusticated
New IT customer
Hero Member
*
Posts: 659


« Reply #4 on: 28 January 2012, 06:37:53 pm »

Quote
Any updates to this?
Which procedure would you like updated ?
OpenOCD, U-Boot, & the Kernel have all moved on, the technique remains the same, use u-boot to flash u-boot.
« Last Edit: 28 January 2012, 07:04:03 pm by Confusticated » Logged

Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!
kjax
Newbie
*
Posts: 3


« Reply #5 on: 29 January 2012, 02:21:37 am »

Quote
Any updates to this?
Which procedure would you like updated ?
OpenOCD, U-Boot, & the Kernel have all moved on, the technique remains the same, use u-boot to flash u-boot.
I guess my question was related to your last post:
Quote
I have one final option to implement in the u-boot variables, the use of scripting, once everything is all ironed out or I can be sure of what the caveats are I will post.
I was thinking you might be giving more details on your u-boot environment, and if you had to apply patches, etc. ? I got the impression you might be sharing more of your experience / details of your implementation. I just recently picked up an esata drive, so your multiboot approach is of real interest to me, as I'm not yet fully immersed in u-boot, yet. (Would you believe I thought I was buying "turn-key," more or less, when I bought a couple of dreamplugs? LOL) At any rate, I appreciate what you have shared, already.
Logged
Confusticated
New IT customer
Hero Member
*
Posts: 659


« Reply #6 on: 29 January 2012, 11:48:03 am »

Quote
the use of scripting
NewIT_James has since covered this very nicely http://www.newit.co.uk/forum/index.php/topic,2743.msg7902.html#msg7902
By using a u-boot script on removable media, you can easily change it without concern of messing up the plug.
You can also load and run a (previously saved) script from different flash locations as a backup strategy.

NewIT have also kindly posted the configuration that was derived for the 'Multiboot Dreamplug' http://www.newit.co.uk/forum/index.php/topic,2231.msg6288.html#msg6288
I am sure if you search you will find a guide for booting from eSATA, although you may well be able to figure out how to do it yourself using this configuration as an example.

I still haven't been able to simply & reliably boot any kernel from every device, as changing the kernel\modules changes the order the devices are detected (changing the root filesystem device). It is possible to overcome this issue  by using an initrd\intramfs image and blkid\filesystem labels, if you are ready to take that path, then you don't need guidance from me Smiley
« Last Edit: 29 January 2012, 12:01:36 pm by Confusticated » Logged

Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!