Should we add logo and other tests in u-boot 1.3.3

Hi all:

I am following a two phased approach for software

1. Pushing the existing code to respective GIT tree : Long process.
2. Keeping complete source and binary images for others to use.

As mentioned in previous mail, I would like to post u-boot 1.3.3. and X-loader to code.google.com before that I would like to know:

- Should we have test cases for Audio tone and DVI logo ported from 1.1.4 to 1.3.3?

Let me know what other things we can add and what we can remove from existing x-loader and u-boot. I will incorporate your comments and upload the same.

Thanks

Regards,
Khasim

Hi Khasim,

Syed Mohammed, Khasim wrote:

Hi all:

I am following a two phased approach for software

1. Pushing the existing code to respective GIT tree : Long process.

Hopefully not so long. Or, better, hopefully long == several weeks, long != several month

2. Keeping complete source and binary images for others to use.

Source: Please don't doublicate source repositories. It's always confusing and makes trouble. Binary: Yes. Proposal: Get uboot and xloader git, build binaries, put binaries to code.google.com and mention "this is build with git version xxx". For xxx easiest would be a label, but git hash will work as well (git checkout <hash> is easy).

As mentioned in previous mail, I would like to post u-boot 1.3.3. and X-loader to code.google.com before that I would like to know:

- Should we have test cases for Audio tone and DVI logo ported from 1.1.4 to 1.3.3?

I don't think audio and DVI has to be "ported". If I remember correctly, the audio and DVI stuff worked at 1.3.3 as well. We removed it cause of size and boottime reasons.

For upstream, audio and DVI has no chance. Once Beagle uboot support is upstream, I think we have to support some uboot git add on (patches) with stuff not upstream. E.g. this then will be "take uboot git for basic beagle boot functionality, if you like to have some nice add ons not upstream please apply these patches".

Let me know what other things we can add and what we can remove from existing x-loader and u-boot. I will incorporate your comments and upload the same.

Who is "we"?

Please, don't do your own "fork" of Steve's git tree, nor put source snapshots of Steve's uboot tree at code.google.com. Yes, please feel free to *build* Steve's tree from time to time and put the resulting binaries at code.google.com.

Regarding Steve's uboot git tree, it would be really nice if you could help to clean it up. E.g. as already asked, we need help how to remove historical stuff e.g. ES1 support, clean up and fix pin mux, check clock configuration etc. Ideally, this help would be patches against Steve's git tree.

But again, please don't just put a fixed/improved uboot source blob at code.google.com and then do a "community, this is the master TI code, what's changed and how you get the changes/improvements into your (Steves) tree is your job". Please don't.

Sorry if I misunderstood anything, but in the past it happened several times that a "TI tree" (mainly kernels) appeared somewhere (with most probably quite good features and fixes), and it was always a pain to extract the improvements/changes and feed them back to mainline.

We started now to clean up the TI uboot source, so please help by working on this and don't publish an additional "TI uboot source v2".

Thanks

Dirk

I am following a two phased approach for software

  1. Pushing the existing code to respective GIT tree : Long process.

Hopefully not so long. Or, better, hopefully long == several weeks,
long != several month

Weeks for u-boot and x-loader but month(s) for features like Display in Kernel.

  1. Keeping complete source and binary images for others to use.

Source: Please don’t doublicate source repositories. It’s always
confusing and makes trouble. Binary: Yes. Proposal: Get uboot and
xloader git, build binaries, put binaries to code.google.com and
mention “this is build with git version xxx”. For xxx easiest would be
a label, but git hash will work as well (git checkout is easy).

Believe me I totally understand your concern, you have been helping TI for a much better software in community, your comment should be taken into account.

As mentioned in previous mail, I would like to post u-boot 1.3.3. and X-loader to code.google.com before that I would like to know:

  • Should we have test cases for Audio tone and DVI logo ported from 1.1.4 to 1.3.3?

I don’t think audio and DVI has to be “ported”. If I remember
correctly, the audio and DVI stuff worked at 1.3.3 as well. We removed
it cause of size and boottime reasons.

OK, no more tests or Logo in u-boot.

Let me know what other things we can add and what we can remove from existing x-loader and u-boot. I will incorporate your comments and upload the same.

Who is “we”?

beagle community… :), my “We” on beagle discussion list is “beagle” community and not TI :slight_smile:

Please, don’t do your own “fork” of Steve’s git tree, nor put source
snapshots of Steve’s uboot tree at code.google.com. Yes, please feel
free to build Steve’s tree from time to time and put the resulting
binaries at code.google.com

Ok, then we are going the GIT way for all sources, no more tar packages - right?

Dirk, you and me are from community so we can handle GIT stuff as suggested, but what about the app developers etc, will they be able to play around with GIT -?

I think with proper documentation even APP developers should be able to pull in GIT and do necessary modifications etc. Anyway this is the right procedure to work with Linux community so lets adopt this approach.

Then we need to host Bealge GIT for u-boot, kernel, x-loader, … and we need maintainers for the same.

