[U-Boot-Users] How to patch u-boot?

[U-Boot-Users] How to patch u-boot?

[Tiju]

>> 
Hi
>> 
>> 
Could 
someone 
help 
me 
out 
with 
patching 
the 
u-boot.
>> 
I 
downloaded 
the 
source 
code 
of 
u-boot-1.1.6 
and 
untared 
it. 
Then 
I 
do 
a 
>> 
$cd 
u-boot-1.1.6
>> 
$svn 
co 
http://svn.openmoko.org/trunk/src/target/u-boot/patches/

>those 
patches 
are 
against 
current 
git 
head 
of 
u-boot.  
What 
gave 
you 
the
>assumption 
that 
the 
patches 
are 
agains 
1.1.6?


Because in http://wiki.openmoko.org/wiki/Uboot, the bootloader source code section says..."The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/. Untar the sources, apply the patch, run "make gta01bv3_config"
(or gta01bv2_config, or whatever hardware revision you have), run
"make". You will get a resulting "u-boot.bin" image, which you can
directly flash (either using existing bootloader or sjf2410-linux) into NAND.
"

So, I do not know which version to apply the patches to. How do I get the current git head of u-boot or the source code of the current bootloader for which the patches has to be applied.


Thanks
Tiju Jacob



      Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php

[U-Boot-Users] How to patch u-boot?

[Wolfgang Denk]

In message <99605.88037.qm@web94612.mail.in2.yahoo.com> you wrote:
> >> 
> Hi
> >> 
> >> 
> Could 
> someone 
> help 
> me 
> out 
> with 
> patching 
> the 
> u-boot.
...

Stop sending such junk. Learn to send regular e-mail before poosting
here again.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
      Bugs are by far the largest and  most successful class of
      entity, with nearly a million known species. In this res-
      pect they outnumber all the other  known  creatures about
      four to one.  -- Professor Snope's Encyclopedia of Animal

[U-Boot-Users] How to patch u-boot?

[Jerry Van Baren]

Tiju wrote:
> Hi

[snipped unreadable original request]

> Because in http://wiki.openmoko.org/wiki/Uboot, the bootloader source
> code section says..."The current bootloader patches can be found at
> http://svn.openmoko.org/trunk/src/target/u-boot/patches/. Untar the
> sources, apply the patch, run "make gta01bv3_config" (or
> gta01bv2_config, or whatever hardware revision you have), run "make".
> You will get a resulting "u-boot.bin" image, which you can directly
> flash (either using existing bootloader or sjf2410-linux) into NAND." 
> 
> So, I do not know which version to apply the patches to. How do I get
> the current git head of u-boot or the source code of the current
> bootloader for which the patches has to be applied.
> 
> Thanks
> Tiju Jacob

Openmoko has not been an active participant on the u-boot list.  They 
took a snapshot of u-boot and then did their own patching, but did not 
feed the patches back to u-boot.  The result is a fork.  IIRC, there has 
been talk about unforking openmoko, but that has not happened yet.

The bottom line is that we know little or nothing about openmoko's 
u-boot build methodology.  You need to ask openmoko developers (openmoko 
lists).
   <http://lists.openmoko.org/mailman/listinfo/>

Best regards,
gvb

[U-Boot-Users] How to patch u-boot?

[Harald Welte]

On Mon, Jan 21, 2008 at 10:07:07AM -0500, Jerry Van Baren wrote:

> Openmoko has not been an active participant on the u-boot list.  

Mh, please check your list archives.  I see 22 postings over the last
year.  Not many, but also !=- 'not been active'.

> They  took a snapshot of u-boot and then did their own patching, but
> did not  feed the patches back to u-boot.  

This is also not entirely true

1) we are constantly merging our patchset with mainline u-boot, at least
   once per week.

2) I have submitted two rounds of our patches (with about one year in
   between those two instances), and I have the feeling that the
   interest in even commenting to those patches was quite low.  This is
   not very encouraging for further submissions.

> The result is a fork.  IIRC, there has  been talk about unforking
> openmoko, but that has not happened yet.

I'd be very happy to do so.  However, there are several reasons why this
is extremely difficult

1) the s3c24xx chipset family support in u-boot is minimal and outdated.
   It only covers the s3c2400 and s3c2410, and even those only partially
   In order to make it support the s3c2410, s3c2440, s3c2442, I had to
   do some extensive re-work.  Since there seems to be nobody who cares
   a lot about that family of chips (most products based on them,  even
   if they run linux, don't use u-boot), I see quite a bit of reluctance
   to merge those patches.  Furthermore, I have zero clue if there still
   is any living person out there who is trying to run u-boot on a
   s3c2400, and we certainly have no way of testing whether the new code
   breaks any of the old code.  It has actually come to a point where
   I'd volunteer to maintain the s3c24xx chipset code in u-boot, if
   anyone was interested in that

2) Some of the changes, notably the sd/mmc driver for s3c24xx was
   rejected by the u-boot list, since it just does what everyone else
   does: no shared host controller code, just copy+paste the bits that
   the other sd/mmc controllers do.  While I understand that there is a
   need for a shared sd/mmc code, putting the burden of creating such
   code on us is just too much.  With this kind of requirement you will
   unlikely to see anyone merge another sd/mmc controller driver into
   u-boot, since everyone evades creating the generic/common code. This
   is not pure laziness, but inexperience with the code and lack of
   access to all the different hardware 

