Out of the Box Beagle REV C u-boot GIT

GoogleGroups
1

Hi all,

I have hosted a GIT for consolidating the work for REV C Out of the box u-boot.

Details below:
http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/logs/omap3dev

This tree is cloned from Sakoman's omap3dev branch.

I have committed a patch to add 1024x768 Logo. Also tested it booting
Angstrom, 2.6.22.18, Linux-omap GIT kernels.

http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/commits/478ae7a53716585f274306c1074b80d00e7c1882

• Public clone url:
git://gitorious.org/beagleboard-default-u-boot/mainline.git More info…
• HTTP clone url:
http://git.gitorious.org/beagleboard-default-u-boot/mainline.git More
info…
• Push url: git@gitorious.org:beagleboard-default-u-boot/mainline.git
More info…

BRANCH : omap3dev

Regards,
Khasim

2

Khasim,

Khasim Syed Mohammed wrote:

Hi all,

I have hosted a GIT for consolidating the work for REV C Out of the box u-boot.

Details below:
http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/logs/omap3dev

This tree is cloned from Sakoman's omap3dev branch.

How do you plan to make your work you do in your "fork" of Sakoman's
git is going back to that?

I understand that you might need some additional features for REV C
Out of the box U-Boot we don't want in (upstream preparation)
Sakoman's git (e.g. logo, some additional test functionality).

But we should avoid to have x "forks" of Sakoman's git confusing the
user. Having x "forks" wouldn't be better than the ugly tar balls we
had in the past.

I'd like that we discuss *all* the changes you make and then decide:

(a) if it is something we like to have in Sakoman's git you send a
patch to this list and/or ask Steve to pull it from your git into his

(b) if it is something we don't want in Sakoman's git (e.g. logo, test
functions) you send them as consolidated patch to this list (compare
[1]). This would enable user's to easily take them and apply them on
top of Sakoman's git if they like. This avoids that they need to deal
with an other git which might be confusing.

I don't want that we have to check your git regularly, have to extract
the changes and have to do (a) or (b) our own. I'd like you to do
this. Additionally, this means that review results are fixed, too.

I'd really like that we avoid "here is the (TI) code (tar ball), clean
up and merge into community tree is communities job, we are busy to
get the product out" this time!

Many thanks

Dirk

[1]
http://groups.google.com/group/beagleboard/browse_thread/thread/3ad9b803a3418624/3416ad0648deea06?lnk=gst&q=logo#3416ad0648deea06

Btw.: To test what is said above, the logo patch

http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/commits/478ae7a53716585f274306c1074b80d00e7c1882

you mention in this mail goes into category (b) above. So:

* Please don't do *((uint *) and *((unsigned short *) stuff. Use
readx/writex functions
* Most probably the access method *((xxx *) lacks volatile and
therefore only works by accident (readx/writex will do this for you).
* For register access use struct overlays.
* Replace all hard coded values (0xfefffedf etc.) with macros
* Add some comments what this code is doing

* When you did the clean up, please send an update patch against [1]
above, then.

3

Dirk Behme wrote:

* For register access use struct overlays.
One question to this. I know this is the way U-boot/Linux goes, but I have a
concern/questions since I once experienced a problem with this. It's around
4-5 years back, and I tried to share structs between different compilers
(both different embedded compilers - GCC, RVCT and a DSP compiler AFAIR -
and MSVC6.0 for the Windows host).

During this I realized, that different compilers might interpret the layout
of a struct differently. I.e. insert a different number of pad-bytes in the
struct to align data most optimal. Furthermore the struct layout padding
would sometimes change depending on the optimization level and the actual
struct in question. Last but not least I think to remember one compiler
which actually changed the order of the elements to optimize stuff. At that
time I didn't had the time to investigate the problem in dept, and just
turned for the "quick and dirty" solution with a set of defines pointing at
the right offsets...

Does anybody know if this is really controlled by the C-language or GCC, or
if we are "living on luck" while doing register accesses using structs? I
meant, it might be that the only reason it works is that all/most registers
in OMAP are 32-bit-sized and -aligned, meaning no padding bytes need to be
inserted?

Best regards
  Søren

4

Hi Søren,

using the structs for register definition and allocating the pointer to
the specified adress is indeed very comfortable.
On complex HW I/O control registers this provides much better indication
on what I'm dealing with and, for me, helps against my own fainty memory
on dealing with the lots of flags and subadresses being involved with a
built in periphial. So I rather like using it :-).

