[U-Boot] {Spam?} u-boot-usb DFU working but need some ideas
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
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 :
- I start u-boot
- I issue the dfuinit command (new)
- 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
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 :
- I start u-boot
- I issue the dfuinit command (new)
- 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
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
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 :-) ).
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
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
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
participants (3)
-
Detlev Zundel -
Marcel -
Wolfgang Denk