dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5666
share rss forum feed

yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

[General] Build your u-boot for Dockstar

The following link has instructions for building mtd0 and mtd3 u-boot:

»jeff.doozan.com/debian/uboot/build_uboot.htm

I had down loaded and built tool chain and were able to build mtd3 u-boot.

I'm trying to build mtd0 u-boot and having some source/patch mismatch problems.


mazilo
From Mazilo
Premium
join:2002-05-30
Lilburn, GA
kudos:4

As I mentioned to you through a PM to you that I would like to take Jeff's parameters to the OpenWRT u-boot configuration and use OpenWRT to build the u-boot. IIRC, you have a JTAG cable for your DockStar that you can use to recover the unit from brick. If so and you don't mind to try the above approach, I sure will appreciate that.
--
don't and stop are the ONLY two 4-letter words considered offensive to men, but not when used together.


yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

3 edits

Using Dockstar and OpenWrt to build u-boot is an interesting idea, I'm sure you'll have many hours' fun.

I do have JTAG to recover from mtd0 uboot problem. I can test any uboot by loading to SDRAM first.

Please note Jeff's patches seem outdated. e.g., the patch for \tools\env\makefile will produce error for sources from "git".

In old makefile, there is CFLAG while in new makefile it's replace by HOSTCFLAG.

From now on, I'll keep a copy of the source after "git" .

Some of the feature I'd like to have:

(1). Adding time out for tftpboot. To boot OpenWrt or other Linux from network, tftpboot should timeout if network boot fails.

(2). Adding pogo compatible 4 bit ECC for envs.

(3). Adding complete set of default envs (except MAC and SN) for recovery when envs are corrupted.

(4) others.

I found Jeff's patches were for 06.2010 uboot release, there were many changes for 09.2010 uboot release, the choice would be to roll back uboot source to 06.2010 release or to update patches for 09.2010 release.


yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

4 edits
reply to yahoo2003

downloaddownload_ins···y.sh.zip 1,832 bytesdownloaddoimage.c.zip 7,808 bytesdownloadbootstrap_os.h.zip 5,122 bytes
downloadbootstrap_def.h.zip 2,226 bytes  
I was able to download old uboot source and build mtd0 and mtd3 boot loaders, the steps are:
(1). As root, run "download_install_codesourcery.sh" script to dowload "arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2"(81 MB) and install tool chain.
If "arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2" has been downloaded before, run "install_codesourcery.sh" script.

(2). As user, download 2010-06-29 uboot source tarball (in one line):
»git.denx.de/cgi-bin/gitweb.cgi?p···7;sf=tgz

(3). Extract tarball in u-boot folder:
gzip -dc u-boot-a59e27997637a2395ae2cc7f809127f24119a167.tar.gz | tar xf -
 

(4). change to "u-boot" folder:
cd u-boot
 

(5). Download the following files for mtd0 uboot:
wget http://jeff.doozan.com/debian/uboot/dramregs_pp128_A.txt
wget http://jeff.doozan.com/debian/uboot/uboot.mtd0.patch
wget http://jeff.doozan.com/debian/uboot/mkDockstar.mtd0
 
or the following files for mtd3 uboot:
wget http://jeff.doozan.com/debian/uboot/uboot.mtd3.patch
wget http://jeff.doozan.com/debian/uboot/mkDockstar.mtd3
 
(6). Patch source code for mtd0 uboot:
patch -p1  < uboot.mtd0.patch
 
# or for mtd3 uboot:
patch -p1  < uboot.mtd3.patch
 

(7). For mtd0 uboot, save "doimage.c" "bootstrap_def.h" "bootstrap_os.h" to u-boot folder, build "doimage" and make it executable:
gcc doimage.c bootstrap_def.h bootstrap_os.h -o doimage
chmod +x doimage
 

(8). Switch to the cross compiler environment codesourcery-arm-2009q3.sh
codesourcery-arm-2009q3.sh
 

(9). Run mkDockstar.mtd0 for mtd0 uboot:
chmod +x mkDockstar.mtd0
./mkDockstar.mtd0
 
or for mtd3 ubbot:
chmod +x mkDockstar.mtd3
./mkDockstar.mtd3
 