Regarding Steve’s uboot git tree, it would be really nice if you could
help to clean it up. E.g. as already asked, we need help how to remove
historical stuff e.g. ES1 support, clean up and fix pin mux, check
clock configuration etc. Ideally, this help would be patches against
Steve’s git tree.

I will work on cleaning up the u-boot code base.

But again, please don’t just put a fixed/improved uboot source blob at

code.google.com and then do a “community, this is the master TI code,
what’s changed and how you get the changes/improvements into your
(Steves) tree is your job”. Please don’t.

I was almost doing this :), Now I will stop this.

But we have work on hosting GIT trees for u-boot, kernel and X-loader.

Thanks for you comments.

Regards,
Khasim

Khasim,

Syed Mohammed, Khasim wrote:

     > - Should we have test cases for Audio tone and DVI logo ported
    from 1.1.4 to 1.3.3?

    I don't think audio and DVI has to be "ported". If I remember
    correctly, the audio and DVI stuff worked at 1.3.3 as well. We removed
    it cause of size and boottime reasons.

OK, no more tests or Logo in u-boot.

Yes and no :wink:

No for upstream.

Yes for having a nice featured uboot for demos. The uboot beagle logo is quite impressive :wink: We have to find a way to maintain beagle uboot "add ons" which have no upstream chance but are nice to have. I would do it with "quilt controlled add on patches", but I'm sure that there is a git way as well.

Ok, then we are going the GIT way for all sources, no more tar packages - right?
Dirk, you and me are from community so we can handle GIT stuff as suggested, but what about the app developers etc, will they be able to play around with GIT -?

I would not distinguish between "kernel" and "app" developers. Let us distinguish between binary only users and people willing to rebuild from source. We will put uboot binaries to code.google.com, then mention which git "label/hash" was the base for this. And anybody who feels that he has to rebuild, just can do it. I don't think for people willing to rebuild uboot from source, there should be no difference extracting a tar archive or getting a git tree and doing checkout xxx.

I think with proper documentation even APP developers should be able to pull in GIT and do necessary modifications etc. Anyway this is the right procedure to work with Linux community so lets adopt this approach.

Agreed.

Then we need to host Bealge GIT for u-boot, kernel, x-loader, ... and we need maintainers for the same.

It's all there, no?

x-loader:

http://www.beagleboard.org/gitweb/?p=x-load.git;a=summary

Maintainer: Well, in above link there is an owner field :wink:

uboot:

Until basic stuff is upstream:

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

Steve does a great job here.

If stuff is upstream:

kernel:

http://source.mvista.com/git/?p=linux-omap-2.6.git;a=summary

    Regarding Steve's uboot git tree, it would be really nice if you could
    help to clean it up. E.g. as already asked, we need help how to remove
    historical stuff e.g. ES1 support, clean up and fix pin mux, check
    clock configuration etc. Ideally, this help would be patches against
    Steve's git tree.

I will work on cleaning up the u-boot code base.

I really like to see a patch from you (or anybody else with the knowledge) or at least a hint:

- How to cleanly remove ES1.0 clock stuff

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=blob;f=board/omap3530beagle/clock.c;h=964525b08aa9d63c9023494a2457be8cbe3c8413;hb=refs/heads/test

Lines 165 -181

Lines 214 -235

- How to fix pin mux

http://groups.google.com/group/beagleboard/msg/ea6419d444e76160

- Do we have to clean up v7_flush_dcache_all() ?

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=blob;f=cpu/omap3/start.S;h=065b3c7fd0a8b9172eb99e0cdacdb52295bbeeec;hb=refs/heads/test

Lines 420 - 470

I'm not sure, but reading the comments it seems that for Beagle's GP device we can remove most of this?

    But again, please don't just put a fixed/improved uboot source blob at
    code.google.com <http://code.google.com> and then do a "community,
    this is the master TI code,
    what's changed and how you get the changes/improvements into your
    (Steves) tree is your job". Please don't.

I was almost doing this :), Now I will stop this.

Thanks! Good that we talked about it :wink:

But we have work on hosting GIT trees for u-boot, kernel and X-loader.

? I think everything is already there and working, see above.

Best regards and thanks for your help

Dirk

Btw.: Two answers you asked at IRC:

- git tree: Yes, we are working at

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

with test as head. I had some trouble to check this out

http://elinux.org/BeagleBoard#U-Boot

worked for me then. And today an update worked with "git pull"

- What about some (volatile) checkpatch errors?

As already discussed with Nishant, not all *kernel* checkpatch warnings seem to apply to uboot. E.g. this linux/io.h vs. asm/io.h is an other one.

What I currently plan to do for upstream are several steps:

1) Do the easy clean up: Remove easy checkpatch errors, remove #if 0 parts, remove historical stuff or other boards etc.
2) Then discuss with everybody if we need some code rewrite (e.g. what we can do with remaining warnings, do we need additional features or remove features).
3) Reorganize directories (names) and files (content). E.g. some days ago there was some discussion at IRC how to name cpu subdirecory.

Then we will split the remaining beagle patch into < 40k chunks and send them the first time to uboot list. And then, well, we will see :wink: