Pandora Pandora Bios


Squidge said:
The reason SD isn't first is that it takes time to initialise the SD card, read the partition table, dos info and root file system to determine if the card is bootable or not. Considering how often the feature is likely to be used, NAND is therefore the default.

Understood. Perhaps later on in the boot process the system could check if the SD card contains a bootable OS and asks if you want to froom it?
 
Last edited by a moderator:
Is the actual process of loading a suspend-to-disk image back into memory a function of the BIOS or of Linux?
 
Typically Linux, as it checks the swap file for a valid signature, and if one is found, restores the system using that data.
 
Chip said:
Is the actual process of loading a suspend-to-disk image back into memory a function of the BIOS or of Linux?
Suspend to RAM is definitely a kernel action, as Linux is 'running' in a matter of speaking... but I'm not so sure about suspend to disk... It almost certainly has to be a BIOS function, since the boot sequence is run through the BIOS and it has to know at a very low level to load a RAM file off of the SD before/during the boot process, without the help of the kernel.

Interesting...

Edit:

QUOTE

Typically Linux, as it checks the swap file for a valid signature, and if one is found, restores the system using that data.



So some part of the kernel is loaded before it understands that it needs to dump a file into RAM? Nothing special needs to be added to the BIOS?
 
Last edited by a moderator:
Rayek said:
So some part of the kernel is loaded before it understands that it needs to dump a file into RAM? Nothing special needs to be added to the BIOS?
Nothing special, just the normal Linux kernel, with a couple of extra configs enabled. Check out http://suspend2.net/ for an explanation of how it works.
 
Last edited by a moderator:
Squidge said:
Typically Linux, as it checks the swap file for a valid signature, and if one is found, restores the system using that data.
OK. So if we wanted a bootup option to restore from one of several different "save states", that wouldn't go in the BIOS thread. :)

Thanks.
 
