Re: [U-Boot] [PATCH v5 12/13] buildman: Introduce an 'and' operator for board selection
Hi York, On 8 August 2014 11:46, York Sun wrote: > On 08/08/2014 04:10 AM, Simon Glass wrote: >> Currently buildman allows a list of boards to build to be specified on the >> command line. The list can include specific board names, architecture, SOC >> and so on. >> >> At present the list of boards is dealt with in an 'OR' fashion, and there >> is no way to specify something like 'arm & freescale', meaning boards with >> ARM architecture but only those made by Freescale. This would exclude the >> PowerPC boards made by Freescale. >> >> Support an '&' operator on the command line to permit this. Ensure that >> arguments can be specified in a single string to permit easy shell quoting. >> >> Suggested-by: York Sun >> Signed-off-by: Simon Glass >> --- >> >> Changes in v5: >> - Add new patch to add an 'and' operator for board selection >> >> Changes in v4: None >> Changes in v3: None >> Changes in v2: None >> >> tools/buildman/README | 9 +++ >> tools/buildman/board.py | 144 ++-- >> tools/buildman/test.py | 48 >> 3 files changed, 184 insertions(+), 17 deletions(-) >> >> diff --git a/tools/buildman/README b/tools/buildman/README >> index aaf0a10..d4e8404 100644 >> --- a/tools/buildman/README >> +++ b/tools/buildman/README >> @@ -108,6 +108,15 @@ behaviour is a superset of exact or substring matching. Examples are: >> * '^tegra[23]0$' All boards with either Tegra20 or Tegra30 SoC >> * 'powerpc' All PowerPC boards >> >> +While the default is to OR the terms together, you can also make use of >> +the '&' operator to limit the selection: >> + >> +* 'freescale & arm sandbox' All Freescale boards with ARM architecture, >> + plus sandbox >> + >> +It is convenient to use the -n option to see whaat will be built based on >> +the subset given. >> + >> Buildman does not store intermediate object files. It optionally copies >> the binary output into a directory when a build is successful. Size >> information is always recorded. It needs a fair bit of disk space to work, > > Simon, > > It is good to see this working. It would be helpful to point out when using & > logic, users should put them in quotes (single or double). > > I can't get the --count=1 work though. See my example > > $ tools/buildman/buildman -c 1 -b working_85xx t104x -n > No section: 'make-flags' > Dry run, so not doing much. But I would do this: > > Building 16 commits for 9 boards (4 threads, 1 job per thread) > Build directory: ../working_upstream_85xx > e76b933e Prepare v2014.10-rc1 > 89c8bc86 fsl/diu: ch7301 encoder split off from t1040qds/diu.c > 57d28806 powerpc/t1042RDB: Add Video - HDMI support > dc9ed535 buildman: Fix a few typos > 04344da3 buildman: Add some notes about moving from MAKEALL > 4aa63fae buildman: Allow building of current source tree > 1e5d6ab5 buildman: Move BuilderThread code to its own file > fc5f1107 buildman: Sort command line options > eacd9496 buildman: Refactor output options > 7793b089 buildman: Add verbose option to display errors as they happen > 1e0d4a12 buildman: Remove unused non-incremental build method code > deaa8cfd buildman: Add an option to specify the buildman config file > 8bacf282 buildman: Add a message indicating there are no errors > e292dd4c buildman: Add a few more toolchain examples to the README > 384e98f1 buildman: Introduce an 'and' operator for board selection > 1eddd296 RFC: Deprecate MAKEALL > > t104x : 9 boards > Total boards to build for each commit: 9 > > I expect only the last commit to build. Am I wrong? I don't see --count in the > README file. Yes it is not implemented. I will add this and send a new series. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] tools: genboardscfg.py, no exception if columns undetectable
Hi Roger, (adding York to cc) 2014-08-07 23:19 GMT+09:00 Roger Meier : > The existing terminalsize detection raised an exception on build > server. Just removes the exception. This also deactivates the > progress indicator. > > Remove a trainling whitespace. > > Signed-off-by: Roger Meier > CC: Masahiro Yamada > CC: Tom Rini Acked-by: Masahiro Yamada Tom, This problem seems fatal. Please apply this patch asap. Thanks! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: remove generated boards.cfg within make mrproper
Hi Roger, > How should we ensure that boards.cfg is up-to-date? > What about removing boards.cfg within "make distclean" and use > "make mrproper" within MAKEALL? Sounds good to me, too. Thanks! Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] T4240 SGMII "Tx buffer not ready"
Hi everybody, We're trying to bring up a 100M/1G ethernet interface on a custom T4240 board over SGMII and running into the following errors: Immediately after board reset: => ping 192.168.1.53 Using FM2@DTSEC6 device FM2@DTSEC6: Tx error FM2@DTSEC6: Rx error ping failed; host 192.168.1.53 is not alive On any subsequent attempts: => ping 192.168.1.53 Using FM2@DTSEC6 device FM2@DTSEC6: Tx buffer not ready. txbd->status = 0x8800 FM2@DTSEC6: Tx buffer not ready. txbd->status = 0x8800 ping failed; host 192.168.1.53 is not alive We're running from u-boot 2014.07-rc3. Our custom board ethernet bring-up code is closely based on the code for the t4rdb. The SGMII interface hardware is coming up out of reset (we're seeing the interface toggling at the expected rate) but it looks like u-boot isn't communicating with it properly. There's very little information to go on in the source code related to this error (drivers/net/fm/eth.c, in fm_eth_send). What can cause this problem? Here are my environment variables related to networking: eth1addr=00:50:C2:72:01:04 eth2addr=00:50:C2:72:01:06 eth3addr=00:50:C2:72:01:08 eth4addr=00:50:C2:72:01:0a eth5addr=00:50:C2:72:01:0c eth6addr=00:50:C2:72:01:0e ethact=FM2@DTSEC6 ethaddr=00:50:C2:72:01:02 ethprime=FM2@DTSEC6 ipaddr=192.168.1.230 netmask=255.255.255.0 gatewayip=192.168.1.11 Thanks for any help you can provide. Let me know if you need more information, Danny Gale daniel.g...@coloradoengineeringinc.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Python subprocess module missing in multiconfig.py
Hello Marek, On 07-08-14 23:52, Marek Vasut wrote: Thanks for CCing me. I sent a patch to OE-core to ship the python modules. This is a problem with the Yocto Qt SDK toolchain in general and you can track the mayhem at [1]. There will likely be ELDK 5.5.3 once this is all settled. btw. you should update to ELDK 5.5.2 in the first place, since the compiler in Yocto 1.5.0 did have trouble with code generation [2], [3]. [1] http://lists.openembedded.org/pipermail/openembedded-core/2014- August/095470.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [3]http://lists.openembedded.org/pipermail/openembedded-core/2014- February/089489.html A bit of topic, beside the toolchain problems, aren't these dependencies of the u-boot recipe? The native sdk will pick them up if any machine needs them (at least in my setup). Why would it do it please? For the RDEPENDS at least adding it to the recipe itself instead of some common image file makes sure it gets deleted if nobody is using it any longer. And hopefully makes sure you can't compile/use something on the host which isn't on the target, since the header files will be missing. RDEPENDS do get included in the sdk in my setup. For DEPENDS it would mean the sdk can build the same targets with the same tools, but I never checked if it does that. What exactly is your setup, please describe it in detail. Doesn't really matter, you need to convince the oe people. Not me, I am just a user of oe user, if the thing does what I want I am happy enough. Besides of that, do we really want so much dependencies for u-boot what used to be sed, awk.. and uh find perhaps? Is all of this needed to just compile u-boot? This is a question for Yamada-san, +CC . But from my point of view, I see we had dependency on python with some tools for a while -- it's only now that the dependency got pulled into the build system. On the other hand, I don't know what are the plans with the Kconfig and it might end up that this dependency will eventually disappear. yup, understood, I will leave it up to them. With kind regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 13/13] RFC: Deprecate MAKEALL
On 08/08/2014 02:30 PM, Tom Rini wrote: > On Fri, Aug 08, 2014 at 02:19:34PM -0700, York Sun wrote: >> On 08/08/2014 02:12 PM, Tom Rini wrote: > [snip] >>> Oh I'm sure, but maybe we can help get everyone a better script. For >>> example, you've said the way your job goes currently is every commit >>> gets a test. But.. that's not what you need exactly it sounds like. It >>> sounds like you need a given gerrit issue, which can have a few commits >>> to it, to be bisectable and compile tested. buildman will handle this >>> part for you, if you let it. >>> >> Tom, >> >> I agree buildman has improvements comparing with MAKEALL. I spent time >> to make Gerrit, Jenkins and MAKEALL work together. It is not easy as >> one would expect. For now, if I can make builmand to build the last >> commit, I can replace MAKEALL with buildman. But that seems not >> working. > > I believe you, I've spent a bunch of time inside of Jenkins myself (and > then with IBM's LSF compute setup) and I'm doing some of the same > hoop-jumping now too. But I'm hoping maybe we can all take this as a > chance to improve the various ad-hoc builder setups many of us have. > Since we use Gerrit for internal review, each commit (proposed patch) triggers a Jenkins event. I can change the script so no build is triggered, but I need to explorer if buildman servers better than MAKEALL in this case. Because Jenkins has no knowledge of the number of patches pushed, I don't think buildman has enough information to find the "top" and start the build. But anyway, it shouldn't stop us from moving to buildman. I just need the basic feature available before removing MAKEALL. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 13/13] RFC: Deprecate MAKEALL
On Fri, Aug 08, 2014 at 02:19:34PM -0700, York Sun wrote: > On 08/08/2014 02:12 PM, Tom Rini wrote: [snip] > > Oh I'm sure, but maybe we can help get everyone a better script. For > > example, you've said the way your job goes currently is every commit > > gets a test. But.. that's not what you need exactly it sounds like. It > > sounds like you need a given gerrit issue, which can have a few commits > > to it, to be bisectable and compile tested. buildman will handle this > > part for you, if you let it. > > > Tom, > > I agree buildman has improvements comparing with MAKEALL. I spent time > to make Gerrit, Jenkins and MAKEALL work together. It is not easy as > one would expect. For now, if I can make builmand to build the last > commit, I can replace MAKEALL with buildman. But that seems not > working. I believe you, I've spent a bunch of time inside of Jenkins myself (and then with IBM's LSF compute setup) and I'm doing some of the same hoop-jumping now too. But I'm hoping maybe we can all take this as a chance to improve the various ad-hoc builder setups many of us have. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 13/13] RFC: Deprecate MAKEALL
On 08/08/2014 02:12 PM, Tom Rini wrote: > On Tue, Aug 05, 2014 at 03:06:55PM -0700, York Sun wrote: >> On 08/05/2014 12:10 PM, Tom Rini wrote: >>> On Tue, Aug 05, 2014 at 12:01:33PM -0700, York Sun wrote: On 08/05/2014 11:59 AM, Simon Glass wrote: > Hi York, > > On 5 August 2014 12:55, York Sun wrote: >> On 08/05/2014 11:52 AM, Simon Glass wrote: > > BTW where does this information get published? > When we use gerrit and Jenkins, the build log is stored in Jenkins log, and emails were sent with the failure log. >>> >>> OK, I don't think I've send such an email. Do I have to do anything to >>> get them to come to me? >>> >> The emails were sent from Jenkins, by my script collecting information >> from .ERR >> files. >> >> Maybe I didn't understand your question. What do you mean "where does >> this >> information get published"? > > I just mean that I don't think I have received an email yet, and don't > know about the service, so am wondering how to get an email. > Simon, Sorry I misled you. The emails are sent by my scripts under Jenkins (A tool, see http://jenkins-ci.org/). It is not within u-boot. >>> >>> Would you be able to post your jobs / scripts somewhere? I've toyed >>> with a personal setup and I know Marek has run one before as well. >>> Thanks! >>> >> Tom, >> >> My script is long and messy. This is the part sending emails. > > Oh I'm sure, but maybe we can help get everyone a better script. For > example, you've said the way your job goes currently is every commit > gets a test. But.. that's not what you need exactly it sounds like. It > sounds like you need a given gerrit issue, which can have a few commits > to it, to be bisectable and compile tested. buildman will handle this > part for you, if you let it. > Tom, I agree buildman has improvements comparing with MAKEALL. I spent time to make Gerrit, Jenkins and MAKEALL work together. It is not easy as one would expect. For now, if I can make builmand to build the last commit, I can replace MAKEALL with buildman. But that seems not working. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 13/13] RFC: Deprecate MAKEALL
On Tue, Aug 05, 2014 at 03:06:55PM -0700, York Sun wrote: > On 08/05/2014 12:10 PM, Tom Rini wrote: > > On Tue, Aug 05, 2014 at 12:01:33PM -0700, York Sun wrote: > >> On 08/05/2014 11:59 AM, Simon Glass wrote: > >>> Hi York, > >>> > >>> On 5 August 2014 12:55, York Sun wrote: > On 08/05/2014 11:52 AM, Simon Glass wrote: > >>> > >>> BTW where does this information get published? > >>> > >> > >> When we use gerrit and Jenkins, the build log is stored in Jenkins > >> log, and > >> emails were sent with the failure log. > > > > OK, I don't think I've send such an email. Do I have to do anything to > > get them to come to me? > > > The emails were sent from Jenkins, by my script collecting information > from .ERR > files. > > Maybe I didn't understand your question. What do you mean "where does > this > information get published"? > >>> > >>> I just mean that I don't think I have received an email yet, and don't > >>> know about the service, so am wondering how to get an email. > >>> > >> > >> Simon, > >> > >> Sorry I misled you. The emails are sent by my scripts under Jenkins (A > >> tool, see http://jenkins-ci.org/). It is not within u-boot. > > > > Would you be able to post your jobs / scripts somewhere? I've toyed > > with a personal setup and I know Marek has run one before as well. > > Thanks! > > > Tom, > > My script is long and messy. This is the part sending emails. Oh I'm sure, but maybe we can help get everyone a better script. For example, you've said the way your job goes currently is every commit gets a test. But.. that's not what you need exactly it sounds like. It sounds like you need a given gerrit issue, which can have a few commits to it, to be bisectable and compile tested. buildman will handle this part for you, if you let it. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot/master
On Thu, Aug 07, 2014 at 04:37:06PM +0200, Marek Vasut wrote: > The following changes since commit fbe79a17fddb7f0b11aa15b9c93e9a4a26165ed8: > > m68k: define __kernel_size_t as unsinged int again (2014-07-22 09:46:50 > -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-usb.git HEAD > > for you to fetch changes up to 401abbf150e55e974829a7cc64584d9e463fc5ea: > > usb: ehci: rmobile: Remove xHCI address (2014-07-28 12:47:31 +0200) > > > Nobuhiro Iwamatsu (2): > usb: ehci: rmobile: Add support R8A7794 > usb: ehci: rmobile: Remove xHCI address > > Stephen Warren (11): > fs: implement size/fatsize/ext4size > dfu: fix some issues with reads/uploads > dfu: add write error handling > dfu: defer parsing of device string to IO backend > dfu: allow backend to specify a maximum buffer size > dfu: add free_entity() to struct dfu_entity > dfu: add SF backend > test: dfu: script enhancements > test: dfu: cleanup before execution > test: dfu: add some more test cases > dfu: fix readback buffer overflow test > > Łukasz Majewski (3): > test:dfu: Add test scripts for testing DFU regression > test:dfu: README file update > thor: defer parsing of device string to IO backend > > common/cmd_dfu.c | 3 +-- > common/cmd_ext4.c| 14 +++ > common/cmd_fat.c | 13 ++ > common/cmd_fs.c | 13 ++ > common/cmd_thordown.c| 6 ++--- > drivers/dfu/Makefile | 1 + > drivers/dfu/dfu.c| 105 > +-- > drivers/dfu/dfu_mmc.c| 80 > ++-- > drivers/dfu/dfu_nand.c | 9 +-- > drivers/dfu/dfu_ram.c| 13 +- > drivers/dfu/dfu_sf.c | 139 > + > drivers/usb/gadget/f_dfu.c | 20 --- > drivers/usb/gadget/f_thor.c | 5 ++-- > drivers/usb/host/ehci-rmobile.c | 7 -- > fs/ext4/ext4fs.c | 5 > fs/fat/fat.c | 5 > fs/fs.c | 43 + > fs/sandbox/sandboxfs.c | 5 > include/configs/koelsch.h| 2 +- > include/configs/lager.h | 2 +- > include/dfu.h| 52 > +++ > include/ext4fs.h | 1 + > include/fat.h| 1 + > include/fs.h | 9 +++ > include/sandboxfs.h | 1 + > test/dfu/README | 37 > test/dfu/dfu_gadget_test.sh | 94 > +++ > test/dfu/dfu_gadget_test_init.sh | 31 > 28 files changed, 626 insertions(+), 90 deletions(-) > create mode 100644 drivers/dfu/dfu_sf.c > create mode 100644 test/dfu/README > create mode 100755 test/dfu/dfu_gadget_test.sh > create mode 100755 test/dfu/dfu_gadget_test_init.sh Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/master
On Thu, Aug 07, 2014 at 11:34:47AM +0900, Nobuhiro Iwamatsu wrote: > Dear Tom Rini. > > Please pull u-boot-sh master branch. > > The following changes since commit e76b933e02e1b38e48754c435e9dba1c0deeb3c6: > > Prepare v2014.10-rc1 (2014-08-06 09:12:58 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 6b4eb03527576616253526bc3134da039b2bbe14: > > serial: sh: Add support External Clock mode (2014-08-07 11:30:58 +0900) > > > Nobuhiro Iwamatsu (2): > serial: sh: Add support DL and CKS register for R8A7794 > serial: sh: Add support External Clock mode > > drivers/serial/serial_sh.c | 8 +++- > drivers/serial/serial_sh.h | 7 --- > 2 files changed, 11 insertions(+), 4 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U boot with imx-usb-loader
Hi Alexandre,
I'm trying to send a u-boot built from denx sources to my board, a SabreLite, with
imx-usb-loader. But when I try, I receive an error, "unknown load address" do
you know how can I fix this?
Here's the content of my mx6_usb_work.conf file:
mx6_qsb
#hid/bulk,[old_header,]max packet size, {ram start, ram size}(repeat
valid ram areas)
hid,1024,0x1000,1G,0x00907000,0x31000
#file:dcd,plug,load nnn,jump [nnn/header/header2]
/u-boot.imx:dcd,load 0x00906fe0,jump header
Don't care too much about the load address on the last line, as far as
I've experimented the imx-usb-loader ignores it and uses the proper
address from the IVT header.
Hope this helps.
Kind regards,
Nikolay
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/13] Add some missing buildman features and deprecate MAKEALL
On Fri, Aug 08, 2014 at 05:10:17AM -0600, Simon Glass wrote: > Buildman has been around for a little over a year and is used by a fair > number of U-Boot developers. However quite a few people still use MAKEALL. Not a blocker for the series, but [toolchain-alias] is a required section today. Otherwise with arm, armv7a and powerpc found and doing a build for only powerpc I see tons of "No section: toolchain-alias" messages. I didn't plan on populating the aliases since I'm only doing arm/powerpc builds in this instance. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 2/2] spl: Lightweight UBI and UBI fastmap support
On Sat, Jul 05, 2014 at 09:48:13AM -, Thomas Gleixner wrote:
> Booting a payload out of NAND FLASH from the SPL is a crux today, as
> it requires hard partioned FLASH. Not a brilliant idea with the
> reliability of todays NAND FLASH chips.
[snip]
> + CONFIG_SPL_UBI
> + Support for a lightweight UBI (fastmap) scanner and
> + loader
... for the related options, please see doc/README.ubispl
> +Usage notes:
> +
> +In the board config file define for example:
> +
> +#define CONFIG_SPL_UBI
> +#define CONFIG_SPL_UBI_MAX_VOL_LEBS 256
> +#define CONFIG_SPL_UBI_MAX_PEB_SIZE (256*1024)
> +#define CONFIG_SPL_UBI_MAX_PEBS 4096
> +#define CONFIG_SPL_UBI_VOL_IDS 8
> +
> +The size requirement is roughly as follows:
> +
> +2k for the basic data structure
> + + CONFIG_SPL_UBI_VOL_IDS * CONFIG_SPL_UBI_MAX_VOL_LEBS * 8
> + + CONFIG_SPL_UBI_MAX_PEBS * 64
> + + CONFIG_SPL_UBI_MAX_PEB_SIZE * UBI_FM_MAX_BLOCKS
> +
> +The last one is big, but I really don't care in that stage. Real world
> +implementations only use the first couple of blocks, but the code
> +handles up to UBI_FM_MAX_BLOCKS.
> +
> +Given the above configuration example the requirement is about 5M
> +which is usually not a problem to reserve in the RAM along with the
> +other areas like the kernel/dts load address.
> +
> +So something like this will do the trick:
> +
> +#define SPL_FINFO_ADDR 0x8080
> +#define SPL_DTB_LOAD_ADDR0x8180
> +#define SPL_KERNEL_LOAD_ADDR 0x8200
> +
> +In the board file, implement the following:
> +
> +static struct ubispl_load myvolumes[] = {
> + {
> + .name = "Kernel",
> + .vol_id = 0,
> + .load_addr = (void *)SPL_KERNEL_LOAD_ADDR,
> + },
> + {
> + .name = "DTB",
> + .vol_id = 1,
> + .load_addr = (void *)SPL_DTB_LOAD_ADDR,
> + }
> +};
> +
> +int spl_start_uboot(void)
> +{
> + struct ubispl_info info;
> +
> + info.ubi = (struct ubi_scan_info *) SPL_FINFO_ADDR;
OK, so here's some problems with the example. First, we can / should
(and OK, after you posted the patch this went in) moved stack into DDR
in some cases, so in the case of wanting to use this, DDR would have to
be up in time for that to be a valid option, so we shoudl just do that.
Second, we have CONFIG_SYS_SPL_ARGS_ADDR for where the DT would go and
since Falcon supports uImages only (And if/when zImage is added, we'll
have to sort something out generically) we don't need to hard-code in a
load address for the kernel.
> + /*
> + * Bad block, unrecoverable ECC error, skip the block
> + */
> + if (res) {
> + ubi_dbg("Skipping bad or unreadable block %d", pnum);
Here and everywhere else, we have debug() please use that.
> +#ifdef CHECKME
> + /*
> + * If fastmap is leaking PEBs (must not happen), raise a
> + * fat warning and fall back to scanning mode.
> + * We do this here because in ubi_wl_init() it's too late
> + * and we cannot fall back to scanning.
> + */
> + if (WARN_ON(count_fastmap_pebs(ai) != ubi->peb_count -
> + ai->bad_peb_count - fm->used_blocks))
> + goto fail_bad;
> +#endif
Use DEBUG here?
> +#ifdef LATER
> + int image_seq;
> + ret = ubi_io_read_ec_hdr(ubi, pnum, ech, 0);
> + if (ret && ret != UBI_IO_BITFLIPS) {
> + ubi_err("unable to read fastmap block# %i EC (PEB: %i)",
> + i, pnum);
> + if (ret > 0)
> + ret = UBI_BAD_FASTMAP;
> + goto free_hdr;
> + } else if (ret == UBI_IO_BITFLIPS)
> + fm->to_be_tortured[i] = 1;
> +
> + image_seq = be32_to_cpu(ech->image_seq);
> + if (!ubi->image_seq)
> + ubi->image_seq = image_seq;
> + /*
> + * Older UBI implementations have image_seq set to zero, so
> + * we shouldn't fail if image_seq == 0.
> + */
> + if (image_seq && (image_seq != ubi->image_seq)) {
> + ubi_err("wrong image seq:%d instead of %d",
> + be32_to_cpu(ech->image_seq), ubi->image_seq);
> + ret = UBI_BAD_FASTMAP;
> + goto free_hdr;
> + }
> +#endif
What is LATER in this context? Missing functionality? Or debug code?
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 12/13] buildman: Introduce an 'and' operator for board selection
On 08/08/2014 04:10 AM, Simon Glass wrote: > Currently buildman allows a list of boards to build to be specified on the > command line. The list can include specific board names, architecture, SOC > and so on. > > At present the list of boards is dealt with in an 'OR' fashion, and there > is no way to specify something like 'arm & freescale', meaning boards with > ARM architecture but only those made by Freescale. This would exclude the > PowerPC boards made by Freescale. > > Support an '&' operator on the command line to permit this. Ensure that > arguments can be specified in a single string to permit easy shell quoting. > > Suggested-by: York Sun > Signed-off-by: Simon Glass > --- > > Changes in v5: > - Add new patch to add an 'and' operator for board selection > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > tools/buildman/README | 9 +++ > tools/buildman/board.py | 144 > ++-- > tools/buildman/test.py | 48 > 3 files changed, 184 insertions(+), 17 deletions(-) > > diff --git a/tools/buildman/README b/tools/buildman/README > index aaf0a10..d4e8404 100644 > --- a/tools/buildman/README > +++ b/tools/buildman/README > @@ -108,6 +108,15 @@ behaviour is a superset of exact or substring matching. > Examples are: > * '^tegra[23]0$' All boards with either Tegra20 or Tegra30 SoC > * 'powerpc' All PowerPC boards > > +While the default is to OR the terms together, you can also make use of > +the '&' operator to limit the selection: > + > +* 'freescale & arm sandbox' All Freescale boards with ARM architecture, > + plus sandbox > + > +It is convenient to use the -n option to see whaat will be built based on > +the subset given. > + > Buildman does not store intermediate object files. It optionally copies > the binary output into a directory when a build is successful. Size > information is always recorded. It needs a fair bit of disk space to work, Simon, It is good to see this working. It would be helpful to point out when using & logic, users should put them in quotes (single or double). I can't get the --count=1 work though. See my example $ tools/buildman/buildman -c 1 -b working_85xx t104x -n No section: 'make-flags' Dry run, so not doing much. But I would do this: Building 16 commits for 9 boards (4 threads, 1 job per thread) Build directory: ../working_upstream_85xx e76b933e Prepare v2014.10-rc1 89c8bc86 fsl/diu: ch7301 encoder split off from t1040qds/diu.c 57d28806 powerpc/t1042RDB: Add Video - HDMI support dc9ed535 buildman: Fix a few typos 04344da3 buildman: Add some notes about moving from MAKEALL 4aa63fae buildman: Allow building of current source tree 1e5d6ab5 buildman: Move BuilderThread code to its own file fc5f1107 buildman: Sort command line options eacd9496 buildman: Refactor output options 7793b089 buildman: Add verbose option to display errors as they happen 1e0d4a12 buildman: Remove unused non-incremental build method code deaa8cfd buildman: Add an option to specify the buildman config file 8bacf282 buildman: Add a message indicating there are no errors e292dd4c buildman: Add a few more toolchain examples to the README 384e98f1 buildman: Introduce an 'and' operator for board selection 1eddd296 RFC: Deprecate MAKEALL t104x : 9 boards Total boards to build for each commit: 9 I expect only the last commit to build. Am I wrong? I don't see --count in the README file. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] support blackfin board initialization in generic board_f
On Thu, Aug 07, 2014 at 03:08:52PM +0800, Sonic Zhang wrote: > From: Sonic Zhang > > - init hardware watchdog if applicable > - use CONFIG_SYS_MONITOR_LEN as the gd monitor len for Blackfin > - reserve u-boot memory at the top field of the RAM for Blackfin > - avoid refer to CONFIG_SYS_MONITOR_LEN, which is not defined by Blackfin > > Signed-off-by: Sonic Zhang Build tested this and 1/2 for blackfin and m68k here and everything is good now, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: tegra: use new generic $bootcmd
On 30 July 2014 16:37, Stephen Warren wrote: > From: Stephen Warren > > Replace the custom $bootcmd with that from . > There should be no functional change, since the new generic $bootcmd was > derived strongly from tegra-common-post.h. > > Signed-off-by: Stephen Warren (Resending to list) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 08/07/2014 06:17 PM, Simon Glass wrote: Acked-by: Simon Glass For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: mx6: fix occasional link failures
On Fri, Aug 8, 2014 at 10:33 AM, Marek Vasut wrote:
> Can you guys test it on FSL hardware ?
Sure, I am running u-boot-imx with Tim's patch applied and this
additional debug patch that shows the number of reboots and PCI
linkups:
drivers/pci/pcie_imx.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c
index a3982c4..1ee77f9 100644
--- a/drivers/pci/pcie_imx.c
+++ b/drivers/pci/pcie_imx.c
@@ -20,6 +20,8 @@
#include
#include
+#define DEBUG
+
#define PCI_ACCESS_READ 0
#define PCI_ACCESS_WRITE 1
@@ -573,6 +575,10 @@ void imx_pcie_init(void)
static struct pci_controllerpcc;
struct pci_controller*hose = &pcc;
int ret;
+#ifdef DEBUG
+u32 dbg_reg_addr = 0x020cc068;
+u32 dbg_reg = readl(dbg_reg_addr) + 1;
+#endif
memset(&pcc, 0, sizeof(pcc));
@@ -607,7 +613,14 @@ void imx_pcie_init(void)
if (!ret) {
pci_register_hose(hose);
hose->last_busno = pci_hose_scan(hose);
+#ifdef DEBUG
+dbg_reg += 1<<16;
+#endif
}
+#ifdef DEBUG
+writel(dbg_reg, dbg_reg_addr);
+printf("PCIe Successes/Attempts: %d/%d\n", dbg_reg >> 16, dbg_reg
& 0x);
+#endif
}
Then I do:
=> setenv bootcmd reset
=> save
=> reboot
,connect an Intel Wifi 7260HMW card to the mx6qsabresd and let the
system rebooting in loop.
It has been running with no PCI linkup failures here:
U-Boot 2014.07-16451-g7496820-dirty (Aug 08 2014 - 11:34:13)
CPU: Freescale i.MX6Q rev1.1 at 792 MHz
Reset cause: WDOG
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
00:01.0 - 16c3:abcd - Bridge device
01:00.0- 8086:08b1 - Network controller
PCIe Successes/Attempts: 2350/2350
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out: serial
Err: serial
PMIC: PFUZE100 ID=0x10
Net: FEC [PRIME]
So here goes my:
Tested-by: Fabio Estevam
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] e1000: add i210 support
On Friday, August 08, 2014 at 04:41:37 PM, Tim Harvey wrote: > Two patches to add Intel i210 support to the e1000 driver. > > Marek Vasut (2): > e1000: Implement dcache support > e1000: add i210 support > > drivers/net/e1000.c | 266 > ++-- drivers/net/e1000.h | > 12 +++ > include/pci_ids.h | 7 ++ > 3 files changed, 236 insertions(+), 49 deletions(-) Thanks for taking care of those! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] e1000: add i210 support
From: Marek Vasut
Add i210 support to the e1000 driver.
Signed-off-by: Marek Vasut
Acked-by: Tim Harvey
---
drivers/net/e1000.c | 195
drivers/net/e1000.h | 12
include/pci_ids.h | 7 ++
3 files changed, 187 insertions(+), 27 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 0441a4f..0eba57c 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -92,6 +92,12 @@ static struct pci_device_id e1000_supported[] = {
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_80003ES2LAN_SERDES_DPT},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_80003ES2LAN_COPPER_SPT},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_80003ES2LAN_SERDES_SPT},
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I210_COPPER},
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I210_COPPER_FLASHLESS},
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I210_SERDES},
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I210_SERDES_FLASHLESS},
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_I210_1000BASEKX},
+
{}
};
@@ -340,7 +346,7 @@ int32_t e1000_acquire_eeprom(struct e1000_hw *hw)
return -E1000_ERR_SWFW_SYNC;
eecd = E1000_READ_REG(hw, EECD);
- if (hw->mac_type != e1000_82573 || hw->mac_type != e1000_82574) {
+ if (hw->mac_type != e1000_82573 && hw->mac_type != e1000_82574) {
/* Request EEPROM Access */
if (hw->mac_type > e1000_82544) {
eecd |= E1000_EECD_REQ;
@@ -391,10 +397,15 @@ int32_t e1000_acquire_eeprom(struct e1000_hw *hw)
static int32_t e1000_init_eeprom_params(struct e1000_hw *hw)
{
struct e1000_eeprom_info *eeprom = &hw->eeprom;
- uint32_t eecd = E1000_READ_REG(hw, EECD);
+ uint32_t eecd;
int32_t ret_val = E1000_SUCCESS;
uint16_t eeprom_size;
+ if (hw->mac_type == e1000_igb)
+ eecd = E1000_READ_REG(hw, I210_EECD);
+ else
+ eecd = E1000_READ_REG(hw, EECD);
+
DEBUGFUNC();
switch (hw->mac_type) {
@@ -485,9 +496,10 @@ static int32_t e1000_init_eeprom_params(struct e1000_hw
*hw)
eeprom->page_size = 8;
eeprom->address_bits = 8;
}
- eeprom->use_eerd = true;
- eeprom->use_eewr = true;
if (e1000_is_onboard_nvm_eeprom(hw) == false) {
+ eeprom->use_eerd = true;
+ eeprom->use_eewr = true;
+
eeprom->type = e1000_eeprom_flash;
eeprom->word_size = 2048;
@@ -511,6 +523,16 @@ static int32_t e1000_init_eeprom_params(struct e1000_hw
*hw)
eeprom->use_eerd = true;
eeprom->use_eewr = false;
break;
+ case e1000_igb:
+ /* i210 has 4k of iNVM mapped as EEPROM */
+ eeprom->type = e1000_eeprom_invm;
+ eeprom->opcode_bits = 8;
+ eeprom->delay_usec = 1;
+ eeprom->page_size = 32;
+ eeprom->address_bits = 16;
+ eeprom->use_eerd = true;
+ eeprom->use_eewr = false;
+ break;
/* ich8lan does not support currently. if needed, please
* add corresponding code and functions.
@@ -552,7 +574,8 @@ static int32_t e1000_init_eeprom_params(struct e1000_hw *hw)
break;
}
- if (eeprom->type == e1000_eeprom_spi) {
+ if (eeprom->type == e1000_eeprom_spi ||
+ eeprom->type == e1000_eeprom_invm) {
/* eeprom_size will be an enum [0..8] that maps
* to eeprom sizes 128B to
* 32KB (incremented by powers of 2).
@@ -596,10 +619,17 @@ e1000_poll_eerd_eewr_done(struct e1000_hw *hw, int eerd)
int32_t done = E1000_ERR_EEPROM;
for (i = 0; i < attempts; i++) {
- if (eerd == E1000_EEPROM_POLL_READ)
- reg = E1000_READ_REG(hw, EERD);
- else
- reg = E1000_READ_REG(hw, EEWR);
+ if (eerd == E1000_EEPROM_POLL_READ) {
+ if (hw->mac_type == e1000_igb)
+ reg = E1000_READ_REG(hw, I210_EERD);
+ else
+ reg = E1000_READ_REG(hw, EERD);
+ } else {
+ if (hw->mac_type == e1000_igb)
+ reg = E1000_READ_REG(hw, I210_EEWR);
+ else
+ reg = E1000_READ_REG(hw, EEWR);
+ }
if (reg & E1000_EEPROM_RW_REG_DONE) {
done = E1000_SUCCESS;
@@ -632,13 +662,23 @@ e1000_read_eeprom_eerd(struct e1000_hw *hw,
eerd = ((offset+i) << E1000_EEPROM_RW_ADDR_SHIFT) +
E1000_EEPROM_RW_REG_START;
- E1000_WRITE_REG(hw, EERD, ee
[U-Boot] [PATCH 1/2] e1000: Implement dcache support
From: Marek Vasut
Implement proper support for cache flushing and invalidation into the
Intel e1000 NIC driver.
Signed-off-by: Marek Vasut
Acked-by: Tim Harvey
---
drivers/net/e1000.c | 71 -
1 file changed, 49 insertions(+), 22 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 9d9b259..0441a4f 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -41,12 +41,12 @@ tested on both gig copper and gig fiber boards
/* NIC specific static variables go here */
-static char tx_pool[128 + 16];
-static char rx_pool[128 + 16];
-static char packet[2096];
+/* Intel i210 needs the DMA descriptor rings aligned to 128b */
+#define E1000_BUFFER_ALIGN 128
-static struct e1000_tx_desc *tx_base;
-static struct e1000_rx_desc *rx_base;
+DEFINE_ALIGN_BUFFER(struct e1000_tx_desc, tx_base, 16, E1000_BUFFER_ALIGN);
+DEFINE_ALIGN_BUFFER(struct e1000_rx_desc, rx_base, 16, E1000_BUFFER_ALIGN);
+DEFINE_ALIGN_BUFFER(unsigned char, packet, 4096, E1000_BUFFER_ALIGN);
static int tx_tail;
static int rx_tail, rx_last;
@@ -4803,12 +4803,25 @@ void
fill_rx(struct e1000_hw *hw)
{
struct e1000_rx_desc *rd;
+ uint32_t flush_start, flush_end;
rx_last = rx_tail;
rd = rx_base + rx_tail;
rx_tail = (rx_tail + 1) % 8;
memset(rd, 0, 16);
- rd->buffer_addr = cpu_to_le64((u32) & packet);
+ rd->buffer_addr = cpu_to_le64((u32)packet);
+
+ /*
+* Make sure there are no stale data in WB over this area, which
+* might get written into the memory while the e1000 also writes
+* into the same memory area.
+*/
+ invalidate_dcache_range((u32)packet, (u32)packet + 4096);
+ /* Dump the DMA descriptor into RAM. */
+ flush_start = ((u32)rd) & ~(ARCH_DMA_MINALIGN - 1);
+ flush_end = flush_start + roundup(sizeof(*rd), ARCH_DMA_MINALIGN);
+ flush_dcache_range(flush_start, flush_end);
+
E1000_WRITE_REG(hw, RDT, rx_tail);
}
@@ -4822,17 +4835,10 @@ fill_rx(struct e1000_hw *hw)
static void
e1000_configure_tx(struct e1000_hw *hw)
{
- unsigned long ptr;
unsigned long tctl;
unsigned long tipg, tarc;
uint32_t ipgr1, ipgr2;
- ptr = (u32) tx_pool;
- if (ptr & 0xf)
- ptr = (ptr + 0x10) & (~0xf);
-
- tx_base = (typeof(tx_base)) ptr;
-
E1000_WRITE_REG(hw, TDBAL, (u32) tx_base);
E1000_WRITE_REG(hw, TDBAH, 0);
@@ -4941,7 +4947,6 @@ e1000_setup_rctl(struct e1000_hw *hw)
static void
e1000_configure_rx(struct e1000_hw *hw)
{
- unsigned long ptr;
unsigned long rctl, ctrl_ext;
rx_tail = 0;
/* make sure receives are disabled while setting up the descriptors */
@@ -4963,10 +4968,6 @@ e1000_configure_rx(struct e1000_hw *hw)
E1000_WRITE_FLUSH(hw);
}
/* Setup the Base and Length of the Rx Descriptor Ring */
- ptr = (u32) rx_pool;
- if (ptr & 0xf)
- ptr = (ptr + 0x10) & (~0xf);
- rx_base = (typeof(rx_base)) ptr;
E1000_WRITE_REG(hw, RDBAL, (u32) rx_base);
E1000_WRITE_REG(hw, RDBAH, 0);
@@ -4989,12 +4990,25 @@ e1000_poll(struct eth_device *nic)
{
struct e1000_hw *hw = nic->priv;
struct e1000_rx_desc *rd;
+ uint32_t inval_start, inval_end;
+ uint32_t len;
+
/* return true if there's an ethernet packet ready to read */
rd = rx_base + rx_last;
+
+ /* Re-load the descriptor from RAM. */
+ inval_start = ((u32)rd) & ~(ARCH_DMA_MINALIGN - 1);
+ inval_end = inval_start + roundup(sizeof(*rd), ARCH_DMA_MINALIGN);
+ invalidate_dcache_range(inval_start, inval_end);
+
if (!(le32_to_cpu(rd->status)) & E1000_RXD_STAT_DD)
return 0;
/*DEBUGOUT("recv: packet len=%d \n", rd->length); */
- NetReceive((uchar *)packet, le32_to_cpu(rd->length));
+ /* Packet received, make sure the data are re-loaded from RAM. */
+ len = le32_to_cpu(rd->length);
+ invalidate_dcache_range((u32)packet,
+ (u32)packet + roundup(len, ARCH_DMA_MINALIGN));
+ NetReceive((uchar *)packet, len);
fill_rx(hw);
return 1;
}
@@ -5002,12 +5016,13 @@ e1000_poll(struct eth_device *nic)
/**
TRANSMIT - Transmit a frame
***/
-static int e1000_transmit(struct eth_device *nic, void *packet, int length)
+static int e1000_transmit(struct eth_device *nic, void *txpacket, int length)
{
- void *nv_packet = (void *)packet;
+ void *nv_packet = (void *)txpacket;
struct e1000_hw *hw = nic->priv;
struct e1000_tx_desc *txp;
int i = 0;
+ uint32_t flush_start, flush_end;
txp = tx_base + tx_tail;
tx_tail = (tx_tail + 1) % 8;
@@ -5015,10 +5030,22 @@ static int e
[U-Boot] [PATCH 0/2] e1000: add i210 support
Two patches to add Intel i210 support to the e1000 driver. Marek Vasut (2): e1000: Implement dcache support e1000: add i210 support drivers/net/e1000.c | 266 ++-- drivers/net/e1000.h | 12 +++ include/pci_ids.h | 7 ++ 3 files changed, 236 insertions(+), 49 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: mx6: fix occasional link failures
On Friday, August 08, 2014 at 03:02:27 PM, Fabio Estevam wrote: > Hi Tim, > > On Fri, Aug 8, 2014 at 2:57 AM, Tim Harvey wrote: > > According to the IMX6 reference manuals, REF_SSP_EN (Reference clock > > enable for SS function) must remain deasserted until the reference clock > > is running at the appropriate frequency. > > > > Without this patch we find a high link failure rate (>5%) on certain > > IMX6 boards at various temperatures. > > > > Signed-off-by: Tim Harvey > > Looks good, thanks. > > Reviewed-by: Fabio Estevam > > Also Cc Richard and Rogerio in case they have any comment. Can you guys test it on FSL hardware ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Removing the need for boards.cfg
On Fri, Aug 01, 2014 at 12:48:44PM +0100, Simon Glass wrote: > Hi, > > At present, as a work-around, we generate boards.cfg if needed. This > is quite a slow process since each board config must be fully > processed. > > What can we do to improve this? We only need a small number of options > in order to start buildman - things like CONFIG_SYS_ARCH, > CONFIG_SYS_CPU, etc. > > I wonder if we could run a script which adds these to the defconfigs > for each board and then apply a patch to mainline? Would that require > removing the options from the config.h files? Or could we do that > later as a separate step? I wonder (and I haven't had my coffee nor dug into this much more yet) about using say https://github.com/ulfalizer/Kconfiglib to have buildman parse all configs/ and then use that information to build what's been asked (depending on how long the reading+parsing takes). If it's relatively quick, that would be a big argument in favour of dropping MAKEALL. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: mx6: fix occasional link failures
Hi Tim, On Fri, Aug 8, 2014 at 2:57 AM, Tim Harvey wrote: > According to the IMX6 reference manuals, REF_SSP_EN (Reference clock enable > for SS function) must remain deasserted until the reference clock is running > at the appropriate frequency. > > Without this patch we find a high link failure rate (>5%) on certain > IMX6 boards at various temperatures. > > Signed-off-by: Tim Harvey Looks good, thanks. Reviewed-by: Fabio Estevam Also Cc Richard and Rogerio in case they have any comment. > --- > drivers/pci/pcie_imx.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c > index c48737e..a3982c4 100644 > --- a/drivers/pci/pcie_imx.c > +++ b/drivers/pci/pcie_imx.c > @@ -509,10 +509,6 @@ static int imx6_pcie_deassert_core_reset(void) > > imx6_pcie_toggle_power(); > > - /* Enable PCIe */ > - clrbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_TEST_POWERDOWN); > - setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_REF_SSP_EN); > - > enable_pcie_clock(); > > /* > @@ -521,6 +517,10 @@ static int imx6_pcie_deassert_core_reset(void) > */ > mdelay(50); > > + /* Enable PCIe */ > + clrbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_TEST_POWERDOWN); > + setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_REF_SSP_EN); > + > imx6_pcie_toggle_reset(); > > return 0; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: remove generated boards.cfg within make mrproper
On Thu, Aug 07, 2014 at 02:53:47PM +, Roger Meier wrote: > Hi Masahiro > Quoting Masahiro Yamada : > > >Hi Roger, > > > > > > > >On Thu, 7 Aug 2014 12:52:30 +0200 > >Roger Meier wrote: > > > >>Signed-off-by: Roger Meier > >>CC: Masahiro Yamada > >>CC: Wolfgang Denk > >>--- > >> Makefile |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >>diff --git a/Makefile b/Makefile > >>index 666d291..831e091 100644 > >>--- a/Makefile > >>+++ b/Makefile > >>@@ -1221,7 +1221,7 @@ CLOBBER_FILES += u-boot* MLO* SPL System.map > >> # Directories & files removed with 'make mrproper' > >> MRPROPER_DIRS += include/config include/generated spl tpl \ > >> .tmp_objdiff > >>-MRPROPER_FILES += .config .config.old include/autoconf.mk* > >>include/config.h \ > >>+MRPROPER_FILES += .config .config.old boards.cfg > >>include/autoconf.mk* include/config.h \ > >> ctags etags TAGS cscope* GPATH GTAGS GRTAGS GSYMS > >> > >> # clean - Delete most, but leave enough to build external modules > >>-- > >>1.7.10.4 > > > > > > > >NAK. > > > >MAKEALL needs boards.cfg > > > >Before building each board, MAKEALL runs "make distclean" and > >boards.cfg gets lost. > oops, did not recognize that. Thanks! > > > > >With your patch, MAKEALL does not work at all. > How should we ensure that boards.cfg is up-to-date? > What about removing boards.cfg within "make distclean" and use > "make mrproper" within MAKEALL? Sounds good to me. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: mx6: fix occasional link failures
On Friday, August 08, 2014 at 07:57:29 AM, Tim Harvey wrote: > According to the IMX6 reference manuals, REF_SSP_EN (Reference clock enable > for SS function) must remain deasserted until the reference clock is > running at the appropriate frequency. > > Without this patch we find a high link failure rate (>5%) on certain > IMX6 boards at various temperatures. > > Signed-off-by: Tim Harvey Acked-by: Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Removing the need for boards.cfg
On Fri, Aug 08, 2014 at 05:06:03AM -0600, Simon Glass wrote: > Hi Masahiro, > > On 1 August 2014 06:22, Masahiro Yamada wrote: > > Hi. > > > > > > > > On Fri, 1 Aug 2014 12:48:44 +0100 > > Simon Glass wrote: > > > >> Hi, > >> > >> At present, as a work-around, we generate boards.cfg if needed. This > >> is quite a slow process since each board config must be fully > >> processed. > >> > >> What can we do to improve this? We only need a small number of options > >> in order to start buildman - things like CONFIG_SYS_ARCH, > >> CONFIG_SYS_CPU, etc. > >> > >> I wonder if we could run a script which adds these to the defconfigs > >> for each board and then apply a patch to mainline? Would that require > >> removing the options from the config.h files? Or could we do that > >> later as a separate step? > >> > > > > > > We cannot add CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. to defconfigs > > because they are not user-editable options. > > (They must be always selected in correct combination.) > > > > This is already discussed when I posted the RFC version of the Kconfig > > series. > > My understanding is that if you have a 'select' option in Kconfig then > it will be selected always, but it will still appear in the defconfig. > I think that is the way the kernel works. So there are options that > cannot be changed, and don't appear in the menu, but they are selected > just the same. Maybe we came up with the wrong answer during RFC on Kconfig then. It's good if selecting say CONFIG_TARGET_AM335X_EVM results in CONFIG_SYS_ARCH="arm", CONFIG_SYS_CPU="armv7", etc. I _think_ the problem here is what I ran into with doing CONS_INDEX patches. You cannot do 'select SYS_CPU="armv7"'. So we would instead need to get rid of CONFIG_SYS_CPU and instead do CONFIG_SYS_CPU_ARMV7, etc, etc. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 02/13] buildman: Add some notes about moving from MAKEALL
For those used to MAKEALL, buildman seems strange. Add some notes to ease the transition. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: - Minor changes to the text tools/buildman/README | 92 +++ 1 file changed, 92 insertions(+) diff --git a/tools/buildman/README b/tools/buildman/README index a5d181c..1c919af 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -3,6 +3,8 @@ # SPDX-License-Identifier: GPL-2.0+ # +(Please read 'How to change from MAKEALL' if you are used to that tool) + What is this? = @@ -663,6 +665,96 @@ Other options Buildman has various other command line options. Try --help to see them. +How to change from MAKEALL +== + +Buildman includes most of the features of MAKEALL and is generally faster +and easier to use. In particular it builds entire branches: if a particular +commit introduces an error in a particular board, buildman can easily show +you this, even if a later commit fixes that error. + +The reasons to deprecate MAKEALL are: +- We don't want to maintain two build systems +- Buildman is typically faster +- Buildman has a lot more features + +But still, many people will be sad to lose MAKEALL. If you are used to +MAKEALL, here are a few pointers. + +First you need to set up your tool chains - see the 'Setting up' section +for details. Once you have your required toolchain(s) detected then you are +ready to go. + +Buildman works on entire branches, so the normal use is: + + ./tools/buildman/buildman -b + +followed by (afterwards, or perhaps concurrently in another terminal): + + ./tools/buildman/buildman -b -s + +to see the results of the build. Rather than showing you all the output, +buildman just shows a summary, with red indicating that a commit introduced +an error and green indicating that a commit fixed an error. Use the -e +flag to see the full errors. + +You don't need to stick around on that branch while buildman is running. It +checks out its own copy of the source code, so you can change branches, +add commits, etc. without affecting the build in progress. + +The can include board names, architectures or the +like. There are no flags to disambiguate since ambiguities are rare. Using +the examples from MAKEALL: + +Examples: + - build all Power Architecture boards: + MAKEALL -a powerpc + MAKEALL --arch powerpc + MAKEALL powerpc + ** buildman -b powerpc + - build all PowerPC boards manufactured by vendor "esd": + MAKEALL -a powerpc -v esd + ** buildman -b esd + - build all PowerPC boards manufactured either by "keymile" or "siemens": + MAKEALL -a powerpc -v keymile -v siemens + ** buildman -b keymile siemens + - build all Freescale boards with MPC83xx CPUs, plus all 4xx boards: + MAKEALL -c mpc83xx -v freescale 4xx + ** buildman -b mpc83xx freescale 4xx + +Buildman automatically tries to use all the CPUs in your machine. If you +are building a lot of boards it will use one thread for every CPU core +it detects in your machine. This is like MAKEALL's BUILD_NBUILDS option. +You can use the -T flag to change the number of threads. If you are only +building a few boards, buildman will automatically run make with the -j +flag to increase the number of concurrent make tasks. It isn't normally +that helpful to fiddle with this option, but if you use the BUILD_NCPUS +option in MAKEALL then -j is the equivalent in buildman. + +Buildman puts its output in ../ by default but you can change +this with the -o option. Buildman normally does out-of-tree builds: use -i +to disable that if you really want to. But be careful that once you have +used -i you pollute buildman's copies of the source tree, and you will need +to remove the build directory (normally ../) to run buildman +in normal mode (without -i). + +Buildman doesn't keep the output result normally, but use the -k option to +do this. + +Please read 'Theory of Operation' a few times as it will make a lot of +things clearer. + +Some options you might like are: + + -B shows which functions are growing/shrinking in which commit - great +for finding code bloat. + -S shows image sizes for each commit (just an overall summary) + -u shows boards that you haven't built yet + --step 0 will build just the upstream commit and the last commit of your +branch. This is often a quick sanity check that your branch doesn't +break anything. But note this does not check bisectability! + + TODO -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 05/13] buildman: Sort command line options
These options have got slightly out of order. Fix them.
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4:
- Fix typo in commit message
Changes in v3:
- Add new patch to sort command line options
Changes in v2: None
tools/buildman/buildman.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/buildman/buildman.py b/tools/buildman/buildman.py
index 42847ac..da6025a 100755
--- a/tools/buildman/buildman.py
+++ b/tools/buildman/buildman.py
@@ -70,6 +70,9 @@ parser.add_option('-c', '--count', dest='count', type='int',
parser.add_option('-C', '--force-reconfig', dest='force_reconfig',
action='store_true', default=False,
help='Reconfigure for every commit (disable incremental build)')
+parser.add_option('-d', '--detail', dest='show_detail',
+ action='store_true', default=False,
+ help='Show detailed information for each board in summary')
parser.add_option('-e', '--show_errors', action='store_true',
default=False, help='Show errors and warnings')
parser.add_option('-f', '--force-build', dest='force_build',
@@ -78,9 +81,6 @@ parser.add_option('-f', '--force-build', dest='force_build',
parser.add_option('-F', '--force-build-failures', dest='force_build_failures',
action='store_true', default=False,
help='Force build of previously-failed build')
-parser.add_option('-d', '--detail', dest='show_detail',
- action='store_true', default=False,
- help='Show detailed information for each board in summary')
parser.add_option('-g', '--git', type='string',
help='Git repo containing branch to build', default='.')
parser.add_option('-H', '--full-help', action='store_true', dest='full_help',
@@ -96,6 +96,9 @@ parser.add_option('--list-tool-chains', action='store_true',
default=False,
help='List available tool chains')
parser.add_option('-n', '--dry-run', action='store_true', dest='dry_run',
default=False, help="Do a try run (describe actions, but no nothing)")
+parser.add_option('-o', '--output-dir', type='string',
+ dest='output_dir', default='..',
+ help='Directory where all builds happen and buildman has its workspace
(default is ../)')
parser.add_option('-Q', '--quick', action='store_true',
default=False, help='Do a rough build, with limited warning resolution')
parser.add_option('-s', '--summary', action='store_true',
@@ -110,9 +113,6 @@ parser.add_option('-T', '--threads', type='int',
default=None, help='Number of builder threads to use')
parser.add_option('-u', '--show_unknown', action='store_true',
default=False, help='Show boards with unknown build result')
-parser.add_option('-o', '--output-dir', type='string',
- dest='output_dir', default='..',
- help='Directory where all builds happen and buildman has its workspace
(default is ../)')
parser.usage = """buildman -b [options]
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 04/13] buildman: Move BuilderThread code to its own file
The builder.py file is getting too long, so split out some code.
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4:
- Fix missing import in builder.py
Changes in v3:
- Add new patch to move BuilderThread code to its own file
Changes in v2: None
tools/buildman/builder.py | 439 +---
tools/buildman/builderthread.py | 434 +++
2 files changed, 442 insertions(+), 431 deletions(-)
create mode 100644 tools/buildman/builderthread.py
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index d2b72d5..e2da0eb 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -6,7 +6,6 @@
#
import collections
-import errno
from datetime import datetime, timedelta
import glob
import os
@@ -15,9 +14,9 @@ import Queue
import shutil
import string
import sys
-import threading
import time
+import builderthread
import command
import gitutil
import terminal
@@ -97,428 +96,6 @@ OUTCOME_OK, OUTCOME_WARNING, OUTCOME_ERROR, OUTCOME_UNKNOWN
= range(4)
trans_valid_chars = string.maketrans("/: ", "---")
-def Mkdir(dirname):
-"""Make a directory if it doesn't already exist.
-
-Args:
-dirname: Directory to create
-"""
-try:
-os.mkdir(dirname)
-except OSError as err:
-if err.errno == errno.EEXIST:
-pass
-else:
-raise
-
-class BuilderJob:
-"""Holds information about a job to be performed by a thread
-
-Members:
-board: Board object to build
-commits: List of commit options to build.
-"""
-def __init__(self):
-self.board = None
-self.commits = []
-
-
-class ResultThread(threading.Thread):
-"""This thread processes results from builder threads.
-
-It simply passes the results on to the builder. There is only one
-result thread, and this helps to serialise the build output.
-"""
-def __init__(self, builder):
-"""Set up a new result thread
-
-Args:
-builder: Builder which will be sent each result
-"""
-threading.Thread.__init__(self)
-self.builder = builder
-
-def run(self):
-"""Called to start up the result thread.
-
-We collect the next result job and pass it on to the build.
-"""
-while True:
-result = self.builder.out_queue.get()
-self.builder.ProcessResult(result)
-self.builder.out_queue.task_done()
-
-
-class BuilderThread(threading.Thread):
-"""This thread builds U-Boot for a particular board.
-
-An input queue provides each new job. We run 'make' to build U-Boot
-and then pass the results on to the output queue.
-
-Members:
-builder: The builder which contains information we might need
-thread_num: Our thread number (0-n-1), used to decide on a
-temporary directory
-"""
-def __init__(self, builder, thread_num):
-"""Set up a new builder thread"""
-threading.Thread.__init__(self)
-self.builder = builder
-self.thread_num = thread_num
-
-def Make(self, commit, brd, stage, cwd, *args, **kwargs):
-"""Run 'make' on a particular commit and board.
-
-The source code will already be checked out, so the 'commit'
-argument is only for information.
-
-Args:
-commit: Commit object that is being built
-brd: Board object that is being built
-stage: Stage of the build. Valid stages are:
-distclean - can be called to clean source
-config - called to configure for a board
-build - the main make invocation - it does the build
-args: A list of arguments to pass to 'make'
-kwargs: A list of keyword arguments to pass to command.RunPipe()
-
-Returns:
-CommandResult object
-"""
-return self.builder.do_make(commit, brd, stage, cwd, *args,
-**kwargs)
-
-def RunCommit(self, commit_upto, brd, work_dir, do_config, force_build,
- force_build_failures):
-"""Build a particular commit.
-
-If the build is already done, and we are not forcing a build, we skip
-the build and just return the previously-saved results.
-
-Args:
-commit_upto: Commit number to build (0...n-1)
-brd: Board object to build
-work_dir: Directory to which the source will be checked out
-do_config: True to run a make _defconfig on the source
-force_build: Force a build even if one was previously done
-force_build_failures: Force a bulid if the previous result showed
-failure
-
-Returns:
-tuple containing:
-- CommandResult object containing the results of the build
-- boolean indicating whether 'make
[U-Boot] [PATCH v5 12/13] buildman: Introduce an 'and' operator for board selection
Currently buildman allows a list of boards to build to be specified on the command line. The list can include specific board names, architecture, SOC and so on. At present the list of boards is dealt with in an 'OR' fashion, and there is no way to specify something like 'arm & freescale', meaning boards with ARM architecture but only those made by Freescale. This would exclude the PowerPC boards made by Freescale. Support an '&' operator on the command line to permit this. Ensure that arguments can be specified in a single string to permit easy shell quoting. Suggested-by: York Sun Signed-off-by: Simon Glass --- Changes in v5: - Add new patch to add an 'and' operator for board selection Changes in v4: None Changes in v3: None Changes in v2: None tools/buildman/README | 9 +++ tools/buildman/board.py | 144 ++-- tools/buildman/test.py | 48 3 files changed, 184 insertions(+), 17 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index aaf0a10..d4e8404 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -108,6 +108,15 @@ behaviour is a superset of exact or substring matching. Examples are: * '^tegra[23]0$' All boards with either Tegra20 or Tegra30 SoC * 'powerpc' All PowerPC boards +While the default is to OR the terms together, you can also make use of +the '&' operator to limit the selection: + +* 'freescale & arm sandbox' All Freescale boards with ARM architecture, + plus sandbox + +It is convenient to use the -n option to see whaat will be built based on +the subset given. + Buildman does not store intermediate object files. It optionally copies the binary output into a directory when a build is successful. Size information is always recorded. It needs a fair bit of disk space to work, diff --git a/tools/buildman/board.py b/tools/buildman/board.py index 7bcc932..a333287 100644 --- a/tools/buildman/board.py +++ b/tools/buildman/board.py @@ -5,6 +5,72 @@ import re +class Expr: +"""A single regular expression for matching boards to build""" + +def __init__(self, expr): +"""Set up a new Expr object. + +Args: +expr: String cotaining regular expression to store +""" +self._expr = expr +self._re = re.compile(expr) + +def Matches(self, props): +"""Check if any of the properties match the regular expression. + +Args: + props: List of properties to check +Returns: + True if any of the properties match the regular expression +""" +for prop in props: +if self._re.match(prop): +return True +return False + +def __str__(self): +return self._expr + +class Term: +"""A list of expressions each of which must match with properties. + +This provides a list of 'AND' expressions, meaning that each must +match the board properties for that board to be built. +""" +def __init__(self): +self._expr_list = [] +self._board_count = 0 + +def AddExpr(self, expr): +"""Add an Expr object to the list to check. + +Args: +expr: New Expr object to add to the list of those that must + match for a board to be built. +""" +self._expr_list.append(Expr(expr)) + +def __str__(self): +"""Return some sort of useful string describing the term""" +return '&'.join([str(expr) for expr in self._expr_list]) + +def Matches(self, props): +"""Check if any of the properties match this term + +Each of the expressions in the term is checked. All must match. + +Args: + props: List of properties to check +Returns: + True if all of the expressions in the Term match, else False +""" +for expr in self._expr_list: +if not expr.Matches(props): +return False +return True + class Board: """A particular board that we can build""" def __init__(self, status, arch, cpu, soc, vendor, board_name, target, options): @@ -124,6 +190,55 @@ class Boards: """ return [board.target for board in self._boards if board.build_it] +def _BuildTerms(self, args): +"""Convert command line arguments to a list of terms. + +This deals with parsing of the arguments. It handles the '&' +operator, which joins several expressions into a single Term. + +For example: +['arm & freescale sandbox', 'tegra'] + +will produce 3 Terms containing expressions as follows: +arm, freescale +sandbox +tegra + +The first Term has two expressions, both of which must match for +a board to be selected. + +Args: +args: List of command line arguments +Returns: +A list of Term objects +"""
[U-Boot] [PATCH v5 13/13] RFC: Deprecate MAKEALL
Since buildman now includes most of the features of MAKEALL it is probably
time to talk about deprecating MAKEALL.
Comments welcome.
Signed-off-by: Simon Glass
---
Changes in v5:
- Drop patch to search for *cc instead of *gcc for the compiler
Changes in v4: None
Changes in v3: None
Changes in v2: None
MAKEALL | 4
1 file changed, 4 insertions(+)
diff --git a/MAKEALL b/MAKEALL
index 929fe88..dbbf74b 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -60,6 +60,10 @@ usage()
exit ${ret}
}
+echo "** Note: MAKEALL is deprecated - please use buildman instead"
+echo "** See tools/buildman/README for details"
+echo
+
SHORT_OPTS="ha:c:v:s:b:lmMCnr"
LONG_OPTS="help,arch:,cpu:,vendor:,soc:,board:,list,maintainers,mails,check,continue,rebuild-errors"
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 09/13] buildman: Add an option to specify the buildman config file
Add a new --config-file option (-G) to specify a different configuration
file from the default ~/.buildman.
Reported-by: Tom Rini
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4:
- Add new patch to allow the config file to be specified
Changes in v3: None
Changes in v2: None
tools/buildman/buildman.py | 2 ++
tools/buildman/control.py | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/buildman.py b/tools/buildman/buildman.py
index f32557f..6ca8dc6 100755
--- a/tools/buildman/buildman.py
+++ b/tools/buildman/buildman.py
@@ -83,6 +83,8 @@ parser.add_option('-F', '--force-build-failures',
dest='force_build_failures',
help='Force build of previously-failed build')
parser.add_option('-g', '--git', type='string',
help='Git repo containing branch to build', default='.')
+parser.add_option('-G', '--config-file', type='string',
+ help='Path to buildman config file', default='')
parser.add_option('-H', '--full-help', action='store_true', dest='full_help',
default=False, help='Display the README file')
parser.add_option('-i', '--in-tree', dest='in_tree',
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index cc8593f..0c9e2cb 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -86,7 +86,7 @@ def DoBuildman(options, args):
"""
gitutil.Setup()
-bsettings.Setup()
+bsettings.Setup(options.config_file)
options.git_dir = os.path.join(options.git, '.git')
toolchains = toolchain.Toolchains()
--
2.0.0.526.g5318336
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 03/13] buildman: Allow building of current source tree
Originally buildman had some support for building the current source tree.
However this was dropped before it was submitted, as part of the effort to
make it faster when building entire branches.
Reinstate this support. If no -b option is given, buildman will build the
current source tree.
Reported-by: Masahiro Yamada
Signed-off-by: Simon Glass
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add new patch to build current source tree
Changes in v2: None
tools/buildman/builder.py | 71 +---
tools/buildman/control.py | 91 ++-
2 files changed, 108 insertions(+), 54 deletions(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 48408ff..d2b72d5 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -248,21 +248,34 @@ class BuilderThread(threading.Thread):
if self.toolchain:
# Checkout the right commit
-if commit_upto is not None:
+if self.builder.commits:
commit = self.builder.commits[commit_upto]
if self.builder.checkout:
git_dir = os.path.join(work_dir, '.git')
gitutil.Checkout(commit.hash, git_dir, work_dir,
force=True)
else:
-commit = self.builder.commit # Ick, fix this for
BuildCommits()
+commit = 'current'
# Set up the environment and command line
env = self.toolchain.MakeEnvironment()
Mkdir(out_dir)
args = []
+cwd = work_dir
if not self.builder.in_tree:
-args.append('O=build')
+if commit_upto is None:
+# In this case we are building in the original source
+# directory (i.e. the current directory where buildman
+# is invoked. The output directory is set to this
+# thread's selected work directory.
+#
+# Symlinks can confuse U-Boot's Makefile since
+# we may use '..' in our path, so remove them.
+work_dir = os.path.realpath(work_dir)
+args.append('O=%s/build' % work_dir)
+cwd = None
+else:
+args.append('O=build')
args.append('-s')
if self.builder.num_jobs is not None:
args.extend(['-j', str(self.builder.num_jobs)])
@@ -272,14 +285,14 @@ class BuilderThread(threading.Thread):
# If we need to reconfigure, do that now
if do_config:
-result = self.Make(commit, brd, 'distclean', work_dir,
+result = self.Make(commit, brd, 'distclean', cwd,
'distclean', *args, env=env)
-result = self.Make(commit, brd, 'config', work_dir,
+result = self.Make(commit, brd, 'config', cwd,
*(args + config_args), env=env)
config_out = result.combined
do_config = False # No need to configure next time
if result.return_code == 0:
-result = self.Make(commit, brd, 'build', work_dir, *args,
+result = self.Make(commit, brd, 'build', cwd, *args,
env=env)
result.stdout = config_out + result.stdout
else:
@@ -478,8 +491,10 @@ class BuilderThread(threading.Thread):
self.builder.out_queue.put(result)
else:
# Just build the currently checked-out build
-result = self.RunCommit(None, True)
-result.commit_upto = self.builder.upto
+result, request_config = self.RunCommit(None, brd, work_dir, True,
+True, self.builder.force_build_failures)
+result.commit_upto = 0
+self._WriteResult(result, job.keep_outputs)
self.builder.out_queue.put(result)
def run(self):
@@ -491,12 +506,16 @@ class BuilderThread(threading.Thread):
alive = True
while True:
job = self.builder.queue.get()
+if self.builder.active and alive:
+self.RunJob(job)
+'''
try:
if self.builder.active and alive:
self.RunJob(job)
except Exception as err:
alive = False
print err
+'''
self.builder.queue.task_done()
@@ -763,10 +782,13 @@ class Builder:
Args:
commit_upto: Commit number to use (0..self.count-1)
"""
-commit = self.commits[
[U-Boot] [PATCH v5 08/13] buildman: Remove unused non-incremental build method code
The non-incremental build method is no longer used, so remove it. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: - Add new patch to remove unused non-incremental build method code Changes in v3: None Changes in v2: None tools/buildman/builder.py | 34 -- tools/buildman/test.py| 1 - 2 files changed, 35 deletions(-) diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py index dd7f5a4..22a24b1 100644 --- a/tools/buildman/builder.py +++ b/tools/buildman/builder.py @@ -955,40 +955,6 @@ class Builder: self.upto = self.warned = self.fail = 0 self._timestamps = collections.deque() -def BuildBoardsForCommit(self, board_selected, keep_outputs): -"""Build all boards for a single commit""" -self.SetupBuild(board_selected) -self.count = len(board_selected) -for brd in board_selected.itervalues(): -job = BuilderJob() -job.board = brd -job.commits = None -job.keep_outputs = keep_outputs -self.queue.put(brd) - -self.queue.join() -self.out_queue.join() -print -self.ClearLine(0) - -def BuildCommits(self, commits, board_selected, show_errors, keep_outputs): -"""Build all boards for all commits (non-incremental)""" -self.commit_count = len(commits) - -self.ResetResultSummary(board_selected) -for self.commit_upto in range(self.commit_count): -self.SelectCommit(commits[self.commit_upto]) -self.SelectOutputDir() -builderthread.Mkdir(self.output_dir) - -self.BuildBoardsForCommit(board_selected, keep_outputs) -board_dict, err_lines = self.GetResultSummary() -self.PrintResultSummary(board_selected, board_dict, -err_lines if show_errors else []) - -if self.already_done: -print '%d builds already done' % self.already_done - def GetThreadDir(self, thread_num): """Get the directory path to the working dir for a thread. diff --git a/tools/buildman/test.py b/tools/buildman/test.py index a724d83..502c9b4 100644 --- a/tools/buildman/test.py +++ b/tools/buildman/test.py @@ -136,7 +136,6 @@ class TestBuild(unittest.TestCase): build.do_make = self.Make board_selected = self.boards.GetSelectedDict() -#build.BuildCommits(self.commits, board_selected, False) build.BuildBoards(self.commits, board_selected, keep_outputs=False, verbose=False) build.SetDisplayOptions(show_errors=True); -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 06/13] buildman: Refactor output options
We need the output options to be available in several places. It's a pain to pass them into each function. Make them properties of the builder and add a single function to set them up. At the same time, add a function which produces summary output using these options. Signed-off-by: Simon Glass --- Changes in v5: - Update test for output options Changes in v4: None Changes in v3: - Add new patch to refactor output options Changes in v2: None tools/buildman/builder.py | 46 +++--- tools/buildman/control.py | 8 tools/buildman/test.py| 6 +++--- 3 files changed, 34 insertions(+), 26 deletions(-) diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py index e2da0eb..a6c43e0 100644 --- a/tools/buildman/builder.py +++ b/tools/buildman/builder.py @@ -235,6 +235,20 @@ class Builder: for t in self.threads: del t +def SetDisplayOptions(self, show_errors=False, show_sizes=False, + show_detail=False, show_bloat=False): +"""Setup display options for the builder. + +show_errors: True to show summarised error/warning info +show_sizes: Show size deltas +show_detail: Show detail for each board +show_bloat: Show detail for each function +""" +self._show_errors = show_errors +self._show_sizes = show_sizes +self._show_detail = show_detail +self._show_bloat = show_bloat + def _AddTimestamp(self): """Add a new timestamp to the list and record the build period. @@ -891,9 +905,18 @@ class Builder: print "Boards not built (%d): %s" % (len(not_built), ', '.join(not_built)) +def ProduceResultSummary(self, commit_upto, commits, board_selected): +board_dict, err_lines = self.GetResultSummary(board_selected, +commit_upto, read_func_sizes=self._show_bloat) +if commits: +msg = '%02d: %s' % (commit_upto + 1, +commits[commit_upto].subject) +print self.col.Color(self.col.BLUE, msg) +self.PrintResultSummary(board_selected, board_dict, +err_lines if self._show_errors else [], +self._show_sizes, self._show_detail, self._show_bloat) -def ShowSummary(self, commits, board_selected, show_errors, show_sizes, -show_detail, show_bloat): +def ShowSummary(self, commits, board_selected): """Show a build summary for U-Boot for a given board list. Reset the result summary, then repeatedly call GetResultSummary on @@ -902,27 +925,13 @@ class Builder: Args: commit: Commit objects to summarise board_selected: Dict containing boards to summarise -show_errors: Show errors that occured -show_sizes: Show size deltas -show_detail: Show detail for each board -show_bloat: Show detail for each function """ self.commit_count = len(commits) if commits else 1 self.commits = commits self.ResetResultSummary(board_selected) for commit_upto in range(0, self.commit_count, self._step): -board_dict, err_lines = self.GetResultSummary(board_selected, -commit_upto, read_func_sizes=show_bloat) -if commits: -msg = '%02d: %s' % (commit_upto + 1, -commits[commit_upto].subject) -else: -msg = 'current' -print self.col.Color(self.col.BLUE, msg) -self.PrintResultSummary(board_selected, board_dict, -err_lines if show_errors else [], show_sizes, show_detail, -show_bloat) +self.ProduceResultSummary(commit_upto, commits, board_selected) def SetupBuild(self, board_selected, commits): @@ -1032,14 +1041,13 @@ class Builder: if dirname not in dir_list: shutil.rmtree(dirname) -def BuildBoards(self, commits, board_selected, show_errors, keep_outputs): +def BuildBoards(self, commits, board_selected, keep_outputs): """Build all commits for a list of boards Args: commits: List of commits to be build, each a Commit object boards_selected: Dict of selected boards, key is target name, value is Board object -show_errors: True to show summarised error/warning info keep_outputs: True to save build output files """ self.commit_count = len(commits) if commits else 1 diff --git a/tools/buildman/control.py b/tools/buildman/control.py index 12a9699..d8fa74b 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -207,13 +207,13 @@ def DoBuildman(options, args): print GetActionSummary(options.summary, commits, board_selected, op
[U-Boot] [PATCH v5 10/13] buildman: Add a message indicating there are no errors
If buildman finds no problems it prints nothing. This can be a bit confusing, so add a message that all is well. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: - Add new patch to show a message when there are no errors Changes in v3: None Changes in v2: None tools/buildman/builder.py | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py index 22a24b1..3a156ae 100644 --- a/tools/buildman/builder.py +++ b/tools/buildman/builder.py @@ -891,10 +891,13 @@ class Builder: self.col.MAGENTA) for arch, target_list in arch_list.iteritems(): print '%10s: %s' % (arch, target_list) +self._error_lines += 1 if better_err: print self.col.Color(self.col.GREEN, '\n'.join(better_err)) +self._error_lines += 1 if worse_err: print self.col.Color(self.col.RED, '\n'.join(worse_err)) +self._error_lines += 1 if show_sizes: self.PrintSizeSummary(board_selected, board_dict, show_detail, @@ -937,9 +940,12 @@ class Builder: self.commit_count = len(commits) if commits else 1 self.commits = commits self.ResetResultSummary(board_selected) +self._error_lines = 0 for commit_upto in range(0, self.commit_count, self._step): self.ProduceResultSummary(commit_upto, commits, board_selected) +if not self._error_lines: +print self.col.Color(self.col.GREEN, '(no errors to report)') def SetupBuild(self, board_selected, commits): -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 07/13] buildman: Add verbose option to display errors as they happen
Normally buildman operates in two passes - one to do the build and another to summarise the errors. Add a verbose option (-v) to display build problems as they happen. With -e also given, this will display errors too. When building the current source tree (rather than a list of commits in a branch), both -v and -e are enabled automatically. Signed-off-by: Simon Glass --- Changes in v5: - Update test for verbose option Changes in v4: None Changes in v3: - Add new patch to add a verbose option Changes in v2: None tools/buildman/README | 46 -- tools/buildman/builder.py | 16 +--- tools/buildman/buildman.py | 2 ++ tools/buildman/control.py | 4 +++- tools/buildman/test.py | 3 ++- 5 files changed, 56 insertions(+), 15 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index 1c919af..6ba24c0 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -41,9 +41,10 @@ Theory of Operation Buildman is a builder. It is not make, although it runs make. It does not produce any useful output on the terminal while building, except for -progress information. All the output (errors, warnings and binaries if you -are ask for them) is stored in output directories, which you can look at -while the build is progressing, or when it is finished. +progress information (except with -v, see below). All the output (errors, +warnings and binaries if you are ask for them) is stored in output +directories, which you can look at while the build is progressing, or when +it is finished. Buildman produces a concise summary of which boards succeeded and failed. It shows which commit introduced which board failure using a simple @@ -77,12 +78,17 @@ Buildman automatically selects the correct tool chain for each board. You must supply suitable tool chains, but buildman takes care of selecting the right one. -Buildman always builds a branch, and always builds the upstream commit as -well, for comparison. It cannot build individual commits at present, unless -(maybe) you point it at an empty branch. Put all your commits in a branch, -set the branch's upstream to a valid value, and all will be well. Otherwise -buildman will perform random actions. Use -n to check what the random -actions might be. +Buildman generally builds a branch (with the -b flag), and in this case +builds the upstream commit as well, for comparison. It cannot build +individual commits at present, unless (maybe) you point it at an empty +branch. Put all your commits in a branch, set the branch's upstream to a +valid value, and all will be well. Otherwise buildman will perform random +actions. Use -n to check what the random actions might be. + +If you just want to build the current source tree, leave off the -b flag. +This will display results and errors as they happen. You can still look +at them later using -s. Note that buildman will assume that the source +has changed, and will build all specified boards in this case. Buildman is optimised for building many commits at once, for many boards. On multi-core machines, Buildman is fast because it uses most of the @@ -659,6 +665,15 @@ It is expected that any variables added are dealt with in U-Boot's config.mk file and documented in the README. +Quick Sanity Check +== + +If you have made changes and want to do a quick sanity check of the +currently-checked-out source, run buildman without the -b flag. This will +build the selected boards and display build status and errors as it runs +(i.e. -v amd -e are enabled automatically). + + Other options = @@ -685,7 +700,15 @@ First you need to set up your tool chains - see the 'Setting up' section for details. Once you have your required toolchain(s) detected then you are ready to go. -Buildman works on entire branches, so the normal use is: +To build the current source tree, run buildman without a -b flag: + + ./tools/buildman/buildman + +This will build the current source tree for the given boards and display +the results and errors. + +However buildman usually works on entire branches, and for that you must +specify a board flag: ./tools/buildman/buildman -b @@ -698,6 +721,9 @@ buildman just shows a summary, with red indicating that a commit introduced an error and green indicating that a commit fixed an error. Use the -e flag to see the full errors. +If you really want to see build results as they happen, use -v when doing a +build (and -e if you want to see errors as well). + You don't need to stick around on that branch while buildman is running. It checks out its own copy of the source code, so you can change branches, add commits, etc. without affecting the build in progress. diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py index a6c43e0..dd7f5a4 100644 --- a/tools/buildman/builder.py +++ b/tools/buildman/builder.py @@ -321,7 +321,8 @@ class Builder: """Process the
[U-Boot] [PATCH v5 11/13] buildman: Add a few more toolchain examples to the README
The current README is a bit sparse in this area, so add a few more examples. Suggested-by: Tom Rini Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: - Add new path to add a few more toolchain examples to the README Changes in v3: None Changes in v2: None tools/buildman/README | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/buildman/README b/tools/buildman/README index 6ba24c0..aaf0a10 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -134,6 +134,8 @@ example: root: / rest: /toolchains/* eldk: /opt/eldk-4.2 +arm: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux +aarch64: /opt/linaro/gcc-linaro-aarch64-none-elf-4.8-2013.10_linux [toolchain-alias] x86: i386 -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 01/13] buildman: Fix a few typos
There are several typos in the README - fix them. Signed-off-by: Simon Glass --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: - Add new patch to fix existing typos tools/buildman/README | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index c30c1d4..a5d181c 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -71,8 +71,8 @@ directory. It clones this repository into a copy for each thread, and the threads do not affect the state of your git repository. Any checkouts done by the thread affect only the working directory for that thread. -Buildman automatically selects the correct toolchain for each board. You -must supply suitable toolchains, but buildman takes care of selecting the +Buildman automatically selects the correct tool chain for each board. You +must supply suitable tool chains, but buildman takes care of selecting the right one. Buildman always builds a branch, and always builds the upstream commit as @@ -287,7 +287,7 @@ If it can't detect the upstream branch, try checking out the branch, and doing something like 'git branch --set-upstream upstream/master' or something similar. -As an exmmple: +As an example: Dry run, so not doing much. But I would do this: @@ -339,7 +339,7 @@ Building 18 commits for 1059 boards (4 threads, 1 job per thread) 528 36 124 /19062 1:13:30 : SIMPC8313_SP This means that it is building 19062 board/commit combinations. So far it -has managed to succesfully build 528. Another 36 have built with warnings, +has managed to successfully build 528. Another 36 have built with warnings, and 124 more didn't build at all. Buildman expects to complete the process in an hour and 15 minutes. Use this time to buy a faster computer. @@ -413,7 +413,7 @@ again. At commit 16, the error moves - you can see that the old error at line 120 is fixed, but there is a new one at line 126. This is probably only because -we added some code and moved the broken line futher down the file. +we added some code and moved the broken line father down the file. If many boards have the same error, then -e will display the error only once. This makes the output as concise as possible. @@ -491,7 +491,7 @@ You can also use -d to see a detailed size breakdown for each board. This list is sorted in order from largest growth to largest reduction. It is possible to go a little further with the -B option (--bloat). This -shows where U-Boot has bloted, breaking the size change down to the function +shows where U-Boot has bloated, breaking the size change down to the function level. Example output is below: $ ./tools/buildman/buildman -b us-mem4 -sSdB -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/13] Add some missing buildman features and deprecate MAKEALL
Buildman has been around for a little over a year and is used by a fair number of U-Boot developers. However quite a few people still use MAKEALL. Buildman was intended to replace MAKEALL, so perhaps now is a good time to start that process. The reasons to deprecate MAKEALL are: - We don't want to maintain two build systems - Buildman is typically faster - Buildman has a lot more features This series adds a few features to buildman to fill some gaps, adds some information into the README on how to migrate from MAKEALL, and adds a deprecation message to MAKEALL. Changes in v5: - Update test for output options - Update test for verbose option - Add new patch to add an 'and' operator for board selection - Drop patch to search for *cc instead of *gcc for the compiler Changes in v4: - Fix missing import in builder.py - Fix typo in commit message - Add new patch to remove unused non-incremental build method code - Add new patch to allow the config file to be specified - Add new patch to show a message when there are no errors - Add new path to add a few more toolchain examples to the README Changes in v3: - Add new patch to build current source tree - Add new patch to move BuilderThread code to its own file - Add new patch to sort command line options - Add new patch to refactor output options - Add new patch to add a verbose option Changes in v2: - Add new patch to fix existing typos - Minor changes to the text Simon Glass (13): buildman: Fix a few typos buildman: Add some notes about moving from MAKEALL buildman: Allow building of current source tree buildman: Move BuilderThread code to its own file buildman: Sort command line options buildman: Refactor output options buildman: Add verbose option to display errors as they happen buildman: Remove unused non-incremental build method code buildman: Add an option to specify the buildman config file buildman: Add a message indicating there are no errors buildman: Add a few more toolchain examples to the README buildman: Introduce an 'and' operator for board selection RFC: Deprecate MAKEALL MAKEALL | 4 + tools/buildman/README | 159 ++-- tools/buildman/board.py | 144 +-- tools/buildman/builder.py | 544 ++-- tools/buildman/builderthread.py | 434 tools/buildman/buildman.py | 16 +- tools/buildman/control.py | 101 +--- tools/buildman/test.py | 56 - 8 files changed, 905 insertions(+), 553 deletions(-) create mode 100644 tools/buildman/builderthread.py -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Removing the need for boards.cfg
Hi Masahiro, On 1 August 2014 06:22, Masahiro Yamada wrote: > Hi. > > > > On Fri, 1 Aug 2014 12:48:44 +0100 > Simon Glass wrote: > >> Hi, >> >> At present, as a work-around, we generate boards.cfg if needed. This >> is quite a slow process since each board config must be fully >> processed. >> >> What can we do to improve this? We only need a small number of options >> in order to start buildman - things like CONFIG_SYS_ARCH, >> CONFIG_SYS_CPU, etc. >> >> I wonder if we could run a script which adds these to the defconfigs >> for each board and then apply a patch to mainline? Would that require >> removing the options from the config.h files? Or could we do that >> later as a separate step? >> > > > We cannot add CONFIG_SYS_ARCH, CONFIG_SYS_CPU, etc. to defconfigs > because they are not user-editable options. > (They must be always selected in correct combination.) > > This is already discussed when I posted the RFC version of the Kconfig series. My understanding is that if you have a 'select' option in Kconfig then it will be selected always, but it will still appear in the defconfig. I think that is the way the kernel works. So there are options that cannot be changed, and don't appear in the menu, but they are selected just the same. > > > We can easily do > > [1] Choose boards by arch > > Just grep CONFIG_ARM=y, CONFIG_MIPS=y, CONFIG_SANDBOX=y in defconfigs OK. > > [2] Choose boards by board name > > It is the file name of defconfigs Almost, as Wolfgang points out. > > > > > My question is, do we really need to choose by CPU, Vendor, SoC ? > I know they are useful. > For ex. nvidia developers probably want to build only Tegra boards. > > > > One possible idea I come up with is to have 'board group' in .buildman file > so people can build only boards they are interested in. > > > Something like this: > > -->8--- > > [board-alisa] > tegra20: harmony seaboard ventana > tegra30: beaver > tegra114: dalmore > tegra124: venice2 > tegra:tegra20 tegra30 tegra114 tegra124 > > ---8<--- > > > With the settings above, > > > "tools/buildman/buildman tegra20" > is the same as > "tools/buildman/buildman harmony seaboard ventana" > > > "tools/buildman/buildman tegra" > is the same as > "tools/buildman/buildmantegra20 tegra30 tegra114 tegra124" > and also the same as > "tools/buildman/buildmanharmony seaboard ventana beaver dalmore venice2" > > > > We have to setup ~/.buildman at the first run. > (and modify it when adding new boards) > > Better to provide a tool to auto-generate .buildman file? That doesn't sound very different to having a boards.cfg file again. If we really need it, it seems better to me to have an auto-generated boards.cfg which is checked into the source tree, at least for now. When people add boards they can re-run the generation script. But I'd like to avoid that if possible, so will await your thoughts on the above Kconfig question. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 02/13] buildman: Add some notes about moving from MAKEALL
Hi Masahiro, On 7 August 2014 07:14, Masahiro Yamada wrote: > Hi. > > > > On Thu, 7 Aug 2014 06:12:18 -0600 > Simon Glass wrote: > >> Hi Tom, York, >> >> On 6 August 2014 09:06, Tom Rini wrote: >> > On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote: >> >> Hi York, >> >> >> >> On 5 August 2014 20:53, York Sun wrote: >> >> > >> >> > >> >> > On 8/5/14 7:15 PM, "Simon Glass" wrote: >> >> >> >> But in this case why not just leave off the 'freescale'? >> >> >>> >> >> >>> This is just an example. What if I chose "-a arm" and "-v freescale". >> >> >>>ARM has >> >> >>> 300+ targets, but only 20+ are for Freescale. I could save time by >> >> >>>building a >> >> >>> lot less platforms. >> >> >>> >> >> >>> The point here is the "OR" logic. >> >> >> >> >> >>I suppose you could use mx6 or similar, but I take your point. >> >> >> >> >> >>So what could we do here? Perhaps add a --vendor flag to limit to a >> >> >>particular vendor? Would that be enough? >> >> > >> >> > With the ability to build targets for more than one arch, I will be >> >> > tempted to use syntax like this >> >> > >> >> > buildman (powerpc & freescale) (arm & freescale) aarch64 >> > >> > Spaces outside of parens are implicit ORs here, so all >> > powerpc+freescale, all arm+freescale and all aarch64. In the fullness >> > of time the last one might become all freescale+aarch64. Bonus points >> > if we can easily write 'buildman ... ((powerpc|arm|aarch64) & freescale)' >> > >> > Thinking out loud, the problem is today we have | for OR but we don't >> > have an AND symbol. I can do: >> > $ buildman 'arm|powerpc|aarch64' >> > Today and get what I want. But I can't: >> > $ buildman '(powerpc&freescale)|(arm&freescale)' >> >> OK I'll have a crack at this. >> > > I am afraid the requirement for buildman is getting too complicated. > > >> > $ buildman '(powerpc&freescale)|(arm&freescale)' > > This feature completely depends on boards.cfg > but we want to completely break with it, don't we? > > Grepping Kconfig for searching Freescale boards > is almost impossible, I think. Actually buildman requires this information regardless, so it knows what boards to build. It needs a list of all boards even if there are no conditions. > > Maybe it is time to change our mind. > But I have no idea for the replacement. Let's continue in the other thread. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: fix ERASE_GRP_DEF handling
if we set manually this bit on the eMMC card using mmc_switch(...), we also have to set it within our (before read) internal structure 'ext_csd'. Otherwise following checks on this will fail. Signed-off-by: Hannes Petermaier --- drivers/mmc/mmc.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index a26f3ce..52a8e36 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1010,6 +1010,8 @@ static int mmc_startup(struct mmc *mmc) if (err) return err; + else + ext_csd[EXT_CSD_ERASE_GROUP_DEF] = 1; /* Read out group size from ext_csd */ mmc->erase_grp_size = -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: spl: Add vectors section to linker script
On 08/07/2014 02:26 PM, Peter Crosthwaite wrote:
> The vectors section contains the _start symbol which is used as the
> program entry point. Add it to the linker script in same fashion as done
> for regular u-boot. This allows for correct generation of an spl elf
> with a non-zero entry point.
>
> A similar change was applied to sunxi platform in
> "sunxi: Fix u-boot-spl.lds to refer to .vectors"
> (sha1: 9e5f80d823e3fd2a685b10ecf02009e34b86cff9)
>
> This also allows for placement of the vector table at the hivecs
> location by setting the TEXT_BASE to 0x.
>
> Tested-by: Michal Simek
> Signed-off-by: Peter Crosthwaite
>
> ---
> Changed since v1 (Michal Review):
> s/fasion/fashion
> elaborate commit SHA1 reference
> ---
> arch/arm/cpu/armv7/zynq/u-boot-spl.lds | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/cpu/armv7/zynq/u-boot-spl.lds
> b/arch/arm/cpu/armv7/zynq/u-boot-spl.lds
> index 0c4501e..0f2f756 100644
> --- a/arch/arm/cpu/armv7/zynq/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv7/zynq/u-boot-spl.lds
> @@ -22,6 +22,7 @@ SECTIONS
> .text :
> {
> __image_copy_start = .;
> + *(.vectors)
> CPUDIR/start.o (.text*)
> *(.text*)
> } > .sram
>
Applied.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: m53evk: Fix RTC bus number
On 25/07/2014 17:23, Marek Vasut wrote: > A previous update to the I2C stack introduced a typo in the > configuration option. Fix the typo and therefore allow the > RTC to work correctly with the 'date' command again. > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX31 PDK: Enable generic board for i.MX31 PDK
On 05/08/2014 19:03, Magnus Lilja wrote: > Enable CONFIG_SYS_GENERIC_BOARD for the i.MX31 PDK board. > > Tested on actual hardware. > > Signed-off-by: Magnus Lilja > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] pmic: pmic_pfuze100: Use a shorter name for PMIC name
On 01/08/2014 13:50, Fabio Estevam wrote: > From: Fabio Estevam > > It is redundant to use 'PFUZE100_PMIC' as the PMIC name because we already > know it is a PMIC. > > Call it simply 'PFUZE100' instead. > > Cc: Tim Harvey > Cc: Markus Niebel > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] mx6: crm_regs: Fix MXC_CCM_CLPCR_WB_PER_AT_LPM definition
On 01/08/2014 13:50, Fabio Estevam wrote: > From: Fabio Estevam > > According to the Reference Manual the 'wb_per_at_lpm' field of register > CCM_CLPCR corresponds to bit 16 so fix its definition accordingly. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] mx6: crm_regs: Fix MXC_CCM_CIMR_MASK_PERIPH2_CLK_SEL_LOADED
On 01/08/2014 13:50, Fabio Estevam wrote: > From: Fabio Estevam > > According to the Reference Manual the 'mask_periph2_clk_sel_loaded' field of > register CCM_CIMR corresponds to bit 19 so fix its definition accordingly. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mx6: imx-regs: Remove unused 'omux' field from iomux struct
On 01/08/2014 13:49, Fabio Estevam wrote: > From: Fabio Estevam > > 'omux' field is not used anywhere and such layout is not valid for mx6solox. > > Instead of adding more ifdef's into the structure, let's simply remove this > unused 'omux' field. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] mx6: crm_regs: Fix CDCDR_SPDIF0_CLK_PODF mask and offset
On 01/08/2014 13:50, Fabio Estevam wrote: > From: Fabio Estevam > > According to the Reference Manual the 'spdif0_clk_podf' field of register > CCM_CDCDR corresponds to bits 22, 23 and 24, so fix the mask and offset > definitions accordingly. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/18] arm: mx6: add support for Compulab cm-fx6 CoM
On Wed, Aug 6, 2014 at 10:29 AM, Nikita Kiryanov wrote:
>
>
> On 04/08/14 16:36, Nikita Kiryanov wrote:
>>
>>
>>
>> On 04/08/14 07:45, Tim Harvey wrote:
>>>
>>> On Sun, Aug 3, 2014 at 12:34 AM, Nikita Kiryanov
>>> wrote:
Add initial support for Compulab CM-FX6 CoM.
Support includes MMC, SPI flash, and SPL with dynamic DRAM detection.
>>>
+
+static void spl_mx6s_dram_init(enum ddr_config dram_config, int reset)
+{
+ struct mx6_mmdc_calibration calib;
+ struct mx6_ddr_sysinfo sysinfo;
+ struct mx6_ddr3_cfg ddr3_cfg;
+
+ if (reset)
+ ((struct mmdc_p_regs *)MX6_MMDC_P0_MDCTL)->mdmisc = 2;
+
+ calib.p0_mpwldectrl0= 0x005B0061;
+ calib.p0_mpwldectrl1= 0x004F0055;
+ calib.p0_mpdgctrl0 = 0x0314030C;
+ calib.p0_mpdgctrl1 = 0x025C0268;
+ calib.p0_mprddlctl = 0x42464646;
+ calib.p0_mpwrdlctl = 0x36322C34;
+ ddr3_cfg.mem_speed = 800;
+ ddr3_cfg.density= 4;
+ ddr3_cfg.rowaddr= 14;
+ ddr3_cfg.coladdr= 10;
+ ddr3_cfg.pagesz = 2;
+ ddr3_cfg.trcd = 1800;
+ ddr3_cfg.trcmin = 5200;
+ ddr3_cfg.trasmin= 3600;
+ ddr3_cfg.SRT= 0;
+ sysinfo.cs1_mirror = 1;
+ sysinfo.cs_density = 16;
+ sysinfo.bi_on = 1;
+ sysinfo.rtt_nom = 1;
+ sysinfo.rtt_wr = 0;
+ sysinfo.ralat = 5;
+ sysinfo.walat = 1;
+ sysinfo.mif3_mode = 3;
+ sysinfo.rst_to_cke = 0x23;
+ sysinfo.sde_to_rst = 0x10;
+ switch (dram_config) {
+ case DDR_16BIT_256MB:
+ sysinfo.dsize = 0;
+ sysinfo.ncs = 1;
+ break;
+ case DDR_32BIT_512MB:
+ sysinfo.dsize = 1;
+ sysinfo.ncs = 1;
+ break;
+ case DDR_32BIT_1GB:
+ sysinfo.dsize = 1;
+ sysinfo.ncs = 2;
+ break;
+ default:
+ puts("Tried to setup invalid DDR configuration\n");
+ hang();
+ }
+
+ mx6_dram_cfg(&sysinfo, &calib, &ddr3_cfg);
+ udelay(100);
+}
>>>
>>>
>>> Nikita,
>>>
>>> I'm curious why you add an extra udelay(100) here? There is an
>>> mdelay(1) before the return of mx6_dram_cfg() to wait for auto-ZQ
>>> calibration to complete (I never found a way to determine when it was
>>> complete via registers).
>>
>>
>> Yes you're right. This udelay can probably be removed (unless I catch
>> the board misbehaving during multiple resets).
>
>
> Caught the DRAM config failing during multiple resets when udelay(100)
> is removed, so I guess they stay..
>
Nikita,
What exactly was failing? Was the subsequent to get_ram_size()
failing? If the extra delay is really needed we should add it to the
mx6_dram_cfg() function. The issue I ran into before I added the
mdelay(1) there to wait for auto-ZQ calib to complete was that SDRAM
operations immediately following the call to mx6_dram_cfg() would be
un-reliable, specifically a memset to 0 would fail to clear memory
where GD was which caused some interesting failures down the line.
Maybe I'll open up an issue with Freescale and ask them if there is a
way to know when auto-ZQ calibration is complete because it isn't
clear to me how to do that. The 1ms delay was because the 0 value we
set to MPZQHWCTRL ZQ_HW_PER configures it for a 1ms ZQ calibration
cycle maybe we simply need a little more headroom.
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