3) Some code is really ugly and spread throughout the code, since there
   is no clean/modular way how to do this inside u-boot.  One perfect
   example is the boot menu code that we added.  I don't even bother to
   submit it, since I'm sure it will be rejected

> The bottom line is that we know little or nothing about openmoko's  
> u-boot build methodology.  You need to ask openmoko developers (openmoko  
> lists).
>   <http://lists.openmoko.org/mailman/listinfo/>

This is entirely true.  Usually those questions are raised on the (now
defunct) openmoko-uboot list, that has been superseded by
openmoko-kernel.

Cheers,
-- 
- Harald Welte <laforge@openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone

[U-Boot-Users] How to patch u-boot?

[gvb.uboot]

Harald Welte wrote:
> On Mon, Jan 21, 2008 at 10:07:07AM -0500, Jerry Van Baren wrote:
> 
>> Openmoko has not been an active participant on the u-boot list.  
> 
> Mh, please check your list archives.  I see 22 postings over the last
> year.  Not many, but also !=- 'not been active'.

Good to know, thanks for correcting me.  I've watched openmoko in the 
past and thought about buying one but don't have enough time in my life 
right now.  :-(

>> They  took a snapshot of u-boot and then did their own patching, but
>> did not  feed the patches back to u-boot.  
> 
> This is also not entirely true
> 
> 1) we are constantly merging our patchset with mainline u-boot, at least
>    once per week.
> 
> 2) I have submitted two rounds of our patches (with about one year in
>    between those two instances), and I have the feeling that the
>    interest in even commenting to those patches was quite low.  This is
>    not very encouraging for further submissions.

:-(

>> The result is a fork.  IIRC, there has  been talk about unforking
>> openmoko, but that has not happened yet.
> 
> I'd be very happy to do so.  However, there are several reasons why this
> is extremely difficult
> 
> 1) the s3c24xx chipset family support in u-boot is minimal and outdated.
>    It only covers the s3c2400 and s3c2410, and even those only partially
>    In order to make it support the s3c2410, s3c2440, s3c2442, I had to
>    do some extensive re-work.  Since there seems to be nobody who cares
>    a lot about that family of chips (most products based on them,  even
>    if they run linux, don't use u-boot), I see quite a bit of reluctance
>    to merge those patches.  Furthermore, I have zero clue if there still
>    is any living person out there who is trying to run u-boot on a
>    s3c2400, and we certainly have no way of testing whether the new code
>    breaks any of the old code.  It has actually come to a point where
>    I'd volunteer to maintain the s3c24xx chipset code in u-boot, if
>    anyone was interested in that

I spend most my time in PowerPC world, so I'm pretty clueless WRT 
ARM-based chips.  According to
   <http://www.denx.de/wiki/UBoot/Custodians>
Peter Pearse is the ARM custodian, so he most likely would be the one to 
pester.

I would speculate the lack of comments on your patches (2 above) and the 
lack of anyone else(?) working with that chipset are related.

> 2) Some of the changes, notably the sd/mmc driver for s3c24xx was
>    rejected by the u-boot list, since it just does what everyone else
>    does: no shared host controller code, just copy+paste the bits that
>    the other sd/mmc controllers do.  While I understand that there is a
>    need for a shared sd/mmc code, putting the burden of creating such
>    code on us is just too much.  With this kind of requirement you will
>    unlikely to see anyone merge another sd/mmc controller driver into
>    u-boot, since everyone evades creating the generic/common code. This
>    is not pure laziness, but inexperience with the code and lack of
>    access to all the different hardware 

/me == clueless

> 3) Some code is really ugly and spread throughout the code, since there
>    is no clean/modular way how to do this inside u-boot.  One perfect
>    example is the boot menu code that we added.  I don't even bother to
>    submit it, since I'm sure it will be rejected

:-(

>> The bottom line is that we know little or nothing about openmoko's  
>> u-boot build methodology.  You need to ask openmoko developers (openmoko  
>> lists).
>>   <http://lists.openmoko.org/mailman/listinfo/>
> 
> This is entirely true.  Usually those questions are raised on the (now
> defunct) openmoko-uboot list, that has been superseded by
> openmoko-kernel.

Well, at least I got one thing right.  :-/

Best regards,
gvb

[U-Boot-Users] How to patch u-boot?

[Martin Krause]

Hi Harald,

u-boot-users-bounces at lists.sourceforge.net wrote on :
> > The result is a fork.  IIRC, there has  been talk about unforking
> > openmoko, but that has not happened yet.
> 
> I'd be very happy to do so.  However, there are several reasons why
> this is extremely difficult
> 
> 1) the s3c24xx chipset family support in u-boot is minimal and
>    outdated. It only covers the s3c2400 and s3c2410, and even those
>    only partially In order to make it support the s3c2410, s3c2440,
>    s3c2442, I had to do some extensive re-work.  Since there seems to
>    be nobody who cares a lot about that family of chips (most
>    products based on them,  even if they run linux, don't use
>    u-boot), I see quite a bit of reluctance to merge those patches. 
>    Furthermore, I have zero clue if there still is any living person
>    out there who is trying to run u-boot on a s3c2400, and we

