BIOS boot capability

[sed10]

I've gotten the SD card setup without much trouble, but I read some horror stories of others. For those that are not tech savvy, but want to be (aka, basically the original target demographic of the Pi), a very simple BIOS boot ability that can retrieve an image from the internet and setup the card all on the machine would be ideal. Not sure how difficult this would be (might require extra real estate or RAM that is not available), but it would probably take the Pi to a new level of marketability.

The Foundation would determine the "default" OS to be installed. Remember, this is for people who need direction, so making decisions for them is what they want. Anyone capable of imaging their card can put whatever they want, but for newbies, this would offer a less scary way to start out, and an easy way to recover from bricking the device. My thought is that if the device is powered on without a card, it looks for ethernet, pings the server, then displays a screen saying, "no OS is available, to create one, insert an SD card. All data on the card will be destroyed. To cancel, do not insert a card, unplug the device." This way, no keyboard is needed, just a screen. You may not even need a screen, if it could blink an LED in a particular pattern, letting the user know it is ready for a card, then blink in a different pattern when complete.

[W. H. Heydt]

Problem number one...the Pi has no BIOS.

[sed10]

Well, the idea would be for a future model. If too many hardware tradeoffs are required for a BIOS then it wouldn't work. There's no shortage of pre-loaded cards available and free software that walks you through the whole process, so it's not that important. Also, I can imagine the server potentially getting bogged down (since a BIOS wouldn't have a built-in torrent client).

[Cloudcentric]

Pi in the Sky as per usual................................

[RaTTuS]

Model A have not internet capability

[W. H. Heydt]

Model A have not internet capability

Not necessarily true. It has one USB port and that could be dedicated to a WiFi dongle. Alternatively, a Model A could have an attached hub with either a dongle or a USB-to-Ethernet adapter.

I will agree, though, that the required setting up to make dongles work kind of precludes an "out of the box" solution working as proposed.

[kbailey]

Model A have not internet capability

Not necessarily true. It has one USB port and that could be dedicated to a WiFi dongle. Alternatively, a Model A could have an attached hub with either a dongle or a USB-to-Ethernet adapter.

I will agree, though, that the required setting up to make dongles work kind of precludes an "out of the box" solution working as proposed.

I stuck a dongle in my RevB and messed with the wifi config tool and got it working nicely, but I'm a bit geek, and a newb might have found this very daunting, so it's not plug and play by any means. bThe hub proves to be a good idea; with a hub only one standard usb socket is needed. It interested me there was such a thing as a stacked standard usb socket assembly; is there such a thing for SD cards? This would let Pi make more Pi cards. Another approach would be to load the raspberrypi booter into memory and download the image to the SD card- step 1, fire up the pi with the special program in a sdcard in it. it boots, loads into ramdisk. step 2, yank the SD, place a blank Sd into it, press [enter] and it formats the card and downloads the image into it. Step 3, remove finished card and replace the boot card, and press enter again. now shut down and test the new card to insure it works, and put in in antistatic- or ship it with a pi, letting the pi insure it is protected.

[ghans]

What is wrong with BerryBoot ? Doesn't it load itself into RAM too ?

ghans

[roelb]

You could of course build something yourself to accomplish this. For example, if you create an extensive bootloader that will do everything from USB to PXE booting and fit that on a small SD card it would do what you are proposing. You should be able to fit something like that on a (very cheap) 32 or 64MB SD card. Just glue that SD in place and voila, done.

The only disadvantage to this setup is that you can no longer use the SD slot for storage but would have to either run an OS completely over the network or use an USB storage device. Also, you will need to support at least the internal Pi's network hardware and USB storage, but such a bootloader would preferably support a whole load of USB networking devices as well.

[redhawk]

It would prudent to keep a weekly backup of your operating system anyway not that SD Cards are liekly to byte the dust after 1 week of usage.
Why worry about BIOS, internet installing you only need a PC and software to flash a new SD Card with your latest backup copy - job done init.

