* Ben Hutchings [2013-07-16 01:42]:
> I heard a lot of support for keeping iop32x, but no-one volunteereed to
> maintain the configuration. Unless someone does so, the next time they
> fail to build due to lack of space I may simply disable them. That does
> not, of course, prevent anyone from r
linux version 3.10.3-1 failed to build on armel, as the iop32x image
grew just over the limit.
As you volunteered to try maintaining the configuration changes for the
size-limited armel flavours, please can you try to find a configuration
change that will bring iop32x within the limit (also checki
On Mon, 2013-06-24 at 23:44 +0100, Ben Hutchings wrote:
> We have a recurring problem with building kernels for armel: three
> flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be
> less than 1.4-1.5 MB in order to fit into a fixed flash partition.
>
> As more features continue t
Ben Hutchings wrote:
The other option that has been suggested repeatedly is to put armel
chroots on ARMv7 hardware. Unaligned accesses behave differently on
v7, but they weren't consistent between different v5 implementations
(http://www.heyrick.co.uk/armwiki/Unaligned_data_access) so I don't
th
Hello,
2013/6/27 Ben Hutchings :
> On Wed, Jun 26, 2013 at 04:39:15PM +0100, Ben Hutchings wrote:
>> On Wed, Jun 26, 2013 at 03:13:48PM +0200, Arnaud Patard wrote:
>> > Ben Hutchings writes:
>> > btw, iop32x is used on n2100 which are used on buildd/porter boxes. If
>> > we stop supporting it, I
On Wed, Jun 26, 2013 at 04:39:15PM +0100, Ben Hutchings wrote:
> On Wed, Jun 26, 2013 at 03:13:48PM +0200, Arnaud Patard wrote:
> > Ben Hutchings writes:
> >
> > > We have a recurring problem with building kernels for armel: three
> > > flavours (iop32x, ixp4xx, orion5x) require the kernel image
On Wed, Jun 26, 2013 at 03:13:48PM +0200, Arnaud Patard wrote:
> Ben Hutchings writes:
>
> > We have a recurring problem with building kernels for armel: three
> > flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be
> > less than 1.4-1.5 MB in order to fit into a fixed flash pa
Ben Hutchings writes:
> We have a recurring problem with building kernels for armel: three
> flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be
> less than 1.4-1.5 MB in order to fit into a fixed flash partition.
>
> As more features continue to be added to Linux and cannot al
+1 for maintaining iop32xx support. I bought and use one for debian
development and offer it as a service to open-source developers.
Keeping it running with standard stable and sid is essential to this.
I also remember nslu2 being the whizzo machine for hackers
On 25 June 2013 04:05, Chris Wilkin
On Tue, Jun 25, 2013 at 4:05 AM, Chris Wilkinson wrote:
> I increased the kernel zimage flash available to 4mb on an Intel SS4000E
> (iop32x) by reconfiguring the flash with fconfig, deleting the unused parts
> used by the stock firmware. This enabled me to upgrade the kernel to v3.2.
>
> This doe
I increased the kernel zimage flash available to 4mb on an Intel SS4000E
(iop32x) by reconfiguring the flash with fconfig, deleting the unused parts
used by the stock firmware. This enabled me to upgrade the kernel to v3.2.
This does need serial console access as Ben says but that is true whatev
On Mon, Jun 24, 2013 at 11:44:42PM +0100, Ben Hutchings wrote:
> We have a recurring problem with building kernels for armel: three
> flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be
> less than 1.4-1.5 MB in order to fit into a fixed flash partition.
At least on Thecus N2100
I don't think anyone is going to greatly miss support for the nslu2.
It can no longer be installed using d-i anyway. I imagine most of the
deployments where it makes sense to still be using a nslu2 are ones
where running an old kernel version doesn't much matter.
The iop32x boxes are rather more e
On Tue, 2013-06-25 at 00:26 +0100, Ben Hutchings wrote:
[...]
> I think it may just be a
> case of adding the right ID numbers and block sizes to the existing
> Spansion SPI flash driver, though. I have a datasheet for the flash
> chip, if anyone's interested.
Sorry, not sure I thought that. The
On Mon, 2013-06-24 at 23:44 +0100, Ben Hutchings wrote:
[...]
> Perhaps [the DNS-323] could be supported by
> putting a second stage uboot in flash which would load the kernel and
> initramfs from disk, as suggested in [3]?
[...]
> [3] http://dns323.kood.org/howto:uboot
Alternately it could load a
We have a recurring problem with building kernels for armel: three
flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be
less than 1.4-1.5 MB in order to fit into a fixed flash partition.
As more features continue to be added to Linux and cannot always
configurable as a module, it
16 matches
Mail list logo