The trab board (with a S3C2400 CPU) is still in production. But there
we use an old U-Boot version (1.1.4) and I see no need to ever update
to a newer version (the board is running stable for some years now).

>    certainly have no way of testing whether the new code breaks any
>    of the old code.  It has actually come to a point where I'd

I would not raise any objections, if the trab board will not be 
supported by future U-Boot versions. I can't speak for other S3C2400 
boards, but AFAIK the production of the S3C2400 has been discontinued.

Berst Regards,
Martin Krause

[U-Boot-Users] How to patch u-boot?

[Wolfgang Denk]

In message <47F3F98010FF784EBEE6526EAAB078D10635DDAB@tq-mailsrv.tq-net.de> you wrote:
> 
> >    Furthermore, I have zero clue if there still is any living person
> >    out there who is trying to run u-boot on a s3c2400, and we
> 
> The trab board (with a S3C2400 CPU) is still in production. But there
> we use an old U-Boot version (1.1.4) and I see no need to ever update
> to a newer version (the board is running stable for some years now).

Yet we still use the trab board as reference for S3C2400 when testing
new U-Boot versions.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quantum particles: The dreams that stuff is made of.

[U-Boot-Users] How to patch u-boot?

[Wolfgang Denk]

Dear Harald,

in message <20080121193613.GW706@prithivi.gnumonks.org> you wrote:
> 
> 2) I have submitted two rounds of our patches (with about one year in
>    between those two instances), and I have the feeling that the
>    interest in even commenting to those patches was quite low.  This is
>    not very encouraging for further submissions.

Please don't mistake missing feedback for missing interest. There *is*
interest in your patches, and care will be taken that your patches get
processed as they should. Promised.

We do habe an ARM custodian problem that needs to be solved soon, but
this affects all ARM contriobutions, not only yours. So please  don;t
take it personally.

> 1) the s3c24xx chipset family support in u-boot is minimal and outdated.

It's outdated because nobody feeds back patches. This  is  a  chicekn
and  egg  situation,  and  if  you work on this platform it's you who
could solve it.

>    do some extensive re-work.  Since there seems to be nobody who cares
>    a lot about that family of chips (most products based on them,  even
>    if they run linux, don't use u-boot), I see quite a bit of reluctance
>    to merge those patches.  Furthermore, I have zero clue if there still

I am not reluctant. Please go on and post patches. U-Boot will not
spread if we don;t use it, or if we don;t make our changes available
to the public.

Pther users of such processors will not use U-Boot *because* support
for these chips is "minimal and outdated".

>    is any living person out there who is trying to run u-boot on a
>    s3c2400, and we certainly have no way of testing whether the new code

This is wrong. There is tens of thousands of systems running in the
field.

>    breaks any of the old code.  It has actually come to a point where
>    I'd volunteer to maintain the s3c24xx chipset code in u-boot, if
>    anyone was interested in that

You are welcome. Is this a serious offer? I think it might help to
solve at least some parts of the ARM dilemma we're in.

> 2) Some of the changes, notably the sd/mmc driver for s3c24xx was
>    rejected by the u-boot list, since it just does what everyone else
>    does: no shared host controller code, just copy+paste the bits that
>    the other sd/mmc controllers do.  While I understand that there is a
>    need for a shared sd/mmc code, putting the burden of creating such
>    code on us is just too much.  With this kind of requirement you will
>    unlikely to see anyone merge another sd/mmc controller driver into
>    u-boot, since everyone evades creating the generic/common code. This
>    is not pure laziness, but inexperience with the code and lack of
>    access to all the different hardware 

Well, someone has to go ahead... 

> 3) Some code is really ugly and spread throughout the code, since there
>    is no clean/modular way how to do this inside u-boot.  One perfect
>    example is the boot menu code that we added.  I don't even bother to
>    submit it, since I'm sure it will be rejected

Maybe in th first version of the patch. But  maybe  others  will  add
ideas how to make it less ugly and more suitable for integration, and
maybe  (maybe!)  in the end we will have a system which is better for
everybody.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Totally illogical, there was no chance.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] How to patch u-boot?

[Harald Welte]

Dear Wolfgang,

thanks for your prompt feedback.

On Tue, Jan 22, 2008 at 10:18:39AM +0100, Wolfgang Denk wrote:
> > 
> > 2) I have submitted two rounds of our patches (with about one year in
> >    between those two instances), and I have the feeling that the
> >    interest in even commenting to those patches was quite low.  This is
> >    not very encouraging for further submissions.
> 
> Please don't mistake missing feedback for missing interest. There *is*
> interest in your patches, and care will be taken that your patches get
> processed as they should. Promised.
> 
> We do habe an ARM custodian problem that needs to be solved soon, but
> this affects all ARM contriobutions, not only yours. So please  don;t
> take it personally.