Richard S.

[W. H. Heydt]

Model A have not internet capability

Not necessarily true. It has one USB port and that could be dedicated to a WiFi dongle. Alternatively, a Model A could have an attached hub with either a dongle or a USB-to-Ethernet adapter.

I will agree, though, that the required setting up to make dongles work kind of precludes an "out of the box" solution working as proposed.

I stuck a dongle in my RevB and messed with the wifi config tool and got it working nicely, but I'm a bit geek, and a newb might have found this very daunting, so it's not plug and play by any means.

What I was driving at is that there is no standard to set an installation to that will get you wifi access at a random location. Even if a Pi could (a) recognize the dongle at first boot, and (b) configure the dongle...there is no way for it to automatically know what your SSID and password/phrase are, so you can't just run headless wifi "out of the box". You have to either do some sort of pre-configuration (though a file in /boot, which is accessible to a WinTel PC) or do the initial boot with at least keyboard and monitor...and that isn't going to work when you only have one USB port unless you use a hub.

The alternative is two Pis where one is used to do the initial configuration and the others are then supplied with pre-configured SD cards.

[tnakurahc]

How to get only a BIOS or a bootloader on the SD card?

[ghans]

There a some bootloaders for the Pi including u-boot , rpi-boot
and demo programs .

This does not change two facts :

1) The Pi has no BIOS and propably never will.
2) The GPU starts the primary bootloader , which is
necessary to start the bootloader of YOUR choice.


ghans

[Joe Schmoe]

1) The Pi has no BIOS and propably never will.

This is true in a "common man/common usage" sort of way, in that the term BIOS now pretty much means "Like we find on our x86 boxes" (to the common man, in the common usage).

But, really, technically, the fact is that the Pi does have a BIOS - in the sense of the term meaning "Whatever it is on the chip that allows it to load and execute code - that is, to bootstrap itself". Namely, the code in the GPU that looks for and loads some code (I believe this is "bootcode.bin") from the first FAT partition found on the SD card.

So, it does have a BIOS.

[jamesh]

1) The Pi has no BIOS and propably never will.

This is true in a "common man/common usage" sort of way, in that the term BIOS now pretty much means "Like we find on our x86 boxes" (to the common man, in the common usage).

But, really, technically, the fact is that the Pi does have a BIOS - in the sense of the term meaning "Whatever it is on the chip that allows it to load and execute code - that is, to bootstrap itself". Namely, the code in the GPU that looks for and loads some code (I believe this is "bootcode.bin") from the first FAT partition found on the SD card.

So, it does have a BIOS.

I'd call it a RRSIOS (a really really simple input output system), rather than a BIOS, since it does nothing except start the GPU and load and run bootcode.bin. It's a bootstrapper really rather than a BIOS.

[plugwash]

This is true in a "common man/common usage" sort of way, in that the term BIOS now pretty much means "Like we find on our x86 boxes" (to the common man, in the common usage).

I could be wrong here but afaict BIOS has always been a term related to IBM PCs and compatibles. Other computers had stuff that did similar functions but afaict they didn't use the term "BIOS". As the name (basic input output system) suggests the BIOS in a PC provides basic input and output functionality. It also provided the ability to load a more complete OS from disk. By the time the BIOS passes control over to code from the MBR the core hardware is already up and running and the code can call into the BIOS for input and output.

The Pi does have some code in rom but afaict it is designed to be barely enough to load the next stage of the boot process. Afaict there is no ability to interact with the user at that stage and not even any ability to do things like get the ram working properly.

[Joe Schmoe]

The Pi does have some code in rom but afaict it is designed to be barely enough to load the next stage of the boot process.

Good. We're all in agreement.

Happy happy, joy joy!

[SteveSpencer]

I could be wrong here but afaict BIOS has always been a term related to IBM PCs and compatibles. Other computers had stuff that did similar functions but afaict they didn't use the term "BIOS".

