[U-Boot] Pull request: u-boot-net
A few patches that came in during the merge window and appear harmless.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
---------------------------------------------------------------- Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet() net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
Fabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-)
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
so..
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet()
This one here pushes "iocon" just over the edge, again, with ELDK 5.6.
First off, let me say that I eagarly await the gcc that will finally let strings of garbage collected functions also be collected and dropped. My first very quick _hack_ here to gain a tiny bit of space back was to remove from the common case some functions in common/fdt_support.c
I really don't know a good fix for today and as Dirk has pointed out (and I frankly agree, and have been poked about in some other places), we really do need to take care with our image sizes when adding all of these neat new features.
net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unusedFabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-) _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Tom,
On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
so..
Hmm... With the buildman toolchains I'm using nothing broke.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet()
This one here pushes "iocon" just over the edge, again, with ELDK 5.6.
First off, let me say that I eagarly await the gcc that will finally let strings of garbage collected functions also be collected and dropped. My first very quick _hack_ here to gain a tiny bit of space back was to remove from the common case some functions in common/fdt_support.c
I really don't know a good fix for today and as Dirk has pointed out (and I frankly agree, and have been poked about in some other places), we really do need to take care with our image sizes when adding all of these neat new features.
That's a fine goal, but features aren't free. We can have a goal of not bloating grossly or making easily separable functionality disable-able by adding ifdefs, but requiring that any given combination of ifdefs in a config never grow even a few bytes seems unwieldy. Surely keeping any target so close to the limit is a waste of everyone's time and energy. Why not take advantage of the enormous numbers of ifdefs and start disabling some features to get these targets off the ledge?
-Joe
On Mon, Dec 28, 2015 at 09:02:02PM -0600, Joe Hershberger wrote:
Hi Tom,
On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
so..
Hmm... With the buildman toolchains I'm using nothing broke.
What one(s) are that? ELDK 5.3 has failed for a while for me and ELDK 5.6 just started with this PR.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet()
This one here pushes "iocon" just over the edge, again, with ELDK 5.6.
First off, let me say that I eagarly await the gcc that will finally let strings of garbage collected functions also be collected and dropped. My first very quick _hack_ here to gain a tiny bit of space back was to remove from the common case some functions in common/fdt_support.c
I really don't know a good fix for today and as Dirk has pointed out (and I frankly agree, and have been poked about in some other places), we really do need to take care with our image sizes when adding all of these neat new features.
That's a fine goal, but features aren't free. We can have a goal of not bloating grossly or making easily separable functionality disable-able by adding ifdefs, but requiring that any given
Yes, this is where I do agree and wonder if we perhaps haven't been giving enough care here. Especially since until another big gcc release or two we won't have the stupid string consolidation bug fixed. We may need to keep that bug in mind and re-think how we structure some of the code.
combination of ifdefs in a config never grow even a few bytes seems unwieldy. Surely keeping any target so close to the limit is a waste of everyone's time and energy. Why not take advantage of the enormous numbers of ifdefs and start disabling some features to get these targets off the ledge?
The problem with "iocon" is that we have an active board maintainer and I'm not immediately seeing a bunch of waste that could just be turned off here. Perhaps Dirk will see something or another.
-Joe
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet() net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
Fabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-)
I think at this stage in the release we need to rework this and drop the fdt patches, or defer the whole thing until we can figure out some way to fit iocon in with the ELDK 5.6 toolchains. Thanks!
+Dirk
On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet() net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
Fabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-)
I think at this stage in the release we need to rework this and drop the fdt patches, or defer the whole thing until we can figure out some way to fit iocon in with the ELDK 5.6 toolchains. Thanks!
--
I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain. I am downloading ELDK 5.6 toolchain to see what's going on there. IMHO, we should increase the iocon's U-Boot size to 512K. I see from its iocon.h file its flash size is 64MB, which has plenty of spaces to store a bigger U-Boot. Even if we try our best to rework this fdt patch, there is still possibility to break iocon sometime in the future by some other random fixes or new features. This to me is a tedious process.
Regards, Bin
On Mon, Jan 04, 2016 at 10:35:39AM +0800, Bin Meng wrote:
+Dirk
On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet() net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
Fabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-)
I think at this stage in the release we need to rework this and drop the fdt patches, or defer the whole thing until we can figure out some way to fit iocon in with the ELDK 5.6 toolchains. Thanks!
I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain. I am downloading ELDK 5.6 toolchain to see what's going on there. IMHO, we should increase the iocon's U-Boot size to 512K. I see from its iocon.h file its flash size is 64MB, which has plenty of spaces to store a bigger U-Boot. Even if we try our best to rework this fdt patch, there is still possibility to break iocon sometime in the future by some other random fixes or new features. This to me is a tedious process.
I don't know why this is so hard to reproduce, I also see it with the debian/unstable gcc 5.x toolchain I do beleive.
+Simon,
Hi Tom,
On Mon, Jan 4, 2016 at 11:46 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 10:35:39AM +0800, Bin Meng wrote:
+Dirk
On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet() net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
Fabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-)
I think at this stage in the release we need to rework this and drop the fdt patches, or defer the whole thing until we can figure out some way to fit iocon in with the ELDK 5.6 toolchains. Thanks!
I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain. I am downloading ELDK 5.6 toolchain to see what's going on there. IMHO, we should increase the iocon's U-Boot size to 512K. I see from its iocon.h file its flash size is 64MB, which has plenty of spaces to store a bigger U-Boot. Even if we try our best to rework this fdt patch, there is still possibility to break iocon sometime in the future by some other random fixes or new features. This to me is a tedious process.
I don't know why this is so hard to reproduce, I also see it with the debian/unstable gcc 5.x toolchain I do beleive.
Still downloading ELDK toolchains so cannot comment ELDK compiler behavior :) One question, what's our recommended toolchains for U-Boot? I have been using kernel.org toolchains as mentioned in the buildman doc and some other ones mentioned in the moveconfig doc.
The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
Regards, Bin
On Mon, Jan 4, 2016 at 11:56 AM, Bin Meng bmeng.cn@gmail.com wrote:
+Simon,
Hi Tom,
On Mon, Jan 4, 2016 at 11:46 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 10:35:39AM +0800, Bin Meng wrote:
+Dirk
On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
A few patches that came in during the merge window and appear harmless.
These cause no additional build warnings or errors.
Thanks, -Joe
The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2015-12-18 07:28:24 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-net.git master
for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused (2015-12-21 20:01:57 -0600)
Bin Meng (5): fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet() fdt: Rewrite the logic in fdt_fixup_ethernet() net: e1000: Remove dead codes wrapped by #if 0 net: e1000: Remove CONFIG_MVBC_1G net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
Fabio Estevam (1): include: net: Simplify the usage of __always_inline
common/fdt_support.c | 64 ++++++++++++++++++++-------------------- drivers/net/e1000.c | 77 +------------------------------------------------ drivers/net/e1000.h | 31 -------------------- drivers/net/e1000_spi.c | 9 +++--- include/net.h | 9 +++--- 5 files changed, 42 insertions(+), 148 deletions(-)
I think at this stage in the release we need to rework this and drop the fdt patches, or defer the whole thing until we can figure out some way to fit iocon in with the ELDK 5.6 toolchains. Thanks!
I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain. I am downloading ELDK 5.6 toolchain to see what's going on there. IMHO, we should increase the iocon's U-Boot size to 512K. I see from its iocon.h file its flash size is 64MB, which has plenty of spaces to store a bigger U-Boot. Even if we try our best to rework this fdt patch, there is still possibility to break iocon sometime in the future by some other random fixes or new features. This to me is a tedious process.
I don't know why this is so hard to reproduce, I also see it with the debian/unstable gcc 5.x toolchain I do beleive.
Still downloading ELDK toolchains so cannot comment ELDK compiler behavior :) One question, what's our recommended toolchains for U-Boot? I have been using kernel.org toolchains as mentioned in the buildman doc and some other ones mentioned in the moveconfig doc.
The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
I am having a hard time installing ELDK 5.6 with eldk-5.6-powerpc-4xx.iso on a CentOS machine.
Firstly, I read the help by:
$ ./install.sh -h
Usage: install.sh [-D] [-d <dir>] [-a <arch>] [-s <sdk_img> ] [-r <rfs_img> ] [<target>] install.sh -l [<target>] install.sh -h -D: Dry-run: display commands, but don't actually execute them. -a: SDK host architecture. Chose one of 'i686' or 'x86_64". Defaults to "i686". -d: Destination directory. Defaults to "/opt/eldk-5.6" -h: Help: print this message. -l: List available SDK and RFS images -s: Select SDK image. Chose one of 'toolchain', 'toolchain-qte', 'toolchain-qte-xenomai', or '-' for none. Defaults to "toolchain". -r: Select list of target RFS images. Chose one or more of 'minimal', 'minimal-mtdutils', 'minimal-dev', 'minimal-xenomai', 'base', 'basic', 'clutter', 'lsb', 'lsb-dev', 'lsb-sdk', 'sato', 'sato-dev', 'sato-sdk', 'qte-sdk', 'qte-xenomai-sdk', 'x11', or '-' for none. Defaults to all.
<target> target architecture, defaults to "armv7a-hf"
Then I did:
$ ./install.sh -d /share/toolchain/eldk-5.6 -r - -a x86_64 powerpc-4xx Error: SDK image "gmae" is not available Available SDK images for target 'powerpc-4xx': <none>
Then I did:
$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a x86_64 powerpc-4xx Error: SDK image "toolchain" is not available Available SDK images for target 'powerpc-4xx': <none>
Nothing helpful was shown on the console until I figured it out I should pass '-a i686' :(
$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686 powerpc-4xx *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh into /share/toolchain/eldk-5.6/powerpc-4xx tar: ./sysroots: Cannot mkdir: Read-only file system tar: ./sysroots/ppc440e-linux: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/boot: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/bin: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/bin/.debug: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/lib: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/lib/.debug: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/lib/security: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/lib/security/.debug: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/lib/security/pam_filter: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/lib/security/pam_filter/.debug: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/pam.d: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/security: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/security/namespace.d: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/security/limits.d: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/default: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/default/volatiles: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/terminfo: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/terminfo/v: Cannot mkdir: No such file or directory tar: ./sysroots/ppc440e-linux/etc/terminfo/s: Cannot mkdir: No such file or directory <......>
Lots of 'Cannot mkdir: No such file or directory' message are shown on the console. I am pretty sure I have RW rights on the /share/toolchain/eldk-5.6 directory. Anything I am missing here?
Regards, Bin
On Mon, Jan 04, 2016 at 04:31:05PM +0800, Bin Meng wrote: [snip]
$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686 powerpc-4xx *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh into /share/toolchain/eldk-5.6/powerpc-4xx tar: ./sysroots: Cannot mkdir: Read-only file system
[snip]
Lots of 'Cannot mkdir: No such file or directory' message are shown on the console. I am pretty sure I have RW rights on the /share/toolchain/eldk-5.6 directory. Anything I am missing here?
Well, please confirm that you can write to /sysroots/ :) IIRC the installer doesn't invoke sudo by itself, btw..
Hi Tom,
On Mon, Jan 4, 2016 at 10:24 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 04:31:05PM +0800, Bin Meng wrote: [snip]
$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686 powerpc-4xx *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh into /share/toolchain/eldk-5.6/powerpc-4xx tar: ./sysroots: Cannot mkdir: Read-only file system
[snip]
Lots of 'Cannot mkdir: No such file or directory' message are shown on the console. I am pretty sure I have RW rights on the /share/toolchain/eldk-5.6 directory. Anything I am missing here?
Well, please confirm that you can write to /sysroots/ :) IIRC the installer doesn't invoke sudo by itself, btw..
The install.sh prompts ./sysroots/, not /sysroots/. ./sysroots/ should point to the installation root where I definitely have the write permission.
Today I switched to another machine with a Ubuntu 12.04, and with the same iso and command I installed ELDK successfully without any error message like "Cannot mkdir: Read-only file system". But when I used the ELDK toolchain to build U-Boot iocon, I got:
/buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd -m32 -melf32ppclinux -g -Ttext 0x40000 -o examples/standalone/hello_world -e hello_world examples/standalone/hello_world.o examples/standalone/libstubs.o -L . -lgcc /buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd: cannot find -lgcc make[2]: *** [examples/standalone/hello_world] Error 1 make[1]: *** [examples/standalone] Error 2 make: *** [examples] Error 2
It did not help whether I just source "environment-setup-ppc440e-linux" in the ELDK installation tree, or just simply "export CROSS_COMPILE=path/to/ELDK/toolchain" before building U-Boot.
Regards, Bin
On Tue, Jan 05, 2016 at 12:08:24PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:24 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 04:31:05PM +0800, Bin Meng wrote: [snip]
$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686 powerpc-4xx *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh into /share/toolchain/eldk-5.6/powerpc-4xx tar: ./sysroots: Cannot mkdir: Read-only file system
[snip]
Lots of 'Cannot mkdir: No such file or directory' message are shown on the console. I am pretty sure I have RW rights on the /share/toolchain/eldk-5.6 directory. Anything I am missing here?
Well, please confirm that you can write to /sysroots/ :) IIRC the installer doesn't invoke sudo by itself, btw..
The install.sh prompts ./sysroots/, not /sysroots/. ./sysroots/ should point to the installation root where I definitely have the write permission.
Today I switched to another machine with a Ubuntu 12.04, and with the same iso and command I installed ELDK successfully without any error message like "Cannot mkdir: Read-only file system". But when I used the ELDK toolchain to build U-Boot iocon, I got:
/buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd -m32 -melf32ppclinux -g -Ttext 0x40000 -o examples/standalone/hello_world -e hello_world examples/standalone/hello_world.o examples/standalone/libstubs.o -L . -lgcc /buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd: cannot find -lgcc make[2]: *** [examples/standalone/hello_world] Error 1 make[1]: *** [examples/standalone] Error 2 make: *** [examples] Error 2
It did not help whether I just source "environment-setup-ppc440e-linux" in the ELDK installation tree, or just simply "export CROSS_COMPILE=path/to/ELDK/toolchain" before building U-Boot.
I've never had a problem installing and using eldk-eglibc-i686-powerpc-toolchain-5.6.sh (or 5.5 and so on).
Hi Bin,
... The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
Updating partition layout in tens of thousands of devices in the field is not an option for us.
Cheers Dirk
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote:
Hi Bin,
... The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
I guess so.
Updating partition layout in tens of thousands of devices in the field is not an option for us.
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
Regards, Bin
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote:
Hi Bin,
... The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
I guess so.
Updating partition layout in tens of thousands of devices in the field is not an option for us.
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote:
Hi Bin,
... The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
I guess so.
Updating partition layout in tens of thousands of devices in the field is not an option for us.
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
Regards, Bin
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote:
Hi Bin,
... The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
I guess so.
Updating partition layout in tens of thousands of devices in the field is not an option for us.
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote:
Hi Bin,
... The simple fix is to change change iocon to a more larger size since it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
I guess so.
Updating partition layout in tens of thousands of devices in the field is not an option for us.
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
Do anyone volunteer to do this "splitting up common/fdt_support.c into logical chunks"? I still cannot make ELDK work in my env thus cannot make any further investigation :(
Regards, Bin
On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote:
Hi Bin,
> ... > The simple fix is to change change iocon to a more larger size since > it has a 64MB flash. Dirk, can you please comment?
The problem is the flash partition layout, coming from a time where u-boot was an order of magnitude smaller :)
I guess so.
Updating partition layout in tens of thousands of devices in the field is not an option for us.
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
Do anyone volunteer to do this "splitting up common/fdt_support.c into logical chunks"? I still cannot make ELDK work in my env thus cannot make any further investigation :(
I'll put it on my TODO list. I'll leave ELDK support up to the denx folks.
Hi Tom,
On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
Hi Dirk,
On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote: > Hi Bin, > >> ... >> The simple fix is to change change iocon to a more larger size since >> it has a 64MB flash. Dirk, can you please comment? > > The problem is the flash partition layout, coming from a time where > u-boot was an order of magnitude smaller :) >
I guess so.
> Updating partition layout in tens of thousands of devices in the field > is not an option for us. >
I suspect 256KB won't fit anyway, if trying to make use of these new U-Boot features,eg: using driver model adds some more footprints too. So in your deployment, you just upgrade those devices in the field to latest U-Boot (new version) but not changing partition layout, for fix only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
Do anyone volunteer to do this "splitting up common/fdt_support.c into logical chunks"? I still cannot make ELDK work in my env thus cannot make any further investigation :(
I'll put it on my TODO list. I'll leave ELDK support up to the denx folks.
Maybe Bin can make a patch to disable Ethernet on iocon and apply before the fdt patch? Or would we rather wait on this until you rework the fdt_support? Or just rebase this pr and apply as is?
Thanks, -Joe
On Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote:
Hi Tom,
On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote: > Hi Dirk, > > On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote: > > Hi Bin, > > > >> ... > >> The simple fix is to change change iocon to a more larger size since > >> it has a 64MB flash. Dirk, can you please comment? > > > > The problem is the flash partition layout, coming from a time where > > u-boot was an order of magnitude smaller :) > > > > I guess so. > > > Updating partition layout in tens of thousands of devices in the field > > is not an option for us. > > > > I suspect 256KB won't fit anyway, if trying to make use of these new > U-Boot features,eg: using driver model adds some more footprints too. > So in your deployment, you just upgrade those devices in the field to > latest U-Boot (new version) but not changing partition layout, for fix > only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
Do anyone volunteer to do this "splitting up common/fdt_support.c into logical chunks"? I still cannot make ELDK work in my env thus cannot make any further investigation :(
I'll put it on my TODO list. I'll leave ELDK support up to the denx folks.
Maybe Bin can make a patch to disable Ethernet on iocon and apply before the fdt patch? Or would we rather wait on this until you rework the fdt_support? Or just rebase this pr and apply as is?
So, ELDK 5.3 requires a lot of lifting to get the size down to linking (and in fact fails locally either way). I did a bunch of easy non-FDT trimming now, let me see if that gets the -net PR linking still and work from there.
On Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote:
Hi Tom,
On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote: > Hi Dirk, > > On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote: > > Hi Bin, > > > >> ... > >> The simple fix is to change change iocon to a more larger size since > >> it has a 64MB flash. Dirk, can you please comment? > > > > The problem is the flash partition layout, coming from a time where > > u-boot was an order of magnitude smaller :) > > > > I guess so. > > > Updating partition layout in tens of thousands of devices in the field > > is not an option for us. > > > > I suspect 256KB won't fit anyway, if trying to make use of these new > U-Boot features,eg: using driver model adds some more footprints too. > So in your deployment, you just upgrade those devices in the field to > latest U-Boot (new version) but not changing partition layout, for fix > only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
Do anyone volunteer to do this "splitting up common/fdt_support.c into logical chunks"? I still cannot make ELDK work in my env thus cannot make any further investigation :(
I'll put it on my TODO list. I'll leave ELDK support up to the denx folks.
Maybe Bin can make a patch to disable Ethernet on iocon and apply before the fdt patch? Or would we rather wait on this until you rework the fdt_support? Or just rebase this pr and apply as is?
So, just the hush.c patch is enough now, I'll take that and the current PR. I'll also post as patches some of what I've done locally.
On Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote:
Hi Tom,
On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote: > Hi Dirk, > > On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach dirk.eibach@gdsys.cc wrote: > > Hi Bin, > > > >> ... > >> The simple fix is to change change iocon to a more larger size since > >> it has a 64MB flash. Dirk, can you please comment? > > > > The problem is the flash partition layout, coming from a time where > > u-boot was an order of magnitude smaller :) > > > > I guess so. > > > Updating partition layout in tens of thousands of devices in the field > > is not an option for us. > > > > I suspect 256KB won't fit anyway, if trying to make use of these new > U-Boot features,eg: using driver model adds some more footprints too. > So in your deployment, you just upgrade those devices in the field to > latest U-Boot (new version) but not changing partition layout, for fix > only?
I'm not convinced that we shouldn't be able to be useful in 256KB. Sure, a kitchen-sink EVM + config will be large but iocon is a defined production type config. If we can't make this work, I'm going to be worried. I've already gotten some aside pokes about making U-Boot shrink down when you turn stuff off.
I want to cycle back to saying that we need to look at ways to work-around the gcc issue that's keeping a bunch of unused strings in the resulting binary.
So, what's our best way to do with this PR? I am worried that since this iocon board is already at an edge, any ramdom bug fix (to common codes) in the future could be the next victim.
For this PR, I think we need to push the fdt patch in question out and for the next release look at splitting up common/fdt_support.c into logical chunks.
Do anyone volunteer to do this "splitting up common/fdt_support.c into logical chunks"? I still cannot make ELDK work in my env thus cannot make any further investigation :(
I'll put it on my TODO list. I'll leave ELDK support up to the denx folks.
Maybe Bin can make a patch to disable Ethernet on iocon and apply before the fdt patch? Or would we rather wait on this until you rework the fdt_support? Or just rebase this pr and apply as is?
Applied to u-boot/master, thanks!
On Mon, Jan 04, 2016 at 11:56:34AM +0800, Bin Meng wrote:
[snip]
Still downloading ELDK toolchains so cannot comment ELDK compiler behavior :) One question, what's our recommended toolchains for U-Boot? I have been using kernel.org toolchains as mentioned in the buildman doc and some other ones mentioned in the moveconfig doc.
Well, the way I look at it we have two answers: 1) In general, any sane for your architecture gcc 4.x or later should work. I'm not going to test every possible combination here but maintainers (who might have less visible needs like hey, our product uses toolchain X, so I need to use it) may also say their board needs to work with toolchain X. 2) To me, ELDK current release, current kernel.org toolchains and current commodity distro (Debian, Fedora, SuSE, etc) toolchains should work too.
I personally use ELDK 5.6 or PowerPC and MIPS, kernel.org for most everything else and Debian 8 arm-none-eabi (gcc 4.8.x) as that does both armv7 and armv7m, and then Debian/Unstable gcc 5.x for x86/aarch64/arm/sandbox/powerpc.
participants (4)
-
Bin Meng -
Dirk Eibach -
Joe Hershberger -
Tom Rini