Re: [U-Boot] [PATCH 0/8] U-Boot port to Xtensa architecture
Hi Michal, On Fri, Aug 29, 2014 at 6:46 AM, Michal Simek wrote: > On 08/29/2014 02:25 PM, Max Filippov wrote: >> On Fri, Aug 29, 2014 at 3:50 PM, Michal Simek wrote: >>> Any link to bitstreams? I have ml605 and kc705 here and will be nice to >>> test it. >> >> The board alone is not enough to boot xtensa software, as the JTAG connector >> capable of loading code into CPU goes on a separate daughterboard that plugs >> into FMC connectors. I will check if I can share a bitstream and if it may be >> somehow used with the FPGA board alone. > > Any link to that FMC connector and connections there? > >> However you should be able to test with qemu, as it simulates all necessary >> hardware. Some examples are listed here: >> http://wiki.linux-xtensa.org/index.php/Xtensa_on_QEMU > > I am more interested to see this work on real HW than on qemu. Tensilica IP group is willing to provide you the bitstream and the related documentation, but for its own protection it wants you to sign a license agreement. It is said to be short and written in plain language. I will provide additional details privately. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi all, Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining: http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page TI also has a very nice article in Electronic Products on the benefits of mainlining Linux ... http://www.electronicproducts.com/Software/Development_Tools_and_Software/The_benefits_of_Mainline_Linux_and_the_mindset_of_upstream_development.aspx Altera would benefit from a similar philosophy. Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message <541373ad.4020...@opensource.altera.com> you wrote: > > Then I vote for myself as the custodian for u-boot-socfpga. By the way, May I ask what made you change your mind like that? First you wrote that Vince was assigned to to that, and now it's suddenly you? As far as I can see, you have not participated in any SoCPGA related code reviews or discussions in 2014 at all, so what would be the difference? > what is the difference between a Maintainer and a custodian? I don't > understand why if Chin-Liang and myself are listed as Maintainer(s) for > SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA? A maintainer is someone who developed some piece of code and feels responsible for it - who is available as contact person for questions, or who will be asked to fix any bugs in that code. A Custodian is "one that guards and protects or maintains" [1], i. e. he is responsible for maintaining the design principles of U-Boot and the code quality even for code he did not work on himself, and for patches submitted by others. This is a job that carries a much higher responsibility than just maintaining your own code. He will interface to the actual maintainers of the respective code, negotiatiate solutions and decide in case of conflicts. [1] http://www.merriam-webster.com/dictionary/custodian > Yes, this is the repo will be the one that we will use. I have a couple > of other things on my plate at the moment and will populate this repo > shortly. Thats great, as it means you will not lose any efforts when we start with u-boot-socfpga now, as you then can start with synchronized repositories right from the beginning. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "In the long run, every program becomes rococo, and then rubble." - Alan Perlis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message <5413667d.50...@opensource.altera.com> you wrote: > > Wolfgang's advice is valuable and noted. However, it is in Altera's > best interest that we have 1 central gathering point for all our > opensource software support. Full agreement here. But I would like to point out that your point of view appears to be biased: U-Boot mainline is a community project, and the community is very much vendor-independent. So the question we're trying to solve here is not what is optimal for Altera, but what is optimal for the community. As is, current mainline U-Boot is not really working well on most SoCFPGA systems. Progress is dissatisfactory slow. Marek volunteers to help out now, and you promise to chime in very soon. I see no conflict here. Let us create the u-boot-socfpga repository we need in any case, and agree with Marek as custodian until Vince has gathered enough reputation to relieve Marek. I talked to him - he is not clinging to that job, he just sees the need to get the current problems solved now, not in some uncertain future. Please try to understand that this is totally unrelated to what you do at u-boot-socfpga-next - it does not influence your work there in any way. Ideally, your u-boot-socfpga-next and the mainline u-boot-socfpga repositories would be just redundant copies. On the other hand, setting up u-boot-socfpga now allows the community to make some progress until you (rsp. Vince) start populating u-boot-socfpga-next and gather experience working with the community. So it is actually in both the community's and Altera's best interest to get a mainline u-boot-socfpga set up without further delay. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Well, the way I see it, logic is only a way of being ignorant by num- bers. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 05:14 PM, Wolfgang Denk wrote: > Dear Dinh, > > In message <54136276.6040...@opensource.altera.com> you wrote: >> >>> To get patches or new code into U-Boot mainline, these have to be >>> submitted to the U-Boot mailing list (among other purposes for >>> archival and that they get stored in the patchwork database). Then a >>> peer review takes place, and the responsible custodian finally applies >>> these patches to the respective custodian repository. Finally, he >>> sends a pull request to the next higher custodian - in case of SoCFPGA >>> that would be Albert as ARM custodian. >> >> Does the above process differ from the Linux community process in >> anyway? If not, then I've been doing the same for the Linux support for >> SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling >> from the git repo at rocketboards for quite some time now. I think I can >> probably do the same for u-boot. > > I think we are a bit more critical here in U-Boot. The repositories > we pull from are maintained by community-assigned custodians, who have > a proven track record not only as experienced developers, but also for > working with the community and being able to negotiate conflicts. > > If Vince gets appointed as custodian for socfpga, there should be no > problem for him to automatically synchronize your u-boot-socfpga-next.git > repository with the U-Boot u-boot-socfpga one. Then I vote for myself as the custodian for u-boot-socfpga. By the way, what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA? > > On the other hand - what exactly is the code you are referring to in > u-boot-socfpga-next.git ? At the moment, I see this: > > -> git clone > git://git.rocketboards.org/u-boot-socfpga-next.git > Cloning into 'u-boot-socfpga-next'... > warning: You appear to have cloned an empty repository. > Checking connectivity... done. > Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message <54136276.6040...@opensource.altera.com> you wrote: > > > To get patches or new code into U-Boot mainline, these have to be > > submitted to the U-Boot mailing list (among other purposes for > > archival and that they get stored in the patchwork database). Then a > > peer review takes place, and the responsible custodian finally applies > > these patches to the respective custodian repository. Finally, he > > sends a pull request to the next higher custodian - in case of SoCFPGA > > that would be Albert as ARM custodian. > > Does the above process differ from the Linux community process in > anyway? If not, then I've been doing the same for the Linux support for > SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling > from the git repo at rocketboards for quite some time now. I think I can > probably do the same for u-boot. I think we are a bit more critical here in U-Boot. The repositories we pull from are maintained by community-assigned custodians, who have a proven track record not only as experienced developers, but also for working with the community and being able to negotiate conflicts. If Vince gets appointed as custodian for socfpga, there should be no problem for him to automatically synchronize your u-boot-socfpga-next.git repository with the U-Boot u-boot-socfpga one. On the other hand - what exactly is the code you are referring to in u-boot-socfpga-next.git ? At the moment, I see this: -> git clone git://git.rocketboards.org/u-boot-socfpga-next.git Cloning into 'u-boot-socfpga-next'... warning: You appear to have cloned an empty repository. Checking connectivity... done. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Only in our dreams we are free. The rest of the time we need wages. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 04:05 PM, David Hawkins wrote: > Hi guys, > > I'm going to jump in here with an end-user's perspective, > along with an offer of assistance/contribution. > > I'm interested in using Altera's SOCs in my designs. > Altera guys - if you look over on the Altera Forum, > you will see that I am very active over there > (basically answering everyone's FPGA questions). Awesome...thank you for your support! > > Up until now I have avoided any SoC development kits as > I considered the software support to not have matured > enough. I consider "mature" code to be code that I can > checkout from mainline, where mainline is U-Boot via the > Denx repos, and Linux via the Kernel repos. For Linux, we have done a better job than u-boot. You should be able to have most of what you need from kernel.org for the Altera Devkits and Terasic SocKit board. The most important piece maybe the FPGA manager, otherwise the SOCFPGA platform is just any other A9 board. The FPGA manager is in-flight: https://lkml.org/lkml/2014/8/1/517 For U-boot, the upstreaming process has been slow. I admit it, but it is very high on our to-do list. > > Freescale has done this forever, and I hold their > processors and code in high regard. > I used to work at Freescale's doing the i.MX parts. I hope these were the processors you had in the mind? > Texas Instruments has recently realized that this > is the way to go, and have invested significantly > in this area - as demonstrated by Tom Rini. > TI have dedicated a page to mainlining: > > http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page > > TI have similarly gained my respect. > > The fact that discussion is now occurring for Altera's > SoCs indicates to me that a certain level of maturity has > been reached and that it is now time for me to consider > using these devices. > > I'd like to help, and I'm sure Ira Snyder will help too > (most likely more so than me). I would like to obtain > some SoC development kits so as to help with the SoC > "experience" for end-users. > > To aid in this development, I'd like some recommendations > on what hardware to buy. I've included the list below > the body of this email (to save cluttering the flow of > this discussion). Its possible for me to obtain one or more > of these boards. > > Which ones are supported in mainline U-Boot and Linux? > What will it take to make it easier for the end-user > like myself? Echoing earlier...There is good Linux support for the Altera Cyclone5 and Arria5 devkit and Terasic SoCkit from kernel.org. > > I would like to be able to buy something like the Critical > Link or Denx modules and simply plug them into my custom > hardware, configure the FPGA fabric with whatever custom > "magic" I need, have Ira develop a custom drive to that > "magic" and just have things *WORK*. As an end-user, > I don't want to have to pull a dozen patches off the > mailing list to get a working system. > > Altera's success in the SoC market depends on "getting > it right" with respect to integration with the open-source > community. That integration involves playing by the established > set of rules. Wolfgang and his (creation and) support of U-Boot > is of immeasurable value to the open-source community. > > Altera developers, please follow Wolfgang's advice. Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support. I maintain a linux-next git repo at rocketboards for patches that have been properly reviewed, and acked-by that are destined for kernel.org. The logic should follow that I(Altera) would do the same for u-boot patches at rocketboards that are destined for mainline u-boot at denx. Thanks, Dinh > > Cheers, > Dave Hawkins, > California Institute of Technology. > > -- > > 1. Cyclone V SoC Development Kit > >http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html > >This is the main kit that most people are probably >developing with. At $1,795 its pretty expensive, >but I could request a couple of kits from the >Altera University Program. > > 2. Arria V SoC kit > >http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html > >At $3,495 this is also very expensive. >This board still ships with ES (Engineering Sample), so I >would not buy this yet. > > 3. Terasic/Arrow SOCKit > > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=816 > >At $299 this is pretty reasonable. > > 4. SOC System-on-Modules > > > http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html > > >eg, Critical Link MitySOM > >http://www.criticallink.com/product/mitysom-5csx/ > > > http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d > > >Each module is a
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 02:46 PM, Wolfgang Denk wrote: > Dear Dinh, > > In message <54133b22.2090...@opensource.altera.com> you wrote: >> >>> So I suggest we create u-boot-socfpga now, as this will be needed >>> in any case when any significant amount of patches is coming in for >>> mainline. >>> >>> For now, we assing Marek as custodian - he has volunteered, and he >>> already has a reputation in the community. As soon as Vince starts >>> actively working here on the mailing list, we can switch this role >>> to him. >> >> NO..we'd like to maintain the u-boot-socfpga-next git repo at >> rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively >> maintain it from now on. > > I'm sorry, but that's not the way how the U-Boot community works. > > To get patches or new code into U-Boot mainline, these have to be > submitted to the U-Boot mailing list (among other purposes for > archival and that they get stored in the patchwork database). Then a > peer review takes place, and the responsible custodian finally applies > these patches to the respective custodian repository. Finally, he > sends a pull request to the next higher custodian - in case of SoCFPGA > that would be Albert as ARM custodian. > Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Dave Il 12/set/2014 23:23 "David Hawkins" ha scritto: > > Hi Michael, > > >> We know and thank you very much for price list ;) > > > I hope my incomplete list of vendors did not offend you. > I'm board vendor agnostic. If your company has an > Altera SoC board, I'm more than happy to look at it too. > > Feel free to offer alternative options :) > It was just nice. I'm agree with you but I don't see any problem to have different host domain at the end. Michael PS: tools take to much time to build design on my laptop > Cheers, > Dave > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Michael, We know and thank you very much for price list ;) I hope my incomplete list of vendors did not offend you. I'm board vendor agnostic. If your company has an Altera SoC board, I'm more than happy to look at it too. Feel free to offer alternative options :) Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Il 12/set/2014 23:16 "David Hawkins" ha scritto: > > Hi guys, > > I'm going to jump in here with an end-user's perspective, > along with an offer of assistance/contribution. > > I'm interested in using Altera's SOCs in my designs. > Altera guys - if you look over on the Altera Forum, > you will see that I am very active over there > (basically answering everyone's FPGA questions). > > Up until now I have avoided any SoC development kits as > I considered the software support to not have matured > enough. I consider "mature" code to be code that I can > checkout from mainline, where mainline is U-Boot via the > Denx repos, and Linux via the Kernel repos. > > Freescale has done this forever, and I hold their > processors and code in high regard. > > Texas Instruments has recently realized that this > is the way to go, and have invested significantly > in this area - as demonstrated by Tom Rini. > TI have dedicated a page to mainlining: > > http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page > > TI have similarly gained my respect. > > The fact that discussion is now occurring for Altera's > SoCs indicates to me that a certain level of maturity has > been reached and that it is now time for me to consider > using these devices. > > I'd like to help, and I'm sure Ira Snyder will help too > (most likely more so than me). I would like to obtain > some SoC development kits so as to help with the SoC > "experience" for end-users. > > To aid in this development, I'd like some recommendations > on what hardware to buy. I've included the list below > the body of this email (to save cluttering the flow of > this discussion). Its possible for me to obtain one or more > of these boards. > > Which ones are supported in mainline U-Boot and Linux? > What will it take to make it easier for the end-user > like myself? > > I would like to be able to buy something like the Critical > Link or Denx modules and simply plug them into my custom > hardware, configure the FPGA fabric with whatever custom > "magic" I need, have Ira develop a custom drive to that > "magic" and just have things *WORK*. As an end-user, > I don't want to have to pull a dozen patches off the > mailing list to get a working system. > > Altera's success in the SoC market depends on "getting > it right" with respect to integration with the open-source > community. That integration involves playing by the established > set of rules. Wolfgang and his (creation and) support of U-Boot > is of immeasurable value to the open-source community. > > Altera developers, please follow Wolfgang's advice. > > Cheers, > Dave Hawkins, > California Institute of Technology. > We know and thank you very much for price list ;) Michael > -- > > 1. Cyclone V SoC Development Kit > >http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html > >This is the main kit that most people are probably >developing with. At $1,795 its pretty expensive, >but I could request a couple of kits from the >Altera University Program. > > 2. Arria V SoC kit > >http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html > >At $3,495 this is also very expensive. >This board still ships with ES (Engineering Sample), so I >would not buy this yet. > > 3. Terasic/Arrow SOCKit > > > http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=816 > >At $299 this is pretty reasonable. > > 4. SOC System-on-Modules > > > http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html > >eg, Critical Link MitySOM > >http://www.criticallink.com/product/mitysom-5csx/ > > > http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d > >Each module is about $600 at Mouser. > > 5. Denx MCV board > >http://www.denx-cs.de/?q=MCV > >These modules look reasonably priced. > > The CriticalLink and Denx modules look suitable for my intended > application, i.e., as the controller for a much larger FPGA board. > > Wolfgang - feel free to advise me to use the Denx modules, and > I'll take a more critical look at the data sheets to check > they have the features I want to use. > > > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi guys, I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution. I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions). Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider "mature" code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos. Freescale has done this forever, and I hold their processors and code in high regard. Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining: http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page TI have similarly gained my respect. The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices. I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC "experience" for end-users. To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards. Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself? I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom "magic" I need, have Ira develop a custom drive to that "magic" and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system. Altera's success in the SoC market depends on "getting it right" with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community. Altera developers, please follow Wolfgang's advice. Cheers, Dave Hawkins, California Institute of Technology. -- 1. Cyclone V SoC Development Kit http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program. 2. Arria V SoC kit http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet. 3. Terasic/Arrow SOCKit http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=816 At $299 this is pretty reasonable. 4. SOC System-on-Modules http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html eg, Critical Link MitySOM http://www.criticallink.com/product/mitysom-5csx/ http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d Each module is about $600 at Mouser. 5. Denx MCV board http://www.denx-cs.de/?q=MCV These modules look reasonably priced. The CriticalLink and Denx modules look suitable for my intended application, i.e., as the controller for a much larger FPGA board. Wolfgang - feel free to advise me to use the Denx modules, and I'll take a more critical look at the data sheets to check they have the features I want to use. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm.git
Hi Tom (Rini), On 10 September 2014 13:04, Simon Glass wrote: > Hi Tom, > > This pull includes driver model implementations for serial (uclass, > sandbox and Tegra) as well as GPIO for Tegra, I've held off on exynos > until we resolve some questions there. I'm not 100% sure it will make > the release. Sorry I forgot to cc you on this pull request. Please let me know I need to re-issue it. > > > > The following changes since commit b7a809957bcd72c2efa49ce733774b1e28878585: > > Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze > (2014-09-10 06:59:49 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-dm.git > > for you to fetch changes up to 858530a8c0a7ce7e573e513934804a00d6676813: > > dm: tegra: Enable driver model for serial (2014-09-10 13:00:02 -0600) > > > Simon Glass (17): > dm: Move pre-reloc init earlier to cope with board_early_init_f() > Set up stdio earlier when using driver model > dm: Make driver model available before board_init() > dm: tegra: Set up a pre-reloc malloc() > tegra: Convert tegra GPIO driver to use driver model > serial: Set up the 'priv' pointer when creating a serial device > dm: fdt: Add a function to look up a chosen node > dm: Adjust lists_bind_fdt() to return the bound device > dm: Add a uclass for serial devices > sandbox: Convert serial driver to use driver model > sandbox: serial: Support a coloured console > sandbox: dts: Add a serial console node > dm: serial: Move baud rate calculation to ns16550.c > dm: serial: Collect common baud rate code in ns16550 > dm: serial: Add driver model support for ns16550 > tegra: dts: Add serial port details > dm: tegra: Enable driver model for serial > > arch/arm/dts/tegra114-dalmore.dts | 4 + > arch/arm/dts/tegra114.dtsi | 53 + > arch/arm/dts/tegra124-jetson-tk1.dts | 4 + > arch/arm/dts/tegra124-venice2.dts | 4 + > arch/arm/dts/tegra124.dtsi | 66 + > arch/arm/dts/tegra20-colibri_t20_iris.dts | 4 + > arch/arm/dts/tegra20-harmony.dts | 4 + > arch/arm/dts/tegra20-medcom-wide.dts | 4 + > arch/arm/dts/tegra20-paz00.dts | 4 + > arch/arm/dts/tegra20-plutux.dts| 4 + > arch/arm/dts/tegra20-seaboard.dts | 4 + > arch/arm/dts/tegra20-tec.dts | 4 + > arch/arm/dts/tegra20-trimslice.dts | 4 + > arch/arm/dts/tegra20-ventana.dts | 4 + > arch/arm/dts/tegra20-whistler.dts | 4 + > arch/arm/dts/tegra20.dtsi | 51 ++--- > arch/arm/dts/tegra30-beaver.dts| 4 + > arch/arm/dts/tegra30-cardhu.dts| 4 + > arch/arm/dts/tegra30-tamonten.dtsi | 4 + > arch/arm/dts/tegra30.dtsi | 66 + > arch/arm/include/asm/arch-tegra/gpio.h | 15 ++-- > arch/sandbox/dts/sandbox.dts | 10 +++ > board/nvidia/seaboard/seaboard.c | 2 +- > common/board_f.c | 4 +- > common/board_r.c | 19 +++-- > common/stdio.c | 18 - > doc/device-tree-bindings/serial/ns16550.txt| 10 +++ > doc/device-tree-bindings/serial/sandbox-serial.txt | 13 > drivers/core/lists.c | 10 ++- > drivers/core/root.c| 2 +- > drivers/gpio/tegra_gpio.c | 327 > ++-- > drivers/serial/Makefile| 7 +- > drivers/serial/ns16550.c | 203 > -- > drivers/serial/sandbox.c | 140 > +++--- > drivers/serial/serial-uclass.c | 213 > > drivers/serial/serial.c| 1 + > drivers/serial/serial_ns16550.c| 14 +--- > drivers/serial/serial_tegra.c | 38 ++ > include/configs/sandbox.h | 3 + > include/configs/tegra-common.h | 11 ++- > include/dm/lists.h | 6 +- > include/dm/uclass-id.h | 1 + > include/dt-bindings/clock/tegra114-car.h | 342 > > include/dt-bindings/clock/tegra124-car.h | 342 > +
Re: [U-Boot] u-boot-socfpga repository
Hi all Il 12/set/2014 21:53 "Dinh Nguyen" ha scritto: > > On 09/12/2014 12:25 AM, Wolfgang Denk wrote: > > Dear Dinh, > > > > In message <54122de5.1080...@opensource.altera.com> you wrote: > >> > >> Understood...You have just lit a fire in our arses! We have added a > >> resource internally, Vince Bridgers, to help us upstream more u-boot > >> support. Also, now that Linux support for SOCFPGA is decent, I will > >> focus more on u-boot. > > > > That's great to hear, thank. > > > > So I suggest we create u-boot-socfpga now, as this will be needed > > in any case when any significant amount of patches is coming in for > > mainline. > > > > For now, we assing Marek as custodian - he has volunteered, and he > > already has a reputation in the community. As soon as Vince starts > > actively working here on the mailing list, we can switch this role > > to him. > > NO..we'd like to maintain the u-boot-socfpga-next git repo at > rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively > maintain it from now on. > > I went back to the mailing list last night and you're right, there were > quite a few patches that had Chin-Liang's ACK, but sat idle. I'll start > to pull those patches in ASAP. > If patches are in U-Boot mailing list, i don't see any problem to pull from their server. You should only agree how review process should be done. Michael > > Thanks, > Dinh > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Hi Il 12/set/2014 21:53 "Mariusz Boguszewski" ha scritto: > > Hello, > I need to get this new version of u-boot for my PandaBoard A6 rev. > I tried Linaro release 14.08 from July 2014 but all I get is the error: > > U-Boot SPL 2013.01.-rc1-g43ee87a (May 25 2014 - 07:45:31) > OMAP4430 ES2.3 > SDRAM: identified size not same as expected size identified: 0 expected: 4000 > Try to enable auto detection Michael > Is this fix applied to u-boot, and where can I get it ? > > Regards. > > > > > > Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. > New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 12:25 AM, Wolfgang Denk wrote: > Dear Dinh, > > In message <54122de5.1080...@opensource.altera.com> you wrote: >> >> Understood...You have just lit a fire in our arses! We have added a >> resource internally, Vince Bridgers, to help us upstream more u-boot >> support. Also, now that Linux support for SOCFPGA is decent, I will >> focus more on u-boot. > > That's great to hear, thank. > > So I suggest we create u-boot-socfpga now, as this will be needed > in any case when any significant amount of patches is coming in for > mainline. > > For now, we assing Marek as custodian - he has volunteered, and he > already has a reputation in the community. As soon as Vince starts > actively working here on the mailing list, we can switch this role > to him. NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on. I went back to the mailing list last night and you're right, there were quite a few patches that had Chin-Liang's ACK, but sat idle. I'll start to pull those patches in ASAP. Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Hello, I need to get this new version of u-boot for my PandaBoard A6 rev. I tried Linaro release 14.08 from July 2014 but all I get is the error: U-Boot SPL 2013.01.-rc1-g43ee87a (May 25 2014 - 07:45:31) OMAP4430 ES2.3 SDRAM: identified size not same as expected size identified: 0 expected: 4000 Is this fix applied to u-boot, and where can I get it ? Regards. Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message <54133b22.2090...@opensource.altera.com> you wrote: > > > So I suggest we create u-boot-socfpga now, as this will be needed > > in any case when any significant amount of patches is coming in for > > mainline. > > > > For now, we assing Marek as custodian - he has volunteered, and he > > already has a reputation in the community. As soon as Vince starts > > actively working here on the mailing list, we can switch this role > > to him. > > NO..we'd like to maintain the u-boot-socfpga-next git repo at > rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively > maintain it from now on. I'm sorry, but that's not the way how the U-Boot community works. To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian. There is nothing wrong with you maintaining u-boot-socfpga-next at rocketboards.org. It's just that such code does not get into mainline other than by the procedure described before. So we need the custodian repository in any way (unless Albert says he wants to take stuff directly into the ARM repo - but from the amount of work that is going on this seems unwise). Vince may of course volunteer as custodian for the new u-boot-socfpga repository, but that would be a community decision, and like everybody else in that role he needs to earn some reputation first - we haven't seen him at work so far. In the meantime, it appears to make sense that Marek fills in the gap. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You get a wonderful view from the point of no return. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Michal, In message <541334d0.80...@monstr.eu> you wrote: > > But creating separate repository for every SoC in u-boot seems to me > just too much. We're not talking about one repo for every SoC here. > Definitely I also really appreciate that Marek volunteers to be responsible > for socfpga. But that means that guys who are responsible for socfpga failed > and they are not responding for patches which others are sending to mailing > list for review. > I am not closely following them but did this really happen? I think the problem is that so far nobody feels responsible for systematically mainlining the code. There are some patches here and there, but usually you cannot build a useful and working U-Boot image from the existing mainline code. > If they don't want to maintain their socfpga in mainline and Marek > wants to do it I will definitely support Marek in this new possition > to get things done properly but also I just want to make sure that > this is really happen and isn't it just the part of misunderstanding > how u-boot community is working. Probably both. > Having arm SOC sub maintainers is definitely good concept > but I am just not sure that creating separate repository fully solve > this. You are right - the repository is just one necessary step. A custodian who knows how the community works and who is willing to collect patches and synchronize efforts is also needed - this is where Marek volunteered for now. If someone from Altera is willing to take over, such a switch would be trivial to perform. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Build a system that even a fool can use and only a fool will want to use it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Fri, Sep 12, 2014 at 03:42:19PM +0200, Albert ARIBAUD wrote: > Hello Tom, > > The following changes since commit > d6c1ffc7d23f4fe4ae8c91101861055b8e1501b6: > > Prepare v2014.10-rc2 (2014-09-02 16:58:29 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-arm master > > for you to fetch changes up to a7f99bf139b3aaa0d5494693fd0395084355e41a: > > arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39 > +0200) > > NOTE that 7 boards still fail building, two with warnings (k2e_evm > k2hk_evm), five with errors (openrd_client tricorder_flash tricorder > openrd_ultimate openrd_base). > > > Ajay Kumar (8): > exynos_fb: Remove usage of static defines > arm: exynos: Add RPLL for Exynos5420 > arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for > Exynos5420 video: exynos_fimd: Add framework to disable FIMD sysmmu > ARM: exynos: Add missing declaration for gpio_direction_input > exynos5420: add callbacks needed for exynos_fb driver > ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge > chip CONFIGS: peach-pit: Enable display for peach_pit board > > Albert ARIBAUD (2): > Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' > Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master' > > Benoît Thébaudeau (2): > arm: Make reset position-independent > arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG > > Enric Balletbo i Serra (1): > AM335x: igep0033: Convert to generic board and use > ti_am335x_common.h. > > FUKAUMI Naoki (1): > sun7i: Add support for Olimex A20-OLinuXino-LIME > > Guillaume GARDET (1): > omap3_beagle: Add boot script support to omap3 beagle board > > Ian Campbell (1): > sunxi: Correct typo CONFIG_FTDFILE => CONFIG_FDTFILE > > Jeroen Hofstee (8): > board_r: ARM[64] do not set gd again > ARM: SPL: do not set gd again > cc-option: also detect unsupported warnings options > ARM: make gd a function for clang > eabi_compat: add __aeabi_memcpy __aeabi_memset > clang: workaround for generated constants > Makefile: default to cc for host compiler > README.clang: build command with clang > > Khoronzhuk, Ivan (3): > ARM: keystone: clock: use correct BWADJ field mask for PASSPLLCTL0 > keystone2: use readl/writel functions instead of redefinition > mtd: nand: davinci_nand: correct keystone RBL layout definition > > Masahiro Yamada (3): > arm: am335x: add Kconfig range attribute to prevent invalid > CONS_INDEX MAINTAINERS: update the maintainer of Arndale board > kconfig: remove redundant "SPL" from CONFIG_SYS_EXTRA_OPTIONS > > Przemyslaw Marczak (13): > samsung: misc: fix soc revision setting in the set_board_info() > exynos: pinmux: fix the gpio names for exynos4x12 mmc > arch:exynos: boot mode: add get_boot_mode(), code cleanup > board:samsung: check the boot device and init the right mmc > driver. samsung: misc: add function for setting $dfu_alt_info > samsung:board: misc_init_r: call set_dfu_alt_info() > arm:reset: call the reset_misc() before the cpu reset > samsung: board: enable support of multiple board types > samsung: misc: use board specific functions to set env board info > odroid: add board file for Odroid X2/U3 based on Samsung > Exynos4412 odroid: add odroid U3/X2 device tree description > odroid: kconfig: add odroid_defconfig > odroid: set MPLL clock to 880MHz > > R Sricharan (1): > ARM: DRA72: DDR3: Add emif settings for 666MHz clock > > Rostislav Lisovy (2): > mtd: nand: omap_gpmc: Enable multiple NAND flash devices > mtd: nand: omap_gpmc: Fix 'bit-flip' errors > > Vadim Bendebury (1): > video: Add driver for Parade PS8625 dP to LVDS bridge > > Kbuild | 3 +- > Makefile | 4 +- > arch/arm/cpu/armv7/exynos/Kconfig | 4 + > arch/arm/cpu/armv7/exynos/clock.c | 83 > +++-- arch/arm/cpu/armv7/exynos/clock_init.h > | 3 + arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 > arch/arm/cpu/armv7/exynos/exynos5_setup.h | 2 +- > arch/arm/cpu/armv7/exynos/pinmux.c | 4 +- > arch/arm/cpu/armv7/exynos/power.c | 7 ++ > arch/arm/cpu/armv7/exynos/spl_boot.c | 7 +- > arch/arm/cpu/armv7/keystone/clock.c| 2 +- > arch/arm/cpu/armv7/keystone/psc.c | 44 +-- > arch/arm/cpu/armv7/omap5/hw_data.c | 39 +- > arch/arm/cpu/armv7/omap5/sdram.c | 60 ++- > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/exynos4412-odroid.dts | 70 ++ > arch/arm/dts/exynos5420-peach-pit.dts | 30
Re: [U-Boot] u-boot-socfpga repository
Hi Wolfgang, On 09/11/2014 09:46 AM, Wolfgang Denk wrote: > Dear Michal, > > In message <54112b64.5010...@monstr.eu> you wrote: >> >> I am not sure if you need to have separate repo to work like this. >> I am keeping zynq patches in my microblaze repo and sending pull request >> to Albert >> (or Tom now) and there is no problem with that. > > Well, technically of course this works, but it is far from perfect. > It works only for those who actually know about this. But anybody > looking at the U-Boot site for any zynq related stuff will have hard > times to find it. Please don't get me wrong I am just trying to understand what happened. We have MAINTAINERS file where we can simply add person who is responsible for specific SOC. I also believe that this is exactly reason why to have it. From that file everybody can find out who should take the patches and and almost doesn't matter if git is at denx.de or somewhere else. But still all ARM patches should go through our ARM custodian not directly to Tom. get_maintainer.pl should also keep all interested people in the loop. > I think it is much better to make this knowledge public information - > and one easy way to do this is to have a separate repository for it, > which is listed on the custodians page, so everybody looking for it > will find all relevant information. Isn't that MAINTAINERS file already publicly available? Of course if you want to add the same information on wiki, I can't see any problem there. But creating separate repository for every SoC in u-boot seems to me just too much. >> In socfpga case I think there are guys from Altera who maintain it. > > Well, they maintain the stuff at rocketboards.org ; there are efforts > on the way to mainline stuff, but the process is not exactly > satisfactory. I highly appreciate that Marek volunteers to put > efforts in this. Definitely I also really appreciate that Marek volunteers to be responsible for socfpga. But that means that guys who are responsible for socfpga failed and they are not responding for patches which others are sending to mailing list for review. I am not closely following them but did this really happen? If they don't want to maintain their socfpga in mainline and Marek wants to do it I will definitely support Marek in this new possition to get things done properly but also I just want to make sure that this is really happen and isn't it just the part of misunderstanding how u-boot community is working. > As far as I am concerned, I support both Marek's and Masahiro's > requests. > > @ Marek and Masahiro: if we reach an agreement to create such repos, > please send me your SSH public keys that shall be used for > these. Also, what should the names be - u-boot-socfpga ? > And u-boot-uniphier ? [But is there not a chance that Pana- > sonic might have other SoCs that might be mainlines? So > maybe we should use u-boot-panasonic instead?] If they want to have separate repository because they think that it is better then their current one then sure why not to create them. Having arm SOC sub maintainers is definitely good concept but I am just not sure that creating separate repository fully solve this. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
On Fri, Sep 12, 2014 at 2:57 AM, Ian Campbell wrote: > On Thu, 2014-09-11 at 19:19 +0200, Hans de Goede wrote: >> Hi Chen, >> >> On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote: >> > Hi Ian, Hans, >> > >> > On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai wrote: >> >> BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when >> >> CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally >> >> include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI. >> > >> > The other patches are for the next release, but maybe this fix could >> > go into 2014.10? >> >> I agree that this is a benign bug fix, but since we don't have any >> boards not setting CONFIG_EHCI atm I don't really see the value >> for getting it into 2014.10. > > FWIW I was planning on putting the whole series in #next until the next > merge window as soon as I find a some spare moments to look through it > (sorry, might take me a few more days, I'm travelling at the w/e). OK. Thanks for the heads up. ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test: dfu: script: wrong md5sum on nand partitions
On 09/12/2014 12:27 AM, Heiko Schocher wrote: when uplaoding a file, at least from a nand partition, the complete mtd nand partition size is transferred. This leads in a wrong md5sum as the filesize is different between the downloaded file and the uploaded file. Limit the uploaded filesize to the downloaded fixes this. I was going to say that it'd be better to fix U-Boot's NAND code to transfer the correct amount of data. However, I suppose the correct amount *is* the whole partition for anything other than a filesystem file. As such, I'd suggest replacing "nand" in the patch description with something else, since presumably the exact same issue applies to partitions on eMMC. The issue applies to any partition. I wonder if there's a way to distinguish between file tests and partition tests in dfu_gadget_test.sh, so that the $N_FILE_FULL -> $N_FILE conversion can be applied only for partitions. Otherwise, a file upload/download test could end up changing (increasing) the file length and this bug wouldn't be detected. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] samsung: Use common config files with Samsung boards (help wanted)
Hi Przemyslaw, On 12 September 2014 02:39, Przemyslaw Marczak wrote: > > Hello Simon, > > > On 09/09/2014 12:31 PM, Przemyslaw Marczak wrote: >> >> Hi, >> >> I will test this patch set on a trats2 board - today evening. >> >> On 09/09/2014 08:05 AM, Simon Glass wrote: >>> >>> Hi Minkyu, >>> >>> On 25 July 2014 08:43, Simon Glass wrote: >>> Hi Lucasz, On 24 July 2014 09:34, Lukasz Majewski wrote: > > Hi Simon, > >> This series tries to unify the Samsung board configs into a few header >> files for exynos5 and exynos5. >> >> The purpose is to make it easier to move to driver model. In that case >> I would like things like the GPIO drivers and serial drivers to work >> in a standard way, and not need to support device tree and platform >> data at the same time. That would be quite painful. >> >> Another reason is that the Chrome OS EC drivers are currently >> included in boards that don't have a Chrome OS EC. This concern was >> raised by the Samsung maintainer (Minkyu) a while back. >> >> There are still a few boards that don't use CONFIG_OF_CONTROL so I >> have updated these with the most rudimentary of device tree files. >> >> Unfortunately I don't have boards for most of these (for testing) and >> I am hoping that the maintainers can come to the rescue and fix up any >> patches that have problems. I am also worried that I have used a >> common exynos file for things like smdkv310, when in fact they have >> some other chip in common. >> >> So maintainers, please can you test this and re-issue the patch, or >> make comments on my attempts? > > > We will do our best to test our Exynos4 based boards. Thanks - please feel free to re-issue the patches and I will drop mine (if you cc me). >>> >>> Can you please review this series? We are already at rc2. >>> >>> Regards, >>> Simon >>> >>> >>> >>> ___ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >>> >> >> Best regards, > > > It works fine on trats2. > I'm currently working on PMIC framework at the top of your u-boot-dm/working > branch and it also works fine on Trats2. OK good, thanks for testing. I'll go through the feedback and see if I can give the patches another spin. It would be great if we can get exynos DM support in mainline for the upcoming release. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] Please pull u-boot-imx
Hi Albert, please pull from u-boot-imx, thanks ! The board cm_fx6 cannot be built due to a couple of missing patches that are already merged into u-boot-spi. Please ignore this issue, the board will be compiled clean at the next iteration after Jagan's tree will be merged by Tom. The following changes since commit a6bc0195dba895fa0e9facc718d17eb098695685: Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master' (2014-09-09 09:19:10 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 4c97f16911e229f6d5bbea5bee52449916e5fa92: imx: mx6slevk: Change to use generic board (2014-09-11 11:04:26 +0200) Fabio Estevam (9): net: fec_mxc: Adjust RX DMA alignment for mx6solox net: fec_mxc: Poll FEC_TBD_READY after polling TDAR tools: imximage: Fix the maximum DCD size for mx53/mx6 mx6dlsabresd: Use its own DCD table mx6qsabreauto: Remove imx6q-sabreauto.dts mx6: imx-regs: Provide a structure for GPC registers pcie_imx: Add mx6solox support mx6sxsabresd: Add PCI support README.imximage: Fix the maximum DCD size Guillaume GARDET (1): imx: nitrogen6x: Replace 'fatload' by 'load' command in env settings to be filesystem independent Nikita Kiryanov (16): mx6: add clock enabling functions compulab: eeprom: add support for defining eeprom i2c bus sata: dwc_ahsata: implement sata_port_status i2c: imx: add macros to setup pads for multiple SoC types arm: mx6: ddr: cleanup arm: mx6: ddr: do not write into reserved bit arm: mx6: ddr: configure MMDC for slow_pd arm: mx6: ddr: fix cs0_end calculation arm: mx6: add get_cpu_type() arm: mx6: add support for Compulab cm-fx6 CoM arm: mx6: cm_fx6: add nand support arm: mx6: cm_fx6: add ethernet support arm: mx6: cm_fx6: add usb support arm: mx6: cm_fx6: add i2c support arm: mx6: cm_fx6: use eeprom arm: mx6: cm_fx6: add sata support Nikolay Dimitrov (1): mx6: Fix ECSPI typo in soc_boot_modes Stefan Agner (2): arm: vf610: lpuart: fix status register handling arm: vf610: lpuart: disable FIFO on initializaton Stefano Babic (1): imx: Fix build of mx6sxsabresd Thierry Reding (1): imx: ventana: Avoid undefined behaviour Tim Harvey (6): imx: ventana: updated notes regarding NAND boot errata imx: ventana: base SPL MMDC calibration on width and size not board imx: ventana: add GW5520 support imx: ventana: added cputype env var pci: add support for board_pci_fixup_dev function imx: ventana: add pci fixup for PLX PEX860x switch GPIO Ye.Li (4): iMX6: Disable the L2 before chaning the PL310 latency imximage: Fix imximage IVT bug for EIM-NOR boot imx: mx6q/dlarm2: Change to use generic board imx: mx6slevk: Change to use generic board arch/arm/Kconfig| 4 + arch/arm/cpu/armv7/mx6/clock.c | 107 +- arch/arm/cpu/armv7/mx6/ddr.c| 277 arch/arm/cpu/armv7/mx6/soc.c| 11 +- arch/arm/dts/Makefile | 1 - arch/arm/dts/imx6q-sabreauto.dts| 13 - arch/arm/include/asm/arch-mx6/clock.h | 5 + arch/arm/include/asm/arch-mx6/imx-regs.h| 13 + arch/arm/include/asm/arch-mx6/iomux.h | 9 + arch/arm/include/asm/arch-mx6/sys_proto.h | 5 +- arch/arm/include/asm/imx-common/mxc_i2c.h | 33 ++ board/compulab/cm_fx6/Kconfig | 23 ++ board/compulab/cm_fx6/MAINTAINERS | 6 + board/compulab/cm_fx6/Makefile | 12 + board/compulab/cm_fx6/cm_fx6.c | 483 board/compulab/cm_fx6/common.c | 84 + board/compulab/cm_fx6/common.h | 37 +++ board/compulab/cm_fx6/imximage.cfg | 8 + board/compulab/cm_fx6/spl.c | 366 + board/compulab/common/eeprom.c | 13 +- board/freescale/mx6sabresd/mx6dlsabresd.cfg | 131 board/gateworks/gw_ventana/eeprom.c | 3 + board/gateworks/gw_ventana/gsc.c| 4 + board/gateworks/gw_ventana/gw_ventana.c | 118 ++- board/gateworks/gw_ventana/gw_ventana_spl.c | 189 ++- board/gateworks/gw_ventana/ventana_eeprom.h | 1 + configs/cm_fx6_defconfig| 4 + configs/mx6dlsabresd_defconfig | 2 +- doc/README.imximage | 2 +- drivers/block/dwc_ahsata.c | 17 + drivers/net/fec_mxc.c | 42 ++- drivers/pci/pci.c | 4 + drivers/pci/pcie_imx.c | 40 ++- drivers/serial/serial_lpuart.c | 19 +- include/configs/cm_fx6.h| 290 + include/configs/cm_t335.h
[U-Boot] Pull request: u-boot-arm/master
Hello Tom, The following changes since commit d6c1ffc7d23f4fe4ae8c91101861055b8e1501b6: Prepare v2014.10-rc2 (2014-09-02 16:58:29 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to a7f99bf139b3aaa0d5494693fd0395084355e41a: arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39 +0200) NOTE that 7 boards still fail building, two with warnings (k2e_evm k2hk_evm), five with errors (openrd_client tricorder_flash tricorder openrd_ultimate openrd_base). Ajay Kumar (8): exynos_fb: Remove usage of static defines arm: exynos: Add RPLL for Exynos5420 arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 video: exynos_fimd: Add framework to disable FIMD sysmmu ARM: exynos: Add missing declaration for gpio_direction_input exynos5420: add callbacks needed for exynos_fb driver ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge chip CONFIGS: peach-pit: Enable display for peach_pit board Albert ARIBAUD (2): Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master' Benoît Thébaudeau (2): arm: Make reset position-independent arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG Enric Balletbo i Serra (1): AM335x: igep0033: Convert to generic board and use ti_am335x_common.h. FUKAUMI Naoki (1): sun7i: Add support for Olimex A20-OLinuXino-LIME Guillaume GARDET (1): omap3_beagle: Add boot script support to omap3 beagle board Ian Campbell (1): sunxi: Correct typo CONFIG_FTDFILE => CONFIG_FDTFILE Jeroen Hofstee (8): board_r: ARM[64] do not set gd again ARM: SPL: do not set gd again cc-option: also detect unsupported warnings options ARM: make gd a function for clang eabi_compat: add __aeabi_memcpy __aeabi_memset clang: workaround for generated constants Makefile: default to cc for host compiler README.clang: build command with clang Khoronzhuk, Ivan (3): ARM: keystone: clock: use correct BWADJ field mask for PASSPLLCTL0 keystone2: use readl/writel functions instead of redefinition mtd: nand: davinci_nand: correct keystone RBL layout definition Masahiro Yamada (3): arm: am335x: add Kconfig range attribute to prevent invalid CONS_INDEX MAINTAINERS: update the maintainer of Arndale board kconfig: remove redundant "SPL" from CONFIG_SYS_EXTRA_OPTIONS Przemyslaw Marczak (13): samsung: misc: fix soc revision setting in the set_board_info() exynos: pinmux: fix the gpio names for exynos4x12 mmc arch:exynos: boot mode: add get_boot_mode(), code cleanup board:samsung: check the boot device and init the right mmc driver. samsung: misc: add function for setting $dfu_alt_info samsung:board: misc_init_r: call set_dfu_alt_info() arm:reset: call the reset_misc() before the cpu reset samsung: board: enable support of multiple board types samsung: misc: use board specific functions to set env board info odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412 odroid: add odroid U3/X2 device tree description odroid: kconfig: add odroid_defconfig odroid: set MPLL clock to 880MHz R Sricharan (1): ARM: DRA72: DDR3: Add emif settings for 666MHz clock Rostislav Lisovy (2): mtd: nand: omap_gpmc: Enable multiple NAND flash devices mtd: nand: omap_gpmc: Fix 'bit-flip' errors Vadim Bendebury (1): video: Add driver for Parade PS8625 dP to LVDS bridge Kbuild | 3 +- Makefile | 4 +- arch/arm/cpu/armv7/exynos/Kconfig | 4 + arch/arm/cpu/armv7/exynos/clock.c | 83 +++-- arch/arm/cpu/armv7/exynos/clock_init.h | 3 + arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 arch/arm/cpu/armv7/exynos/exynos5_setup.h | 2 +- arch/arm/cpu/armv7/exynos/pinmux.c | 4 +- arch/arm/cpu/armv7/exynos/power.c | 7 ++ arch/arm/cpu/armv7/exynos/spl_boot.c | 7 +- arch/arm/cpu/armv7/keystone/clock.c| 2 +- arch/arm/cpu/armv7/keystone/psc.c | 44 +-- arch/arm/cpu/armv7/omap5/hw_data.c | 39 +- arch/arm/cpu/armv7/omap5/sdram.c | 60 ++- arch/arm/dts/Makefile | 3 +- arch/arm/dts/exynos4412-odroid.dts | 70 ++ arch/arm/dts/exynos5420-peach-pit.dts | 30 arch/arm/dts/exynos54xx.dtsi | 10 +++ arch/arm/include/asm/arch-exynos/clk.h | 1 + arch/arm/include/asm/arch-exynos/gpio.h| 1 + arch/arm/include/asm/arch-exynos/power.h | 21 ++ arch/arm/include/asm/arch-exynos/spl.h | 17 +
[U-Boot] boot count feature with eMMC booting
I want to implement fail-safe booting feature in my project. Basically my logic is, i will increase any u-boot environment variable each time and up on successful bring up, i want to decrease the value of that again. If the value of u-boot environment variable is more than 5, it will boot from the other image. As i am using the eMMC for booting, i am not getting how i will access the u-boot environment variable from the linux application. I also dont know whether i can save the environment variable in the eMMC or not? What mechanism i should use to achieve this feature. I have read about the fw_printenv and fw_savenv, but from where this utility will access the variable. Thanks, Jags Gediya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] imx: mx6sabresd: Add clear print for pfuze200
Hi Stefano,
On 9/12/2014 6:13 PM, Stefano Babic wrote:
> Hi Ye,
>
> On 11/09/2014 05:13, Ye.Li wrote:
>> Add clear print log to show pfuze200 or pfuze100 found on mx6sabresd.
>>
>> Signed-off-by: Ye.Li
>> ---
>> Changes since v1:
>> - None
>>
>> Changes since v2:
>> - None
>>
>> board/freescale/mx6sabresd/mx6sabresd.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
>> b/board/freescale/mx6sabresd/mx6sabresd.c
>> index 5f65f1b..72d6562 100644
>> --- a/board/freescale/mx6sabresd/mx6sabresd.c
>> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
>> @@ -472,7 +472,8 @@ static int pfuze_init(void)
>> return ret;
>>
>> pmic_reg_read(p, PFUZE100_DEVICEID, ®);
>> -printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
>> +printf("PMIC: PFUZE%s ID=0x%02x\n",
>> +((reg & 0xf) == 0) ? "100" : "200", reg);
>>
>> /* Increase VGEN3 from 2.5 to 2.8V */
>> pmic_reg_read(p, PFUZE100_VGEN3VOL, ®);
>>
> This is completely unrelated to the series - it can be applied
> independently from the other patches. You do not need to resend this one
> but please send in future patches belonging to the same series if they
> are related to the same issue or to the same set of issues. This
> simplifies review and merging - thanks !
>
> Acked-by: Stefano Babic
>
> Best regards,
> Stefano Babic
>
Thanks for your comments. I feel this patch has somewhat relation with others,
that in 4/4 the pfuze mode setup needs to consider the pfuze chip type. Of
course, this patch can be applied independently. I will be more careful about
the patch set in future.
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] A minor question on a Driver Model function
Hi Simon,
I have a qustion about lists_driver_lookup_name() function.
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry->name, len))
continue;
/* Full match */
if (len == strlen(entry->name))
return entry;
}
Why is this not like follows?
for (entry = drv; entry != drv + n_ents; entry++) {
if (!strcmp(name, entry->name))
return entry;
}
It seems equivalent to the former and simpler.
Am I missing something?
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/2] mtd: nand: add Freescale vf610_nfc driver
This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. The driver is called vf610_nfc since this is the first supported and tested hardware platform supported by the driver. Signed-off-by: Stefan Agner Acked-by: Bill Pringlemeir --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 724 +++ 2 files changed, 725 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..eef86d1 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_NDFC) += ndfc.o diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..7feb3a7 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,724 @@ +/* + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Ported to U-Boot by Stefan Agner + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir + * Jason ported to M54418TWR and MVFA5. + * Authors: Stefan Agner + * Bill Pringlemeir + * Shaohui Xie + * Jason Jin + * + * Based on original driver mpc5121_nfc.c. + * + * This is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + * - Only 2K page w. 64+OOB and hardware ECC. + */ + +#include +#include + +#include +#include +#include + +#include +#include +#include + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC 0x3F14 +#define NFC_FLASH_STATUS1 0x3F18 +#define NFC_FLASH_STATUS2 0x3F1c +#define NFC_CACHE_SWAP 0x3F28 +#define NFC_SECTOR_SIZE0x3F2c +#define NFC_FLASH_CONFIG 0x3F30 +#define NFC_IRQ_STATUS 0x3F38 + +/* Addresses for NFC MAIN RAM BUFFER areas */ +#define NFC_MAIN_AREA(n) ((n) * 0x1000) + +#define PAGE_2K0x0800 +#define OOB_64 0x0040 + +/* + * NFC_CMD2[CODE] values. See section: + * - 31.4.7 Flash Command Code Description, Vybrid manual + * - 23.8.6 Flash Command Sequencer, MPC5125 manual + * + * Briefly these are bitmasks of controller cycles. + */ +#define READ_PAGE_CMD_CODE 0x7EE0 +#define PROGRAM_PAGE_CMD_CODE 0x7FC0 +#define ERASE_CMD_CODE 0x4EC0 +#define READ_ID_CMD_CODE 0x4804 +#define RESET_CMD_CODE 0x4040 +#define STATUS_READ_CMD_CODE 0x4068 + +/* NFC ECC mode define */ +#define ECC_BYPASS 0 +#define ECC_45_BYTE6 + +/*** Register Mask and bit definitions */ + +/* NFC_FLASH_CMD1 Field */ +#define CMD_BYTE2_MASK 0xFF00 +#define CMD_BYTE2_SHIFT24 + +/* NFC_FLASH_CM2 Field */ +#define CMD_BYTE1_MASK 0xFF00 +#define CMD_BYTE1_SHIFT24 +#define CMD_CODE_MASK 0x0000 +#define CMD_CODE_SHIFT 8 +#define BUFNO_MASK 0x0006 +#define BUFNO_SHIFT1 +#define START_BIT (1<<0) + +/* NFC_COL_ADDR Field */ +#define COL_ADDR_MASK 0x +#define COL_ADDR_SHIFT 0 + +/* NFC_ROW_ADDR Field */ +#define ROW_ADDR_MASK 0x00FF +#define ROW_ADDR_SHIFT 0 +#define ROW_ADDR_CHIP_SEL_RB_MASK 0xF000 +#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28 +#define ROW_ADDR_CHIP_SEL_MASK 0x0F00 +#define ROW_ADDR_CHIP_SEL_SHIFT24 + +/* NFC_FLASH_STATUS2 Field */ +#define STATUS_BYTE1_MASK 0x00FF + +/* NFC_FLASH_CONFIG Field */ +#define CONFIG_ECC_SRAM_ADDR_MASK 0x7FC0 +#define CONFIG_ECC_SRAM_ADDR_SHIFT 22 +#define CONFIG_ECC_SRAM_REQ_BIT(1<<21) +#define CONFIG_DMA_REQ_BIT
[U-Boot] [PATCH v5 2/2] arm: vf610: add NAND support for vf610twr
This adds NAND support for the Vybrid tower system (TWR-VF65GS10)
provided by the vf610_nfc driver. Full 16-Bit bus width is
supported. Also an aditional config vf610twr_nand is introduced
which gets the environment from NAND. However, booting U-Boot from
NAND is not yet possible due to missing boot configuration block
(BCB).
Signed-off-by: Stefan Agner
---
board/freescale/vf610twr/vf610twr.c | 47 ++---
configs/vf610twr_defconfig | 2 +-
configs/vf610twr_nand_defconfig | 3 +++
include/configs/vf610twr.h | 46 +++-
4 files changed, 93 insertions(+), 5 deletions(-)
create mode 100644 configs/vf610twr_nand_defconfig
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..4d09796 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -278,6 +278,39 @@ static void setup_iomux_i2c(void)
imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
}
+#ifdef CONFIG_NAND_VF610_NFC
+static void setup_iomux_nfc(void)
+{
+ static const iomux_v3_cfg_t nfc_pads[] = {
+ VF610_PAD_PTD31__NF_IO15,
+ VF610_PAD_PTD30__NF_IO14,
+ VF610_PAD_PTD29__NF_IO13,
+ VF610_PAD_PTD28__NF_IO12,
+ VF610_PAD_PTD27__NF_IO11,
+ VF610_PAD_PTD26__NF_IO10,
+ VF610_PAD_PTD25__NF_IO9,
+ VF610_PAD_PTD24__NF_IO8,
+ VF610_PAD_PTD23__NF_IO7,
+ VF610_PAD_PTD22__NF_IO6,
+ VF610_PAD_PTD21__NF_IO5,
+ VF610_PAD_PTD20__NF_IO4,
+ VF610_PAD_PTD19__NF_IO3,
+ VF610_PAD_PTD18__NF_IO2,
+ VF610_PAD_PTD17__NF_IO1,
+ VF610_PAD_PTD16__NF_IO0,
+ VF610_PAD_PTB24__NF_WE_B,
+ VF610_PAD_PTB25__NF_CE0_B,
+ VF610_PAD_PTB27__NF_RE_B,
+ VF610_PAD_PTC26__NF_RB_B,
+ VF610_PAD_PTC27__NF_ALE,
+ VF610_PAD_PTC28__NF_CLE
+ };
+
+ imx_iomux_v3_setup_multiple_pads(nfc_pads, ARRAY_SIZE(nfc_pads));
+}
+#endif
+
+
static void setup_iomux_qspi(void)
{
static const iomux_v3_cfg_t qspi0_pads[] = {
@@ -354,6 +387,8 @@ static void clock_init(void)
CCM_CCGR7_SDHC1_CTRL_MASK);
clrsetbits_le32(&ccm->ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
+ clrsetbits_le32(&ccm->ccgr10, CCM_REG_CTRL_MASK,
+ CCM_CCGR10_NFC_CTRL_MASK);
clrsetbits_le32(&anadig->pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
@@ -373,14 +408,17 @@ static void clock_init(void)
CCM_CACRR_IPG_CLK_DIV(1) | CCM_CACRR_BUS_CLK_DIV(2) |
CCM_CACRR_ARM_CLK_DIV(0));
clrsetbits_le32(&ccm->cscmr1, CCM_REG_CTRL_MASK,
- CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3));
+ CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3) |
+ CCM_CSCMR1_NFC_CLK_SEL(0));
clrsetbits_le32(&ccm->cscdr1, CCM_REG_CTRL_MASK,
CCM_CSCDR1_RMII_CLK_EN);
clrsetbits_le32(&ccm->cscdr2, CCM_REG_CTRL_MASK,
- CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0));
+ CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0) |
+ CCM_CSCDR2_NFC_EN);
clrsetbits_le32(&ccm->cscdr3, CCM_REG_CTRL_MASK,
CCM_CSCDR3_QSPI0_EN | CCM_CSCDR3_QSPI0_DIV(1) |
- CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3));
+ CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3) |
+ CCM_CSCDR3_NFC_PRE_DIV(5));
clrsetbits_le32(&ccm->cscmr2, CCM_REG_CTRL_MASK,
CCM_CSCMR2_RMII_CLK_SEL(0));
}
@@ -411,6 +449,9 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+#ifdef CONFIG_NAND_VF610_NFC
+ setup_iomux_nfc();
+#endif
return 0;
}
diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
index 10e6432..7de374a 100644
--- a/configs/vf610twr_defconfig
+++ b/configs/vf610twr_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/vf610twr/imximage.cfg"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_MMC"
CONFIG_ARM=y
CONFIG_TARGET_VF610TWR=y
diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig
new file mode 100644
index 000..e78db26
--- /dev/null
+++ b/configs/vf610twr_nand_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_NAND"
+CONFIG_ARM=y
+CONFIG_TARGET_VF610TWR=y
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..6fd0b17 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/v
[U-Boot] [PATCH v5 0/2] arm: vf610: add NAND flash support
This patch set adds NAND Flash Controller (NFC) support for Freescale Vybrid ARM SoCs (vf610). The driver is based on Bill Pringlemeirs prelineary patch sent in January 2014 to the MTD mailing list: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226623.html Changes in v5 - Fix style issues Changes in v4 - Drop preparation patches 1 and 2 since they are already merged upstream - Add memcpy accessor function vf610_nfc_memcpy - Remove disabled code Changes in v3 - Further optimizations in vf610_nfc_send_command(s) to avoid performance hit by additional barriers introduced through using writel/readl - Removed unnecessary barrier and added comment - Use void __iomem * as memory base data type - Set page to -1 on read error to allow reread of pages by the higher layers - Minor style fixes Changes in v2: - Renamed the driver from fsl_nfc to vf610_nfc - Use writel/readl in register access functions - Optimized some register accesses by read/write value only once in code - Use CONFIG_SYS_NAND_SELF_INIT and fix board_nand_init implementation - Removed uncommented code/fixed comments - Add CONFIG_USE_ARCH_MEMCPY for improved NAND performance - Use hweight32 for improved count_written_bits performance - Implement page_read/page_write rather than reuse MTD stacks version Stefan Agner (2): mtd: nand: add Freescale vf610_nfc driver arm: vf610: add NAND support for vf610twr board/freescale/vf610twr/vf610twr.c | 47 ++- configs/vf610twr_defconfig | 2 +- configs/vf610twr_nand_defconfig | 3 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c| 724 include/configs/vf610twr.h | 46 ++- 6 files changed, 818 insertions(+), 5 deletions(-) create mode 100644 configs/vf610twr_nand_defconfig create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10] nand/denali: Adding Denali NAND driver support
On Fri, 12 Sep 2014 00:42:17 -0500 Chin Liang See wrote: > To add the Denali NAND driver support into U-Boot. > This driver is leveraged from Linux with commit ID > fdbad98dff8007f2b8bee6698b5d25ebba0471c9. For Denali > controller 64 variance, you need to declare macro > CONFIG_SYS_NAND_DENALI_64BIT. > > Signed-off-by: Chin Liang See > Cc: Scott Wood > Cc: Masahiro Yamada > --- > Changes for v10 > - Updated the commit message to include Linux driver commit ID, > usage of macro CONFIG_SYS_NAND_DENALI_64BIT > - Removed casting for memcpy function > - Removed NAND_CMD_LOCK_TIGHT support as no longer in latest NAND driver Signed-off-by: Masahiro Yamada Reviewed-by: Masahiro Yamada Tested-by: Masahiro Yamada I am looking forward to get this driver in. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
Hi Ye,
On 12/09/2014 12:27, Li Ye-B37916 wrote:
>
> On 9/12/2014 4:17 PM, Stefano Babic wrote:
>> Hi Ye,
>>
>> On 10/09/2014 07:52, Ye.Li wrote:
>>> Initialize the Pfuze100 at board late init.
>>>
>>> Signed-off-by: Ye.Li
>>> ---
>>> board/freescale/mx6qsabreauto/mx6qsabreauto.c | 52
>>> -
>>> include/configs/mx6qsabreauto.h |6 +++
>>> 2 files changed, 57 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>>> b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>>> index bfb9b6a..76b024b 100644
>>> --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>>> +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (C) 2012 Freescale Semiconductor, Inc.
>>> + * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
>>> *
>>> * Author: Fabio Estevam
>>> *
>>> @@ -23,6 +23,8 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>>
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
>>>
>>> #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>>>
>>> +#define I2C_PMIC 1
>>> +
>>> int dram_init(void)
>>> {
>>> gd->ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
>>> @@ -259,6 +263,51 @@ int board_init(void)
>>> return 0;
>>> }
>>>
>>> +static int pfuze_init(void)
>>> +{
>>> + struct pmic *p;
>>> + int ret;
>>> + unsigned int reg;
>>> +
>>> + ret = power_pfuze100_init(I2C_PMIC);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + p = pmic_get("PFUZE100");
>>> + ret = pmic_probe(p);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + pmic_reg_read(p, PFUZE100_DEVICEID, ®);
>>> + printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
>>> +
>>> + /* Set SW1AB stanby volage to 0.975V */
>>> + pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
>>> + reg &= ~0x3f;
>>> + reg |= 0x1b;
>>> + pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
>>> +
>>> + /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
>>> + pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
>>> + reg &= ~0xc0;
>>> + reg |= 0x40;
>>> + pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
>>> +
>>> + /* Set SW1C standby voltage to 0.975V */
>>> + pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
>>> + reg &= ~0x3f;
>>> + reg |= 0x1b;
>>> + pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
>>> +
>>> + /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
>>> + pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
>>> + reg &= ~0xc0;
>>> + reg |= 0x40;
>>> + pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
>>> +
>>> + return 0;
>>> +}
>> The initialization, with the exception of VGEN3/VGEN5, is identical to
>> the sabresd. Any possibility to improve code and factorize the function
>> for sabre* boards ?
>>
>> Best regards,
>> Stefano Babic
>>
> Yes. The pfuze codes are similar on these boards. I will try to factorize the
> function. How about moving the common codes to "board/freescale/imx" ?
>
Agree. The imx directory can contain all common code shared among
Freescale's board.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] imx: mx6slevk: Add I2C1 support
Hi Stefano,
On 9/12/2014 6:08 PM, Stefano Babic wrote:
> Hi Ye,
>
>
> On 11/09/2014 05:13, Ye.Li wrote:
>> Add I2C1 pin and pad settings, and enable the MXC I2C driver.
>>
> I see two different topics in this patch:
>
> 1. Add I2C1 pins to mx6sl pins. This is general, and not related to a
> specific board.
>
> 2. Add I2C1 support to 6slevk board, as in subject.
>
> Please spliut this patch to address ewach related issue.
>
> Thanks,
> Stefano Babic
>
>> Signed-off-by: Ye.Li
>> ---
>> Changes since v1:
>> - None
>>
>> Changes since v2:
>> - None
>>
>> arch/arm/include/asm/arch-mx6/mx6sl_pins.h |5 +
>> board/freescale/mx6slevk/mx6slevk.c| 26 ++
>> include/configs/mx6slevk.h |6 ++
>> 3 files changed, 37 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
>> b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
>> index 045ccc4..ac84270 100644
>> --- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
>> +++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
>> @@ -34,5 +34,10 @@ enum {
>> MX6_PAD_FEC_REF_CLK__FEC_REF_OUT=
>> IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
>> MX6_PAD_FEC_RX_ER__GPIO_4_19=
>> IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
>> MX6_PAD_FEC_TX_CLK__GPIO_4_21 =
>> IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
>> +
>> +MX6_PAD_I2C1_SDA__I2C1_SDA =
>> IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
>> +MX6_PAD_I2C1_SDA__GPIO_3_13 =
>> IOMUX_PAD(0x0450, 0x0160, 5, 0x, 0, 0),
>> +MX6_PAD_I2C1_SCL__I2C1_SCL =
>> IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
>> +MX6_PAD_I2C1_SCL__GPIO_3_12 =
>> IOMUX_PAD(0x044C, 0x015C, 5, 0x, 0, 0),
>> };
>> #endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
>> diff --git a/board/freescale/mx6slevk/mx6slevk.c
>> b/board/freescale/mx6slevk/mx6slevk.c
>> index a990b4c..fedd5c3 100644
>> --- a/board/freescale/mx6slevk/mx6slevk.c
>> +++ b/board/freescale/mx6slevk/mx6slevk.c
>> @@ -13,12 +13,14 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> +#include
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -37,8 +39,29 @@ DECLARE_GLOBAL_DATA_PTR;
>> #define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
>>PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
>>
>> +#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
>> +PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
>> +PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
>> +PAD_CTL_ODE | PAD_CTL_SRE_FAST)
>> +
>> #define ETH_PHY_RESET IMX_GPIO_NR(4, 21)
>>
>> +#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>> +
>> +/* I2C1 for PMIC */
>> +struct i2c_pads_info i2c_pad_info0 = {
>> +.sda = {
>> +.i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
>> +.gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
>> +.gp = IMX_GPIO_NR(3, 13),
>> +},
>> +.scl = {
>> +.i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
>> +.gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
>> +.gp = IMX_GPIO_NR(3, 12),
>> +},
>> +};
>> +
>> int dram_init(void)
>> {
>> gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
>> @@ -162,6 +185,9 @@ int board_init(void)
>> #ifdef CONFIG_FEC_MXC
>> setup_fec();
>> #endif
>> +
>> +setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info0);
>> +
>> return 0;
>> }
>>
>> diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
>> index 3d05a64..bf5066f 100644
>> --- a/include/configs/mx6slevk.h
>> +++ b/include/configs/mx6slevk.h
>> @@ -60,6 +60,12 @@
>> #define CONFIG_PHYLIB
>> #define CONFIG_PHY_SMSC
>>
>> +/* I2C Configs */
>> +#define CONFIG_CMD_I2C
>> +#define CONFIG_SYS_I2C
>> +#define CONFIG_SYS_I2C_MXC
>> +#define CONFIG_SYS_I2C_SPEED 10
>> +
>> /* allow to overwrite serial and ethaddr */
>> #define CONFIG_ENV_OVERWRITE
>> #define CONFIG_CONS_INDEX 1
>>
>
I will split this patch to two in v4.
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
On 9/12/2014 4:17 PM, Stefano Babic wrote:
> Hi Ye,
>
> On 10/09/2014 07:52, Ye.Li wrote:
>> Initialize the Pfuze100 at board late init.
>>
>> Signed-off-by: Ye.Li
>> ---
>> board/freescale/mx6qsabreauto/mx6qsabreauto.c | 52
>> -
>> include/configs/mx6qsabreauto.h |6 +++
>> 2 files changed, 57 insertions(+), 1 deletions(-)
>>
>> diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>> b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>> index bfb9b6a..76b024b 100644
>> --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>> +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (C) 2012 Freescale Semiconductor, Inc.
>> + * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
>> *
>> * Author: Fabio Estevam
>> *
>> @@ -23,6 +23,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>> #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>>
>> +#define I2C_PMIC1
>> +
>> int dram_init(void)
>> {
>> gd->ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
>> @@ -259,6 +263,51 @@ int board_init(void)
>> return 0;
>> }
>>
>> +static int pfuze_init(void)
>> +{
>> +struct pmic *p;
>> +int ret;
>> +unsigned int reg;
>> +
>> +ret = power_pfuze100_init(I2C_PMIC);
>> +if (ret)
>> +return ret;
>> +
>> +p = pmic_get("PFUZE100");
>> +ret = pmic_probe(p);
>> +if (ret)
>> +return ret;
>> +
>> +pmic_reg_read(p, PFUZE100_DEVICEID, ®);
>> +printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
>> +
>> +/* Set SW1AB stanby volage to 0.975V */
>> +pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
>> +reg &= ~0x3f;
>> +reg |= 0x1b;
>> +pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
>> +
>> +/* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
>> +pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
>> +reg &= ~0xc0;
>> +reg |= 0x40;
>> +pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
>> +
>> +/* Set SW1C standby voltage to 0.975V */
>> +pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
>> +reg &= ~0x3f;
>> +reg |= 0x1b;
>> +pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
>> +
>> +/* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
>> +pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
>> +reg &= ~0xc0;
>> +reg |= 0x40;
>> +pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
>> +
>> +return 0;
>> +}
> The initialization, with the exception of VGEN3/VGEN5, is identical to
> the sabresd. Any possibility to improve code and factorize the function
> for sabre* boards ?
>
> Best regards,
> Stefano Babic
>
Yes. The pfuze codes are similar on these boards. I will try to factorize the
function. How about moving the common codes to "board/freescale/imx" ?
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] imx: mx6sabresd: Add clear print for pfuze200
Hi Ye,
On 11/09/2014 05:13, Ye.Li wrote:
> Add clear print log to show pfuze200 or pfuze100 found on mx6sabresd.
>
> Signed-off-by: Ye.Li
> ---
> Changes since v1:
> - None
>
> Changes since v2:
> - None
>
> board/freescale/mx6sabresd/mx6sabresd.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
> b/board/freescale/mx6sabresd/mx6sabresd.c
> index 5f65f1b..72d6562 100644
> --- a/board/freescale/mx6sabresd/mx6sabresd.c
> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
> @@ -472,7 +472,8 @@ static int pfuze_init(void)
> return ret;
>
> pmic_reg_read(p, PFUZE100_DEVICEID, ®);
> - printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
> + printf("PMIC: PFUZE%s ID=0x%02x\n",
> + ((reg & 0xf) == 0) ? "100" : "200", reg);
>
> /* Increase VGEN3 from 2.5 to 2.8V */
> pmic_reg_read(p, PFUZE100_VGEN3VOL, ®);
>
This is completely unrelated to the series - it can be applied
independently from the other patches. You do not need to resend this one
but please send in future patches belonging to the same series if they
are related to the same issue or to the same set of issues. This
simplifies review and merging - thanks !
Acked-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] imx: mx6slevk: Add I2C1 support
Hi Ye,
On 11/09/2014 05:13, Ye.Li wrote:
> Add I2C1 pin and pad settings, and enable the MXC I2C driver.
>
I see two different topics in this patch:
1. Add I2C1 pins to mx6sl pins. This is general, and not related to a
specific board.
2. Add I2C1 support to 6slevk board, as in subject.
Please spliut this patch to address ewach related issue.
Thanks,
Stefano Babic
> Signed-off-by: Ye.Li
> ---
> Changes since v1:
> - None
>
> Changes since v2:
> - None
>
> arch/arm/include/asm/arch-mx6/mx6sl_pins.h |5 +
> board/freescale/mx6slevk/mx6slevk.c| 26 ++
> include/configs/mx6slevk.h |6 ++
> 3 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
> b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
> index 045ccc4..ac84270 100644
> --- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
> +++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
> @@ -34,5 +34,10 @@ enum {
> MX6_PAD_FEC_REF_CLK__FEC_REF_OUT=
> IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
> MX6_PAD_FEC_RX_ER__GPIO_4_19=
> IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
> MX6_PAD_FEC_TX_CLK__GPIO_4_21 =
> IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
> +
> + MX6_PAD_I2C1_SDA__I2C1_SDA =
> IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
> + MX6_PAD_I2C1_SDA__GPIO_3_13 =
> IOMUX_PAD(0x0450, 0x0160, 5, 0x, 0, 0),
> + MX6_PAD_I2C1_SCL__I2C1_SCL =
> IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
> + MX6_PAD_I2C1_SCL__GPIO_3_12 =
> IOMUX_PAD(0x044C, 0x015C, 5, 0x, 0, 0),
> };
> #endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
> diff --git a/board/freescale/mx6slevk/mx6slevk.c
> b/board/freescale/mx6slevk/mx6slevk.c
> index a990b4c..fedd5c3 100644
> --- a/board/freescale/mx6slevk/mx6slevk.c
> +++ b/board/freescale/mx6slevk/mx6slevk.c
> @@ -13,12 +13,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -37,8 +39,29 @@ DECLARE_GLOBAL_DATA_PTR;
> #define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
> PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
>
> +#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
> + PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> + PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
> + PAD_CTL_ODE | PAD_CTL_SRE_FAST)
> +
> #define ETH_PHY_RESETIMX_GPIO_NR(4, 21)
>
> +#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> +
> +/* I2C1 for PMIC */
> +struct i2c_pads_info i2c_pad_info0 = {
> + .sda = {
> + .i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
> + .gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
> + .gp = IMX_GPIO_NR(3, 13),
> + },
> + .scl = {
> + .i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
> + .gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
> + .gp = IMX_GPIO_NR(3, 12),
> + },
> +};
> +
> int dram_init(void)
> {
> gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> @@ -162,6 +185,9 @@ int board_init(void)
> #ifdef CONFIG_FEC_MXC
> setup_fec();
> #endif
> +
> + setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info0);
> +
> return 0;
> }
>
> diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
> index 3d05a64..bf5066f 100644
> --- a/include/configs/mx6slevk.h
> +++ b/include/configs/mx6slevk.h
> @@ -60,6 +60,12 @@
> #define CONFIG_PHYLIB
> #define CONFIG_PHY_SMSC
>
> +/* I2C Configs */
> +#define CONFIG_CMD_I2C
> +#define CONFIG_SYS_I2C
> +#define CONFIG_SYS_I2C_MXC
> +#define CONFIG_SYS_I2C_SPEED 10
> +
> /* allow to overwrite serial and ethaddr */
> #define CONFIG_ENV_OVERWRITE
> #define CONFIG_CONS_INDEX1
>
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCs
The code provides framework for heterogeneous multicore chips based on StarCore
and Power Architecture which are chasis-2 compliant, like B4860 and B4420
It will make u-boot recognize all non-ppc cores and peripherals like
SC3900/DSP CPUs, MAPLE, CPRI and print their configuration in u-boot logs.
Example boot logs of B4420:
Clock Configuration:
CPU0:1600 MHz, CPU1:1600 MHz,
DSP CPU0:1200 MHz, DSP CPU1:1200 MHz,
CCB:666.667 MHz,
DDR:800 MHz (1600 MT/s data rate) (Asynchronous), IFC:166.667 MHz
CPRI:600 MHz
MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
FMAN1: 666.667 MHz
QMAN: 333.333 MHz
Top level changes include:
(1) Top level CONFIG to identify HETEROGENUOUS clusters
(2) CONFIGS for SC3900/DSP components
(3) Global structure updated for dsp cores and other components
(3) APIs to get DSP num cores and their Mask like:
cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC
(5) Code to fetch and print SC cores and other heterogenous
device's frequencies
(6) README added for the same
Signed-off-by: Shaveta Leekha
---
arch/powerpc/cpu/mpc85xx/cpu.c| 25 ++
arch/powerpc/cpu/mpc85xx/speed.c | 133 +
arch/powerpc/cpu/mpc8xxx/cpu.c| 83 ++-
arch/powerpc/include/asm/config_mpc85xx.h | 13 +++-
arch/powerpc/include/asm/processor.h |1 +
doc/README.Heterogeneous-SoCs | 105 +++
include/common.h |2 +
include/e500.h|9 ++
8 files changed, 368 insertions(+), 3 deletions(-)
create mode 100644 doc/README.Heterogeneous-SoCs
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 6274f92..43f5331 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -71,7 +71,9 @@ int checkcpu (void)
#endif /* CONFIG_FSL_CORENET */
unsigned int i, core, nr_cores = cpu_numcores();
+ unsigned int j, dsp_core, dsp_numcores = cpu_num_dspcores();
u32 mask = cpu_mask();
+ u32 dsp_mask = cpu_dsp_mask();
svr = get_svr();
major = SVR_MAJ(svr);
@@ -166,6 +168,16 @@ int checkcpu (void)
printf("CPU%d:%-4s MHz, ", core,
strmhz(buf1, sysinfo.freq_processor[core]));
}
+
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ for_each_cpu(j, dsp_core, dsp_numcores, dsp_mask) {
+ if (!(j & 3))
+ printf("\n ");
+ printf("DSP CPU%d:%-4s MHz, ", j,
+ strmhz(buf1, sysinfo.freq_processor_dsp[dsp_core]));
+ }
+#endif
+
printf("\n CCB:%-4s MHz,", strmhz(buf1, sysinfo.freq_systembus));
printf("\n");
@@ -224,6 +236,19 @@ int checkcpu (void)
printf(" QE:%-4s MHz\n", strmhz(buf1, sysinfo.freq_qe));
#endif
+#if defined(CONFIG_SYS_CPRI)
+ printf(" ");
+ printf("CPRI:%-4s MHz", strmhz(buf1, sysinfo.freq_cpri));
+#endif
+
+#if defined(CONFIG_SYS_MAPLE)
+ printf("\n ");
+ printf("MAPLE:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple));
+ printf("MAPLE-ULB:%-4s MHz, ", strmhz(buf1, sysinfo.freq_maple_ulb));
+ printf("MAPLE-eTVPE:%-4s MHz\n",
+ strmhz(buf1, sysinfo.freq_maple_etvpe));
+#endif
+
#ifdef CONFIG_SYS_DPAA_FMAN
for (i = 0; i < CONFIG_SYS_NUM_FMAN; i++) {
printf(" FMAN%d: %s MHz\n", i + 1,
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 3236f6a..9a2b487 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -35,6 +35,7 @@ void get_sys_info(sys_info_t *sys_info)
volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR);
unsigned int cpu;
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
+ unsigned int dsp_cpu;
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS;
#endif
@@ -68,6 +69,7 @@ void get_sys_info(sys_info_t *sys_info)
[14] = 4, /* CC4 PPL / 4 */
};
uint i, freq_c_pll[CONFIG_SYS_FSL_NUM_CC_PLLS];
+ uint rcw_tmp1, rcw_tmp2;
#if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV)
uint rcw_tmp;
#endif
@@ -164,6 +166,16 @@ void get_sys_info(sys_info_t *sys_info)
sys_info->freq_processor[cpu] =
freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
+
+ for_each_cpu(i, dsp_cpu, cpu_num_dspcores(), cpu_dsp_mask()) {
+ int cluster = fsl_qoriq_dsp_core_to_cluster(dsp_cpu);
+ u32 c_pll_sel = (in_be32(&clk->clkcsr[cluster].clkcncsr) >> 27)
+ & 0xf;
+ u32 cplx_pll = core_cplx_PLL[c_pll_sel];
+ cplx_pll += cc_group[cluster] - 1;
+ sys_info->freq_processor_dsp[dsp_cpu] =
+freq_c_pll[cplx_pll]
[U-Boot] [PATCH v2 1/1] net: dns: fix for DNS queries sent to the wrong MAC address
When a DNS query is sent out, the ethernet packet can get directed to
the MAC address of a server that was communicated to before. This is
wrong when the previously stored MAC address corresponds to a different
server's IP address, i.e. when the IP address of the previous and the
current communication are different.
The error can get reproduced by running a sequence of e.g. a TFTP
download and a DNS query, where the TFTP and DNS servers reside on
individual machines.
The fix is to clear the server's MAC address that might be left from a
previous operation, and to fetch the peer's MAC address in a new ARP
lookup, before the DNS query is sent. This is the approach taken in
other network services, like 8e52533d1095 ("net: tftpsrv: Get correct
client MAC address").
Reported-by: Dirk Zimoch
Signed-off-by: Gerhard Sittig
---
This patch suffers from a checkpatch warning about CamelCase, which
cannot get resolved, as it is a consequence of established identifier
names in the network part of the code base.
changes in v2:
- adjust the recipients lists to include the network custodian
- drop an obvious/redundant comment as recommended by Joe Hershberger
---
net/dns.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/net/dns.c b/net/dns.c
index ff9ddffc9d0a..dd4532015045 100644
--- a/net/dns.c
+++ b/net/dns.c
@@ -202,5 +202,8 @@ DnsStart(void)
NetSetTimeout(DNS_TIMEOUT, DnsTimeout);
net_set_udp_handler(DnsHandler);
+ /* Clear a previous MAC address, the server IP might have changed. */
+ memset(NetServerEther, 0, sizeof(NetServerEther));
+
DnsSend();
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: mxc_spi: remove second reset from ECSPI config handler
I will pick! On 12 September 2014 14:20, Stefano Babic wrote: > Hi Markus, > > On 01/09/2014 10:46, Markus Niebel wrote: >> From: Markus Niebel >> >> the second reset prevents other registers to be written. >> This will prevent to have the correct signal levels for >> SCLK before writing to the config reg in spi_xchg_single. >> >> Tested with GPIO based chipselect and SPI_MODE_3 on i.MX6S >> >> Signed-off-by: Markus Niebel >> --- >> drivers/spi/mxc_spi.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c >> index 2d5f385..6a05d15 100644 >> --- a/drivers/spi/mxc_spi.c >> +++ b/drivers/spi/mxc_spi.c >> @@ -163,9 +163,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, >> unsigned int cs, >> reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_POSTDIV(0x0F)) | >> MXC_CSPICTRL_POSTDIV(post_div); >> >> - /* We need to disable SPI before changing registers */ >> - reg_ctrl &= ~MXC_CSPICTRL_EN; >> - >> if (mode & SPI_CS_HIGH) >> ss_pol = 1; >> >> > > Acked-by: Stefano Babic > > Jagannadha, this series is currently assigned to me in patchwork. Should > I merge into u-boot-imx or do you prefer to merge the two patches into > u-boot-spi ? > > Best regards, > Stefano Babic > > -- > = > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: mxc_spi: remove second reset from ECSPI config handler
Hi Markus, On 01/09/2014 10:46, Markus Niebel wrote: > From: Markus Niebel > > the second reset prevents other registers to be written. > This will prevent to have the correct signal levels for > SCLK before writing to the config reg in spi_xchg_single. > > Tested with GPIO based chipselect and SPI_MODE_3 on i.MX6S > > Signed-off-by: Markus Niebel > --- > drivers/spi/mxc_spi.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c > index 2d5f385..6a05d15 100644 > --- a/drivers/spi/mxc_spi.c > +++ b/drivers/spi/mxc_spi.c > @@ -163,9 +163,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, > unsigned int cs, > reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_POSTDIV(0x0F)) | > MXC_CSPICTRL_POSTDIV(post_div); > > - /* We need to disable SPI before changing registers */ > - reg_ctrl &= ~MXC_CSPICTRL_EN; > - > if (mode & SPI_CS_HIGH) > ss_pol = 1; > > Acked-by: Stefano Babic Jagannadha, this series is currently assigned to me in patchwork. Should I merge into u-boot-imx or do you prefer to merge the two patches into u-boot-spi ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] imx: Support i.MX6 High Assurance Boot authentication
Hi Nitin,
On 04/09/2014 03:18, Nitin Garg wrote:
> When CONFIG_SECURE_BOOT is enabled, the signed images
> like kernel and dtb can be authenticated using iMX6 CAAM.
> The added command hab_auth_img can be used for HAB
> authentication of images. The command takes the image
> DDR location, IVT (Image Vector Table) offset inside
> image as parameters. Detailed info about signing images
> can be found in Freescale AppNote AN4581.
>
> Signed-off-by: Nitin Garg
>
> ---
>
> Changes in v3:
> - Remove typecast of get_cpu_rev since its not required
>
> Changes in v2:
> - Cleaned up clock code as per review comments
> - Removed dead code as per review comments
> - Re-written commit log as per review comments
>
> arch/arm/cpu/armv7/mx6/clock.c| 32 ++-
> arch/arm/cpu/armv7/mx6/hab.c | 165
> -
> arch/arm/cpu/armv7/mx6/soc.c | 15 +++
> arch/arm/include/asm/arch-mx6/clock.h |4 +
> 4 files changed, 214 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index 820b8d5..db6a8fc 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
> + * Copyright (C) 2010-2014 Freescale Semiconductor, Inc.
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -543,6 +543,36 @@ int enable_pcie_clock(void)
> BM_ANADIG_PLL_ENET_ENABLE_PCIE);
> }
>
> +#ifdef CONFIG_SECURE_BOOT
> +void hab_caam_clock_enable(void)
> +{
> + struct mxc_ccm_reg *const imx_ccm =
> + (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> +
> + /*CG4 ~ CG6, enable CAAM clocks*/
> + setbits_le32(&imx_ccm->CCGR0, MXC_CCM_CCGR0_CAAM_WRAPPER_IPG_MASK |
> + MXC_CCM_CCGR0_CAAM_WRAPPER_ACLK_MASK |
> + MXC_CCM_CCGR0_CAAM_SECURE_MEM_MASK);
> +
> + /* Enable EMI slow clk */
> + setbits_le32(&imx_ccm->CCGR6, MXC_CCM_CCGR6_EMI_SLOW_MASK);
> +}
> +
> +void hab_caam_clock_disable(void)
> +{
> + struct mxc_ccm_reg *const imx_ccm =
> + (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> +
> + /*CG4 ~ CG6, disable CAAM clocks*/
> + clrbits_le32(&imx_ccm->CCGR0, MXC_CCM_CCGR0_CAAM_WRAPPER_IPG_MASK |
> + MXC_CCM_CCGR0_CAAM_WRAPPER_ACLK_MASK |
> + MXC_CCM_CCGR0_CAAM_SECURE_MEM_MASK);
> +
> + /* Disable EMI slow clk */
> + clrbits_le32(&imx_ccm->CCGR6, MXC_CCM_CCGR6_EMI_SLOW_MASK);
> +}
> +#endif
Generally, we have in clock.c one function per clock, getting as
enable_uart_clkparameter a boolean for enabling/disabling (i.e.
enable_ocotp_clk(), enable_uart_clk(),...)
Please stick with the same rule.
> +
> unsigned int mxc_get_clock(enum mxc_clock clk)
> {
> switch (clk) {
> diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
> index f6810a6..61a94a1 100644
> --- a/arch/arm/cpu/armv7/mx6/hab.c
> +++ b/arch/arm/cpu/armv7/mx6/hab.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2010-2014 Freescale Semiconductor, Inc.
> *
> * SPDX-License-Identifier:GPL-2.0+
> */
> @@ -7,8 +7,12 @@
> #include
> #include
> #include
> +#include
> #include
>
> +/* HAB (High Assurance Boot) debug */
> +#undef DEBUG_AUTHENTICATE_IMAGE
This is never defined, you do not need to undefine it.
> +
> /* start of HAB API updates */
>
> #define hab_rvt_report_event_p \
> @@ -71,6 +75,41 @@
> ((hab_rvt_exit_t *)HAB_RVT_EXIT)\
> )
>
> +#define IVT_SIZE 0x20
> +#define ALIGN_SIZE 0x1000
> +#define CSF_PAD_SIZE 0x2000
> +
> +/*
> + * ++ 0x0 (DDR_UIMAGE_START) -
> + * | Header | |
> + * ++ 0x40|
> + * || |
> + * || |
> + * || |
> + * || |
> + * | Image Data | |
> + * .| |
> + * .| > Stuff to be authenticated +
> + * .| ||
> + * || ||
> + * || ||
> + * ++ ||
> + * || ||
> + * | Fill Data | ||
> + * || ||
> + * ++ Align to ALIGN_SIZE ||
> + * |IVT |
Re: [U-Boot] [PATCH 0/8] samsung: Use common config files with Samsung boards (help wanted)
Hello Simon, On 09/09/2014 12:31 PM, Przemyslaw Marczak wrote: Hi, I will test this patch set on a trats2 board - today evening. On 09/09/2014 08:05 AM, Simon Glass wrote: Hi Minkyu, On 25 July 2014 08:43, Simon Glass wrote: Hi Lucasz, On 24 July 2014 09:34, Lukasz Majewski wrote: Hi Simon, This series tries to unify the Samsung board configs into a few header files for exynos5 and exynos5. The purpose is to make it easier to move to driver model. In that case I would like things like the GPIO drivers and serial drivers to work in a standard way, and not need to support device tree and platform data at the same time. That would be quite painful. Another reason is that the Chrome OS EC drivers are currently included in boards that don't have a Chrome OS EC. This concern was raised by the Samsung maintainer (Minkyu) a while back. There are still a few boards that don't use CONFIG_OF_CONTROL so I have updated these with the most rudimentary of device tree files. Unfortunately I don't have boards for most of these (for testing) and I am hoping that the maintainers can come to the rescue and fix up any patches that have problems. I am also worried that I have used a common exynos file for things like smdkv310, when in fact they have some other chip in common. So maintainers, please can you test this and re-issue the patch, or make comments on my attempts? We will do our best to test our Exynos4 based boards. Thanks - please feel free to re-issue the patches and I will drop mine (if you cc me). Can you please review this series? We are already at rc2. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Best regards, It works fine on trats2. I'm currently working on PMIC framework at the top of your u-boot-dm/working branch and it also works fine on Trats2. Best regards -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
Hi Ye,
On 10/09/2014 07:52, Ye.Li wrote:
> Initialize the Pfuze100 at board late init.
>
> Signed-off-by: Ye.Li
> ---
> board/freescale/mx6qsabreauto/mx6qsabreauto.c | 52
> -
> include/configs/mx6qsabreauto.h |6 +++
> 2 files changed, 57 insertions(+), 1 deletions(-)
>
> diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> index bfb9b6a..76b024b 100644
> --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (C) 2012 Freescale Semiconductor, Inc.
> + * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
> *
> * Author: Fabio Estevam
> *
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
>
> #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>
> +#define I2C_PMIC 1
> +
> int dram_init(void)
> {
> gd->ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
> @@ -259,6 +263,51 @@ int board_init(void)
> return 0;
> }
>
> +static int pfuze_init(void)
> +{
> + struct pmic *p;
> + int ret;
> + unsigned int reg;
> +
> + ret = power_pfuze100_init(I2C_PMIC);
> + if (ret)
> + return ret;
> +
> + p = pmic_get("PFUZE100");
> + ret = pmic_probe(p);
> + if (ret)
> + return ret;
> +
> + pmic_reg_read(p, PFUZE100_DEVICEID, ®);
> + printf("PMIC: PFUZE100 ID=0x%02x\n", reg);
> +
> + /* Set SW1AB stanby volage to 0.975V */
> + pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
> + reg &= ~0x3f;
> + reg |= 0x1b;
> + pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
> +
> + /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
> + pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
> + reg &= ~0xc0;
> + reg |= 0x40;
> + pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
> +
> + /* Set SW1C standby voltage to 0.975V */
> + pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
> + reg &= ~0x3f;
> + reg |= 0x1b;
> + pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
> +
> + /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
> + pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
> + reg &= ~0xc0;
> + reg |= 0x40;
> + pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
> +
> + return 0;
> +}
The initialization, with the exception of VGEN3/VGEN5, is identical to
the sabresd. Any possibility to improve code and factorize the function
for sabre* boards ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/6] nand: denali: add Denali NAND driver for SPL
Hi.
> > Changes in v4:
> > - Add a workaround to not depend on the Denali driver
> > posted by Chin Liang See.
> > This driver has been taking too long:
> > http://patchwork.ozlabs.org/patch/381305/
> >
>
> Yup, hopefully v10 would be the final patch.
I hope so.
> > +static int nand_block_isbad(int block)
> > +{
> > + int ret;
> > +
> > + ret = nand_read_oob(page_buffer, block * pages_per_block);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return page_buffer[CONFIG_SYS_NAND_BAD_BLOCK_POS] != 0xff;
> > +}
> > +
> > +/* nand_init() - initialize data to make nand usable by SPL */
> > +void nand_init(void)
> > +{
> > + /* access to main area */
> > + writel(0, denali_flash_reg + TRANSFER_SPARE_REG);
> > +
> > + page_size = readl(denali_flash_reg + DEVICE_MAIN_AREA_SIZE);
> > + oob_size = readl(denali_flash_reg + DEVICE_SPARE_AREA_SIZE);
> > + pages_per_block = readl(denali_flash_reg + PAGES_PER_BLOCK);
>
>
> I believe this will work for ONFI NAND devices only.
> For non-ONFI, the value might not correct.
I don't think so.
It depends on the hardware; in my understanding
Denali IP is capable of detecting MAIN_AREA_SIZE etc.
for non-ONFI devices. At least this is working with non-ONFI devices
on some Panasonic boards.
If it does not work for Altera SoCs (and if you are planning to use
this driver), these three registers should be set in advance
in an earlier board init.
> > +}
> > +
> > +int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
> > +{
> > + int block, page, column, readlen;
> > + int ret;
> > + int force_bad_block_check = 1;
> > +
> > + page = offs / page_size;
> > + column = offs % page_size;
> > +
> > + block = page / pages_per_block;
> > + page = page % pages_per_block;
> > +
> > + while (size) {
>
> I believe we need to error out when reading beyond last block.
How do you know the number of blocks of non-ONFI devices?
Scan nand_ids.c for SPL?
>
> > + if (force_bad_block_check || page == 0) {
> > + ret = nand_block_isbad(block);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (ret) {
> > + block++;
> > + continue;
> > + }
> > + }
> > +
> > + force_bad_block_check = 0;
>
> I believe we still need to check the subsequent block whether is bad or
> not too. This can be enable when cross the block boundary.
I am afraid you are misunderstanding my code.
This function does bad block checking for every block.
Here,
if (force_bad_block_check || page == 0) {
ret = nand_block_isbad(block);
"page == 0" means the beginning of each block.
>
>
> Currently U-Boot has drivers/mtd/nand/nand_spl_simple.c which handling
> the SPL NAND image load. Wonder this driver will be integrated into
> nand_spl_simple.c once drivers/mtd/nand/denali.c is applied?
I am not planning to do so because:
[1] nand_spl_simple.c requires CONFIG_SYS_NAND_BLOCK_SIZE,
CONFIG_SYS_NAND_PAGE_SIZE,
CONFIG_SYS_NAND_PAGE_COUNT; we need to specify the device attributes at
compilation,
which the Denali IP is able to detect at run time.
It is not acceptable for us because we need (want) the run time configuration.
[2] nand_spl_simple.c is so generic that it cannot use the hardware
acceleration of
the Denali IP, that is, slower booting.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] mtd: nand: add Freescale vf610_nfc driver
Hi Stefan, On 11/09/2014 15:07, Stefan Agner wrote: > This adds initial support for Freescale NFC (NAND Flash Controller) > found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. > The driver is called vf610_nfc since this is the first supported > and tested hardware platform supported by the driver. > > Signed-off-by: Stefan Agner > --- By applying I have seen some other minor issues. checkpatch reports some warnings, can you fix them ? WARNING: line over 80 characters #200: FILE: drivers/mtd/nand/vf610_nfc.c:157: +#define mtd_to_nfc(_mtd) (struct vf610_nfc *)((struct nand_chip *)_mtd->priv)->priv; CHECK: Alignment should match open parenthesis #367: FILE: drivers/mtd/nand/vf610_nfc.c:324: + vf610_nfc_set_field(mtd, NFC_COL_ADDR, COL_ADDR_MASK, + COL_ADDR_SHIFT, column); CHECK: Alignment should match open parenthesis #371: FILE: drivers/mtd/nand/vf610_nfc.c:328: + vf610_nfc_set_field(mtd, NFC_ROW_ADDR, ROW_ADDR_MASK, + ROW_ADDR_SHIFT, page); CHECK: Alignment should match open parenthesis #388: FILE: drivers/mtd/nand/vf610_nfc.c:345: + vf610_nfc_send_commands(nfc->regs, NAND_CMD_SEQIN, +command, PROGRAM_PAGE_CMD_CODE); CHECK: Alignment should match open parenthesis #409: FILE: drivers/mtd/nand/vf610_nfc.c:366: + vf610_nfc_send_commands(nfc->regs, NAND_CMD_READ0, + NAND_CMD_READSTART, READ_PAGE_CMD_CODE); CHECK: Alignment should match open parenthesis #417: FILE: drivers/mtd/nand/vf610_nfc.c:374: + vf610_nfc_send_commands(nfc->regs, command, + NAND_CMD_ERASE2, ERASE_CMD_CODE); WARNING: line over 80 characters #428: FILE: drivers/mtd/nand/vf610_nfc.c:385: + vf610_nfc_send_command(nfc->regs, command, STATUS_READ_CMD_CODE); WARNING: line over 80 characters #460: FILE: drivers/mtd/nand/vf610_nfc.c:417: + vf610_nfc_memcpy(buf, nfc->regs + NFC_MAIN_AREA(0) + c, l); CHECK: Alignment should match open parenthesis #668: FILE: drivers/mtd/nand/vf610_nfc.c:625: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_MODE_MASK, CHECK: Alignment should match open parenthesis #690: FILE: drivers/mtd/nand/vf610_nfc.c:647: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, CONFIG_PAGE_CNT_MASK, + CONFIG_PAGE_CNT_SHIFT, 1); CHECK: Alignment should match open parenthesis #694: FILE: drivers/mtd/nand/vf610_nfc.c:651: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_SRAM_ADDR_MASK, CHECK: Alignment should match open parenthesis #737: FILE: drivers/mtd/nand/vf610_nfc.c:694: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_MODE_MASK, > drivers/mtd/nand/Makefile| 1 + > drivers/mtd/nand/vf610_nfc.c | 721 > +++ > 2 files changed, 722 insertions(+) > create mode 100644 drivers/mtd/nand/vf610_nfc.c > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index bf1312a..eef86d1 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o > obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o > obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o > obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o > +obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o > obj-$(CONFIG_NAND_MXC) += mxc_nand.o > obj-$(CONFIG_NAND_MXS) += mxs_nand.o > obj-$(CONFIG_NAND_NDFC) += ndfc.o > diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c > new file mode 100644 > index 000..f0eba9a > --- /dev/null > +++ b/drivers/mtd/nand/vf610_nfc.c > @@ -0,0 +1,721 @@ > +/* > + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others > + * > + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. > + * Ported to U-Boot by Stefan Agner > + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir > + * Jason ported to M54418TWR and MVFA5. > + * Authors: Stefan Agner > + * Bill Pringlemeir > + * Shaohui Xie > + * Jason Jin > + * > + * Based on original driver mpc5121_nfc.c. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * Limitations: > + * - Untested on MPC5125 and M54418. > + * - DMA not used. > + * - 2K pages or less. > + * - Only 2K page w. 64+OOB and hardware ECC. > + */ > + > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +/* Register Offsets */ > +#define NFC_FLASH_CMD1 0x3F00 > +#define NFC_FLASH_CMD2 0
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Hi everybody, On 02/09/2014 01:51, Fabio Estevam wrote: > On Mon, Sep 1, 2014 at 8:34 PM, Eric Nelson > wrote: > >> I believe that the Wand board is using the configuration files >> from the nitrogen6x tree. > > Yes, I should have said "As it stands today only mx6qsabresd and > congatec share the same mx6q_4x_mt41j128.cfg script." > I try to sumarize the result of the discussion. This file was factorized, but it was proofed that calibration data are very board specific, and factorizing this file is not correct. I agree with Fabio and Eric that it is very unlike to have the same calibration data for different boards and the reuse of the same data is not correct. However, with this statement the patch should also unbind the congatec board from the sabresd, not only change the reference. A congatec specific board must be also created in congatec/cgtqmx6eval, and it is only a case that it has the same values of the sabresd. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sort drivers/mmc/Makefile
On Tue, 2014-09-09 at 15:16 +0200, ZY - pavel wrote: > Sort drivers/mmc makefile, as requested by wd. > > Signed-off-by: Pavel Machek > > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile > index 464cee1..461d7d8 100644 > --- a/drivers/mmc/Makefile > +++ b/drivers/mmc/Makefile > @@ -5,37 +5,39 @@ > # SPDX-License-Identifier: GPL-2.0+ > # > > +obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o > +obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o > obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o > obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o > +obj-$(CONFIG_DWMMC) += dw_mmc.o > +obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o > obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o > obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o > obj-$(CONFIG_FTSDC021) += ftsdc021_sdhci.o > obj-$(CONFIG_GENERIC_MMC) += mmc.o > obj-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o > +obj-$(CONFIG_KONA_SDHCI) += kona_sdhci.o > obj-$(CONFIG_MMC_SPI) += mmc_spi.o > -obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o > +obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o > obj-$(CONFIG_MV_SDHCI) += mv_sdhci.o > +obj-$(CONFIG_MVEBU_MMC) += mvebu_mmc.o > obj-$(CONFIG_MXC_MMC) += mxcmmc.o > obj-$(CONFIG_MXS_MMC) += mxsmmc.o > obj-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o > obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o > -obj-$(CONFIG_SDHCI) += sdhci.o > -obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o > -obj-$(CONFIG_KONA_SDHCI) += kona_sdhci.o > +obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o > obj-$(CONFIG_S3C_SDI) += s3c_sdi.o > obj-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o > +obj-$(CONFIG_SDHCI) += sdhci.o > obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o > +obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o > obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o > obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o > -obj-$(CONFIG_DWMMC) += dw_mmc.o > -obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o > -obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o > obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o > -obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o > -obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o > + > ifdef CONFIG_SPL_BUILD > obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o > else > obj-$(CONFIG_GENERIC_MMC) += mmc_write.o > endif > -obj-$(CONFIG_MVEBU_MMC) += mvebu_mmc.o > + > Acked-by: Chin Liang See ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t4rdb: Add support of CPLD
This support of CPLD includes
- Files and register definitions
- Command to switch alternate bank
- Command to switch default bank
Signed-off-by: Chunhe Lan
---
board/freescale/t4rdb/Makefile |1 +
board/freescale/t4rdb/cpld.c | 136 ++
board/freescale/t4rdb/cpld.h | 49 ++
board/freescale/t4rdb/law.c |3 +
board/freescale/t4rdb/t4240rdb.c | 12
board/freescale/t4rdb/tlb.c |5 ++
include/configs/T4240RDB.h | 23 +++
7 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/t4rdb/cpld.c
create mode 100644 board/freescale/t4rdb/cpld.h
diff --git a/board/freescale/t4rdb/Makefile b/board/freescale/t4rdb/Makefile
index f7f7fc0..3886e3d 100644
--- a/board/freescale/t4rdb/Makefile
+++ b/board/freescale/t4rdb/Makefile
@@ -5,6 +5,7 @@
#
obj-$(CONFIG_T4240RDB) += t4240rdb.o
+obj-y += cpld.o
obj-y += ddr.o
obj-y += eth.o
obj-$(CONFIG_PCI) += pci.o
diff --git a/board/freescale/t4rdb/cpld.c b/board/freescale/t4rdb/cpld.c
new file mode 100644
index 000..d5f3812
--- /dev/null
+++ b/board/freescale/t4rdb/cpld.c
@@ -0,0 +1,136 @@
+/**
+ * Copyright 2014 Freescale Semiconductor
+ *
+ * Author: Chunhe Lan
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This file provides support for the board-specific CPLD used on some
Freescale
+ * reference boards.
+ *
+ * The following macros need to be defined:
+ *
+ * CONFIG_SYS_CPLD_BASE - The virtual address of the base of the
+ * CPLD register map
+ *
+ */
+
+#include
+#include
+#include
+
+#include "cpld.h"
+
+u8 cpld_read(unsigned int reg)
+{
+ void *p = (void *)CONFIG_SYS_CPLD_BASE;
+
+ return in_8(p + reg);
+}
+
+void cpld_write(unsigned int reg, u8 value)
+{
+ void *p = (void *)CONFIG_SYS_CPLD_BASE;
+
+ out_8(p + reg, value);
+}
+
+/**
+ * Set the boot bank to the alternate bank
+ */
+void cpld_set_altbank(void)
+{
+ u8 val, curbank, altbank, override;
+
+ val = CPLD_READ(vbank);
+ curbank = val & CPLD_BANK_SEL_MASK;
+
+ switch (curbank) {
+ case CPLD_SELECT_BANK0:
+ altbank = CPLD_SELECT_BANK4;
+ CPLD_WRITE(vbank, altbank);
+ override = CPLD_READ(software_on);
+ CPLD_WRITE(software_on, override | CPLD_BANK_SEL_EN);
+ CPLD_WRITE(sys_reset, CPLD_SYSTEM_RESET);
+ break;
+ case CPLD_SELECT_BANK4:
+ altbank = CPLD_SELECT_BANK0;
+ CPLD_WRITE(vbank, altbank);
+ override = CPLD_READ(software_on);
+ CPLD_WRITE(software_on, override | CPLD_BANK_SEL_EN);
+ CPLD_WRITE(sys_reset, CPLD_SYSTEM_RESET);
+ break;
+ default:
+ printf("CPLD Altbank Fail: Invalid value!\n");
+ return;
+ }
+}
+
+/**
+ * Set the boot bank to the default bank
+ */
+void cpld_set_defbank(void)
+{
+ u8 val;
+
+ val = CPLD_DEFAULT_BANK;
+
+ CPLD_WRITE(global_reset, val);
+}
+
+#ifdef DEBUG
+static void cpld_dump_regs(void)
+{
+ printf("chip_id1= 0x%02x\n", CPLD_READ(chip_id1));
+ printf("chip_id2= 0x%02x\n", CPLD_READ(chip_id2));
+ printf("sw_maj_ver = 0x%02x\n", CPLD_READ(sw_maj_ver));
+ printf("sw_min_ver = 0x%02x\n", CPLD_READ(sw_min_ver));
+ printf("hw_ver = 0x%02x\n", CPLD_READ(hw_ver));
+ printf("software_on = 0x%02x\n", CPLD_READ(software_on));
+ printf("cfg_rcw_src = 0x%02x\n", CPLD_READ(cfg_rcw_src));
+ printf("res0= 0x%02x\n", CPLD_READ(res0));
+ printf("vbank = 0x%02x\n", CPLD_READ(vbank));
+ printf("sw1_sysclk = 0x%02x\n", CPLD_READ(sw1_sysclk));
+ printf("sw2_status = 0x%02x\n", CPLD_READ(sw2_status));
+ printf("sw3_status = 0x%02x\n", CPLD_READ(sw3_status));
+ printf("sw4_status = 0x%02x\n", CPLD_READ(sw4_status));
+ printf("sys_reset = 0x%02x\n", CPLD_READ(sys_reset));
+ printf("global_reset= 0x%02x\n", CPLD_READ(global_reset));
+ printf("res1= 0x%02x\n", CPLD_READ(res1));
+ putc('\n');
+}
+#endif
+
+#ifndef CONFIG_SPL_BUILD
+int do_cpld(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int rc = 0;
+
+ if (argc <= 1)
+ return cmd_usage(cmdtp);
+
+ if (strcmp(argv[1], "reset") == 0) {
+ if (strcmp(argv[2], "altbank") == 0)
+ cpld_set_altbank();
+ else
+ cpld_set_defbank();
+#ifdef DEBUG
+ } else if (strcmp(argv[1], "dump") == 0) {
+ cpld_dump_regs();
+#endif
+ } else
+ rc = cmd_usage(cmdtp);
+
+ return rc;
+}
+
+U_BOOT_CMD(
+ cpld, CONFIG_SYS_MAXARGS, 1, do_cpld,
+ "Reset the board or alternate bank",
+ "reset - reset to default bank\n"
+ "cpld reset altbank - re
Re: [U-Boot] [PATCH] dw_mmc: cleanups
Hi,
On Thu, 2014-09-11 at 11:06 +0900, Jaehoon Chung wrote:
> Hi, Pavel.
>
> It looks good to me.
> If you're ok, can i suggest one thing?
>
> On 09/05/2014 07:49 PM, Pavel Machek wrote:
> >
> > dw_mmc driver was responding to errors with debug(). Change that to
> > prinf so that any errors are immediately obvious. Also adjust english
> > in comments.
> >
> > Signed-off-by: Pavel Machek
> >
> > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> > index 0df30bc..4c16e7f 100644
> > --- a/drivers/mmc/dw_mmc.c
> > +++ b/drivers/mmc/dw_mmc.c
> > @@ -260,7 +262,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
> > freq)
> > do {
> > status = dwmci_readl(host, DWMCI_CMD);
> > if (timeout-- < 0) {
> > - printf("TIMEOUT error!!\n");
> > + printf("dwmci_setup_bus: timeout!\n");
> > return -ETIMEDOUT;
> > }
> > } while (status & DWMCI_CMD_START);
> > @@ -275,7 +277,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
> > freq)
> > do {
> > status = dwmci_readl(host, DWMCI_CMD);
> > if (timeout-- < 0) {
> > - printf("TIMEOUT error!!\n");
> > + printf("dwmci_setup_bus: timeout!\n");
> According to your the main purpose, this patch is goal that noticed
> where/what error is occurred.
> Then i think good that add the "__LINE__".
> Because there are same message like "dwmci_setup_bus: tiemout!\n" at some
> place.
>
> Then i think we don't need to discuss about this patch with Marek. :)
>
This patch looks good except need to distinguish the error location as
pointed by Jaehoon.
Thanks
Chin Liang
> Best Regards,
> Jaehoon Chung
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/6] nand: denali: add Denali NAND driver for SPL
Hi Masahiro,
On Fri, 2014-09-05 at 14:50 +0900, Masahiro Yamada wrote:
> The SPL-mode driver for Denali(Cadence) NAND Flash Memory Controller IP.
>
> This driver requires two CONFIG macros:
> - CONFIG_SPL_NAND_DENALI
> Define to enable this driver.
> - CONFIG_SYS_NAND_BAD_BLOCK_POS
> Specify bad block mark position in the oob space. Typically 0.
>
> Signed-off-by: Masahiro Yamada
> Cc: Chin Liang See
> Cc: Scott Wood
> ---
>
> Changes in v4:
> - Add a workaround to not depend on the Denali driver
> posted by Chin Liang See.
> This driver has been taking too long:
> http://patchwork.ozlabs.org/patch/381305/
>
Yup, hopefully v10 would be the final patch.
> Changes in v3: None
> Changes in v2:
> - Avoid unaligned access
> - Replace a magic number 0x2000 with PIPELINE_ACCESS
>
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/denali_spl.c | 245
> ++
> 2 files changed, 246 insertions(+)
> create mode 100644 drivers/mtd/nand/denali_spl.c
>
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index bf1312a..f90f9a0 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -12,6 +12,7 @@ NORMAL_DRIVERS=y
> endif
>
> obj-$(CONFIG_SPL_NAND_AM33XX_BCH) += am335x_spl_bch.o
> +obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
> obj-$(CONFIG_SPL_NAND_DOCG4) += docg4_spl.o
> obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
> obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
> diff --git a/drivers/mtd/nand/denali_spl.c b/drivers/mtd/nand/denali_spl.c
> new file mode 100644
> index 000..ab23743
> --- /dev/null
> +++ b/drivers/mtd/nand/denali_spl.c
> @@ -0,0 +1,245 @@
> +/*
> + * Copyright (C) 2014 Panasonic Corporation
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#if 0
> +#include "denali.h"
> +#else
> +/* workaround until denali.h is merged */
> +#define TRANSFER_SPARE_REG 0x10
> +#define ECC_ENABLE 0xe0
> +#define PAGES_PER_BLOCK 0x150
> +#define DEVICE_MAIN_AREA_SIZE0x170
> +#define DEVICE_SPARE_AREA_SIZE 0x180
> +
> +#define INTR_STATUS(__bank) (0x410 + ((__bank) * 0x50))
> +#define INTR_STATUS__ECC_UNCOR_ERR 0x0001
> +#define INTR_STATUS__LOAD_COMP 0x0040
> +
> +#define INDEX_CTRL_REG0x0
> +#define INDEX_DATA_REG0x10
> +#define MODE_010x0400
> +#define MODE_100x0800
> +#endif
> +
> +#define SPARE_ACCESS 0x41
> +#define MAIN_ACCESS 0x42
> +#define PIPELINE_ACCESS 0x2000
> +
> +#define BANK(x) ((x) << 24)
> +
> +static void __iomem *denali_flash_mem =
> + (void __iomem *)CONFIG_SYS_NAND_DATA_BASE;
> +static void __iomem *denali_flash_reg =
> + (void __iomem *)CONFIG_SYS_NAND_REGS_BASE;
> +
> +static const int flash_bank;
> +static uint8_t page_buffer[NAND_MAX_PAGESIZE];
> +static int page_size, oob_size, pages_per_block;
> +
> +static void index_addr(uint32_t address, uint32_t data)
> +{
> + writel(address, denali_flash_mem + INDEX_CTRL_REG);
> + writel(data, denali_flash_mem + INDEX_DATA_REG);
> +}
> +
> +static int wait_for_irq(uint32_t irq_mask)
> +{
> + unsigned long timeout = 100;
> + uint32_t intr_status;
> +
> + do {
> + intr_status = readl(denali_flash_reg + INTR_STATUS(flash_bank));
> +
> + if (intr_status & INTR_STATUS__ECC_UNCOR_ERR) {
> + debug("Uncorrected ECC detected\n");
> + return -EIO;
> + }
> +
> + if (intr_status & irq_mask)
> + break;
> +
> + udelay(1);
> + timeout--;
> + } while (timeout);
> +
> + if (!timeout) {
> + debug("Timeout with interrupt status %08x\n", intr_status);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static void read_data_from_flash_mem(uint8_t *buf, int len)
> +{
> + int i;
> + uint32_t *buf32;
> +
> + /* transfer the data from the flash */
> + buf32 = (uint32_t *)buf;
> +
> + /*
> + * Let's take care of unaligned access although it rarely happens.
> + * Avoid put_unaligned() for the normal use cases since it leads to
> + * a bit performance regression.
> + */
> + if ((unsigned long)buf32 % 4) {
> + for (i = 0; i < len / 4; i++)
> + put_unaligned(readl(denali_flash_mem + INDEX_DATA_REG),
> + buf32++);
> + } else {
> + for (i = 0; i < len / 4; i++)
> + *buf32++ = readl(denali_flash_mem + INDEX_DATA_REG);
> + }
> +
> + if (len % 4) {
> + u32 tmp;
> +
> + tmp = cpu_to_le32(readl(denali_flash_mem + INDEX_DATA_REG));
> + buf =
