Re: ARM Ports BoF: armel in buster

2017-08-28 Thread David Goodenough 
On Monday, 28 August 2017 16:23:24 BST W. Martin Borgert wrote:
> Quoting uhmgawa :
> > On 08/28/2017 08:46 AM, W. Martin Borgert wrote:
> >> As long as you have enough flash memory (some hundreds of MiB) and RAM
> >> (at least 64 MiB, better 128 MiB), Debian runs fine on such hardware
> >> in my experience. It depends on your applications, of course.
> > 
> > Available flash is from 32~64MB depending on platform.  So manual subset
> > of the distro id required and where recurring the effort enters the
> > picture.
> OK, then Debian is probably not an option. I doubt, that one can strip down
> Debian 9 to 32 MiB... Has anybody tried?
Have you looked at the now remerged OpenWRT/LEDE?  They support
lots of little systems like this, and I think several are armel.

David
> 
> >> Debian is supposed to be the "universal operating system". I.e. it is for
> >> server + workstation + embedded + whatever. This is different from most
> >> other Linux distributions.
> > 
> > I applaud that goal.  But the approach of using a native arch build
> > vehicle
> > for the distro also introduces complication for embedded class
> > development.
> > Not insurmountable but additional compared to the cross-build approach
> > typical of embedded linux distros.
> 
> The native build requirement is only affecting Debian itself, not its users
> (people deriving the distribution for their needs or building appliances).
> In my company, we always cross-build our .deb packages for ARM. We do this
> also, if we need to recompile official Debian packages (local backports or
> patched packages). We don't have any armel hardware, that would be fun to
> build packages with.

Re: Debian in a Pcduino3

2014-12-30 Thread David Goodenough 
On Tuesday 30 December 2014 15:36:34 Patrice Go wrote:
 It seems that dtb(s) is an electronic shema (in a file), for that the
 kernel recognize the board (partially or completely).
 Thanks for the explanation, it is more clear now.
 
 However, i don't know if the dtb (and others modifications to do) can be
 done just in reading the electronic shema... but if it is necessary to have
 the physical board to know more precisely some I/O address, i can give some
 informations (there's an installed OS - not the one i want- with a Shell in
 the pcduino3 board) from this one.  If it can help for the next dtb.
