Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Gaudenz Steinlin]

Vagrant Cascadian  writes:

> [ Unknown signature status ]
> On 2016-04-24, Rick Thomas wrote:
>> Any chance I could download a pre-built binary?
>
> Just uploaded u-boot 2016.05-rc2 packages to:
>
>   deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
>
> The u-boot-imx package there worked on my cubox-i4x4, but will almost
> certainly hang on a cubox-i4pro. It also doesn't seem to boot with
> firefly-4gb variant. Too experimental for Debian experimental...
>
>

I have the same problem with my Cubox-i 4x4. Is there any progress on
this? The version of u-boot mentioned above is no longer available. Are
the patches incorporated into the latest version in experimental?

Is there anything I could test to get this into Debian?

Gaudenz

Help need with build failure of ceph 10.2.5-2 on armel

[Gaudenz Steinlin]

Hi

The build of the most recent version of ceph fails on armel[1]. As far
as I understand the log, the first failure (a bit above the end of the
log) is because armel does not support NEON (-mfpu=neon) despite the
configure check for this succeeding.

The autotools based build system uses the following check:
AX_CHECK_COMPILE_FLAG(-mfpu=neon, ax_cv_support_neon_ext=yes, [])

Is it correct that for armel NEON has to be disabled or this there a way
to support NEON instructions on armel? And how could I fix the above
test to correctly disable NEON for armel.

AFAICS the build failure appears if a source file uses
"#include ".

AFAIU the build tries to build a plugin with NEON instructions to be
used depending on runtime detection.

Thanks,
Gaudenz

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ceph&arch=armel&ver=10.2.5-2&stamp=1482596609
-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Re: [Ceph-maintainers] Bug#850906: ceph FTBFS on armel, libtool/linker related issues.

[Gaudenz Steinlin]

peter green  writes:

> Package: ceph
> Version: 10.2.5-5
> Severity: serious
> x-debbugs-cc: debian-arm@lists.debian.org
>
> The most recent upload of ceph fixed the build on most architectures but 
> unfortunately armel is still failing.
>
> libtool: relink: g++  -fPIC -DPIC -shared -nostdlib 
> /usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi/crti.o 
> /usr/lib/gcc/arm-linux-gnueabi/6/crtbeginS.o  
> java/native/.libs/libcephfs_jni_la-libcephfs_jni.o 
> java/native/.libs/libcephfs_jni_la-JniConstants.o  -Wl,--whole-archive 
> ./.libs/libcommon.a -Wl,--no-whole-archive  -Wl,--as-needed 
> -L/«PKGBUILDDIR»/debian/tmp/usr/lib/arm-linux-gnueabi 
> -L/usr/lib/arm-linux-gnueabi -lcephfs -ldl -lboost_thread -lboost_random 
> -lblkid -luuid -lrt -lboost_iostreams -lboost_system 
> -L/usr/lib/gcc/arm-linux-gnueabi/6 
> -L/usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi 
> -L/usr/lib/gcc/arm-linux-gnueabi/6/../../.. -L/lib/arm-linux-gnueabi -lstdc++ 
> -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnueabi/6/crtendS.o 
> /usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi/crtn.o  -O2 -g 
> -fstack-protector-strong -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro 
> -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now   -Wl,-soname 
> -Wl,libcephfs_jni.so.1 -o .libs/libcephfs_jni.so.1.0.0
> /usr/bin/ld: 
> /«PKGBUILDDIR»/debian/tmp/usr/lib/arm-linux-gnueabi/libcephfs.so: invalid 
> string offset 50471 >= 3194 for section `.strtab'
> <--snip-->
> libtool: warning: remember to run 'libtool --finish 
> /usr/lib/arm-linux-gnueabi'
> make[5]: Leaving directory '/«PKGBUILDDIR»/src'
> Makefile:32173: recipe for target 'install-am' failed
> make[4]: *** [install-am] Error 2
> make[4]: Leaving directory '/«PKGBUILDDIR»/src'
> Makefile:30865: recipe for target 'install-recursive' failed
> make[3]: *** [install-recursive] Error 1
> make[3]: Leaving directory '/«PKGBUILDDIR»/src'
> Makefile:32167: recipe for target 'install' failed
> make[2]: *** [install] Error 2
> make[2]: Leaving directory '/«PKGBUILDDIR»/src'
> Makefile:703: recipe for target 'install-recursive' failed
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory '/«PKGBUILDDIR»'
> dh_auto_install: make -j4 install DESTDIR=/«PKGBUILDDIR»/debian/tmp 
> AM_UPDATE_INFO_DIR=no returned exit code 2
> debian/rules:73: recipe for target 'binary-arch' failed
>
> This seems like a rather strange error, putting debian-arm in cc in
> case anyone there has any ideas.

I have seen these warnings (invalid string offset 50471 >= 3194 for
section `.strtab') too. I don't know what causes them and if they are
serious.

