Re: [U-Boot] SPL framework re-design
On Tuesday 28 June 2011 09:48 PM, Scott Wood wrote: On Tue, 28 Jun 2011 12:24:11 +0530 Aneesh Vane...@ti.com wrote: 1. If there are SPL customized generic files like the nand_spl/nand_boot.c where do we keep them? I suggest that we keep them in spl/nand, spl/onenand etc. And for the object file hierarchy let's have something like spl/obj. How about that? How about drivers/nand/generic_spl.c, drivers/nand/fsl_elbc_spl.c, etc.? Wolfgang, How about this suggestion from Scott? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Tuesday 28 June 2011 02:52 AM, Wolfgang Denk wrote: Dear Scott Wood, In message20110627161803.16783...@schlenkerla.am.freescale.net you wrote: But if we do not create a new hierarchy of target directories we will have the normal and the spl objects in parallel (and I don't want to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. The question came up what we need it for. Just seems cleaner to me than jamming it into the file extension. If we're treating it as a separate build, it should go into a separate place. It's not really a different type of file. I'm fine with that as well. I too think this approach is cleaner. This is essentially Daniel's approach. So, we can use some of his code. There are couple of open points though: 1. If there are SPL customized generic files like the nand_spl/nand_boot.c where do we keep them? I suggest that we keep them in spl/nand, spl/onenand etc. And for the object file hierarchy let's have something like spl/obj. How about that? 3. I hope partially linked libraries is fine. Or do you want to link all object files in a single stage? Is there any advantage in doing that? Shall I re-work my series using this framework? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Tue, 28 Jun 2011 12:24:11 +0530 Aneesh V ane...@ti.com wrote: 1. If there are SPL customized generic files like the nand_spl/nand_boot.c where do we keep them? I suggest that we keep them in spl/nand, spl/onenand etc. And for the object file hierarchy let's have something like spl/obj. How about that? How about drivers/nand/generic_spl.c, drivers/nand/fsl_elbc_spl.c, etc.? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi Aneesh, On 27.06.2011 08:29, Aneesh V wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work). Yes, surely I understand that currently U-Boot is not configurable enough to meet hard SPL constraints. But why don't we add the required configuration options instead of implementing the SPL thing separately? Again, maybe I'm missing something but it looks like not very difficult task to add the required configuration options and this approach seems to be more straight to me... Aneesh, what's the state of your patches? I'm especially interrested in OMAP3 (AM3517) support. Maybe I will be able to help you. I should be able to send out an updated revision of my series once we finalize on the new framework for SPL. BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. That can be integrated with my work and we will get an SPL that supports both MMC and NAND. I guess Simon Schwarz is also doing some work lately on OMAP3. Thanks for the pointers, I will take a look. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi, You mentioned that /spl can not be used for source files. Isn't there a way to workaround this problem? Why should we have source files in a SPL directory? I would prefer to have spl specific sources right where the rest ist - maybe marked with something like _spl or excluded by some #define-test. If we have a SPL specific directory we have to copy most of the tree (arch/cpu etc.) which in my eyes is totally unnecessary if we don't do the symlinking stuff... Also, I agree with Scott's opinion that re-compiling some files while re-using the binary of some other files won't be a good idea. In this case, CONFIG_PRELOADER will be honored in some files but not in other files. That will be a source of confusion for developers. I also see this as the biggest problem with reusing the object-files. It will add more complexity than a simple re-run with different flags like suggested by Daniel. BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. That can be integrated with my work and we will get an SPL that supports both MMC and NAND. I guess Simon Schwarz is also doing some work lately on OMAP3. I am working on OMAP3 (on devkit8000). If this discussion comes to a conclusion soon I would prefer sending the patches with the new SPL format. Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi Ilya, On Monday 27 June 2011 01:54 PM, Ilya Yanok wrote: Hi Aneesh, On 27.06.2011 08:29, Aneesh V wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work). Yes, surely I understand that currently U-Boot is not configurable enough to meet hard SPL constraints. But why don't we add the required configuration options instead of implementing the SPL thing separately? Again, maybe I'm missing something but it looks like not very difficult task to add the required configuration options and this approach seems to be more straight to me... I agree. SPL, as I understand, was an easy workaround for this problem. But if we are spending a lot of time on SPL framework, we may rather solve the real problem(Oh no, I am not volunteering:-)) Honestly, I have no idea how much effort that will be. Actually, I had raised this point sometime back. But that was more in favor of keeping SPL the way it is now and not adding anymore complexity. http://news.gmane.org/find-root.php?group=gmane.comp.boot-loaders.u-bootarticle=100550 best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh, In message 4e0804dc.8090...@ti.com you wrote: +spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend + $(MAKE) -C spl/ all + $(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl The mmc_spl/ is suppoed to be moved into spl/, isn't it? This patch was intended only as a prototype for the new directory structure. I didn't bother to touch the existing stuff. I see. --- /dev/null +++ b/spl/Makefile @@ -0,0 +1,94 @@ +# +# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com. Really??? I copied Daniel's Makefile and started from there. I guess the only real part that was left from the old file is the GPL header... As Mike mentioned, we can eventually directly include the OBJSs here and omit the building of libraries? I can't seem to find a mail from Mike on this thread. Did I miss any mail? I can find it either. I don't know what I had in mind then. Do you mean re-using equivalent libraries from the normal U-Boot without re-compiling them? There are actually two different topics here: - The first is how to link all the objects in the spl/ tree together. As I understand, you proposal was to link all objects in each of the subdirectories into a library, and then link all the libraries together. Instead of doing this, we could as well just maintain a list of objects and then link all these together directly, without creating libraries first. - The other topic is if to build new object files, and where. At the moment we have two situations: * Some files are built with special options such that unneeded code gets commented out using respecive #ifdef's / #ifndef's. We can probably get rid of (most of ?) these #ifdef's / #ifndef's when properly using -ffunction-sections / --gc-sections Why should we then recompile the code? * Some files (start.S) really need different code. Here the questions is more how and where to recompile using proper options. I would be glad if we could get rid of the symlinking. Maybe we can add respective build rules to the original Makefiles (see also proposal by Ilya, http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102033 ), eventually just using a different suffix, say .splo instead of .o? allow for vendor directories (where BOARDDIR = $(VENDOR)/$(BOARD)). I didn't want to make the directory structure any longer than required. But I can add this if required. It will be needed. Hm... can we try to do without the symlinks? Well. I think it's difficult. Most of my hardware initialization such as clock init, SDRAM init etc need to know under what context it is getting executed. The context can be: 1. SPL 2. Regular U-Boot executing from NOR flash 3. Regular U-Boot executing from SDRAM etc. Agreed - we need another, independent set of object files. But cannot we create these in the existent source tree? If you want to do away with symlinks, I would propose going with Daniel's approach. This uses /spl as a remote building directory, but do not create any symlinks. Yes, this is an improvement over the current situation - but Ilya's question is a good one: why do we need the pl/ subtree in the first place? 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 shouldn't make my toaster angry. - Household security explained in Johnny Quest ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Ilya, In message loom.20110627t010402-...@post.gmane.org you wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Good point. Eventually we can just add additional build rules for new object files (say, .splo instead of .o) ? 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 Have you lived in this village all your life?No, not yet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh, In message 4e080733.2030...@ti.com you wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work). This statement does not make much sense to me. If we can do it in the spl/ directory, we should be able to do it in any other directory as well. The worst to happen is that we have to keep two setsof object files separated, but chosing a different suffix should be sufficient. BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. Yes, but AFAIR he never followed up to the requested changes. That can be integrated with my work and we will get an SPL that supports both MMC and NAND. I guess Simon Schwarz is also doing some work lately on OMAP3. OK, so we have all the more reason to do this thorougly now. 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 Applying computer technology is simply finding the right wrench to pound in the correct screw. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi, On Mon, Jun 27, 2011 at 11:27 AM, Wolfgang Denk w...@denx.de wrote: Dear Ilya, In message loom.20110627t010402-...@post.gmane.org you wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? I guess that is because the discussion started with several directories (nand_spl, mmc_spl etc.) which should be merged into a single spl directory. Good point. Eventually we can just add additional build rules for new object files (say, .splo instead of .o) ? I agree this approach seems to be the best one. But then we have to create SPL-specific libraries too, right? (e.g. lib$(ARCH).splo, lib$(CPU).splo) Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Monday 27 June 2011 02:57 PM, Wolfgang Denk wrote: Dear Aneesh, In message4e0804dc.8090...@ti.com you wrote: +spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend + $(MAKE) -C spl/ all + $(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl The mmc_spl/ is suppoed to be moved into spl/, isn't it? This patch was intended only as a prototype for the new directory structure. I didn't bother to touch the existing stuff. I see. --- /dev/null +++ b/spl/Makefile @@ -0,0 +1,94 @@ +# +# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com. Really??? I copied Daniel's Makefile and started from there. I guess the only real part that was left from the old file is the GPL header... As Mike mentioned, we can eventually directly include the OBJSs here and omit the building of libraries? I can't seem to find a mail from Mike on this thread. Did I miss any mail? I can find it either. I don't know what I had in mind then. Do you mean re-using equivalent libraries from the normal U-Boot without re-compiling them? There are actually two different topics here: - The first is how to link all the objects in the spl/ tree together. As I understand, you proposal was to link all objects in each of the subdirectories into a library, and then link all the libraries together. Instead of doing this, we could as well just maintain a list of objects and then link all these together directly, without creating libraries first. Is this like a make variable that keeps accumulating objects from sub-directories? If so, is that through a *.mk at each level and including all these *.mk at the top level Makefile. Or is there some other idea? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 11:27:31 +0200 Wolfgang Denk w...@denx.de wrote: Dear Ilya, In message loom.20110627t010402-...@post.gmane.org you wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Good point. Eventually we can just add additional build rules for new object files (say, .splo instead of .o) ? No need for new extensions -- we should be able to use the target directory to influence rule selection. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 11:36:33 +0200 Wolfgang Denk w...@denx.de wrote: Dear Aneesh, In message 4e080733.2030...@ti.com you wrote: I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work). This statement does not make much sense to me. If we can do it in the spl/ directory, we should be able to do it in any other directory as well. The worst to happen is that we have to keep two setsof object files separated, but chosing a different suffix should be sufficient. We do it in the spl/ directory by bypassing the normal makefile config system, specifying a board-and-spl-specific list of objects instead. It could of course be done with the standard config system, but it will require that every bit of code in U-Boot be enabled only with a particular config option -- no always on code. This would be a good thing anyway, but it will take some work to do it cleanly. A first step would probably be a global finegrained/small flag that configs use to opt into the new system, but eventually all bits of functionality should have appropriate individual config symbols. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Daniel, In message BANLkTin-s=wznptu8ej7s_gz9hrrv-p...@mail.gmail.com you wrote: Good point. Eventually we can just add additional build rules for new object files (say, .splo instead of .o) ? I agree this approach seems to be the best one. But then we have to create SPL-specific libraries too, right? (e.g. lib$(ARCH).splo, lib$(CPU).splo) Not necessarily. We might instead just link the object files we build. 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 This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4e089a25.4050...@ti.com you wrote: Instead of doing this, we could as well just maintain a list of objects and then link all these together directly, without creating libraries first. Is this like a make variable that keeps accumulating objects from sub-directories? If so, is that through a *.mk at each level and including all these *.mk at the top level Makefile. Or is there some other idea? Well, if we do it right and build only such objects we actually need for the target binary, we might not need any explicit rules at all and instead just use file globbing to link all objects we find. 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 I express preference for a chronological sequence of events which precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message 20110627133435.31cd3...@schlenkerla.am.freescale.net you wrote: Good point. Eventually we can just add additional build rules for new object files (say, .splo instead of .o) ? No need for new extensions -- we should be able to use the target directory to influence rule selection. But if we do not create a new hierarchy of target directories we will have the normal and the spl objects in parallel (and I don't want to delete one when building the other). 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 Karl's version of Parkinson's Law: Work expands to exceed the time alloted it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message 20110627134205.021af...@schlenkerla.am.freescale.net you wrote: This statement does not make much sense to me. If we can do it in the spl/ directory, we should be able to do it in any other directory as well. The worst to happen is that we have to keep two setsof object files separated, but chosing a different suffix should be sufficient. We do it in the spl/ directory by bypassing the normal makefile config system, specifying a board-and-spl-specific list of objects instead. We can provide such a board-and-spl-specific list of objects for the spl code in the normal Makefiles as well. It could of course be done with the standard config system, but it will require that every bit of code in U-Boot be enabled only with a particular config option -- no always on code. This would be a good thing anyway, but it will take some work to do it cleanly. A first step would probably be a global finegrained/small flag that configs use to opt into the new system, but eventually all bits of functionality should have appropriate individual config symbols. If we do it right, we will only build such objects in spl configuration that are needed for the spl linking. So we can start with this finer control for spl initially, and then (later) extend it for normal builds as well. 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 The only way to get rid of a temptation is to yield to it. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 22:50:46 +0200 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20110627133435.31cd3...@schlenkerla.am.freescale.net you wrote: Good point. Eventually we can just add additional build rules for new object files (say, .splo instead of .o) ? No need for new extensions -- we should be able to use the target directory to influence rule selection. But if we do not create a new hierarchy of target directories we will have the normal and the spl objects in parallel (and I don't want to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message 20110627155535.4217b...@schlenkerla.am.freescale.net you wrote: But if we do not create a new hierarchy of target directories we will have the normal and the spl objects in parallel (and I don't want to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. The question came up what we need it for. 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 I haven't lost my mind - it's backed up on tape somewhere. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Mon, 27 Jun 2011 23:10:33 +0200 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20110627155535.4217b...@schlenkerla.am.freescale.net you wrote: But if we do not create a new hierarchy of target directories we will have the normal and the spl objects in parallel (and I don't want to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. The question came up what we need it for. Just seems cleaner to me than jamming it into the file extension. If we're treating it as a separate build, it should go into a separate place. It's not really a different type of file. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message 20110627161803.16783...@schlenkerla.am.freescale.net you wrote: But if we do not create a new hierarchy of target directories we will have the normal and the spl objects in parallel (and I don't want to delete one when building the other). What's wrong with creating a new hierarchy of target directories? It would be like specifying a different output directory. The question came up what we need it for. Just seems cleaner to me than jamming it into the file extension. If we're treating it as a separate build, it should go into a separate place. It's not really a different type of file. I'm fine with that as well. 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 A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi All, Just thought I'd throw in a left-field idea... Could we make the loading of U-Boot into a generic multi-stage framework with each stage bootstrapping the next stage? OK, I know this is how IPL, SPL etc work already, but I'm thinking something more formal and arch independent. I can think of three disctinct phases which are relatively commong across most arch's (especially NAND Flash arches) 1) An intial page (say 256 bytes for example) which loads a second stage into the CPU's cache 2) A second phase running in the CPU cache which initialises SDRAM and loads the remainder into main memory (performs relocations etc) 3) A final phase which is U-Boot proper, running at the final target address in SDRAM Now what I'm thinking is that if we formalise these loader stages, we could actually add a little more flexibility by, say, allowing the final U-Boot binary to reside on a file-system. And even break the final binary up into smaller 'run-once-and-discard' chunks. For example, a lot of the low level init is only ever done once, but it stays in SDRAM as a permanent piece of the U-Boot image - What if the second stage loader could instead load an low-level init blob and run it before loading the final U-Boot blob? This then opens the door for all sort of options - What if U-Boot commands were build into stand-alone binary blobs and only loaded when needed. Same with device drivers So a lot of what is now build-time configuration could be reduced to run-time configuration Just a few wild ideas... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Graeme Russ, In message banlktinapvrprepfnsoypjertu6hzga...@mail.gmail.com you wrote: I can think of three disctinct phases which are relatively commong across most arch's (especially NAND Flash arches) 1) An intial page (say 256 bytes for example) which loads a second stage into the CPU's cache 2) A second phase running in the CPU cache which initialises SDRAM and loads the remainder into main memory (performs relocations etc) 3) A final phase which is U-Boot proper, running at the final target address in SDRAM The thing is that we have many different architectures, and NAND booting systems are just one configuration out of many. Depending on your architecture, the initialization of the RAM may be semi-automatic (with just very few parameters needed), or data-driven (you have to provide some magic data blob that gets interpreted by some ROM code), or completely manual (where you have to pay close attentian to insert the correct N microseconds delay here and there in your code, as required by the RAM data sheet). If you look back at the trouble reports from people who ported U-Boot (and Linux) to their platforms you can see that RAM initialization problems have always been a major problem area. This experience, collected over many years, has led to the design we have now: http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#6_Keep_it_Debuggable Having debug output on the console as soon as possible is a pretty important design goal; if technically possible, we do want to have debug output long before initializing the RAM. Unfortunately, this pulls in a lot of dependencies: bigger parts of the code like printf() and friends, access to the environment (to read the baudrate settings, etc.) Now what I'm thinking is that if we formalise these loader stages, we could actually add a little more flexibility by, say, allowing the final U-Boot binary to reside on a file-system. And even break the final binary up into smaller 'run-once-and-discard' chunks. For example, a lot of the low level init is only ever done once, but it stays in SDRAM as a permanent piece of the U-Boot image - What if the second stage loader could instead load an low-level init blob and run it before loading the final U-Boot blob? You would most probably lose the capability to have early debug messages. This then opens the door for all sort of options - What if U-Boot commands were build into stand-alone binary blobs and only loaded when needed. Same with device drivers Device drivers clearly need a rework. But I'm not sure if dynamic loading is as easy as you imagine it - we have a large number of architectures here, and you need some support (drivers, file system [or other structured storage space]) to koads objects from external storage. So a lot of what is now build-time configuration could be reduced to run-time configuration It sounds like a nice idea, but I fear there are a lots of devils in the details. 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 A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hello everybody, I've read the whole thread and I really like what Daniel suggests but I just want to speak it in a little bit different words. I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? Aneesh, what's the state of your patches? I'm especially interrested in OMAP3 (AM3517) support. Maybe I will be able to help you. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang,
On Saturday 25 June 2011 05:40 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4e00799a.5040...@ti.com you wrote:
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
Here is an updated version of my prototype implementation with fixes
for some issues pointed out by Scott. Please let me know your views
about this.
---
Makefile|5 ++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 94
+++
spl/mmc/Makefile| 55 +++
4 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index 8540e39..0321634 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +316,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
This patch seems strangely white-space corrupted.
Maybe, because I copy-pasted in Thunderbird instead of git-send-mail.
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -428,6 +429,9 @@ $(obj)u-boot-onenand.bin:onenand_ipl
$(obj)u-boot.bin
mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl:$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+$(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
The mmc_spl/ is suppoed to be moved into spl/, isn't it?
This patch was intended only as a prototype for the new directory
structure. I didn't bother to touch the existing stuff.
$(VERSION_FILE):
@@ -1142,6 +1146,7 @@ clean:
@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
Dito here for onenand_ipl/ ?
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
...also line-wrapped.
+@rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
Make this:
@rm -f $(obj)spl/u-boot{.lds,-spl,-spl.map,-spl.bin,-mmc-spl.bin}
instead.
ok.
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
Goes away?
I am yet to think about the migration of existing code. If it's mere
movement of code I should be able to do it for all. But if it is about
re-factoring the code of other SoCs, I will not be able to do it. Hope
respective maintainers will take care of that.
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,94 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
Really???
I copied Daniel's Makefile and started from there.
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o
As Mike mentioned, we can eventually directly include the OBJSs here
and omit the building of libraries?
I can't seem to find a mail from Mike on this thread. Did I miss any
mail?
Do you mean re-using equivalent libraries from the normal U-Boot
without re-compiling them?
+LIBS-y += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+$(ARCH)/lib$(ARCH).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+$(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+$(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ];
then echo \
+$(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
We should probably use /$(BOARDDIR)? here instead of /$(BOARD)/ to
allow for vendor directories (where BOARDDIR = $(VENDOR)/$(BOARD)).
I didn't want to make the directory structure any longer than required.
But I can add this if required.
+ALL = $(obj)u-boot-spl.bin
+
+all:$(ALL)
Do we need ALL then at all?
ok. I will remove it.
...
diff --git a/spl/mmc/Makefile b/spl/mmc/Makefile
new file mode 100644
index 000..b4f7efd
--- /dev/null
+++ b/spl/mmc/Makefile
@@ -0,0 +1,55 @@
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
Really???
Again I copied the Makefile from arch/arm/cpu/armv7/Makefile as a
template.
+$(obj)mmc.c:
+@rm -f $@
+@ln -s $(TOPDIR)/drivers/mmc/mmc.c $@
+
+$(obj)omap_hsmmc.c:
+@rm -f $@
+@ln -s $(TOPDIR)/drivers/mmc/omap_hsmmc.c $@
Hm... can we try to do without the symlinks?
Re: [U-Boot] SPL framework re-design
Hi Ilya, On Monday 27 June 2011 04:47 AM, Ilya Yanok wrote: Hello everybody, I've read the whole thread and I really like what Daniel suggests but I just want to speak it in a little bit different words. I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work). Aneesh, what's the state of your patches? I'm especially interrested in OMAP3 (AM3517) support. Maybe I will be able to help you. I should be able to send out an updated revision of my series once we finalize on the new framework for SPL. BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. That can be integrated with my work and we will get an SPL that supports both MMC and NAND. I guess Simon Schwarz is also doing some work lately on OMAP3. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Tuesday 21 June 2011 04:29 PM, Aneesh V wrote: Dear Wolfgang, On Friday 17 June 2011 10:18 PM, Aneesh V wrote: Dear Wolfgang, Here is a crude implementation of the top-down approach you had been suggesting (or my interpretation of it). This is not complete yet and serves only as a material for further discussions on this topic. Here is an updated version of my prototype implementation with fixes for some issues pointed out by Scott. Please let me know your views about this. I guess you are busy with the release. When will you get a chance to look at this so that I can continue with the work once we are aligned on the design. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V,
In message 4e00799a.5040...@ti.com you wrote:
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
Here is an updated version of my prototype implementation with fixes
for some issues pointed out by Scott. Please let me know your views
about this.
---
Makefile|5 ++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 94
+++
spl/mmc/Makefile| 55 +++
4 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index 8540e39..0321634 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +316,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
This patch seems strangely white-space corrupted.
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -428,6 +429,9 @@ $(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
mmc_spl:$(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
The mmc_spl/ is suppoed to be moved into spl/, isn't it?
$(VERSION_FILE):
@@ -1142,6 +1146,7 @@ clean:
@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
Dito here for onenand_ipl/ ?
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
...also line-wrapped.
+ @rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
Make this:
@rm -f $(obj)spl/u-boot{.lds,-spl,-spl.map,-spl.bin,-mmc-spl.bin}
instead.
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
Goes away?
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,94 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
Really???
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o
As Mike mentioned, we can eventually directly include the OBJSs here
and omit the building of libraries?
+LIBS-y += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+ $(ARCH)/lib$(ARCH).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ];
then echo \
+ $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
We should probably use /$(BOARDDIR)? here instead of /$(BOARD)/ to
allow for vendor directories (where BOARDDIR = $(VENDOR)/$(BOARD)).
+ALL = $(obj)u-boot-spl.bin
+
+all: $(ALL)
Do we need ALL then at all?
...
diff --git a/spl/mmc/Makefile b/spl/mmc/Makefile
new file mode 100644
index 000..b4f7efd
--- /dev/null
+++ b/spl/mmc/Makefile
@@ -0,0 +1,55 @@
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
Really???
+$(obj)mmc.c:
+ @rm -f $@
+ @ln -s $(TOPDIR)/drivers/mmc/mmc.c $@
+
+$(obj)omap_hsmmc.c:
+ @rm -f $@
+ @ln -s $(TOPDIR)/drivers/mmc/omap_hsmmc.c $@
Hm... can we try to do without the symlinks?
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
The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts.
- Bertrand Russell
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang,
On 06/25/2011 02:10 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4e00799a.5040...@ti.com you wrote:
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
Here is an updated version of my prototype implementation with fixes
for some issues pointed out by Scott. Please let me know your views
about this.
---
Makefile|5 ++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 94
+++
spl/mmc/Makefile| 55 +++
4 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index 8540e39..0321634 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +316,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
This patch seems strangely white-space corrupted.
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -428,6 +429,9 @@ $(obj)u-boot-onenand.bin:onenand_ipl
$(obj)u-boot.bin
mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl:$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+$(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
The mmc_spl/ is suppoed to be moved into spl/, isn't it?
$(VERSION_FILE):
@@ -1142,6 +1146,7 @@ clean:
@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
Dito here for onenand_ipl/ ?
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
...also line-wrapped.
+@rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
Make this:
@rm -f $(obj)spl/u-boot{.lds,-spl,-spl.map,-spl.bin,-mmc-spl.bin}
instead.
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
Goes away?
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,94 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
Really???
That is only because Aneesh used my experimental Makefile that I
published for discussion and to show one possible solution for
the top-down design.
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o
As Mike mentioned, we can eventually directly include the OBJSs here
and omit the building of libraries?
What about files which need to recompiled with a different configuration?
For example I have a use case (MIPS based) that reuses parts of the CPU
and board lowlevel init code. This SPL runs in a SoC internal SRAM,
initializes the memory controller, needs no relocation, have a different
stack offset and copies the real U-Boot from SPI flash to RAM.
At least I have to recompile start.S without relocate_code() and
a different stack pointer initialization.
+LIBS-y += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+$(ARCH)/lib$(ARCH).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+$(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+$(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ];
then echo \
+$(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
We should probably use /$(BOARDDIR)? here instead of /$(BOARD)/ to
allow for vendor directories (where BOARDDIR = $(VENDOR)/$(BOARD)).
+ALL = $(obj)u-boot-spl.bin
+
+all:$(ALL)
Do we need ALL then at all?
actually not. The original spl/Makefile is only a strongly simplified
version of the top-level Makefile.
...
diff --git a/spl/mmc/Makefile b/spl/mmc/Makefile
new file mode 100644
index 000..b4f7efd
--- /dev/null
+++ b/spl/mmc/Makefile
@@ -0,0 +1,55 @@
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
Really???
+$(obj)mmc.c:
+@rm -f $@
+@ln -s $(TOPDIR)/drivers/mmc/mmc.c $@
+
+$(obj)omap_hsmmc.c:
+@rm -f $@
+@ln -s $(TOPDIR)/drivers/mmc/omap_hsmmc.c $@
Hm... can we try to do without the symlinks?
that is possible with if you play a little with the src and obj
variables in config.mk
Best regards,
Daniel
___
U-Boot mailing list
Re: [U-Boot] SPL framework re-design
Dear Wolfgang,
On Friday 17 June 2011 10:18 PM, Aneesh V wrote:
Dear Wolfgang,
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
Here is an updated version of my prototype implementation with fixes
for some issues pointed out by Scott. Please let me know your views
about this.
---
Makefile|5 ++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 94
+++
spl/mmc/Makefile| 55 +++
4 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index 8540e39..0321634 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +316,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -428,6 +429,9 @@ $(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
$(VERSION_FILE):
@@ -1142,6 +1146,7 @@ clean:
@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
+ @rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
diff --git a/include/configs/omap4_sdp4430.h
b/include/configs/omap4_sdp4430.h
index c424951..c9adc3c 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -257,4 +257,5 @@
/* 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM */
#define CONFIG_SYS_TEXT_BASE 0x8010
+#define CONFIG_SYS_SPL_MMC_SUPPORT
#endif /* __CONFIG_H */
diff --git a/spl/Makefile b/spl/Makefile
new file mode 100644
index 000..9e3a5b1
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,94 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
+#
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o
+
+LIBS-y += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+ $(ARCH)/lib$(ARCH).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ];
then echo \
+ $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
+
+LIBS-y := $(addprefix $(obj),$(sort $(LIBS-y)))
+
+__LIBS := $(subst $(obj),,$(LIBS-y))
+
+ifndef SPL_LDSCRIPT
+ ifdef CONFIG_SYS_SPL_LDSCRIPT
+ # need to strip off double quotes
+ SPL_LDSCRIPT := $(subst ,,$(CONFIG_SYS_SPL_LDSCRIPT))
+ endif
+endif
+
+ifndef SPL_LDSCRIPT
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT :=
$(TOPDIR)/spl/$(ARCH)/$(CPU)/$(SOC)/$(BOARDDIR)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT :=
$(TOPDIR)/spl/$(ARCH)/$(CPU)/$(SOC)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT := $(TOPDIR)/spl/$(ARCH)/$(CPU)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+$(error could not find linker script)
+ endif
+endif
+LNDIR := $(OBJTREE)/spl
+
+# Special flags for CPP when processing the linker script.
+# Pass the version down so we can handle backwards compatibility
+# on the fly.
+LDPPFLAGS += \
+ -include $(TOPDIR)/include/u-boot/u-boot.lds.h \
+ $(shell $(LD) --version | \
+ sed -ne 's/GNU ld version
\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
+
+ALL= $(obj)u-boot-spl.bin
+
+all: $(ALL)
+
+$(obj)u-boot-spl.bin: $(obj)u-boot-spl
+ $(OBJCOPY) $(OBJCFLAGS) -O binary $ $@
+
+GEN_UBOOT = \
+ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS-y) | \
+ sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
+ cd $(LNDIR) $(LD) $(LDFLAGS)
Re: [U-Boot] SPL framework re-design
On Sun, 19 Jun 2011 15:52:29 +0530 V, Aneesh ane...@ti.com wrote: On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood scottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber: clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Still, what would go in those files? It'd have to be something more specific, like: LIBS-$(CONFIG_SYS_SPL_NAND_SIMPLE) += nand/nand_boot.o LIBS-$(CONFIG_SYS_SPL_NAND_FSL_ELBC) += nand/nand_boot_fsl_elbc.o ... Hmm, I guess you'd stick this in a recursive makefile. Seems like overkill. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). Couldn't there be only OBJS? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Monday 20 June 2011 09:49 PM, Scott Wood wrote: On Sun, 19 Jun 2011 15:52:29 +0530 V, Aneeshane...@ti.com wrote: On Sat, Jun 18, 2011 at 3:58 AM, Scott Woodscottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh Vane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber:clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Still, what would go in those files? That's actually one rule per sub-directory in the directory structure. What goes in there can be decided by the respective Makefile in the sub-directory. It can have more fine-grained selection like what you have mentioned below. It'd have to be something more specific, like: LIBS-$(CONFIG_SYS_SPL_NAND_SIMPLE) += nand/nand_boot.o LIBS-$(CONFIG_SYS_SPL_NAND_FSL_ELBC) += nand/nand_boot_fsl_elbc.o ... Hmm, I guess you'd stick this in a recursive makefile. Seems like overkill. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). Couldn't there be only OBJS? It looks to me at the moment that the root directory for SPL, 'spl/', need not have any source files. We will have an spl/common directory for such needs(I forgot to add this in the list of libraries) If this framework looks reasonable I shall go ahead an convert the OMAP4 spl to this framework, so that we can thrash out some more details. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood scottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber: clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Why are these in mmc? What is it you propose would be in these files? +$(LIBS-y): depend + $(MAKE) -C $(dir $(subst $(obj),,$@)) all If no libraries are selected, this will produce a rule with an empty target, which is undefined behavior. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thursday 16 June 2011 10:15 PM, Scott Wood wrote: On Thu, 16 Jun 2011 13:38:00 +0530 Aneesh Vane...@ti.com wrote: New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' * nand_spl/Makefile builds a generic library with the generic source files at this level. What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. A crude form of this is what I had done in my patch-set. OMAP4 SDP and OMAP4 Panda Makefiles were identical because there was no board specific content. So, I moved them into an omap4.mk and rules.mk and included these two files from the board level Makefiles. But Wolfgang apparently didn't like this because I was having board level Makefile despite not having any board specific content. I still believe that extending this to more granular re-usable components such as mmc.mk, nand.mk, console.mk, fat.mk etc may be a less disruptive but effective solution. And no, I don't think we can get rid of building the objects separately, and I don't want a situation where #ifdef NAND_SPL is honored in some files but not others. Agree. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Friday 17 June 2011 03:39 AM, Wolfgang Denk wrote: Dear Scott Wood, In message20110616114556.7d3c2...@schlenkerla.am.freescale.net you wrote: What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? And also 'config.mk's that are SoC specific, CPU specific etc? Otherwise the board specific config.mk will still duplicate SoC and CPU content. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang,
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
This work borrows from the work of Daniel Schwierzeck
staged here:
https://github.com/danielschwierzeck/u-boot-spl/commits/spl
However the approach is quite different from that of Daniel's.
Appreciate everybody's feedback about this approach.
---
Makefile|7 +++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 95
+++
spl/mmc/Makefile| 55 ++
4 files changed, 158 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index dcf5d93..4a2cb58 100644
--- a/Makefile
+++ b/Makefile
@@ -311,6 +311,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -326,6 +327,7 @@ ifeq ($(CONFIG_MMC_U_BOOT),y)
ALL += $(obj)mmc_spl/u-boot-mmc-spl.bin
endif
+
all: $(ALL)
$(obj)u-boot.hex: $(obj)u-boot
@@ -420,6 +422,9 @@ $(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
$(VERSION_FILE):
@@ -1133,6 +1138,7 @@ clean:
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
+ @rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@@ -1158,6 +1164,7 @@ clobber: clean
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type
l -print | xargs rm -f
@[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l
-print | xargs rm -f
+ @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print |
xargs rm -f
ifeq ($(OBJTREE),$(SRCTREE))
mrproper \
diff --git a/include/configs/omap4_sdp4430.h
b/include/configs/omap4_sdp4430.h
index 68ffa87..3122d1c 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -243,4 +243,5 @@
#define CONFIG_SYS_PL310_BASE 0x48242000
#endif
+#define CONFIG_SYS_SPL_MMC_SUPPORT
#endif /* __CONFIG_H */
diff --git a/spl/Makefile b/spl/Makefile
new file mode 100644
index 000..8dc6e88
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,95 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
+#
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+# The following commented for the time-being, but will be enabled in
+# real implementation
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o
+LIBS += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+ $(ARCH)/lib$(ARCH).o; fi)
+LIBS += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ]; then
echo \
+ $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
+
+LIBS-y := $(addprefix $(obj),$(sort $(LIBS-y)))
+
+__LIBS := $(subst $(obj),,$(LIBS-y))
+
+ifndef SPL_LDSCRIPT
+ ifdef CONFIG_SYS_SPL_LDSCRIPT
+ # need to strip off double quotes
+ SPL_LDSCRIPT := $(subst ,,$(CONFIG_SYS_SPL_LDSCRIPT))
+ endif
+endif
+
+ifndef SPL_LDSCRIPT
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT :=
$(TOPDIR)/spl/$(ARCH)/$(CPU)/$(SOC)/$(BOARDDIR)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT :=
$(TOPDIR)/spl/$(ARCH)/$(CPU)/$(SOC)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT := $(TOPDIR)/spl/$(ARCH)/$(CPU)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+$(error could not find linker script)
+ endif
+endif
+LNDIR := $(OBJTREE)/spl
+
+# Special flags for
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Daniel Schwierzeck, In message banlktim9ae2aszklidh53vd+hjpz7gv...@mail.gmail.com you wrote: The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. This is very much wrong. In the general case, you still need relocation (because the final start address of the U-Boot code canonly be determined at runtime), and you definitely need the code in board_init_r(). I guess we are talking about different kinds of SPL. In my understanding a SPL runs inside an internal SRAM, initializes any external RAM and loads U-Boot from any kind of memory or flash device into that RAM at a fixed load address and then jumps to that address. In this case no relocation is needed. Some kind of SoC specific booting mechanism like a NAND-IPL or hard-wired Boot-ROM loads the SPL initially into SRAM and jumps to it. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. No. All SPL related stuff should go into spl/ ok Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Fri, 17 Jun 2011 20:45:19 +0200 Daniel Schwierzeck daniel.schwierz...@googlemail.com wrote: Dear Wolfgang, On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Daniel Schwierzeck, In message banlktim9ae2aszklidh53vd+hjpz7gv...@mail.gmail.com you wrote: The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. This is very much wrong. In the general case, you still need relocation (because the final start address of the U-Boot code canonly be determined at runtime), and you definitely need the code in board_init_r(). I guess we are talking about different kinds of SPL. In my understanding a SPL runs inside an internal SRAM, initializes any external RAM and loads U-Boot from any kind of memory or flash device into that RAM at a fixed load address and then jumps to that address. In this case no relocation is needed. Some kind of SoC specific booting mechanism like a NAND-IPL or hard-wired Boot-ROM loads the SPL initially into SRAM and jumps to it. It starts from an SRAM, but often relocates to RAM before loading the final image. In some cases the SRAM is also used by hardware as the I/O buffer, so we need to vacate it before any further NAND operations. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber:clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Why are these in mmc? What is it you propose would be in these files? +$(LIBS-y): depend + $(MAKE) -C $(dir $(subst $(obj),,$@)) all If no libraries are selected, this will produce a rule with an empty target, which is undefined behavior. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh, In message 4df9b9e0.8020...@ti.com you wrote: To make sure I understand your new proposals, let me consolidate them here. Please correct me if I am wrong. Also, in the end I have some questions about your new proposal. Some of the questions are getting into the details. But I need the details to re-work my patches according to the new proposal. Thanks for going into this! Current Design: * Currently a single board level Makefile determines what gets built into SPL. And as we have learned so far, these board level Makefiles contain a large lot of duplicated code, especially when dealing with several boards based on the same or similar Soc(s). * This Makefile chooses all the files to be built. Makes symbolic links to them in the board level SPL directory and builds and links them to create the SPL image. * This structure is duplicated for different types of SPLs, nand_spl, onenand_ipl, mmc_spl etc. * Directory structure is something like: nand_spl/board/vendor/board/ All correct so far. New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' The longer I think about this the more I feel we should even take this one step further. Looking at what we have so far: mmc_spl/ nand_spl/ onenand_ipl/ we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ This can probably done in an initial step which is more or less plain renaming and without any functional changes. We would then have spl/Makefile ... spl/common/Makefile ... spl/nand/Makefile ... * nand_spl/Makefile builds a generic library with the generic source files at this level. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. ...again with the addition that these may or may not exist - depending if any board specific code is needed or not. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. ...together by spl/Makefile ... Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe, arch needs to be added too. If this seems necessary, we may do this. But I would like to avoid to copying basicly the whole source tree (either as verbatim copies or as symlinks). We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? As far as building is concerned, the files to be built should always (unless truly common) be selected based on CONFIG_ settings in the Makefiles. As far as linking is concerned, we can do the same for most cases (keep in mind that all linker scripts are run through the C preprocessor, so we can do a lot of things). For those cases where even more flexibility is needed, we can use custom linker scripts in the board directories. 4. How do we handle the case where a given SoC doesn't need any board level code for the SPL(This is the case with OMAP4). Is this handled by just not have any board directories? Right. Or, if a board directory exists for other reasons, by just building an empty board library. 5. If so, how does the top-level SPL Makefile handle this? By checking for the existence of board directory before descending into it? How Yes. does it handle the link step
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Thursday 16 June 2011 04:17 PM, Wolfgang Denk wrote: Dear Aneesh, In message4df9b9e0.8020...@ti.com you wrote: To make sure I understand your new proposals, let me consolidate them here. Please correct me if I am wrong. Also, in the end I have some questions about your new proposal. Some of the questions are getting into the details. But I need the details to re-work my patches according to the new proposal. Thanks for going into this! Current Design: * Currently a single board level Makefile determines what gets built into SPL. And as we have learned so far, these board level Makefiles contain a large lot of duplicated code, especially when dealing with several boards based on the same or similar Soc(s). * This Makefile chooses all the files to be built. Makes symbolic links to them in the board level SPL directory and builds and links them to create the SPL image. * This structure is duplicated for different types of SPLs, nand_spl, onenand_ipl, mmc_spl etc. * Directory structure is something like: nand_spl/board/vendor/board/ All correct so far. New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' The longer I think about this the more I feel we should even take this one step further. Looking at what we have so far: mmc_spl/ nand_spl/ onenand_ipl/ we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. This can probably done in an initial step which is more or less plain renaming and without any functional changes. We would then have spl/Makefile ... spl/common/Makefile ... spl/nand/Makefile ... * nand_spl/Makefile builds a generic library with the generic source files at this level. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). What's the distinction between spl/Makefile and spl/common/Makefile? I guess we won't have any source files at spl/ level? * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. ...again with the addition that these may or may not exist - depending if any board specific code is needed or not. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. ...together by spl/Makefile ... Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe,arch needs to be added too. If this seems necessary, we may do this. But I would like to avoid to copying basicly the whole source tree (either as verbatim copies or as symlinks). We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. You mean you will re-use *.o files with normal u-boot? If so, do you want to create symbolic links to them in the SPL directories or use them in-place? Whether you reuse the source code or the object files we still need directories for all the levels for the respective Makefiles, right? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ I meant code that is media specific, such as MMC support, NAND support etc. I think these should still go in spl/mmc, spl/nand etc right? A multi-device SPL will have to use 2 or more such libraries. 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe,
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4df9ee03.8010...@ti.com you wrote: we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. Correct, i. e. please add for example: spl/board/freescale/mx31pdk/ spl/board/freescale/mx31pdk/Makefile ... ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). What's the distinction between spl/Makefile and spl/common/Makefile? I guess we won't have any source files at spl/ level? I think we can implement the logic to decide which directories need to be entered and built into spl/Makefile, so we can keep this out of the top level Makefile. spl/common/Makefile is responsible for building the common code in the spl/common/ directory. Correct, I do not see need for any sources in spl/ We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. You mean you will re-use *.o files with normal u-boot? If so, do you want to create symbolic links to them in the SPL directories or use them in-place? We should use them in-place. Using --gc-sections and -ffunction-sections we have enough granularity to select only what we really need. Whether you reuse the source code or the object files we still need directories for all the levels for the respective Makefiles, right? Can we not use the objects that get normally built, with the existing Makefiles? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. Please let's check where this is needed, and how we can handle this. I'd really like to get rid of this symlinking. I meant code that is media specific, such as MMC support, NAND support etc. I think these should still go in spl/mmc, spl/nand etc right? A multi-device SPL will have to use 2 or more such libraries. Right. So, is the logic like this: If there is a linker script in the board directory use it, else look for a linker script in SoC directory? We should use the same logic as in config.mk, i. e. CONFIG_SYS_LDSCRIPT has hioghest priority, then search in the standard locations. BTW, my question was more about the contents of final image than the memory map. But, I think this can be handled with appropriate use of --gc-sections, -ffunction-sections, and -fdata-sections. The two main entry points board_init_f() and board_init_r() are typically implemented in the SoC layer or board layer of an SPL. This along with the use of above compiler switches will help SoCs/boards to link in only what they need, right? This is my understanding, too. 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 2000 pounds of chinese soup = 1 Won Ton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi all, for my MIPS based boards I tested a approach similar to Wolfgang's one in the last weeks. My goal was to create a SPL image, that is able to boot from a SPI flash. The basic idea is to have a spl directory that is used as remote build directory for all object files needed for the SPL image. It contains only the Makefile and nothing else. This Makefile is a strongly simplified version of the TOPDIR/Makefile, uses TOPDIR/config.mk and creates a u-boot-spl.bin. The SPL build can be enabled by defining CONFIG_UBOOT_SPL in the board config file. If the spl/Makefiles becomes active, an additional variable name CONFIG_UBOOT_SPL_BUILD wiil be exported in the make environment. Additionally -DCONFIG_UBOOT_SPL_BUILD will be added to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse almost of the arch, SoC and board code. The board_init_f function could be implemented in arch/ARCH/lib/board_spl.c to allow arch-specific code. The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. With this approach I can create a SPL image, that reuses all of the minimal needed MIPS CPU code, mySoC code, my board lowlevel_init, my SPI driver and some parts of the generic SPI flash driver. Some further comments below On Thu, Jun 16, 2011 at 12:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Aneesh, [snip] The longer I think about this the more I feel we should even take this one step further. Looking at what we have so far: mmc_spl/ nand_spl/ onenand_ipl/ we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ This can probably done in an initial step which is more or less plain renaming and without any functional changes. We would then have spl/Makefile ... spl/common/Makefile ... spl/nand/Makefile ... * nand_spl/Makefile builds a generic library with the generic source files at this level. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. ...again with the addition that these may or may not exist - depending if any board specific code is needed or not. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. ...together by spl/Makefile ... Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe, arch needs to be added too. If this seems necessary, we may do this. But I would like to avoid to copying basicly the whole source tree (either as verbatim copies or as symlinks). We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. By using something like CONFIG_UBOOT_SPL_BUILD in the make environment and as CFLAG all code can be reused without symlinking or copying. You need only a separate directory for putting the object files in. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? As far as building is concerned, the files to be built should always (unless truly
Re: [U-Boot] SPL framework re-design
Dear all, Am 16.06.2011 14:55, schrieb Daniel Schwierzeck: snip On Thu, Jun 16, 2011 at 12:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Aneesh, snip We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. By using something like CONFIG_UBOOT_SPL_BUILD in the make environment and as CFLAG all code can be reused without symlinking or copying. You need only a separate directory for putting the object files in. +1 for reusing existing stuff but changing it a little bit to be able to work as spl(driver) where this is necessary 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. sounds better to me than having a complete new tree under /spl regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thursday 16 June 2011 05:45 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4df9ee03.8010...@ti.com you wrote: we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. Correct, i. e. please add for example: spl/board/freescale/mx31pdk/ spl/board/freescale/mx31pdk/Makefile ... I thought we were going to have cpu directory SoC directory etc in this directory structure. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). What's the distinction between spl/Makefile and spl/common/Makefile? I guess we won't have any source files at spl/ level? I think we can implement the logic to decide which directories need to be entered and built into spl/Makefile, so we can keep this out of the top level Makefile. spl/common/Makefile is responsible for building the common code in the spl/common/ directory. Correct, I do not see need for any sources in spl/ We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. You mean you will re-use *.o files with normal u-boot? If so, do you want to create symbolic links to them in the SPL directories or use them in-place? We should use them in-place. Using --gc-sections and -ffunction-sections we have enough granularity to select only what we really need. Whether you reuse the source code or the object files we still need directories for all the levels for the respective Makefiles, right? Can we not use the objects that get normally built, with the existing Makefiles? But where do you add the reference to SoC level and CPU level object files? Which library do you make them part of? I thought the board level Makefile was meant only to build the board specific library. For example, let's say we have board 'a' and 'b' of same SoC(soc). Unless we have a SoC directory we may have to do something like this. spl/board/vendor/a/Makefile: OBJS := soc_1.o OBJS += soc_2.o OBJS += a.o spl/board/vendor/b/Makefile: OBJS := soc_1.o OBJS += soc_2.o OBJS += b.o Please note that soc_1.o and soc_2.o are duplicated in the two Makefiles. We are back to square one, right? Or did you have something else in mind? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. Please let's check where this is needed, and how we can handle this. I'd really like to get rid of this symlinking. One case is start.S. We need a simplified start.S for SPL(no relocation, no interrupt handling etc). There are places where CONFIG_PRELOADER is used today. But maybe, these could be avoided it we try. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi Daniel, This looks like an interesting alternative. On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote: Hi all, for my MIPS based boards I tested a approach similar to Wolfgang's one in the last weeks. My goal was to create a SPL image, that is able to boot from a SPI flash. The basic idea is to have a spl directory that is used as remote build directory for all object files needed for the SPL image. It contains only the Makefile and nothing else. This Makefile is a strongly simplified version of the TOPDIR/Makefile, uses TOPDIR/config.mk and creates a u-boot-spl.bin. The SPL build can be enabled by defining CONFIG_UBOOT_SPL in the board config file. In the last few mails Wolfgang was suggesting re-use of object files themselves, not the source files. In this respect his approach may be different from yours. But I think his objective was to avoid the symbolic link business, which this approach achieves. If the spl/Makefiles becomes active, an additional variable name CONFIG_UBOOT_SPL_BUILD wiil be exported in the make environment. Additionally -DCONFIG_UBOOT_SPL_BUILD will be added to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse almost of the arch, SoC and board code. So, you are essentially re-using the make infrastructure of normal U-Boot with a different top-level Makefile and the additional flags, right? With this scheme can you build two different SPLs for a given board, let's say a NAND spl and another MMC spl. I don't know if this is a valid case, but just wondering. I guess you have a unique u-boot- spl.bin much like you have single u-boot.bin, right? Will you be sending your patches to the list? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thu, Jun 16, 2011 at 3:57 PM, Aneesh V ane...@ti.com wrote: Hi Daniel, This looks like an interesting alternative. On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote: Hi all, for my MIPS based boards I tested a approach similar to Wolfgang's one in the last weeks. My goal was to create a SPL image, that is able to boot from a SPI flash. The basic idea is to have a spl directory that is used as remote build directory for all object files needed for the SPL image. It contains only the Makefile and nothing else. This Makefile is a strongly simplified version of the TOPDIR/Makefile, uses TOPDIR/config.mk and creates a u-boot-spl.bin. The SPL build can be enabled by defining CONFIG_UBOOT_SPL in the board config file. In the last few mails Wolfgang was suggesting re-use of object files themselves, not the source files. In this respect his approach may be different from yours. But I think his objective was to avoid the symbolic link business, which this approach achieves. I guess this requires more changes in the build system. But I wanted to keep the diff as minimal as possible. And some files like start.S must be recompiled with different flags. If running from SRAM you need another monitor base address, stack pointer offset and you must disable the relocate_code stuff. To reduce the SPL footprint you have to disable the whole printf and console stuff, so maybe you must recompile some drivers too. If the spl/Makefiles becomes active, an additional variable name CONFIG_UBOOT_SPL_BUILD wiil be exported in the make environment. Additionally -DCONFIG_UBOOT_SPL_BUILD will be added to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse almost of the arch, SoC and board code. So, you are essentially re-using the make infrastructure of normal U-Boot with a different top-level Makefile and the additional flags, right? yes, but mainly the config.mk With this scheme can you build two different SPLs for a given board, let's say a NAND spl and another MMC spl. I don't know if this is a valid case, but just wondering. I guess you have a unique u-boot- spl.bin much like you have single u-boot.bin, right? I have a single u-boot.bin and a single u-boot-spl.bin. To create images for different boot media, I use different board configs. For example BOARDNAME_nor or BOARDNAME_sf to boot from NOR flash or SPI flash. The NOR image currently builds without SPL. But there is a use case to combine a SPL image and a compressed U-Boot image to reduce the overall flash footprint. Will you be sending your patches to the list? I've pushed some sample code to https://github.com/danielschwierzeck/u-boot-spl/commits/spl Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thu, 16 Jun 2011 13:38:00 +0530 Aneesh V ane...@ti.com wrote: New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' * nand_spl/Makefile builds a generic library with the generic source files at this level. What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. And no, I don't think we can get rid of building the objects separately, and I don't want a situation where #ifdef NAND_SPL is honored in some files but not others. We could perhaps get rid of the symlinking and have the SPL makefile build directly from the source into a different object location, though whether we should depends on whether it actually makes things simpler. 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. This is a critical feature for a situation where we need to fit in a tiny space and target a variety of different hardware. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? What about when code depends on #defines that are not present for a given target, because that target isn't going to select that file? What about when alternative files have the same function names? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Daniel Schwierzeck, In message banlktim9ae2aszklidh53vd+hjpz7gv...@mail.gmail.com you wrote: The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. This is very much wrong. In the general case, you still need relocation (because the final start address of the U-Boot code canonly be determined at runtime), and you definitely need the code in board_init_r(). available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. No. All SPL related stuff should go into spl/ 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 There is nothing in this world constant but inconstancy. - Swift ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4dfa0759.2060...@ti.com you wrote: Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. Correct, i. e. please add for example: spl/board/freescale/mx31pdk/ spl/board/freescale/mx31pdk/Makefile ... I thought we were going to have cpu directory SoC directory etc in this directory structure. If needed, yes. This example showed a board directory. Can we not use the objects that get normally built, with the existing Makefiles? But where do you add the reference to SoC level and CPU level object files? Which library do you make them part of? I thought the board level Makefile was meant only to build the board specific library. Sorry, I don;t understand your questions (because I don't understand which problem you see). Yes, the board directories will contain only board specific stuff. For example, let's say we have board 'a' and 'b' of same SoC(soc). Unless we have a SoC directory we may have to do something like this. Why should we not have a SoC dir? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. Please let's check where this is needed, and how we can handle this. I'd really like to get rid of this symlinking. One case is start.S. We need a simplified start.S for SPL(no relocation, no interrupt handling etc). OK. There are places where CONFIG_PRELOADER is used today. But maybe, these could be avoided it we try. We should carefully check these. 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 To live is always desirable. -- Eleen the Capellan, Friday's Child, stardate 3498.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4dfa0be1.4060...@ti.com you wrote: In the last few mails Wolfgang was suggesting re-use of object files themselves, not the source files. In this respect his approach may be different from yours. But I think his objective was to avoid the symbolic link business, which this approach achieves. We may do both. Such files that will compile the same (i. e. where no specific code changes are done depending on CONFIG_PRELOADER or other settings) should re-use the existing object files. Allothers need to be rebuild, obviously. But this is optimization already, which should be done in a second stage. I will not complain when we start with rebuilding all needed objects. 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 Never underestimate the bandwidth of a station wagon full of tapes. -- Dr. Warren Jackson, Director, UTCS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message 20110616114556.7d3c2...@schlenkerla.am.freescale.net you wrote: What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? We could perhaps get rid of the symlinking and have the SPL makefile build directly from the source into a different object location, though whether we should depends on whether it actually makes things simpler. Agreed. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? What about when code depends on #defines that are not present for a given target, because that target isn't going to select that file? What about when alternative files have the same function names? What do you mean? When a target does not select (and thus build) a file, then it does not matter which #defines are in there or not - they don't get build anyway. If files which export the same funcktion names get linked together we have an error somewhere that needs to be fixed - but this is not a new issue, this situation is the same now already. 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 I dislike companies that have a we-are-the-high-priests-of-hardware- so-you'll-like-what-we-give-you attitude. I like commodity markets in which iron-and-silicon hawkers know that they exist to provide fast toys for software types like me to play with...- Eric S. Raymond ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Fri, 17 Jun 2011 00:09:00 +0200 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20110616114556.7d3c2...@schlenkerla.am.freescale.net you wrote: What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. There's some, but really not that much that I can see. A handful of lines for putc/puts. Some similar but not identical board init code within a board family. Extracting duplicated code into files in the common directories, which can be picked up by the targets that want them, can be done without significant changes to the makefile structure. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? That's a little less flexible, but probably OK. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? What about when code depends on #defines that are not present for a given target, because that target isn't going to select that file? What about when alternative files have the same function names? What do you mean? When a target does not select (and thus build) a file, then it does not matter which #defines are in there or not - they don't get build anyway. That's currently how it works, but it appeared that a suggestion was being made to build certain code as a library before getting to what the target wants. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
