Software or Firmware

That is one way of looking at it
Certainly the way the originator of the term seemed to think, if you believe Wikipedia ( :roflmao: ) https://en.wikipedia.org/wiki/Firmware#History.
I am beginning to see the point(s) you are making, and I may (eventually) get to your way of thinking. (:rolling:)

Just to confuse matters, I pose the following - not knowing the answer. The Humax firmware/software updates - if you take a FOX-T2 or 2000T downloaded .hdf file and extract the files, you find a basic Linux filestore and associated files. Can I assume that they also contain some sort of microcode (for want of a better term) for tinkering with the hardware state of the Humax, or is this all done at device driver level within Linux? You can see where I'm going with this. Unix (and therefore Linux?) is, as I understand it, written mainly in C. I suppose you might argue that a device driver - interfacing software to the particular hardware - is a type of firmware. Isn't it likely to be written in C or assembler (ie. software)? Do we define an embedded Linux (software?) as firmware?:frantic: (My head hurts!)
 
I think it's 6 and some eggs. You can draw the line wherever you want these days, it's a lot less clear cut than is used to be.
The Humax 'firmware' consists of a boot loader, a Linux kernel and a Linux root filesystem, the Humax set-top-box software and a Broadcom library that interfaces with the firmware on the embedded broadcom chip.

I'd be inclined to file the stuff on the chip and the bootloader as firmware and everything else as software.
 
I'd be inclined to file the stuff on the chip and the bootloader as firmware and everything else as software.
Sounds about right to me.
Problem is, what do you call the combined update of some firmware and some software?
 
Do we define an embedded Linux (software?) as firmware?
I do - because if it's in non-volatile store ready for use from power-up, and requires special procedures to update it, it is distinct from "software" from the user's viewpoint.
 
I think you have the wrong end of the stick. If the user is going to load and run code of their own choice - that's software. If they don't have to bother with any of that, it's firmware. There's not a difference to notice if there's no software in the equation.
 
Can I assume that they also contain some sort of microcode (for want of a better term) for tinkering with the hardware state of the Humax, or is this all done at device driver level within Linux?
I don't know, but I assume there must be. Most of the hardware interfacing is done directly in the closed Humax binaries rather than via standard device drivers, hence our lack of access (but possibly essential from a timing point of view). I suspect there are "uncommitted" elements on the Broadcom chip that need definitions loaded before they perform their desired function, and this may be done in code that runs immediately post-boot. However, I would not be willing to call this "microcode" unless it was a form of stored program working at the hardware level - just setting up a set of control bits and leaving them as they are for a period, doesn't cut it.
 
But what is a system?
A fair point. Your average user probably isn't going to understand system update, firmware update or even software update. Still, for the knowledgeable user, "system update" avoids the problems of defining software and firmware - and it might just keep BH happy. :roflmao:
 
I think af123 sort of answered that. If I understood correctly, a Humax ????ware update contains both a Linux filestore and low level stuff for a chip and the boot loader.
We're talking at slightly cross-purposes. You are thinking generally, but because I have had engineering experience of microcode and configurable logic I am contemplating what (exactly) the Broadcom chip contains and whether there are any microcoded elements or configurable logic at all (or just hardware control registers).
 
A fair point. Your average user probably isn't going to understand system update, firmware update or even software update.
But that's the nub of my argument: by being inconsistent with terms, the "average user" is given a confusing message and not the chance to understand what distinguishes software from firmware or why it matters. If user documentation stuck to the concept that software is something the user can reconfigure to their own requirements and firmware is something that is only modified by manufacturer updates (or "power users"!), there could be a clear understanding.
 
If user documentation stuck to the concept that software is something the user can reconfigure to their own requirements and firmware is something that is only modified by manufacturer updates (or "power users"!), there could be a clear understanding.
Get the point. Not only the average user is confused. My confusion is that I spent a long time as a VAX system manager (a sideline to my proper job of designing/programming/running big numerical simulations). The differences you can see between software and firmware are a bit of a blur when you can reconfigure the system to your own requirements.
 
As a system manager, you would count as a "power user". I'm not convinced that what even a system manager can tweak on a VAX system counts as firmware though.
 
Back
Top