Re: Boot time speed up
Sound advice. You might also investigate systemd, which makes it a little easier to start services in parallel and/or on demand rather than all at once. b.g. On Apr 17, 2014 3:41 AM, "David Hicks" wrote: > > Unsure what the specifics are for your system but I'd recommend attempting to install 'bootchart' (should be as simple as apt-get install boothart) and seeing what's using most of the time during boot, so you can figure out what it is you want to optimise. > > Another generally good idea would be to review all the services that are installed by default and see if you can remove any. You might not need them all and while each one may not have a huge impact on boot time, if you remove a few that you don't need you could see some improvement. > > > On Thu, Apr 17, 2014 at 5:28 AM, Divya Subramanian < divyaenginee...@gmail.com> wrote: >> >> Any other way of cutting down boot time? >> >> Regards, >> >> Divya Subramanian >> >> >> On Wed, Apr 16, 2014 at 7:10 PM, David Hicks wrote: >>> >>> >> The initramfs isn't the source of the slowdown, unless you have a really huge one. >>> >>> It could be a part of it, though maybe not a massive part. On my hacked up NAS uboot takes a few seconds to copy the initramfs from onboard NAND into the system RAM before it launches the kernel. If you ditched ramfs you could cut those few seconds out. It's not masses I suppose >>> >>> >>> On Tue, Apr 15, 2014 at 5:35 PM, Bill Gatliff wrote: >>>> >>>> >>>> On Fri, Apr 11, 2014 at 8:42 AM, David Hicks wrote: >>>>> >>>>> I'm not exactly the foremost expert on this but ... my understanding is that the initramfs, or initrd or whatever it is, contains a bunch of useful things the kernel needs to boot the board fully. Primarily these include hardware driver modules needed by the kernel ahead of when the main filesystem becomes available. For instance disk controllers and filesystem drivers. >>>>> >>>>> One way to reduce the use of the initramfs/initrd is to build a kernel that has the drivers you need built into it rather than loaded as modules from the ramfs. You would need to build a custom kernel (relatively easy with debian already on the device and using make-kpkg) with the kernel config customised to achieve this. >>>>> >>>>> I have no idea how much this would speed up boot time, if at all. You also lose some of the other benefits of using an initramfs/initrd, which I'm having trouble remembering right now. (recovery shell? various scripts for mdadm/lve? stuff...) >>>> >>>> >>>> Actually, baking the necessary modules into the kernel rather than loading them from initramfs would speed things up quite a bit, especially if the modules are demand-loaded. Reasons include the fact that you'd be doing the linking at build-time on your fast PC, rather than at run-time on a slow(er) ARM core. >>>> >>>> The initramfs isn't the source of the slowdown, unless you have a really huge one. The bootloader already has to load the kernel, and having the filesystem in RAM at the same time will usually speed things along. At least until you have to scour the eMMC to find the final root filesystem, but there's no avoiding that really... >>>> >>>> Granted, you can put things into initramfs that DO slow you down: hardware probing, lack of parallelism, sleeps, lots of shell scripts, and so on. But the initramfs concept itself doesn't present any speed issues. >>>> >>>> I haven't looked at Debian's initramfs lately, since I tend to build my own. But since Debian favors generalism over performance (as they should), it wouldn't surprise me to see one built from the ordinary Debian tools that drags its feet a lot before going to the user prompt. >>>> >>>> >>>> b.g. >>>> -- >>>> Bill Gatliff >>>> b...@billgatliff.com >>> >>> >> >
Re: Boot time speed up
On Fri, Apr 11, 2014 at 8:42 AM, David Hicks wrote: > I'm not exactly the foremost expert on this but ... my understanding is > that the initramfs, or initrd or whatever it is, contains a bunch of useful > things the kernel needs to boot the board fully. Primarily these include > hardware driver modules needed by the kernel ahead of when the main > filesystem becomes available. For instance disk controllers and filesystem > drivers. > > One way to reduce the use of the initramfs/initrd is to build a kernel > that has the drivers you need built into it rather than loaded as modules > from the ramfs. You would need to build a custom kernel (relatively easy > with debian already on the device and using make-kpkg) with the kernel > config customised to achieve this. > > I have no idea how much this would speed up boot time, if at all. You also > lose some of the other benefits of using an initramfs/initrd, which I'm > having trouble remembering right now. (recovery shell? various scripts for > mdadm/lve? stuff...) > Actually, baking the necessary modules into the kernel rather than loading them from initramfs would speed things up quite a bit, especially if the modules are demand-loaded. Reasons include the fact that you'd be doing the linking at build-time on your fast PC, rather than at run-time on a slow(er) ARM core. The initramfs isn't the source of the slowdown, unless you have a really huge one. The bootloader already has to load the kernel, and having the filesystem in RAM at the same time will usually speed things along. At least until you have to scour the eMMC to find the final root filesystem, but there's no avoiding that really... Granted, you can put things into initramfs that DO slow you down: hardware probing, lack of parallelism, sleeps, lots of shell scripts, and so on. But the initramfs concept itself doesn't present any speed issues. I haven't looked at Debian's initramfs lately, since I tend to build my own. But since Debian favors generalism over performance (as they should), it wouldn't surprise me to see one built from the ordinary Debian tools that drags its feet a lot before going to the user prompt. b.g. -- Bill Gatliff b...@billgatliff.com
Re: Arm bof and raspbian.
On Fri, Aug 16, 2013 at 12:39 PM, Wookey wrote: > > Thoughts? > > Wookey > Trick question, right? I mean, it looks like such a straightforward solution that I can't believe there isn't some kind of hidden gotcha in there somewhere... :-) It even has me asking why we don't do this kind of thing more often, for nuanced configurations that aren't appropriate or just aren't ready for mainline Debian. I don't buy any objection based on "fragmentation", since the tools were intended to be used like this anyway. How else would Debian be the most ISA-friendly distribution on the planet, even without its glacial pace of development(*)? * - The "glacial" attribution is largely cultural in my mind. So much of Debian is so stable and functional already, it's hard to keep coming up new-and-shiny things to add to it that would merit a whole new named release. I don't have a problem with that. Now let's start using those great tools to promote and embrace ecosystem diversity, rather than trying to decide what e.g. a one-true-ARM configuration has to look like. We don't have to leave anyone behind, really... b.g. -- Bill Gatliff b...@billgatliff.com
Re: Plug computer with two eth
On Sun, Mar 3, 2013 at 9:26 AM, Ted To wrote: > Globalscale has a couple with two ethernet ports but they are not as cheap > as the typical plug computer. Never used one so I can't tell you much else. I'm ambivalent to the Globalscale Dreamplug. I purchased one, and was VERY pleased that it came with Debian already pre-installed. But I was greatly concerned from the beginning at how hot it runs, so I have been careful to keep it well-ventilated. About two months of putting it into service, it started OOPSing with command timeouts from the internal SD card. And they got progressively quicker as time marched on. The thing is basically unusable after three months. I don't know if this issue is heat-related, but I can't help but wonder. Especially since the system boots and runs fine when it's cool, and I haven't seen any OOPSes until things are fairly well heat-soaked and I'm leaning on the filesystem (apt-get update, etc.). Have raised the issue with Globalscale support, still awaiting a response. In the big picture, I've got lots of examples of hardware here that isn't commercially available, but could do the job AND doesn't run hot to the touch. I don't understand why this device (and just about every other Marvell chip I have ever encountered) has to kick out so much heat. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcautzzz_qze8+v6dmvv71vh7fbmxmmhtoqvuu1g6+q1z...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Thu, Feb 28, 2013 at 4:32 PM, Lennart Sorensen wrote: > > So I can see why makers of cell phones and tablets just don't care. I wouldn't say that they don't care. Rather, (a) Google and Android gave them some spectacularly bad models to follow, which they are because it's both the path of least-resistance and there aren't any ready-made better alternatives; and (b) they're always behind schedule, and the margins are thin enough that there isn't much opportunity for fixing tomorrow's problems today. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcaut+l8unujpvupphjxkzjn13kcexvofr3ayjwcijbee...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card (or rather arguing over what a boot loader should do)
On Thu, Feb 28, 2013 at 1:47 PM, Lennart Sorensen wrote: > > I think the big difference is: Some of us design it to not go wrong. > Some of us design it to make it easy to fix when something goes wrong. > Different philosophy. With all due respect, I'll just say this: it WILL go wrong. There is no point designing for a universe where things will not go wrong, because that universe simply does not exist. So if your plan does not include an accommodation for that, your system is fundamentally incomplete. End of story. > To some users, something going wrong really isn't appreaciated and it > should really be designed to avoid that. Simply reloading the box > isn't good enough. Again, in the real world things simply go wrong: hardware failures, buggy code, unstable power supplies, butterflies, and so on. You must be prepared to deal with them. Users are far more accepting of the inevitable failure when they also see that you have planned for it and already have a recovery strategy in place. That's professionalism. b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAusHk34tZnmSSh4Ofq_JTudSjZ705HtYbcp6LgRG4Q=b...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Thu, Feb 28, 2013 at 1:38 PM, Lennart Sorensen wrote: > > Of course it would seem that if the HTC phones are that different from > each other while doing essentially the same things, then the hardware > designers are designing them wrong. If they don't have to be different, > then they shouldn't be different. There you go, trying to simplify the universe again. :-) The phones in question are already designed. The unicorn has already left the castle. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcautbq+hr5ntji48vvvdhh0gpddnwsitu0fmyvdv72as...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card (or rather arguing over what a boot loader should do)
On Thu, Feb 28, 2013 at 1:32 PM, Luke Kenneth Casson Leighton wrote: > > there is absolutely no reason why this application should not read a > linux kernel + initrd and execute that instead of u-boot. > > the point i'm making is: the exact same technique could be deployed > on any other hardware, again making it completely unnecessary to make > a dog's dinner out of u-boot or pollute the linux kernel itself with > yet more low-level initialisation. This. As in, "what he said". And if the kernel+initramfs that it loads ends with an optional kexec and/or pivot_root, then the end user sees the overall experience as the platform "booting" their kernel from /boot in their filesystem. What's more, when the end user wants to update their kernel, it's a simple apt-get just like every other program file in the system. And if something goes horribly wrong, they see a super-smart "bootloader" (the aforementioned kernel+initramfs) doing a wget, multistrap, ssh, throwing up a web page, or something else intelligent to help them get things back into line. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcaustlxgbewudcu9s_aoq-aqa6om+t6atb674yocnxyq...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
On Thu, Feb 28, 2013 at 1:24 PM, Luke Kenneth Casson Leighton wrote: > On Thu, Feb 28, 2013 at 3:14 PM, Lennart Sorensen > wrote: > > all that devicetree has done is move the problem, as well as add a > runtime overhead to the execution of resource-critical devices. > > not very clever, that. Part of me regrets being as positive about DT as I was on LAK back when the decision was made. But I had just come off of a PowerPC project, and it worked pretty well there and so I figured, "why not?". I do think that DT is a good idea, and the runtime overhead is a manageable problem. But it's a good idea because it creates the opportunity for post-compile-time flexibility, which CAN make some board files go away. Not nearly as many as some of us thought they would however, and not without effort. A related problem is that about 80% of what goes on in most ARM board files should be done as module_init(), not board_init(). If we were to be more vigilant about that, then DT would have more chances to improve things. What were we talking about, again? :-) b.g. -- Bill Gatliff b...@billgatliff.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/cadkcauvatomenrobcs2ofjzkxsuu7v-mpse9vuratwesgcc...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card (or rather arguing over what a boot loader should do)
On Thu, Feb 28, 2013 at 1:03 PM, Luke Kenneth Casson Leighton wrote: > > u-boot began as a mind-f**k merge of parts of uclibc (or equivalent), > some userspace code and the linux kernel. Awww. That's about the nicest thing I've heard anyone say about u-boot in a long time. :-) (I don't hate u-boot, I just hate the monster people are always trying to turn it into). > the problem lennart is that in order to do enough "bring-up" to do > the kinds of tasks that you're expecting to do - such as initialise a > screen, a usb, a serial, an sd/mmc, a this, a that - you actually need > to do *exactly* the same job that the linux kernel already does. Precisely! > [except that there happens to be in some devices some additional > low-level initialisation such as "bring up the DDR3 RAM interface and > tell it to switch on and to use 8 banks of 4 @ a clock rate of 400mhz" > and so on, but those kinds of things aren't that hard to add to the > linux kernel early initialisation phase...] I'm not insisting that we have to bring all this stuff into Linux too. In fact, keeping some of these details hidden away inside a true bootloader is often a good idea because some low-level hardware details Linux just doesn't care about, or they have to be addressed before the hardware can deal with the large memory footprint that Linux requires. In such cases it's essential that you pass the hardware identifier and bootloader version strings forward in the kernel command line, so that the kernel and userspace gain visibility to those details should they need them (and mine always seem to at some point). > using kexec actually allows you to write a boot-up application in > userspace, and test it in userspace. ... and deploy it in userspace, in the form of a kernel+initramfs. In essence, it becomes what the end user sees as "the bootloader". b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAusUMdg+rBM3FMdtr4n41o_Jqqt9bgZykSwdH=mft+l...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
Lennart: On Thu, Feb 28, 2013 at 9:14 AM, Lennart Sorensen wrote: > > That bit would be tricky unless you had a part of your storage that was > never written to that contained the code to boot when nothing else worked. At some point, that's essential. And since you can't change it, you want the LOC for that part to be as small as possible so that you reduce your exposure to defects. That means stripping out everything you can live without. A brain-dead simple u-boot is just fine here, since in the nominal case all it needs to do is pull a kernel+initramfs into memory from a predictable location. That kernel+initramfs is also unlikely to change, at least in my case, because I almost always have enough storage to keep the customer's own kernel and rootfs elsewhere. When I find that (detected by a /boot/zImage in the customer filesystem, for example) I kexec to it. So the customer "updates the kernel" in the device via an ordinary package installation, just like a workstation. But unlike a workstation, the customer doesn't have to worry about really screwing up the system because their kernel isn't the one responsible for initially bringing the core platform to life. On the other hand, I don't have to worry about bringing a kernel that can do EVERYTHING the customer wants it to do, because I know that they can just supplement the system with their own kernel once they decide to do so. The job for my kernel+initramfs is, in most cases, to provide a bare minimum of functionality that either gets me to their kernel, or allows the platform to "phone home" to restore the user's filesystem if necessary. (Kind of like what the recovery partition does on an Android device, but implemented differently). But if things go really bad, and that kernel+initramfs is somehow lost, then it's ok to be much more restrictive about the recovery process since it's a much less likely event. I'll do a board swap, tftp, or something similar. > There is no need to do things 500 different ways. Maybe 10 or 20 > different ways is sufficient (certainly 1 way is likely to be too > restrictive). Agreed. But to be clear, I think what you and I are defining as "different ways" may in fact be different. You and I both run Debian workstations, and both behave in generally the same way even though we both probably have significant differences in e.g. how our networks are set up. And yet we can still manage both machines with the same packaging concepts and sysadmin procedures. Thus, from one perspective our machines are identical: the underlying framework. But we use are using that identical framework to achieve different work products, which is precisely what the framework was designed to allow. I have found that the Debian Way is pretty much the One True Way for dealing robustly with a shockingly wide range of use cases, both yours and mine. I'm just saying that rather than crowding it out by making larger and more functional bootloaders, we should consider going the opposite direction: "debianizing" more and more of what we now think of as the bootloader concept, and marginalizing our true bootloaders farther and farther into the background where they came from. The Debian installer is another instance of what I'm talking about: it sits above the hardware, and does intelligent things. Then it hands control over to the filesystem after it decides everything is ready to go. In fact, it was kind of my inspiration. > Diversity does not mean sprawl is required. Correct. Debian is proof of that. Your workstation, compared to mine, is proof of that. As are all the devices I have here that are running Debian-like configurations, none of which look or act like workstations at all. (The one downside? They all look so similar here that I have to be very careful when I issue a reboot command over SSH. Whoops, wrong target!) > I really hope the ARM servers can do something sane so that they have > a common interface for installation and booting. If they don't I doubt > they will ever be taken seriously. That would be a shame. I agree! But "server" is just one use case, and ARM is a broadly applicable family of SoCs that does way more than server workloads. If we are smart about it, we can accommodate a lot of those use cases within a consistent, flexible, and sane framework. Some of us already are. The n2100/n4100 devices are a perfect example of a server-like device that was almost perfectly-executed from a Debian perspective. The only flaw, in my opinion, is that the startup sequence depends on having just one kernel in the system, and that kernel has to live in flash. If that kernel+initramfs instead just did a kexec+pivot_root over to whatever it found on disk, I could put my serial cables away forever. Martin Michlmayr is really, really good. But I th
Re: iMX6 EOMA-68 CPU Card
Lennart: On Wed, Feb 27, 2013 at 2:00 PM, Lennart Sorensen wrote: > I really think that one way could work for all, including what you are > doing. Yes. For example, the approach I described. :-) > No one says that firmware has to be as slow as many PCs seem to > be able to make it. I remember my 486 hit grub in under 3 seconds from > power on. It can be done. It isn't always about speed per se, but it is always about flexibility without fundamentally destabilizing the fundamentals of the system. Consider what it would take to modify grub so that if it didn't find a filesystem, after checking in several places, then it would phone home over all available network connections in including any USB ethernet adapters. And then consider how you would facilitate a new developer changing that code without breaking it. > I do think that there are way too many different ways done on arm systems, > and most arm systems end up in a state of not being supported because > they are all different and the manufacturer often doesn't care once they > have shipped the product. Nah, don't drink the kool-aid. This diversity is good when the alternative is locking us into a BIOS-like universe that says e.g. Thou Shalt Frame Your Solution Like A Tablet Computer. > I know for powerpc, the linux kernel made it quite clear that no new > powerpc system would be accepted if it didn't use devicetree (some of > the first IBM powerpc systems supported in linux did something messy > and very different and not scalable at all). ARM has managed to be > a mess for years now, with every system doing its own thing, which > certainly explains why Linus had a bit of a temper explosion over the > state of ARM last year. I think the origins of Linus' tantrum lie in a misunderstanding of the problems that ARM machines face (a point I made on LKML and LAK back in the day). The solution isn't to demand that all problems must be solved in the same way; rather, it's to bring an infrastructure that isn't so brittle. You can't simplify the universe. The "mess" you see in ARM isn't the problem, it's merely a symptom of the problem. Devicetree is a step in the right direction, but basically because it brings two fundamentally different capabilities: you can describe the device model in something that doesn't require kernel recompilation to change, and you can describe the device model in something that you can parse pre-kernel boot. But I digress... b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAuuF8QgChtAkjHsoQj=sbqrrrsxcwiu1zjesvghjhx0...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
Lennart: On Wed, Feb 27, 2013 at 12:54 PM, Lennart Sorensen wrote: > > What you are doing is to me a terrible idea that I hate and have always > hated. I hated it on the netwinder in the late 90s, I hated it on the > alpha in the form of MILO. They were always getting out of date and > would be unable to boot newer kernels and they were difficult if not > impossible to get the full source code for in many cases (A problem I > hope you are at least avoiding). I think you and I might be solving different problems, hence your disagreement. And while I have a certain gut-level negative reaction to the notion of BIOS in all forms, I can see that in the cases you have mentioned it would genuinely be helpful. In my case, however, your approach is going completely in the wrong direction and I have a decade of personal experience with its implications to back that up. And I think that the majority (but by no means all) of ARM CPU adopters would find it counterproductive as well. I'm not saying you are fundamentally wrong, only that there is a very large part of your target audience that would find a different approach more helpful. Your suggestion is great for a platform that has a uniformity of installation use cases e.g. workstation-like, tablet-like, cell-phone-like, media-center-like devices. They are all variations on a few common themes, and within some limits a standardized base platform configuration is helpful to the application stack and vise versa. And both can be generalized to the point where a lot of the details just don't matter. The problem and solution have both been been well-framed, in other words. By the numbers, however, a substantial set of ARM users are delivering highly-differentiated devices where a cookie-cutter approach just won't work. My devices are in the control and/or data visualization paths for factory automation equipment, spacecraft, aircraft, trains, medical devices, earth-moving equipment, set-top boxes, and such (all true, by the way). There is no one-size-fits-all possibility, and there's no substitute for a system architecture that can be safely adapted---even in the extreme---to meet the fundamental requirements of the overall application: boot times well under a second, in some cases; layered, possibly concurrent operational modes; fallback operation for dealing with several different types of failures including watchdog timeouts in both software and hardware; and so on. What's super-cool about Debian is that if you use it well, it can be safely adapted---even in the extreme---to meet many of those use cases. But that possible only if you as much as you can inside the concepts of Debian, and as little as possible elsewhere. And that's why if you are going to make me use a BIOS, it's going to look like Linux+initramfs that eventually pivot-roots into Debian. You can deliver the platform already configured like that, or I will get out my JTAG adapter. Because I have learned through trial and error that eventually, something like u-boot or a BIOS will get in the way because it represents a chunk of code that and design decisions that I'm forbidden to adapt to my own needs in the moment. It becomes an all-or-nothing proposition, and I take the latter because I work at that level now. One other thing. If I have a Linux+initramfs with enough code to "phone home" and wget an initial filesystem image or the Debian installer, then I don't even need the JTAG adapter. I just tell the user in Nowheredistan to hook the thing to the internet, and hold down a button at boot. Then multistrap takes over from there. ... which is kinda cool even for a workstation or a media device. Which is why I end up back at making Linux+initramfs my BIOS for all ARM machines, even though I started this conversation by agreeing with you. I'm not making any of this up: it's how I do business. And again, I'm not saying your approach is objectively wrong. I'm just saying that nowadays, there are some really interesting alternatives once we break free of the traditional notion of "bootloader". I'm done now. :-) b.g. -- 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/CADkCAuuYwRB57cOK35KpC1pMjvSsbL3Rr=2jbyasz9ov0em...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
Lennart: On Wed, Feb 27, 2013 at 12:29 PM, Lennart Sorensen wrote: > > Well a standard firmware that initialized hardware and then calls a > dedicated bootloader like grub that resides on sata is certainly very > convinient and I wish arm boards would start doing something like that. > I am not sure they will ever get taken seriously in the server market > if they don't. openfirmware seems to do that nicely on powerpc and > sparc systems (and I believe some mips systems too). No reason arm > couldn't do that too (and of course switch to devicetree for passing > info about the system to the kernel at the same time). Thing is, by the time you make a bootloader that intelligent, you are well on your way to reinventing the things Linux+initramfs can already do better---and that's even before you consider the device driver implications. That's why I tend to go that route, rather than making a super-bootloader. b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAuuX36FQwAYfW6-vBFWC=FR=x2hiskqp7kyxhnhem8n...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
Guys: On Wed, Feb 27, 2013 at 9:50 AM, Lennart Sorensen wrote: > On Wed, Feb 27, 2013 at 12:51:13AM +, luke.leighton wrote: >> http://rhombus-tech.net/freescale/iMX6/news/ > > I know the iMX53 boots from SD. Not sure what the iMX6 boots from. > As long as I can use SATA for my filesystem and only have to put the > boot loader somewhere (although on SATA would be by far the most ideal), > then NAND flash is of no interest what so ever. My vote would go in the exact opposite direction: the board has to boot from NAND (or eMMC), and then step over to SATA if present. Among other things, that makes it realistic that a new developer boots it by merely plugging in the USB cable for the serial console. And don't go all u-boot on me, either, except as a quick jump to a Linux kernel+initramfs that most developers will see as the real "bootloader". That lets you use usb-storage to manage the NAND partitions, SATA if connected, SSH/telnet to the "bootloader", and so on. And then kexec to the developer's kernel if they provide their own. And manpages for same. That way, all the bad parts of u-boot et. al never see the light of day. As it should be. :-) Viola! Much easier to work with than a lot of existing hardware, and darned unlikely to brick as well. Disclaimer: the above describes how I do my boards. Get me one of these, and I'll show you. I also make pretty extensive use of multistrap et. al from the embedded Debian project, to keep the target filesystem AND developer tools in sync. This isn't me self-promoting (ok, not much). Rather, Debian is just MADE to make this stuff awesome. I'm merely a lowly user thereof. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcauu6hx2ksg6_lfoduhn_2x24mnawfvcuytmppwojja9...@mail.gmail.com
Re: iMX6 EOMA-68 CPU Card
Luke: On Tue, Feb 26, 2013 at 6:51 PM, luke.leighton wrote: > http://rhombus-tech.net/freescale/iMX6/news/ > > just a heads-up that the iMX6 EOMA-68 CPU card is probably about 3-5 > weeks away from a first prototype, so i wanted to ask people if there > is any feedback on RAM, NAND flash sizes or any other features that > would make it useful to the debian arm community at all. Know what would be even more amazing than this board? To hear that you did it with the gEDA stack. :-) I'm not suggesting that gEDA couldn't do it, only that many people won't even try. b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAutgdTMNfcJyXz3g-vuuDEhW7eCNKTVJMoCvU21ocza=4...@mail.gmail.com
Re: ARM/Linux based car stereo?
Ivan: On Thu, Dec 22, 2011 at 2:58 PM, Ivan Jager wrote: > I suppose I could leave bluetooth on my phone on all the time and have it > start playing automatically when it sees the car, although I > don't expect that would be great for battery life... (It might > not be too bad though.) That is precisely what I do--- I have a Jabra Clipper connected to the AUX input on my car stereo. It puts itself to sleep after a while of not having a connection, so I have to turn it on but then after that I just drive the whole thing with my phone. Sometimes Pandora, but mostly the music I have on my phone at the time (which is pretty much my whole library). I also have a Bluetooth earpiece for making and taking calls, a Plantronics 975. Somehow Android is able to tell the two apart and route calls to the right place when they come in--- even muting the music while the call is ongoing. (I think the "somehow" might come from the different protocols that the two devices support being nonoverlapping. Unverified). My phone doesn't "automatically" start playing, but I'm sure there is an app for that somewhere... I don't notice Bluetooth having a significant drain on my batteries anywhere. I recharge the Clipper once every couple of weeks or so, or maybe once a day on long trips, with a USB charger I have in the car anyway to support my phone (Google Maps eats a LOT of power). I just plug it in to the Clipper as I am stepping out. Now, here in the 'States we have satellite radio suppliers and my phone won't get those but the car system will (if I subscribe), but that's the only thing I seem to give up with my current setup Many of my local radio stations have internet feeds, so I can still listen to them--- although it won't be synchronized with the guy sitting in the car next to me. But I get slightly greater range than he does. :) (I think the satellite broadcasters offer internet feeds, too). And the best part is, in my case the whole setup looks like an ordinary car radio. Nothing unusual to invite theft while I'm away. One thing to watch out for is that in some places here it isn't legal to poke at your phone while driving. So I avoid doing that. Just put on the album, and let it play. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcaut_x_pmu5b2kipwu_ektjcdhyb0unfn1c2bqyikepc...@mail.gmail.com
Re: ARM/Linux based car stereo?
Thinking out of the box, pardon the pun... What if you just put a bluetooth speaker system in your car, and drive it with your phone or other device? b.g. On Thu, Dec 22, 2011 at 12:46 PM, Ivan Jager wrote: > Hi, > > I'm in the market for a new car stereo, and was wondering if yinz > would know of an ARM based one that can run Debian. Something > similar to the empeg but about a decade newer would be nice. > > I've searched the internets and find a lot of x86 based > carpc's/carputers and even articles about running linux on them, > but they all seem to be too power-hungry to run off battery. > > I've considered using my Netgear WGT634u with a USB hub, USB > audio adapter, thumbdrive and bluetooth dongle, but my current > car stereo doesn't have an aux input, and it's dying, so I need a > new one anyway. (In case you're not familiar, the wgt634u is an > ARM based wireless router with a 200MHz CPU and USB 2.0. I > haven't actually tested whether it's fast enough to play MP3s, > but it seems like it should be able to. It comes with a 5V 1A > power supply, so it can't use more than 5W at most.) > > I now have a spare android phone, which would probably do a > better job, but I'd prefer something less stealable, and I'm > thinking of giving the phone to my brother anyway. > > So, anyone know of a good linux-based carputer? I'd like it to > have 802.11 and be able to run off battery for at least a week or > two. (I often leave my car parked for a week at a time, and I'd > like the ability to copy music from my house.) > > Please CC me as I'm not on this list. > > Thanks, > Ivan > > > -- > 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/2011104632.ga22...@mrph.org > -- Bill Gatliff b...@billgatliff.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/CADkCAuv=ii4vF6E3t6gpwjE3FyKmdNUEWnoZzsBAi5wxRg=t...@mail.gmail.com
Re: single device to replace ADSL router, WiFi/Ethernet router, SIP router?
Guys: On Thu, Dec 22, 2011 at 11:48 AM, Lennart Sorensen wrote: > In terms of being unbrickable, I am very impressed by my i.MX53 quick > start board. The bootloader is on microSD. Any actual board designed > with it could have the boot loader on a SATA disk if desired. There is > no boot rom at all in the design as far as I can tell. I really, really hate this idea. :) I much prefer having a bootloader in NAND, so that I'm not beholden to all the i/o necessary to read it from somewhere more complicated and less controllable. In addition, I really, really hate the quality levels I am seeing with uSD/eMMC devices right now. I know they are all internally based on NAND, why not ditch the little microcontroller they must also include and talk to a NAND directly? One less part to break, and one less thing to question the sanity of when you switch that device from FAT (which it is almost certainly optimized for) and extN or equivalent. (OT, but I wonder if the hangs and hiccups I see often enough to worry about aren't in some way due to the microcontroller's assumptions about the filesystem in use). Finally, obviously what you are calling the "bootloader" in your board is merely a second-stage one, as the CPU almost certainly does not natively know how to read from uSD. A first-stage bootloader must exist somewhere in the SoC itself. That doesn't really matter if you are happy always reading from a presumed-functional uSD, but as a platform integrator I would want to research what other options it makes available--- especially ones that would allow me to have a "factory reset button" on the unit that truly wipes the uSD and initiates a fresh download of a kernel and rootfs over https from somewhere. Don't get me wrong, I like the Quick Start board too (I think I have one on my desk somewhere, actually). But I don't like the temptation to turn something like that into a product without a lot of additional thought. I'm looking at you too, Beagleboard. :) b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAut3=m86n00y6pdengu86oceyfttmb8fbjnc-zv+08u...@mail.gmail.com
Re: Debian GNU/Linux on tablet hardware
On Oct 28, 2011 7:37 AM, "Phil Endecott" wrote: > > The i.MX LOCO board, the OMAP panda board, and some of the others cost about the > same as your tablet. > > > 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. > > > 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. Yes, you have: LOCO, Panda, Beagleboard, etc.. The OP disagrees due to an unclear definition of "motherboard". And the nice thing about the aforementioned boards is, they come with schematics. That erases the stability and availability problems by significantly lowering the barriers to producing the boards yourself if the need arises. BeagleBoard is built by CircuitCo, and I'm sure they would be pleased to quote any similar board you like. Getting boards is NOT the problem, overcoming the psychology preventing one from asking for the boards is the problem. b.g.
Re: Debian GNU/Linux on tablet hardware
On Oct 28, 2011 5:31 AM, "Luke Kenneth Casson Leighton" wrote: > > i say quotes illegal quotes because the > fucking morons at infotmic forced everyone to sign NDAs before > receiving the BSP (including kernel source code) thus losing their > rights to actually distribute their *own* BSPs under the terms of the > GPLv2. Oh, the irony of signing an NDA with a Chinese company! Pardon me, I think my head just exploded... b.g.
Re: [fedora-arm] ARM summit at Plumbers 2011
Russell: On Fri, Aug 26, 2011 at 11:35 AM, Russell King - ARM Linux wrote: > On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote: >> As such refactoring consolidated larger and larger chunks of kernel >> code, new designs would gravitate towards those consolidated >> implementations because they would be the dominant references. > > Don't bet on it. That's not how it works (unfortunately.) I wasn't being clear. The Linux community isn't large enough to dictate to ARM SoC designers how their hardware should work--- mostly because the "Linux community" doesn't buy chips, corporations do. And it has been my experience that the parts of corporations that negotiate deals for the hardware aren't populated with the developers of the drivers for said hardware. What I meant was that as new hardware becomes available, if we have strong driver models then driver authors will adopt those APIs rather than inventing their own. I'm thinking about GPIO before gpiolib, for example. Or the current state of PWM. > This "need to be different" is so heavily embedded in the mindset of the > hardware people that I doubt "providing consolidated implementations" > will make the blind bit of difference. I doubt that hardware people > coming up with these abominations even care one bit about what's in > the kernel. I don't routinely see a "need to be different" as existing strictly for its' own sake, even with the hardware guys. Rather, I see a lot of developers (hardware and software) that are so consumed with their own requirements and deadlines that they don't get the chance to step back and see the bigger picture. The resulting fragmentation is a symptom, not the disease itself. And honestly, some of the fragmentation is a really good thing. I love how Atmel does their GPIO controllers on the SAM-series parts, for example. The SODR and CODR registers are a godsend for concurrent code. We wouldn't have such treats if everybody did things the same way. So I'm generally ambivalent to the hardware situation. But that doesn't mean that the software has to be equally fragmented. In fact, I think the hardware situation necessitates that we pay particular attention to NOT fragmenting the drivers for said hardware. Gpiolib proves that is possible, something I didn't think I would find myself saying when David Brownell started his effort. I'm glad he proved me wrong. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcauvjvjz0cahqytzm_booodxrypzuqz93y3jwhqsqia+...@mail.gmail.com
Re: [fedora-arm] ARM summit at Plumbers 2011
David: On Wed, Aug 24, 2011 at 6:55 PM, wrote: > ARM is currently in worse shape than the PC market ever was in this aspect, > but in this case it's less a matter of getting the hardware guys to change > what they do than it is to get better documentation of what the hardware is > really doing and not duplicating drivers for cases where the right answer is > just replacing a constant with a variable (just as an example of the very > common case where the same component is wired to a different address) I agree. Maybe Linaro or an equivalent organization could provide a "ARM kernel janitor" service to the community, where they refactor existing ARM platform/driver code to make it more common. This is something that's difficult for a single person with experience in only one or two SoCs to do, but it would be pretty straightforward work for a team of three or four people with broad coverage of the SoC devices the kernel supports now. As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. b.g. -- Bill Gatliff b...@billgatliff.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/cadkcaut2smmkcclig0g+rwt5z4dxjgrzyyvuazcqvtqqmpf...@mail.gmail.com
Re: [fedora-arm] ARM summit at Plumbers 2011
Luke: Step back from the keyboard just a bit. :) It's true that the glass isn't completely full--- but it's pretty darned full! And we wouldn't be discussing the various GPL and other violations that you cite were it not for the overwhelming successes of Free Software, ARM, Linux, and Android. We are well past debating the merits of Free Software et. al, which itself is a huge milestone that we need to recognize. Now it's time to let the lawyers do their jobs. And they will, because there are tremendous sums of money at play. Money that wouldn't be there if it weren't for us developers. But we need to stay out of their way, while at the same time taking care to continue producing tangible things that are worth fighting over. As developers, we've won. Deal with it. Revel in it. And then get over it. I have observed all the hand-wringing regarding the state of ARM Linux, and it's obvious to everyone that there is still work to be done. ARM isn't like PCs, and that's obviously inconvenient for Linus but it's an essential part of ARM's success. Russell King has been overworked for a decade or more, attempting through sheer force of human/developer will to keep ARM Linux from running off the rails. As far as ARM Linux is concerned, I think we're dangerously close to being smothered by our own success. We have to learn to work smarter, because we can't work any harder. And I applaud Linaro and the countless others for recognizing this problem and looking for ways to resolve it. I for one would love to participate in the ARM Summit, but I'm a sole proprietor without an expense account to charge the travel costs to and they are too large for me to carry personally. I suspect I'm not the only one in that situation. The fact that there has been little response to the ARM Summit doesn't mean that nobody cares or that the problems seem to large to solve. It just means that we're going to have to find a different way to get this work done. b.g. -- Bill Gatliff b...@billgatliff.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/CADkCAuuaH5k2duuvUdmj1j9=6oackorn-njgg4gt2oveshh...@mail.gmail.com
Re: X video drivers appropriate for ARM?
Bryce: On Thu, Mar 24, 2011 at 4:07 PM, Bryce Harrington wrote: > On Thu, Mar 24, 2011 at 10:13:26PM +, Luke Kenneth Casson Leighton wrote: >> > >From talking with lool and jcristau, it sounds like only -fbdev is >> > really needed from this list. (Drivers that seem worth including such >> > as -dovefb, -omapfb, -imx, etc. are not in the list and perhaps should, >> > but that is a separate issue.) >> >> there's an s3c6410 one as well, somewhere around. > > Any idea if that is at all related to -s3 or -s3virge? If so, or if > there's any doubt, then perhaps one or both of those should stick around > a bit longer. But if it's a separate driver, then best to handle it > separately with -dovefb and those others. I think the name "s3c6410" is a reference to an ARM-based SoC. Completely unrelated to -s3 and -s3virge. b.g. -- Bill Gatliff b...@billgatliff.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/AANLkTi=MxCtMfu+xv=jroczr_v1mzxhg14q5c7hyd...@mail.gmail.com
Re: X video drivers appropriate for ARM?
On Thu, Mar 24, 2011 at 2:57 PM, Bryce Harrington wrote: > I am reviewing the default X drivers included in xorg for arm, and > notice there are a number which are pretty obscure and perhaps > irrelevant. I'm wondering if we can safely drop most of these from > xserver-xorg-video-all? You have my vote in support. I generally uninstall all but fbdev; but the list you suggest is fine by me. Just my $0.02, since I'm not a DD. I am a pretty heavy embedded user of debian, tho. :) b.g. -- Bill Gatliff b...@billgatliff.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/AANLkTin3Tf1WMUX=cqzfbx7xrnnekndpnbkphv3f8...@mail.gmail.com
Re: ARM ports
On Fri, Aug 13, 2010 at 7:24 AM, Wookey wrote: > This is not technically a debian-arm subject as such, although as > Debian does support kernels other than Linux as well as architectures > other than x86 I guess it's as good a place to ask as any. You might also check in with the Minix guys on their mailing list(s), they might be able to offer some guidance too. b.g. -- Bill Gatliff b...@billgatliff.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/aanlktikx9y2s=eipxf9nlplrqww6v4gy=rv5evjcu...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
> > > The tricky-bit here is that instruction-set extensions (VFP3, thumb2, > NEON) and instruction set versions (v4, v5, v6a, v7) can also be > incompatible in the sense that they won't run on hardware without > those features. But I really think we should try to deal with that by > correctly decorating ELF headers and making sure that the loaders and > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch > for every combination. > But then doesn't that mean that everything is "armel", so we never have a hope of having Debian officially support more than one combination? I'm ok with that, actually--- an ecosystem of unofficial "armel" repositories cropping up containing optimized packages for specific configurations. Especially if it's true that Debian won't officially support much more than armeb/armel. b.g. -- Bill Gatliff b...@billgatliff.com
Re: armelfp: new architecture name for an armel variant
> > > I would suggest to pick a generic, short name, with we could reuse > later if it is proven that hardfloat has no sense in the next years. > Comments? > I suggest just the opposite. :) We should pick a name that is clear and concise, so that it doesn't collide with another name we'd like to use later. For example, I'm glad we dropped "arm" because it tells me very little in detail about _which_ ARM machines are supported. And there aren't a lot of people you can ask about stuff like that who have a truly informed answer. I don't see them all becoming official Debian ports, but it would be awfully nice to someday have several repositories to choose from depending on whether you want least-common-denominator Debian for ARM, packages that have been built with compiler optimizations for Cortex A8, or XScale, or whatever. And then big/little-endian, EABI/OABI, SMP, and whatever else comes along later. I think the howls of maintenance protest are somewhat justified, but you just can't go wrong with names like "arma8vfpel", "arm920tel", and so on. In an ideal world, I would prefer we go that route. To me, names like "armel" are just too generic to be meaningful. I'm speaking from the perspective of someone who uses Debian (and emDebian) across the full range of ARM machines. For embedded applications, mostly. So the clarity is important to me, even if the names are somewhat inconsistent with the tidy, generic names that Debian uses for its architectures now. It would be really cool if we could find a way to make it easy to launch a buildd to create packages for, say, "A8 with VFP and EABI", and the package scripts somehow tolerate a new ARM-based arch name that they haven't seen before because I'm the first guy to try to optimize for a certain machine. b.g. -- Bill Gatliff b...@billgatliff.com
Re: Alignement on ARM
On 05/12/2010 01:21 PM, Vincent Bernat wrote: While I have fixed my warnings, I am still a bit astonished that such a common code as : sa = (struct sockaddr_in *)ifa->ifa_addr; if (... sa->sin_addr ...) ... can lead to a misaligned access on ARM. Maybe there is something somewhere that ensure that struct sockaddr and struct sockaddr_ll are always aligned correctly on a 4-byte boundary? Because with enough casting and whatnot, any magic number can get plugged into ifa_addr. Look carefully at where the value that gets assigned to ifa_addr comes from. If it truly is the address of an independent structure that's allocated by the compiler (stack, data or code), then it's highly unlikely to be misaligned because IIRC all structures begin on 32-bit address boundaries. I think there's even some language in the C standard about that. I don't think your example code will exhibit any problems. If ifa_addr is instead the address of something inside of another structure, and that structure is "packed", then ifa_addr could be a misaligned pointer because of the structure packing. And if ifa_addr is a casted pointer from a location in a byte stream, or a calculated value, then only $deity$ knows what you can say about it other than it's bad, bad code. :) b.g. -- Bill Gatliff b...@billgatliff.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/4beaf473.9060...@billgatliff.com
Re: genesi and open rd
Martin Guy wrote: > On 2/8/10, Karsten König wrote: > >> So Debian will run on both as it is built for the ARMv5 architecture >> > > ARMv4t (so it will still run on both) > OT, but has anyone looked at what gains can be had by rebuilding packages with, say, A8 or other optimizations for processors that support them? I have a hunch that they offer at best minimal improvements except for specific packages/situations, but I have never taken the initiative to produce a quantitative answer... b.g. -- Bill Gatliff Embedded systems training and consulting http://billgatliff.com b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: doubt
rajagopal venugopal wrote: > > hi all, > > > my doubt is whether i can use my own kernel for for my own > arm hardware and make the kernel work with debian GNU/Linux Yes. b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Thecus recovery
Markus Ulbricht wrote: > Hi folks, > > after running a few hundred days continuously my N2100 is now > no longer pingable. After rebooting with Power off/on (frontpanel > switch was no longer working) no success with ping etc. Some > HDD action is noticeable, no red front panel lights etc. > > I am afraid that e2fsk etc is needed. But how can I get into a > console? IP address is configured statically, no DHCP. > Redboot is still available, nut no output if I do not interrupt with > Ctrl-C. Bootstrap a filesystem on a workstation accessible over NFS, or maybe in a USB stick that you plug into the Thecus? You'll have to modify the parameters RedBoot passes to the kernel, of course... That's the first idea that comes to my mind. b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Keyspan-enabled kernel?
Guys: I'm running: Linux n2100 2.6.26-1-iop32x #1 Sun Jan 11 10:42:50 UTC 2009 armv5tel GNU/Linux Obviously, that kernel won't talk to my Keyspan 4-port USB serial adapter. So I grabbed a source package from here: http://www.knizefamily.net/russ/software/linux/keyspan-usb-to-serial-converter-driver/ Although that package works fine on my AMD64 workstation, it doesn't work on the n2100: I get a weird, kinda off-by-one error where keystrokes echoed to me are different from what actually seems to be going out over the wire. Or something, I can't quite figure out how to describe it. But it's broken. Anyway, ... and I'm almost ashamed to ask since this is a Debian mailing list and all, ... :) does anyone have an n2100 kernel that talks to Keyspan adapters? I could really use one! b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Update on Thecus N2100 support in Debian
Marc Pignat wrote: - There's still no DMA support, but I will provide an unofficial kernel for lenny that has some DMA patches: http://www.cyrius.com/debian/iop/n2100/dma.html Tested on my n2100 with debian lenny for armel, seems to work just fine! (still no data lost at this time ;) ) Tested on my lenny arm n2100, same (good) results. Speed increase is quite apparent. Thanks! b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upgrade arm installation to armel?
Gordon Farquharson wrote: Hi Bill On Sun, Feb 22, 2009 at 20:21, Bill Gatliff wrote: If I have a machine like an n2100 that's running lenny arm, is it possible to merely "upgrade" it to armel? You may want to try out the instructions in the section "Migrating arm installation to arm EABI installation" on this page [1]. Those sound so... scary. :) Ok, I think I'm ok with a fresh install. But the n2100 docs all talk about an n2100.bin file, put into place using the Thecus infrastructure. What if the system is already running Debian arm? I looked at mounting the installer image over NFS, but apparently the stock n2100 kernel can't do nfsroot. Any suggestions? b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upgrade arm installation to armel?
Guys: I'm pretty sure I know the answer to this, but... :) If I have a machine like an n2100 that's running lenny arm, is it possible to merely "upgrade" it to armel? b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: arm (not armel) d-i buildd is over
Martin Michlmayr wrote: This also raises the question what to do about arm, i.e. whether we can remove support for arm from the kernel, installer and other packages. Riku and Aurelien initially agreed to remove it, but then Riku pointed out that we may have to keep support around in sid if arm wants to take part in lenny+half. I think it makes sense to support arm for lenny+half in terms of the kernel upgrade, but not for the installer (since we don't want any new installations of arm anyway). That would make it a lot easier for existing deployments, yes. b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to install iceweasel on a Linux device without using Debian installer?
Weidong Li wrote: Hi, I’d like to iceweasel and its dependency libraries on an ARM-based Linux device which does not have all those Debian tools. Can anyone give me some advice on how to install it manually? Well, there's probably a Makefile in the source code somewhere... :) But seriously, in the past I've debootstrapped a debian environment for the target, plugged my binaries into it, and then started rm'ing the stuff that kept it from fitting into the hardware. I wouldn't recommend that approach in the general case, but as a one-off it's tolerable. Advice: take good notes, because there really never is such a thing as a "one-off". :) b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
My co-lo ISP is kicking me out...
Guys: The plan that my ISP used to get me in the door to their colocation facility is being retired, and they want me to triple what I'm paying now in order to keep my location. That's not going to happen. At some point before the end of January, I have to move the N2100 to somewhere else. I'm already transitioning my other resources to a Xen-based virtual server, but as the N2100 is physical hardware that presents a different problem. :) One possibility is to bring the box back to my office, and put it on what is basically an ADSL with a dynamic IP address. That's no problem for outbound, but it will make it hard for anyone except me to do maintenance. We could possibly address that with openvpn. Any other ideas? b.g. -- Bill Gatliff b...@billgatliff.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian-arm on omap3
Amit Pundir wrote: > Greetings! > > I have been assigned a task to port gnome-desktop on omap3evm i.e. to > bring up omap3-evm LCD with a running Gnome Desktop like GUI, similar > to what I got on my X86-Desktop. > > I have been lookin around for possible solutions and even started to > build my own from scratch untill I been redirected to this list for > debian-arm distribution which looks quiet promising. > > > It would be great if someone can help me in answering my following concerns: > > Is there any pre-build solution available for omap/arm platform which > I can download and check? > > How much pain will it take to build certain packets on top of it or to > customize the kernel/package needs? As of now X11 and Gnome-desktop > are must for me. > > Lastly, did anyone tested it on omap3-evm(ARM Cortex A8) or any other OMAP? I run it more or less continuously on a Beagleboard. Debootstrap of the armel architecture, works for me. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BUG booting 2.6.26-1-iop32x on Thecus N2100
Riku Voipio wrote: > On Tue, Nov 18, 2008 at 01:37:11PM +0100, Martin Michlmayr wrote: >> It happens because of Riku's LED driver. When I compile a kernel >> without the driver, I can start ifplugd just fine. > >> Riku, the best way to reproduce this is to install ifplugd (but _not_ >> change INTERFACES in /etc/default/ifplugd to "auto") and then you can >> trigger it with: >> /usr/sbin/ifplugd -i eth0 > > I see, ifplugd tries to beep. Why when ifplugd is calling it ends up > in atomic context is unclear to me, using schedule_work should make > it more safe anyway. will convert when back at device to test.. I haven't looked at any of the related code. Does iop32x use gpiolib? Maybe the GPIO pin that controls the beep is at the end of an i2c GPIO expander. If that's the case, then there is at least one sleep whilst waiting for the i2c bus controller to complete the transaction. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I don't have root on hedges.billgatliff.com any more...
Aurelien Jarno wrote: > On Wed, Oct 15, 2008 at 10:52:53AM -0500, Bill Gatliff wrote: >> Guys: >> >> >> A catastrophic system failure has nuked the keys that allowed me root access >> on >> hedges.billgatliff.com. I hope someone else has been babysitting that >> machine! :) >> > > I don't know the root password, but I have sudo access, and you should > have it. Please contact me privately with a new key/password for you > account so that we can fix the problem. I just checked, turns out I have sudo as well. So problem (already) solved! b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I don't have root on hedges.billgatliff.com any more...
Guys: A catastrophic system failure has nuked the keys that allowed me root access on hedges.billgatliff.com. I hope someone else has been babysitting that machine! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian on thecus n4100
Marc Pignat wrote: > Hi all! > > Is there any plan to support this machine? > > Or even if it isn't supported, where can I find a howto for testing debian on > it? Check back in the archives a few weeks, you'll see some traffic from me and others regarding how I got my n4100 working. Short answer is that the code for the n2100 is 99% of what's needed, it can be made to work, but I haven't had time to finish the n4100 hooks in the mainline kernel. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hard drive connected to the slug
Michael Glockenstein wrote: > Hello, > some weeks ago I reported an error where my drive makes strange sounds like > spinning up in 6 or 7 sequences, then noise, then spinning up again and the > slug did respond anymore for login. Because nobody replied, I thought it was > a one time accident, but three days before it happended again :-( > So now I think about a solution the slug running all the time instead of shut > it down > in the evening and wake up in the morning. I have connected a 3.5" hd to port > 1 > with an external power supply in the moment. But this is power consuming too > much. > Is it possible to have a 2.5" notebook hd without external power supply > connected > to the slug and the usb port spends enough energy for that drive? > Regards Michael > > Might be the drive recalibrating its head-positioning hardware, which signals a failing drive. Very non-repeatable, at least until whatever is prompting the event dies completely. :( Regardless of the answer to your question, I'd procure a backup storage source and put it to work right now. And don't shut the ailing drive down until you have all the data safely off of it--- it might not restart. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [E1000-devel] Supporting platforms with no EEPROM?
Riku Voipio wrote: > On Fri, Sep 12, 2008 at 10:23:06AM -0700, Brandeburg, Jesse wrote: > >> we don't want to support this in the default drivers, but maybe we could >> in the kernel with a Kconfig option that defaulted to off. > > This could be acceptable, we would only turn that option on the iop32x > kernel. It's sub-optimal, as some iop32x boards have PCI slots. I agree, it would be an excellent capability. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Supporting platforms with no EEPROM?
Lennart Sorensen wrote: > On Fri, Sep 12, 2008 at 12:59:06PM -0400, Daniel Kahn Gillmor wrote: >> What about stuffing an equivalent line into your initramfs? >> >> Something like: >> >> ip link set eth0 address 12:34:56:78:9a:bc >> >> (assuming you've got /bin/ip and dependencies -- i can't seem to make >> this work from busybox's implementation of ip) > > Do you HAVE to have an initramfs? If the bootloader of the platform > correctly sets the MAC in the ethernet device, it would seem nice if the > driver would realize that and leave it alone. Or did I misunderstand > the issue and nothing on the platform contains a mac address? > I've verified that RedBoot properly sets up the MAC on my platform. And Thecus in fact adjusted the e1000 driver that ships with the box, to take out the logic that faults if there is no EEPROM. I agree, it would be nice if the driver would just leave things alone if it finds them in an acceptable state... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Supporting platforms with no EEPROM?
Daniel Kahn Gillmor wrote: > What about stuffing an equivalent line into your initramfs? > > Something like: > > ip link set eth0 address 12:34:56:78:9a:bc > > (assuming you've got /bin/ip and dependencies -- i can't seem to make > this work from busybox's implementation of ip) Is there not some way to make the driver Do The Right Thing, i.e. just keep the MAC address if it's already there? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Supporting platforms with no EEPROM?
John Winters wrote: > Bill Gatliff wrote: > [snip] >> The MAC Address will be reset to 00:00:00:00:00:00, which is invalid >> and requires you to set the proper MAC address manually before continuing >> to enable this network device. > [snip] >> To date, the only way I've seen around this is to just hack out the code in >> the >> e1000 driver that deals with the EEPROM and MAC addresses. Is there any plan >> for cleanly handling no-EEPROM platforms, or am I into "undiscovered >> territory" >> here? I'm willing to submit patches once I find a minimally-invasive and >> robust >> solution, but I don't want to reinvent the wheel... > > Can't you just put a made-up MAC address into /etc/network/interfaces? > Like this: > > allow-hotplug eth0 > iface eth0 inet dhcp > hwaddress ether 00:07:95:09:c4:96 > > Don't use that one (IIRC, it belongs to a Mini-ITX board in my > cupboard). Ideally use the original one configured for the unit. One could, but that won't work for root-over-NFS. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Supporting platforms with no EEPROM?
Guys: I'm working on a Thecus N4100 platform, which has two e1000's but no EEPROMs. The MAC addresses are set by the bootloader, using values that are stored in the platform's equivalent of a BIOS (flash memory). The platform boots into Linux, currently 2.6.27-rc5. It's an ARM instruction set architecture machine. When the platform boots, the kernel (not surprisingly) reports as follows: ... Intel(R) PRO/1000 Network Driver - version 7.3.20-k3-NAPI Copyright (c) 1999-2006 Intel Corporation. e1000: :00:01.0: e1000_probe: The EEPROM Checksum Is Not Valid /*/ Current EEPROM Checksum : 0x Calculated : 0xbaf9 OffsetValues == : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Include this output when contacting your support provider. This is not a software error! Something bad happened to your hardware or EEPROM image. Ignoring this problem could result in further problems, possibly loss of data, corruption or system hangs! The MAC Address will be reset to 00:00:00:00:00:00, which is invalid and requires you to set the proper MAC address manually before continuing to enable this network device. Please inspect the EEPROM dump and report the issue to your hardware vendor or Intel Customer Support. /*/ e1000: :00:01.0: e1000_probe: Invalid MAC Address e1000: :00:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:00:00:00:00:00 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: :00:02.0: e1000_probe: The EEPROM Checksum Is Not Valid /*/ Current EEPROM Checksum : 0x Calculated : 0xbaf9 OffsetValues == : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Include this output when contacting your support provider. This is not a software error! Something bad happened to your hardware or EEPROM image. Ignoring this problem could result in further problems, possibly loss of data, corruption or system hangs! The MAC Address will be reset to 00:00:00:00:00:00, which is invalid and requires you to set the proper MAC address manually before continuing to enable this network device. Please inspect the EEPROM dump and report the issue to your hardware vendor or Intel Customer Support. /*/ e1000: :00:02.0: e1000_probe: Invalid MAC Address e1000: :00:02.0: e1000_probe: (PCI:33MHz:32-bit) 00:00:00:00:00:00 e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI e100: Copyright(c) 1999-2006 Intel Corporation ... To date, the only way I've seen around this is to just hack out the code in the e1000 driver that deals with the EEPROM and MAC addresses. Is there any plan for cleanly handling no-EEPROM platforms, or am I into "undiscovered territory" here? I'm willing to submit patches once I find a minimally-invasive and robust solution, but I don't want to reinvent the wheel... (Crossposted to debian-arm, since it's an ARM platform and I've already raised the issue there). Thanks! b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newer kernel for N4100?
Peter Korsgaard wrote: >>>>>> "Bill" == Bill Gatliff <[EMAIL PROTECTED]> writes: > > Hi, > > Bill> ... and this patch is so bad, I hesitate to post it. But > Bill> if I don't, I'll lose it myself! :) > > ;) > > Bill> +#else > Bill> +#warning "TODO: Figure out how to deal with EEPROM checksum on N4100" > Bill> + static int mac_seed = 0x8a; > Bill> + hw->mac_addr[0] = 0; > Bill> + hw->mac_addr[1] = 0x14; > Bill> + hw->mac_addr[2] = 0xfd; > Bill> + hw->mac_addr[3] = 0x10; > Bill> + hw->mac_addr[4] = 0x11; > Bill> + hw->mac_addr[5] = mac_seed++; > > You could atlest use random_ether_addr(). That would definitely be a more generic solution. :) I'm trying to avoid the sudden change in MAC address that the other network members would suddenly see, and the ARP cache trashing that it would cause (which is a problem for root-over-NFS, at least). My patch obviously isn't the answer, either. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newer kernel for N4100?
Martin Michlmayr wrote: > * Bill Gatliff <[EMAIL PROTECTED]> [2008-09-08 14:30]: >> So now the kernel is very happy talking to the drives, apparently. But it >> doesn't like the e1000's: > > I thought you were aware of this, but in case you're not: Thecus > removed the EEPROM from both i82541 chips and stored the MAC address > in the RedBoot configuration area. > Yep. The head-scratching part is figuring out a way to tell the e1000 driver to keep the MAC that's already programmed. I don't see a robust, convenient way to do that with the existing driver. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newer kernel for N4100?
Bill Gatliff wrote:
> I found in the .17 kernel where Thecus commented out the EEPROM checksum test
> in
> the e1000 driver, I'm going to do the same and see what happens. My first
> attempt caused the code to load all ff's for the MAC, which obviously isn't
> what
> I want.
... and this patch is so bad, I hesitate to post it. But if I don't, I'll
lose it myself! :)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ad6da7b..9a2a65a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1064,6 +1064,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
/* before reading the EEPROM, reset the controller to
* put the device in a known good starting state */
+#if 0
e1000_reset_hw(hw);
/* make sure the EEPROM is good */
@@ -1080,10 +1081,21 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
*/
memset(hw->mac_addr, 0, netdev->addr_len);
} else {
/* copy the MAC address out of the EEPROM */
if (e1000_read_mac_addr(hw))
DPRINTK(PROBE, ERR, "EEPROM Read Error\n");
}
+#else
+#warning "TODO: Figure out how to deal with EEPROM checksum on N4100"
+ static int mac_seed = 0x8a;
+ hw->mac_addr[0] = 0;
+ hw->mac_addr[1] = 0x14;
+ hw->mac_addr[2] = 0xfd;
+ hw->mac_addr[3] = 0x10;
+ hw->mac_addr[4] = 0x11;
+ hw->mac_addr[5] = mac_seed++;
+#endif
/* don't block initalization here due to bad MAC address */
memcpy(netdev->dev_addr, hw->mac_addr, netdev->addr_len);
memcpy(netdev->perm_addr, hw->mac_addr, netdev->addr_len);
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newer kernel for N4100?
Riku Voipio wrote: > On Mon, Jul 14, 2008 at 12:35:21PM -0500, Bill Gatliff wrote: >> I just built mainline 2.6.26 with iop32x_defconfig and arm-linux-gnueabi-gcc >> (GCC) 4.2.4 (Debian 4.2.4-2). Booting on my n4100, I get this: > >> RedBoot> exec -c "console=ttyS0,115200 [EMAIL PROTECTED] panic=5 root=nfs >> nfsroot=192.168.2.10:/exports/arm >> ip=192.168.2.8:192.168.2.10:192.168.2.1:255.255.255.0:n4100:eth0:off >> init=/bin/sh" >> Using base address 0x0020 and length 0x00200594 >> i82544_stop >> i82544_stop 0 flg 17 >> Uncompressing >> Linux... >> . done, >> booting the kernel. >> Linux version 2.6.26 ([EMAIL PROTECTED]) (gcc version 4.2.4 (Debian >> 4.2.4-2)) #9 Mon >> Jul 14 11:41:31 CDT 2008 >> CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=397f >> Machine: Intel IQ31244 > > Thats probable the wrong machine. Try prependig the N2100 machine-id > for fixups. > > devio > vmlinuz 'wl 0xe3a01c04,4' 'wl 0xe381104d,4' > cat arch/arm/boot/zImage >> vmlinuz Finally got around to trying this out (it's been a rough summer), this time on 2.6.27-rc5. It definitely changes things: ... scsi0 : sata_vsc scsi1 : sata_vsc scsi2 : sata_vsc scsi3 : sata_vsc ata1: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080200 irq 29 ata2: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080400 irq 29 ata3: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080600 irq 29 ata4: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080800 irq 29 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100 ata1.00: 586072368 sectors, multi 0: LBA48 ata1.00: configured for UDMA/100 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100 ata2.00: 586072368 sectors, multi 0: LBA48 ata2.00: configured for UDMA/100 ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100 ata3.00: 586072368 sectors, multi 0: LBA48 ata3.00: configured for UDMA/100 ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata4.00: ATA-6: WDC WD3000JD-00KLB0, 08.05J08, max UDMA/100 ata4.00: 586072368 sectors, multi 0: LBA48 ata4.00: configured for UDMA/100 scsi 0:0:0:0: Direct-Access ATA WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 586072368 512-byte hardware sectors (300069 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 586072368 512-byte hardware sectors (300069 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sd 1:0:0:0: [sdb] Attached SCSI disk sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdc] 586072368 512-byte hardware sectors (300069 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdc] 586072368 512-byte hardware sectors (300069 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sd 2:0:0:0: [sdc] Attached SCSI disk sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 3:0:0:0: Direct-Access ATA WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5 sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB) sd 3:0:0:0: [sdd] Write Protect is off sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB) sd 3:0:0:0: [sdd] Write Protect is off sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sdd2 sd 3:0:0:0: [sdd] Attached SCSI disk sd 3:0:0:0: Attached scsi generic sg3 type 0 physmap platform flash device: 0100 at f000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer wr
Re: "offline" install of Etch to SATA HDDs for MyBook World?
Jonsen, Dan wrote: > I guess that either (1) this is a highly customized Linux distro from WD, or > (2) the ARM architecture doesn't use GRUB, because I can't find a grub.conf > file. Probably both are true. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "offline" install of Etch to SATA HDDs for MyBook World?
> > Thanks for that; since I'm an IT guy and haven't done any embedded work (gee, > am I on the wrong platform here? ;-) ) Certainly not! Once you're over to Debian, it's all pretty much the same from an IT perspective regardless of the particulars of the platform. And, I think that the more "I haven't done any embedded work"-type guys we can get to come over to the light side, the better off we'll all be. Welcome aboard! > this device doesn't even come close to true gigabit throughput on the NIC No opinions on your (1) or (2), since I'm not an IT guy. But as for (3), that's a known characteristic of any device like the MyBook, NSLU2, Thecus N*, etc. because the CPUs in such devices top out at < 500 MIPS, and the boxes themselves don't do a lot of hardware-assisted packet manipulation or disk i/o. So the CPU is pretty busy doing such things itself, and quickly becomes a bottleneck. But the price is right, and the target audience of these devices probably never notices anyway--- all they seem to want is something with an RJ45 jack that creates an icon on their XP or Vista Desktop. I say more power to 'em, because what we get in return is cheap hardware that can be "liberated" from such mundane work for more useful purposes. :) If you really need 1GB throughput, you need something substantially more expensive than any device you've mentioned so far. Something with a lot of smart hardware between the ethernet jack and the disk--- and not just a faster CPU! b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "offline" install of Etch to SATA HDDs for MyBook World?
Jonsen, Dan wrote: > > Do any of you know of a way to use an i386 Etch workstation to install a > binary ARM distribution onto an "additional" set of HDs? I don't know about etch, but I use sid/lenny and debootstrap to create armel images all the time. Use the --foreign parameter. The tricky part might be how to invoke the --second-stage. Maybe you could pass init=/debootstrap/debootstrap --second-stage on the kernel command line, but it will probably be more complicated than that because you need to mount proc and export $PATH before debootstrap will complete. On all the targets I work with, I have a console of some type (usually serial) to control the device with. > Also, WD does put the source code for everything on the MyBook WEII on their > website Wow, I had no idea :) Is this thing a better option than an NSLU2, for those with the budget? Hmmm... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Progress on Bug#444271 / N2100 disk performance
Ross Burton wrote: > I've been using this kernel for some time on my N2100 now, and the > improvement in disk IO performance is substantial. I'd love to see this > merged into lenny's kernel but I realise I should have sent this email a > few weeks ago for that to be in any way possible... hedges.billgatliff.com/hedges.debian.org is an N2100. Might be another good place to try it out. I don't have root on hedges, and wouldn't use it even if I did--- it's debian's machine, after all. :) But I'm occasionally in physical proximity to the colo center that houses it, if necessary. Or, not. Not my call. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newer kernel for N4100?
Riku Voipio wrote: > > perhaps you'll want to ask the sata_vsc author. another possibility is > that the pci IRQ map is wrong and the driver isn't recieving interrupts > from the sata controller. Here is lspci -vvv output. See anything? Looks like the PCI-X SATA HBA is tied to IRQ 29. Not sure what to do with that information, though... b.g. -- Bill Gatliff [EMAIL PROTECTED] 00:01.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05) Subsystem: Intel Corporation 82541GI Gigabit Ethernet Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR-
Re: Newer kernel for N4100?
Riku Voipio wrote:
> On Sat, Jul 12, 2008 at 10:49:09AM -0500, Bill Gatliff wrote:
>> Anyone know of a recent kernel for the n4100? I was using the 2.6.17.8
>> sources
>> from wpkg.org, which are a bit out of date. Is anyone else paying any
>> attention
>> to this platform?
>
> What patches does the "wpkg.org 2.6.17.8" add to the kernel? Are these
> in mainline kernels already? If they are, the -iop32x kernel should
> probably work just fine. If they are not, it should not be a big job.
> N4100 is almost identical to n2100. Similar enough that it would be
> a pity if support were lost. However, it needs someone with the actual
> hardware to make it possible.
I just built mainline 2.6.26 with iop32x_defconfig and arm-linux-gnueabi-gcc
(GCC) 4.2.4 (Debian 4.2.4-2). Booting on my n4100, I get this:
RedBoot> exec -c "console=ttyS0,115200 [EMAIL PROTECTED] panic=5 root=nfs
nfsroot=192.168.2.10:/exports/arm
ip=192.168.2.8:192.168.2.10:192.168.2.1:255.255.255.0:n4100:eth0:off
init=/bin/sh"
Using base address 0x0020 and length 0x00200594
i82544_stop
i82544_stop 0 flg 17
Uncompressing
Linux...
. done,
booting the kernel.
Linux version 2.6.26 ([EMAIL PROTECTED]) (gcc version 4.2.4 (Debian 4.2.4-2))
#9 Mon
Jul 14 11:41:31 CDT 2008
CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=397f
Machine: Intel IQ31244
...
scsi0 : sata_vsc
scsi1 : sata_vsc
scsi2 : sata_vsc
scsi3 : sata_vsc
ata1: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080200 irq 27
ata2: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080400 irq 27
ata3: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080600 irq 27
ata4: SATA max UDMA/133 mmio [EMAIL PROTECTED] port 0x80080800 irq 27
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: qc timeout (cmd 0x27)
ata1.00: failed to read native max address (err_mask=0x4)
ata1.00: HPA support seems broken, skipping HPA handling
ata1: failed to recover some devices, retrying in 5 secs
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: qc timeout (cmd 0x27)
ata2.00: failed to read native max address (err_mask=0x4)
ata2.00: HPA support seems broken, skipping HPA handling
ata2: failed to recover some devices, retrying in 5 secs
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: configured for UDMA/100
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: qc timeout (cmd 0x27)
ata3.00: failed to read native max address (err_mask=0x4)
ata3.00: HPA support seems broken, skipping HPA handling
ata3: failed to recover some devices, retrying in 5 secs
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/100
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: qc timeout (cmd 0x27)
ata4.00: failed to read native max address (err_mask=0x4)
ata4.00: HPA support seems broken, skipping HPA handling
ata4: failed to recover some devices, retrying in 5 secs
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA WDC WD3000JD-00K 08.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
...
...
...
It repeats this over and over and over again, as far as I can tell it tries
UDMA/133, then UDMA/100, ... until it gets to UDMA/33. For each device. It
takes an *age*.
After that, it apparently gives up and moves through the rest of the boot
process (which I haven't finished yet--- I had to restart because I forgot the
ip= parameter needed for nfsroot).
Interestingly, the above does contain the right information for the drive(s) in
question: WDC WD3000JD-00K. So the drives are at least still talking.
Not knowing much about SATA, though, I can't tell what all the above means---
either for the kernel's functionality on this platform, or the health of the
drives running in it.
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Newer kernel for N4100?
Guys: Simultaneous with latest dist-upgrade, my N4100's RAID5 array went south (by now, you'd think I would have learned to not mess with what wasn't broke). I don't know if there's a connection, but two simultaneous drive "failures" without warning have me feeling somewhat suspicious about a false-positive. Anyway... Now I have to figure out how to stand this box back up, hopefully without losing the data on the array (some of which would be a _major_ pain to recover). Suggestions are more than welcome, and will be reciprocated with the beverages of your choice. :) My strategy at the moment is to debootstrap an arm tree on an NFS server, and use that as my rootfs while I sort out my md problems. Anyone know of a recent kernel for the n4100? I was using the 2.6.17.8 sources from wpkg.org, which are a bit out of date. Is anyone else paying any attention to this platform? I am, but perhaps not for much longer... :( b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NSLU2 Debian installer for lenny beta 2
Does anyone know of an armel installer and/or kernel for an N4100? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Thecus N299
How does "solder onto the RedBoot UART" count as a "remote exploit"? ;) -Original Message- From: "Michael Goetze" <[EMAIL PROTECTED]> To: debian-arm@lists.debian.org Sent: 4/29/08 3:42 PM Subject: Thecus N299 Hi, aparently Thecus has released a new, incredibly cheap, 2-Bay NAS, the N299. It seems to run on the Gemini SL3516[1] which seems to have all the necessary code already available under the GPL [2]. Now, since I'm a cheapo, and the N2100 costs twice as much, I'm quite interested. I wonder if anyone could (maybe someone has actually seen one?) could give me an educated guess as to ... whether it will be possible to get a root shell without waiting for a new remote exploit? ... whether it will eventually be possible to run Debian on this box? ... how it might stack up to the N2100 performance-wise? All comments appreciated! Kind regards, Michael (Please CC me as I am not subscribed.) [1] http://www.storlinksemi.com/product_page.cfm?RecordID=3 [2] http://laforge.gnumonks.org/weblog/2008/01/20/ - currently down? But available in Google's cache -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Puzzling difference between debian-arm and debian-i386 re growisofs
Barry Tennison wrote: I wonder whether anyone can help a very puzzled moderately skilled debian and NSLU2 hacker? Apologies for the length of explanation needed. Are you running out of memory on the NSLU2? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] MiniPCI GPS and GSM card for router
Michelle Konzack wrote: > Note: Currently I do not know, whether I schould use a "Soekris > net4526", "Soekris net4826" or a "VIA EPIA LN5000EA" since > currently I have not found any routers using an ARM CPU and > offering enough MiniPCI Slots. What about some USB-based options? I know they're out there, but I can't point to any part numbers right now... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] MiniPCI GPS and GSM card for router
Michelle Konzack wrote: > > Now for my other Mobilhomes/offices/workshops I want to use a cheaper > model and like to know, whether someone know MiniPCI GSM cards which > support only GPRS 56kBit and are respectively much more expensive since > I have the need for at least 12 cards. (Used cards are welcome too) > > The second thing is, that I need a NMEA compatible GPS card. The one I > have currently choosen is a "GPS Engine Board NL-954M" but it cost > 120 Euro which I not realy like to pay, since I need 8 of them. Do you really need so much redundant hardware? With gpsd, you could share the GPS engine's output with all the machines on your LAN. Likewise a GSM modem often looks like a PPP connection, so it could be shared as well... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LCD Dot-Matrix Display "Bona MG24064-01"
Michelle Konzack wrote: > Hello, > > I hope, next week I will get my 19" 2U case and now I like to know, if > the Dot-Matrix display "Bona MG24064-01" is supported under arm/i386 and > could replace a monitor for the console... Anything's possible! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hedges will need some downtime next week
Bill Gatliff wrote: Guys: I no longer have root on hedges, due to a power supply failure on my workstation, and a non-backed-up SSH key. :( This has been corrected. As soon as I know what the install date/time is, I'll add a crontab entry to do a shutdown with several hours' notice. At the scheduled time, the machine will be down for 6-12 hours. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hedges will need some downtime next week
Guys: The colo facility that houses hedges is doing some facilities work next week, and will need to shut down the unit for several hours. I don't have the date/time schedule yet. I no longer have root on hedges, due to a power supply failure on my workstation, and a non-backed-up SSH key. :( I'll post the date/time here when I know it. Could someone set up a crontab to shut the machine down, with warning, at that time? Thanks! b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LUKS overhead (was Re: encrypted root fs on a slug and crypto-modules)
Tomasz Chmielewski wrote: Tobias Frost schrieb: to throw another number into the round, I got around 2-3 MByte/s on the new ABI. BTW: Does someone know a Mini-PCI crypto accelerator card fit for LUKS/device-mapper? I found some two solutiions the net, but all of them are very "secret", that is you need probably a NDA to get more infos like datasheets or in which format the drivers are supplied ... (The best candidate so far would be the NITROX XL NMB Acceleration Boards, http://www.caviumnetworks.com/acceleration_boards_Mini-PCI.htm) VPN 1411 from Soekris could in theory help: http://soekris.com/vpn1401.htm In theory only, because there is no working driver for Linux 2.6 (there are sources for Linux 2.4 and OpenBSD/FreeBSD). (Slightly) OT, are there any HOWTOs or other general overviews of the crypto-related APIs in the kernel that appear to be getting significant attention the last few releases? It looks like there's more than an accelerator API there lately, I'm trying to get a sense of the motivations for its use--- as well as how to use it, of course. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Video application
Tomasz Chmielewski wrote: Richard schrieb: Hi All Has anyone tried to use a NSLU2 for video streaming, ie connect a web cam to it and use it as a streaming server. I'd like to be able to video an object exploding , stream the video to another computer, sample at a high rate and then play it back slowly. has anyone already done any thing similar ?? I used to experiment with video streaming on ASUS WL-500gP (266 MHz, 32 MB RAM, mipsel arch). I used vlc for video transcoding and streaming and Philips USB camera. The device was swapping a bit and was a bit slow. You say you want high rate to film an exploding object - you may have trouble with that with NSLU2, I guess. I would think so. In particular, it will (a) be difficult to find an off-the-shelf webcam with a useful frame rate (b) that won't also swamp the NSLU2's bandwidth-constrained, floating-point-challenged processor which at the same time is (c) overwhelmed with pushing what data it can out over TCP/IP through a bandwidth-challenged ethernet implementation to another machine. I'm not really an authority on such matters, though. Just my $0.02 after working with other, comparable processors and other platforms. I looked at some solutions out of curiosity once, and discovered that a lot of the high-speed streaming camera implementations used for this kind of thing actually bolt the camera core right to the CPU over DMA, and then "stream" the raw frames to SRAM. An offline process then pushes those frames out over a fast link (Firewire? SCSI?) to another processsor with the memory and horsepower to turn them into streaming-compatible formats. Or they do the compression with FPGAs. Big ones. :) These were 1000s of frames per second-type systems intended for scientific work, though. Maybe beyond what you're after, but even a cinematic-quality experience is probably beyond the NSLU2. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trendnet TV-IP312W/Zonet ZVC7630W/Fitivision CS-1013
GoatZilla wrote: Has anyone looked at getting Debian on one of these things? I haven't, but I think you should. ;) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: armel boxes for Debian
Joey Hess wrote: If we had an armel buildd that used ccache and had pre-built versions of all the security sensitive packages in its cache, updates for most packages could probably be built in a timeframe that compares with other architectures. Aside from the complexity of setting this up and desire for KISS, is there any reason not to consider doing this? I bet the ccache would be volatile enough that you wouldn't be able to exploit it repeatably. But you could task that maintenance work to the machine itself, so there's no reason not configure it that way. I think the reality is that ARM machines just can't compete with the high-horsepower machines in x86 and PPC worlds. If that makes us "second-class citizens" to the Security team, there's no point in denying it. I like the idea that Security patches come out as quickly as they can, without being gated by the performance of a slow architecture. Compared to x86, ARM isn't a very inviting exploit target so if we're 12 hours behind them, I really don't see the problem. Far better that we tune for consistency configuration-wise with the rest of Debian, methinks, and just accept that our CPUs are slower. Over time, the performance gap may close without us doing anything special, but if we produce a headache-inducing setup in an attempt to improve performance in the near-term, then we have to go through more work to undo that setup later when we get faster chips. I don't like to do work twice! Just my (non-DD) opinion... BTW, I've got my n4100 running armel now, and even with 512MB the performance is ... underwhelming. And by ARM standards, this machine is big-iron! b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on N4100
Bill Gatliff wrote: The gcc came from crosstool-ng-1.0. Despite my repeated requests, crosstool-ng-1.0 insisted on building gcc-4.2.2. So I built my own gcc-4.1.1, used that to build the _same_ kernel, and the box is now solid. Go figure. If I had more hours in the day, I'd investigate further. At the moment, I have leave it as it is now... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on N4100
1d0c r8 : cb65fbd1 r7 : 8f0e6234 r6 : adca82b9 r5 : 8f1a7d20 r4 : r3 : r2 : r1 : 02b9 r0 : 0e2a1500 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 397F Table: AD7CC000 DAC: 0017 Process swapper (pid: 0, stack limit = 0x802ba1a0) Stack: (0x802bbd40 to 0x802bc000) bd40: 8f1a7d20 802d67c4 80342d9c bd60: 80341d0c 803416ec 802bbda4 802bbd78 802069f8 802228ec 801ec804 8f0e6220 bd80: 8f1a7d20 80341aec 0008 80340a08 ffc091a0 807b6ba0 802bbddc 802bbda8 bda0: 80206fe0 802068d8 80655000 801ec85c 802bbddc 802bbdc0 80245094 801ec954 bdc0: 8f1a7d20 803409f8 80655000 0008 802bbe04 802bbde0 801f0cdc 80206bcc bde0: 0001 8f1a7d20 8f1a7d20 0067 0067 80655260 802bbe5c 802bbe08 be00: 80190818 801f0ac4 0040 802bbe6c 80655000 ffc091b0 9097d1a0 001b be20: 0023 9097d000 01b0 0100 80655260 807cac00 be40: 807cac00 0040 802bbea4 802bbe9c 802bbe60 8018b0e0 80190364 be60: 802bbe8c 012c 80036838 0001 807cac00 807cacc0 80340768 be80: 802bbea4 cd4d 802bf618 80340778 802bbed4 802bbea0 801f2694 8018b028 bea0: 802bbea0 012c 1400 80325140 0001 000a 80325100 0001 bec0: 80326c18 802bbf04 802bbed8 8003feb8 801f2610 001b bee0: 001f 0800 802bbf48 a001e39c 69052e30 a001e1bc 802bbf14 802bbf08 bf00: 800401d8 8003fe5c 802bbf44 802bbf18 80025930 800401a0 802bbf54 802bbf28 bf20: 001f 0800 8031f748 a001e39c a001e1bc 802bbf9c 802bbf48 bf40: 800239b0 80025834 0001 802ba000 6013 80026260 802ba000 bf60: 80026260 8031f748 a001e39c 69052e30 a001e1bc 802bbf9c 802bbfa0 802bbf90 bf80: 800262a4 800262b0 6013 802bbfbc 802bbfa0 800260c8 8002626c bfa0: 803278ac 8031ebfc 802bdc64 8034ba00 802bbfcc 802bbfc0 800232bc 80026098 bfc0: 802bbff4 802bbfd0 80008870 800232a4 80008388 8031f828 bfe0: 397d 8031f7c8 802bbff8 a0008030 800086b0 Backtrace: [<802228e0>] (tcp_v4_rcv+0x0/0x904) from [<802069f8>] (ip_local_deliver+0x12c/0x204) [<802068cc>] (ip_local_deliver+0x0/0x204) from [<80206fe0>] (ip_rcv+0x420/0x468) [<80206bc0>] (ip_rcv+0x0/0x468) from [<801f0cdc>] (netif_receive_skb+0x224/0x24c) r7 = 0008 r6 = 80655000 r5 = 803409F8 r4 = 8F1A7D20 [<801f0ab8>] (netif_receive_skb+0x0/0x24c) from [<80190818>] (e1000_clean_rx_irq+0x4c0/0x590) r8 = 80655260 r7 = 0067 r6 = 0067 r5 = 8F1A7D20 r4 = 8F1A7D20 [<80190358>] (e1000_clean_rx_irq+0x0/0x590) from [<8018b0e0>] (e1000_clean+0xc4/0x1c8) [<8018b01c>] (e1000_clean+0x0/0x1c8) from [<801f2694>] (net_rx_action+0x90/0x160) [<801f2604>] (net_rx_action+0x0/0x160) from [<8003feb8>] (__do_softirq+0x68/0xe0) [<8003fe50>] (__do_softirq+0x0/0xe0) from [<800401d8>] (irq_exit+0x44/0x4c) [<80040194>] (irq_exit+0x0/0x4c) from [<80025930>] (asm_do_IRQ+0x108/0x124) [<80025828>] (asm_do_IRQ+0x0/0x124) from [<800239b0>] (__irq_svc+0x30/0x80) [<80026260>] (default_idle+0x0/0x58) from [<800260c8>] (cpu_idle+0x3c/0x58) [<8002608c>] (cpu_idle+0x0/0x58) from [<800232bc>] (rest_init+0x24/0x2c) r7 = 8034BA00 r6 = 802BDC64 r5 = 8031EBFC r4 = 803278AC [<80023298>] (rest_init+0x0/0x2c) from [<80008870>] (start_kernel+0x1cc/0x224) [<800086a4>] (start_kernel+0x0/0x224) from [] (0xa0008030) Code: 0a09 e153000c 0a07 e1a02001 (e5921000) <0>Kernel panic - not syncing: Aiee, killing interrupt handler! <0>Rebooting in 5 seconds I sometimes see OOPSes in udp_v4_get_port as well. Any ideas? This is the wpkg linux-2.6.17.8 kernel, rebuilt to add ramdisks, md raid 5 and initrd. The gcc came from crosstool-ng-1.0. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on N4100
Bill Gatliff wrote: Ok. I'm very, very close. Details to follow shortly. :) :) Still very close, but not there just yet. :( To recap. I rebuilt the wpkg kernel, to turn on things like NFS and ramdisks. I used a gcc-4.2.1 kernel constructed with crosstool-ng. I used the ads initrd image, downloading it as a ramdisk. Installation-wise, there weren't any significant issues. So I get the runtime installed fine, which naturally includes a bunch of network traffic to download the packages, etc. But after a restart the system I get seemingly-random oopses that seem related to incoming network packets. If I use the debian runtime, the OOPS happens every kernel boot. If I use NFS root, no oopses. Very strange... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on N4100
Martin Michlmayr wrote: There's no d-i image. The URL above is your best bet. Ok. I'm very, very close. Details to follow shortly. :) :) Quick question. I thought armel implied EABI, but I notice that the ads installer image seems to require an OABI-capable kernel. It doesn't appear to work with an EABI-only kernel. Thoughts? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian on N4100
Guys: I've had just about all of my stock N4100 that I can stand. :) Is there an n4100 d-i image around anywhere? I tried the one for the n2100, it just hangs after mounting. Can't rule out a kernel problem, I used a kernel from here: http://wpkg.org/Running_Debian_on_Thecus_n4100 I'm in the process of building my own kernel, one with NFS support so that I can use debootstrap. Suggestions? I just don't want to reinvent the wheel... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: leisner: rm assertion
Peter Palfrader wrote: Hi Bill, arm folks, in the sid chroot on leisner this can be observed: [sid] leisner:~# dpkg -i /var/cache/apt/archives/dpkg_1.14.16.6_arm.deb (Reading database ... 31850 files and directories currently installed.) Preparing to replace dpkg 1.14.16.6 (using .../dpkg_1.14.16.6_arm.deb) ... Unpacking replacement dpkg ... rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == RM_USER_DECLINED || (status) == RM_ERROR)' failed. dpkg: error while cleaning up: subprocess rm cleanup killed by signal (Aborted) Setting up dpkg (1.14.16.6) ... chown: changing ownership of `Aq\207': No such file or directory dpkg: error processing dpkg (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: dpkg Do we have a guess whether this is hardware, kernel, or coreutils related? (anybody else seeing this?) Yep, I've seen it: http://bugs.debian.org/462677 I'll see about the workaround. I don't know the root cause. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-boost-devel] Boost needs help on ARM
Steve M. Robbins wrote: Ah. I didn't know that. Thanks. Is there any mechanism to prevent this in future? For example, can boost be added to a list of packages that are not to be built on a netwinder? Netwinders et al. are getting really long in the tooth, and are pretty underpowered for this kind of thing. Hedges is a good arm buildd. I think it's got enough horsepower to do armel work too, but that's an admin thing. As for developer machines, I've outspent myself putting up hedges and leisner--- and the latter is blacklisted right now because of the local root exploit kernel problem. Anyone? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security buildd for armel
Kevin Price wrote: Hi Martin, Martin Guy schrieb: If it's just a question of money I don't mind buying the security team an N2100, but mine is giving segfaults and bus errors on long builds so you might like to consider something different. Are you saying that in general N2100 might be unreliable? Hedges is an N2100 that I outfitted with 512MB SDRAM. Anyone know how it's holding up? Top says it's not idling, but loaded 1.15 on average with 32MB free. Dmesg and the logs don't show anything ugly. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security buildd for armel
Moritz Muehlenhoff wrote: Also there are four updates for iceweasel, xulrunner, icedove and iceape coming very soon, which take 12-15 hours each, while the second slowest arch requires ca. 4-5 hours, imposing another delay. It takes that long on hedges.billgatliff.com? Wow! Are you saying that _arm_ is lacking high-grunt hardware, or _arme[lb]_? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: more ram/swap on leisner, please?
Peter Palfrader wrote: On Wed, 02 Jan 2008, Bill Gatliff wrote: The kernel is NOT running the nbd swap patch, so I don't know if the system will deadlock under stress, or not... Upgraded the chroots last night - or tried to. It has exceptionally slow so I had to leave it running when I went to bed. This morning the box appears to be offline - did it lock up or is this just a coincidence? :) Appears to be hung. Lennert is right again! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: more ram/swap on leisner, please?
Lennert Buytenhek wrote: On Wed, Jan 02, 2008 at 08:30:07PM +, Martin Guy wrote: I run NDB swap on little arms and qemus routinely and have never had a lockup despite stressing them. You obviously haven't stressed your systems hard enough, then. :) Heh, maybe because they're stressing _me_ even harder! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: more ram/swap on leisner, please?
Martin Guy wrote: I run NDB swap on little arms and qemus routinely and have never had a lockup despite stressing them. The trick is *not* to include nbd-client's -swap flag, with which, if i remember correctly, it doesn't work at all. Indeed. With that flag, nbd-client won't run at all. The other way is to create an ext2 in a file on an NFS-mounted volume, loop-mount it on the ARM box, create a big file in it, mkswap and swapon that. A bit contorted but it was stable the one time I had to do that. Yea, I can't get my head around that until next week, at least. :) Sorry about repetitions, Bill, thought I'd put this on list too. You did. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: more ram/swap on leisner, please?
Lennert Buytenhek wrote: On Wed, Jan 02, 2008 at 01:00:02PM -0600, Bill Gatliff wrote: Ok, I've set up a 5GB swap over NBD. If the system reboots, it won't automagically reattach it. The kernel is NOT running the nbd swap patch, so I don't know if the system will deadlock under stress, or not... It most likely will... Older kernels definitely would. But the mailing lists aren't so clear about the current state of things, and I can't seem to find the patches either... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: more ram/swap on leisner, please?
Guys: Ok, I've set up a 5GB swap over NBD. If the system reboots, it won't automagically reattach it. The kernel is NOT running the nbd swap patch, so I don't know if the system will deadlock under stress, or not... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thecus 2100, extremly slow r8169
Martin Michlmayr wrote: * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-12-03 11:52]: Im running kernel 2.6.18-5-iop32x and the needwork speed is something around < 1MBit/s I get around 1.7 MB/s (that's MB/s, not MBit/s) copying a large file with scp from one machine to my N2100 on my local 100MBit network. So that's much more than 1MBit/s and the scp is limited by the CPU rather than the networking - I'm sure I could get more than 1.7 MB/s if I used something that didn't rely so much on CPU, e.g. ftp. This is with 2.6.18-5, 2.6.22-3 and 2.6.23-1. Can you switch to blowfish for scp, the way you can for ssh? That's a pretty light algorithm, but maybe not such that you'd notice any significant improvement. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please reschedule regina-normal/arm build
Ben Burton wrote: Hi again, Thanks for rescheduling another regina-normal/arm build. Unfortunately it looks as though it crashed at the same point in the test suite as last time. I did try to reproduce this problem myself -- Martin Guy was good enough to give me access to a box of his with enough oomph to actually build the package (which leisner.d.o does not have). When I built regina-normal on his machine the test suite ran perfectly. Can you reproduce it with a QEMU running armel and/or arm? Was Martin's machine big-endian, perhaps? What is the test that's failing? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installing debian on N2100
Martin Michlmayr wrote: * Andrew Haswell <[EMAIL PROTECTED]> [2007-12-13 19:57]: I've been waiting to see if the installer will get fixed so i can install Debian on my Thecus n2100. [...] I would like to do this as a project over christmas, im just worried about getting stranded. Advice greatfully received. Given all the delays with 4.0r2, I'm finally ready to give in and explain the workaround on my web page. I hope to find time to do it this weekend... so you should be able to do the installation over Christmas. :) Any idea if the same procedure will work for the n4100? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: objc on armel - why not?
Martin Guy wrote: The log from the last build says: DEBIAN_BUILDARCH: Install prefix: /usr Will not build the biarch compilers Will build the C++ compiler Will not build the ObjC compiler: disabled for armel Will build the Obj-C++ compiler Will build the Fortran 95 compiler. but I dunno why... When I get the Thecus box up I'll try compiling it with armel and see what happens... unless someone knows better... M Leisner is back up, and I installed an armel chroot on it. You're welcome to use it if that helps. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian armel status update
Wookey wrote: On 2007-11-01 23:40 +0200, Riku Voipio wrote: = Where is armel port today = == Developer machine == I believe Wookey was working on this - any news? Yes. I updated http://wiki.debian.org/armelLennyReleaseRecertification yesterday with some info. A machine (500Mhz 384MB balloon3 with 250GB disk) has been donated (by Cambridge University Eng dept, hosting by Toby Churchill Ltd on a leased line) and somewhat set-up (chroot config needs some more work and it needs DSA LDAP merging once properly on-line. It is currently waiting for NTL to give us some more external IPs as there is not one spare for it to use (and they are of course being crap). I expect this to get fixed next week so that the machine can actually be accessed. I have also got a kurobox from Marvell donated to Debian. I could set that one as another dev-access box, unless anyone has a better use for it. Only 128Mb RAM but much faster disk than the balloon. I think this is one of the Orion machines mentioned below. Is the arm distribution kernel for the n2100 armel-capable? Could we install an armel chroot on hedges, and have it serve as a buildd for both arm and armel? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VGA cards on USB or such?
Michelle Konzack wrote: Since I have not found arm/mips based SBC's with onboard Graphic, my question is: You must be looking in the wrong places. :) Nearly anything based on an AU1x000 (MIPS) chip will have an onboard VGA-quality adapter because it's built into that chip. Likewise for many AT91SAM926x (ARM) and some AVR32 chips. There are many others, but those come to mind right now. Silicon Motion's SM50x chips are great add-on chips for microcontrollers that don't have onboard graphics abilities. Cogent Computer Systems, among others, makes a line of system-on-module boards that use these chips. They're pretty low-power. HTH, b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Re: Java interpreter on ARM GNU/Linux
Peter Naulls wrote: In message <[EMAIL PROTECTED]> Bill Gatliff <[EMAIL PROTECTED]> wrote: Does the n2100 support both OABI and EABI? If so, maybe someone should put chroots for both on hedges? Any ARM processor made in the last 10 years or so will do EABI. Of course, you'll need a modern kernel with EABI enabled (the newer the better) to run both EABI and OABI sensibly on the same system. D'oh! :) Yes, I meant to type "n2100 _kernel_". I don't know if the packaged one for that board is set up to do both OABI and EABI. b.g. -- Bill Gatliff [EMAIL PROTECTED]
Re: Fw: Re: Java interpreter on ARM GNU/Linux
Wookey wrote: Good news on the java front thanks to sterling efforts by aph. This still needs merging back into the debian packaging. - Forwarded message from Andrew Haley <[EMAIL PROTECTED]> - I can work around some of the failures, but I can't really be bothered: the real fix for this is EABI. Does the n2100 support both OABI and EABI? If so, maybe someone should put chroots for both on hedges? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Re: debian java libffi patches
Wookey wrote: And a follow-on - Forwarded message from Andrew Haley <[EMAIL PROTECTED]> - From: Andrew Haley <[EMAIL PROTECTED]> Date: Wed, 4 Jul 2007 11:21:11 +0100 To: Wookey <[EMAIL PROTECTED]>, Aurelien Jarno <[EMAIL PROTECTED]> Subject: Re: debian java libffi patches X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7-deb, No Andrew Haley writes: > Wookey writes: > > On 2007-07-03 17:02 +0100, Andrew Haley wrote: > > > [EMAIL PROTECTED]:~$ apt-get source libjava > > > Reading package lists... Done > > > Building dependency tree... Done > > > E: You must put some 'source' URIs in your sources.list > > > [EMAIL PROTECTED]:~$ apt-get source libgcj > > > Reading package lists... Done > > > Building dependency tree... Done > > > E: You must put some 'source' URIs in your sources.list > > > > Only the binary repositories were listed (sources not normally needed > > here, you are expected to be operating in the chroots). > > > > I've added source repositories too - should work now. > > > > (I fell off the net for a couple of hours after the thunder and > > lightning) > > Ah. :) Remarkably, all the machines here stayed up despite the brownouts. > > Anyway, I have a problem. The linker is complaining about overflows > in relocs, and I can see why: > > 2d9c: ebfebl 0 > 2d9c: R_ARM_PLT32 lt_dlopenext > > This looks to me like offsets from an instruction to the PLT have to > be contained within 24 bits. Is that correct? The text section of > libgcj (unoptimized) is 52794995 bytes, which I reckon needs a 26 or > 27 bit offset field, depending on whether the bl instruction takes a > signed or an unsigned offset. > > size .libs/libgcj.so.9.0.0 >textdata bss dec hex filename > 527949954723732 219216 5773794337102d7 .libs/libgcj.so.9.0.0 > > Dows the 24-bit limit of the bl instruction impose an absolute limit > on the size of a shared library? I would think that it would, at least in the general case. (OT: *man* that's one hge library!!) The BL instruction has a 24-bit signed offset field. If you're going bigger than that, use gcc's -mlong-calls option, which forces gcc to emit branch instructions in a two-instruction sequence which has a modest performance overhead but gives you the full 32-bit address space. Which suggests that the text size when built with -Os would be about halved -- 24 megabytes. ... which would have performance implications (probably not serious ones), and would probably only postpone the inevitable. Maybe you want to use -mlong-calls for the unoptimized case, and not anywhere else? At one point I thought gas/ld would patch up oversized branch instructions, but I guess not... b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What demotivates debian-arm? [Was: Re: Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure]
Lennert Buytenhek wrote: What I wrote was: The regular ARM port isn't in very good shape at all, and there is no indication that armeb or armel would end up doing any better. I.e., regardless of the technical merits of the port, there is no indication that the current problems in the old-ABI port are suddenly going to disappear once/if we switch to EABI (if ever.) ... problems that you still haven't enumerated in any quantifiable way. But by now, this is probably not the best thread for that. :) I'm not saying that your business absolutely depends on it, but being able to take a set of prebuilt, QA'd binary packages and use those does save time over having to compile everything manually, so it's not that the value of Debian is zero to you. Agreed. Which is why I support it as best I can. As I invest in Debian, Debian gives back to me--- and to others. I now have half-a-dozen clients who are using it one capacity or another, and some of the developers on those projects have expressed an interest in becoming more involved in Debian maintenance and improvement. I don't keep tabs on them, for all I know they're major contributors by now. Or perhaps not. Dunno. If you would be using, say, OpenEmbedded in your consulting business, would you (considering that you are so very very busy working very hard to make sure that you and your family get by that you can't write a simple 5-minute patch without a PO to cover for it) still be writing a long email on the debian-arm@ mailing list arguing that Debian should not drop their ARM port? Show me a patch that can be investigated and resolved by a mere Debian user in only 5 minutes. :)Despite my efforts, I'm still not the power-user that you are. Things take longer than that for most of us. And I _never_ said that it would require a P.O. for me to release a 5-minute patch--- or any patch, for that matter--- because it isn't true. Not saying anything about your statement, I disagree with the assertion that all the debian-arm port needs is a little bit of commercial attention, i.e. that the success of the port depends on external factors. I said: 1. Debian-arm could benefit from some focused attention. 2. One way to get that focus is by making it someone's job. And I also said this: 3. I wouldn't mind it if debian-arm maintenance was my job. "Debian has no value to me.", I think we've already asserted that that is not true. How about: "Take Linux away, and I'll just go back to using *BSD. Linux will become irrelevant to me, and I'll apply my time, skills, hardware and other resources somewhere else. It's that simple, and I won't lose any sleep over it." Or: "Take the IT industry away, and I'll just go back to herding sheep. Computers will become irrelevant to me, and I'll apply my time, skills, hardware and other resources somewhere else. It's that simple, and I won't lose any sleep over it." You're taking this to a ridiculous extreme, and I won't follow you there except to note that I did in fact grow up on a farm (cows, not sheep), and the possibility of returning to that lifestyle is one that I find appealing on certain days. :) That's a red herring. A lot of people have day jobs and get along just fine answering a question here and there on some mailing list here and there. And kudos to them! But I wasn't talking about "answering a question here and there". I _would_ object against the (purely hypothetical) case where Bill Gatliff would get a PO to implement a feature X and then sends Lennert email saying "What is feature X? How do I implement it? Can you do it for me? This week? Thanks!" And I would too! But now we've both asserted that that's a purely hypothetical case, so there's no point continuing to discuss it in this thread. So if the guy who pimps his consulting business at every possible opportunity (BTW, do you know I have a consulting business?) posts to the linux-arm-kernel@ mailing list saying something like "Before I dig into it, has anyone seen problems with $FOO?", I really do start to wonder. Yes, I know you have a consulting business too. Presumably he's being paid to make $FOO work, which means that he does have time to spend on it, but before spending any time on it himself, he'd rather check first whether he can find someone else to fix the issue for him. Personally, in such cases, I just use the 'D' key. ... as you are free to do. And please continue to do so, as it suits you. Doesn't offend me at all, really. Yes, I do post on l-a-k as well. And yes, I do ask if someone has made progress on somethi
What demotivates debian-arm? [Was: Re: Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure]
ntil ADS made it such that you didn't have to get distracted by a bunch of other stuff for a few weeks. And when they did, you turned out work product in less than two months. (Kudos to you and ADS, btw). In that regard, I don't think that pitching your services on this mailing list is helping to motivate people to work on the issues that the Debian ARM port is currently facing very much. ... which is why I saved the motivation bits for the last paragraph. The rest was my vote against eliminating ARM, citing reasons I think debian-arm isn't getting the attention it deserves, and offering to help connect my resources (skills, time, but no funding) with others (no skills or time, but available funding) to come up with a way to keep debian-arm moving forward. If you want to work on a volunteer basis, you're certainly free to do so (if you don't, that's fine too but it'd be a real loss and I for one would miss you greatly). Some of us would also love to come to the party, but can't for all kinds of reasons. Now everyone knows mine, and if they want to see me there more often then they know how to help. It pains me a bit to admit my shortcomings, but I won't apologize for being honest and realistic about myself here. Finally, the fact that I get paid money to develop embedded systems puts YOU off Debian? That doesn't sound much like my problem. And I don't think you speak for the debian-arm community as a whole when you say that, either. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure
Lennert: This isn't directed towards you, but a general remark is that all the talk about dropping arm as a release architecture over the last couple of years (for reasons that seem mostly beyond my control), and the resulting uncertainty has definitely made most of my motivation to work on the Debian ARM port disappear. I don't think anyone enjoys working on a project that is in a 'maybe-sort-of-almost-dropped' state pretty much all the time. Maybe the ARM port should just be dropped to have it over with. Do you mean the "arm" port vs. "armel" and "armeb"? Or do you mean ARM targets in general? I don't have a problem dropping the "arm" port but keeping armel and armeb, since the EABI stuff renders everything else obsolete. But if you're suggesting that Debian should drop all ARM targets entirely, I'm totally against that! I think the problem with Debian for ARM targets is the same as for other non-x86 targets, in that there are limited resources for support because the required hardware and skills are hard to come by. I would _gladly_ take on that responsibility, since I have the skills *and* the hardware, if I could find a way to do it and still keep my family fed (suggestions and purchase orders welcome!). It's a full-time job for someone, and you aren't going to keep someone with the right skills and hardware focused on it if they have to at the same time find an income from somewhere else. It's too big a job. That's reality. The limited opportunity I have for it now is often at the expense of other project work and family time, which is _not_ the way to grow and maintain a serious project. Dunc-tank was a step in the right direction, and we see how that turned out. :( Frankly, I think Debian is as awesome as it is _precisely because_ of its devotion to non-x86 targets (among other reasons, of course). I don't want to see that go away. Let's pool our resources, face reality, and find a way to give Debian for ARM the time and attention it deserves. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