All you need to do is find the file from the 3.17 or later kernel (it can be
found at kernel.org by looking at the git tree (I chose one from 3.18.1) at 
(this next is only one line):-

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts?id=v3.18.1

you will find a file called:-

sun7i-a20-pcduino3.dts

This file is specifically the one for the pcduino3 and defines everything that
the kernel needs to know to run on the pcduino3.

Then follow the instructions in:-

https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_on_systems_that_are_not_supported_out_of_the_box

David
 
 Is there a mean to know when the dtb and others spécifications, enabling
 the install in pcduino3, will be in jessie ? I don't know how to find this
 information and where are the diff from jessie enouncing that...
 
 Great thanks for this work in the pcduino3...
 
 Le 28 déc. 2014 01:20, Karsten Merker mer...@debian.org a écrit :
  On Sat, Dec 27, 2014 at 11:18:25PM +0100, Patrice Go wrote:
  
  [using a dtb from a newer kernel with kernel 3.16]
  
   understood. don't have enough technical capacities and time to
   advance in that...  is it something like that, that it would be
   necessary to do ?  :
   http://olimex.wordpress.com/2013/09/18/7795/
  
  Hello,
  
  the olimex page describes something completely different - it is
  about manually setting up a Debian rootfs with a linux-sunxi.org
  3.4 kernel.  The linux-sunxi.org 3.4 kernel does not use
  device-trees, but instead uses the Allwinner-specific fex
  system, which is incompatible with mainline kernels.
  
  I guess you need some more background information about Linux on
  arm-based systems:
  
  Historically, every arm-based system needed a specifically built
  kernel.  This obviously did not scale well to a large number of
  systems, so people worked on a solution, which was found in the
  form of device-trees.  A device-tree is a description of the
  hardware setup of a specific board.  It contains information such
  as which I/O-pins are connected to which external devices and
  which non-probeable hardware components are built onto the board.
  Systems-on-Chip (SoC) like the Allwinner A20 give a hardware
  designer the possibility to use their I/O connectors for very
  different functions, which means that the very same I/O pin that
  is used for detecting the presence of an SD card on one board
  might be used to control the power supply of an ethernet PHY on
  another board.  All this information is encoded in the board's
  device-tree, so that a single kernel which understands this
  device-tree information can run on lots of different boards, as
  long as a device-tree for that board exists and the kernel has
  the necessary drivers for the hardware components on the board.
  
  The kernel 3.16 in Jessie has drivers for several core components
  of the pcduino3 (like serial port, MMC controller, USB host
  controller, internal ethernet MAC, external ethernet PHY, SATA
  controller), but due to lack of a device-tree for the board, it
  does not know how several of the connectors or external
  components are wired to the SoC.  If one provides the device-tree
  information for the board (which can be taken from kernel 3.17)
  to kernel 3.16, those drivers which are already available in
  kernel 3.16 can make use of it and thereby work on the new
  board.
  
  I hope this helps a bit in clearing up the confusion.
  
  Regards,
  Karsten
  --
  Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
  sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
  Werbung sowie der Markt- oder Meinungsforschung.


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1674594.Xpq5G3lv0i@stargate

Re: Debian in a Pcduino3

2014-12-27 Thread David Goodenough 
On Saturday 27 December 2014 15:50:26 Patrice Go wrote:
 Thanks for the help,
 
 I am not sure to be able and to have enough time to install a wheezy by
 hand (lfs, kernel compilation, modules choices, etc), i think i will
 rather test an install of a Jessie or a sid on the pcduino3.
 
 The use of my pcduino3, for the future, will be just for ssh (and others
 console, ncurses), then there's no need for me a video support, i won't use
 X server. i don't have the necessity to use the pcduino3 now, i have others
 arm board (raspberrypi, beaglebone black) for my use. Therefore, i would be
 happy to be a debian tester for this pcduino3.
 and thanks to
 
 However, i am not sure to understand correctly all the technical point...
 
 i enounce my actual understanding of these points :
 
 Jessie is defined/frozen actually with a kernel 3.16, which doesn't support
 the A20 device-tree (structure of the pcduino3 board). then if i install a
 Jessie, will i be able to use it for minimal uses ? by example, command
 line and ssh, to install the kernel 3.17 backport which support the A20
 device tree ?
 or is it better to install the sid ?
Actually this is not true.  Out of the box Jessie supports A20 devices like 
the Cubieboard-2, the Cubietruck and the PananaPi.  It just does not have
the PcDuino DTS in a package.  If you look at the the u-boot-sunxi package
it had the above mentioned DTS file in it, and the page you have been
pointed at  below for installing on Sunxi systems you will find instructions
for installing one which is not pre-installed.

David
 
 Patrice G.
 
 Le 25 déc. 2014 23:35, Karsten Merker mer...@debian.org a écrit :
  On Thu, Dec 25, 2014 at 09:28:53PM +0100, Patrice Go wrote:
   I am searching some technical informations to know if it is
   possible to install a debian OS in a pcduino3.  I was searching
   on the debian arm iso ftp, but i don't know what is the arm iso
   (armel or armhf) to choose for the pcduino3.  It seems that it
   is an arm v7, then maybe the armhf :
   
   CPU : AllWinner A20 SoC, 1GHz ARM Cortex A7 Dual Core.
   GPU : OpenGL ES2.0, OpenVG 1.1, Mali 400 Dual Core
  
  The architecture in this case is armhf.
  
   I don't know what to choose between mx5 and vexpress :
   /debian/dists/wheezy/main/installer-armhf/current/images/
  
  It is neither mx5 nor vexpress - these are completely different
  systems.  Support for certain Allwinner A20-based systems is
  officially available in Jessie (testing) and Sid (unstable), but
  not in Wheezy (stable).  It is possible to setup Wheezy on an
  A20-based system, but you would have to do that completely by
  hand as Wheezy lacks the necessary installer support.
  
   i don't see any informations about debian for this device. Was
   there some tests previously on this kind of device ?  I would
   want to test the installation...
  
  The pcduino3 is (in contrast to the older A10-based pcduino) not
  yet officially supported by Debian (device-tree support for it
  has been added in kernel 3.17 while Jessie uses Kernel 3.16), but
  we could possibly backport the device-tree support.  The major
  issue at the moment is that Debian is currently frozen for the
  next release, which means that normally only bugfixes get
  accepted, but no new features.  If you are willing to act as a
  tester, I can look into backporting the relevant changes to
  kernel 3.16 and making the necessary adjustments to the
  installer, but I cannot promise that these modifications would
  be accepted by the release team.
  
  Please note that Debian would in any case only support using a
  serial console on the pcduino3, as there is no video driver
  support for the A20 in the mainline kernel.  For background
  information about Debian on Allwinner-based systems, I would like
  to refer you to the Debian Wiki at
  https://wiki.debian.org/InstallingDebianOn/Allwinner.
  
  Regards,
  Karsten
  --
  Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
  sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
  Werbung sowie der Markt- oder Meinungsforschung.


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7761596.NZLBO7QYr2@stargate

Which kernel flavor for big.Little systems?

2014-05-07 Thread David Goodenough 
The world of big.Little is about to hit boards that Debian might support
in the form of the AllWiner A80 (it has 4 big A15 and 4 little A7 processors).
This is due to hit the marketplace in the form of PcDuino-8 and 
Cubieboard-8 boards next month.  The A80 Optimus board is supposed to
be available this month.

Which kernel flavor should be used?  Should it just be treated as a 
64 bit ARM board, or are all ARM 64 kernels going to be big.Little enabled
in rather the same way that Amd64 kernels are today - although of course
in the Amd64 world this only applies to the application code not the kernel?  
If so I would then be able to load either an armhf or an arm64 deb file and 
run the relevant executables I presume.

David


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3689297.s7kSSyH2ET@stargate

Re: Which kernel flavor for big.Little systems?

2014-05-07 Thread David Goodenough 
On Wednesday 07 May 2014 12:23:10 Lennart Sorensen wrote:
 On Wed, May 07, 2014 at 04:03:04PM +0100, David Goodenough wrote:
  The world of big.Little is about to hit boards that Debian might support
  in the form of the AllWiner A80 (it has 4 big A15 and 4 little A7
  processors). This is due to hit the marketplace in the form of PcDuino-8
  and
  Cubieboard-8 boards next month.  The A80 Optimus board is supposed to
  be available this month.
  
  Which kernel flavor should be used?  Should it just be treated as a
  64 bit ARM board, or are all ARM 64 kernels going to be big.Little enabled
  in rather the same way that Amd64 kernels are today - although of course
  in the Amd64 world this only applies to the application code not the
  kernel? If so I would then be able to load either an armhf or an arm64
  deb file and run the relevant executables I presume.
 
 Well A15/A7 are 32bit (with LPAE for 32bit physical memory).  They are
 not 64bit.
 
 A53/A57 chips are 64bit.
 
 I think the vexpress in the mp kernel is already A15 based, so probably
 the same kernel would make sense.
 
 I am not sure there is any support for big.LITTLE in the current kernel
 though, although it is certainly being worked on.
Well thank you for clearing up my mis-understanding about the big in 
big.Little.  Being all 32 bit obviously makes life easier, in that all
the apps will be armhf, which should mean it fits into the current 
Debian family without real change (other than the kernel).

It will be interesting to see what kernel bits AllWinner release with
the A80 and what then gets merged into the mainline kernel.  Although
I suppose I should not hold my breath for that as the AllWinner kernel
shipped with the Cubieboard2 is only single processor, it does not even
make use of SMP.

David


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5479735.0YEP7ZukMe@stargate

Re: flash-kernel anb beaglebone

2013-11-13 Thread David Goodenough 
On Wednesday 13 Nov 2013, Loïc Minier wrote:
 On Tue, Nov 12, 2013, François-Régis wrote:
   Is there a reason for flash-kernel not supporting beaglebone [black]
   
   No particular reason, happy to add support for it if you could send the
   boot information (typically this is: where it boots from, /proc/cpuinfo
   or /proc/dt/model, which Debian kernel it uses etc.)
  
  root@cavalas:~# cat /proc/cpuinfo
 
 [...]
 
  Hardware: Generic AM33XX (Flattened Device Tree)
 
 This indicates Device Tree is in use; what's in /proc/dt/model?
 
  The kernel is not debian  provided by arago-project (
  http://arago-project.org/git/projects/?p=linux-am33x.git) but it should
  be merge with armmp v3.13.
 
 (Great to see focus on getting things working with armmp!)
I know this is an ARM list, but any prospect of having this for mips and
mipsel as well?  As OpenWrt shows, there are lots of little mips routers
out there that would be relevant for this kind of utility.

David


--
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/201311131038.26759.david.goodeno...@btconnect.com

Re: flash-kernel anb beaglebone

2013-11-13 Thread David Goodenough 
On Wednesday 13 Nov 2013, Paul Wise wrote:
 On Wed, Nov 13, 2013 at 6:38 PM, David Goodenough wrote:
  I know this is an ARM list, but any prospect of having this for mips and
  mipsel as well?  As OpenWrt shows, there are lots of little mips routers
  out there that would be relevant for this kind of utility.
 
 Looks like various people are working on that:
 
 https://www.google.com/search?q=mips%20device-tree
I know that work is proceeding on mips and device tree, what I was asking 
about was getting flash-kernel to work on mips(el) devices.  Or are you 
implying that the only holding it back is the lack of device tree and that
as soon as DT is used for mips(el) that flash-kernel will be available for
mips(el)?

David


-- 
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/201311131841.34428.david.goodeno...@btconnect.com

Re: apt-get /lib/ld-linux.so.3 deletion screwup disaster

2013-05-08 Thread David Goodenough 
On Wednesday 08 May 2013, Wookey wrote:
 +++ Phil Endecott [2013-05-08 09:13 +]:
  Wookey wookey at wookware.org writes:
   Your original install was built before the name for the armhf linker
   was agreed between distros. Once it was agreed (with a different path
   to the one Debian originally picked) everything had to be
   (incompatibly) rebuilt.
  
  Hmmm.  It's disappointing that apt didn't know about this.  Isn't this
  sort of compatibility between packages exactly the sort of thing that it
  is supposed to track?
 
 No, not for unreleased early port builds. It (we) would manage such a
 transition if it was in a released port, but that's a big pile of work
 we decided wasn't worthwhile/necessary in this case.
 
  Anyway, I'm still unsure what I should do now.  Presumably I will have to
  do some sort of apt-get upgrade to replace all packages (or at least all
  packages with executables).  But I think the first thing it will try to
  do is to replace libc again, and delete /lib/ld-linux.so.3.  Maybe I
  should make the symlink immutable, or something.
 
 Yes, replacing libc (carefully, with a root shell open) fix up symlink
 (until upgrade complete) and then everything else should work.
 
 Don't forget to re-install everything, not just stuff that has a new
 verison number (dpkg --reinstall, probably combined with a
--reinstall does not exist in either the command help (dpkg -?) or in
man dpkg.  If it exists should it not be documented?

David
 --get-selections and set-seletions)
 
 
 Wookey


-- 
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/201305081423.19503.david.goodeno...@btconnect.com

Re: running Debian on a Cubieboard

2013-05-05 Thread David Goodenough 
On Sunday 05 May 2013, Luke Kenneth Casson Leighton wrote:
 On Sun, May 5, 2013 at 7:49 AM, Jean-Marc jean-m...@6jf.be wrote:
  Hi guys,
  
  I bought a Cubieboard some days ago (http://cubieboard.org).
  I would like to install a Debian Testing on it and some useful services
  (webserver, wiki, xmpp server, mail server, ...).
  
  I took a look at the doc' and found some interesting things here:
  http://linux-sunxi.org/Cubieboard/
  http://linux-sunxi.org/Cubieboard/Installing_on_NAND
  
  Did somebody already try this ?
 
  there are dozens of people, if not hundreds, who have installed
 debian on A10 devices.  they're all pretty much the same.
 
  start from here:
  http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/
 
  then you go here:
  http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/Building_Debi
 an_From_Source_Code_for_Mele/
 
  or here:
  http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/debian_kernel
 /
 
  and here:
  http://linux-sunxi.org/Building_on_Debian
 
  and yes you've found this one already:
  http://linux-sunxi.org/Cubieboard/Installing_on_NAND
 
  and you might also like to get one of the bootable images from here:
  http://linux-sunxi.org/Bootable_OS_images#Debian
 
 
  but if you like, you should be able to use this and adapt it, if you
 prefer not to do any kind of cross-compiling, you can use chroot
 bootstrapping instead - just adapt the sdcard partition setup
 arrangements using bits of the instructions above:
  http://lkcl.net/reports/odroid-u2.html
 
 that report is pretty similar in procedure to the Installing_on_NAND
 one except that it shows how to compile a native kernel and also
 doesn't mean you download a ridiculous 4gb or 8gb image, you use
 debootstrap and save a ton of network bandwidth in the process.
 
  the only thing to watch out for is that many people are not aware of
 the changes to fdisk of the past 18 or so months, where fdisk used to
 default to using cylinders or something but now uses different
 defaults, so many people have been reporting instructions that work on
 e.g. ubuntu but if you use debian/testing those exact same
 instructions completely fail.  if i recall correctly you'll need
 fdisk -u i.e. use sectors instead of cylinder as a default unit.
 
  Did youo do it the same way ?
 
  i strongly advise you not to deviate from any of the build
 instructions, at least not initially.  bear in mind the following
 things:
 
  * there is no BIOS.  AT ALL on ARM devices.  you're operating at
 low-level, and you are on your own.  deviate one tiny bit and you
 could f*** things up or waste 3 weeks trying to work outside the box.
 
  * luckily with allwinner a10 devices, they're unbrickable.  even if
 you f*** them up there's a way to put them into a mode which allows
 low-level recovery.
 
  And I have a question: as the Debian installer takes the arch armhf in
  charge, do you think a standard install' from a netboot image will work
  ?
 
  this has been on my list for a lng time.  as with *all* debian
 installer images however you are hampered by the fact that there is no
 BIOS - at all - on ARM devices - and therefore it is impossible to
 have a one size fits all debian installer.
I wonder if the device tree is the answer here.  If the box comes with
a DT or one is available on the web then the installer could read it and 
know what to install.  That and the armmp kernel should solve the problem.

David
 
  in other words you need to customise the debian installer by putting
 in very very specific boot procedures, kernel and initrd that is
 *specifically* tailored to understand that hardware.
 
  nobody has yet tackled this for any allwinner 10 devices, and as this
 is your first a10 device i would advise you not to try messing about
 with debian installer until you have at least prepared a
 debootstrapped image and got a first independent boot.
 
  once you've done that and have an SD Card that you can always go back
 to, *then* you will be in a strong position to explore creating a
 customised version of debian installer.
 
  if you try to create a customised version of debian installer first
 without having ever successfully booted this system up you risk
 getting in *way* over your head and giving up.
 
  small steps first - trust and follow other peoples' instructions first.
 
 l.

Re: Hackberry A10 Dev Board for $60

2012-08-06 Thread David Goodenough 
On Monday 06 Aug 2012, Rob van der Hoeven wrote:
 Hi,
 
 Today i stumbled upon what looks like a very interesting device.
 
 It has the following specs:
 
 CPU : 1.2GHz Allwinner A10 ARM Cortex A8
 GPU : Mali400
 Serial port : 4-pin header
 Audio in: 3.5mm microphone jack
 Audio out   : Audio over HDMI
 USB : 2 x USB A 2.0 ports
 Internal storage: 4GB NAND storage, 1.5GB available in user partition 
in
 Android
 External storage: SDHC card slot supporting up to 32GB
 Networking  : 10/100 Ethernet, Realtek 802.11n WiFi
 Memory  : DDR3 512MB / 1GB, ~100MB is reserved for the GPU
 Boot: Boot from SD card and internal storage via u-boot
 OS  : Android 4.0 ICS, Linux support
 Digital video   : HDMI up to 1080p
 Analog video: 3.5mm composite AV, 3.5mm component Y/Pb/Pr
 Power   : NEMA 2-pin power adapter included Input
 AC100-240V-0.4A 50/60Hz Output DC5v
 
 Price is $60 for a system with 512MB, $65 for a system with 1GB.
 
 Link:
 
 https://www.miniand.com/products/Hackberry%20A10%20Developer%20Board
 
 I'm not an ARM expert, but this looks interesting to me. What do you
 think?
 
 Kind regards,
 Rob.
 http://freedomboxblog.nl
Is that US dollars, or (as they are in Australia) Australian dollars?

David


-- 
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/201208061344.01340.david.goodeno...@btconnect.com

Re: Debian GNU/Linux on tablet hardware

2011-10-28 Thread David Goodenough 
On Friday 28 Oct 2011, Rob van der Hoeven wrote:
 On Fri, 2011-10-28 at 14:37 +, Phil Endecott wrote:
  Rob van der Hoeven robvanderhoeven at ziggo.nl writes:
 I think the hardware of this tablet can also be used as a server or
 desktop computer. The tablet is mass produced and very cheap (i got
 mine for 149 euro).

For that price, to make a server, I would rather buy a loco board or
any other development board
   
   These boards are not mass produced which makes them relatively
   expensive.
  
  The i.MX LOCO board, the OMAP panda board, and some of the others cost
  about the same as your tablet.
 
 Panda board has very nice specs.
 
   Hardware that is not mass produced has some other issues,
   namely availability and vendor lock-in
  
  You think that your tablet is going to have better availability and less
  lock-in than a board from Freescale or TI?  That seems unlikely to me. 
  Look at the BeagleBoard; it would be hard to find any smartphone or
  tablet device that has been available for as long as that has.
 
 The FreedomBox project is looking for very cheap hardware. This hardware
What about the shortly to be released Raspberry Pi?

David
 exists today, but it is used for running Android. It would be very nice
 if we could liberate this hardware and use it for our own computing.
 
 Beagle board and Panda board are very nice but i don't think they will
 become cheap enough for the FreedomBox (one monopolistic manufacturer,
 low volume - only 8900 Panda boards sold)
 
 If the FreedomBox would use a popular SoC then the manufacturer of the
 motherboard seems less important to me. All the major functionalities
 for which drivers are needed are on one chip. We could simply switch to
 an other board with the same SoC and still run our software (maybe with
 some minor adjustments, please correct me if i am wrong...)
 
   I think it must be possible to buy an android motherboard for just a
   fraction of the price that i paid for my tablet.
  
  Why do you think that?  I have personally never seen an Android
  motherboard offered for sale at all, let alone for a low price.
 
 You find out the manufacturer of the motherboard inside a tablet. Then
 you contact this manufacturer and say: Hi, i know you are making 1
 motherboards for Yarvik, if i were to order 1000 of these boards what
 would the price be? I think the manufacturer will be happy with an extra
 order. Mass produced boards are well tested (the manufacturer simply
 can't afford mass problems) and cheap.
 
   Why is relying on
   hardware with a SoC such a bad idea? If the SoC is popular it will not
   go out of production for a long time.
  
  No, that's not how it works.  Both popular and unpopular chips are
  replaced on a schedule that's determined by advances in manufacturing
  technology.  This also applies to the consumer products that are made
  from them: even if a device is popular, it will soon be replaced with
  something that is faster and cheaper.
 
 Not quite true i think, especially for SoC. My FreedomBox has an Marvell
 6281 (Kirkwood) SoC inside. This chip has been around for a long time.
 You are right for non-SoC boards, they can more easily change for
 example the graphics chip and spoil our fun.
 
 Regards,
 Rob van der Hoeven.
 
 http://freedomboxblog.nl


-- 
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/201110281933.25798.david.goodeno...@btconnect.com

Re: APEX and Debian

2006-07-16 Thread David Goodenough 
On Sunday 16 July 2006 02:12, Kevin Price wrote:
 Hey Martin!

 Martin Michlmayr schrieb:
  kernel, and it generates a proper initramfs (taking the non-free
  ixp4xx drivers if they're available) and flashes it.  What's missing
  is that...

 Thanks a lot for nslu2-utils. I think that most users prefer not to flash
 the slug too often, just like I. I know that flash EEPROMS cannot stand
 infinetely many flashes and I know that if I flash something bad then my
 slug goes to NAS-heaven. So my favorite option is to flash only one debian
 image and never again anything else.

 Are you convinced that most users think like I do or should I write more
 arguments?

 brgds
   Kevin
While flash memory used to be a bit fragile, these days it is really very
resilient.  Think of the flash cards used in cameras, they do not last for 
ever but they take lots of photos.  I have had compact flash memory running
on systems which keep log files on flash (and are writing all the time) for
nearly three years now without failure.

David


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

Marvell SoC support in current 2.6 kernels

2006-03-31 Thread David Goodenough 
Does anyone have 2.6 versions of the patches necessary to get 2.6 running
on the Marvell ARM9 based 88W8510 chips.

I have a system (running 2.4) and I am trying to find out what devices are
attached.  Unfortunately lspci is not installed, but looking in /proc there is
no /proc/pci either.  I am from the i386 world, so I may be looking in the 
wrong place, but is there a similar bus with IDs that can be matched to
drivers for such chips?

David


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