I know the problem, both specifically and general to FOSS projects, as I
have worked in many of them ;)  So I know it isn't personally, but then
also I personally don't think that my patches are more important than
anyone elses...

> > 1) the s3c24xx chipset family support in u-boot is minimal and outdated.
> 
> It's outdated because nobody feeds back patches. This  is  a  chicekn
> and  egg  situation,  and  if  you work on this platform it's you who
> could solve it.

yes and no.  

> >    do some extensive re-work.  Since there seems to be nobody who cares
> >    a lot about that family of chips (most products based on them,  even
> >    if they run linux, don't use u-boot), I see quite a bit of reluctance
> >    to merge those patches.  Furthermore, I have zero clue if there still
> 
> I am not reluctant. Please go on and post patches. U-Boot will not
> spread if we don;t use it, or if we don;t make our changes available
> to the public.

I agree that at least the core s3c24xx stuff should go mainline, no
question about that.

> Pther users of such processors will not use U-Boot *because* support
> for these chips is "minimal and outdated".

that's true.  btw: Samsung is now shipping some (old, outdated) fork of
u-boot with their later smdk2443 and smdk6400 boards.  Obviously the
code is neither clean nor suitable for submission, nor was it ever even
submitted :(

But 2443 and 6400 are beyond what openmoko has done so far anyway, so
this is not competing.

> >    is any living person out there who is trying to run u-boot on a
> >    s3c2400, and we certainly have no way of testing whether the new code
> 
> This is wrong. There is tens of thousands of systems running in the
> field.

yes. I was thinking of 'people who develop new products and are looking
for a bootloader'.  The 2400 is discontinued for quite some time...

> >    breaks any of the old code.  It has actually come to a point where
> >    I'd volunteer to maintain the s3c24xx chipset code in u-boot, if
> >    anyone was interested in that
> 
> You are welcome. Is this a serious offer? I think it might help to
> solve at least some parts of the ARM dilemma we're in.

I'm serious about this, yes.  

At least for 2410/2440/2442, I have quite extensive experience after all
the hacking at OpenMoko.  I'm familiar with the smdk2410, qt2410,
smdk2440, qt2440, neo1973_gta01 (s3c2410), neo1973_gta02 (s3c2442b) and
hxd8 (s3c2440) boards, and I can contribute board support for all those
to u-boot.  I'm also in contact with what Ben Dooks (Linux s3c24xx
maintainer) is doing on the mainline kernel side.

> > 2) Some of the changes, notably the sd/mmc driver for s3c24xx was
> >    rejected by the u-boot list, since it just does what everyone else
> >    does: no shared host controller code, just copy+paste the bits that
> >    the other sd/mmc controllers do.  While I understand that there is a
> >    need for a shared sd/mmc code, putting the burden of creating such
> >    code on us is just too much.  With this kind of requirement you will
> >    unlikely to see anyone merge another sd/mmc controller driver into
> >    u-boot, since everyone evades creating the generic/common code. This
> >    is not pure laziness, but inexperience with the code and lack of
> >    access to all the different hardware 
> 
> Well, someone has to go ahead... 

yes, of course.  But you need somebody who is voluntarily committed to
doing a generic sd/mmc stack for u-boot.  It's no use to try to
push/force  people who have only the time to write a host controlelr
driver into doing it ;)

Ok.  Give me a bit of time, and I'll do another round of
s3c24xx/openmoko/neo1973 related patch submissions.

Cheers,
-- 
- Harald Welte <laforge@openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone

[U-Boot-Users] How to patch u-boot?

[Stefan Roese]

Hi Harald,

On Tuesday 22 January 2008, Harald Welte wrote:
> > >    breaks any of the old code.  It has actually come to a point where
> > >    I'd volunteer to maintain the s3c24xx chipset code in u-boot, if
> > >    anyone was interested in that
> >
> > You are welcome. Is this a serious offer? I think it might help to
> > solve at least some parts of the ARM dilemma we're in.
>
> I'm serious about this, yes.
>
> At least for 2410/2440/2442, I have quite extensive experience after all
> the hacking at OpenMoko.  I'm familiar with the smdk2410, qt2410,
> smdk2440, qt2440, neo1973_gta01 (s3c2410), neo1973_gta02 (s3c2442b) and
> hxd8 (s3c2440) boards, and I can contribute board support for all those
> to u-boot.  I'm also in contact with what Ben Dooks (Linux s3c24xx
> maintainer) is doing on the mainline kernel side.

I really hope you are still willing to take over the s3c24xx U-Boot 
custodianshipment. This would be a great improvement. If yes, please send 
Wolfgang your public SSH key, so that he setup a new repository for the 
Samsung ARM stuff.

BTW: How should this repository be called? "u-boot-s3c24xx"? Or do you have a 
different suggestion?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] How to patch u-boot?

[Harald Welte]

Hi Stefan!

On Mon, Mar 17, 2008 at 02:54:00PM +0100, Stefan Roese wrote:
 
