Beagle U-Boot (v1) patch upstream sending

After being again some days offline (yes, I'm still alive) I quickly scanned the IRC logs (some interruption?) and saw that I missed some discussion about uboot v1 patches upstream sending.

http://www.beagleboard.org/irclogs/index.php?date=2008-05-30#T22:16:32

Don't forget me :wink:

I'd be really happy to help to bring uboot v1 patches upstream as I already helped with DaVinci uboot support.

Step 1: First, I think we need a patch again recent uboot v1 that works for all of us. For this first step, I think the format (code and file organization) doesn't matter. Just let us get the technical stuff working (*).

Step 2: Then, the next step would be to reorganize the file/directory organization, clean up the code and create a set < 40k patches from the first step patch.

Step 1 & 2 can be done on this list. If we think that the result of step 2 is ready we can send it to uboot list. Then, the usual re-do cycles start, everybody can help. Most probably, it will become harder than with omap-linux patches :wink:

I think we need to agree that we couldn't get anything what is currently in the uboot patches upstream. E.g. I think our chance for upstream will be better if we omit logo and audio output and try to bring "nice to have features" upstream in some later steps.

Opinions?

Dirk

Btw: Steve: Does

http://www.beagleboard.org/irclogs/index.php?date=2008-05-30#T14:02:29

mean that recent uboot v1 git

+ uboot beagle patches
+ 500MHz patch
+ don't disable L2 cache for kernel patch
+ logo and audio *disabled*

  works stable for you? Have to try this, maybe if we disable audio the I2C issues I saw are gone...

(*) I would have started with upstream preparing already if I hadn't these I2C issues, i.e. if I had some stable uboot git patches.

Dirk,

I agree with your outline of general strategy!

re: v1 patches: I started with those patches, and made quite a few
other changes. The only known issue is that mmcinit causes a silent
crash. Otherwise pretty much everything I tried worked.

I can set up a public git of my changes a bit later today. I broke
things this morning trying to re-architect the cpu directory
structure, but should be able to fix things relatively quickly. I
could also generate a consolidated patch off of mainline u-boot git.

Steve

I got latest u-boot GIT to boot on Beagle with 1.3.2 patches. There is lot of cleanup required, I will get you some initial stuff by evening today.

I think a GIT tree maintained by Sakoman is better, we can consolidate our patches and review before pushing the same to community.

I will remove Logo, Audio and add 500Mhz, NAND support + Bad block managemnet to this

As Nishanth Menon was suggesting, we should try to use same code base for X-loader too, it only needs proper coding to disable the code that is not required, it will help us to maintain a single code base.

Regards,
Khasim

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/test

regards,

Koen

:slight_smile: I will wait for this version to complete before giving code for NAND bad block management.

Is it possible for me to pull this GIT tree over HTTP?

Regards,
Khasim

koen wrote:

Dirk,

I agree with your outline of general strategy!

re: v1 patches: I started with those patches, and made quite a few
other changes. The only known issue is that mmcinit causes a silent
crash. Otherwise pretty much everything I tried worked.

I can set up a public git of my changes a bit later today.

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/test

I tried Steve's consolidated patch.

It basically works!

Steve: Do you mind to send the patch to the list? From my point of view the first step #1 I mentioned is done with this :slight_smile:

Unfortunately, I still get some I2C error messages. Nobody else see these? See log below.

Thanks

Dirk

-- cut --
...40T..

Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector

135372 Bytes Read from MMC
Starting OS Bootloader from MMC...

U-Boot 1.3.3-00030-g1f15548-dirty (Jun 3 2008 - 16:46:59)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
DRAM: 128 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
timed out in wait_for_bb: I2C_STAT=1000
timed out in wait_for_pin: I2C_STAT=1000
I2C read: I/O error
timed out in wait_for_bb: I2C_STAT=1000
Hit any key to stop autoboot: 0
OMAP3 beagleboard.org # mmcinit
timed out in wait_for_bb: I2C_STAT=1000
timed out in wait_for_pin: I2C_STAT=1000
I2C read: I/O error
OMAP3 beagleboard.org # fatload mmc 0:1 0x80000000 uimage
reading uimage

2706788 bytes read
OMAP3 beagleboard.org # bootm
## Booting kernel from Legacy Image at 80000000 ...
    Image Name: Linux-2.6.26-rc2-omap1-04592-gfe
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2706724 Bytes = 2.6 MB
    Load Address: 80008000
    Entry Point: 80008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
OK

Starting kernel ...
...
Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz
...
OMAP3 L2 cache enabled
...
-- cut --

Dirk,

I don't see any i2c errors on my beagleboard.

Hardware issues perhaps? Or maybe compiler? I build with gcc 4.3.0.

I've fixed the mmc issue and the change is in the git repo. I think
that might be better to use than passing a big patch set on the list.

Steve

sakoman wrote:

Dirk,

I don't see any i2c errors on my beagleboard.

Hardware issues perhaps? Or maybe compiler? I build with gcc 4.3.0.

Seems to be toolchain :frowning:

I've fixed the mmc issue and the change is in the git repo. I think
that might be better to use than passing a big patch set on the list.

Okay. A patch is easier to review, though :wink:

Thanks

Dirk