Yes, the problem is figuring out *what* is causing the box to "hang". Note that it could be "something else" that just happens to tickle some graphics I/O, etc.
Until I can *see* the dmesg output, it's just a guessing game. Easier to build a stripped down kernel with *nothing*, see what's going on, make note of the "not configured" devices, then add then back in.
(sigh) Everything just takes *time* :-/
According to Wikipedia (would they lie to you?), the Atoms released in
2008 didn't have integrated video, but the later ones did. I think I was working with the "Pineview" [ND][45].. series chips, which did.I haven't played with BSD much lately, but newer Linux distributions seem to compile the kernel to ask for something other than 80x25 text fairly early in the boot process - I think this is mostly so you can see more of the boot-time messages on the screen. If BSD is doing the same thing, perhaps that change is causing trouble. Linux has a "vga=" kernel boot parameter that lets you force a video mode.
Linux also has a "console=" boot parameter that can give you a serial console if you want, and I think this happens early enough that it gets the kernel boot messages. Hook up your Teletype and party like it's
1969! :)The last time I played with BSD a lot, it was FreeBSD, and I got the impression that while the security and networking was better than Linux, the device support was not nearly as good as Linux.
My checkout step was usually to boot a Linux live CD/DVD, using an external optical drive with its own power supply. In theory, you can put a bootable image on a USB stick, but I have found that the boot image, USB stick, BIOS, and phase of the moon must all align to get this to work right - the external optical drive was slower but much more likely to work.
Matt Roberds
From what I can gather looking at the "Setup" screen, this is an earlier series -- Diamondville -- Atom 330 (dual core, 1.6GHz, IA-64, Hyperthreading capable. *No* GPU (seems consistent from the number of heatsinks in the box)
No idea what the kernel on the Live CD that I was using was built as. Hence, the reason it's easier to just build a new one from scratch
*knowing* what sort of cruft you've thrown into the pot.Have to eBay the TTY soon. One more thing to get rid of. (last time I checked, folks were spending $1K on the silly things!)
I started out with NetBSD back at v0.8. (maybe 1993?) Soon moved to FreeBSD (at the time, they were at 0.9, IIRC) because they were
*solely* focused on i386 (NetBSD was pursuing many architectures concurrently -- admirable but meant getting an i386 box with the features that I wanted WORKING was more effort). Stayed there until about 2.2.7/8 (maybe 1998?). Then, disappointed with the falling quality (esp the ports/packages collection) -- and, having acquired a bit of larger iron (unsupported on FreeBSD) -- moved back to NetBSD.Which is where I have stayed, since (at least in terms of my own workstations/servers that run FOSS).
Yeah, I opted to boot from an external CD-ROM with a "live CD" than to bother installing a real system (actually, I didn't have a small enough disk drive to waste on the task :< ).
I'll make a list of which boxes I can discard/replace in the event that these little things prove "suitable". Then, evaluate the effort to investigate more fully. (also gives me some time to round up smaller disk drives)
That says to me the problem might well not be the video, but that the video is an unintended victim of the real problem. I believe this text stream can be redirected to a file, no? Maybe that is the way to go. Do a postmortem on the text file.
Wow, it is only my most recent laptop that has that much ram. I design FPGAs and got by on 3 GB for some time.
Is NetBSD that different from Linux? I figured it was just another flavor.
I don't think the computers are designed for any OS. The OS is modified for the newest processors and chips. Motherboards are just designed for target markets.
-- Rick
Yes, but the text file has to be *stored* somewhere that isn't volatile! I.e., you need writable media in the machine! ;)
I.e., the only way I can move forward is to build a "system" and then let that system boot -- having a disk on which to scribble log messages. Of course, if the system doesn't get to multiuser state (or, if the network IF doesn't come up), then there is no way to troubleshoot *that*.
So, best shot for getting The Answers on the first shot is to build a stripped down kernel -- remove any drivers that are not essential. *Hope* it gets through the boot sequence (to "single-user"). Then, examine the dmesg output to see which devices it detected but didn't "configure" (because the corresponding drivers weren't wired in).
If you can get a console, building a "custom" NetBSD kernel tailored for that particular device is no more than half an hour, start to finish.
I've lived with far less. My first boxes (386) had 12MB -- and the memory alone set me back $1500/box!
I don't think any of the workstations on which I spend most of my time have more than 3G usable. Not sure of the laptops as I spend very little time with them.
The blade server has 14? dual dual-core's in it each with 4G, IIRC. But, it dims the lights when I fire it up... :<
Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, yadayadaBSD, etc. are all OS environments. E.g., what you would call "distros" in the Linux camp.
The *BSD's also have a different heritage -- all outgrowths of the 386BSD sources (1991/2) -- derived from (ultimately) the 4.3BSD (Net/2) distribution.
The key difference between the *BSD's and the Linux camp is the licensing terms that are applied. I.e., you can FREELY take the NetBSD kernel, modify it, include it in commercial products, etc. without ever having to share -- or make available the sources from which you started -- any of your modifications/enhancements with others[1] (IIRC, you have to acknowledge the copyright on the inherited code and that's about it)
I.e., you aren't "encumbered" with the GPL's terms. You are free to "make the codebase yours" -- as if you had developed it entirely "in house" (subject to the copyright notice restriction and the indemnification of the original copyright holders, etc.)
The same is true of FreeBSD/PicoBSD, OpenBSD, etc.
[And, there is far less of a "fanboy" attitude surrounding it/them and its/their development]Yes, but if a market embraces Windows, then the product effectively was "designed for Windows".
[1] The same can not be said of the NetBSD "OS" -- as it includes many applications that are covered under less permissive licensing terms (e.g., much FSF code).
If you don't have writable media, what are you booting from, a CD with no HD? So put a HD on it...
So adding a HD is "building a system"? The software you are booting doesn't know about hard drives? Really?
If you want to do all that work. Or you could plug a hard drive to it.
Plugging in a hard drive is 5 minutes and the first 4 is finding a cable.
When I say Linux, I am referring to all of those collectively. When you say you don't run Linux, you mean... whatever... this can be exasperating sometimes.
The point is that why can't your version of Linux "distro" do the enumeration?
Ok, whatever.... by your definition of "designed for Windows" it has no useful meaning.
-- Rick
Correct. It takes a 2.5" SATA drive. All of the 2.5" SATA drives that I have a large and "have stuff on them". So, putting a disk drive in the box means cleaning off one of these -- just to see why the video is getting scrambled, etc.
As it isn't a "pressing need" (i.e., it can surely wait a week or two), the cost of making a disk *available* for it far exceeds the value of doing so! :-/
I *think* I have some "converters" that could let me adapt one of my PATA drives. OTOH, they might be the exact "wrong" type of converters...
(I could also drag out a 3" SATA drive, am external power supply and hack together some suitable cables... again, a lot of work vs. just waiting until I can get my hands on some smaller/disposable SATA drives)
No. Add a hard drive and install the system *on* that hard drive (so that the system knows it has a place to scribble -- which it doesn't know when booting off a read-only medium).
If you're going to put the system on the disk, then you might as well spend the half hour to customize the kernel so it stands a better chance of getting past whatever is causing the live CD to scramble video...
See above. Just *adding* a hard disk to the system (AND CONTINUING TO BOOT OFF THE LIVE CD) will result in exactly the same situation that I have now -- messages won't get stored anywhere because the system has no knowledge of how "acceptable" it would be to scribble on that disk!
Normally, the kernel buffers diagnostic/log messages while it is booting. When it is "up" (or, nearly so), these are flushed to log files -- typically under /var/log. If the entire file system is represented by a live CD, then /var/log is not writeable. No way to see what it *would* have scribbled there!
[Of course, if the kernel never makes it all the way "up", then all bets are off, anyway!]If the kernel manages to boot, you can still examine these "in core" messages AS IF they were entered in the log file (dmesg(8) dumps the "system message buffer"). So, in *most* situations, I can boot a live CD, wait for the prompt, type "dmesg | more" and examine the various messages to see what devices are present, how much memory, etc.
If I can get to a command prompt, I can manually mount a thumb drive and copy the messages to that medium (dmesg > /mnt/messages.txt)
Or, I can manually bring up a network interface and move stuff on/off via that mechanism.
[But, I need access to a command prompt to do so!]See above. All that would do is *eventually* list a hard disk as one of the devices probed in the system -- *if* the boot managed to make it that far.
Take a virgin machine. Try to install Linux, Windows, BeOS, OSX, etc. You've got executables on a CD/DVD. And, a disk onto which you can scribble!
But, if you can't get to a command prompt, you can't tell the machine to *use* that disk to scribble!
That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris, etc.
*BSD is different from Linux as Linux is different from Windows and Windows is different from OSX..."I don't run Linux" I also don't run OSX. So, if OSX could "do it", I'd be just as SOL.
My NetBSD "live cd" never gets to a command prompt for me to be able to *see* what it is saying! I can watch the first part of the boot process... see the first group of devices successfully probed (have to look fast because it scrolls by in a jiffy)... But, it gets to a point where the screen gets scrambled.
Looking at the screen, I can see much of the previous messages (in red-colored text) still present. But, it is as if the HSync has been lost so nothing is clear/readable.
What I want/need to know is the message that it was getting ready to emit just as the screen went wonky. If the kernel is truly crashed, then I wouldn't be able to get this message from it even if I had a means of typing: dmesg | more If just the video is crashed, it is possible that the kernel is still functioning (doubtful) but I can't talk to it -- because I can't type at the "console" and the network isn't "up".
The solution is to install a simpler kernel (e.g., I can live without USB support, network interface, wireless, etc. WHILE I am troubleshooting) and then watch to see what the LIKELY problem may be.
The fact that the kernel is able to emit messages for a portion of the boot process suggests the video can operate as a "dumb text console" (because it *is* -- up until that point!). I just need to make sure nothing interferes with it *continuing* to do so.
With a system on disk (or, CD if I want to endlessly burn CD's!), I can boot a specific kernel: boot netbsd.STRIPPED_DOWN and observe the results. Then, modify this kernel (add in some devices not present in STRIPPED_DOWN) and reboot, specifying this
*new* kernel: boot netbsd.A_FEW_DEVICES and repeat until I find the change that causes the screen to go wonky.It means I am more likely to find a Windows release that will run "flawlessly" on this particular set of hardware. Even if the device/driver that is (probably) causing my problem is completely proprietary/closed.
OTOH, expecting Linux, *BSD, OSX to run on "any random hardware" is a bit of a crap shoot.
Say Don how hard would it be to try a different monitor? A different native resolution may not scramble.
?-)
That;s an option. But, note that the "scrolling text" that would normally appear (and has appeared up until this point) appears to have stopped scrolling. I.e., if you could filter out the sync problems, you would see that the underlying image is static from the moment the scrambling starts -- not as if the scrolling had continued and has finally stopped at a "login" prompt.
It's as if something has been wonked and/or the system is expecting a result that it isn't getting (from the hardware).
In an effort to get at dmesg(8) output without building a new kernel, I tried a few other "products" that I had lying around on CD (to save me the hassle of having to fire up file server, download images and burn).
An old FreeBSD install CD (1998) complained loudly! "bounce memory". A recent OPHCrack CD resulted in the same scrambling (I believe it is Linux based).
However, a Clonezilla CD didn't fret (when configured 800x600 as its default offering). Accessing a shell from there, I was able to mount a thumb drive and copy the dmesg output to it! (because "dmesg | more" apparently doesn't work the same way under Linux as it does under *BSD so I couldn't examine it interactively!)
The pertinent lines (Linux's dmesg output is WAY too verbose: "I'm setting voo to 26. Now I am going to add it to bar. Having done that, I am going to divide by three...") are:
[ 0.000000] NX (Execute Disable) protection: active [ 0.000000] Memory: 1933912k/1965568k available (2840k kernel code, 31204k reserved, 1372k data, 412k init, 1054216k highmem) [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] Detected 1596.815 MHz processor. [ 0.055590] CPU0: Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping 02 [ 0.148177] Total of 2 processors activated (6441.48 BogoMIPS). [ 3.588418] vesafb: mode is 800x600x16, linelength=1600, pages=7 [ 3.588432] vesafb: protected mode interface info at ccfe:0004 [ 3.588444] vesafb: pmi: set display start = c00cd00e, set palette = c00cd05b [ 3.588454] vesafb: scrolling: redraw [ 3.588465] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 [ 3.589066] vesafb: framebuffer at 0xd0000000, mapped to 0xf8280000, using 1875k, total 131072k [ 3.628198] Console: switching to colour frame buffer device 100x37 [ 3.667295] fb0: VESA VGA frame buffer device [ 4.025707] agpgart-sis 0000:00:00.0: SiS chipset [1039/0671] [ 4.035043] agpgart-sis 0000:00:00.0: AGP aperture is 128M @ 0xf0000000 [ 5.814094] sata_sis 0000:00:05.0: version 1.0 [ 5.814181] sata_sis 0000:00:05.0: PCI INT A -> GSI 17 (level, low)-> IRQ 17 [ 5.835469] sata_sis 0000:00:05.0: Detected SiS 1183/966/966L/968/680 controller in PATA mode [ 6.435391] Atheros(R) L2 Ethernet Driver - version 2.2.3 [ 6.501421] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit Ethernet Driver bnx2x 1.70.30-0 (2011/10/25)
(forgive the wrap -- blame the driver coders!)
Obviously, a SiS chipset for the video (and disk interface!). I'll use that tidbit as a starting point when I build a NetBSD kernel. It should also help me avoid an iteration when it comes to sorting out the disk controller, NIC and wireless.
And, it proves Matt's assertion that I should be able to just leave a text console running on that port (instead of having to drag a "terminal" over to it when it craps out).
While I am at it, I should probably build a bunch of kernels (of varying capabilities) to avoid this sort of issue in the future!
If you have some larger drives available, can't you just copy one of the laptop drives to the larger one, then it is free for the Atom system... That would be 5 minutes of your time and whatever time for it to copy.
Or can the Linux distro boot from a USB stick? Surely you have one of those around...
Aren't there a bunch of ways to skin this cat?
I thought the whole point was you didn't know what to configure the system for!
If you are booting from a CD I guess there is no way to tell the system that it needs to log to the HD anyway.
Well duh! Is it that hard to make an installation on the HD without recompiling it all? I can do that with Windows. You just use a different machine.
Sometimes you make no sense. You just said Linux is the kernal for all of those systems. Now you are saying it is the kernal for Windows too... ok
Is BSD not at all based on Linux? Regardless, don't get hung up on the terminology.
Or others have suggested you work over a serial port. Is there no serial port on this machine? Can you use a USB serial port?
I think it means Windows is designed to run on more hardware than the various alternative OSs. The hardware is simply designed to run...
-- Rick
All I can say here is that I am /so/ glad I use Linux rather than one of the BSD's. (Though I happily agree that BSD has its place, and is the stronger choice for some uses. The world would be poorer without the BSD's.)
There is no point in going into detail here, and I know I am not going to change your mind. I'm just going to give a list of a few key phrases
- if you need something to do during your kernel builds, you can look them up. If you want to discuss any of the items, that's fine. But I am not looking for a fight - I am merely trying to give suggestions that I think could make things easier for you. If you want to stick to BSD here, for whatever reasons, that's fine.
- Recovery boots
- Booting from a USB stick with persistent storage
- Serial port console
- Linux kernel parameters (choosing video modes, disabling hardware, etc.)
- Hardware enumeration utilities (lspci, lsusb, lshw)
- NFS mounts
- Booting over NFS/TFTP
Building my own kernels, especially for a trial-and-error test to identify problems, is probably the last thing I would consider.
My point was that you should be able to see this when using a serial console.
-- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Please don't.
It's like saying birds to refer to all dinosaurs. It doesn't make any sense from a phylogenic standpoint.
-- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
The 500G drives are 2.5's. So, to clear one off, I would need at least 500G of space on another (e.g., 3.5") drive.
Sure! All take varying amounts of time. And, EVENTUALLY, I will
*still* have to build a kernel to run on this machine! So, why not just wait until I have a smaller (capacity) drive that can STAY in the machine, forever? Build the kernel appropriately and solve ALL the problems (instead of investing time just to figure out what NOT to put in the kernel -- that I will still have to build and configure even after I know what this machine's "issue" happens to be!)You build a stripped down kernel. One that doesn't have various video, network, wireless, SCSI HBA, etc. drivers present. I.e., so all it knows about is a "barebones PC architecture" (hence the reason for my initial question re: Atom's).
If you can't boot *that*, then there's no hope! :>
Once you *can*, you examine the dmesg output from the first boot. It will tell you which devices are present but not yet configured (i.e., missing drivers) in the "stripped down kernel".
Add those lines back into the kernel's configuration file. Rebuild. Install as final OPERATING kernel.
In practice, you start with a kernel configuration file that supports everything and comment out all but the most basic components -- to arrive at the "barebones PC". Call this netbsd.BAREBONES (kernels are named /netbsd by convention). Examine the dmesg from this boot. Find the drivers that are missing (by notes in the dmesg) and uncomment them in your "new" kernel configuration file. Then: config NEWKERNELNAME cd ../compile/NEWKERNELNAME make depends make make install and reboot. If you've been observant, you've now got a kernel (NEWKERNELNAME) that supports everything you want in the new hardware/machine.
As the Atom's will run x86 code, the initial BAREBONES kernel can be built on any x86 NetBSD box and just copied onto the disk that will LIVE in the new machine -- along with the rest of the "system". Once it has booted, the new kernel can be built ON that new machine.
A few weeks ago, I did exactly this for another "new" box: made a copy of an existing x86 system (complete filesystem) on a new disk drive. Installed drive. Noted which devices were not correctly probed (dmesg). Modified the kernel configuration file. Rebuild (as illustrated above). Then, reboot.
[Unfortunately, the laptop drive that I did this on has already died. Unsure if it was from abuse or if it was just "getting on in years". So, I'll have to do it again -- perhaps using one of these boxes to replace that machine]
Correct. If, OTOH, the system was booting from a hard disk, then /var/log would be writeable and the log files would populate that portion of the filesystem in the natural course of events.
Similarly, if I can get to a command prompt, I can manually mount some other writeable medium (e.g., thumb drive).
Yes, *knowing* (point of my post!) that Atom's can execute i386 binaries in a functionally equivalent manner means I can just build a BAREBONES kernel on another machine and copy the "complete filesystem" onto the new disk. Then, install in the new machine.
No! Linux is *a* kernel. In DOS parlance, it is COMMAND.COM... for Linux Distros -- and ONLY for Linux Distros!
NetBSD's kernel (entirely different source code -- because there's no GPL code contained within!) is used in NetBSD. FreeBSD's kernel is used in FreeBSD. OpenBSD's kernel is used in OpenBSD. etc. The *BSD kernels share some code but are maintained by different groups and with different goals. So, a FreeBSD kernel won't support NetBSD executables and vice versa (actually, there are some compatibility options that can be used but the kernels aren't just "drop in replacements").
My above statement was meant to illustrate that calling all of these (NetBSD, OpenBSD, FreeBSD, OSX, PicoBSD, etc.) "Linux" is wrong. Just like it would be wrong to call Linux "Windows"!
NetBSD is NetBSD. Linux is Linux. What they have in common is they are maintained in an "open" fashion -- unlike "Windows". Linux, e.g., had its roots in more of a SysV flavor while the BSD's were (not surprisingly) derived from the Berkeley Software Distribution (of "UNIX").
No. Different evolutions, goals, licenses, etc. That was the point I was trying to make.
If the kernel is crashing, then it doesn't matter if I use a serial port or the console. Once device is probed during the boot, the system will "go away". A dead serial console is just as bad as a dead *console*!
Instead of trying to avoid the problem, I'll just *solve* it; when I have a smaller disk that I am willing to *commit* to this machine!
Solve problem and end up with *working* machine -- instead of just a description of the problem followed by actually having to MAKE that working machine!
As I said, this is usually a pretty simple process. This is the first time that I've not been able to take "any old kernel" and get to a point where I can start modifying that kernel. Usually, the big issues are NICs (so, no network connectivity until you get the "right" kernel built) and more exotic I/O's (e.g., SCSI HBA's, wireless adapters, PCMCIA support, etc.).
This is the first time that the video hardware has not liked being tickled the way the kernel wants to tickle it!
"Ontogeny recapitulates phylogeny" - Ernst Haeckel
-- Rick
No, it seems that the machine is locking up when this happens.
In the past, I've always just built a GENERIC kernel, partitioned the new disk, newfs(1) all partitions, filled fstab(5) and copied all the file system from a "template" system onto the new disk... all from within that "template system".
Then, unplug the disk and install it in the new machine. EXPECT the network not to work and other devices to need to be tweeked. But, copy the GENERIC kernel configuration to NEWMACHINE, drop into vi(1) and edit NEWMACHINE to add/remove/change the appropriate lines. Build new kernel (now I am *on* the new machine!) and install it.
This is the first time that I have *had* to rely on a live CD. Lesson learned: build a live cd that has a barebones kernel (which tries to be the least of all worlds) instead of GENERIC (which tries to be all things to all machines). I.e., instead of trying to have a running system on a live CD, try for a DEBUGGABLE system.
A kernel has to be built EVENTUALLY! Why invest time in some other pursuit and *hope* you can relate that to the actual kernel that you will ultimately build?
I don't think you understand just how easy it is to build (or modify) a *BSD kernel. Edit a text file (if you are clever, you will start with a suitable kernel configuration file to reduce the total number of keystrokes) having the name of your new kernel configuration -- e.g. FOO. config FOO cd ../compile/FOO make depend make make install reboot (of course, the makes can all be condensed to a single line).
On a 1GHz machine, it's about 30 minutes to a command prompt on the *new* kernel -- most of that time spent waiting for the compiler.
If you are building the kernel on another "host" machine, then you omit the "install" and "reboot" stages and, instead, copy the resulting kernel to the new medium.
Once *that* machine can boot, you can further tweek the kernel (by editing "FOO" -- which can be embedded in the actual kernel image with a configuration option if you want to make your life easy!)
A kernel has to be built - but it certainly doesn't have to be built by the user. I don't know much about building kernels in the BSD world, but in the Linux world it is a very long time since it was common to bother building your own kernel. Unless you want to patch the kernel, use bleeding-edge versions before your distro has them in place, have /really/ weird hardware, or you are doing kernel development, then there is usually almost nothing to be gained by building it yourself.
For most distros, most of the drivers and many of the other features of the kernel are built as modules. This means they take up some disk space, but are not loaded and don't use any resources unless they are actually used. The difference in ram between compiling something as a module and compiling it statically is seldom more than a few percent, and the difference in speed is less than that. So unless disk space is a premium, standard practice is to use a kernel with suitable base characteristics (such as a "server" or "workstation" kernel, featuring slightly different options aimed at high throughput or low latency), and with most other parts as modules.
That way, your kernel boots quickly and has all the drivers you need. If you change your hardware (add a new network card, plug in a USB device, or whatever), the modules are there. If you connect something with an odd filesystem (say, a USB stick formatted for MacOS or BSD), the modules are there and load automatically as needed. The cost is a bit of disk space.
(Distro builds usually don't include /all/ the drivers and modules - there are plenty of esoteric drivers and features that are not included.)
Building Linux kernels is not dissimilar. Usually you use the menu system ("make menuconfig") rather than editing the configuration file manually, but the process is roughly the same. Of course, the Linux kernel is far bigger than the BSD kernel, supporting an order of magnitude more devices, boards, and other features, but the idea is the same. I don't know off-hand how long it takes to build a typical PC kernel - in recent times I have only built for embedded systems (where I needed modified drivers).
So yes, I understand perfectly well how simple it is to build a kernel (BSD or Linux) - and I am still perfectly happy not to bother doing so. Building a BSD kernel may be easy, but it is no easier than building a Linux kernel - and it is certainly no where near as easy as simply using a pre-build Linux kernel.
You make that sound like a unique feature. But like almost anything else in the kernel, anything that BSD has, Linux has too - and usually has had it for longer.
The advantage of the BSD's over Linux (and Linux distros) are in having a smaller and simpler system, with fewer features, but with a more centralised development team. The aim is not to support everything, but to give good support for key features - thus they can focus on security and reliability for a smaller software base. None of the BSD's attempt to compete with Linux or the Linux distros on features, hardware support, software support, speed, or ease of use.
The differences in license is, for almost everybody, irrelevant. The difference in the development model and focus is key.
Because, for almost everybody, you aren't designing products that you do NOT want encumbered with GPL. I surely don't care to invest my time updating sources -- that I will then NOT be able to distribute sans GPL!
Especially when there are unencumbered alternatives!
"For almost everybody", the only difference between a FOSS license and a Windows/OSX license is some dollars. How many folks do you know who lament NOT being able to patch the Windows/OSX/iOS/etc. sources? They just want to use apps supported ON that OS.
[If the cost of a Windows/OSX/etc. license is an impediment, then I suspect they truly misunderstand the cost and value *of* the product they are using. Or, are just plain "cheap". Yet, probably would cringe at the idea of not being compensated for *their* work!]
Almost everybody who /is/ designing products will choose Linux over BSD. This is because almost everybody who is designing an embedded *nix system does not care about keeping the code for the kernel secret, nor the code for the base system or the libraries. They didn't write it - why should they keep it secret? At most, they will have made a couple of drivers for the kernel - and by making them open they can get others to help maintain them.
Of course, people making embedded Linux systems will generally have plenty of their own code in the system - and that will often be under closed licenses with secret code. But that's perfectly fine - the GPL applies to the kernel, not programs running with it.
And once you get beyond the kernel itself to the libraries and common utilities, most of these are exactly the same programs in BSD and Linux systems. Some (such as ssh) are basically from the BSD world, others (such as the gnu utilities) come originally as Unix alternatives, and others come from the Linux world. It's all open source, it's all freely available, and it is all usable on different systems despite license differences.
In many cases, the cost of /administering/ Windows licenses (especially embedded ones) outweighs the cost of the licenses themselves!
People choose embedded Linux for their products because it is a better system for many uses than embedded Windows. You are right that the license cost is (or should be!) a minor issue. A telephone manufacturer must pay MS more for their patent protection racket when they use Android than they would pay to use Windows Phone - but they use Android because it is a better system.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.