> On Tuesday 22 January 2008, Harald Welte wrote:
> > > >    breaks any of the old code.  It has actually come to a point where
> > > >    I'd volunteer to maintain the s3c24xx chipset code in u-boot, if
> > > >    anyone was interested in that
> > >
> > > You are welcome. Is this a serious offer? I think it might help to
> > > solve at least some parts of the ARM dilemma we're in.
> >
> > I'm serious about this, yes.
> >
> > At least for 2410/2440/2442, I have quite extensive experience after all
> > the hacking at OpenMoko.  I'm familiar with the smdk2410, qt2410,
> > smdk2440, qt2440, neo1973_gta01 (s3c2410), neo1973_gta02 (s3c2442b) and
> > hxd8 (s3c2440) boards, and I can contribute board support for all those
> > to u-boot.  I'm also in contact with what Ben Dooks (Linux s3c24xx
> > maintainer) is doing on the mainline kernel side.
> 
> I really hope you are still willing to take over the s3c24xx U-Boot 
> custodianshipment. This would be a great improvement. If yes, please send 
> Wolfgang your public SSH key, so that he setup a new repository for the 
> Samsung ARM stuff.

Yes, I am still willing to do this, and will be happy to help.

> BTW: How should this repository be called? "u-boot-s3c24xx"? Or do you have a 
> different suggestion?

That name is fine.

Please find my SSHv2 keys (home and laptop) attached.

Please also note that I'm still on holidays in Brasil until March 26th,
so there will be no work before that time.

Cheers,
-- 
- Harald Welte <laforge@openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone
-------------- next part --------------
ssh-dss AAAAB3NzaC1kc3MAAACBAKud0HBhEhp+ojejfXQCdWdNUzeY1wx3inhGcweVSurHPEMUVGOtOse6dAd0d2MSc3EBXexVaIr/8nNVRdBRAHpwFDg1r8QozZVkCuIEfWZoCoIcSGQP78qZfkKt95+97LUDDTILxoh/j04RCeftbITulkqY5T1z13JSyON/xibPAAAAFQDD5QCtv96Kwsk9c/dxaiCrkqkRzwAAAIAeCGWQyv/DGfJlUa0Gft7BMZLa7XIkPAGUgT66LopBfC/2N0w5uSoAC5zSf/NYcmR+J/urKdkQ40b4XRUJIoXJyTIyuIYdEjILxpYEkCXy3zFUvrujgIY1h36sybsvcccEsttIQwaZKnVZGLpsaEc2T3KmGjLSDMjjPpO6yao1vwAAAIEAqlNLphpFEc0pN3HExYG6/i8zXl4tziQ+fBzE2EUA0jBPJbxzkW1AjuArDJBqrmW3vhQ4H9EB8BStVPi4bYpxm0AtMGK8KFUmF7J0wudIMWUKuN0tVjBiGnX4nmqzJj3BVBNvoWfLi/w5lwrTir32RkWyw9EUhQLix/MYa3jV6jQ= laforge at sunbeam.gnumonks.org
ssh-dss AAAAB3NzaC1kc3MAAAEBANaQAGtgd7Qsez1DeWNPY826lcw1RPAYoafWLAeWv42jSxx9UtHkhvuAzic0MCiAdytyufBD8O+k/gW8M+3G5n/clrRLWZg17KYItBPw0aRYWmJWuBGajwuMEwV33MUwg56eKr2OEjMWGQE9L9bQj3K8u1CnBDmx6HVl/8HlwWdC7g4TIuBHD76ZgusrPr5i318s/WusjJ527gKYbBK1g14/SG0az0Av4mwYMKIlF3Wramy5q3Iz+761yxdmK5oHYDbdiwRgGhbvFH276/G8ENog3h4DugvWN/uKgyJPq7TG7B84oO5dVAd4hWnVYlE4z055Qhf0kBnDk59x2lhFKNEAAAAVANvJ/guYzuobWZCLeIbia6QHXt27AAABAQDJtj2rmNQSYQaezlC1+s4qW4I1X8gBhYUzzwfCo1ljwUsvHC+yIP/704szK/QI+jbzbD2fph8CbMVx2RIoti30DrYTAGqxgj16YwOvaYt8ru/pz3jZjBQOlwfXLx1/Fl+0BCF2Emdpp+vq50iM2Il7ifczNMKn5JUksdXerQbQ5+xXOUhDhsm5VXL2/PH0xsQHIdJq3Aj/teS8m9osHSU6ox51q9pW46V9IltDeXFsuR4g4Xw+zHMRqSPjJ8AAGzofwzrJoMjvOGh3cpDVlqjLnGoYctgtBhQT5ZemKZ4O5yx+48crwZpGyImzigiYgi/rTyQIsow5z6QOyEQIwwh8AAABADaCjzwFT4mBbErno65vvHYY783tVsvzFqXBZGP7MIWmUq8ARrvXQXKEZVtEby0/X98A4TtkANHu8z5VwmKMi6/cMl7kL11RVhhzJ9SYvmyF+Pznmw+Fm++CI9k5lbqm6QVuM6D5v1pkgkmmvYjGMK6bQyHjw8wWDTjS35Wlfoqu7MMdAAbjdUEsFcP05zt0I3p3zkVChZILw6N5CA1+BXc3jDq123z/ui1lREFCcBDcHfBMf/llX7wHl/XrthLQuURYFRf9n1tf1ER5NYOWX+95MOwCkm8b5XwJQX3wNpr6Xeo4UkVCXMXlGX/Owry+IRoHkxCJ0DqoYD6W7Jval54= laforge at rama

