Re: Proposal to replace/extend current armhf builders
On Fri, 15 Nov 2013 00:23:55 + Wookey woo...@wookware.org wrote: Arm64 kit will be even more expensive/unobtanium for a while. Although I expect the situation to be very different laster next year. We can schedule a reevaluation of getting server class hardware next year then. Until then however, we still have to fix the current situation. It's expensive, but not that bad. Or are you talking about 64-bit hardware? Has anyoneannounced prices for that yet? No that was the price estimate I heard from Hector a while back for the Calxeda boards (is that the highbank ones that Arnaud mentioned? probably but not sure). I'm pretty sure that was the price, but I might be wrong as to what that price involved (ie chassis with boards or single board). Anyway it's expensive, and it's still the matter of redundancy, you can't just buy one. I think that's nonsense. If we had a box we could find somewhere to house it. Fine then, I still think the situation would be more complicated, but I'll take your word for it that it's a non-issue. There was very strong resistance in the room to the use of buildds without debian kernel support, because it's a major hassle and security risk. That rules out odroid for the time being. That's fine, I'm not the one to do the security upgrades so I can't possibly insist on putting more burden on other people's shoulders. I'd fancy the idea of super fast builders, but not at the cost of other people doing the grunt work for one port's convenience. Or Wanda or the Nitrogen6x we've just kindly been offered. Or those, yes. One of the issues is getting boards with more RAM than the current 1GB that the MX53 Locos have, so only the wandboard quad and the utilite fall in that criteria, I see that the Nitrogen6X has only 1GB RAM, so even if it's a nice and tempting offer, I'd still think we need to evaluate this better. It would definitely improve the situation immensely, but builds might still break due to OutOfMemory errors (like iceweasel), but we would definitely get rid of tons of timeout errors that currently need special casing. What's the mainline status of those? I was going to answer I don't really know, but I just saw that Arnaud just answered that, thanks :) I think we need to bash out some criteria for deciding during the mini-debconf. i.e deciding how we decide (or just make a decision if possible). Better to decide now rather than wait for the perfect solution next year (which might have other problems other than price). Better is Good's worst enemy. e.g hold out for server-grade kit for a while - if so how long? (0 months, 3 months, 6months, longer?) If it was a vote, I'd say get some cheap hardware now to replace the current builders, say costing under an absolute limit of 1000GBP (total: disks, boards, cases, PSU, multiserial terminals, etc). That might even get lower if we accept the Nitrogen6X offer. And reevaluate the situation in 12 months when arm server class becomes available (arm64 or arm32). Is debian kernel an absolute requirement, or are we prepared to risk a custom kernel if we think it'll only be for 6 months? If DSA absolutely requires kernel support then I don't think there is much we can do. And I don't think that's a promise anyone could actually make, that we expect mainline support to be fixed in the next 6 months. It might take a year or more for that matter and I wouldn't want to be the one to tell DSA just a couple of weeks more! :) Though to be honest, I think the main issues, disk, network and SATA should already be working, iMX6 is pretty well supported currently, afaik. Rate the other options. (Sponsored kit immediately has a significant advantage :-) Markos- as driver on this, could you summarise the relevant features of odroid, N6x, wanda, utilite?) Speed, specs, cost, remote serial, remote power cycle, mounting, kernel status, availability, power consumption. Anything else important. I'll prepare a wiki page and post here soon. Regards Konstantinos pgpNmoEqtgwZ2.pgp Description: PGP signature
Re: Proposal to replace/extend current armhf builders
On Fri, Nov 15, 2013 at 12:37:15PM +0200, Konstantinos Margaritis wrote: On Fri, 15 Nov 2013 00:23:55 + Wookey woo...@wookware.org wrote: [...] Or Wanda or the Nitrogen6x we've just kindly been offered. Or those, yes. One of the issues is getting boards with more RAM than the current 1GB that the MX53 Locos have, so only the wandboard quad and the utilite fall in that criteria, I see that the Nitrogen6X has only 1GB RAM, so even if it's a nice and tempting offer, I'd still think we need to evaluate this better. It would definitely improve the situation immensely, but builds might still break due to OutOfMemory errors (like iceweasel), but we would definitely get rid of tons of timeout errors that currently need special casing. Surely it adds something to the final price tag but seems the Nitrogen6X boards can be easily upgraded to 2GB: http://boundarydevices.com/products/2gb-ddr3-upgrade-for-nitrogen6x/ So maybe still an option. regards, -- Ricardo Mones ~ Absence of evidence is not evidence of absence. Carl Sagan signature.asc Description: Digital signature
Re: Proposal to replace/extend current armhf builders
Thanks Ricardo, On 11/15/2013 06:18 AM, Ricardo Mones wrote: On Fri, Nov 15, 2013 at 12:37:15PM +0200, Konstantinos Margaritis wrote: On Fri, 15 Nov 2013 00:23:55 + Wookey woo...@wookware.org wrote: [...] Or Wanda or the Nitrogen6x we've just kindly been offered. Or those, yes. One of the issues is getting boards with more RAM than the current 1GB that the MX53 Locos have, so only the wandboard quad and the utilite fall in that criteria, I see that the Nitrogen6X has only 1GB RAM, so even if it's a nice and tempting offer, I'd still think we need to evaluate this better. It would definitely improve the situation immensely, but builds might still break due to OutOfMemory errors (like iceweasel), but we would definitely get rid of tons of timeout errors that currently need special casing. Surely it adds something to the final price tag but seems the Nitrogen6X boards can be easily upgraded to 2GB: http://boundarydevices.com/products/2gb-ddr3-upgrade-for-nitrogen6x/ So maybe still an option. You saved me some time ;) These boards do tend to be out of stock though (we keep underestimating demand). Regards, Eric -- 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/52863a58.7010...@boundarydevices.com
Re: Proposal to replace/extend current armhf builders
I think we need to bash out some criteria for deciding during the mini-debconf. i.e deciding how we decide (or just make a decision if possible). Better to decide now rather than wait for the perfect solution next year (which might have other problems other than price). Better is Good's worst enemy. Wearing my armel buildd maintainer hat, I don't feel the same urgency as you seem to have - perhaps that's because the armel buildd'd are less ram-starved than the locos? e.g hold out for server-grade kit for a while - if so how long? (0 months, 3 months, 6months, longer?) If it was a vote, I'd say get some cheap hardware now to replace the current builders, say costing under an absolute limit of 1000GBP (total: disks, boards, cases, PSU, multiserial terminals, etc). That might even get lower if we accept the Nitrogen6X offer. And reevaluate the situation in 12 months when arm server class becomes available (arm64 or arm32). One thing I'd like to avoid is growing the diversity of buildd's we have. If we have many different buildd hardware, each of buildd classes needs different kind of maintainence. So when add a new type of hw for buildd's, it should go in tandem of getting rid of another type of hw. So if we go with nitrogenx 2GB, are we ready to get rid of locos? Is debian kernel an absolute requirement, or are we prepared to risk a custom kernel if we think it'll only be for 6 months? If DSA absolutely requires kernel support then I don't think there is much we can do. And I don't think that's a promise anyone could actually make, that we expect mainline support to be fixed in the next 6 months. It's not just DSA, it is also in our porters best interests. We don't want to end up in the situtation where glibc/udev/systemd/ruby needs features from a new kernel version, while we are stuck in a old kernel. Riku -- 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/20131115155033.ga23...@afflict.kos.to
Re: Proposal to replace/extend current armhf builders
On Fri, 15 Nov 2013 17:50:33 +0200 Riku Voipio riku.voi...@iki.fi wrote: Wearing my armel buildd maintainer hat, I don't feel the same urgency as you seem to have - perhaps that's because the armel buildd'd are less ram-starved than the locos? Yeah, you're spoiled, iirc, one buildd has 3GB of RAM :P One thing I'd like to avoid is growing the diversity of buildd's we have. If we have many different buildd hardware, each of buildd classes needs different kind of maintainence. So when add a new type of hw for buildd's, it should go in tandem of getting rid of another type of hw. So if we go with nitrogenx 2GB, are we ready to get rid of locos? I can't speak for the rest, but I'd also vote to gradually retire them and send them to interested developers for help in development/porting. I'm also of the same opinion that diversity of buildds should be kept to a minimum. So, in eg. 1 month after deployment of the new systems, retire one loco every week -or all at once, if we're confident the new ones work perfectly. It's not just DSA, it is also in our porters best interests. We don't want to end up in the situtation where glibc/udev/systemd/ruby needs features from a new kernel version, while we are stuck in a old kernel. You're right, but I think this has only happened a couple of times in the past in the case of armhf that is, but can't remember if we were still using FSL kernel or our packaged ones (not that it matters, just saying). So yes, that's a valid point. Konstantinos pgpKugFtNxrDf.pgp Description: PGP signature
Re: Proposal to replace/extend current armhf builders
On Fri, 15 Nov 2013 08:14:32 -0700 Eric Nelson eric.nel...@boundarydevices.com wrote: Surely it adds something to the final price tag but seems the Nitrogen6X boards can be easily upgraded to 2GB: http://boundarydevices.com/products/2gb-ddr3-upgrade-for-nitrogen6x/ So maybe still an option. You saved me some time ;) These boards do tend to be out of stock though (we keep underestimating demand). Oh wow, didn't notice there was an upgrade listed there! In that case, I would vote in favour of your offer! I would expect the Nitrogen boards to be amongst the best in mainline support as they're around the longest. So, how many boards would you be willing to offer? My original suggestion was for 3 odroids + 1 spare in each location, so 5 total, I didn't see any comment about that so far. I guess 3 nitrogen6x +2 spare would also work (+RAM upgrades, which I hope you have readily available!). I'll have to complete the wiki page with the comparison matrix and send back to the list. Even if I personally like this option, I'd still like for a consensus to be reached amongst the developers/porters. But nevertheless thank you for the nice offer! Regards Konstantinos pgp05dOD1h3vU.pgp Description: PGP signature
Re: Proposal to replace/extend current armhf builders
On Fri, Nov 15, 2013 at 05:50:33PM +0200, Riku Voipio wrote: One thing I'd like to avoid is growing the diversity of buildd's we have. If we have many different buildd hardware, each of buildd classes needs different kind of maintainence. So when add a new type of hw for buildd's, it should go in tandem of getting rid of another type of hw. So if we go with nitrogenx 2GB, are we ready to get rid of locos? Possibly, if we're happy that they're stable and supportable. Is debian kernel an absolute requirement, or are we prepared to risk a custom kernel if we think it'll only be for 6 months? If DSA absolutely requires kernel support then I don't think there is much we can do. And I don't think that's a promise anyone could actually make, that we expect mainline support to be fixed in the next 6 months. It's not just DSA, it is also in our porters best interests. We don't want to end up in the situtation where glibc/udev/systemd/ruby needs features from a new kernel version, while we are stuck in a old kernel. Absolutely. We had these issues with the locos fairly soon after we started, and I was worried whether or not we'd get sufficient upstream kernel support to keep them usable. -- Steve McIntyre, Cambridge, UK.st...@einval.com We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs. -- Mike Andrews -- 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/20131115164910.gf14...@einval.com
Re: Proposal to replace/extend current armhf builders
Hi Konstantinos, On 11/15/2013 09:33 AM, Konstantinos Margaritis wrote: On Fri, 15 Nov 2013 08:14:32 -0700 Eric Nelson eric.nel...@boundarydevices.com wrote: Surely it adds something to the final price tag but seems the Nitrogen6X boards can be easily upgraded to 2GB: http://boundarydevices.com/products/2gb-ddr3-upgrade-for-nitrogen6x/ So maybe still an option. You saved me some time ;) These boards do tend to be out of stock though (we keep underestimating demand). I just confirmed that we're 4 weeks out for 2GB boards. If it helps, we can provide a SABRE Lite to whomever will work on getting a build structure together in the interim. Oh wow, didn't notice there was an upgrade listed there! In that case, I would vote in favour of your offer! I would expect the Nitrogen boards to be amongst the best in mainline support as they're around the longest. I can only promise that we'll try. We do tend to spend most of our time tweaking older Freescale kernels, but that's rapidly changing. The Freescale teams have put significant effort into moving things forward. So, how many boards would you be willing to offer? My original suggestion was for 3 odroids + 1 spare in each location, so 5 total, I didn't see any comment about that so far. I guess 3 nitrogen6x +2 spare would also work (+RAM upgrades, which I hope you have readily available!). I'll have to complete the wiki page with the comparison matrix and send back to the list. Even if I personally like this option, I'd still like for a consensus to be reached amongst the developers/porters. Five is no problem, and we'll try to make sure we have some extra 2GiB boards in this next build ;) But nevertheless thank you for the nice offer! You're more than welcome. We're happy for an opportunity to help in a tangible way. Regards, Eric -- 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/52865355.9030...@boundarydevices.com
Unable to boot QNAP TS-119 since update on 12 Nov
Hi there, I was following debian testing on a QNAP TS 119. Since the update late on 12 Nov 2013, I am unable to boot the device. While I haven't been able to root cause my problems, I suspect it might have to do with the kernel update included in that version. I have since then re-flashed the device but haven't gotten around to putting it back on-line. I was wondering whether anybody else has had better results on a similar device (kirkwood chipset) with the current jesse tree, which would point to a misconfiguration on my side. In which case I would consider staying on testing rather than dropping back to stable. Also, I have had the weird 00:00:00:05:0e mac address issue when trying to reflash the device referenced at http://lists.debian.org/debian-arm/2010/05/msg00052.html Unfortunately, I haven't been able to resolve this without re-inserting my HD which would make the QNAP firmware wipe it appearently. Is there any well known way to re-flash a current debian kernel without wiping the contents of the HD? Regards Felix
Re: Unable to boot QNAP TS-119 since update on 12 Nov
* Felix Andreas Braun felix.br...@mail.mcgill.ca [2013-11-15 16:39]: I was following debian testing on a QNAP TS 119. Since the update late on 12 Nov 2013, I am unable to boot the device. While I haven't been able to root cause my problems, I suspect it might have to do with the kernel update included in that version. I take it you have no serial console? Is there any well known way to re-flash a current debian kernel without wiping the contents of the HD? You can generate a recovery image with the old kernel from disk. I thought there were intructions for this on my web site but I just checked and there aren't. :( -- 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/20131115172439.ge3...@jirafa.cyrius.com
Re: Debian arm on WD Sharespace
Hi Todor, * Todor Milkotev todor.a.milko...@gmail.com [2013-11-14 15:18]: Instead of upgrading the kernel I guess it will be better if I just go with: http://www.cyrius.com/debian/ (kirkwood or orion ?!?). Unfortunately, that won't work for you on the WD device. ARM is not like PCs, where one installation image will pretty much work on any PC. Debian doesn't have support for the WD Sharespace. -- 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/20131115173232.gf3...@jirafa.cyrius.com
Re: Proposal to replace/extend current armhf builders
Hello, 2013/11/15 Konstantinos Margaritis mar...@freevec.org: Riku Voipio riku.voi...@iki.fi wrote: Wearing my armel buildd maintainer hat, I don't feel the same urgency as you seem to have - perhaps that's because the armel buildd'd are less ram-starved than the locos? Yeah, you're spoiled, iirc, one buildd has 3GB of RAM :P To add up more options, we received a donation offer from OpenBlocks people as well, those machines have an ArmadaXP SoC and have miniPCI slot to extend hardware up to 3GB RAM. Nobuhiro and Thomas Petazzoni have been doing great work mainlining stuff. Openblocks donation was done at the beginning of the current year (or end of last year), but we rejected it in the hope to move to server class hardware. On the other side of things, Boston guys are aware of our interests and they need to do some internal discussion and maybe allocate some budget for special price or donation, I'll come back with more once they let us know. Also, it appears to be that thanks to midways coming up soon, highbanks might get under used by Linaro team, and they might be able to donate/sponsor some (I asked them for 10) nodes for Debian. I would also like to thank the kind offer from Boundary devices. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- 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/caodfwef4_scccrj8rclaz+esjkja3pmec8zobcvjbq-vbrj...@mail.gmail.com
Re: Further trimming of ARM NAS kernel images
Hello Ben, 2013/11/11 Ben Hutchings b...@decadent.org.uk: As the Linux kernel has continued to grow, in Linux 3.12 the iop32x and ixp4xx kernel images have again exceeded the size limits for the target machines. [Note, all figures here are based on the emdebian gcc-4.7 cross-compiler whereas we'll actually use the gcc-4.8 compiler for the packages, and refer to the zImage size.] iop32x is about 13K over-size and ixp4xx about 5K over-size. I've therefore disabled the following features (approximate reduction in size): - BPF_JIT (3K) - MEMCG (7K) - USER_NS (5K) (newly enabled for 3.12 for other configurations) The kernel is likely to carry on growing, so further optional features will probably still need to be dropped if these flavours are to be included in jessie, possibly large ones such as: - AUDIT, SELINUX (~50K) - KALLSYMS (~150K) This really is the last time I will work on this; next time this happens Thanks for all the work done until now. I will drop these flavours until someone provides configuration changes to fix them. The same goes for orion5x, although that currently has about 30K to spare. Please, drop those flavours when that happens, do not waste more time fixing obsolete platforms. Hereby, I would like to suggest to already drop ixp4xx as that kernel was meant to run on Slugs, which have been removed from Debian Installer and replaced with more modern kirkwood devices as the *plugs. Regards -- 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/CAODfWeFT1U1N=mz0bnzeoxqb1wzpp296sqpx1+8p0j9z2py...@mail.gmail.com
Re: Unable to boot QNAP TS-119 since update on 12 Nov
I can make my ts 119 kernel image available for download. Would that help? It's wheezy. (Skickat från min telefon == Sent from my phone) On Nov 15, 2013 6:25 PM, Martin Michlmayr t...@cyrius.com wrote: * Felix Andreas Braun felix.br...@mail.mcgill.ca [2013-11-15 16:39]: I was following debian testing on a QNAP TS 119. Since the update late on 12 Nov 2013, I am unable to boot the device. While I haven't been able to root cause my problems, I suspect it might have to do with the kernel update included in that version. I take it you have no serial console? Is there any well known way to re-flash a current debian kernel without wiping the contents of the HD? You can generate a recovery image with the old kernel from disk. I thought there were intructions for this on my web site but I just checked and there aren't. :( -- 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/20131115172439.ge3...@jirafa.cyrius.com
Re: Proposal to replace/extend current armhf builders
On Fri, 15 Nov 2013 20:23:58 +0100 Hector Oron hector.o...@gmail.com wrote: To add up more options, we received a donation offer from OpenBlocks people as well, those machines have an ArmadaXP SoC and have miniPCI slot to extend hardware up to 3GB RAM. Nobuhiro and Thomas Petazzoni have been doing great work mainlining stuff. Openblocks donation was done at the beginning of the current year (or end of last year), but we rejected it in the hope to move to server class hardware. OpenBlocks is nice, but I think it's going to be slower than any quad iMX6, though SATA2 and 3GB of RAM is tempting. Not having NEON however, I think that's a slight drawback (I know NEON is not required for the port specs, but some package might have a NEON testcase to run, eg gcc). Not fatal, but would just like to make the point. On the other side of things, Boston guys are aware of our interests and they need to do some internal discussion and maybe allocate some budget for special price or donation, I'll come back with more once they let us know. Also, it appears to be that thanks to midways coming up soon, highbanks might get under used by Linaro team, and they might be able to donate/sponsor some (I asked them for 10) nodes for Debian. That is good news, 10 nodes, doesn't each board contain 4 nodes or have I got that wrong (so 2.5 boards)? These highbanks *are* the Calxeda blades right, or is this a different thing? Could you please give more details on this (eg. systems would be actually donated to Debian, or not, physical access allowed, etc). When is that more likely to happen, if you could give an estimate? Regards Konstantinos pgp2RnkjpXEDj.pgp Description: PGP signature
Re: Proposal to replace/extend current armhf builders
Hello, 2013/11/15 Konstantinos Margaritis mar...@freevec.org: On the other side of things, Boston guys are aware of our interests and they need to do some internal discussion and maybe allocate some budget for special price or donation, I'll come back with more once they let us know. Also, it appears to be that thanks to midways coming up soon, highbanks might get under used by Linaro team, and they might be able to donate/sponsor some (I asked them for 10) nodes for Debian. That is good news, 10 nodes, doesn't each board contain 4 nodes or have I got that wrong (so 2.5 boards)? These highbanks *are* the Calxeda blades right, or is this a different thing? Could you please give more details on this (eg. systems would be actually donated to Debian, or not, physical access allowed, etc). When is that more likely to happen, if you could give an estimate? A board has 4 nodes, but we are speaking on shareable machine with 48 nodes hosted by (potential) donator. Highbank is Calxeda blade based on cortex A9, Midway has Cortex A15 (and extra RAM, ~8GB). I cannot give more details, as soon as I heard back from Boston, they warned it might take over 2 weeks, I'll come back with the options they propose. It might take some time, however we do not urge on getting armhf hardware. Cheers, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. PS./ I read on the thread backlog iceweasel ftbfs on sid... note it builds on experimental, on a more recent version. https://buildd.debian.org/status/fetch.php?pkg=iceweaselarch=armhfver=25.0-1stamp=1384006368 -- 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/CAODfWeEX72JP1j+c9XEqnj=R2cUnMQaq2EdWavSw7O=qpmg...@mail.gmail.com
Re: Proposal to replace/extend current armhf builders
Steve McIntyre wrote: if we're happy that they're stable and supportable. Having had a 2GB nitrogen6x running as a raspbian buildd for a while I would consider it stable and supportable. We did have some crashes on both the nitrogen6x and the wandboard quad caused by the eglibc testsuite in the past but since upgrading to 3.11.0-armv7-x13 that seems to have stopped happening. Adding a heatsink is reccomended, the IMX6 gets bloody hot without one. http://uk.farnell.com/jsp/search/productdetail.jsp?SKU=2084441 Kernel wise I currently run one of robert nelsons mainstream based kernels (partly so I can run the same kernel on my nitrogen6x and my wandboard quads). I'd be happy to test a debian kernel though if people want (now I have the four wanboards at bytemark I can more easilly afford to pull the test autobuilders out of the pool for testing stuff). Bootloader wise I patched up uboot to combine the support for booting plain zimages/initrds (I HATE uImages) with support for the 2GB nitrogen6x. I posted details of this to debian-arm some time back. The board boots up immediately on power on so remote power control would be easy enough to accomplish either by giving each board a seperate PSU and plugging them into a switchable PDU or by using a networkable relay board. Serial is RS232 levels and the board comes with a cable that brings the serial ports out to 9 way D connectors (specifically female ones with DCE wiring) so serial console should be easy enough. The board is similar enough to a sabre lite that it will boot and key hardware (serial console, sata, network) will work with the sabre lite device tree file. Indeed that is how i'm running mine at the moment. Overall i'd say the board ticks all the important boxes for an autobuilder. The reasons I picked the wandboard quad instead of the nitrogen6x for raspbian were price (which is not an issue if the boards are donated) and physical size (which AIUI is not a massive deal for the hosting arrangements debian has). -- 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/5286c445.8080...@p10link.net
Re: Proposal to replace/extend current armhf builders
Thanks for the details Peter, On 11/15/2013 06:03 PM, peter green wrote: Steve McIntyre wrote: if we're happy that they're stable and supportable. Having had a 2GB nitrogen6x running as a raspbian buildd for a while I would consider it stable and supportable. We did have some crashes on both the nitrogen6x and the wandboard quad caused by the eglibc testsuite in the past but since upgrading to 3.11.0-armv7-x13 that seems to have stopped happening. Adding a heatsink is reccomended, the IMX6 gets bloody hot without one. http://uk.farnell.com/jsp/search/productdetail.jsp?SKU=2084441 We have those in stock. Kernel wise I currently run one of robert nelsons mainstream based kernels (partly so I can run the same kernel on my nitrogen6x and my wandboard quads). I'd be happy to test a debian kernel though if people want (now I have the four wanboards at bytemark I can more easilly afford to pull the test autobuilders out of the pool for testing stuff). Bootloader wise I patched up uboot to combine the support for booting plain zimages/initrds (I HATE uImages) with support for the 2GB nitrogen6x. I posted details of this to debian-arm some time back. Note that these are now in main-line U-Boot. Regards, Eric -- 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/5286c832.80...@boundarydevices.com
Re: Proposal to replace/extend current armhf builders
On Fri, Nov 15, 2013 at 7:03 PM, peter green plugw...@p10link.net wrote: Steve McIntyre wrote: if we're happy that they're stable and supportable. Having had a 2GB nitrogen6x running as a raspbian buildd for a while I would consider it stable and supportable. We did have some crashes on both the nitrogen6x and the wandboard quad caused by the eglibc testsuite in the past but since upgrading to 3.11.0-armv7-x13 that seems to have stopped happening. Adding a heatsink is reccomended, the IMX6 gets bloody hot without one. http://uk.farnell.com/jsp/search/productdetail.jsp?SKU=2084441 Kernel wise I currently run one of robert nelsons mainstream based kernels (partly so I can run the same kernel on my nitrogen6x and my wandboard quads). I'd be happy to test a debian kernel though if people want (now I have the four wanboards at bytemark I can more easilly afford to pull the test autobuilders out of the pool for testing stuff). Once debian's pushes out a v3.12.x armmp final it should be pretty close to my patched v3.11.x based kernel your running now, as i essentially pulled in most of the imx for-next branch.. Btw, one thing I've noticed on the wand quad's, with v3.12.x they seem more stable if you just force the performance cpufreq, for some reason mine keep having sata/cpufreq kernel dumps. (the sata drives might be failing too thou, they've been abused over the years on lots of random arm usb/sata hardware...) Otherwise the sabrelite/nitrogen6x's have been rock solid.. Bootloader wise I patched up uboot to combine the support for booting plain zimages/initrds (I HATE uImages) with support for the 2GB nitrogen6x. I posted details of this to debian-arm some time back. The board boots up immediately on power on so remote power control would be easy enough to accomplish either by giving each board a seperate PSU and plugging them into a switchable PDU or by using a networkable relay board. Serial is RS232 levels and the board comes with a cable that brings the serial ports out to 9 way D connectors (specifically female ones with DCE wiring) so serial console should be easy enough. The board is similar enough to a sabre lite that it will boot and key hardware (serial console, sata, network) will work with the sabre lite device tree file. Indeed that is how i'm running mine at the moment. Overall i'd say the board ticks all the important boxes for an autobuilder. The reasons I picked the wandboard quad instead of the nitrogen6x for raspbian were price (which is not an issue if the boards are donated) and physical size (which AIUI is not a massive deal for the hosting arrangements debian has). Regards, -- Robert Nelson http://www.rcn-ee.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/CAOCHtYi6pyAsSy8n5zkM8JQZfPvqqPpc294U7=dwb0+6xhz...@mail.gmail.com
AW: Unable to boot QNAP TS-119 since update on 12 Nov
* Martin Michlmayr t...@cyrius.com [2013-11-15 18:24]: * Felix Andreas Braun felix.br...@mail.mcgill.ca [2013-11-15 16:39]: I was following debian testing on a QNAP TS 119. Since the update late on 12 Nov 2013, I am unable to boot the device. While I haven't been able to root cause my problems, I suspect it might have to do with the kernel update included in that version. I take it you have no serial console? Sorry no. I'm also not very good at soldering. -- 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/126f2941065a084bbf03c60fe296864c2bc47...@exmbx2010-2.campus.mcgill.ca
AW: Unable to boot QNAP TS-119 since update on 12 Nov
* Björn Wetterbom wrote on 2013-11-15 21:06 * Felix Andreas Braun felix.br...@mail.mcgill.ca [2013-11-15 16:39]: I was following debian testing on a QNAP TS 119. Since the update late on 12 Nov 2013, I am unable to boot the device. While I haven't been able to root cause my problems, I suspect it might have to do with the kernel update included in that version. I can make my ts 119 kernel image available for download. Would that help? It's wheezy. If you could export the entire contents of your flash cat /dev/mtdblock0 /dev/mtdblock4 /dev/mtdblock5 /dev/mtdblock1 /dev/mtdblock2 /dev/mtdblock3 F_TS-119_debian and make that available for download, so that I can directly flash it, then that might spare me the process of having my disk wiped by the original firmware and re-installing from scratch. However, I'm not sure the boot will succeed (at least until sshd is started) if the flash doesn't match the debian version on disk. Martin? Thanks anyway for your offer. Regards Felix -- 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/126f2941065a084bbf03c60fe296864c2bc47...@exmbx2010-2.campus.mcgill.ca
