[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Marcel]

Hi,

I finally got things working well with my SAM9G45 USB devcie controller and 
continued to implement DFU for it. 
I implemented it using the new gadget layer and should be compatible with the 
at91_udc driver.

I have managed to get DFU working in such way that it transfers the file to 
RAM.  There's still a lot to do, but most things are in place and working 
well. Basically after transfer to RAM,  a u-boot script can handle additional 
actions, so I'm in doubt about the following :

The DFU implementation I used as a basis came from openmoko. This implements 
directly flashing the device.
However, my thought is that it's much better to just write the file to RAM and 
let a script in u-boot handle what should happen with it (verify, boot, flash)
The DFU spec seems to handle this with the bitManifestationTolentant bit, but 
the current dfu-utils don't use this bit (that can be updated of course, which 
I already did).

About the way it currently works :
1) I start u-boot
2) I issue the dfuinit command (new)
3) the host can now download a file to RAM.
Any thoughts on what would be the most preferred way to do this ?

Additionally I think I will implement this as a composite driver so that both 
(usb)CDC and DFU are available via USB. I have both working, but currently 
must select it at compile time.
My current implementation basically is just DFU as it assumes the application 
(not u-boot) to be the firmware to be updated, so no need to switch on 
descriptor layer level.

Any reply on this would be nice, even if my above thoughts are in line.
I hope to be able to post my changes in 1-2 weeks. After that my time is 
extremely limited due to long time travel. If anyone is interested in helping 
me out posting the changes it would be very much appreciated.

Best regards,
Marcel

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Detlev Zundel]

Hi Marcel,

> I finally got things working well with my SAM9G45 USB devcie controller and 
> continued to implement DFU for it. 
> I implemented it using the new gadget layer and should be compatible with the 
> at91_udc driver.

Excellent, congratulations!

> I have managed to get DFU working in such way that it transfers the file to 
> RAM.  There's still a lot to do, but most things are in place and working 
> well. Basically after transfer to RAM,  a u-boot script can handle additional 
> actions, so I'm in doubt about the following :
>
> The DFU implementation I used as a basis came from openmoko. This implements 
> directly flashing the device.
> However, my thought is that it's much better to just write the file to RAM and 
> let a script in u-boot handle what should happen with it (verify, boot, flash)
> The DFU spec seems to handle this with the bitManifestationTolentant bit, but 
> the current dfu-utils don't use this bit (that can be updated of course, which 
> I already did).

I am not too familiar with the DFU spec, but I agree with regards to the
scripting.  I can envision usage scenarios where the downloaded files
are written to other storage media, so I would much rather leave that up
to the U-Boot script interpreter.

> About the way it currently works :
> 1) I start u-boot
> 2) I issue the dfuinit command (new)
> 3) the host can now download a file to RAM.
> Any thoughts on what would be the most preferred way to do this ?

This sequence sounds absolutely feasible.  What exactly is your
question?

> Additionally I think I will implement this as a composite driver so that both 
> (usb)CDC and DFU are available via USB. I have both working, but currently 
> must select it at compile time.
> My current implementation basically is just DFU as it assumes the application 
> (not u-boot) to be the firmware to be updated, so no need to switch on 
> descriptor layer level.
>
> Any reply on this would be nice, even if my above thoughts are in line.
> I hope to be able to post my changes in 1-2 weeks. After that my time is 
> extremely limited due to long time travel.

I'm really looking forward to getting DFU support into U-Boot - having
lobbyied for it quite a while :)

> If anyone is interested in helping me out posting the changes it would
> be very much appreciated.

What help do you need?

Cheers
  Detlev

-- 
Emacs seems a more likely candidate  to contain a mail system than the
mail system to contain an Emacs, so this is the way it was done.
                                            -- Bernard S. Greenberg
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Marcel]

Hi Detlev,

> I am not too familiar with the DFU spec, but I agree with regards to the
> scripting.  I can envision usage scenarios where the downloaded files
> are written to other storage media, so I would much rather leave that up
> to the U-Boot script interpreter.

I did create a new command "dfu" that activates the controller and DFU.
I than used the GPBR register of the AT91 to make u-boot know that it has to 
activate DFU by script. Basically the value of the GPBR register either tells 
u-boot to wait for TFTP or DFU ways to upgrade.
 
> > About the way it currently works :
> > 1) I start u-boot
> > 2) I issue the dfuinit command (new)
> > 3) the host can now download a file to RAM.
> > Any thoughts on what would be the most preferred way to do this ?
> 
> This sequence sounds absolutely feasible.  What exactly is your
> question?