[U-Boot-Users] How to patch u-boot?

[Stefan Roese]

Hi Harald,

On Monday 17 March 2008, Harald Welte wrote:
> > I really hope you are still willing to take over the s3c24xx U-Boot
> > custodianshipment. This would be a great improvement. If yes, please send
> > Wolfgang your public SSH key, so that he setup a new repository for the
> > Samsung ARM stuff.
>
> Yes, I am still willing to do this, and will be happy to help.

Thanks. This is really great news.

> > BTW: How should this repository be called? "u-boot-s3c24xx"? Or do you
> > have a different suggestion?
>
> That name is fine.
>
> Please find my SSHv2 keys (home and laptop) attached.
>
> Please also note that I'm still on holidays in Brasil until March 26th,
> so there will be no work before that time.

Understood. Make sure you enjoy the vacation and the nice weather, which will 
be no doubt be much nicer than here in Germany. :-)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] How to patch u-boot?

[Haavard Skinnemoen]

On Mon, 21 Jan 2008 20:36:13 +0100
Harald Welte <laforge@openmoko.org> wrote:

> 2) I have submitted two rounds of our patches (with about one year in
>    between those two instances), and I have the feeling that the
>    interest in even commenting to those patches was quite low.  This is
>    not very encouraging for further submissions.

[...]

> 2) Some of the changes, notably the sd/mmc driver for s3c24xx was
>    rejected by the u-boot list, since it just does what everyone else
>    does: no shared host controller code, just copy+paste the bits that
>    the other sd/mmc controllers do.

Hey, is that the thanks I get for actually commenting at your mmc
driver? I don't recall rejecting anything, nor do I have the power to
do so.

>    While I understand that there is a
>    need for a shared sd/mmc code, putting the burden of creating such
>    code on us is just too much.  With this kind of requirement you will
>    unlikely to see anyone merge another sd/mmc controller driver into
>    u-boot, since everyone evades creating the generic/common code. This
>    is not pure laziness, but inexperience with the code and lack of
>    access to all the different hardware

I did suggest that you move the MMC protocol definitions to a common
header file. That's not a huge task, but you could have said "no, I
don't want to do that right now. Maybe later." and it would have been
perfectly fine. Instead, you said "will do so in the next version of
the patch." But no next version of the patch ever showed up, despite
quite a few comments from others as well.

Of course, it would certainly be nice with a common mmc host controller
layer, but I certainly agree that placing that burden on you is
unreasonable. But IMO _suggesting_ that you do it is completely
different.

Btw, I find the "lack of hardware" argument a bit disturbing. Doing
some cleanups really shouldn't require anyone to have access to all the
affected hardware -- IMO much of the responsibility for testing that
nothing breaks on real hardware lies on the custodians and other users
that actually have access to the affected boards. But a few cross
toolchains are definitely required to verify that it actually compiles
on a handful of configurations before submitting.

Haavard

[U-Boot-Users] How to patch u-boot?

[Harald Welte]

On Tue, Jan 22, 2008 at 10:32:53AM +0100, Haavard Skinnemoen wrote:
 
> > 2) I have submitted two rounds of our patches (with about one year in
> >    between those two instances), and I have the feeling that the
> >    interest in even commenting to those patches was quite low.  This is
> >    not very encouraging for further submissions.
> 
> [...]
> 
> > 2) Some of the changes, notably the sd/mmc driver for s3c24xx was
> >    rejected by the u-boot list, since it just does what everyone else
> >    does: no shared host controller code, just copy+paste the bits that
> >    the other sd/mmc controllers do.
> 
> Hey, is that the thanks I get for actually commenting at your mmc
> driver? I don't recall rejecting anything, nor do I have the power to
> do so.

well, sorry.  But since there were no other significant comments, it was
sort of the most important/influential one.

> I did suggest that you move the MMC protocol definitions to a common
> header file. That's not a huge task, but you could have said "no, I
> don't want to do that right now. Maybe later." and it would have been
> perfectly fine. Instead, you said "will do so in the next version of
> the patch." But no next version of the patch ever showed up, despite
> quite a few comments from others as well.

well, obiously I try to implement the suggestions of the people on this
list, even if it means significant additional delays.  There is no point
in submitting the same stuff without implementing the comments from the
review.

> But IMO _suggesting_ that you do it is completely different.

Well, then I say 'thanks for the suggestion'.  In fact, I guess nobody
would ever object to the fact that 'yes, a common layer would be
better'.

> Btw, I find the "lack of hardware" argument a bit disturbing. Doing
> some cleanups really shouldn't require anyone to have access to all the
> affected hardware 

