Completely "out there" question

[CentralWare]

I've always been curious about this so hopefully someone out there can shed a little light on the topic.

"Back in the day" when we played with Z80 and other processors, "HOW" to program the processor was always the same...  write code, burn to E/EEPROM, plug it into a socket and connect power.  Straight-forward, but a lot of mechanical hands-on should you have to make alterations.

Time fast forwards to current days and I'm struggling with the "Chicken or the Egg" when it comes to people developing for boards using processors that have never been developed on outside of the factory?

ie: RasPi...  when these first hit the streets, if you bought a raw board with no operating system, how did you possibly design anything for it?  (Emulator perhaps?  If so, was it factory supplied?)  Getting an image ONTO the board is always simple...  back in the day you burn a rom chip based on instruction sets provided by the factory.  Today you "dd" an image onto an SD.  The question, however, is how do you possibly "test" new processors with no more than an empty SD and without an emulator?  There are no compilers (I'd imagine) for a given platform yet and unless the factory supplied a tool-chain, I can't fathom how you get the board to even hello.c state using instruction sets designed for IT when you're using a foundation foreign to it?  Maybe I'm just too old school to see the missing pieces, perhaps?

[core-user]

I would think, as long as it has a bootstrap in BIOS, it will find the next bit of code to get going.
From my understanding, a bootstrap finds the loader, which finds the kernel, which finds the system.

[CentralWare]

@core: That's just it.  Back in the day WE had to program the boot-strap (usually a small program which when booting, allows for serial or in-circuit programming of the "flash" area - but even the boot-strap has to be able to be upgraded.)  It normally is programmed at "X" starting location which the processor expects to find the first instruction.  The BS then has, in memory, a starting point to pass along to the firmware location and we're off to the races.

With Android, Pi and other systems of the likes, I would "imagine" the BS is just a bios-like set of instructions to pass control over to what ever the boot media is (ie: SD, uSD, onboard flash, etc.) so I can only guess that somehow, someone leaves a bread-crumb for potential developers which tells them "Starting at location "X" on the boot media is where we need to start the boot-loader/manager.

For linux, this means we install grub, syslinux, etc. at that exact location...  but how we get those loaders to "talk the language" of the processor is my main curiosity.  (ie: A "jump" command in assembly to skip to the next location in memory is going to be somewhat universal in concept, but could be a completely different numerical value for every processor.)  Thus, I'm curious when these boards first ship...  what was available on the developer's market to help people compile even the boot-loader into the new "language" of the new processor unless there were tool-chains, etc. provided when the boards first launched.

Thanks for the feedback & take care!

[gerald_clark]

The board manufacturer either cross compiles it or buys the bootloader from a software house that compiles it for them.

[CentralWare]

@gerald: Thanks.  Generally when new boards come out I just disregard them for a while as the "bugs" are ironed out and figure during which time I'll let the community figure out how to get past the boot-strap and everything lined up, but with all of the new boards hitting the market these past few years I don't think I can afford to "sit around" as has been the case for some time now.

Example: IBM is good at just throwing docs your way, whereas it sounds as though RasPi had an entire kernel/image released (optional purchase) with theirs, Google had an SDK to go with Android (though I can't say whether or not it was available at launch) and so forth, so I can imagine there's quite a bit of effort involved with "staying up with the times" as I'd imagine there's not much in regards to standardization.

Take Pi for example...  and please correct me if I'm wrong, I haven't spent any time in the forums yet.  I'm guessing there's a specific address (offset) location (on the SD/uSD) where we have to start burning the TC image such as dd if=image of=device offset=x so the boot-strap always knows exactly where to find the first instruction (in this case, I'm going to assume the boot loader) and from there, things operate as normal.  I'm going to also guess it'll be FAT based since most chips today from condensed audio/video recorders, media devices, etc. see FAT as being a simplistic means to an end, so I don't imagine this will be any different here.  From there (boot loader, config and/or boot image) I'm guessing this is where we start with a secondary file system (ext2) for the heart of the matter (our TCE/TCZ, persistence, etc.)  To accomplish this remotely, another offset would likely be required or possibly just fdisk-ing the remainder.  Am I on track?

Thanks again and take care!

[gerald_clark]

There is no standard boot loader for ARM boards like there for PCs.
For most ARM boards you copy the prepared OS image to an SD card, and boot that.
You really need to read the forum articles for instructions for  the specific boards that interest you,

[CentralWare]

@gerald: Thank you.  Yes, I do have a good deal of reading to tend to in the near future, but the inquiry is based on "every day life" whereas some of the hardware I'll be working on is the furthest from it.

For example, I have stand-alone LCD NAS boxes here which need to be revamped (ARM6 if I'm not mistaken) which aren't your run of the mill devices.  I have the sources, etc. so I'll likely be using an ARM emulator to build a binary image I can just flash to the devices, but the thought crossed my mind...  "What if I didn't have emulation...  or worse yet, source code?"  The people who built these things for Galaxy (NAS-1500) were terrific and quite helpful (supplying resources) but I don't imagine I'll get the same warm welcome with everyone.  I was enthused to see how TC would perform in such a cramped environment (64mb ram, 32mb flash) but that'll be sometime in the near future once the current agenda dissipates some.  It's almost exciting to think of resurrecting these things with a remastered TC (including busybox-httpd instead of tiny, a torn apart samba with a great deal more options, dlna and dnsmasq to give the boxes more "usefulness" and a few firmware tweaks so I could plug a wireless and/or GBe network (USB) device in - though I doubt the machine itself could handle the hammering!   Being NAS devices I could always off-load extensions onto the HDD and with the right kernel tweaks focus the kernel based on the device's specific needs and likely do the same with the ramfs, but due to the extremely small memory block it'll likely end up a hybrid between a clean TCL in flash and a scatter on the drive which in many areas is what they're doing with it themselves, minus the TC portion.

Thanks again and take care!