Not strictly true. Digital Research, Inc., purveyors of that fine operating system, CP/M, also used the term. The operating system was split into a BIOS (Basic Input/output System), which was tailored for specific hardware, normally loaded into a high area of memory (such as the top 1K), and the BDOS (Basic Disk Operating System), typically loaded just below the BIOS. There was then a third section, which was the CCP (Command/Control Program) (loaded below the BDOS). which was transient and was reloaded after whatever single application ran had finished. The applications used to load at 0x100, and had to fit in between that and the lowest part of the BDOS.

My first experience of CP/M was on the RML 380Z, which had 5.25" floppy drives of 72 Kilobyte capacity (ours had two!) , and a massive 31 Kilobyte RAM which it all had to fit into.

Of course, this is wildly off-topic (sorry, James!), and probably only of interest to pedants and oldies like me. Happy days, they were...

Steve

[jamesh]

I could be wrong here but afaict BIOS has always been a term related to IBM PCs and compatibles. Other computers had stuff that did similar functions but afaict they didn't use the term "BIOS".

Not strictly true. Digital Research, Inc., purveyors of that fine operating system, CP/M, also used the term. The operating system was split into a BIOS (Basic Input/output System), which was tailored for specific hardware, normally loaded into a high area of memory (such as the top 1K), and the BDOS (Basic Disk Operating System), typically loaded just below the BIOS. There was then a third section, which was the CCP (Command/Control Program) (loaded below the BDOS). which was transient and was reloaded after whatever single application ran had finished. The applications used to load at 0x100, and had to fit in between that and the lowest part of the BDOS.

My first experience of CP/M was on the RML 380Z, which had 5.25" floppy drives of 72 Kilobyte capacity (ours had two!) , and a massive 31 Kilobyte RAM which it all had to fit into.

Of course, this is wildly off-topic (sorry, James!), and probably only of interest to pedants and oldies like me. Happy days, they were...

Steve

I'm an oldie too! 32k? You were lucky, when I was a lad, we had 16k, and used up 24 of that on Mode 2! etc etc

[W. H. Heydt]

The Pi does have some code in rom but afaict it is designed to be barely enough to load the next stage of the boot process. Afaict there is no ability to interact with the user at that stage and not even any ability to do things like get the ram working properly.

Heh... Kind of like what the IBM System/360 series had.

The hardware could...
1. Read the dialed in channel and device number from the front panel (3 hex digits),
2. Read 24 bytes of the first logical record from the selected device into memory location zero, such a a card in the card reader, or cyl 0, head 0, record 0 on a disk drive,
3. Start a channel program with a channel command word (CCW) in the first 8 bytes that had been read,
4. Load the third set of 8 bytes from what was read as a program status word (PSW) when the channel program ended.

And that's IT. That's all the hardware would do on IPL on its own. I once wrote a 2-card boot loader that could be used with a standard (DOS) object deck. It would actually load the program into the correct location specified in the object deck and then run it. The cards even left columns 73 through 80 available for sequence numbers. It was a real pain to hand punch the cards, though. 24 columns of binary on the first card and 72 columns of binary on the second.

What was that people were saying about "bare metal" programming?. Been there, done that, wore out the t-shirt.

[Overdale]

Ah - such nostalgia your post delivered. Not that I programmed the 360 at this basic level, but I did get to press the IPL button occasionally.

I was actually looking for a reference to a reputed comment made by some engineer at IBM during the development of System 360 who described it, unforgettably, as 'Two Pi in the sky".

(:-)

[mrpi64]

Model A have not internet capability

Not necessarily true. It has one USB port and that could be dedicated to a WiFi dongle. Alternatively, a Model A could have an attached hub with either a dongle or a USB-to-Ethernet adapter.

I will agree, though, that the required setting up to make dongles work kind of precludes an "out of the box" solution working as proposed.

Some ethernet adapters should work out-of-the-box, but probably not on the Pi.