Question about u-boot.kwb

Jeff,

I was looking at your mkDockstar.mtd0 script and noticed the following:

make u-boot.kwb

#echo "Creating u-boot.bin.512k padded to 512k"
#dd if=u-boot.bin of=u-boot.bin.512k ibs=512K conv=sync

echo "Removing bad u-boot.kwb"
rm u-boot.kwb

Is it really necessary to build u-boot.kwb if it just gets deleted?

Furthermore, I noticed your uboot.mtd0.patch modifies board/Marvell/sheevaplug/kwbimage.cfg. The only place that references this file is board/Marvell/sheevaplug/config.mk:

KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg

The only place KWD_CONFIG is referenced is in the main Makefile to build u-boot.kwb:

$(obj)u-boot.kwb:       $(obj)u-boot.bin
                $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \
                -a $(TEXT_BASE) -e $(TEXT_BASE) -d $< $@

Since mkDockstar.mtd0 tosses u-boot.kwb, isn't the change uboot.mtd0.patch makes to kwbimage.cfg unnecessary?

I've been digging into this so that I can compile u-boot on the dockstar. Though I don't know why what I produce does not work yet.
However, here is what I have found:

The ultimate goal here is to produce a u-boot.kwb file. In the case of the mkDockstar.mtd0 it ends up deleting it since it is later produced by using doimage and dramregs_pp128_A.txt files. So instead of doing a make u-boot.kwb it could have been a make u-boot.bin.

If the file board/Marvell/sheevaplug/kwbimage.cfg is setup correctly then make u-boot.kwb will work. I went ahead and matched it up with the values from dramregs_pp128_A.txt and it now produces a file with the correct header just like the doimage does.

So with kwbimage.cfg file setup correctly you can then just do the following:
(don't need the sed command as the file board/Marvell/sheevaplug/config.mk already has TEXT_BASE as 0x00600000)
make mrproper (cleanup files)
make sheevaplug_config (configure u-boot)
make u-boot.kwb (make u-boot)
dd if=u-boot.kwb of=uboot.mtd0.kwb ibs=512K conv=sync (pad it to 512K)


Here's the diff against the patched version for board/Marvell/sheevaplug/kwbimage.cfg
137,138c137,138
< DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0
< DATA 0xFFD01504 0x0FFFFFF1 # CS[0]n Size
---
> #DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0
> DATA 0xFFD01504 0x07FFFFF1 # CS[0]n Size
144a145
> DATA 0xFFD01508 0x10000000 # CS[1]n Base address to 256Mb
145a147
>


Here's the diff against the original git version for board/Marvell/sheevaplug/kwbimage.cfg
77c77
< DATA 0xFFD01410 0x000000cc # DDR Address Control
---
> DATA 0xFFD01410 0x0000000d # DDR Address Control
137,138c137,138
< DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0
< DATA 0xFFD01504 0x0FFFFFF1 # CS[0]n Size
---
> #DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0
> DATA 0xFFD01504 0x07FFFFF1 # CS[0]n Size
146c146
< DATA 0xFFD0150C 0x0FFFFFF5 # CS[1]n Size 256Mb Window enabled for CS1
---
> DATA 0xFFD0150C 0x00000000 # CS[1]n Size, window disabled

ygator Wrote:
-------------------------------------------------------
> I've been digging into this so that I can compile u-boot on the dockstar. Though I don't know why
> what I produce does not work yet.

If you want to compare, I submitted a set of patches against the current (v2010.06) u-boot sources to support the DockStar. They didn't get accepted, but it looks like there's hope. BTW, the LED support in this version is hard-wired, not configurable via environment variables like Jeff's version.

With these patches applied, I use the following script to build an image for chainloading or flashing:

#!/bin/sh -e

usage() {
    echo "Usage: $0 [-d]"
    exit 1
}

case $# in
    0) allow_dirty= ;;
    1) if [ "_$1" = "_-d" ]; then allow_dirty=true; else usage; fi ;;
    *) usage ;;
esac

if tools/setlocalversion | grep dirty; then
    if [ "$allow_dirty" ]; then
	echo Warning: building dirty version as requested.
    else
	echo Please commit changes first.
	exit 1
    fi
fi
export CROSS_COMPILE=arm-linux-gnueabi-
git tag -f last-built
make mrproper
make dockstar_config
make u-boot.kwb
perl -e 'for ($i=0;$i<512;$i++){printf("\xFF" x 1024)}' > /tmp/ff.512k
cat u-boot.bin /tmp/ff.512k | dd of=u-boot.bin.512k bs=1 count=512k
cat u-boot.kwb /tmp/ff.512k | dd of=u-boot.kwb.512k bs=1 count=512k

There were only a couple small differences that I saw and went with what you had, but it still does not work.

ygator Wrote:
-------------------------------------------------------
> There were only a couple small differences that I saw and went with what you had, but it still does
> not work.

Are you padding the images with 00 bytes or FF bytes? I had some problems until I padded with FF.
Please post what happens when you try to run it.

I have Jeff's u-boot already installed. So I let it boot into the clound engine u-boot and loaded my u-boot from there.
Here is what I get now padded with FF.

Filename 'u-boot.kwb.512k'.
Load address: 0x800000
Loading: #################################################################
######################################
done
Bytes transferred = 524288 (80000 hex)
CE>> go 0x800200
## Starting application at 0x00800200 ...


%

SoC: Kirkwood %
DRAM: % %sNAND:
Filename '%s'. Size is 0x%

@ecc

What is the allow_dirty all about?

I noticed in my build u-boot it shows U-Boot 2010.09-rc1-00010-ga12555c-dirty

ygator Wrote:
-------------------------------------------------------
> What is the allow_dirty all about?
>
> I noticed in my build u-boot it shows U-Boot 2010.09-rc1-00010-ga12555c-dirty

The local version string is automatically generated by the tools/setlocalversion script. If you're in a git tree with uncommitted changes, it will append "-dirty" to the string. This was probably taken from similar logic in the Linux kernel build system. The "git tag" command prevents the version string from having that hex commit ID in it.

@ecc

The machine type for the dockstar was added to u-boot 6 hours ago.

ygator Wrote:
-------------------------------------------------------
> The machine type for the dockstar was added to u-boot 6 hours ago.

Cool. I'm currently hung up on making my patches work with the new ARM relocation stuff that's been pulled into the upcoming (2010.09) release. I just don't know enough about the low-level hardware to know how to adapt it. So I'm waiting for the "real" SheevaPlug maintainers to adapt their code, then it should be trivial to copy.