Re: flash-kernel anb beaglebone
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!) -- Loïc Minier -- 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/20131113101651.gb10...@pig2.dooz.org
Re: flash-kernel anb beaglebone
Le 13/11/2013 11:16, Loïc Minier a écrit : 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? root@cavalas:~# cat /proc/device-tree/model TI AM335x BeagleBone -- 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/528355ed.6060...@miradou.com
Re: flash-kernel anb beaglebone
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
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 -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6GpRFiBpwT0pxgDAtkJdm7pbdAkGo4ySpQOHka5=ty...@mail.gmail.com
Re: Fwd: Do others see install failures on DNS-323 to ext2 FS from Debian 7.0 netboot.img?
On Tue, Nov 12, 2013 at 7:10 PM, Martin Michlmayr t...@cyrius.com wrote: I finally had time to look into this issue. I summarized what I found in a bug report: http://bugs.debian.org/729445 What a clear and simple report -- thanks, Martin! (Ext2 seems to be the only linux-native FS available in the installer.) I wonder why you say that. That's something I never understood about the several reports I received from other users about this problem. Why do they use ext2 for the root partition? By default, the installer should use ext3, but for some reason it must be ext2 on the DNS-323. I'm not sure why and I'm not around my ARM devices at the moment to check. But this is definitely another issue since ext2 should *not* be the default for the root partition (only for /boot). Yes. I can only speak for my colleague and myself; we saw only ext2 and several FAT-related choices when we ran d-i and chose to use its partitioning UI. I don't know why ext3 et al. were not on the menu. Of course, d-i is running in 64 MB of RAM in this case. Two possibilities occur to me: 1) the installer is ignoring more memory-intensive partitioning options right away 2) the installer looks at disk size and estimates how much RAM it will need, and then offers partitioning options it can support. A google for Memory allocation failed while setting up superblock shows (with only RAM 192 MB, no swap) some examples of the kind of problem d-i might be seeking to avoid by offering ext2 only. I apologize for speculating without reading the source. The disk I was installing on was 2 TB. When I have time, I shall try the same install on a 250 GB disk and report. I am very grateful for the help, Martin, and for any opinions from the list. -- t...@eastpole.ca East Pole Productions -- 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/calprqqacrienqhqnatq3jct97vp0zjlm+_hraeb0mq_he5_...@mail.gmail.com
Re: flash-kernel anb beaglebone
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: Fwd: Do others see install failures on DNS-323 to ext2 FS from Debian 7.0 netboot.img?
* Tai Viinikka t...@eastpole.ca [2013-11-13 10:24]: Yes. I can only speak for my colleague and myself; we saw only ext2 and several FAT-related choices when we ran d-i and chose to use its partitioning UI. I don't know why ext3 et al. were not on the menu. Of course, d-i is running in 64 MB of RAM in this case. Two Thanks for pointing this out. This explains the behaviour you're seeing. Debian installer has a low memory mode (lowmem). In this mode, additional modules are not loaded automatically; this includes the ext3 module. I'll change the instructions to tell users to choose the ext3 manually. Martin, wondering when 64 MB of RAM became low memory... -- Martin Michlmayr http://www.cyrius.com/ -- 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/20131113190604.gb3...@jirafa.cyrius.com
Re: flash-kernel anb beaglebone
On Wed, Nov 13, 2013, David Goodenough wrote: 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)? flash-kernel is usually updated per machine; doing the packaging changes to enable a mips/mipsel build is relatively trivial (grep for armel / armhf and list mips / mipsel there), but the new machines must be enabled correctly. Ideally not only in flash-kernel but also in debian-installer to generate suitable installation media. There might also be some kernel packaging changes to do. -- Loïc Minier -- 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/20131113193813.gc24...@pig2.dooz.org
Proposal to replace/extend current armhf builders
Hi all, Here is some food for thought for the minidebconf that starts tomorrow in Cambridge [1]. Unfortunately I will not make it there, though I wish I did, but I'm in the process of job searching at the moment[2] and could not afford the expense. Anyway, since I got nothing close to a proper reply to my suggestions over IRC or email before, I thought of doing a proper proposal. Keeping the iMX53 locos just doesn't cut it anymore, they're slow and have started failing builds due to lack of RAM (OOM in linking stage for iceweasel [3]), 2 out of 7 are offline, 1 has a failing disk (hoiby, hasse had its own replaced already). And taking ~2 days to see that the build fails is a bit irritating. By contrast, I've built the same package, iceweasel, on my chromebook (dual-core A15) in 11h. I'm using a USB3 external 2.5 case with an SSD disk and the result is a very well performing system. I guess the XU would do the same compile in about 4-6h due to its being 8-core (4xCortex A15 + 4xCortex A7). So I propose something similar: Upgrade 5 of the iMX53s with 5 Odroid-XU and be done with armhf builders for a long time. This is a counter-proposal to what Hector Oron (zumbi) suggested: that we buy or get donations for real server class hardware (arm64). In theory that would be best as it would build all 3 ports, but it has several drawbacks: 1. Terribly expensive: a single board costs ~7k USD. And it needs the chassis which is also expensive. So if you take redundancy in mind, you need 2 setups in 2 locations, so at least 14k just for the boards and I'd not be surprised if the chassis costs more than 5k itself. So in total ~25k. Now if we get this thing donated, even half of it, by all means, that would be great, but the impression I got is that this is unlikely. And I would never propose that Debian spends $25k of its budget for arm* builders. 2. It causes a SPOF (Single Point Of Failure) risk if we go the route of building for all 3 ports on it. If one board breaks, all 3 ports would have to wait for a repair/replacement. Huge downtime which no port can afford. 3. Liability. Right now armhf builders (iMX53 Loco boards) are in ARM HQ and York University, if I'm not mistaken. If something happens and that equipment breaks due to eg. some fault in the electrical wiring and a board burns, the boards are very cheap to replace and there is no issue there. However with $10k+ worth of equipment I'm very doubtful if ARM or York or anyone really would accept to host these systems and accept liability in case of fault. 4. Availability. In short we don't know when those arm64 boards will be available. Most likely 2014Q1 but it's not concrete. So, my counter-proposal to that is that we get instead some cheap easy to replace boards like the Arndale [4] or the Odroid-XU [5]. Personally I'd prefer the XU as it's better equipped, but I'd go with either choice if people think it's better. This way, all 4 points above are solved, we can even buy a couple of spares in each site, in case one breaks down so we can replace it easily. I've done some short list of items, a BOM if you like, converted in GBP since that's where the boards will most likely end up (used amazon for some parts, feel free to look elsewhere, this is just a rough cost estimate): Qty Item Price Total 5Odroid-XU 105.00 525.00 5Odroid-XU case 5.61 28.05 5Odroid-XU serial cable 9.35 46.75 5Odroid-XU PSU 6.23 31.15 52.5 USB3 SATA case [6]28.50 142.50 5Kingston 2.5 SSD V300 60GB41.96 209.80 Total 983.25 GBP So for less than 1k GBP, we can upgrade our complete buildd farm with just 3 builders and keep 2 spares at each site, we could even keep our current iMX53s as spares of course, but seriously why bother? Just keep them for a while and send them to interested developers afterwards (no I'm not interested myself, have enough MX5x hardware already as it is). One issue I didn't mention is how do you solve remote power and serial console management with these boards. This is actually an advantage in favour of the arm64 server class hardware. Well, with a simple google search, I found several products to solve this case but I'm not an expert so I'll let you find the best solution for this. BUT in case anyone is interested I have a PCI Acceleport 8i cart (one PCI multi-serial cart that extends to 8x DB25 ports, not DB9 unfortunately), which I'd be willing to donate if there is a need for this cause -it was actually used in the original armhf EfikaMX buildfarm to monitor each efika. Finally, last but not least, there is the issue of mainline kernel support for exynos5 and the odroid/arndale boards. Right now 3.11 doesn't give you much, but I've heard that the situation with 3.13 is much better -still not completely operational, but it should get better
Re: flash-kernel anb beaglebone
On Thu, Nov 14, 2013 at 2:41 AM, David Goodenough wrote: 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)? Sorry I thought you were talking about DT rather than flash-kernel. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6h8kdlk+kqg6mkeer+tbhh7xgsxo+ai5yhp137knmp...@mail.gmail.com
