* Ben Hutchings b...@decadent.org.uk [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,
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 to be
Am 11.07.2013 13:26, schrieb Hector Oron:
There is one, alain, but armel is quite busy architecture as it
takes its time to build stuff. I look forward to add more support
for -backports.
Fwiw, I have yet another QNAP TS-412 around somewhere that could run
24/7 to build stuff... Though I am
Hello,
2013/7/5 Ansgar Burchardt ans...@debian.org:
[ Please CC me in replies. I'm not subscribed to the list. ]
On 06/27/2013 19:22, Ben Hutchings wrote:
On Wed, Jun 26, 2013 at 04:39:15PM +0100, Ben Hutchings wrote:
Bet they're slower than QEMU versatile emulation on an x86. And DSA
Hi,
[ Please CC me in replies. I'm not subscribed to the list. ]
On 06/27/2013 19:22, Ben Hutchings wrote:
On Wed, Jun 26, 2013 at 04:39:15PM +0100, Ben Hutchings wrote:
Bet they're slower than QEMU versatile emulation on an x86. And DSA
loves virtual machines. :-)
This speed comparison
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
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 b...@decadent.org.uk writes:
We have a recurring problem with building kernels for armel: three
flavours (iop32x, ixp4xx, orion5x) require the
Hello,
2013/6/27 Ben Hutchings b...@decadent.org.uk:
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 b...@decadent.org.uk writes:
btw, iop32x is used on n2100 which are used on buildd/porter boxes.
+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
Martin Guy wrote:
+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
Has anybody
Dropping support for nslu2 is fine with me. As noted above, I can continue
running it with an older kernel and be equally happy. Or I could retire it
and get (another) rpi.
What would be (a little) worse for me though is dropping orion5 support. I
rely on security updates for my ts-209. OTOH, by
On Wed, Jun 26, 2013, Mark Morgan Lloyd wrote:
Has anybody investigated using something like OpenFirmware as an
intermediate boot loader? If that were in internal Flash then it
should be possible to load the kernel from external storage-
Yeah; I didn't have time to try it out, but there's also
On Wed, Jun 26, 2013 at 02:08:19PM +0200, Loïc Minier wrote:
On Wed, Jun 26, 2013, Mark Morgan Lloyd wrote:
Has anybody investigated using something like OpenFirmware as an
intermediate boot loader? If that were in internal Flash then it
should be possible to load the kernel from external
* Björn Wetterbom bj...@wetterbom.se [2013-06-26 13:28]:
What would be (a little) worse for me though is dropping orion5 support. I
rely on security updates for my ts-209. OTOH, by 2016 it may well be ready
to be replaced by something faster.
Ben didn't propose dropping Orion altogether -- it
Ben Hutchings b...@decadent.org.uk 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
On Wed, Jun 26, 2013 at 03:13:48PM +0200, Arnaud Patard wrote:
Ben Hutchings b...@decadent.org.uk 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
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
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, 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 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
20 matches
Mail list logo