Well, the big issue is that most of those cleanups are deep down in the
low-level head.S/start.S initialization, affecting the ordering of how
PLL's are initialized, the resume-from-ram code paths, etc.

Thos can be very tricky, and especially with the level of documentation
that Samsung provides about chipset bugs (close to zero), it can be very
easy to break something on one chip without noticing.  They have done
things along the lines of re-defining the meaning of the same bits in
the same registers from 'pull-up' to 'pull-down' :)

> -- IMO much of the responsibility for testing that nothing breaks on
> real hardware lies on the custodians and other users that actually
> have access to the affected boards. 

> But a few cross toolchains are definitely required to verify that it
> actually compiles on a handful of configurations before submitting.

This would basically mean I had to know which toolchains other users of
boards using the existing 24xx support are using.

So far, there is
smdk2400
trab
mpl/vcma9
sbc2410x
smdk2410

Now for some of those products, there might be vendor-provided
toolchains that many people use.  For others, there isn't, and even if
there is, quite a number of people use their own stuff, or whatever
configuration of OpenEmbedded, or OpenWRT, or even something else.

Is there somewhere a list of the toolchains that the code has to compile
against, including pointers on where to obtain them?

And while we're at it,

I have working (and want to add) support for:
qt2410
smdk2440
neo1973/gta01
neo1973/gta02

In the future, I could potentially work on support for:
some TomTom GO models (they're all 2410/244x based)
smdk2443
smdk6400

Cheers,
-- 
- Harald Welte <laforge@openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone

[U-Boot-Users] How to patch u-boot?

[Haavard Skinnemoen]

On Tue, 22 Jan 2008 13:30:07 +0100
Harald Welte <laforge@openmoko.org> wrote:

> On Tue, Jan 22, 2008 at 10:32:53AM +0100, Haavard Skinnemoen wrote:

> > Hey, is that the thanks I get for actually commenting at your mmc
> > driver? I don't recall rejecting anything, nor do I have the power to
> > do so.
> 
> well, sorry.  But since there were no other significant comments, it was
> sort of the most important/influential one.

No problem. I just thought it was a bit funny that you first complained
about lack of comments, and then went on to complain that the comments
you _did_ get were too thorough ;-)

> > I did suggest that you move the MMC protocol definitions to a common
> > header file. That's not a huge task, but you could have said "no, I
> > don't want to do that right now. Maybe later." and it would have been
> > perfectly fine. Instead, you said "will do so in the next version of
> > the patch." But no next version of the patch ever showed up, despite
> > quite a few comments from others as well.
> 
> well, obiously I try to implement the suggestions of the people on this
> list, even if it means significant additional delays.  There is no point
> in submitting the same stuff without implementing the comments from the
> review.

Yes, I agree in general. But I also think it should be perfectly ok to
say "no, sorry, that's too much work at this point", although it may
start a discussion about whether it _really_ is too much work. You
should never silently ignore any comments, of course.

Review comments are really just suggestions about how to improve your
work further, but you shouldn't ignore them unless you have a good
reason to do so, and let the reviewer and other know.

> > Btw, I find the "lack of hardware" argument a bit disturbing. Doing
> > some cleanups really shouldn't require anyone to have access to all the
> > affected hardware 
> 
> Well, the big issue is that most of those cleanups are deep down in the
> low-level head.S/start.S initialization, affecting the ordering of how
> PLL's are initialized, the resume-from-ram code paths, etc.

There's mmc code down at that level...?

> Thos can be very tricky, and especially with the level of documentation
> that Samsung provides about chipset bugs (close to zero), it can be very
> easy to break something on one chip without noticing.  They have done
> things along the lines of re-defining the meaning of the same bits in
> the same registers from 'pull-up' to 'pull-down' :)

If you're talking about cleanups in general, then yeah, those low-level
bits can be quite fragile. I think the best you can do is to test it at
your own hardware and clearly state that your patch touches some tricky
low-level bits of code and needs testing.

If nobody steps up to test the code, I guess we have a problem. IMHO,
I'd say screw them and commit the patch anyway, after a reasonable
grace period. If it turns out to break something, you'll at least find
out which boards are properly maintained and which boards aren't.

> > -- IMO much of the responsibility for testing that nothing breaks on
> > real hardware lies on the custodians and other users that actually
> > have access to the affected boards. 
> 
> > But a few cross toolchains are definitely required to verify that it
> > actually compiles on a handful of configurations before submitting.
> 
> This would basically mean I had to know which toolchains other users of
> boards using the existing 24xx support are using.

U-boot is supposed to compile with standard toolchains isn't it?

Sometimes it doesn't, but that may be an interesting piece of
information on its own, which you should report to the mailing list.

Yeah, I know, avr32 currently requires a vendor-supplied toolchain, but
we are working on getting it upstream (honest!) and because of this, we
really don't expect people to do compile-testing with the avr32
toolchain.

> Is there somewhere a list of the toolchains that the code has to compile
> against, including pointers on where to obtain them?

I have a standard ARM toolchain and a standard ppc toolchain, both
compiled from the Ubuntu gcc-4.2 sources. Those two architectures cover
a lot of configurations, so I'd expect them to uncover the vast
majority of problems with a patch.

