Re: [U-Boot] Mini Summit 2014 Followup / Transcript of Open Discussion
Hello Michal, Hi Detlev On 10/17/2014 05:02 PM, Detlev Zundel wrote: Hi, it was a pleasure for me to meet so many of you this Monday in Düsseldorf at the ELCE. As many as 17 current custodians and 2 prospective new custodians were present at the event: Hans de Goede - Sunxi Alexey Brodkin - ARC Marek Vasut - USB Scott Wood - NAND Joe Hershberger - Networking Anatolij Gustschin - Video Heiko Schocher - I2C Stefano Babic - ARM i.MX Stefan Roese - PowerPC 4xx, CFI flash Wolfgang Denk - PowerPC 8xx, 82xx, 85xx, 5xxx, 7xx, 74xx Lukasz Majewski - DFU, OneNAND Tom Rini - Master of the git tree Pantelis Antoniou - MMC Daniel Schwierzek - MIPS Masahiro Yamada - Uniphier, Kconfig / Kbuild Simon Glass - x86, Driver model, patman, buildman Nobuhiro Iwamatsu - SH architecture Vince Bridgers - SoCFPGA (soon) Przemyslaw Marczak - PMIC (soon) Not for full day but + Michal Simek - Microblaze architecture, ARM Zynq Thanks for adding yourself in - the names above were the custodians present during the introductory part so very likely you were not there from the beginning. [...] The page is topped with a picture of the participants of the discussion round in the evening. I started adding the names of the people that gave me explicit approval to do so but I would like to extend this list somewhat further. Whenever there is an NA without a question mark, then I know the name and will fill it in when I get the approval. If there is a question mark behind it then I'm unsure and would be glad to get some help _in addition_ to the approval ;) Feel free to identify me. Thanks, done. As promised, here are my notes that I took during the evening discussion - feel free to follow-up on individual items by cutting out the rest of the mail: 8-8- * Open Discussion ** ARM core vs ARM SoC custodianship Collection of patches should go to mainline in one bunch, rather than splitting them for every custodian repository. Individual custodians can ack parts of such a series. This should be the default - custodians should only pick up individual bits when those bits are pretty isolated. I don't think this was an agreement to be honest. I tried to use the word should and not must to allow for case by case decisions, but I think there was an agreement on the direction of the proposal. Merge early and merge often is golden rule for new SoCs. None is simply working on NAND when you don't have core SoC support or serial console. It means preferred way is to merge sensible patch series from start and then extend it to the drivers exactly how you do your SoC bringup. If you have bigger series touching some areas you need to get ack from custodian or you can be asked to split that series. I believe we are in sync here. Best wishes Detlev -- (7) It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three). -- The Twelve Networking Truths (RFC 1925) -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Mini Summit 2014 Followup / Transcript of Open Discussion
and be used more. Once -rc1 is released, things can then be pulled into the next branch. Only bug fixes should go into the later -rc's. ** Custodian expectations It seems Albert doesn't like to pull from topic branches, so maybe simply do not offer topic branches for him to pull. 8-8- PS: There were a few people taking pictures at the event and I'm certainly interested to see them. So if possible, send them over to me personally. Thanks to everyone! Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New discussion proposal for u-boot summit: switch malloc to succeed or die model, as glib does
Hi Hans, Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches. Ian asked me to add error handling for mmc_create failing, which, if used properly, only ever fails if calloc fails. This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a die() / abort() inside the low level malloc routines when they fail. The reasoning is that if malloc fails, you're typically looking at a fatal error anyways, and this will allow removing error handling from a lot of higher level users, reducing code, and removing a lot of code paths which are in essence unused and as such also very much untested. I guess there may be some special cases where we don't want the malloc_or_die behavior I'm advocating for, for those we could introduce a malloc_unchecked function. Detlev any chance you could squeeze this into the schedule somewhere? I'll note it for the list of things to discuss in the discussion round in the evening. Cheers Detlev -- (let ((s bottles of beer on the wall)) ((lambda (f) (f f 99)) (lambda (f i) (or (= i 0) (format #t ~a ~a - take one down pass it around ~a ~a\n i s (- i 1) s) (f f (- i 1)) -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Mini Summit
Hi Alexey, Hi Detlev, On Tue, 2014-10-07 at 11:38 +0200, Detlev Zundel wrote: Hello Masahiro-san, [...] Perhaps, is it better to insert 5-minute break between talks? Speakers might need to get something prepared. (connecting their laptop to the beamer, etc.) Of course. I did not explicitely include this in the agenda, but such a 5 minute break is what I'll strive to maintain. I would even propose to have a backup setup for slides presentation. I fully agree and it is already in the works. I remember I once tried to use a beamer attached to my Fedora-driven laptop and didn't succeed with that. Moreover new gen laptops may only have like mini-DisplayPort output instead of VGA so there's a probability some laptops won't have a chance to be connected to existing (not that advanced/modern) beamer. Indeed. So given you guys have all presentations beforehand (I believe in for of PDFs) would be good to have an ability to display them if my laptop refuses to work with beamer again. If one laptop fails then we still have enough redundancy to make it happen :) Cheers Detlev -- Once the implementation is up and running, it is still a trick to keep it running. In a normal, closed implementation, this is not a problem; in a system with metaobject protocols [..] there is the potential for spectacular failure modes if certain situations are not properly anticipated. -- The Art of the Metaobject Protocol -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Mini Summit
Hi Albert, [...] I would have liked to attend, but for personal reasons could not free myself up. That's of course unfortunate. Is there any possibility of a Google Hangout or anything similar? To be honest - I have no idea how to do this or if this is feasible. Last year Marek volunteered to try it, but it did not work out. IIRC the conference WiFi wasn't stable enough to do that. Is anyone (who also attends) willing to try setting up such a Google Hangout this year again? Best wishes Detlev -- Be careful in casting out your devil 'lest you cast out the best thing about you. -- Friedrich Nietzsche -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Mini Summit
Hello Masahiro-san, [...] Perhaps, is it better to insert 5-minute break between talks? Speakers might need to get something prepared. (connecting their laptop to the beamer, etc.) Of course. I did not explicitely include this in the agenda, but such a 5 minute break is what I'll strive to maintain. Bets wishes Detlev -- A change in language can transform our appreciation of the cosmos -- Benjamin Lee Whorf -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Alexey, thanks a lot for your willingness to do the presentation at the mini summit. As I personally thik your talk fits our agenda pretty well and nobody has said anything different, it is therefore accepted. Currently I plan for 20 minutes / 10 minutes QA slots, would this be ok for your talk also? Do you guys want to get my presentation beforehand or I may just bring it with me? It would be good to send a copy of the presentation beforehand just in case something breaks. Believe me - _something_ will ;) Cheers Detlev -- It's nice that the students coming to us already know Java. We just have to teach them how to program. -- Michael Sperber -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot Mini Summit
Hi, the agenda for the U-Boot Mini Summit in a few days in Düsseldorf has now been finalized[1]. It is very encouraging to see such a lot of high-class content and I'm very excited to also meet a lot of new people. Please note that we would like to have as many custodians present as possible at 11:15 so that we can have a short round of introductions. I'm sure it will be a very pleasant experience to match names with faces known only from the mailing list so far :) Also note that the agenda allows everybody to attend Toms talk Redundant booting with U-Boot at 16:30[2] and of course it has no chance to collide with Mareks talk Secure and flexible boot with U-Boot on Wednesday at 15:30[2]. Thanks for all the input so far and I'm looking forward to seeing you all in a few days! Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 [2] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/schedule -- It's nice that the students coming to us already know Java. We just have to teach them how to program. -- Michael Sperber -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Git reorganization
Hi, our last git update on git.denx.de last friday caused some minor problems pushing to repositories created already years ago. We hope to have fixed all the problems that we observered in a manner transparent to all users, but if you still have any problem, be sure to complain loudly to me and I'll see what I can do. Sorry for any inconvenience this may have caused Detlev -- Old mathematicians never die; they just lose some of their functions. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi, [...] I will be in U-Boot mini summit 2014. Excellent! I am thinking about giving a talk on Kbuild and Kconfig. Kbuild - I think it is already stable enough, but I'd like to have a quick review of the big change we had in U-Boot in the past year. Kconfig - We have just switched to Kconfig. I will explain how Kconfig was adjusted for U-Boot and why the current approach was chosen and then what will happen in the next phase. BTW, I am not good at talking. Nor am I good at English. (I hope my presentation won't be a disaster...) But I'd like to challenge a new thing. Could you bear with me during a 20min slot? Actually I had a slot reserved for you already ;) Best wishes Detlev -- ... does Linux have a better [security] track record than MS? Damn right it does. We've had fewer problems, and I think there are more people out there standing up for what's right anyway. Less PR people deathly afraid of rocking the boat. Better technology, and fewer horrid design mistakes. [Linus Torvalds] -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Lukasz, [...] btw. Tom etc., do we have some list of talks for the minisummit or some program for it available somewhere ? When is the deadline for CFP ? I would also like to pose this question. Is there any ongoing work on the minisummit schedule? Yes, I'm collecting all information and will push it to the wiki. Best wishes Detlev -- Man gelangt nicht dazu, gluecklich zu sein, aber man macht Feststellungen ueber die Gruende, die uns daran hindern es zu sein. -- Marcel Proust -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Marek, [...] I got my talk, Secure and flexible boot with U-Boot bootloader, accepted for the main track it seems. It's mostly about use fitImage and use UBI on NAND kind of talk, which covers introduction to fitImage and storing system components on UBI/UBIFS to prevent problems like silent data corruption on modern systems. Excellent! That being said, I believe I won't be able to cover the fitImage verified boot part properly, so I might as well cook a talk for the u-boot summit about this advanced topic. We had a talk about that exact topic last year on the main track by Simon and in the mini summit by Jagan Teki[1]. In what respect will your talk differ from that? Thanks Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2013 -- Milk? called Reg. Er, please. One lump or two? One, please. Sugar? Dirk Gently's Holistic Detective Agency, Douglas Adams -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Lukasz, [...] I'd like to share with the u-boot mailing list the proposal of my talk for u-boot's Mini summit in the ELCE2014. Thanks a lot for the proposal. __Mainline u-boot for Tizen 3.0 - “war story”__ Abstract: Utilization of u-boot bootloader at Samsung's Linux powered platforms has a long history. For Tizen 3.0 the reference devices for mobile profile (RD_PQ and Odroid U3/X2) are due to run with u-boot developed with open source philosophy applied. It means that the code was developed, reviewed and tested first in the open source and then reused in Tizen. Introduced changes to mainline code were minimal and only necessary for assuring backward compatibility. In his presentation Lukasz will briefly cover history and future plans of u-boot development for Tizen (as e.g. ongoing work on single binary for Odroid U3 and M0), explain key aspects of persuading community to accept solutions tunned for mobile devices, present remarkable u-boot's “war stories” and give a handful of tips for successful cooperation with community. I would need around 25 minutes for talk and 5 more for discussion. I really appreciate such a war story talk. Actually I tried nudging a lot of people to do such a thing but until now without any success - so I'm all the more happy to see it finally appear. I guess it will be very instructive to share such inside experience on how to integrate a decentralized open source component in a professional work flow. Such procedures have materialized around the Linux kernel, but the situation is not so clear in the bootloader area that has traditionally seen a lot of fire and forget strategies. As I did not see any negative reaction to that talk, I'd say the talk is accepted. Best wishes Detlev -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other to total extinction. Let us pray, we have the wisdom to choose correctly. -- Woody Allen -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mini summit talk proposal: Getting SoC vendors to work with upstream u-boot
Hi Hans, I would to give a talk (more an intro to a group wide discussion) on how to get (more) manufacturers engaged in upstreaming their work / working directly with upstream from day one. This is very welcome indeed, thanks! My own experience in this lies with the Allwinner sunxi support, where Allwinner themselves are shipping a quite old u-boot, which is not even fully functional as it gets chainloaded by a custom loader which sets up RAM first. Thanks to the work of various people in the community we've a fully functional u-boot (replacing the custom loader) for sun4i, sun5i and sun7i. But we are still e.g. waiting for someone to get sun6i support in place. This is not good, so I would like to give a talk with some proposals to (try to) get more manufacturers working with upstream, and then have a discussion on this. Sounds very good to me. Biography: Hans has been a Linux developer since 1996, working on a wide variety of projects, lots of Fedora packaging work, writing various hwmon kernel drivers, (re)writing many webcam drivers, writing libv4l, various usb kernel work, libusb maintainership, Allwinner sunxi kernel and u-boot work. Since 2008 Hans works for Red Hat, besides continuing all the FOSS work he did before, at Red Hat he has worked on anaconda the Fedora / Red Hat installer, parted (the partition tool), Spice and usb-redirection under qemu, and currently he works on the input stack for wayland and new touchpad support for the kernel. I reserved a 30 minutes time slot for you on our wiki[1]. Best wishes Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 -- I've been examining the existing [linux] kernel configuration system, and I have about concluded that the best favor we could do everybody involved with it is to take it out behind the barn and shoot it through the head. -- Eric S. Raymond on linux-kbuild Mar 2000 -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Requesting a custodian tree for sunxi (Allwinner) maintenance
Hi Ian, Hans and I would like to propose the creation of a uboot-sunxi.git custodian tree for things relating to the Allwinner platforms. It would be a downstream of uboot-arm.git tree with responsibility for it shared between us. This was previously mentioned on list[0] but we figured it deserved it's own thread. I have attached the public half of a fresh ssh key generated for this purpose. Hans, you should follow up with yours. A fresh repo has been setup with this key[1]. Let me know if you have any problems. Best wishes Detlev [1] http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=summary -- Those who do not understand Unix are condemned to reinvent it, poorly. - Henry Spencer, University of Toronto Unix hack -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] socfpga: Relocate arch common functions away from board
Hi Chin, To move the arch common function away from board folder to arch/arm/cpu/armv7/socfpga folder. Its to avoid code duplication for other non Altera dev kit which is using socfpga device. This looks like a good first step. I'm sure that followup patches are neccessary to clean up the division between generic and board specific patches, but we'll see this once other boards (like socrates) are added. Pavel, can you rebase your intended change on this? Thanks! Acked-by: Detlev Zundel d...@denx.de -- A change in language can transform our appreciation of the cosmos -- Benjamin Lee Whorf -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target
Hi Chian, Hi guys, On Fri, 2014-05-30 at 11:41 +0200, Detlev Zundel wrote: Hi Pavel, On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote: In message 20140528124910.ga24...@amd.pavel.ucw.cz you wrote: There are no differences between EBV socrates and socfpga boards, currently. Well, for one thing, the board vendor and the board name differ... I meant from current code in u-boot point of view... But as we all agree, this may change quickly and for multiple boards. Yup, some other board vendors are using different HW configuration. Some of the difference are Altera dev kit have EEPROM and using Micrel PHY for EMAC. I presume Socrates board should have their own board path such as board/socrates/socfpga. We are using a board/vendor scheme, so it should be board/ebv/socrates, but otherwise we agree. AFAICT, one solution would be to put - in that column, and do git mv board/altera/ board/socfpga/. Putting - in the vendor column just doesn't feel right. That's what mx6 did, AFAICT. I think Detlev is right here. We do have specific board vendors directories, and there are a number of reasons to keep this used (just to give one example: say a vendor wants to use a similar look and feel for the default environment settings etc. for all boards). If there is code which is identical for several (or all?) boards we should ask ourself if it really belongs into the board/ directory at all? That might be the case. It seems that current code in board/altera is SoC-specific, as it works on both Altera and EBV boards. Then we are in agreement that it does not belong below board/ ;) Within board/altera, there are 2 types of files as below: 1. HW configuration handoff files (such as pinmux_config, pll_config). Pinmux might be different as certain board might have different routing (normally to optimize the board layout and shorter PCB trace length). 2. Board specific code (socfpga_cyclone5.c) These functions include board_init, board_early_init, checkboard. I believe that the function print_cpuinfo and overwrite _console should goto arch/arm/cpu/armv7/socfpga/misc.c. I will create the patch to change this later (as I already did this at rocketboard.org). Thanks in advance! Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go. I think board/altera as such makes sense, with Altera being the vendor of that specific board. However, if there is common code there, this code should be moved out of board/ . It seems there's currently 99.99% of SoC-specific code there. What would be the right place for that code? Depends on what exactly it implements. Apart from that we can also take a look at where the code is in a Linux tree and take that as an example. After all, we want people developing the Linux kernel to also feel at home in the U-Boot sources. arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific. drivers/misc ? Do we need to make a soc/ directory? We have arch/arm/imx-common for example, but I'm not so sure if this is a good approach. Maybe there is not a _single_ correct place, but we have to distribute the files to multiple directories? And then... who does the move? It is not going to make merging between rocketboards.org and mainline even trickier than it already is :-(. This is a good question and we should certainly not answer it lightly. Usually we care only to a certain degree for non-mainline code, though. Blocking ourselves because of non-mainline code would allow external control which I think is not really helpful for the project. As above, I can move some common function to arch/arm/cpu/armv7/socfpga/misc.c. Sounds good. Thanks Detlev -- A statistician can have his head in an oven and his feet in ice, and he will say that on the average he feels fine. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target
Hi Pavel, On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote: In message 20140528124910.ga24...@amd.pavel.ucw.cz you wrote: There are no differences between EBV socrates and socfpga boards, currently. Well, for one thing, the board vendor and the board name differ... I meant from current code in u-boot point of view... But as we all agree, this may change quickly and for multiple boards. AFAICT, one solution would be to put - in that column, and do git mv board/altera/ board/socfpga/. Putting - in the vendor column just doesn't feel right. That's what mx6 did, AFAICT. I think Detlev is right here. We do have specific board vendors directories, and there are a number of reasons to keep this used (just to give one example: say a vendor wants to use a similar look and feel for the default environment settings etc. for all boards). If there is code which is identical for several (or all?) boards we should ask ourself if it really belongs into the board/ directory at all? That might be the case. It seems that current code in board/altera is SoC-specific, as it works on both Altera and EBV boards. Then we are in agreement that it does not belong below board/ ;) Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go. I think board/altera as such makes sense, with Altera being the vendor of that specific board. However, if there is common code there, this code should be moved out of board/ . It seems there's currently 99.99% of SoC-specific code there. What would be the right place for that code? Depends on what exactly it implements. Apart from that we can also take a look at where the code is in a Linux tree and take that as an example. After all, we want people developing the Linux kernel to also feel at home in the U-Boot sources. arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific. drivers/misc ? Do we need to make a soc/ directory? We have arch/arm/imx-common for example, but I'm not so sure if this is a good approach. Maybe there is not a _single_ correct place, but we have to distribute the files to multiple directories? And then... who does the move? It is not going to make merging between rocketboards.org and mainline even trickier than it already is :-(. This is a good question and we should certainly not answer it lightly. Usually we care only to a certain degree for non-mainline code, though. Blocking ourselves because of non-mainline code would allow external control which I think is not really helpful for the project. Cheers Detlev -- I think that level of generalization is too abstract for useful thinking. -- Richard Stallman in e19n344-0006q9...@fencepost.gnu.org -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target
Hi Pavel,
Hi, Detlev!
Altera Cyclone 5 board is very different board (big, rectangular,
expensive) than EBV Socrates (small, circular, cheap) board. Different
parts are used there, too, but same configuration of u-boot works on
both. Nevertheless, printing wrong name confuses users. Virtual target
is completely different, and board configured for it will not boot on
physical targets.
Thanks for the initiative again.
I'm celebrating mainline u-boot on my target :-).
Yay!
--- a/boards.cfg
+++ b/boards.cfg
@@ -379,6 +379,8 @@ Active arm armv7 rmobile renesas lager
Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw
Marczak p.marc...@samsung.com
Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang
mk7.k...@samsung.com
Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - -
+Active arm armv7 socfpga altera socfpga socfpga_virtual - -
+Active arm armv7 socfpga altera socfpga socfpga_socrates
As you correctly note, the socrates is sold by EBV and not Altera so I
guess the 5th column needs to be changed. Will this still work?
That will result in:
CC arch/arm/lib/eabi_compat.o
scripts/Makefile.build:64:
/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
or directory
make[2]: *** No rule to make target
`/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'. Stop.
I feared as much, so thats why I asked ;)
...and I don't think we want to do board/{altera,ebv} symlink. Are
there any other options? Or is altera in the boards file simply
acceptable?
This is a problem that will turn up in the future even more, so I
propose to solve it correctly now. It will not be long before we want
to have our own configuration for our MCV module and this will certainly
be sold by DENX. I think we need an infrastructure to allow for boards
sold by arbitrary manufacturers all using the Altera chip.
The situation as such is not uncommon, so maybe you can follow examples
from different CPUs? I.e. how is the imx6 handled on the different base
boards?
Cheers
Detlev
--
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
-- John McCarthy (1980)
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target
Hi Pavel,
Hi!
/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
or directory
make[2]: *** No rule to make target
`/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'. Stop.
I feared as much, so thats why I asked ;)
...and I don't think we want to do board/{altera,ebv} symlink. Are
there any other options? Or is altera in the boards file simply
acceptable?
This is a problem that will turn up in the future even more, so I
propose to solve it correctly now. It will not be long before we
want
Well, OTOH it is orthogonal problem to the board name is shared
between socrates and altera and config is shared between altera and
virtual target. And this patch is going to go stale rather quickly.
I admit, I do not understand that fully.
to have our own configuration for our MCV module and this will certainly
be sold by DENX. I think we need an infrastructure to allow for boards
sold by arbitrary manufacturers all using the Altera chip.
The situation as such is not uncommon, so maybe you can follow examples
from different CPUs? I.e. how is the imx6 handled on the different base
boards?
The examples I seen were different: there different board vendors
actually needed different code.
AFAICT, one solution would be to put - in that column, and do git
mv board/altera/ board/socfpga/.
Putting - in the vendor column just doesn't feel right. How about
using a minimal board C file for socrates under ebv/socrates that only
implements checkboard and shares the rest?
But if we decide to go that way, it should really be separate patch.
I still like to see a solution that scales to things we already know
will happen ;) Looking at the original patch, with this in mind even
the #define ALTERA_BOARD_NAME doesn't look right any longer.
Thanks
Detlev
--
We have a live-manual. It's called emacs-de...@gnu.org.
You can stick to just reading it, but you can skip to a specific chapter
by simply sending an email asking for it ;-)
-- Stefan Monnier
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target
Hi Pavel,
Altera Cyclone 5 board is very different board (big, rectangular,
expensive) than EBV Socrates (small, circular, cheap) board. Different
parts are used there, too, but same configuration of u-boot works on
both. Nevertheless, printing wrong name confuses users. Virtual target
is completely different, and board configured for it will not boot on
physical targets.
Thanks for the initiative again.
Therefore this splits the configuration so that u-boot knows they are
different. So far it is only used for correcting the puts, but there
may be other uses in future.
Signed-off-by: Pavel Machek pa...@denx.de
---
Diff from v1: separate virtual target, too, and make it apply to
recent u-boot.
diff --git a/board/altera/socfpga/socfpga_cyclone5.c
b/board/altera/socfpga/socfpga_cyclone5.c
index a960eb6..33946b6 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -28,7 +28,7 @@ int print_cpuinfo(void)
*/
int checkboard(void)
{
- puts(BOARD : Altera SOCFPGA Cyclone5 Board\n);
+ puts(BOARD : ALTERA_BOARD_NAME \n);
return 0;
}
diff --git a/boards.cfg b/boards.cfg
index 221b7f8..6eebbf5 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -379,6 +379,8 @@ Active arm armv7 rmobile renesas
lager
Active arm armv7 s5pc1xx samsung goni
s5p_goni -
Przemyslaw Marczak p.marc...@samsung.com
Active arm armv7 s5pc1xx samsung smdkc100
smdkc100 -
Minkyu Kang mk7.k...@samsung.com
Active arm armv7 socfpga altera socfpga
socfpga_cyclone5 -
-
+Active arm armv7 socfpga altera socfpga
socfpga_virtual -
-
+Active arm armv7 socfpga altera socfpga
socfpga_socrates
As you correctly note, the socrates is sold by EBV and not Altera so I
guess the 5th column needs to be changed. Will this still work?
Other than that:
Acked-by: Detlev Zundel d...@denx.de
Cheers
Detlev
--
Those who would give up essential liberty to purchase a little
temporary safety, deserve neither liberty nor safety.
-- Benjamin Franklin
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] kbuild: use cc-cross-prefix to choose CROSS_COMPILE
Hi Masahiro, CROSS_COMPILE is generally passed from the command line or by the environment variable because cross tools vary from user to user. But, having some choices of often used CROSS_COMPILE seems reasonable. $(call cc-cross-prefix, ...) returns the first prefix where a prefix$(CC) is found in PATH. If your cross tools exist in the argument of $(call cc-cross-prefix, ...), you do not have to specify it explicitly. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com I have to admit that I don't really like this approach. On the one hand it is an heuristic trying to guess the intentions of the user. This is nice if it works but can be very surprising when it goes wrong. But more imprtantly, it will blur the the boundaries of the build process as we trade the very self contained determinism of use what CROSS_COMPILE says to use what we may find in the rest of the system. It would even be possible that a once working build process will not work anymore because the user has installed a new toolchain in the meantime and then this completely unrelated action has an (unwanted) impact. In short, I would rather want to stay with our current (clearly defined) setup :) Best wishes Detlev -- He who can properly define and divide is to be considered a god. -- Plato -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] kbuild: use cc-cross-prefix to choose CROSS_COMPILE
Hi Masahiro, Hi Detlev, On Wed, 05 Mar 2014 11:06:03 +0100 Detlev Zundel d...@denx.de wrote: Hi Masahiro, CROSS_COMPILE is generally passed from the command line or by the environment variable because cross tools vary from user to user. But, having some choices of often used CROSS_COMPILE seems reasonable. $(call cc-cross-prefix, ...) returns the first prefix where a prefix$(CC) is found in PATH. If your cross tools exist in the argument of $(call cc-cross-prefix, ...), you do not have to specify it explicitly. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com I have to admit that I don't really like this approach. On the one hand it is an heuristic trying to guess the intentions of the user. This is nice if it works but can be very surprising when it goes wrong. But more imprtantly, it will blur the the boundaries of the build process as we trade the very self contained determinism of use what CROSS_COMPILE says to use what we may find in the rest of the system. It would even be possible that a once working build process will not work anymore because the user has installed a new toolchain in the meantime and then this completely unrelated action has an (unwanted) impact. In short, I would rather want to stay with our current (clearly defined) setup :) Maybe this is verbose, but just in case, let me add a few words. If you like, you can still pass CROSS_COMPILE from the command line or by the environment variable. ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := $(call cc-cross-prefix, arm-linux- arm-linux-gnueabi-) endif $(call cc-cross-prefix, ...) is invoked only when $(CROSS_COMPILE) is empty, that is CROSS_COMPILE is not explicitely specified. For users who know everything happening in the built system, this patch might be helpful for less typing... Yes, I fully understand your intention but I still believe that setting CROSS_COMPILE is usually scripted anyway so the savings are near negligible and the price we pay is adding (more) information about cross-toolchains which is really outside of the scope of U-Boot (or any other project I'd say). If there would be real savings, then maybe it is worth to break the principle of modularity but in the current discussion I just don't see that. Best wishes Detlev -- Our choice isn't between a digital world where the NSA can eavesdrop and one where the NSA is prevented from eavesdropping; it's between a digital world that is vulnerable to allattackers, and one that is secure for all users. -- Bruce Schneier -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
Hi Bhupesh, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of drambo Sent: Thursday, January 23, 2014 12:32 AM To: u-boot@lists.denx.de Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi Bhupesh, U-boot doesn't have ARM trusted firmware support as of now. U-boot for ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware itself is working in EL3. Since the ATF software doesn't really care whether it is loading uefi or u-boot and since it wants to load non-secure images as EL2 or EL1 (https://github.com/ARM-software/arm-trusted- firmware/blob/master/docs/user-guide.md See section Normal World Software Execution), why would we want to assume u-boot starts in EL3 mode by default? If we want to support EL3 execution for convenience to those that don't have ATF setup, that might make sense, but then shouldn't initial EL3 execution and subsequent switching levels be debug CONFIG options? Thanks. In the past I remember using u-boot as the bare-metal s/w to debug a Silicon without any BootROM/firmware code running before the same on ARM 32-bit architectures. Many of our customers (in the embedded market) use U-Boot in such a way very successfully. The ATF is presently tested only for UEFI and UEFI comes up in EL2 while the ATF itself is running in EL3. I don't know what would be the popular vote on this, but personally I feel that the u-boot for ARMv8 should also be launched by the ATF (similar to UEFI) and should start execution in EL2 so that it can launch a hypervisor (running in EL2) or Linux (running in EL1). But this might hurt the popular premise that u-boot can be used as a bare-metal s/w to debug a silicon without additional firmware components. Perhaps u-boot experts can guide us on this ! I have to admit that I'm only reading up on the complexities of the security model of aarch64, but my gut response (cf. [1] is that real security stems from few code rather than adding layer over layer. With this in mind, I'd really like to see that U-Boot with its well known and tested code base can still be the root of trust in an embedded product (i.e. EL3 as far as I understand). Many of the embedded U-Boot users who excercise full control over the whole software stack very likely want to see the same. The interesting question will be if we can reconcile the requirements of classic embedded U-Boot users and this OEM server market that seems to drive much of these new concepts here. But I sincerely hope so. After all, in the end we want to boot an OS to get the real work done ;) Best wishes Detlev [1] Reading one presentation I found about ATF[2] actually made my head hurt around page 12 which looks more like security soup than clearcut concepts, but maybe I'm just not into all the details yet. [2] http://lcu-13.zerista.com/event/member/85121 -- Our choice isn't between a digital world where the NSA can eavesdrop and one where the NSA is prevented from eavesdropping; it's between a digital world that is vulnerable to allattackers, and one that is secure for all users. -- Bruce Schneier -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot porting experiment -- which board or CPU will be good for doing it first time
Hi Allan, I have been reading u-boot documentation for last few weeks. I hope it was fun :) I am looking forward to configure write my own u-boot for some board or CPU . I will be doing it first time. Please suggest some existing board for which we have opensource U-boot software available, which are good for someone to start ? This is a very broad question and without giving us more context like price range, expected features, CPU architecture, etc. it is very hard to answer. An objective start however would be to look into boards.cfg in mainline to see what boards we support. If you have narrowed down your choice a little bit, I'm optimistic that people will then be glad to help find a local optimum amongst them. I can study that apply same concept to other Processors or boards. I will like to be an expert in u-boot porting. TI sitara controllers or RPi(I have an Rpi) or some thing else ? I am no expert on either one, but the Rpi is not an easy beast to tame. If you want to learn, I'd suggest looking for less complicated architectures that have been supported already for a while. Best wishes Detlev -- Our choice isn't between a digital world where the NSA can eavesdrop and one where the NSA is prevented from eavesdropping; it's between a digital world that is vulnerable to allattackers, and one that is secure for all users. -- Bruce Schneier -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] sf: Use shortcut names
Hi Jagan and Marek, On Friday, January 17, 2014 at 03:41:47 PM, Jagannadha Sutradharudu Teki wrote: - SPI_FLASH - SF - ARRAY_SLOW - AS - ARRAY_FAST - AF - DUAL_OUTPUT_FAST - DOF - DUAL_IO_FAST - DIOF - QUAD_OUTPUT_FAST - QOF - QUAD_IO_FAST - QIOF Now this really makes the code impossible to understand :-( I totally agree with Marek that this is the wrong way to go. Doing a change like this is a change to the worse as it removes understandable constants and replaces them with adhoc abbreviations. Please don't do that. Thanks Detlev -- Men are born ignorant, not stupid; they are made stupid by education. --Bertrand Russell -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros
Hi Jagan, On Sun, Jan 19, 2014 at 2:06 AM, Marek Vasut ma...@denx.de wrote: On Saturday, January 18, 2014 at 09:06:31 PM, Jagannadha Sutradharudu Teki wrote: - Used readable names for read/write command macros - Added comments for the same Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com Cc: Marek Vasut ma...@denx.de Cc: Simon Glass s...@chromium.org Does this patch have any impact other than making the code harder to understand ? :-( What's the rationale for making the code more cryptic ? No issues I guess with the readability as each macro we can easily understand. like CMD_RD_QUAD -- command_read_quad CMD_WR_PAGE -- command_write_page_program And this will minimize the macro length - good for in coding and more over description is added in drivers/mtd/spi/sf_internal.h anyway. Again I agree with Marek that readability of code is more important than saving a few characters while coding. This is especially true as editors can support you in coding (Emacs has lots of packages to help here for example). Cheers Detlev -- (7) It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three). -- The Twelve Networking Truths (RFC 1925) -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, link to my u-boot https://github.com/fedya/u-boot-yse5250 Please change the boot command and include the commands Changed to this bootcmd=md 4080 10;imi 4080;bootm 4080 [YSE5250@omv]# boot 4080: 56190527 ba6b0d61 9850d952 08484800'..Va.k.R.P..HH. 40800010: 00800040 00800040 8a221c4c 00020205@...@...L.. 40800020: 756e694c 2e332d78 302e3331 3863722dLinux-3.13.0-rc8 40800030: ## Checking Image at 4080 ... Legacy image found Image Name: Linux-3.13.0-rc8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4737032 Bytes = 4626 KiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Current stack ends at 0xc3cfbcc8 * kernel: cmdline image address = 0x4080 ## Booting kernel from Legacy Image at 4080 ... Image Name: Linux-3.13.0-rc8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4737032 Bytes = 4626 KiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK kernel data at 0x40800040, len = 0x00484808 (4737032) ## No init Ramdisk ramdisk start = 0x, ramdisk end = 0x Loading Kernel Image ... OK OK kernel loaded at 0x40008000, end = 0x4048c808 ERROR: booting os 'Unknown OS' (1) is not supported This is really weird and I am pretty sure that this is not supposed to happen with the code that we have in mainline. I think you have two options here: 1. Get mainline U-Boot running on your board that works with the uImage that os created from mainline Linux 2. Debug your U-Boot version why it does not handle the uImage like it is supposed to. Option 1 will be the more rewarding alternative of course. Best wishes Detlev -- insults: If set, sudo will insult users when they enter an incorrect password. This flag is off by default. -- man sudoers -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros
Hi Jagan, [...] I don't think nothing much gone the readability with these updated: CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like easy to understand. and anyway I have added comments for full name as well. Comments in a far away place cannot compensate for self-explaining constructs at the location where they are used. Stating that a constants needs comments to explain it is actually a good sign that its name is not chosen carefully enough. Really, naming constants and variables for readable and maintainable code is a much harder problem than it looks (cf. my signature) and unfortunately not easily measurable. But I assure you that good names can make a world of a difference. That's why Marek and me are so passionate about this seemingly trivial change. Few of the flashes can be call this as array fast read and fewer call this as fast read and few more call this as high frequency read. CMD_RD_FAST will suits all these names. Comments please! When we change code, we don't do this for the sake of changing it, but in order to improve one aspect of it, i.e. the performance, the maintainability or the features. When everything stays the same, we are even _opposed_ to a change because there is nothing to outweigh the effort to adjusting to the new things. To summarize - we need proof that a change _improves_ something. Showing that we do not loose something is clearly not enough. Now in this specific case, we have multiple people voicing the concern that the renaming looses vital information, thus effectively making reading and maintining the code harder. On the other hand even you agree that something although not much will be gone after the rename. So taking this into account we have only saving of a few keystorkes on the positive side and substantial degradation on readability and maintainability on the negative side. Best wishes Detlev -- There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to perform a secure boot on ARM Linux
Hi Rakesh, I have a beagle board and want to create a u-boot that verifies the kernel and rootfs before booting it. Any pointers on how it can be achieved will be appreciated. You can start here by reading the provided documentation: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt;hb=HEAD There's also a ELCE 2013 presentation by Simon Glass: http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf And a paper by Jagan Teki from the U-Boot Mini Summit http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boot_verified_RSA_boot_flow_on_arm_target.pdf The mailing list is surely the right place for further questions ;) Cheers Detlev -- There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] doc: README: Correct file name of signature verification documentation
Signed-off-by: Detlev Zundel d...@denx.de --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index aea82be..edf5fe4 100644 --- a/README +++ b/README @@ -2832,7 +2832,7 @@ CBFS (Coreboot Filesystem) support CONFIG_RSA This enables the RSA algorithm used for FIT image verification - in U-Boot. See doc/uImage/signature for more information. + in U-Boot. See doc/uImage.FIT/signature.txt for more information. The signing part is build into mkimage regardless of this option. -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, I faced with a strange behaviour of u-boot. Expected behaviour for some people may seem strange to others ;) Few months ago i bought an ARM development board from yicsystem it's based on exynos 5250 and very similar to arndale http://www.yicsystem.com/products/low-cost-board/yse5250/ And i can boot Android ICS but when i try to boot any linux i always see Checking Boot Mode ... SDMMC Now running in RAM - U-Boot at: c3e0 REVISION: 1.0 REVISION: 1.0 MMC Device 0: 3839 MB NAME: S5P_MSHC0 MMC Device 1: 7348 MB MMC Device 2 not found Destroy Hash Table: c3f80f78 table = (null) Create Hash Table: N=512 INSERT: table c3f80f78, filled 1/521 rv c3d047a0 == name=baudrate value=115200 INSERT: table c3f80f78, filled 2/521 rv c3d0582c == name=bootargs value=root=/dev/mmcblk0p1 INSERT: table c3f80f78, filled 3/521 rv c3d04a1c == name=bootcmd value=movi read kernel 0 40008000;movi read rootfs 0 4100 10;bootm 40008000 4100 INSERT: table c3f80f78, filled 4/521 rv c3d04f20 == name=bootdelay value=3 INSERT: table c3f80f78, filled 5/521 rv c3d04bfc == name=bootfile value=/tftpboot/revoboot/bin/revoboot.pxe INSERT: table c3f80f78, filled 6/521 rv c3d040a4 == name=emmcbootrecovery value=mmc erase boot 1 0 0;emmc open 1;movi read fwbl1 0 4000;movi write zero fwbl1 1 4000;movi read bl2 0 40004000;movi write zero bl2 1 40004000;movi read u-boot 0 4200;movi write zero u-boot 1 4200;movi read tzsw 0 4210;movi write zero tzsw 1 4210;emmc close 1 INSERT: table c3f80f78, filled 7/521 rv c3d04998 == name=ethact value=smc911x-0 INSERT: table c3f80f78, filled 8/521 rv c3d0462c == name=ethaddr value=00:40:5c:26:0a:5b INSERT: table c3f80f78, filled 9/521 rv c3d057a8 == name=gatewayip value=192.168.0.1 INSERT: table c3f80f78, filled 10/521 rv c3d05874 == name=ipaddr value=192.168.0.28 INSERT: table c3f80f78, filled 11/521 rv c3d048c0 == name=netmask value=255.255.255.0 INSERT: table c3f80f78, filled 12/521 rv c3d05214 == name=rootfslen value= 10 INSERT: table c3f80f78, filled 13/521 rv c3d048e4 == name=serverip value=192.168.0.13 INSERT: free(data = c3d00010) INSERT: done Net: smc911x-0 ### main_loop entered: bootdelay=3 ### main_loop: bootcmd=movi read kernel 0 40008000;movi read rootfs 0 4100 10;bootm 40008000 4100 Hit any key to stop autoboot: 0 reading kernel..device 0 Start 1063, Count 16384 MMC read: dev # 0, block # 1063, count 16384 ... 16384 blocks read: OK completed reading RFS..device 0 Count 17447, Start 2048 MMC read: dev # 0, block # 17447, count 2048 ... 2048 blocks read: OK completed ## Current stack ends at 0xc3cfbd98 * kernel: cmdline image address = 0x40008000 ## Booting kernel from Legacy Image at 40008000 ... Image Name: Linux-3.12.0-rc1-armv7-x0.6-0012 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3243400 Bytes = 3167 KiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK kernel data at 0x40008040, len = 0x00317d88 (3243400) * ramdisk: cmdline image address = 0x4100 Wrong Ramdisk Image Format ramdisk start = 0x4100, ramdisk end = 0x4100 XIP Kernel Image ... OK This XIP points to a problem. In essence I think you should try to load your image to any address in RAM but _not_ to the load address specified in the uImage. The intention of this field is to tell U-Boot where the uImage file - that could reside on nor flash for exmple - should be loaded to in RAM before it is executed. You have specified 4008000 at image creation time but already load uImage that has a 64-byte header prepended to that location. U-Boot in term finds that the image is alreday where it should be, does nothing and switches to XIP mode and then gets pretty confused. So again, try loading the image somewhere else in RAM and let U-Boot do the copying to the correct place. And even better, we consider uImages to be legacy for quite a while, so please plan to switch to using FIT images sometime soon. Cheers Detlev -- This is not the first time my views on some topic have inspired in someone the desire to psychoanalyze me. Previous experience leads me to ask about your couch. Is it comfortable? Are its springs in good shape? -- Jonh McCarthy -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling fw_printenv tool
Hi Alexey, [...] I've googled it and sorted it out. The problem was that executable was dynamically linked and the *.so was not found on the embedded system. I compiled it with -static and it runs. I'm glad you solved the problem. I only like for such answers to show up in archives so that other people can profit from the answer in DuckDuckGo searches yet to come ;) Cheers Detlev -- Our choice isn't between a digital world where the NSA can eavesdrop and one where the NSA is prevented from eavesdropping; it's between a digital world that is vulnerable to allattackers, and one that is secure for all users. -- Bruce Schneier -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling fw_printenv tool
Hi Masahiro-san, How do I cross compile it for my embedded system? Do I just set the HOSTCC environment variable in the Makefile? No changes in any makefiles are needed, just do make HOSTCC=arm-none-linuex-gnueabi-gcc env It looks weird to me. You're not alone actually :) In a land far away in time, we used to always cross-compile this tool. But at a certain stage IIRC Mike Frysinger convinced us that this tool should be compiled with the host toolchain instead (honestly, I can't remember why). So we accepted this and documented it a later commit log: commit 02bd475e343582b3c915b94ef4016d5876d4a4f1 Author: Daniel Hobi daniel.h...@schmid-telecom.ch Date: Wed Nov 10 14:11:21 2010 +0100 tools/env: cleanup host build flags This patch makes tools/env/Makefile more similar to tools/imls: - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works. - include U-Boot headers using -idirafter to prevent picking up u-boot/include/errno.h. - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic). In order to cross-compile tools/env, override the HOSTCC variable as in this example: make tools env HOSTCC=bfin-uclinux-gcc Signed-off-by: Daniel Hobi daniel.h...@schmid-telecom.ch Tested-by: Detlev Zundel d...@denx.de Tested-by: Steve Sakoman steve.sako...@linaro.org I for myself only saved the magic invocation needed and forgot the reasoning... I think HOSTCC should be always gcc. Correct. One should only switch this for one specific build target. In my understanding, tools/env/fw_printenv is not a host program but a one for the target embedded Linux. Correct. Is there any reason that we don't fix tools/env/Makefile? $(obj)fw_printenv: $(HOSTSRCS) $(HEADERS) $(HOSTCC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS) $(HOSTSTRIP) $@ to $(obj)fw_printenv: $(HOSTSRCS) $(HEADERS) $(CC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS) $(STRIP) $@ Personally I think I can now remember that the change was mostly done to get the makefile somehow more similar to other makefiles. So considering your massive (and most welcome!) work on the build infrastructure, I think you have become kind of an unspoken authority on these issues ;) So if it helps in your cleanup and nobody objects, I'll ack your changes. Best wishes Detlev -- Our choice isn't between a digital world where the NSA can eavesdrop and one where the NSA is prevented from eavesdropping; it's between a digital world that is vulnerable to allattackers, and one that is secure for all users. -- Bruce Schneier -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling fw_printenv tool
Hi Gerhard, [...] Ok, thinking about your answer it kind of makes sense that fw_printenv can easily be used _out of tree_ without much hassle. On the other hand, as part of the build process, it is surely something to run on the target and thus something to compile with CC and not HOSTCC. Bu tmaybe we can get the best of both worlds, but I admit that I'm not that deep into the build infrastructure. Even more so considering that it is currently changing ;) Cheers Detlev -- Algebraists do it in a ring, in fields, in groups. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A list of dead email addresses of board maintainers
Hello Masahiro-san, When I CC board maintainers, it sometimes results in bounce mails. How should we modify boards.cfg? Delete the email? Or just mark as dead address ? This hooks into the recent discussion about when we can remove unsupported boards. The concensus there was to mark those boards as unmaintained and keep the e-mail as last working e-mail address. Deleting the e-mail means loosing important information. Even though the accounts do not work anymore, they carry information. Cheers Detlev [1] article.gmane.org/gmane.comp.boot-loaders.u-boot/173305 -- Now that it's been pointed out, we should just rename Emacs as CTHULHU: CTHULHU's Top Hacks Using Lisp, Horrifying Users For CTHULHU 25, M-x doctor should be replaced by M-x cthulhu, which no one should ever call. -- Jay Belanger 87bnznxlj6@gmail.com -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fat write problem
Hi Ruud, This week I decided to do some further research and testing regarding this problem. With the image I had from the previous time, I could immediately reproduce it and by adding more and more debug prints, I tried to find the cause. Sofar, I have not succeeded in this yet. However: later on I started testing with a freshly formatted drive (32 MB FAT partition) and kept repeating the fatwrite command: fatwrite mmc 0:1 4200 test-x 200 where x runs from 1, 2,3 and further. And this way I could reproduce it quite easily. Writing always fails for the 32nd file. This is with the partition formatted with a 512 byte sector size and a cluster size of 4. If the cluster size is 1 (formatted by Windows), it already fails at the 8th file. If I create a subdirectory (from Linux) with already 24 files in it, I can still write 29 files and it fails at number 30. Also, if earlier files were deleted from the root-directory, they still count in the total number of files here. If I take out the card where u-boot fails to write new files, I can still add new files from my PC with Linux or Windows. I tested with both long and short filenames (same result), VFAT is enabled. I hope this gives you all some more information about this problem and perhaps it is even a known problem (limited number of files in the root directory?). I know it is voor FAT16, but that was 512 entries if I am correct. Thanks for the extensive research into this problem. For people to help, I think the barrier of reproducing the problem is somewhat high, so it occurred to me if you can help setup a very easy test for people to work on. Would you be able to generate a small image that one can dd to a mmc card and then immediately provoke the error? If you don't have any hosting space, as a last resort I'd be fine for you to put it on our wiki [1]. Cheers Detlev [1] http://www.denx.de/wiki/view/U-Boot/TooBigPatches -- Golden rule #12: When the comments do not match the code, they probably are both wrong. -- Steven Rostedt 1300126962.9910.128.ca...@gandalf.stny.rr.com -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
Hi Simon,
[...]
I think the Linux code has two big advantages - for one, we increase the
overlap with Linux kernel proper and secondly we keep the 'grep'ability
of the names which I really missed in your proposal.
Yes that seems reasonable.
Ok, I'm glad we are in agreement.
Many of U-Boot's options are not just yes/no, so I'm not sure what will
happen with those. Perhaps they just can't be used with this macro? Part of
my intent was to allow any option to be used.
In those cases the defines then are a shortcut to using a boolean + a
value and we can make it work by introducing this boolean? I have no
idea of how much work this would be, but it might be worthwhile getting
some real numbers to that.
So for example you can do this:
struct {
const char *str;
u_int len;
int retry;
const char *conf; /* Configuration value */
}
delaykey [] = {
{ str: getenv(bootdelaykey), retry: 1,
conf: autoconf_autoboot_delay_str() },
{ str: getenv(bootdelaykey2), retry: 1,
conf: autoconf_autoboot_delay_str2() },
{ str: getenv(bootstopkey), retry: 0,
conf: autoconf_autoboot_stop_str() },
{ str: getenv(bootstopkey2), retry: 0,
conf: autoconf_autoboot_stop_str2() },
};
or this:
/* don't retry auto boot? */
if (autoconf_boot_retry_time()
!delaykey[i].retry)
retry_time = -1;
Note that autoconf_boot_retry_time() will return 0 if the CONFIG is not
defined, or if its value is 0.
I'm having real trouble figuring out what this would do on first sight.
Of course you could call me lazy, but by experience I tend to favour
solutions that do not need geniuses to understand ;)
Well it is simply that we currently have options which may or may not
be defined. If they are not defined, then it is an error to refer to
them, so they must be guarded by an #ifdef. By defining them to 0 when
not defined, we can avoid that guard.
Ok, I see. But in this way we are actually shutting up the compiler on
code paths that we did not have before. This in effect is a rather be
quiet than error strategy and I'm not sure that I want to use that
when doing such changes. Call me old-fashioned, but I'd prefer to throw
an error and fix it after thinking it through from todays perspective
(I can say this easily if I'm not the one who has to do the fixes ;)
It seems to me we should provide the Linux feature in U-Boot as part of the
Kconfig stuff, and see where it takes us. Combined with a bit more
rationalisation of things like main.c it might be enough.
Why not reimplement your patch set along those lines? I still really
would _love_ to see us using the compiler more to check for errors and
reduce the number of potential source code combination that we have.
Well certainly I could, but I did not want to do this while
Kbuild/Kconfig is in progress, and we are not quite clear on what to
do. I think Kbuild is done - we will probably get the Linux autoconf
stuff for free with Kconfig which I understand is coming very soon.
This makes a lot of sense yes. Actually I'm pretty excited about this
excellent and continuous work from Masahiro-san on that topic!
After that I can certainly take another look at main.c and see how it
can be improved.
Sure, its only that I wanted to keep the ball rolling as I really
believe the wins to be had from such a change are substantial for our
codebase.
Cheers
Detlev
--
Golden rule #12: When the comments do not match the code, they probably are
both wrong. -- Steven Rostedt 1300126962.9910.128.ca...@gandalf.stny.rr.com
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hello Alexander, Thanks for your answer! So again, try loading the image somewhere else in RAM and let U-Boot do the copying to the correct place. It's not obvious for me how to do it. Might you have any guide or faq? [...] ### main_loop: bootcmd=movi read kernel 0 40008000;movi read rootfs 0 ^^^ 4100 10;bootm 40008000 4100 ^^ Your bootmcd reads the kernel to 40008000 and then calls bootm to that address. Simple change those two places to, say, 4080 by editing bootcmd. (Not knowing your system, I presume RAM starts at 4000, and 4080, then would be 8MiB after the beginning. U-Boot will copy the kernel to 4008000 so the kernel should not be bigger than 7.5MiB but the other snippets from your log say the kernel is ~3.2MiB, so this should be fine. Cheers Detlev -- The only thing that interferes with my learning is my education. -- Albert Einstein -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling fw_printenv tool
Hi Alexey, [...] In case someone needs that (before the Makefile changes are accepted), I used the make HOSTCC='arm-none-linuex-gnueabi-gcc -static' env command to get it working. We usually do put options into the HOSTCC variable. Of course one can argue about that, but the make documentation says about CC: `CC' Program for compiling C programs; default `cc'. and about `CFLAGS' Extra flags to give to the C compiler. So maybe you can do the same in a cleaner way like make HOSTCC='arm-none-linux-gnueabi-gcc' HOSTCFLAGS='-static' env Don't get me wrong, I don't want to win a beauty contest, but my experience tells me that such oh this works for me quick and dirty solutions tend to build up debt that can be hard to pay later on ;) Cheers Detlev -- The best way to predict the future is to invent it. -- Alan Kay -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, [...] *ERROR: booting os 'Unknown OS' (1) is not supported* Hm, very strange. Looking up the code, the '1' is the image type contained in the uImage header. It is defined to be OpenBSD in include/image.h and if your U-Boot doesn't have support for that, you will get that message. This however doesn't make sense to have an uImage with this type. Can you do an 'mkimage -l image' on your development host to check the contents of the header? If this looks good, then somehow the image seems to be overwritten before trying to boot, but I don't see where. Cheers Detlev -- I object to doing things that computers can do. -- Olin Shivers -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, Also if flashed 3.12_zImage (same kernel, same sources, just zImage) Ok, zImage doesn't have the uImage header, so we will not see any information nor will U-Boot be able to verify a checksum there. reading kernel..device 0 Start 1063, Count 16384 MMC read: dev # 0, block # 1063, count 16384 ... 16384 blocks read: OK completed reading RFS..device 0 Count 17447, Start 2048 MMC read: dev # 0, block # 17447, count 2048 ... 2048 blocks read: OK completed Boot with zImage Wrong Ramdisk Image Format Note that you also have a problem with your ramdisk, even if the kernel starts, it will likely not do much if it needs the ramdisk. Starting kernel ... And it's stucked at Starting kernel ... Let's say we don't see anything after Starting kernel . This is also a common case when the kernel cannot open an initial console. It may well be that the kernel runs but without a console you will see nothing. To diagnose this you'd need to be sure that bootargs is setup properly before booting the kernel. Let's step back a bit. Do you have a kernel and ramdisk and kernel command line that works on your board? I.e. do we have a working case that we can retreat to for further tests? Also is U-Boot and the kernel mainline? Cheers Detlev -- The management question ... is not _whether_ to build a pilot system and throw it away. You _will_ do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. - Fred Brooks, The Mythical Man Month -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, Might i need a special arguments for mkimage to set up OS in headers of uImage? One needs parameters for that, but the information looks ok: [...] [fedya@discordy linux-linaro-tracking]$ mkimage -l arch/arm/boot/uImage Image Name: Linux-3.13.0-rc8 Created: Fri Jan 17 15:47:36 2014 Image Type: ARM Linux Kernel Image (uncompressed) ^ If you check common/image.c:261 (image_print_type), you'll see that this is correctly decoded from the image, so the image seems perfectly fine. It just makes no sense that U-Boot then complains about an unknown OS. This means that between the time the header is printed and between the time the code wants to boot it, the memory does not contain what it should anymore. Cheers Detlev -- ike|abel - Eine Partnerschaft erweist sich als ikeabel, wenn ein samstäglicher Besuch bei Ikea weder zur sofortigen Trennung noch zu tagelangen Diskussionen führt. In einigen urbanen Subkulturen hat der gemeinsame Ikea-Besuch die Ver- lobung vollständig ersetzt.-- Wortschatz v. Sascha Lobo -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, Do you have a kernel and ramdisk and kernel command line that works on your board? Yes, i have a working 3.0. kernel and ramdisk.img it is an android image. Linux version 3.0.15 (root@yicsystem) (gcc version 4.4.3 (GCC) ) #1 SMP PREEMPT Thu Apr 25 14:28:59 KST 2013 kernel command line # cat /proc/cmdline console=ttySAC1,115200n8 vmalloc=512M androidboot.console=ttySAC1 i built a kernel with same string. Ok, good. Also is U-Boot and the kernel mainline? u-boot based on U-Boot 2012.12-0-g462762b-dirty with yse5250 platform changes And i tried a mainline u-boot and it's does not working. Just an empty screen on terminal window. This is of course unfortunate as we are then not able to _really_ infer what is going on on your board. Potentially, there can be a lot of changes in such modified versions. Cheers Detlev -- #!/usr/bin/perl $c=print\\#\!\/usr\/bin\/perl\ \\\$c\=\.quotemeta\(\$c\)\.\;\\n\$c;\; print#!/usr/bin/perl\n\$c=\.quotemeta($c).\;\n$c;; -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] booting os 'Unknown OS' (1) is not supported
Hi Alexander, You have any suggestion how i can fix or hack it? I really have no clue what's wrong and why it's working with android kernel and not with mainline. Well, potentially, there can be worlds of differences between such kernels. I don't know your platform at all, but is it expected to work with a mainline kernel? The only thing that I can think of to get more information is to edit your bootcmd to only boot the kernel without any ramdisk and see if the loading of the latter is the problem, i.e. something like that: bootcmd=movi read kernel 0 4080;bootm 4080 Even though this cannot fully work, it may give us new input. Cheers Detlev -- ;; Self-replicator in ELisp ((lambda (l) (prin1-to-string (list l (list (quote quote) l (quote (lambda (l) (prin1-to-string (list l (list (quote quote) l)) -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
), retry: 0, conf: autoconf_autoboot_stop_str2() }, }; or this: /* don't retry auto boot? */ if (autoconf_boot_retry_time() !delaykey[i].retry) retry_time = -1; Note that autoconf_boot_retry_time() will return 0 if the CONFIG is not defined, or if its value is 0. I'm having real trouble figuring out what this would do on first sight. Of course you could call me lazy, but by experience I tend to favour solutions that do not need geniuses to understand ;) It seems to me we should provide the Linux feature in U-Boot as part of the Kconfig stuff, and see where it takes us. Combined with a bit more rationalisation of things like main.c it might be enough. Why not reimplement your patch set along those lines? I still really would _love_ to see us using the compiler more to check for errors and reduce the number of potential source code combination that we have. Thanks for all the work so far! Detlev -- The C++ STL, with its dyslexia-inducing syntax blizzard of colons and angle brackets, guarantees that if you try to declare any reasonable data structure, your first seven attempts will result in compiler errors of Wagnerian fierce- ness. -- James Mickens -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling fw_printenv tool
Hi Alexey, Dear Detlev, I ran $ make HOSTCC=arm-none-linux-gnueabi-gcc env and got the tools/env/fw_printenv executable. But the Make command returned error: strip: Unable to recognise the format of the input file `fw_printenv' make[1]: *** [fw_printenv] Error 1 I guess, HOSTSTRIP variable also has to be set. However, I uploaded the unstripped executable to my embedded device, and ran: $ chmod a+x fw_printenv $ ./fw_printenv -sh: ./fw_printenv: not found I tried also manually stripping the executable. What could be this error related to? Oops, I really missed that mail, sorry. This error message means that your cross-compiled binary does not run on the embedded device (maybe the device uses different libraries than your cross toolchain links agains). To troubleshoot that, start with a regular hello-world.c and continue to fw_printenv only if you have this working. Cheers Detlev -- The C++ STL, with its dyslexia-inducing syntax blizzard of colons and angle brackets, guarantees that if you try to declare any reasonable data structure, your first seven attempts will result in compiler errors of Wagnerian fierce- ness. -- James Mickens -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi, as already indicated, we are looking forward to our next U-Boot Mini Summit at Embedded Linux Conference Europe 2014 which will take place in Düsseldorf, Germany from October 13 - 15. The call for papers of the main conference is now open[1] and if you want to submit a talk for the main tracks, you should note the deadline of July 11. For our U-Boot Mini Summit, I'd like to get the schedule completed synchronized to the schedule release of the main event, which is August 12. So please submit talk proposals here with at least me on CC. To coordinate the event better, I have setup another wiki page[2] that can and _should_ be edited by the interested parties. Feel free for example to add yourself to the interested participants so that we get an idea of how many of the U-Boot developers will be there. Best wishes Detlev [1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/cfp [2] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 -- Blaming Snowden for causing problems for the US cloud industry is like blaming Al Gore for the global warming. -- Mikko Hypponen -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling fw_printenv tool
Hi Alexey, I'm trying to compile fw_printenv, to work with U-Boot environment variables under my linux os. I'm using commands: $ cd u-boot/ $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- env The tool compiles successfully, I get the executable under u-boot/tools/env/fw_printenv, but it seem to be compiled for my host machine. On my device it says: # ./fw_printenv: line 1: syntax error: ( unexpected How do I cross compile it for my embedded system? Do I just set the HOSTCC environment variable in the Makefile? No changes in any makefiles are needed, just do make HOSTCC=arm-none-linuex-gnueabi-gcc env We should really turn this into an documentation item. Does anybody hava a good idea where to put it? Cheers Detlev -- Progress in mathematics comes from repeated acts of generalization. If mathematics is anything, it is the art of chosing the most elegant generalization for some abstract pattern. Thus esthetics is central. -- Douglas Hofstadter -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Hi Tom, On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future. Signed-off-by: Pavel Machek pa...@denx.de Is there any way at run time to tell which board we are on? I'll try to find out, but currently I don't know of any way. Best wishes Detlev -- Man gelangt nicht dazu, gluecklich zu sein, aber man macht Feststellungen ueber die Gruende, die uns daran hindern es zu sein. -- Marcel Proust -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Hi Michal, On 11/11/2013 09:33 PM, Tom Rini wrote: On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote: Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future. Signed-off-by: Pavel Machek pa...@denx.de Is there any way at run time to tell which board we are on? Why do you care about board name in general? We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names? Cheers Detlev -- A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan Perlis, Epigrams on Programming -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Minutes from the U-Boot Mini Summit 2013
Hi, [...] - Encourage custodians to delegate separable parts to new custodians (Lukasz volunteered for USB DFU) In the meantime we have setup a new repo for this custodianship[1] and are happy that Lukasz takes on this new responsibility. As discussed the other custodians are invited to propose comparable split-offs to get the work into more manageable areas of responsibility. Cheers Detlev [1] http://git.denx.de/?p=u-boot/u-boot-dfu.git;a=summary -- Another helpful hint for successful MIME processing: application/msword; rm -f %s; description=MS Word Text; -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot Mini Summit slides [was: Minutes from the U-Boot Mini Summit 2013]
Hi, [...] This years installation went very well and the very interesting presentations sparked a lot of fruitful discussion extending into a very intense session somewhat exceeding the official schedule. All slides have now been uploaded to our wiki area: http://www.denx.de/wiki/U-Boot/MiniSummitELCE2013 Enjoy! Detlev -- Do not add new functionality unless an implementor cannot complete a real application without it. -- principles of X Window System -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Minutes from the U-Boot Mini Summit 2013
Hi, it was a real pleasure to meet up with so many people on the ELCE in Edinburgh the last few days. Those of you who could not make it should look out for the Embedded Linux Conference Europe in 2014. Although not yet finalized, we are optimistic to have the second U-Boot Mini Summit there. This years installation went very well and the very interesting presentations sparked a lot of fruitful discussion extending into a very intense session somewhat exceeding the official schedule. As a base for further discussion on this list, as promised here are the minutes recorded during that session (only slightly edited): * Roadmap - A consensus was reached to tackle these four major projects in the following order: Kconfig Driver Model Using Device tree more KBuild ** Kconfig (w/o KBuild) - Change Makefiles to use KConfig - What is the timeline for it? ** Driver model - Introduce the driver model without changing all drivers at once - At a certain stage require new drivers to adhere to the driver model - What is the overhead of the driver model for SPL? - SPL can use the driver model without device tree by binding devices to platform data, so SPL does not require device trees. - U-Boot itself can also use platform data not only device trees to bind to devices, so device tree support is not mandatory - Merge as soon as possible to be the first step ** Configuring U-Boot through device tree - _What_ should be configured? - Google requires every new U-Boot driver to be configured through device tree in U-Boot - Configuring U-Boot through device trees shall aim for using the exact same tree from the Linux kernel. - It is ok to keep a snapshot for the installed U-Boot - dts files are kept within U-Boot repository ** SPL - What minimal requirements do we want to support for SPL? - FIT Support can be configured into SPL (can pretty sure be optimized) - Enable device tree support in SPL? ** Misc - Be more aggressive about removing unsupported/unused configurations - Remove architectures where no uptodate toolchains are available - Allow one experimental branch probably breaking configurations to try out new ideas - Using LLVM should be fine after some compatible changes - We want a way of assigning maintainership on a directory basis comparable to Linux kernel - Encourage custodians to delegate separable parts to new custodians (Lukasz volunteered for USB DFU) - Do we have a tool problem? Yes, patchwork is a problem - What are the perceived problems? - The bundling of patches is tedious or not workable. - It is very hard to see changes late in a revision series (v8 vs. v9) - Is there any existing tool that we can adopt? - Is gerrit the solution to all our problems? No, it does not integrate bidirectional with the mailing list, i.e. gerrit sends mails to the ML and follow-ups from the ML are being picked up by gerrit. - A mythical non-existant bidirectional gerrit seems to solve most problems - Can patman be extended to support the review process? - Can gerrit be used as an interim? Patches originating in gerrit will send mails but followups cannot be picked up automatically and have to be processed manually. - Vadim volunteered to send a How-To on gerrit usage to the ML - If not, can we write one? - UEFI support is not considered to be relevant now ** CI - Adopt kernel toolchains used to build kernel-next for reference builds. What about OpenRISC? m68k? A big thanks again to all participants of the discussion and I'm looking forward to the followup threads ;) Cheers Detlev -- There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Final talk schedule for U-Boot mini summit and collection of discussion topics
Hi, the schedule for the U-Boot mini conference next week has been finalized: ,---+-+--. | Time | Speaker | Summary | |---+-+--| | 13:00 - 13:20 | Marek Vasut | Using i.MX28/i.MX233 without Freescale tools | | 13:30 - 13:50 | Scott Wood | TPL: SPL loading SPL | | | | (and, SPL as just another U-Boot config) | | 14:00 - 14:20 | Stefano Babic | Falcon Boot: current status and | | | | enhancements | |---+-+--| | 14:30 - 14:45 | | Break | |---+-+--| | 14:45 - 15:05 | Lukasz Majewski | Device Firmware Upgrade (DFU) - | | | | present situation and future development | | 15:15 - 15:35 | Jagan Teki | U-boot verified RSA boot flow on arm - | | | | with demo run | | 15:45 - 16:05 | Simon Glass | Driver model, Kconfig and a little Patman | |---+-+--| | 16:15 - 16:30 | | Break | |---+-+--| | 16:30 - 17:00 | Everybody | Open Discussion | `---+-+--/ A notable change is the talk from Jagan that changed from Android fastboot to U-Boot verified RSA boot flow on arm. As this would have overlapped Simon Glass' talk Verified Boot on Chrome OS and How to do it yourself (14:00 - 14:50) in the main track we swapped those two presentations. This way people interested in verified booting can attend both talks. In the meantime our schedule has found its way to the main web pages[1], hopefully giving us a wider audience. Currently the swap explained in the last paragraph is still pending, but I hope this to show up soon. In this second part of my message I'd like to invite everybody to collect topics that need/should be discussed at the U-Boot mini summit, especially in the Open Discussion part at the end. As of now we have collected two items: - Assigning maintainership on a directory basis comparable to Linux kernel - Proposals of maintainers to reduce their workload What else do you want to bring to the attention of the attendants? Cheers Detlev [1] http://embeddedlinuxconferenceeu2013.sched.org/ -- A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan Perlis, Epigrams on Programming -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Preliminary schedule for U-Boot miniconf at ELCE2013
Hi, thanks to the excellent feedback we got on the U-Boot mini conference next week in Edinburgh, this is the current schedule for the mini conference next week: ,---+-+--. | Time | Speaker | Summary | |---+-+--+ | 13:00 - 13:20 | Marek Vasut | Generating bootstreams on i.mx28 | | | | without any external tools | | 13:30 - 13:50 | Scott Wood | SPL loading SPL (a.k.a. TPL) and SPL | | | | as just another U-Boot config | | 14:00 - 14:20 | Stefano Babic | Falcon Boot: current status and enhancements | |---+-+--+ | 14:30 - 14:45 | | Break | |---+-+--+ | 14:45 - 15:05 | Jagan Teki | Android Fastboot | | 15:15 - 15:35 | Lukasz Majewski | DFU | | 15:45 - 16:05 | Simon Glass | Driver model, Kconfig, Patman tutorial | |---+-+--+ | 16:15 - 16:30 | | Break | |---+-+--+ | 16:30 - 17:00 | Everybody | Open Discussion | `---+-+--/ (This is a transcript from the wiki page[1]) For the open discussion, we would especially like to ask all maintainers for proposals of things to discuss. The wiki page is a good place to collect ideas here. For the speakers: As far as I know, it should be possible to hook up your laptop to a beamer in the room, but it would be worthwhile to bring the slides as PDF or ODP no a usb stick in case some problems pop up. We will also collect the slides to publish them on the U-Boot web pages afterwards. Let us know if there are any problems that we may need to look into, otherwise we are looking forward to seeing you next week in Scotland! Best wishes Detlev [1] http://www.denx.de/wiki/edit/U-Boot/MiniSummitELCE2013?t=1381844125 -- I hear and I forget. I see and I remember. I do and I understand. -- Confucius -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Preliminary schedule for U-Boot miniconf at ELCE2013
Hi, [...] [1] http://www.denx.de/wiki/edit/U-Boot/MiniSummitELCE2013?t=1381844125 The correct link of course should not include session details: http://www.denx.de/wiki/edit/U-Boot/MiniSummitELCE201 Cheers Detlev -- Java is sort of the Cobol of the 21 century. It's kind of heavyweight, verbose and everyone loves to hate it. [..] But managers kind of like it. -- Larry Wall -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Preliminary schedule for U-Boot miniconf at ELCE2013
Detlev Zundel d...@denx.de writes: [...] http://www.denx.de/wiki/edit/U-Boot/MiniSummitELCE201 Urgh, I hate to admit it, but that link also does not work, on top of the previous one, it actually has _two_ errors in it... The real (click verified) link is: http://www.denx.de/wiki/U-Boot/MiniSummitELCE2013 Sorry for all that noise. Detlev -- Golden rule #12: When the comments do not match the code, they probably are both wrong. -- Steven Rostedt 1300126962.9910.128.ca...@gandalf.stny.rr.com -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot mini-summit at ELCE 2013 in Edinburgh - call for participation!
Dear Jagan, On Thu, Mar 21, 2013 at 10:21 PM, Detlev Zundel d...@denx.de wrote: Hi fellow U-Boot developers, people meeting us at our booth at the Embedded World trade show in Nürnberg this year may already have heard rumours about it but now it is official - there will be an U-Boot mini-summit at the Emdedd Linux Conference Europe in Edinburgh, UK [1]. I am planning to attend...!! Excellent, I added you to the wiki page[1]. [...] Of course everybody is invited to suggest a presentation, but an informal poll turned up these topics of interest: - Driver model - Kconfig - Patman tutorial - U-Boot configuration through device tree - Falcon boot for everybody - DFU - Android fastboot Does anyone occupied Android fastboot? It seems you just did that ;) Is there any list that shows topics vs speakers?, if so please share. See the wiki page. Thanks Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2013 -- Greenspun's Tenth Rule of Programming: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot mini-summit at ELCE 2013 in Edinburgh - call for participation!
Hi all, having also resumed from my holidays, I'd like to formalize the plans on our meeting. Thanks for the responses so far. I should be there too. Will be there any specific room available for u-boot mini summit? Yes, I do believe so. We currently have our meeting scheduled for Thursday, October 24th from 1-5pm. We will have a room secured to hold 40 attendees with a screen and projector. Judging from the current feedback, this should be enough ;) If we come up with am agenda, the Linux Foundation will publish it beforehand and so hopefully give us more publicity, so this is what we currently should aim for. From this thread, I have noted up the following speakers (ordered alphabetically) ** Lukasz Majewski - DFU ** Simon Glass - Driver model - Kconfig - Patman tutorial - U-Boot configuration through device tree ** Tom Rini - Redundant booting with U-Boot (or: Welcome to the redundancy theatre playhouse) ** Marek Vasut - Liberating the i.MX28 How long will these talks be? Twnty or thirty minutes? Sounds good. I'm not sure how the organization side of the summit is being setup, but I imagine we'll be able to talk about those things. We should of course plan for an open discussion at the end. Is there any link for about discussed topics with covered speakers, if yes please pass. No, we are just assembling it in this thread ;) Thanks Detlev -- Science is a way of thinking much more than it is a body of knowledge. -- Carl Sagan -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.10-rc1
Hi Tom, I've put v2013.10-rc1 out, and I hope Detlev can get the tarball uploaded soon. Thanks a lot - the tarball is now also available. Best wishes Detlev -- Support organized crime: use Micro$oft products! -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot mini-summit at ELCE 2013 in Edinburgh - call for participation!
Hi fellow U-Boot developers, people meeting us at our booth at the Embedded World trade show in Nürnberg this year may already have heard rumours about it but now it is official - there will be an U-Boot mini-summit at the Emdedd Linux Conference Europe in Edinburgh, UK [1]. Thanks to the wonderful people at the Linux Foundation, we will have some space in the afternoon of thursday 24th that we can use to present and discuss topics of interest for the immediate future of the project. Currently we believe that it makes sense to plan for 4-5 short talks in the range of 20-30 minutes with following QA. The audience will very likely be tech level and the presentations are thus allowed to have indecent technical content :) Of course everybody is invited to suggest a presentation, but an informal poll turned up these topics of interest: - Driver model - Kconfig - Patman tutorial - U-Boot configuration through device tree - Falcon boot for everybody - DFU - Android fastboot The organization of the mini-summit is up to our discretion and thus somewhat less formal than the regular ELCE tracks, but we would like to encourage people to also submit U-Boot related talks through the regular CFP[2] if they are of wide interest. Having agreed on our schedule, we will be able to get it included in the official conference schedule and thus hopefully get a broader visibility. To make this work we should finalize our schedule around the end of the official CFP which is July 21st, but of course the sooner, the better. Please inform us if you would like to attend in order to get an idea of the expected presence. If neccessary we will have to look for a larger place early on. Next to the official program I'm sure that we will be able to find a place in the evening to taste local culinary specialities (in solid and liquid form), so be sure to book your return flight no sooner than friday evening ;) Thanks Detlev [1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe [2] http://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp -- The only thing worse than generalizing from one example is generalizing from no examples at all. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Custodians, Maintainers and old platforms
Hi Marek, [...] It brings me to another question though, would it be possible to get a custodian tree for OpenRISC? CCing Detlev. Sorry for being late here - do we still need/want the OpenRISC tree? Actually I anticipated such a tree nearly five years ago[1] *lol*. Cheers Detlev [1] http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees?rev=1.1 -- I'm sorry that I long ago coined the term objects for this topic because it gets many people to focus on the lesser idea. -- Alan Kay on Object Oriented Programming -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2012.10-rc2 tar balls on ftp
Hi Tom, On Wed, Oct 03, 2012 at 02:25:58PM -0600, John Rigby wrote: On Wed, Oct 3, 2012 at 1:20 AM, Deltour, Stephane stephane.delt...@barco.com wrote: Hi, Would it be possible to have the v2012.10-rc1 and v2012.10-rc2 tarballs on the ftp site ? Have you tried the snapshots feature on the git.denx.de website? Note that snapshots are not stable in that they get flushed after a certain timeframe and re-created when needed so md5/sha256/etc will change. I've poked Detlev about adding tarballs to the FTP site. I uploaded tarballs to the server. Thanks Detlev -- Modern methods of production have given us the possibility of ease and security for all; we have chosen, instead, to have overwork for some and starvation for others. -- Bertrand Russell -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Makefile: fix HAVE_VENDOR_COMMON_LIB
Hi, On Tue, 14 Aug 2012 13:44:29 +0200 Daniel Schwierzeck daniel.schwierz...@gmail.com wrote: From: Scott Wood scottw...@freescale.com Commit 8b5a02640adf77301f943e8754992c50df004e8a (Makefile: cosmetic: optimize usage of LIBS-y) broke the build of boards that have a board vendor common directory, by introducing a space between LIBS- and y. Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- Changes vor v2: - fix the wrong spaces also in spl/Makefile Tested with: MAKEALL spear600 MAKEALL -s omap3 MAKEALL -s omap4 --- this fixes newly broken mpc83xx builds, e.g.: Configuring for MPC832XEMDS_ATM - Board: MPC832XEMDS, Options: PQ_MDS_PIB=1,PQ_MDS_PIB_ATM=1 make: *** [u-boot] Error 1 powerpc-fsl-linux-size: './u-boot': No such file board/freescale/mpc832xemds/libmpc832xemds.o: In function board_early_init_r': /home/r1aaha/git/u-boot/board/freescale/mpc832xemds/mpc832xemds.c:90: undefined reference to `pib_init' make: *** [u-boot] Error 1 So, Acked-by: Kim Phillips kim.phill...@freescale.com Applied, thanks. Cheers Detlev -- Science is a way of thinking much more than it is a body of knowledge. -- Carl Sagan -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX28: Add SchulerControl SC_SPS_1 platform
Hi Marek, This i.MX28 platform supports the following: * 2x FEC ethernet * USB on USBH0 * I2C EEPROM * SPI NVRAM * LEDs Signed-off-by: Marek Vasut ma...@denx.de Cc: Detlev Zundel d...@denx.de Acked-by: Detlev Zundel d...@denx.de Cheers Detlev -- ike|abel - Eine Partnerschaft erweist sich als ikeabel, wenn ein samstäglicher Besuch bei Ikea weder zur sofortigen Trennung noch zu tagelangen Diskussionen führt. In einigen urbanen Subkulturen hat der gemeinsame Ikea-Besuch die Ver- lobung vollständig ersetzt.-- Wortschatz v. Sascha Lobo -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi, How about amending the U-Boot design principles with Go for it - it's a wiki. Thinking about it, I turned it not into a rule, but into a Lemma from the 10 rules: Lemmas from the golden rules 1. Generic Code is Good Code New code shall be as generic as possible and added to the U-Boot abstraction hierarchy as high as possible. As few code as possible shall be added in board directories as people usually do not expect re-usable code there. Thus peripheral drivers should be put below drivers even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point. Feel free to amend / modify that. Cheers Detlev [1] http://www.denx.de/wiki/rdiff/U-Boot/DesignPrinciples?rev1=1.14rev2=1.13 PS: Ok, actually I didn't want to ruin the magic 10 ;) -- Question: If you were redesigning UNIX, what would you do differently? Ken Thompson: I'd spell creat with an e. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
the regular merge window are handled in-efficiently ending up as large piles in patchwork. It was agreed that rather then being a accept / don't accept division, it should be a accept into mainline / accept into -next branches split hopefully keeping the flow of incoming patches more uninterrupted. For this to work, every custodian would open his own -next branch and start merging patches from the mailing list resulting in patchwork becoming cleaner during bug fix phases. It was discussed whether to do some automatic merging of these per-custodian trees into a central next, but majority of people believed that the patch handling process should remain as unchanged as possible in sync with the principle of least surprise. * Continuous integration Discussing such automatic merges, the need for continous integration became apparant. As mid- to longterm goals we would like to see automatic builds shifting the requirement to do MAKEALL from individual posters to (cheap) machine time. One obstacle on this way is the complexity of automatic builds for different architectures, i.e. which toolchain to use and how to use them correctly. It was agreed to be a good thing to collect Mike's cross-toolchains on denx.de and ease running MAKEALL. Especially add more switches to MAKEALL for toolchain selection, log-, build- directories. Turn interpretation of environment variables into switches to be more in line with good unix practice. Simon Glass mentioned that he is working on buildman which he will present on the mailing list in due time. (Probably I forgot to mention the eldk-switch tool explicitely that also has a database to setup the ELDK environment for known targets: http://git.denx.de/?p=eldk-switch.git;a=summary Maybe it should be extended to cover other tool-chains also?) * Sandbox For people not being aware of the user-space U-Boot, i.e. the sandbox configuration, Simon Glass described actual use cases for it in his work. He used it as an excellent test bed for generic code and tests not easy to setup on real hardware. During the discussion it became obvious that it may be a very good enabling tool for the driver model changes to come. It was also found to be a worthwhile aim to integrate it into the DUTS framework. (I will look into that when time allows). * U-Boot driver model Having some more time on our hands, Marek Vasut was asked to interactively present some aspects of his and his teams work for a driver model. Additional to the key concepts shown in his presentation on thursday, it became clear that it would be extremely helpful if the Linux and U-Boot driver model would be as close as possible to ease porting _and_ maintenance of drivers from the former to the latter. It appears that the Linux driver model lacks the late initialization needed by the U-Boot initialize hardware only when needed design goal. Achieving it was one motivation to not simply clone the Linux driver model. Although this and other details were discussed very intensly, it was more than obvious that a lot of current problems and limits of scalability of our code base can be alleviated with a solid driver model. All participants agreed to more closely review the documents available in Mareks git Repo: git://git.denx.de/u-boot-marex.git (dm branch, doc/driver-model/) Discussion of the driver model currently is hosted at a separate mailing list: http://lists.denx.de/mailman/listinfo/u-boot-dm Maybe the discussion should be moved completely to the regular users mailing list. * Followup Meetings Most participants expressed interest into further meetings of the U-Boot developers in the future, probably once a year. We will actively look for occassions more closely tied to the embedded community for this. Ok, this was actually agreed on after the first couple of beers, but still I believe it fits in here nicely ;) * Organizational info Attendants (in alphebetical order of first names) Anatolij Gustschin Detlev Zundel Fabio Estevam François Revol (Haiku project) Marek Vasut Mike Frysinger Simon Glass Stefan Roese Stefano Babic Tom Rini Wolfgang Grandegger I'm sorry that I missed the name of one other participant who uses U-Boot on a re-implemented Atari ST (Hatari?) project and gave some interesting user feedback on several topics. Cheers Detlev -- A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan Perlis, Epigrams on Programming -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Wolfgang, [...] Sorry, but I disagree. How many board directories are there in U-Boot? Several hundreds... How many board directories did you check to make sure none of them contains any driver that is similar to what you implement here? If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy. I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions. To make sure everybody sees such code, we should really add it to the standard locations. According to the current situation, we have the choice of getting good code into a board directory or no code at all because Prafulla doesn't accept the code in its current incarnation into a general place. I don't need a crystal ball to see that the project will loose code this way. I'm sorry that the project rejects working code and I re-ask Prafulla to reconsider his NAK which has impact on the whole project. Cheers Detlev -- debian is a prototype for a future version of emacs. -- Thien-Thi Nguyen in 7eekubiffq@ada2.unipv.it -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Wolfgang, [...] If we place the driver in your board diretory, the chances are huge it will simply sit there and rot, and the next one who needs something similar will reinvent the wheel because he did not find your copy. I agree that even very simple and uncomplete implementations can co in if the fulfil some purpose, and can form a basis for future extensions. I just read through our documentation on the Wiki and found nothing relavant to such a topic. If we make this a requirement, we should add it so people know about it beforehand. How about amending the U-Boot design principles with 11. Keep It Generic - Generic code shall be added as high as possible to the U-Boot abstraction hierarchy and only as a last resort into board directories. This entails that peripheral drivers should be put below drivers even if they start out supporting only one specific configuration. Note that it is not a requirement for such a first instance to be generic as genericity generally cannot be extrapolated from a single data point. How does that sound? Cheers Detlev -- The only thing worse than generalizing from one example is generalizing from no examples at all. -- principles of X Window System -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Prafulla, [...] Hi Detlev Clear NAK for this patch Do you mean clear NAK for the patch or for the location of the files? Let's put it in drivers/net/phy/ FYI: there are several drivers used by just one board, [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn CONFIG_PHY_ATHEROS include/configs/* include/configs/microblaze-generic.h:346:# define CONFIG_PHY_ATHEROS1 [prafulla@pe-dt061 u-boot-marvell.git (master)]$ vim drivers/net/phy/Makefile [prafulla@pe-dt061 u-boot-marvell.git (master)]$ grep -Irn CONFIG_PHY_BROADCOM include/configs/* include/configs/microblaze-generic.h:347:# define CONFIG_PHY_BROADCOM 1 Anyways peripheral driver should go in drivers/ Ok, so if the files are moved to drivers/net/phy, then you will ACK the patch? If this is the case, then Valentin please move the files and be done with it. Cheers Detlev -- ... that every year or so they're going to give you a new release full of 50 000 additional lines of code all written by monkeys. Because they generally follow the ``million monkeys typing, and eventually they'll come up with something useful'' school of system development. -- Richard M. Stallman -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration
Hi Valentin and Prafulla, [...] Dear Valentin We must keep develop it as generic driver. Regards... Prafulla . . . Sure it would be great if we had the time and resources to contribute a generic driver for these switches. Unfortunately it is not the case and we have only developed a simple driver with limited features that suits our current needs. Since we know it's very limited, we have intentionally chosen to put in in our board/keymile directory so that it's obvious that it is (currently) not intended to be used nor was it tested on other boards or with other switches. Personally I welcome such a driver submission to mainline as it can be a starting point for someone else later. The question now is: does u-boot allow some boards (or family of boards) to integrate some board codes or drivers ? It was until now our understanding that u-boot allows this. This code definitely fits into this category. This is also my understanding and actually our source code has lots of them and many people are thankful to find such code (if they are able to find it ;) As for the generic driver, if someone contributes one (the current driver can be used as a basis), we will be very happy to drop this code and use the generic driver. Actually I would go even further and say that a generic driver can only be started when there are at least two or more users of the code. One should probably think about not making too many short-sighted assumptions when working on a driver but to think that one could develop a generic driver from one device only would be foolish. So Prafulla, can you please reconsider to add the driver? Thanks Detlev -- Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands. -- principles of X Window System -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood
Hi Prafulla, [...] But 01-08 are not only bugfixes there are also two new boards in these patches. So will you pull these eight patches in if I post them again without 09-14? Pls post bug fixes and improvement patches first those will be pulled faster. May I please ask you to reconsider your stance on the patch sets from Holger? As far as I can see, he explained a few times by now why and how he grouped the patches like he did. And to be honest, I _can_ understand his reasoning and believe it to be well-founded. After all, our requirements come from _practical_ considerations, i.e. bisectability, code size reductions, etc. but in the end they are all compromises in one way or another. So usually we do not invent new requirements for the sake of requirements, but in order to improve the situation if the net effect is positive for the project as a whole. Of course it is a fact that the effort for reviewers is non-negligible, but we have to draw a line somewhere in the area where the well-formedness of patch sets and the ease of reviewing them needs to be compromised. I do not like to see added complexity in patch sets so that reviewing gets easier. As far as I can see, this is the current situation and thus I would like you to reconsider and rather spend some more time on the review process of the whole patch series as it is. Thanks in advance Detlev -- The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28: Fix elftosb source link in README.mx28_common
Hi Marek,
Dear Anatolij Gustschin,
The documented link to elftosb package tarball is not accessible,
change to another working link.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Marek Vasut marek.va...@gmail.com
Cc: Fabio Estevam feste...@gmail.com
---
doc/README.mx28_common |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 448d221..fab0e32 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -29,14 +29,14 @@ is the mxsboot tool found in U-Boot source tree.
Firstly, obtain the elftosb archive from the following location:
-http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
+
http://repository.timesys.com/buildsources/e/elftosb/elftosb-10.12.01/elf
tosb-10.12.01.tar.gz
We use a $VER variable here to denote the current version. At the time of
writing of this document, that is 10.12.01. To obtain the file from
command line, use:
$ VER=10.12.01
-$ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
+$ wget
http://repository.timesys.com/buildsources/e/elftosb/elftosb-${VER}/elftos
b-${VER}.tar.gz
Extract the file:
That's sad, maybe we should mirror this package and be done with it?
Wolfgang/Detlev?
Somewhat late, but still the file can now also be found here:
ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
Cheers
Detlev
--
Music scenes ain't real life / They won't get rid of the bomb
Won't eliminate rape / Or bring down the banks / any kind of change
Takes more time and work / than changing channels on a TV set
-- Jello Biafra
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx28: Fix elftosb source link in README.mx28_common
Hi Anatolij, The documented link to elftosb package tarball is not accessible, change to another working link. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam feste...@gmail.com Acked-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Detlev Zundel d...@denx.de Thanks Anatolij! Detlev -- Man is a fool, and woman, for tolerating him, is a damned fool -- Mark Twain -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX28: Add delay after CPU bypass is cleared
Hi Stefano, On 04/05/2012 13:32, Marek Vasut wrote: This solves issues when larger amount of DRAM is used, like 256MB. Behave the same in case of CPU bypass as we do in case of EMI bypass, but wait 15 ms. We need to wait until the clock domain stabilizes. This issue seemed to have been caused by not waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh. The conclusion is, trying a semi-random delay (there is delay after the EMI bypass change), the issue is fixed. Another possible explanation is that we do not do the simple memory test FSL does in their imx-bootlets (1000 R/W cycles to/from piece of the memory, while also outputing something on the serial port). This might have caused the similar delay in the imx-bootlets and therefore they didn't need to add this explicitly. For now, this seems good fix enough, but to me, whole that memory init code in imx-bootlets is completely flunked and it'd need deeper investigation. Signed-off-by: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Detlev Zundel d...@denx.de Cc: Stefano Babic sba...@denx.de Cc: Fabio Estevam feste...@gmail.com --- arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |2 ++ 1 file changed, 2 insertions(+) V2: Change the description, this issue seemed to have been caused by not waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh. V3: Add more conspiracy theories into the commit message. diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c index 0d13537..9fa5d29 100644 --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c @@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void) /* Disable CPU bypass */ writel(CLKCTRL_CLKSEQ_BYPASS_CPU, clkctrl_regs-hw_clkctrl_clkseq_clr); + +early_delay(15000); } It is fine with me Acked-by: Stefano Babic sba...@denx.de I'm also content with the commit message now, so I don't want to block this anymore. Acked-by: Detlev Zundel d...@denx.de Cheers Detlev -- Sab|bert|jahr - Umgangssprachlich für Elternzeit -- Wortschatz v. Sascha Lobo -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared
Hi Marek, This solves issues when larger amount of DRAM is used. Behave the same in case of CPU bypass as we do in case of EMI bypass, wait 15 ms. We need to wait until the clock domain stabilizes. Sorry to be somewhat persistent here, but can you please include the information what larger amount of DRAM is that this delay works for? Also is this guessed, measured or calculated? The reason why I am so persistent is that this is _available_ information now and it will be very valuable information for the next person reading the code while pondering the question ok, this worked in the past, but maybe it is a problem on my brand new hardware. Thanks Detlev -- Whenever you find yourself on the side of the majority it is time to pause and reflect. -- Mark Twain -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Revert i.MX28: Enable additional DRAM address bits
Hi Marek, This reverts commit 69d26d09de1cb93e0a09ca71d9f0d41a66f0756a. Apparently, this commit got mainline only because of OOT port and causes breakage on board that is mainline. Revert. To be honest, I don't understand what this patch or what the original patch did, nor through what OOT port this hit mainline and what breakage it causes on other boards. So also I can read the sentence, I cannot make heads and tails of it. Can you please write commit messages that people like me can make some sense from? I.e. answering the following questions would help me - What does the original commit do? (its too late to change the original commit) - Why was the change made in the first place and for what OOT port? - What breakage is caused on what boards? - Why can we revert the change without any problems? Thanks Detlev -- #!/usr/bin/perl -l print ((1 x shift) !~ /^(11+?)\1+$/ ? prime : not prime); -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] i.MX28: Increase the delay after DRAM init
Hi Marek, Dear Fabio Estevam, On Wed, May 2, 2012 at 7:14 PM, Marek Vasut ma...@denx.de wrote: This solves issues when larger amount of DRAM is used. Shouldn't we check if we are using a large amount of DRAM? If we don't check then even boards with small amount of RAM would have this additional delay. I'm afraid this worked on boards with a small amound of RAM by sheer accident (or good will of the DRAM), time to play safe and fix this. Can you please comment on why we are waiting and why we are waiting exactly this long? Can we maybe poll the needed time somehow? Thanks Detlev -- Less talking -- more hacking -- Olin Shivers -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Revert i.MX28: Enable additional DRAM address bits
Hi Marek, [...] - Why was the change made in the first place and for what OOT port? Change of a DRAM configuration register that enabled additional address bit, at address 512MB of DRAM. Though this caused memory hole on our M28 module with 256MB of DRAM, which _is_ mainline. X board is OOT and never will be mainlined I guess. I still do not understand this fully. What exactly is this memory hole and why is it fatal? As far as I can remember, there are always some holes in the adress map, so why is this special? Apart from that, I think most of these answers should go into the commit message to understand what is happening. Thanks in advance Detlev -- Every generation laughs at the old fashions, but follows religiously the new. -- Henry David Thoreau -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] INIT_FUNC - List madness
Hi Graeme, [...] Now I just need to write the code that will order the function list Did you check 'man tsort'? Cheers Detlev -- I've been examining the existing [linux] kernel configuration system, and I have about concluded that the best favor we could do everybody involved with it is to take it out behind the barn and shoot it through the head. -- Eric S. Raymond on linux-kbuild Mar 2000 -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] i.MX25: Has a GPIO4 too
Hi Timo,
On 12.04.2012 15:10, Wolfgang Denk wrote:
Please make sure to run your patches through checkpatch !
Sorry about that.
Now I could use some help about how to best edit my commits...
What works very nicely for me is to do the changes, do git add on them
and then do a
COMMIT=commit ; git commit --squash=$COMMIT ; git rebase -i --autosquash
${COMMIT}^
(substitute commit with the commit-ID of the commit in question). In
the editor you can decide to add more to the messages, or simply leave
them as is.
I'm sure you will find the details on how this works and why in the
manual ;)
Cheers
Detlev
--
Some mathematicians become so tense these days that they do not go to
sleep during seminars.
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] UBIFS: Improve error message when reading superblock failed
Hi Bernhard,
In addition to the error message also display the error code. I had the
problem that my malloc memory was not enough (ENOMEM), and if u-boot
had displayed the error code immediately that would have saved me some
debugging.
Signed-off-by: Bernhard Walle wa...@corscience.de
---
fs/ubifs/super.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 26b48f0..0b1440b 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1191,7 +1191,7 @@ int ubifs_mount(char *vol_name)
mnt = NULL;
ret = ubifs_get_sb(ubifs_fs_type, flags, name, data, mnt);
if (ret) {
- printf(Error reading superblock on volume '%s'!\n, name);
+ printf(Error reading superblock on volume '%s': %d!\n, name,
-ret);
return -1;
}
I think this makes sense, but I think it would be more natural to print
the real error code, not the negative value. I don't know how to search
for all such occurrences, but I cannot find any but a lot of sites
printing the error code as is.
Cheers
Detlev
--
The fact is, volatile on data structures is a bug. It's a wart in the C
language. It shouldn't be used.
-- Linus Torvalds
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] command, log: Coding Style cleanup
Hi f, Signed-off-by: Heiko Schocher h...@denx.de Our wiki[1] explicitely encourages such white-space only changes to be marked as cosmetic: to make review easier. Apart from that: Acked-by: Detlev Zundel d...@denx.de [1] http://www.denx.de/wiki/U-Boot/Patches -- The continental people think life is a game. The English think cricket is a game. -- George Mikes -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] command, log: print log-v2.con value in the log info command
Hi f, print in the log info command, if log_version = 2 also the value from log-v2.con. Signed-off-by: Heiko Schocher h...@denx.de Looks plausible. Acked-by: Detlev Zundel d...@denx.de -- Woman who seek to be equal with men lack ambition -- Timothy Leary -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] UBIFS: Improve error message when reading superblock failed
Hi Bernhard,
Hi Detlev,
* Detlev Zundel d...@denx.de [2012-02-17 15:15]:
@@ -1191,7 +1191,7 @@ int ubifs_mount(char *vol_name)
mnt = NULL;
ret = ubifs_get_sb(ubifs_fs_type, flags, name, data, mnt);
if (ret) {
- printf(Error reading superblock on volume '%s'!\n, name);
+ printf(Error reading superblock on volume '%s': %d!\n, name,
-ret);
return -1;
}
I think this makes sense, but I think it would be more natural to print
the real error code, not the negative value. I don't know how to search
for all such occurrences, but I cannot find any but a lot of sites
printing the error code as is.
well, the return value is negative, so my intention was to print the
error code as positive number. So you think we should display it as
negative number (-12 instead of 12 for ENOMEM)?
Personally I believe that any transformation in the printing can mislead
people in the search for the cause or the responsible code.
So if the error value is -12, then we should print it. After all, the
assignment to generate that value will very likely be return -ENOMEM
and people will thus know what to look for.
On the other hand I am open to the consistency argument, so if every
error printing would do such a transformation then it would be better to
also do it. But as I said, I don't know an easy grep pattern to search
for such locations and quick searches showed that I all places I found
print the error codes unmangeld.
Cheers
Detlev
--
Basically, Barnes Noble separates things by how old they are -- current
stuff is Fiction, stuff from 20 years ago is Literature, stuff from 100
years ago is Classics, stuff from 400 years ago is Shakespeare [..] and
stuff from 2000 years ago is History.
-- James Kibo Parry in kibo-120703221201@10.0.1.2
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] command, log: print with log show a full logbuffer
Hi Heiko,
If the logbuffer contains LOGBUFF_LEN chars, they never got
printed with the log show command, because chars get
printed with the following for loop:
for (i = 0; i (size LOGBUFF_MASK); i++) {
with size = LOGBUFF_LEN and LOGBUFF_MASK = (LOGBUFF_LEN-1)
for loop never executed ...
Fix this.
Signed-off-by: Heiko Schocher h...@denx.de
Indeed a good catch!
Acked-by: Detlev Zundel d...@denx.de
--
LISP is the most powerful programming language, and if you want an inter-
preter, LISP is the best. None of the other languages come anywhere near
LISP in their power. The most exciting things about LISP are read, eval,
and print. If you look at other languages, they have no equivalent for
any of those. -- Richard Stallman
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to run scripts with autoscr command
Hi Asif, Im using u-boot version U-Boot 1.3.4 (Dec 9 2010 - 17:45:52) DM365-IPNC-1.0.14 on a davinci_dm365 board, what is the DM365-IPNC-1.0.14 version about? I cannot see such a version (or tag) in mainline U-Boot. I'm trying to run script under U-boot using autoscr command, since I don't see any source command ported into this version of U-boot yet, Yes, it was renamed at some point: commit 74de7aefd79690bae8cf5a5120f5962d444be089 Author: Wolfgang Denk w...@denx.de Date: Wed Apr 1 23:34:12 2009 +0200 Add source command; prepare removal of autoscr command According to the doc/feature-removal-schedule.txt, the autoscr command will be replaced by the source command in approximately 6 months from now. This patch prepares this change and starts a 6 month transition period as follows: - The new source command has been added, which implements exactly the same functionlaity as the old autoscr command before - The old autoscr command name is kept as an alias for compatibility - Command sequences, script files atc. have been adapted to use the new source command - Related environment variables (autoscript, autoscript_uname) have *not* been adapted yet; these will be renamed resp. removed in a separate patch when the support for the autoscr command get's finally dropped. Signed-off-by: Wolfgang Denk w...@denx.de [dzu@pollux u-boot-testing (master)]$ git describe --contains 74de7aefd79690bae8cf5a5120f5962d444be089 v2009.06-rc1~110 [dzu@pollux u-boot-testing (master)]$ So indeed, this cannot be in your version 1.3.4 but autoscr isn't executing commands like -if -then -while in the script, gives the following error: *Unknown command 'if' - try 'help'* *After this I tried enabling the hush shell by setting the following in the config file for respective board,* This is indeed the problem, the used shell is not powerful enough to do such scripting. Using the hush shell will indeed solve the original problem. #define CFG_HUSH_PARSER #define CFG_PROMPT_HUSH_PS2 = #undef CONFIG_BOOT_RETRY_TIME #undef CONFIG_RESET_TO_RETRY #define CONFIG_AUTOSCRIPT 1 #define CONFIG_CMD_AUTOSCRIPT *but after this when I reboot the board, I get indefinite repetative display of the u-boot prompt as below:* Jumping to entry point at 0x8108 DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 Jumping to entry point at 0x8108 DM36x initialization passed! TI UBL Base Version: 1.50 Boot Loader BootMode = NAND Starting NAND Copy... Valid magicnum, 0xA1ACED66, found in block 0x0008. Boot Mode Task Completed IPNC UBL Version: 1.1.0 Platform: DM365 ... what might be the problem, early help would be much appreciated. It seems that by changing your configuration somehow the increase in code size has broken the compilation. Did you see any errors or warnings while compiling? On the other hand, davinci_dm365evm is a supported configuration in mainline, so why not try current code. This way we would be in a much better position to help you. Thanks Detlev -- Wissenschaft ohne Verstand ist doppelte Narrheit. --- Baltasar Gracian -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mcx: Enable command line editing
Signed-off-by: Detlev Zundel d...@denx.de CC: Stefano Babic sba...@denx.de --- include/configs/mcx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/mcx.h b/include/configs/mcx.h index 0940e86..fcc32d6 100644 --- a/include/configs/mcx.h +++ b/include/configs/mcx.h @@ -219,6 +219,8 @@ else run nandboot; fi #define CONFIG_AUTO_COMPLETE +#define CONFIG_CMDLINE_EDITING + /* * Miscellaneous configurable options */ -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about baud rate
Hi Dan, I'm using a board similar to canyonlands with a ppc460ex. The baud rate for ttyS0 is set to 115200 by the console= bootarg, but I'd also like to set ttyS1-3 to 115200 also. Why doe you want to setup this parameters from the outside? Really only the serial device used for a console needs to be setup by firmware. All other serial devices should be initialized by the user space programs using them. For each of the three uarts, the device tree has the following line: current-speed = 0; /* Filled in by U-Boot */ Checking current U-Boot code, I believe this comment is simply wrong. I cannot see any part in the canyonlands / or generic 4xx infrastructure that fixes up these properties. Maybe Stefan can comment on this though. How do I go about configuring u-boot to fill these with the baud rate I choose? Sorry for the silly question! I don;t think its a silly question, but I also think that you do not need the configuration ;) Cheers Detlev -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot
Hi, I am trying to boot beagle board by uart can anybody help me on this issue? I am sorry but I do not understand what you are trying to do. Can you please explain a bit more on what you want to do and what is not working? A good question[1] is the prerequisite for a good answer ;) Cheers Detlev [1] http://catb.org/~esr/faqs/smart-questions.html -- Due to the change in scope, STUN has also been renamed from Simple Traversal of UDP through NAT to Session Traversal Utilities for NAT. The acronym remains STUN, which is all anyone ever remembers anyway.-- rfc5389 -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodians - please lend a hand
Hi Stefano, On 11/16/2011 07:51 PM, Wolfgang Denk wrote: Wolfgang, Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. I have tried with a couple of patches (network related), and then I wanted to test if push works. As u-boot-staging should be open for all custodians, I was expecting I should use the same mechanism, and then I tried with: git push ssh://gu-...@git.denx.de/u-boot-staging sba...@denx.de ...but the new branch sba...@denx.de is now part of u-boot-imx, not u-boot-staging ! Where is the mistake ? Indeed - this is because of the setup of the custodian trees. The git action is directly coupled to the user account so the account gu-imx will _only_ be able to work inside that tree. Effectively, the directory part of the URL is discarded... The correct usage is of course as Wolfgang points out through the gu-staging user. Best wishes Detlev -- Due to the change in scope, STUN has also been renamed from Simple Traversal of UDP through NAT to Session Traversal Utilities for NAT. The acronym remains STUN, which is all anyone ever remembers anyway.-- rfc5389 -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
Hi Thierry, * Stefano Babic wrote: On 11/17/2011 08:56 AM, Thierry Reding wrote: I had actually set Doug Anderson diand...@chromium.org on Cc because he was involved with the initial patch but for some reason he got stripped from Cc. Does anybody know why this is happening? Probably Doug has received the first e-mail. I noted that git send-email strips the CC addresses (maybe to avoid SPAM ?), but the e-mail is sent anyway. I don't think git send-email is stripping the Cc header because I've seen it work properly for other mailing lists. Perhaps the mailing list software is the culprit here? Could it be that it strips people that are subscribed (and will receive the mails anyway) but not those that aren't subscribed? Not that Tom Warren wasn't stripped from Cc. Actually I know that sometimes there are such phenomena on the mailing list, but as yet I failed to find a reason for it. What I saw in the past is that the CC field of individual mails sent to individual subscribers has a reduced CC field with respect to the original mail, i.e. a mail I received had a stripped header compared to what is in the archives. I will try to look into this when I find some time. Cheers Detlev -- Whatever you do will be insignificant, but it is very important that you do it. -- Mahatma Gandhi -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about baud rate
Hi Dan, Why doe you want to setup this parameters from the outside? Really only the serial device used for a console needs to be setup by firmware. All other serial devices should be initialized by the user space programs using them. I would like my startup script to cat messages to ttyS1, as well as to the console (ttyS0). Basically for the purpose of informing users that the firmware cannot execute for some reason (we don't like to give access to the console). I was trying to avoid including stty or setserial, but if this is the accepted way to configure the serial port it's not a big deal ;-) Personally I believe that every software task should setup as much as possible from what it knows to be needed for its own work. For a serial program this includes setting the baud rate and the communications parameter like 8/n/1. For each of the three uarts, the device tree has the following line: current-speed = 0; /* Filled in by U-Boot */ Checking current U-Boot code, I believe this comment is simply wrong. I cannot see any part in the canyonlands / or generic 4xx infrastructure that fixes up these properties. Maybe Stefan can comment on this though. Interesting...I also tried manually entering a value here, but it didn't seem to have any effect. Maybe it just isn't used? This may very well be the case. An answer can probably be found on the linux ppc mailing list[1] ;) Sorry for the silly question! I don;t think its a silly question, but I also think that you do not need the configuration ;) Cheers Detlev Thanks for your response! You're welcome! Detlev [1] http://dir.gmane.org/gmane.linux.ports.ppc64.devel PowerPC developers ML linuxppc-...@ozlabs.org -- Every time history repeats itself the price goes up. -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: Correct build error introduced by getenv_ulong() patch
Hi Graeme,
Hi Wolfgang
On Wed, Nov 9, 2011 at 9:49 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon Glass,
In message
capnjgz15f_gva5+mm1em-l2smxt1waatxqikuhoqat893t9...@mail.gmail.com you
wrote:
This discussion was regarding the need to #ifdef the variable declaration,
viz:
#if defined(THING1) || defined(THING2)
const char *cat;
#endif
...
#ifdef THING1
cat = getenv(cat);
send_back(cat);
#endif
#ifdef THING2
cat = check_outside(cat);
if (cat)
wibble(cat);
#endif
and whether the top bit would be better as:
__maybe_unused const char *cat;
But more generally, lots of #ifdefs do make the code harder to read,
and potentially more brittle in the face of config changes.
I would like to see only a minimal number of __maybe_unused in the
code - in cases, where this is the way that hurts least.
In the examples above, it might be better to use local blocks, like:
#ifdef THING1
{
const char *cat = getenv(cat);
send_back(cat);
}
#endif
I honestly think most of these cases can be factored out into functions.
The compiler should inline them anyway so the overhead should be zero.
The various board.c files are a prime example of where this should be
done as a matter of principle to reduce the complexity and lenght of
the primary function anyway
I would even like to skip the ifdefs completely. Modern compilers with
dead code elimination will completely do away unneeded code _but still
do syntax checks on the parts every time_.
So maybe we should simply try to use
if (THING1)
{
...
}
I know that this would need an #ifdef THING1 1 but errors in this
would be caught immediately (and not only under a certain combination of
ifdefs) by the compiler so I don't think this is a problem.
I don't know how often I repeat my mantra, but every ifdef doubles
the number of _different source codes_ that we deal with.
Cheers
Detlev
--
Lotus Notes (GUI): Run away from it.
-- linux/Documentation/email-clients.txt
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove broken boards csb226 and innokom
Hi Albert,
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
CREDITS |4
MAINTAINERS |5 -
arch/arm/include/asm/arch-pxa/hardware.h |8
boards.cfg |2 --
doc/README.scrapyard |2 ++
5 files changed, 2 insertions(+), 19 deletions(-)
[...]
diff --git a/arch/arm/include/asm/arch-pxa/hardware.h
b/arch/arm/include/asm/arch-pxa/hardware.h
index 44b800f..655c0b9 100644
--- a/arch/arm/include/asm/arch-pxa/hardware.h
+++ b/arch/arm/include/asm/arch-pxa/hardware.h
@@ -108,14 +108,6 @@ extern unsigned int get_lclk_frequency_10khz(void);
#include cerf.h
#endif
-#ifdef CONFIG_ARCH_CSB226
-#include csb226.h
-#endif
-
-#ifdef CONFIG_ARCH_INNOKOM
-#include innokom.h
-#endif
Could you please also remove these header files?
Also the whole board/{innokom,csb226} directories are now superflous,
right?
Cheers
Detlev
--
Two monks went fishing in an electron river. The first monk drew out his
network, and out flopped a hacker. The second monk cried, The poor hacker!
How can it live outside of the network? The first monk said, When you
have learned to live outside the network, then you will know.
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: Correct build error introduced by getenv_ulong() patch
Hi Mike,
On Monday 31 October 2011 17:06:46 Simon Glass wrote:
On Sun, Oct 30, 2011 at 5:44 PM, Mike Frysinger wrote:
On Sunday 23 October 2011 23:44:35 Simon Glass wrote:
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
flash_size = flash_init();
if (flash_size 0) {
# ifdef CONFIG_SYS_FLASH_CHECKSUM
+ char *s = getenv(flashchecksum);
+
print_size(flash_size, );
/*
* Compute and print flash CRC if flashchecksum is set to
'y' *
* NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
*/
- s = getenv(flashchecksum);
if (s (*s == 'y')) {
printf( CRC: %08X, crc32(0,
(const unsigned char *)
CONFIG_SYS_FLASH_BASE, @@ -566,9 +567,12 @@ void board_init_r(gd_t *id,
ulong dest_addr) /* Initialize from environment */
load_addr = getenv_ulong(loadaddr, 16, load_addr);
#if defined(CONFIG_CMD_NET)
- s = getenv(bootfile);
- if (s != NULL)
- copy_filename(BootFile, s, sizeof(BootFile));
+ {
+ char *s = getenv(bootfile);
+
+ if (s != NULL)
+ copy_filename(BootFile, s, sizeof(BootFile));
+ }
#endif
seems like a better solution would be to use at the top:
__maybe_unused char *s;
also, shouldn't these be const char *s ?
We can certainly do this and I agree it is easier than #ifdefs. Does
it introduce the possibility that one day the code will stop using the
variable but it will still be declared? Is the fact that we need the
#ifdefs an indication that the function should be too long and should
be refactored? it in fact better to have these explicit so we can see
them for the ugliness they are?
yes, you're right that it does leave the door open to the variable being
declared, never used, and gcc not emitting a warning about it.
both setups suck, but i'd lean towards the less-ifdef state ... wonder if
Wolfgang has a preference.
Personally, I think that the nuisance of a potential unused variable is
less of an issue than the actual _problems_ that ifdefs induce.
Cheers
Detlev
--
The best way to predict the future is to invent it.
-- Alan Kay
--
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: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: initial implementation
Hi Andrzej, [...] If my assumption is correct, then what would it take to split off protocol part and make it independent of the actual driver interface? I guess that in the situation given it would be of little use. What do you think would be of little use? As far as I understand you correctly, you would like the state machine code extracted from the initial DFU implementation posted on this mailing list. And then you would like the DFU implemented in terms of this abstract state machine. This means actually more code, probably not a desired thing. The generic state machine would also require some accompanying generic data structures, and this would also mean code to translate back and forth between USB/DFU (DFU _is_ USB) and state machine's data structures. All in all, this means adding more complexity and code. This looks like a premature optimization (which is widely known to be the root of all evil), while at the moment, there are no use cases to justify it. Should the use cases appear, the code can be reworked based on the needs of both USB/DFU and new state machine users. Just to add my personal opinion here - I am occassionally lobbying for a long time on this mailing list that mainline U-Boot gains DFU support, so please let's get this working with the existing tools and in the existing contexts, i.e. USB. Personally I consider it to be completely out of scope to dis-entangle DFU from its specification and abstract it into something which it _could_ be, but really _isn't_. When the implementation for USB is here, we all have much better grounds to discuss possible generalizations (although I doubt that there are many). Cheers Detlev -- Perfecting oneself is as much unlearning as it is learning. -- Edsger Dijkstra -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Hello Wolfgang and Nicolas, please allow me to barge in at that point. As I strongly believe that we all want to advance our software in a technical sense and not spend time in flame wars - I am trying to think of ways forward from the current state of affairs. Without evaluating all the arguments individually, let me pick up Wolfgangs latest suggestion which indeed seems like a pragmatic way forward: | I suggest the following: | | - I will apply Stephen's previous patches to support relative images | as they are useful for people who want to use proper uImages | (containing a raw kernel image as payload) on different boards / | architectures. | | - If you want to boot zImages (with the kernel wrapper included and | thus fully relocatable), then please feel free and submit patches to | add support for booting zImage format in U-Boot. Then you get what | you want, and you can use zImages directly, without the 64 byte | uImage header that is only hindering for your usage mode. | | - It would be appreciated if we could get support for real uImages | (wrapping a raw kernel image) into Linux, then. | | This way those who want to use zImages can do so, and those who prefer | a different approach can have their ways, too. My hope is that we can re-start the discussion from this - which actually looks like a consensus. For the unlikely but probable case of further disagreement, I propose a vote on the mailing list as an emergency tie breaker. As we previously did not need to resort to such a measure, we do not have a formal procedure ready for such a thing. Thinking about it a little while, it would probably make sense to have people vote on the issue that demonstrably care about the software and have invested substantial effort in it. A natural choice for such a set people are of course the custodians. So I would suggest to instantiate a poll among the custodians as such a tie breaker if needed. What do you think - is this a way forward? Thanks Detlev -- Perfecting oneself is as much unlearning as it is learning. -- Edsger Dijkstra -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] env: add regex support for environment variables
Hi Wolfgang, this really is an interesting addition! Syntax: env regex [-g] [-s subst] regex name [...] The code is based on SLRE (http://slre.sourceforge.net/) which provides a tiny subset of Perl regular expressions. Without options, this will implement regex pattern matching on environment variables. Variables with matching values will be printd as with env print, so this basicly performs a grep on the given list of variables. Ok, this usage looks fine. With -s subst, the matching pattern gets replaced with the string given in subst. Back references '\0' ... '\9' are allowed, where '\0' stands for the whole matched string, and '\1', '\2', ... are replaced with the first, second, ... sub-pattern. -g allows for global replacement. But IMHO this usage doesn't really belong into the env command. It much rather is a further operation of the setexpr command: set environment variable as the result of eval expression, name value1 op value2\n - set environment variable 'name' to the result of the evaluated\n express specified by op. op can be , |, ^, +, -, *, /, % We could add the operations for regsubst and regsubstg. For actual names for the operations, I'm somewhat unsure. Maybe function like, i.e. regsubst(string, pattern, replacement) and regsubstg(string, pattern, replacement)? Examples: = setenv foo abcdefghijklmnop = env reg 'A' '[bdgmo]' foo = env reg -s 'A' '[bdgmo]' foo foo=aAcdefghijklmnop = env reg -g -s 'B' '[bdgmo]' foo foo=aAcBefBhijklBnBp = env reg -g -s '\\2--\\1' '(Be).*(kl)' foo foo=aAckl--BeBnBp So I'd vote for = setenv result regsubst($foo, '[bdgmo]', 'A') What do you think? Cheers Detlev -- To you I'm an atheist; to God, I'm the Loyal Opposition. -- Woody Allen -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