(10). Exit from cross compiler environment:
exit 
 

##To test mtd3 uboot from uboot consule:

tftpboot 0x800000 uboot.mtd3.bin
go 0x800000
 

##To test mtd0 uboot from uboot consule:

tftpboot 0x800000 uboot.mtd0.kwb
go 0x800200
 

I have tested mtd3 uboot successfully, the mtd0 uboot however failed to boot.

mazilo
From Mazilo
Premium
join:2002-05-30
Lilburn, GA
kudos:4

Thanks for the attachments.

said by yahoo2003:

(6). Patch source code for mtd0 uboot:
patch -p1 uboot.mtd0.patch
# or for mtd3 uboot:
patch -p1 uboot.mtd3.patch
You may want to enclose the above with code block so that it will show the redirection (less) sign in the patch lines.
--
don't and stop are the ONLY two 4-letter words considered offensive to men, but not when used together.

yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

1 edit

said by mazilo:

You may want to enclose the above with code block so that it will show the redirection (less) sign in the patch lines.
I could not figure out how to do it.
Thanks

BTW, someone did use Dockstar to build Jeff's uboot:
»forum.doozan.com/read.php?3,808

He had the same problem of testing mtd0 uboot from SDRAM even the uboot worked after flashed to NAND.

yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

1 recommendation

reply to yahoo2003

Finally I was able to build mtd0 uboot, tested it on SDRAM and flashed it to NAND.

In Jeff's patch and mkDockstar.mtd0, he set:

TEXT_BASE = 0x00600000

Alexander Holler and Jeff's 2nd stage uboot has:

TEXT_BASE = 0x00c00000

I changed TEXT_BASE to 0x00c00000 and it worked. Modified mkDockstar.mtd0 is attached.

Warning: The following may brick your Dockstar!!!
I used the following to replace mtd0 uboot:
tftpboot 0x800000 uboot.mtd0.kwb
nand erase 0x0 0x80000
nand write.e 0x800000 0x0 0x80000

After power cycle I Got:
 
U-Boot 2010.06 (Oct 15 2010 - 17:28:06)
Marvell-Dockstar by Yahoo2003
 
SoC:   Kirkwood 88F6281_A0
DRAM:  128 MiB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  3  2  1  0 
Using egiga0 device
host 192.168.15.100 is alive
Using egiga0 device
TFTP from server 192.168.15.100; our IP address is 192.168.15.105
Filename 'openwrt-kirkwood-uImage'.
Load address: 0x800000
Loading: *#################################################################
 ###############################################
done
Bytes transferred = 1642752 (191100 hex)
Using egiga0 device
TFTP from server 192.168.15.100; our IP address is 192.168.15.105
Filename 'openwrt-kirkwood-rootfs.tar.gz'.
Load address: 0x1000000
Loading: *#################################################################
 #########
done
Bytes transferred = 1076652 (106dac hex)
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.30.10
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1642688 Bytes = 1.6 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
 
Starting kernel ...
 
Uncompressing Linux... done, booting the kernel.
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 528 bytes
NET: Registered protocol family 16
Kirkwood: MV88F6281-A0, TCLK=200000000.
Feroceon L2: Cache support initialised.
Kirkwood: Gating clock using mask 0x1ac224
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
 
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 926 at 0x0000073c0000
Bad eraseblock 1894 at 0x00000ecc0000
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000010000000 : "rootfs"
rtc-mv rtc-mv: internal RTC not ticking
i2c /dev entries driver
cpuidle: using governor ladder
mmc0: mvsdio driver initialized, lacking card detect (fall back to polling)
TCP westwood registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing init memory: 2344K
- preinit -
Press the [f] key and hit [enter] to enter failsafe mode
- regular preinit -
- init -
 
Please press Enter to activate this console. device eth0 entered promiscuous mode
PPP generic driver version 2.4.2
ip_tables: (C) 2000-2006 Netfilter Core Team
NET: Registered protocol family 24
nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
eth0: link up, 100 Mb/s, full duplex, flow control disabled
br-lan: port 1(eth0) entering forwarding state
 