Last edited by a moderator:
Laurent said:
The hardware vram has no way to read C-A8 caches (there's no system level hardware coherency), so if part of the HW FB is in cache it won't be displayed unless flushed.

What the boot showed is hardware FB (at least that's my understanding) and this is what I was commenting on.
I think you're missing my point. If the L2 cache is write-through like the L1 cache then the framebuffer contents will end up in main RAM shortly after it's written to, or at least in theory no "longer" than it would if it were written out to the write buffer (since that's what should be happening). If you don't need to drain the write buffer then you shouldn't need to flush the cache.
 
Last edited by a moderator:
Is it possible to access the sound hardware from the bios? most consoles make some sort of sound when they boot

+1 on the animated boot not a progress bar but somehthing more demosceneish would be nice to have as an option
 
most the flashy stuff some people want sounds more like boot loader stuff?

Most stuff in general could and should be handled by the OS or boot loader, BIOS options should be as some has pointed out boot options like NAND, SD1, SD2, USB and in what order you want the system to search for a boot able system

I would also like options to password protect it and have a option to "remove" NAND from system detection as a safeguard, for ex. tell the BIOS not to search that address making it invisible to the system until that BIOS option is changed back.

Also will there be a timeout or booting while F1 down or likewise to get bios options?
 
Exophase said:
I think you're missing my point. If the L2 cache is write-through like the L1 cache then the framebuffer contents will end up in main RAM shortly after it's written to, or at least in theory no "longer" than it would if it were written out to the write buffer (since that's what should be happening). If you don't need to drain the write buffer then you shouldn't need to flush the cache.

As usual I was not clear enough :)

You are right, but:

1. if the L2 cache is configured as write-through what does it bring you to have FB cached? I consider that FB operations are like GPU's, you mostly do writes (and if you do reads then writes, you have to flush) so if the caches are WT there's no gain (unless having the accesses cached brings some other benefit such as better write merging, but I could not find that in C-A8 TRM)
2. if an area of memory where you mostly do writes is configured as cacheable and write allocate is enabled, you lose performance because the first write to each new cache line has to wait for line fill to complete (+ the cache flush once you're done)
3. you don't know how the L2 cache is configured, WT or WB.

Anyway that's a moot point, Squidge told the obvious thing: this only concerns the boot process, Linux will map the FB its own way :p
 
Last edited by a moderator:
Firefox said:
Pleng said:
Squidge said:
Boot order: NAND, SD
Wouldn't it make more sense to set the SD card as the default boot device. I doubt anybody is going to 'accidently' make themselves an SD boot disk, but if somebody DOES download a bootable distro/os then it would be a bit (just a tiny bit) more user friendly for the instructions to say 'just copy to sd, insert and go', than 'copy to sd, eneter your early boot menu, change boot order, insert card, reset and go'
Could be a double-edged sword, that one.

The Atari ST did things that way, and you had to "infect" all of your disks with a friendly antivirus in order to tell when they became infected by a real virus. Plus the Pandora has flash which could be infected, whereas the ST only had ROM...


I agree, the boot order should default to NAND.

But there's still a strong point for simplicity in booting from an SD card, so I would like to see a "hot key" or shortcut in the Pandora's BIOS to quickly boot from either of the SD card slots. Many PC BIOSes have added this in the past few years for a good reason.
 
Last edited by a moderator:
Squidge said:
USB is a possibility, but that would need a lot of time, code and and space. I doubt it'll happen for the first public batch. You could always boot from a small sd card which could transfer control to USB.
Wifi would be in the same league as USB. It would take time, code, and space. The BIOS can't really affect Linux (apart from passing parameters on the command line), so stuff like Wifi on/off button combination would either be designed in hardware (so it works anywhere) or designed in software (Kernel level).
An option to boot from USB or wi-fi is not that important, but may be helpful in some cases. I might have missed something, but have you mentioned the bios upgrade procedure? If some day another bios image with those features (like usb booting) is released, I would like to be able to install it in a secure way. It was announced that the :pandora1: is going to be unbricable. How this feature is implemented in your bios?
Thanx.
 
Last edited by a moderator:
_VWV_ said:
It was announced that the :pandora1: is going to be unbricable. How this feature is implemented in your bios?

OMAP3530 comes with a factory ROM that loads the BIOS. It looks like it is what makes it unbrickable.
 
Last edited by a moderator:
QUOTE
I would like to see a "hot key" or shortcut in the Pandora's BIOS to quickly boot from either of the SD card slots


At the moment you would press Menu whilst switching on, and then immediately press 'B' to select the first option 'Boot kernel/executable from SD Card'. Is that quick enough? If you need to do it several times, you could temporarily (or permanently) change the boot search order.

_VWV_ said:
I might have missed something, but have you mentioned the bios upgrade procedure? If some day another bios image with those features (like usb booting) is released, I would like to be able to install it in a secure way. It was announced that the :pandora1: is going to be unbricable. How this feature is implemented in your bios?
The same way as the System restore feature works - You would place the update onto an SD card, and power on the :pandora1: whilst holding down a certain key combination. This causes the the OMAP to run non-modifiable code contained within itself to load a binary from the SD card and execute it, which will update the BIOS, Kernel and/or File system. If the SD socket doesn't work, then you can also update via serial or USB.

To prevent corruption of NAND, both the binary loaded by the non-modifiable code in the OMAP, and the updated bios code are signed and checksumed.
 
Last edited by a moderator:
Squidge said:
At the moment you would press Menu whilst switching on, and then immediately press 'B' to select the first option 'Boot kernel/executable from SD Card'. Is that quick enough? If you need to do it several times, you could temporarily (or permanently) change the boot search order.
Definitely quick enough!

This should make instructions for booting an alternate distro from SD simple enough to be understandable by complete newbies. (BTW: I'm afraid I'm not a newbie myself at all, but I haven't found out what to do to change my profile to reflect that...)

As for the graphics on booting: I would prefer all IO/CPU bandwidth available to go into booting, not into showing off... A cool enough static image or simple loop animation would do.
 
Last edited by a moderator:
Bios Options I'd like to see, in order of importance.

Complete control over boot order - devices, order.
Boot splashscreen on/off
Control of any boot time sounds (e.g. "Mute on Boot")
Self-test (e.g. buttons, screen etc.) like the GP2X test mode
Boot passwords (how would you remove it if you set it accidentally?)
Serial console for boot options
 
Laurent said:
_VWV_ said:
It was announced that the :pandora1: is going to be unbricable. How this feature is implemented in your bios?

OMAP3530 comes with a factory ROM that loads the BIOS. It looks like it is what makes it unbrickable.

The boot sequence is
1. ROM loads X-loader
2. X-loader loads U-Boot
3. U-Boot loads Linux kernel

One might want/need to override what gets loaded during each stage, even the first one, to make it truly unbrickable.

The ROM can load the X-loader from UART, USB (using a second computer to download code from), SD or NAND. It can try a certain sequence (for instance SD first, then NAND).

In theory. In practice the device list and the sequence depends on the PCB, i.e. on how a number of pins on the OMAP3530 are configured. UART and USB might be disabled because they cause a 300 ms and 3 (or 3.3) second delay when not used. To enable them might require cutting traces, wiring pins, closing or opening jumpers, pressing certain keys before power-on to allow peripheral boot, etc.

I asked before, but details have not been forthcoming yet.
 
Last edited by a moderator:
As i understand, things like PXE are U-Boot job, is that correct?
 
Back
Top