But the actual build failure is somewhere else further up in the log. It
has to do with running make install in parallel. If I disable parallel
execution for the dh_auto_install step, the package builds fine at least
on the armel porterbox. I'll do another upload with this fix.

Gaudenz
-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Re: XFS is unsafe (Was: Re: d-i does not show jfs in partition tool)

[Gaudenz Steinlin]

Hi

On Wed, Aug 27, 2008 at 10:02:57AM +0200, Tobias Frost wrote:
> So now I have a image prepared, which I can upload somewhere on 
> request. (approx 26 MB gziped)
> 
> As building the image, I had the impression that the corruption occured
> when I deleted some files.
> 
> Can someone please try the xfs on their machines, I'd like to verify
> this and maybe report the problem to the xfs authors (or to the LKML)

I can confirm the corruption also happens on my Thecus N2100 running kernel 
2.6.24
with the DMA patches from Dan Williams. 

I've noticed that some XFS fixes got into 2.6.27-rc4. Martin built some Debian
packages of this kernel version, but only for armel. I'm still running arm 
unfortunately.

Gaudenz

> 
> --
> coldtobi
> http://blog.coldtobi.de
> 
> On Tue, 2008-08-26 at 11:19 +0200, Tobias Frost wrote:
> > So, part copied and did some testing... I'll attach a transcipt.
> > 
> > Abstract: This time xfs_repair did not fail, but the corruption 
> > reoccured immediatly.
> > 
> > I will prepare a test-image of the partition, if someone is interested.
> > (I just have to nullify the swap before.)
> > 



-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: XFS is unsafe (Was: Re: d-i does not show jfs in partition tool)

[Gaudenz Steinlin]

On Wed, Aug 27, 2008 at 01:19:13PM +0300, Martin Michlmayr wrote:
> * Gaudenz Steinlin <[EMAIL PROTECTED]> [2008-08-27 11:56]:
> > I can confirm the corruption also happens on my Thecus N2100 running kernel 
> > 2.6.24
> > with the DMA patches from Dan Williams. 
> > 
> > I've noticed that some XFS fixes got into 2.6.27-rc4. Martin built some 
> > Debian
> > packages of this kernel version, but only for armel. I'm still running arm 
> > unfortunately.
> 
> The ARM XFS fix that got into 2.6.27 is also in our 2.6.26 kernel.
> However, if you want to try 2.6.27-rc4, I can build it for arm.

I tested with 2.6.26-3 from unstable. I also get the corruption with 
this kernel. Are you sure that everything that went into 2.6.27 is also in
the Debian kernel? If not, could you build an image for arm?

Tobias: Are you running arm or armel? The XFS on arm bug referenced in the 
kernel changelog suggests that at least some parts of the problem may be 
arm specific. Did anyone test on armel?

Gaudenz 
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: XFS is unsafe (Was: Re: d-i does not show jfs in partition tool)

[Gaudenz Steinlin]

On Wed, Aug 27, 2008 at 06:08:24PM +0300, Martin Michlmayr wrote:
> * Gaudenz Steinlin <[EMAIL PROTECTED]> [2008-08-27 17:05]:
> > > The ARM XFS fix that got into 2.6.27 is also in our 2.6.26 kernel.
> > > However, if you want to try 2.6.27-rc4, I can build it for arm.
> > 
> > I tested with 2.6.26-3 from unstable. I also get the corruption with 
> > this kernel. Are you sure that everything that went into 2.6.27 is also in
> > the Debian kernel?
> 
> Not everything, only the ARM fix.
> 
> > If not, could you build an image for arm?
> 
> http://newpeople.debian.org/~tbm/arm/kernel/r12144/

OK, I tested with this kernel as well and still got the fs corruption. This is
what I did:

- mkfs.xfs (on a 100GB LV)
- mount it
- download and unpack the kernel sources -> no error
- cp -ar linux-2.6.27-rc4 linux -> errors from cp
- rm -r linux -> no errors from rm
- umount
- mount again -> unable to mount the partition
- xfs_repair -L -> lots of errors 

This is with 2.6.27-rc4 and xfsprogs 2.8.11 on arm oldabi.

This is part of the relevant dmesg output (there are a ton more similar errors):
[ 1188.45] : 58 46 53 42 00 00 10 00 00 00 00 00 01 90 00 00  
XFSB
[ 1188.46] Filesystem "dm-6": XFS internal error xfs_da_do_buf(2) at line 
2107 of file fs/xfs/xfs_da_btree.c.  Caller 0xbf246590
[ 1188.48] [] (dump_stack+0x0/0x14) from [] 
(xfs_error_report+0x4c/0x5c [xfs])
[ 1188.48] [] (xfs_error_report+0x0/0x5c [xfs]) from [] 
(xfs_corruption_error+0x5c/0x68 [xfs])
[ 1188.49]  r4:df2fdc00
[ 1188.50] [] (xfs_corruption_error+0x0/0x68 [xfs]) from 
[] (xfs_da_do_buf+0x5e8/0x6ec [xfs])
[ 1188.51]  r6:bf246590 r5: r4:c5875438
[ 1188.51] [] (xfs_da_do_buf+0x0/0x6ec [xfs]) from [] 
(xfs_da_read_buf+0x3c/0x44 [xfs])
[ 1188.52] [] (xfs_da_read_buf+0x4/0x44 [xfs]) from [] 
(xfs_dir2_leaf_getdents+0x498/0x898 [xfs])
[ 1188.54] [] (xfs_dir2_leaf_getdents+0x0/0x898 [xfs]) from 
[] (xfs_readdir+0xcc/0xe0 [xfs])
[ 1188.55] [] (xfs_readdir+0x0/0xe0 [xfs]) from [] 
(xfs_file_readdir+0x164/0x1c8 [xfs])
[ 1188.56] [] (xfs_file_readdir+0x0/0x1c8 [xfs]) from 
[] (vfs_readdir+0x84/0xb8)
[ 1188.57] [] (vfs_readdir+0x0/0xb8) from [] 
(sys_getdents64+0x6c/0xc0)
[ 1188.58] [] (sys_getdents64+0x0/0xc0) from [] 
(ret_fast_syscall+0x0/0x3c)
[ 1188.59]  r7:00d9 r6:4015806c r5:0001 r4:0003fad0
[ 3466.94] Filesystem "dm-6": Disabling barriers, trial barrier write failed
[ 3466.97] XFS mounting filesystem dm-6
[ 3467.22] Starting XFS recovery on filesystem: dm-6 (logdev: internal)
[ 3467.23] XFS: xlog_recover_process_data: bad clientid
[ 3467.24] XFS: log mount/recovery failed: error 5
[ 3467.24] XFS: log mount failed

Please tell me if you want me to do more testing or if you need additional 
debugging output. If you need it, I can also upload an image of the corrpted
filesystem somewhere.

Tobi: Are you going to take this upstream to the XFS devels or linux-kernel? 

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Ralink

[Gaudenz Steinlin]

On Fri, Aug 29, 2008 at 10:54:32AM +0200, Xan wrote:
> Hi,
>
> I have attached to slug a hub of 4 ports and in one port I plug a net  
> usb key.
> This key has ralink driver
>
> kernel detects it (you can show that in dmesg), but it does not put any  
> interface (I have only eth0 and lo).
>
> What can I do for having interface present in ifconfig?
> Please, step by step. I'm a begginer.
> I want to use rt2x00 instead of old rt2570 driver

How did you determine that there is now interface? Most probably the interface
is still down and therefore does not show with ifconfig. Try 'ifconfig -a' 
to see all interfaces.

If the interface show up with 'ifconfig -a' you have to issue 'ifconfig xxx up' 
to start scanning for wireless networks.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Ralink

[Gaudenz Steinlin]

On Fri, Aug 29, 2008 at 03:33:48PM +0200, Xan wrote:
> En/na Gaudenz Steinlin ha escrit:
> Okay. Thanks.
> With ifconfig -a, it appears. But I have two new interfaces. How can I  
> see what modules use any of these?
>
> ifconfig -a  eth0  Link encap:Ethernet  HWaddr 00:18:39:8a:77:7e  
> inet addr:172.26.0.2  Bcast:172.26.255.255  Mask:255.255.0.0
>  inet6 addr: fe80::218:39ff:fe8a:777e/64 Scope:Link
>  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  RX packets:1298 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:1015 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:100
>  RX bytes:98030 (95.7 KiB)  TX bytes:218310 (213.1 KiB)
>
> loLink encap:Local Loopback  inet addr:127.0.0.1  
> Mask:255.0.0.0
>  inet6 addr: ::1/128 Scope:Host
>  UP LOOPBACK RUNNING  MTU:16436  Metric:1
>  RX packets:8 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:0
>  RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)
>
> wlan0 Link encap:Ethernet  HWaddr 00:80:5a:4e:29:3d  
> BROADCAST MULTICAST  MTU:1500  Metric:1
>  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000
>  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)a

This is the wireless interface. You have to use this one for all
operations.

>
> wmaster0  Link encap:UNSPEC  HWaddr  
> 00-80-5A-4E-29-3D-02-00-00-00-00-00-00-00-00-00  BROADCAST 
> MULTICAST  MTU:1500  Metric:1
>  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000
>  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> What is ralink: wmaster0 or wlan0. Why I have two new interfaces?

The wmaster0 interface is an internal interface created by the linux
wireless stack. Just ignore it for all normal operations. 

Gaudenz

>
> Thanks a lot,
> Xan.
>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mail (local mail)

[Gaudenz Steinlin]

Hi Xan

On Fri, Aug 29, 2008 at 04:24:29PM +0200, Xan wrote:
> Hi,
>
> Recently I drop exim4 packages (# apt-get remove exim4 exim4-base  
> exim4-config exim4-daemon-light) and so it removes "at" and "bsd-mailx".
>
> Now I haven't mail.
> But I want having mail for simply:
> - read /var/mail
> - when I login, shell says me "you have a mail" and I can run "mail" 
> or similar program
> - I can send local mails (from [EMAIL PROTECTED] to [EMAIL PROTECTED], 
> etc.)
>
> What program fits into my needs (without reinstalling exim4, postfix or  
> equivalents)?
> Does anyone know it?

exim4-daemon-light would be one option. There are several others. Try 
'apt-cache search mail-transport-agent' to list them.

This question and also your previous question about the wireless interface
are not really specific to the arm port. Please ask further such questions
on [EMAIL PROTECTED] where they are more on topic. This list is
primarily for arm specific problems and the development of the Debian arm 
port.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: XFS filesystem corruption on the arm(el) architecture

[Gaudenz Steinlin]

On Fri, Oct 17, 2008 at 09:01:09AM +0200, Martin Michlmayr wrote:
> * Eric Sandeen <[EMAIL PROTECTED]> [2008-10-16 17:13]:
> > So is this a regression?  did it used to work?  If so, when? :)
> 
> The original report was with 2.6.18 but that was with the old ABI:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423562
> I just installed a 2.6.22 kernel with EABI and I can also trigger
> the bug.  So it's not a (recent) regression.

As far as I can remember (I only used old ABI arm) this is not a 
regression. XFS never worked on arm for me.

If you need tests on old ABI just tell me.

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: versatile architecture image suitable for qemu usage?

[Gaudenz Steinlin]

Hi 

On Thu, Jan 08, 2009 at 11:35:22PM +0900, Junichi Uekawa wrote:
> Hi,
> 
> 
> I tried to test qemubuilder armel support and realized that I don't
> have the latest kernel.
> 
> initrd isn't distributed inside a package, and I don't think there's a 
> kernel which doesn't work without a initrd.
> 
> Is there a kernel which contains minimal support for ext2/3 and/or
> initrd which contains them ? (and supports parsing init= kernel
> command-line option).

I'm not sure if I correctly understand what you are trying to do. I
suppose this is about bootstrapping the qemu image with quemubuilder,
correct? So this is basically an initrd bootstrapping issue.

I don't know how quemubuilder works internally and how you solved this
problem for other architectures. But I think you will have this problem
on any architecture and don't see why this is arm specific. 
For a generic solution I see either useing debootstrap with the procedure
outlined in http://wiki.debian.org/EmDebian/CrossDebootstrap or useing a
fully preseeded debian-installer.

The debootstrap option does unfortunately not work with plain Debian.
There are bugs and patches available though. Perhaps it's worth
polishing and pushing them. 

A third option would be to use the classical two stage debootstrap
process with --foreign and --second-stage. But this has the problem on
how to launch an initial system to execute the native second-stage.
Perhaps you could script the debian-installer rescue mode to do this.
I'm not sure though if this is possible.

Gaudenz


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Odd ownership of files in tarball [Re: Debian 5.0 (lenny) tar ball for the SheevaPlug - USB install]

[Gaudenz Steinlin]

On Mon, May 18, 2009 at 08:28:03PM -0400, Rick Thomas wrote:
>
> On May 8, 2009, at 11:09 AM, Rick Thomas wrote:
>
>> Cool!
>>
>> My first shivaplug arrived this morning.
>
> It's now installed and doing useful work.  A fairly painless process -- 
> thanks very much for the step-by-step instructions, Martin!  I doubt if I 
> could have done it myself with just the instructions from Marvell.
>
> I've stumbled across an anomaly in the tarball that I thought I should  
> report.
>
> The groups for some of the files in the tarball don't correspond to  
> those in a working system.  Enclosed is a diff of everything  that I've 
> noticed...

How exactly did you produce this diff? If you extract the tarball on
another system and then produced the diff on this system, then this is
just expected. The tarball only stores numerical ids and the displayed
names correspond to the names for these ids on the running system.
Numerical ids are not garantueed to be the same accross different Debian
installations.

Check if the the permissons are also wrong if you actually boot the system
on your plug or if you chroot into the directory of the unpacked
tarball.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: Digital signature

Re: arm port plans for the squeeze cycle

[Gaudenz Steinlin]

Hi

On Tue, Aug 18, 2009 at 08:27:32AM -1000, Martin Michlmayr wrote:
> * Marc Brockschmidt  [2009-08-16 14:40]:
> > Do you have any big changes planned? How much time would they take, and
> > what consequences are there for the rest of the project?
> > 
> > How many "big" transitions will the upcoming changes cause? When should 
> > those
> > happen? Can we do something to make them easier?
> 
> Do we have anything to report here?  IMHO, any release date will work
> fine for the ARM port since there are no major issues or transitions.

Support for the openmoko could be a goal. But we probably need at least
2.6.32 to have a bootable kernel which supports SD cards. The 2.6.31
upcomming 2.6.31 will contain basic support up to the point where the
kernel boots on the phone, but the glamo driver to which the sd reader
is connected is not yet sent upstream.

If we have basic kernel support (including sd cards) debian-installer
support is fairly easy to do. It's basically almost done.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: Digital signature

Re: arm port plans for the squeeze cycle

[Gaudenz Steinlin]

On Wed, Aug 19, 2009 at 02:34:35PM +0200, Frans Pop wrote:
> Riku Voipio wrote:
> > As mentioned elsewhere on the thread, the biggest deal is getting
> > openmoko supprted. But I believe it's more of a kernel and d-i team
> > issue than ARM port issue.
> 
> Eh, support for new hardware is not implemented by the D-I team, but by 
> porters. Of course, we welcome porters to be active in the D-I team, but 
> don't expect support for new hardware to magically appear.
> 
> (But I think you already know that and it was just a case of unfortunate 
> wording.)

Yeah, and that's what's actually happening. Luca and I are currently
working on the Openmoko stuff, but we of course welcome others to help.
BTW I would consider myself more as a d-i team member than an arm
porter..., but I don't think this really matters.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


signature.asc
Description: Digital signature

Re: arm, both disk able to boot (raid1)

[Gaudenz Steinlin]

"rosea.grammostola"  writes:

> Hi,
>
> When the 1st raid disk (which is able to boot) fails, an other method to 
> restore the system might be to mount the 2nd disk (which isn't able to 
> boot), on the laptop and make it able to boot via chroot right?

There is no need for this as there is no such thing as a "boot sector"
with an equivalent of grub on ARM. The uboot bootloader directly
loads the kernel and initrd from internal flash memory on the device.
The kernel and initrd are written there by a utility called
"flash-kernel". So you don't have to make your drives bootable like on
x86.

The initial ramdisk should assemble your software raid just fine even if
one disk failed.

Gaudenz

>
> Regards
>
> On 10/10/2012 01:03 PM, Björn Wetterbom wrote:
>> That's the one.
>>
>> /B
>>
>> On Wed, Oct 10, 2012 at 12:59 PM, rosea.grammostola
>> mailto:rosea.grammost...@gmail.com>> wrote:
>>
>> On 10/10/2012 12:26 PM, Björn Wetterbom wrote:
>>
>> http://www.cyrius.com/debian/__orion/qnap/ts-209/
>> 
>>
>>
>> Thx. Hmm ok so I need this hardware to connect the qnap to my laptop?
>> 
>> http://apple.clickandbuild.__com/cnb/shop/ftdichip?__productID=53&op=catalogue-__product_info-null&__prodCategoryID=47
>> 
>> 
>>
>> On Wed, Oct 10, 2012 at 11:46 AM, rosea.grammostola
>> > 
>> > >> wrote:
>>
>>  On 10/10/2012 11:07 AM, Björn Wetterbom wrote:
>>
>>  I have a raid1 setup on my ts-209 (from the original
>> install).
>>  See my
>>  fstab below.
>>
>>  If your raid1 setup is done, just update your fstab and run
>> "update-initramfs -u && flash-kernel" to update the initramfs
>>  with the
>>  new fstab and install the initramfs to flash. I'd
>> advice you to
>>  have a
>>  serial console in case something goes wrong.
>>
>>
>>  Thanks. I've no experience with a serial console. Tutorials
>> on the
>>  web seems to edit also the grub files, which aren't on this
>> ARM install.
>>  What should be done different on a ARM in comparison with this
>>  method for instance?
>> 
>> http://www.cyberciti.biz/faq/howto-setup-serial-console-__on-__debian-linux/
>> 
>> 
>>
>> 
>> > 
>> >
>>
>>
>>
>>
>>  /B
>>
>>  --- 8< 
>>
>>  $ cat /etc/fstab
>>  # /etc/fstab: static file system information.
>>  #
>>  # 
>> 
>>  proc/proc   procdefaults
>> 0   0
>>  /dev/md0/   ext3
>>   noatime,errors=remount-ro
>>  0   1
>>  /dev/md2/home   ext3noatime
>>  0   2
>>  /dev/md1noneswapsw
>> 0   0
>>  none/proc/bus/usb   usbfs   defaults
>> 0   0
>>
>>  --- >8 ---
>>
>>  On Wed, Oct 10, 2012 at 10:53 AM, rosea.grammostola
>> mailto:rosea.grammost...@gmail.com>
>> > >
>> > __gm__ail.com 
>>
>> > >
>>   On 10/10/2012 06:53 AM, Johnson Chetty wrote:
>>
>>
>>you need u-boot to set up the environment
>> for the
>>   device and
>>u-boot will then load the kernel..
>>
>>
>>   Thanks. Do you've pointers for how to do this?
>>
>>
>>
>>   --
>>   To UNSUBSCRIBE, email to
>>  debian-arm-REQUEST@lists.__debian.org
>>  
>> > __l__ists.debian.org
>> 
>>
>> > >>
>>
>>   

fan control on thecus n2100

[Gaudenz Steinlin]

Hi

With kernel 2.6.23 the F75375 driver for the fan control was updated.
AFAICS it should now support automatic fan control, but I did not
suceeed in enableing it. Is there any documentation for the files in 
/sys/devices/platform/IOP3xx-I2C.0/i2c-adapter\:i2c-0/0-002e/

How can I set the fan speed manually now and how do I enable automatic
fan control (if possible)?

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Munin

[Gaudenz Steinlin]

On Fri, Jan 11, 2008 at 12:32:42PM +0200, Salvatore Iovene wrote:
> On Fri, Jan 11, 2008 at 11:04:38AM +0100, Gaudenz Steinlin wrote:
> > the quintessence is that you need softfloat either by building your own
> > softfloat libraries (like Eddy did) or you need to swith to armel which
> > is softfloat.
> 
> Can you please elaborate more on the second option? Thanks!

I meant the ARM EABI Debian port currently under developement. See
http://wiki.debian.org/ArmEabiPort

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Munin

[Gaudenz Steinlin]

On Fri, Jan 11, 2008 at 10:46:13AM +0200, Salvatore Iovene wrote:
> Hi,
> 
> does anyone here successfully run munin or mtrg on a N2100? I first
> tried on my NSLU-2 and then on the Thecus, but for both of them it seems
> that the CPU power is not enought for rrdtools. Infact, I found that
> munin-graph would take hours and hours. Yesterday I had to kill it after
> about 10 hours of keeping my CPU busy over 80%.

See this blog post:
http://ramblingfoo.blogspot.com/2007/07/how-to-build-rrdtool-with-soft-float.html

from Eddy Petrisor.

the quintessence is that you need softfloat either by building your own
softfloat libraries (like Eddy did) or you need to swith to armel which
is softfloat.

Gaudenz


-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]