Since I wasn't familiar with DFU either I asked. I implemented it basically on 
the go, so while I was reading the spec. Along the way I found some items 
which I found not very logical for u-boot.
DFU states that the device should expose the normal descriptors + a DFU 
descriptor. I don't do that in my application. Instead I have another way to 
reset my application and tel u-boot to go in DFU mode. I however implemented 
the DFU driver in u-boot such way that it does work with dfu-utils without any 
issues.

Also I upload the full application to RAM first before storing it in NAND. On 
my board this has some limits. The RAM is 128M and NAND 256M, so I can not 
flash the whole NAND yet. The Openmoko driver implements a method that allows 
that, which can be added later of course.

I tested it the whole week and use it now as my main way to upgrade my 
application. Haven't seen it fail once so far, so it looks good.

> > Additionally I think I will implement this as a composite driver so that
> > both (usb)CDC and DFU are available via USB. I have both working, but
> > currently must select it at compile time.
> > My current implementation basically is just DFU as it assumes the
> > application (not u-boot) to be the firmware to be updated, so no need to
> > switch on descriptor layer level.
> > 
> > Any reply on this would be nice, even if my above thoughts are in line.
> > I hope to be able to post my changes in 1-2 weeks. After that my time is
> > extremely limited due to long time travel.
> 
> I'm really looking forward to getting DFU support into U-Boot - having
> lobbyied for it quite a while :)

Great. I hope I can post it and that it will be maintained. It really is a 
nice feature I think.
 
> > If anyone is interested in helping me out posting the changes it would
> > be very much appreciated.
> 
> What help do you need?

I'm on a real deadline for my project. I have to go on business trip end of 
next week and very limited in time. I finished u-boot for my companies products 
and I can post a full diff of it. I was hoping someone could help me out 
testing the patch on their board (either sam9g45 or using at91_udc ) and help 
me to post the changes to u-boot.
I can also post a full diff the the forum, but it's rather large I think. I 
never posted changes before, so I have no idea yet how to do it. I know 
there's reading info about it, but had no time yet to look into it (shame on 
me :-) ).

Best regards,
Marcel

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Wolfgang Denk]

Dear Marcel,

In message <201102100846.49072.korgull@home.nl> you wrote:
> 
> I did create a new command "dfu" that activates the controller and DFU.
> I than used the GPBR register of the AT91 to make u-boot know that it has to 
> activate DFU by script. Basically the value of the GPBR register either tells 
> u-boot to wait for TFTP or DFU ways to upgrade.

Hm... Please keep in mind that DFU support is supposed to be
completely hardware independent - it should not only work on AT91
systems, and not even be restricted to ARM, but instead be usabel on
all architectures and boards.

> I'm on a real deadline for my project. I have to go on business trip end of 
> next week and very limited in time. I finished u-boot for my companies products 
> and I can post a full diff of it. I was hoping someone could help me out 

I'm not sure what you mean by "full diff". If you think about posting
all your changes in a single patch, then please don't.  You have to
split the stuff into independent parts - DFU support is then just one
patch in your patch series.

> testing the patch on their board (either sam9g45 or using at91_udc ) and help 
> me to post the changes to u-boot.

Thn it is all the more important to correctly split your changes into
independent (orthogonal) patches.

> I can also post a full diff the the forum, but it's rather large I think. I 
> never posted changes before, so I have no idea yet how to do it. I know 
> there's reading info about it, but had no time yet to look into it (shame on 
> me :-) ).

see http://www.denx.de/wiki/U-Boot/Patches

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
The typical page layout program is nothing more  than  an  electronic
light table for cutting and pasting documents.

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Marcel]

Dear Wolfgang,
 
> In message <201102100846.49072.korgull@home.nl> you wrote:
> > I did create a new command "dfu" that activates the controller and DFU.
> > I than used the GPBR register of the AT91 to make u-boot know that it has
> > to activate DFU by script. Basically the value of the GPBR register
> > either tells u-boot to wait for TFTP or DFU ways to upgrade.
> 
> Hm... Please keep in mind that DFU support is supposed to be
> completely hardware independent - it should not only work on AT91
> systems, and not even be restricted to ARM, but instead be usabel on
> all architectures and boards.

The GPBR is optional in my code. I just use it because it's the nicest 
solution for me over the following options :
1) access my NOR flash to Linux and use env variables.
2) read my eeprom in u-boot.
On any other boards the code should work as well, although I can't test it. I 
fully complied to the use of the new USB layer as ether.c does. If ether.c 
should work on a board, so would DFU I think.
When I post the patches, I'll add a readme for DFU, so that the current 
implementation is clear. It has some restriction due to my time limitation, 
but is basically 100% according spec and works with standard dfu-utils.
There are things 'todo' to make it nicer, but what code is 100% finished the 
first commit :-)