BusyBox v1.15.3 (2010-09-26 19:49:09 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
 
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 Backfire (10.03, r23115) --------------------------
  * 1/3 shot Kahlua    In a shot glass, layer Kahlua 
  * 1/3 shot Bailey's  on the bottom, then Bailey's, 
  * 1/3 shot Vodka     then Vodka.
 ---------------------------------------------------
root@OpenWrt:/# 
 


sdmatto

@comcast.net
reply to yahoo2003

Were you able to build in the features that you recited above:

"(1). Adding time out for tftpboot. To boot OpenWrt or other Linux from network, tftpboot should timeout if network boot fails.

(2). Adding pogo compatible 4 bit ECC for envs.

(3). Adding complete set of default envs (except MAC and SN) for recovery when envs are corrupted.

(4) others."

If so, care to tell how? I am especially interested in items 2-3 above.

Thanks.


yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo
reply to yahoo2003

Update:

Although I was able to flash mtd0 uboot with TEXT_BASE 0xc00000 and 0x600000, I found when "TEXT_BASE" of mtd0 uboot was 0x600000, uboot was only relocated to 0x600000, when "TEXT_BASE" of mtd0 uboot was 0xc00000, uboot was relocated to 0x600000 and 0xc00000.

I believe mtd0 uboot with TEXT_BASE 0x600000 can't be loaded to SDRAM and run from SDRAM by another mtd0 uboot because they are relocated to the same SDRAM address 0x600000. To test mtd0 uboot in SDRAM, it should be loaded using Jtag or from a mtd3 uboot with different relocate address (0xc00000).


yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo
reply to sdmatto

said by sdmatto :

Were you able to build in the features that you recited above:

"(1). Adding time out for tftpboot. To boot OpenWrt or other Linux from network, tftpboot should timeout if network boot fails.

(2). Adding pogo compatible 4 bit ECC for envs.

(3). Adding complete set of default envs (except MAC and SN) for recovery when envs are corrupted.

(4) others."

If so, care to tell how? I am especially interested in items 2-3 above.

Thanks.
I was struggling to figure out relocation of uboot and will test tftpboot time out.

Dogface05 has implemented (2) by reverse engineering.

Pogo open source may have some information about ENV tools but I did not have time to study them.


DogFace05

join:2005-12-09
Cary, NC
kudos:154

1 edit

1 recommendation

I've actually implemented 1), 2) and 3), and then some. Don't know about 4), as I don't know what specific features are meant by "others". My firmware is based on the 09.2010 release with some other code, and built with TEXT_BASE set to 0x00600000. It can be run as either an mtd0 or secondary bootloader (technically actually a tertiary).