But you are right when it comes down to padding bytes...
Usually most compilers allow for setting the padding of structures to 1
(Byte) (eg. #pragma pack (1), don't know yet how to do this in gcc).

Still there are some devices (ex. TMS320F28xx) that may even not be able
to address a single byte at all. Which usually can be quite ass-kicking
when dealing with the implications...
Even though I knew there is no real Byte access, that controller and the
codecomposer caught me several times when dealing with byte related data.

I have _never_ seen a compiler rearranging the order of members within a
struct from written definition so far.
Well, however- there is one thing _close_ to an exception to this 'rule':
Exchanging struct data between little and big endian machines.
This will have different orders for the MSB/LSB inside Word/long/.. of
course.
But even in this case I have never noticed a change of order in the
struct members.

On the other hand it makes no sense for the hw guys to implement hw
registers that are misaligned to the processors preference as they will
need additional resources for decoding adresses, introduce wait states
for accessing and so on.
I think that nowadays one can be shure that the hw registers always are
aligned to the processors preference.
Therefore taking a struct definition should be rather considered portable.
I'd recommend to place a note for the definitions file to tell what
packing and byte order is set/assumed...

regards,
  A. den Toom

Søren Steen Christensen schrieb:

5

Hi Toom,

I totally agree with you, and I as well prefer the struct-approach.

My only question is if we are completely sure about what we are doing before
going ahead and modifying all the code? A worst case scenario could be a
complete new GCC implementation coming out tomorrow handling structs in a
complete other way in case nothing is really specified in the C-standard. I
know this is highly unlikely, but just wanted to make sure, that we - and
not the compiler - are in full control :slight_smile:

And since I wasn't/isn't sure about the answer myself I thought better to
post the question to get the discussion running.

Best regards - Happy New Year
  Søren

6

Hi Søren,

did some googling on the issue and found:
----- Within a structure object, the non-bit-field members and units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member… and vice versa. There may therefore be unnamed padding within a structure object, but not at its beginning, as necessary to achieve the appropriate alignment. ----- This clearly shows that the order of members is defined, in contrary the padding is depending on implementation… As the structure definition (Hardware registers) is clearly connected to a specific hardware I think it is safe to assume that even padding will be the same for all compilers as this is hw related to the target platform. At least when leaving a note about considered alignment and endianess along with the definition, the code will be easily portable. As porting of this code usually is done by HW related persons (at least they should know about HW registers of periphials…) I suspect that they will be aware of whats happening. If you want to give a clear hint to signal problems with endianess, once they come up, you could use something like: — typedef union { unsigned long ul_EndianCheck; unsigned char auc_EndianCheck[4]; } tu_EndianCheck; const U_EndianCheck = {0x01020304}; bool IsLittleEndian(void) { /* during runtime check if the byte at &U_EndianCheck.auc_EndianCheck[0] contains 0x04 for little endian… */ } — however this is only checkable during runtime :frowning: Maybe somebody else has a good (compiler independent) solution for this issue, I don’t know any unless the compiler supplies a predefined macro you can check, or forcing the developer to predefine a global macro for compilation stating the endianess of the machine. Anyway, as long we are dealing with HW related structures this should not appear to be a big problem during porting. If the new machine itself has changed endianess, the hw-periphial the definition is created for may be assumed to be connected according to the endianess of the new machine, if not… well - I guess you will be in big trouble accessing multibyte registers anyway! So, after all above runtime check is quite suitable for data structures being exchanged between two systems of perhaps different endianess and may be considered a mandantory call on initialization of system when dealing with this. regards, AdT Steen Christensen schrieb:

7

Great – Thanks for investigating. I’m happy, that ANSI C states, that the order should be kept – Actually, this was my main concern. J

With respect to the padding, I agree, that it most probably won’t cause any problems, since it would be stupidity of the compiler to insert pad-bytes at “random places” for 32-bit aligned 32-bit-wide-registers – At least I currently can’t come up with any great/valid reasons for doing this J

Best regards and thanks

Søren

8

Khasim,

Please correct me where I'm wrong...

Khasim,

Khasim Syed Mohammed wrote:

Hi all,

I have hosted a GIT for consolidating the work for REV C Out of the box u-boot.

Details below:
http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/logs/omap3dev

This tree is cloned from Sakoman's omap3dev branch.

How do you plan to make your work you do in your "fork" of Sakoman's
git is going back to that?

I understand that you might need some additional features for REV C
Out of the box U-Boot we don't want in (upstream preparation)
Sakoman's git (e.g. logo, some additional test functionality).

I'd guess is that is all that should live on Khasim's fork. The logo is
currently the only patch on it.

But we should avoid to have x "forks" of Sakoman's git confusing the
user. Having x "forks" wouldn't be better than the ugly tar balls we
had in the past.

I disagree, since at least forks have the opportunity to have common
commits, so that you can tell where they are different. This serves the
purpose of keeping everything open. Sakoman's git is currently the
upstream for Beagle u-boot, but even that is a distraction from denx.de
which is the real upstream.

I'd like that we discuss *all* the changes you make and then decide:

(a) if it is something we like to have in Sakoman's git you send a
patch to this list and/or ask Steve to pull it from your git into his

If this was something that should go onto Sakoman's git, the patch
would have been submitted. This is only for diagnostics and out-of-box
experience (logo, etc.).

(b) if it is something we don't want in Sakoman's git (e.g. logo, test
functions) you send them as consolidated patch to this list (compare
[1]). This would enable user's to easily take them and apply them on
top of Sakoman's git if they like. This avoids that they need to deal
with an other git which might be confusing.

Final result can be a consolidated patch set, but this provides the
daily visibility into the process. We could establish that within TI, but
I think that goes against the community development approach. I am
very glad this is public.

I don't want that we have to check your git regularly, have to extract
the changes and have to do (a) or (b) our own. I'd like you to do
this. Additionally, this means that review results are fixed, too.

I'd really like that we avoid "here is the (TI) code (tar ball), clean
up and merge into community tree is communities job, we are busy to
get the product out" this time!

This isn't a step in that direction at all. You should notice TI patches
going directly to the denx.de mailing list. This effort is only for board
production changes that aren't suitable for upstream. There is no need
for you to closely monitor unless you care about *exactly* what is going
to go into the Rev C boards (with diagnostic patches).

Many thanks

Dirk

[1]
http://groups.google.com/group/beagleboard/browse_thread/thread/3ad9b803a3418624/3416ad0648deea06?lnk=gst&q=logo#3416ad0648deea06

Btw.: To test what is said above, the logo patch

http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/commits/478ae7a53716585f274306c1074b80d00e7c1882

you mention in this mail goes into category (b) above. So:

* Please don't do *((uint *) and *((unsigned short *) stuff. Use
readx/writex functions
* Most probably the access method *((xxx *) lacks volatile and
therefore only works by accident (readx/writex will do this for you).
* For register access use struct overlays.
* Replace all hard coded values (0xfefffedf etc.) with macros
* Add some comments what this code is doing

* When you did the clean up, please send an update patch against [1]
above, then.

I have committed a patch to add 1024x768 Logo. Also tested it booting
Angstrom, 2.6.22.18, Linux-omap GIT kernels.

I was able to boot a kernel off of the head of linux-omap (though I did apply
some patches to it and alter the .config). The old logo would work with the
pico projector, though it would get chopped off. The old one would also
work on some HDTVs. This one does not work with the pico nor my HDTV.
I think we should look for HDTV and pico projector compatibility. My feeling
is that 1024x768 is not a very compatible mode as it is *only* for DVI-D
monitors.

9

Jason Kridner wrote:

Khasim,

Please correct me where I'm wrong...

Khasim,

Khasim Syed Mohammed wrote:

Hi all,

I have hosted a GIT for consolidating the work for REV C Out of the
box u-boot.

Details below:
http://gitorious.org/projects/beagleboard-default-u-boot/repos/mainline/logs/omap3dev

This tree is cloned from Sakoman's omap3dev branch.

How do you plan to make your work you do in your "fork" of Sakoman's
git is going back to that?

I understand that you might need some additional features for REV C
Out of the box U-Boot we don't want in (upstream preparation)
Sakoman's git (e.g. logo, some additional test functionality).

I'd guess is that is all that should live on Khasim's fork. The logo is
currently the only patch on it.

Yes. Let us see if somebody (from TI) will take the time and clean it
up now. Then I will be glad and this mail thread resulted in what it
was good for.

Sorry if I was unclear about this, but my impression is/was that this
"fork" we talk about here will have added some more (Rev C test)
features. Not only logo. So I tried to "release early" how I'd like to
deal with this tree.

But we should avoid to have x "forks" of Sakoman's git confusing the
user. Having x "forks" wouldn't be better than the ugly tar balls we
had in the past.

I disagree, since at least forks have the opportunity to have common
commits, so that you can tell where they are different.

Hmm, yes, maybe it is a little easier to pick diffs from git commits.
But if this isn't done by the commiter (Khasim?), then it is some work
for somebody else (like it is work diffing two tar balls).

This serves the
purpose of keeping everything open. Sakoman's git is currently the
upstream for Beagle u-boot, but even that is a distraction from denx.de
which is the real upstream.

Yes. The point here is that we (the commiters of Sakoman's git)
regularly send patches to mailing list. Again: If the maintainer of a
git "fork" regularly cares about sending his patches/pull requests to
mailing list I'm totally fine with git clones. I.e. what I want to say
is: "If you create a git clone, it's *your* job to ensure that your
changes are going back to parent git in a clean way." If this will
happen with your U-Boot branches, too, I will be glad.

I'd like that we discuss *all* the changes you make and then decide:

(a) if it is something we like to have in Sakoman's git you send a
patch to this list and/or ask Steve to pull it from your git into his

If this was something that should go onto Sakoman's git, the patch
would have been submitted.

This will be fine. I will believe it if it happens :wink:

This is only for diagnostics and out-of-box
experience (logo, etc.).

As I don't know what you plan to add to this clone, I talk in a more
general way, not about specific patches. Therefore I asked for
discussion. With logo patch this happened, we will see if it will
happen with further changes, too.

(b) if it is something we don't want in Sakoman's git (e.g. logo, test
functions) you send them as consolidated patch to this list (compare
[1]). This would enable user's to easily take them and apply them on
top of Sakoman's git if they like. This avoids that they need to deal
with an other git which might be confusing.

Final result can be a consolidated patch set, but this provides the
daily visibility into the process.
We could establish that within TI,
but
I think that goes against the community development approach.

What's wrong to send an updated logo patch in reply to [1] if you
think logo patch is ready?

I am
very glad this is public.

Yes, agreed, better than an outdated tar ball hitting us in some month :wink:

I don't want that we have to check your git regularly, have to extract
the changes and have to do (a) or (b) our own. I'd like you to do
this. Additionally, this means that review results are fixed, too.

I'd really like that we avoid "here is the (TI) code (tar ball), clean
up and merge into community tree is communities job, we are busy to
get the product out" this time!

This isn't a step in that direction at all.

Nice to hear!

You should notice TI
patches
going directly to the denx.de mailing list.

About which (OMAP3) patches are you talking? The DaVinci patches?

E.g. we asked Mani several times to send his patches to U-Boot list,
nothing happened (?).

This effort is only for
board
production changes that aren't suitable for upstream.

Ok. Then a consolidated (clean) patch (at the end of development
process) against Steve's git would be fine.

And as mentioned above, if you find e.g. a bug while doing your
production test code which goes in category (a) above, a patch/pull
request would be required.

There is no need
for you to closely monitor unless you care about *exactly* what is going
to go into the Rev C boards (with diagnostic patches).

I have to monitor unless I can be sure that you really care about (a)
and (b) :wink:

A really bad experience is

http://marc.info/?l=linux-omap&m=122911571519657&w=2

with omapzoom git: Creating a git clone, fixing there main bugs and
then some weeks later a mail "this bug is fixed in the clone already".
This is exactly what I try to avoid with this mail thread.

If this doesn't happen here as you promised above, everything will be
fine!

At least it seems to be good that we are talking about it :wink:

Thanks

Dirk