> > I'm on a real deadline for my project. I have to go on business trip end
> > of next week and very limited in time. I finished u-boot for my
> > companies products and I can post a full diff of it. I was hoping
> > someone could help me out
> 
> I'm not sure what you mean by "full diff". If you think about posting
> all your changes in a single patch, then please don't.  You have to
> split the stuff into independent parts - DFU support is then just one
> patch in your patch series.

Do you mean separate patches to add for example the sam9g45 USB controller and 
another patch to add DFU and another one to add my board ?
It does make sense to that, I just wonder how to generate those patches......
I know which files I want to include in separate patches, but how do I do that 
?

Mostly I added new files, so I guess it shouldn't be too difficult.
I will add README.dfu to explain what I implemented, what is optional and what 
can be added in the near future.

> > testing the patch on their board (either sam9g45 or using at91_udc ) and
> > help me to post the changes to u-boot.
> 
> Thn it is all the more important to correctly split your changes into
> independent (orthogonal) patches.
>
> > I can also post a full diff the the forum, but it's rather large I think.
> > I never posted changes before, so I have no idea yet how to do it. I
> > know there's reading info about it, but had no time yet to look into it
> > (shame on me :-) ).
> 
> see http://www.denx.de/wiki/U-Boot/Patches

Thanks again. I read most of it and try posting it like that. It does look 
like I'll be reading the git manual again.

Best regards,
Marcel

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Wolfgang Denk]

Dear Marcel,

In message <201102102015.59437.korgull@home.nl> you wrote:
>
> The GPBR is optional in my code. I just use it because it's the nicest 
> solution for me over the following options :

I haven't seen your code yet, so I may misunderstand what you are
actually referring to, but from what it sounds I think that should
not be optional, but strictly separate from the DFU code.

> Do you mean separate patches to add for example the sam9g45 USB controller and 
> another patch to add DFU and another one to add my board ?

Yes.

> It does make sense to that, I just wonder how to generate those patches......
> I know which files I want to include in separate patches, but how do I do that 
> ?

Normally you do this when developing the code.

If you already have alltogehter as a huge pile of a mess, then you
will have to go thtrough splitting this up.  Either completely
manually (ouch...) or by using git's interactive capabilities - for
example, "git add --interactive" can be used to select even single
lines from hunks of changes into the next commit.

Yes, this is a painful work, but it needs to be done to make your code
acceptable for mainline.

> Thanks again. I read most of it and try posting it like that. It does look 
> like I'll be reading the git manual again.

Well, I have to look up certain details again and again, and I do not
hesitate to refer to certain cheat sheets either when I have to
perform non-trivial actions.

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
The universe, they said, depended for its operation on the balance of
four forces which they identified as charm,  persuasion,  uncertainty
and bloody-mindedness.      -- Terry Pratchett, "The Light Fantastic"

[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Marcel]

Hi Wolfgang,

> In message <201102102015.59437.korgull@home.nl> you wrote:
> > The GPBR is optional in my code. I just use it because it's the nicest
> 
> > solution for me over the following options :
> I haven't seen your code yet, so I may misunderstand what you are
> actually referring to, but from what it sounds I think that should
> not be optional, but strictly separate from the DFU code.

It is separate or I will make sure it is when I post it.
 
> > Do you mean separate patches to add for example the sam9g45 USB
> > controller and another patch to add DFU and another one to add my board
> > ?
> 
> Yes.

OK.

> > It does make sense to that, I just wonder how to generate those
> > patches...... I know which files I want to include in separate patches,
> > but how do I do that ?
> 
> Normally you do this when developing the code.

Than I just check out a new u-boot-usb and port my code in there in order of 
the patches. It sounds not very difficult and at least makes sure I have several 
patches created the way it should.

> If you already have alltogehter as a huge pile of a mess, then you
> will have to go thtrough splitting this up.  Either completely
> manually (ouch...) or by using git's interactive capabilities - for
> example, "git add --interactive" can be used to select even single
> lines from hunks of changes into the next commit.
> 
> Yes, this is a painful work, but it needs to be done to make your code
> acceptable for mainline.

Understood.
I will go for the manual way as I didn't do much changes to the existing u-
boot code anyway. It's a fairly clean implementation so I should be finished 
with in a couple of hours I think.

I'll post the items this weekend. 

Thanks for all the help so far,
Marcel