I almost did pull my hair out with the issue of loading it as a secondary into a different memory location, but got the problem figured out and resolved. It's a cache synchronization problem. The data and instruction caches in the ARM processor don't coordinate with one another (or don't do so reliably), so when executing the image at a different address, which causes it to relocate itself to 0x00600000, the relocation is done within view of the data cache, but not the instruction cache, which happily executes some stale instructions from any other U-Boot that happened to be located at the destination before the relocation.

Which instructions are taken from stale cached code is very hard to predict. Simply rearranging the order of linked-in modules, with no other functional differences whatsoever in the code, would mean the difference between the code executing fine, or crashing without any apparent rational reason why.

An interesting tidbit, is that the mtd0 bootloader is actually a secondary bootloader. The primary resides in a built-in masked ROM within the Marvell 88F6281 chip. That bootloader has a monitor, which can be broken into through the serial port, that supports uploading code images into RAM. In essence, it makes J-Tag totally unnecessary, as one can happily screw up an mtd0 bootloader, and still recover using just the serial port.


mazilo
From Mazilo
Premium
join:2002-05-30
Lilburn, GA
kudos:4

said by DogFace05:

An interesting tidbit, is that the mtd0 bootloader is actually a secondary bootloader. The primary resides in a built-in masked ROM within the Marvell 88F6281 chip. That bootloader has a monitor, which can be broken into through the serial port, that supports uploading code images into RAM. In essence, it makes J-Tag totally unnecessary, as one can happily screw up an mtd0 bootloader, and still recover using just the serial port.
Indeed this is interesting.

Does the built-in masked ROM support flashing a bootloader to any mtd partition? If so, can you tell us how to do this? This way, anyone who can access to the serial-console port doesn't have to worry about bricking their DockStar and can easily and quickly recover it (without a JTAG cable) shall the procedure to upgrade the u-boot on mtd0 goes awry.
--
don't and stop are the ONLY two 4-letter words considered offensive to men, but not when used together.

yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

1 edit
reply to DogFace05

said by DogFace05:

An interesting tidbit, is that the mtd0 bootloader is actually a secondary bootloader. The primary resides in a built-in masked ROM within the Marvell 88F6281 chip. That bootloader has a monitor, which can be broken into through the serial port, that supports uploading code images into RAM. In essence, it makes J-Tag totally unnecessary, as one can happily screw up an mtd0 bootloader, and still recover using just the serial port.
That's an interesting idea.
From »www.marvell.com/products/process···urce.pdf

24.2.6.1 Boot from UART0
As previously indicated, boot from UART0 is not a sample at reset configuration option, but is
performed before every type of boot through sensing the Rx side of the UART0 interface on both
MPP options.
If the debug pattern (0xDD 0x11 0x22 0x33 0x44 0x55 0x66 0x77) was received, the bootROM
enters the command line debug mode. Otherwise, if the boot sequence (0xBB 0x11 0x22 0x33 0x44
0x55 0x66 0x77) was received, the bootROM enters the Boot from UART routine, which starts
receiving the boot image using the Xmodem protocol (i.e., it starts receiving chunks of 128 bytes,
each with an 8-bit checksum).
The boot image must be a continuous image, which includes a main header and an extension
header (extended header is mandatory in this case, since the DDR must be initialized).
The main header, extension header, and source image must contain valid checksum values.
According to the boot sequence described above, this boot method:
1. Executes the registers configuration in the extended header.
2. Downloads the source image to DDR.
3. Executes it in the DDR


brg

join:2001-01-03
Chicago, IL
kudos:1

You guys make my head hurt. And all I wanted was a relatively turn-key hack to enable my Dockstar to load-up a Linux distro upon which I could install Asterisk and then FreePBX.


yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

said by brg:

You guys make my head hurt. And all I wanted was a relatively turn-key hack to enable my Dockstar to load-up a Linux distro upon which I could install Asterisk and then FreePBX.
If you don't mind to use external drive, I believe that was done by many people. To install on internal flash might be tricky (some people said FreePBX won't fit).

Personally I prefer network install.


brg

join:2001-01-03
Chicago, IL
kudos:1

said by yahoo2003:

said by brg:

You guys make my head hurt. And all I wanted was a relatively turn-key hack to enable my Dockstar to load-up a Linux distro upon which I could install Asterisk and then FreePBX.
If you don't mind to use external drive, I believe that was done by many people. To install on internal flash might be tricky (some people said FreePBX won't fit).

Personally I prefer network install.
For my limited, hobby use -- at least to start -- I'm fine with the external drive approach, and also fine with the double-boot flim-flammery that I understand is inherent in that process. So thanks for that. I guess all the esoteric stuff has been about getting the code on the internal flash of the Dockstar...

mazilo
From Mazilo
Premium
join:2002-05-30
Lilburn, GA
kudos:4
reply to brg

said by brg:

You guys make my head hurt.
Don't worry because this hurts my head, too.
--
don't and stop are the ONLY two 4-letter words considered offensive to men, but not when used together.

yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

3 edits
reply to brg

said by brg:

I guess all the esoteric stuff has been about getting the code on the internal flash of the Dockstar...
One stage uboot has some advantages of saving SDRAM.
Dockstar has the least SDRAM (128MB) compared with other plug computers and people are trying to put more and more applications.

I'm trying to figure out how SDRAMs are used:

(1). 0x0~0x800000 for uboot, Starting 0x600000: first stage uboot.
(2). Starting 0xC00000: 2nd stage uboot, range unkown.
(3). Starting 0x800000: may be used for uImage.
(4). rootfs may be relocated to higher SDRAm adress.

One stage boot loader may save some SDRAMs.


sdmatto