ppc is currently broken though, since nobody seems to be interested in
merging my one-line fix...

Haavard

[U-Boot-Users] How to patch u-boot?

[Wolfgang Denk]

In message <20080122123007.GK706@prithivi.gnumonks.org> you wrote:
>
> Is there somewhere a list of the toolchains that the code has to compile
> against, including pointers on where to obtain them?

If you use ELDK 3.1.1 and ELDK 4.<latest> you will be able  to  cover
ARM,  MIPS  and  PowerPC;  this  should  bring up most of the serious
issues... Others will then do the rest ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Wish not to seem, but to be, the best."                  - Aeschylus

[U-Boot-Users] How to patch u-boot?

[Tiju]

Hi

Could 
someone 
help 
me 
out 
with 
patching 
the 
u-boot.
I 
downloaded 
the 
source 
code 
of 
u-boot-1.1.6 
and 
untared 
it. 
Then 
I 
do 
a 
$cd 
u-boot-1.1.6
$svn 
co 
http://svn.openmoko.org/trunk/src/target/u-boot/patches/
$patch 
<patches/boot-menu.patch
patching 
file 
bootmenu.c
can't 
find 
file 
to 
patch 
at 
input 
line 
154
Perhaps 
you 
should 
have 
used 
the 
-p 
or 
--strip 
option?
The 
text 
leading 
up 
to 
this 
was:
--------------------------
|Index: 
u-boot/board/neo1973/gta01/gta01.c
|===================================================================
|--- 
u-boot.orig/board/neo1973/gta01/gta01.c
|+++ 
u-boot/board/neo1973/gta01/gta01.c
--------------------------
File 
to 
patch:


This 
is 
what 
comes....
Is 
this 
the 
way 
to 
do 
it? 
If 
not 
please 
help 
me 
with 
the 
steps 
to 
be 
followed.

Thankyou
Tiju 
Jacob




      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

[U-Boot-Users] How to patch u-boot?

[Tiju]

Hi

Could 
someone 
help 
me 
out 
with 
patching 
the 
u-boot.
I 
downloaded 
the 
source 
code 
of 
u-boot-1.1.6 
and 
untared 
it. 
Then 
I 
do 
a 
$cd 
u-boot-1.1.6
$svn 
co 
http://svn.openmoko.org/trunk/src/target/u-boot/patches/
$patch 
<patches/boot-menu.patch
patching 
file 
bootmenu.c
can't 
find 
file 
to 
patch 
at 
input 
line 
154
Perhaps 
you 
should 
have 
used 
the 
-p 
or 
--strip 
option?
The 
text 
leading 
up 
to 
this 
was:
--------------------------
|Index: 
u-boot/board/neo1973/gta01/gta01.c
|===================================================================
|--- 
u-boot.orig/board/neo1973/gta01/gta01.c
|+++ 
u-boot/board/neo1973/gta01/gta01.c
--------------------------
File 
to 
patch:


This 
is 
what 
comes....
Is 
this 
the 
way 
to 
do 
it? 
If 
not 
please 
help 
me 
with 
the 
steps 
to 
be 
followed.

Thankyou
Tiju 
Jacob





      Forgot the famous last words? Access your message archive online@http://in.messenger.yahoo.com/webmessengerpromo.php

[U-Boot-Users] How to patch u-boot?

[Andreas Schweigstill]

Hello!

Tiju schrieb:
> Could 
> someone 
> help 
> me 
> out 
> with 
> patching 
> the 
> u-boot.

Do you really think this is funny?

And why don't you follow the hint given by the patch program? It
already told you what to do.

Cross-posting to several mailing lists and also to the maintainers
is also not acceptable. Didn't you read any publications about
Usenet netiquette?

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] How to patch u-boot?

[Tiju]

Hi

Could someone help me out with patching the u-boot.
I downloaded the source code of u-boot-1.1.6 and untared it. Then I do a 
$cd u-boot-1.1.6
$svn co http://svn.openmoko.org/trunk/src/target/u-boot/patches/
$patch <patches/boot-menu.patch
patching file bootmenu.c
can't find file to patch@input line 154
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: u-boot/board/neo1973/gta01/gta01.c
|===================================================================
|--- u-boot.orig/board/neo1973/gta01/gta01.c
|+++ u-boot/board/neo1973/gta01/gta01.c
--------------------------
File to patch:


This is what comes....
Is this the way to do it? If not please help me with the steps to be followed.

Thankyou
Tiju Jacob




      Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php

[U-Boot-Users] How to patch u-boot?

[Harald Welte]

On Fri, Jan 18, 2008 at 03:54:29PM +0530, Tiju wrote:
> Hi
> 
> Could someone help me out with patching the u-boot.
> I downloaded the source code of u-boot-1.1.6 and untared it. Then I do a 
> $cd u-boot-1.1.6
> $svn co http://svn.openmoko.org/trunk/src/target/u-boot/patches/

those patches are against current git head of u-boot.  What gave you the
assumption that the patches are agains 1.1.6?

-- 
- Harald Welte <laforge@openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone