Re: Single Chip ARM solution for Debian Linux?
Marcin Juszkiewicz marcin.juszkiewicz at linaro.org writes: Samsung s3c2440 had 64MB ram and 64MB nand flash in cpu iirc. Sorry, but I believe you have mis-remembered. When I look at e.g. this board: http://www.friendlyarm.net/products/mini2440 I see discrete RAM and Flash chips. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120725t103145-...@post.gmane.org
Re: AArch64 planning BoF at DebConf
On Jul 21, 2012, at 04:10, Luke Kenneth Casson Leighton wrote: On Fri, Jul 20, 2012 at 4:12 PM, Steve McIntyre st...@einval.com wrote: I'm hoping to get AArch64 bootstrapped and ready for release in Debian by Wheezy+1, which I acknowledge will take a lot of work in a comparatively short space of time. We will need to cross-bootstrap as much as possible, verifying things in the model. Existing bootstrap work done by Wookey and co. will help a lot here. @begin awkward embarrassing moment, feel free to gloss over i also made some recommendations and offered to knock together a build infrastructure which would have augmented the existing debian build system, (which would have leveraged the best free software cross-compiling and qemu-compile-enabled toolchain that there is, and made it debian-aware) I'm assuming you're talking about Yocto/OE/bitbake/poky -- can you confirm? but the recommendations were, sadly, viewed as - once again - oo the fuck's this lkcl telling us what the fuck to do, we've been doing this for years, oo der fuck does ee fink ee is, trying to take over debian, let's vilify him, deliberately misunderstand what he's saying as much as we can as often as we can, make him look a fool so we look good and he'll go away ahhh that's better: we can go back to doing it our way, now, and stay in control ye rather than being viewed as what they were offered as: an augmentation of and an enhancement of the existing debian build system, offered *without* prejudice and entirely in good faith. Pejorative poetry aside, I think there are some reasonable choices made by Debian with regards to the build system, particularly building directly on the hardware. Is there a case to be made that using qemu and cross-compiling is somehow better? What are the trade offs? Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0b0089ec-5cc3-4bce-aee9-a2eaba676...@jeremiahfoster.com
RE: SS4000E Fan speed, LEDS and power button
How did you arrive at setting the fan1 divisor to 8? I used 4 but it's just
a guess.
I also get funny temps on temp2/3 but high not low like yours. There are 3
sensors in SS4000E, one CPU and 2 on the SATA board. I'm assuming these are
temp1-3 resp. but don't really know how the EM-7220 board is connected.
The disks can report internal temperature but lm-sensors doesn't appear to
support reading these values or using them to control fan speed.
CJW
-Original Message-
From: JF Straeten [mailto:jfstrae...@scarlet.be]
Sent: Tuesday, July 24, 2012 5:51 PM
To: debian-arm@lists.debian.org
Subject: Re: SS4000E Fan speed, LEDS and power button
Re,
On Tue, Jul 24, 2012 at 12:12:46PM -0400, Chris Wilkinson wrote:
Could someone be kind enough to post the output they get from these
commands?
If it has still an interest, here is output of mine after yours :
root@Freestor:~# sensors
w83792d-i2c-0-2d
Adapter: IOP3xx-I2C
VcoreA: +1.28 V (min = +0.00 V, max = +2.04 V)
VcoreB: +0.00 V (min = +0.00 V, max = +2.04 V)
in2: +2.55 V (min = +0.00 V, max = +4.08 V)
in3: +3.30 V (min = +0.00 V, max = +4.08 V)
in4: +0.00 V (min = +0.00 V, max = +4.08 V)
in5: +1.99 V (min = +0.00 V, max = +4.08 V)
+5V: +4.92 V (min = +4.49 V, max = +5.50 V)
5VSB: +4.93 V (min = +4.49 V, max = +5.50 V)
Vbat: +0.00 V (min = +2.69 V, max = +3.30 V) ALARM
fan1: 0 RPM (min =0 RPM, div = 2)
fan2: 0 RPM (min =0 RPM, div = 2)
fan3: 0 RPM (min =0 RPM, div = 2)
fan4: 0 RPM (min =0 RPM, div = 2)
fan5: 0 RPM (min =0 RPM, div = 2)
temp1:+46.0°C (high = +127.0°C, hyst = +0.0°C)
temp2: +127.0°C (high = +80.0°C, hyst = +75.0°C) ALARM
temp3: +127.0°C (high = +80.0°C, hyst = +75.0°C) ALARM
lothar:~# sensors
w83792d-i2c-0-2d
Adapter: IOP3xx-I2C
VcoreA: +1.32 V (min = +0.00 V, max = +2.04 V)
VcoreB: +2.05 V (min = +0.00 V, max = +2.04 V)
in2: +3.30 V (min = +0.00 V, max = +4.08 V)
in3: +2.98 V (min = +0.00 V, max = +4.08 V)
in4: +0.00 V (min = +0.00 V, max = +4.08 V)
in5: +0.00 V (min = +0.00 V, max = +4.08 V)
+5V: +5.01 V (min = +4.49 V, max = +5.50 V)
5VSB:+4.94 V (min = +4.49 V, max = +5.50 V)
Vbat:+0.00 V (min = +2.69 V, max = +3.30 V) ALARM
fan1: 1010 RPM (min =0 RPM, div = 8)
fan2: 0 RPM (min =0 RPM, div = 2)
fan3: 0 RPM (min =0 RPM, div = 2)
fan4: 0 RPM (min =0 RPM, div = 2)
fan5: 0 RPM (min =0 RPM, div = 2)
temp1: +53.0°C (high = +127.0°C, hyst = +0.0°C)
temp2: -30.5°C (high = +80.0°C, hyst = +75.0°C)
temp3: -19.5°C (high = +80.0°C, hyst = +75.0°C)
So almost the same as yours, but with fan1 speed (but funny temps').
root@Freestor:~# modprobe -l | grep 83792
kernel/drivers/hwmon/w83792d.ko
lothar:~# modprobe -l | grep 83792
kernel/drivers/hwmon/w83792d.ko
root@Freestor:~# modinfo w83792d
filename:
/lib/modules/2.6.32-5-iop32x/kernel/drivers/hwmon/w83792d.ko
license:GPL
description:W83792AD/D driver for linux-2.6
author: Chunhao Huang @ Winbond dzs...@winbond.com.tw
alias: i2c:w83792d
depends:
vermagic: 2.6.32-5-iop32x mod_unload modversions ARMv5
parm: force:List of adapter,address pairs to boldly assume to be
present (array of short)
parm: force_w83792d:List of adapter,address pairs which are
unquestionably assumed to contain a `w83792d' chip (array of short)
parm: probe:List of adapter,address pairs to scan additionally
(array of short)
parm: ignore:List of adapter,address pairs not to scan (array of
short)
parm: force_subclients:List of subclient addresses: {bus,
clientaddr, subclientaddr1, subclientaddr2} (array of short)
parm: init:Set to one to force chip initialization (bool)
lothar:~# modinfo w83792d
filename:
/lib/modules/2.6.32-5-iop32x/kernel/drivers/hwmon/w83792d.ko
license:GPL
description:W83792AD/D driver for linux-2.6
author: Chunhao Huang @ Winbond dzs...@winbond.com.tw
alias: i2c:w83792d
depends:
vermagic: 2.6.32-5-iop32x mod_unload modversions ARMv5
parm: force:List of adapter,address pairs to boldly assume
to be present (array of short)
parm: force_w83792d:List of adapter,address pairs which are
unquestionably assumed to contain a `w83792d' chip (array of short)
parm: probe:List of adapter,address pairs to scan
additionally (array of short)
parm: ignore:List of adapter,address pairs not to scan
(array of short)
parm: force_subclients:List of subclient addresses: {bus,
clientaddr, subclientaddr1, subclientaddr2} (array of short)
parm: init:Set to one to force chip
Re: SS4000E Fan speed, LEDS and power button
Re, On Wed, Jul 25, 2012 at 08:53:58AM -0400, Chris Wilkinson wrote: How did you arrive at setting the fan1 divisor to 8? I used 4 but it's just a guess. I slavishly followed Arnaud's help to setup fan control at installation time. Since it worked almost immediately, I didn't look any further... So the fancontrol script must be credited for the magic (it says automated software, after all), but it may also be Arnaud that has a voodoo doll he sticks when giving advice :-) It will not help; I know... A+ -- JFS. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120725131430.ga25...@jones.jfs.dt
Re: [Arm-netbook] ARM port(s) BoF at DebConf
tis 2012-07-24 klockan 00:02 +0100 skrev Luke Kenneth Casson Leighton: rright. many thanks to the person on arm-netbooks who found that the netgear ReadyNAS boxes can take standard DDR3 SO-DIMMs. apparently there are lots of people who have been upgrading them from the pathetic 256mb they come with to at least 1gb, with some degree of success: http://www.readynas.com/forum/viewtopic.php?f=110t=49254 That thread is for DUO v1 only (LEON SPARC based). I have not seen any claims that DUO v2 can be upgraded before the post on this mailinglist. Only numerous claims and complaints about it not being upgradeable, and wrote it off as not interesting when it came ot due to being restricted to 256MB. Regards Henrik -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1343254731.5203.28.ca...@hlaptop.hno.se