@comcast.net
reply to DogFace05

said by DogFace05:

I've actually implemented 1), 2) and 3), and then some. Don't know about 4), as I don't know what specific features are meant by "others". My firmware is based on the 09.2010 release with some other code, and built with TEXT_BASE set to 0x00600000. It can be run as either an mtd0 or secondary bootloader (technically actually a terciary).
DogFace05 - Will you make your UBoot firmware (or tutorial outlining steps to make my own) available? It would be nice to resolve the 4-bit ECC Uboot issue that has kept me from doing a lot with NAND or network boot. Thanks for letting us know.

yahoo2003

join:2007-11-02
Mclean, VA
Reviews:
·callwithus
·Anveo

1 recommendation

reply to yahoo2003

I figured out no firmware mod is needed to change tftpboot from default retry forever to limited timeout.

To change retry to once:

setenv netretry once
 

To change time out from 50 seconds to 10 seconds:

setenv tftptimeout 1000
 

The above envs are used in "net.c" and "tftp.c".

After the changes, if net boot fails, uboot will run the next boot command.
Using egiga0 device
TFTP from server 192.168.15.100; our IP address is 192.168.15.105
Filename 'openwrt-kirkwood-uImage'.
Load address: 0x800000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-2.6.22.18
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1978544 Bytes = 1.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
 
Starting kernel ...
 
Uncompressing Linux..
 


DogFace05

join:2005-12-09
Cary, NC
kudos:154
reply to mazilo

said by mazilo:

Indeed this is interesting.

Does the built-in masked ROM support flashing a bootloader to any mtd partition? If so, can you tell us how to do this? This way, anyone who can access to the serial-console port doesn't have to worry about bricking their DockStar and can easily and quickly recover it (without a JTAG cable) shall the procedure to upgrade the u-boot on mtd0 goes awry.
I didn't say anything about it supporting flashing, nor does the spec from Marvell make any mention of such support. Being that the size of the masked ROM and the bootstrap loader in it are limited, with the latter's purpose being simply to kick-start the system (and provide some way of recovery when the main boot loader is absent or faulty), I doubt very much that it would include means for flashing anything. What the documentation says, is only that it supports loading code over the serial port into DRAM, and executing it from there. That's all that is really necessary. Once a full featured boot loader is loaded into DRAM and executed, that boot loader can in turn do anything it wants, including flashing whatever is wanted into any partition of one's liking.

Note that partitions are only arbitrary logical subdivisions of locations in the flash. The flash chip itself is not aware of, and does not know of partitions.

All that said, it seems one cannot always believe what's said in the official specs. One can indeed send the pattern specified in the spec to the adapter, on power up, and it will stop the boot-up process in its tracks. However, as it turns out, the device just freezes. In fact, sending any pattern at any bit rate, seems to yield the same result--freezing.

So it looks like production versions of the Kirkwood chip (vs those in the evaluation/development boards) may have a different, scaled down version of the boot-ROM loader, or one that uses some other protocol(s) not disclosed in the spec.


DogFace05

join:2005-12-09
Cary, NC
kudos:154
reply to yahoo2003

said by yahoo2003:

One stage uboot has some advantages of saving SDRAM.
Dockstar has the least SDRAM (128MB) compared with other plug computers and people are trying to put more and more applications.

I'm trying to figure out how SDRAMs are used:

(1). 0x0~0x800000 for uboot, Starting 0x600000: first stage uboot.
(2). Starting 0xC00000: 2nd stage uboot, range unkown.
(3). Starting 0x800000: may be used for uImage.
(4). rootfs may be relocated to higher SDRAm adress.

One stage boot loader may save some SDRAMs.

A properly made single stage U-Boot has certain advantages, mostly related to minimizing wear and tear on the on-board NAND flash and thus extending its life expectancy. Saving RAM is not one of the advantages. The loaded kernel reclaims all RAM memory anyway, so which stage U-Boot is used for loading it or where that loader is located in memory, is entirely irrelevant.

Although the DockStar's kernel uImage is normally loaded at 0x800000, the first thing it does when executed, is relocate (and if a compressed image, decompress) itself down to address 0x8000, where execution resumes.