Pandora Pandora Bios

[Squidge]

What do you expect to see in it? (Keep in mind that this needs to be <= 128KB in length, so don't ask for things like MP3 players or video players)

Currently at power on, it shows the Pandora logo and boots a Linux kernel from NAND. However, if you press the 'Menu' button whilst its loading the kernel, you can get a boot menu which allows you boot from sd card (either a kernel or other executable program) and/or change the boot order.

Note that isn't meant to be incredibly simple, as it's only meant for developers who wish to play. People that don't understand are expected to just leave it alone and not alter any settings

Here is the screen you get on pressing 'Menu':


Boot kernel/executable from SD Card
System Restore
----- Boot Options ----------------------------------
Boot order: NAND, SD
Boot type: Kernel
NAND Parameters (ofs, len): 0x280000, 0x400000
SD Parameters: uImage
Kernel load address: 0x80000000
Kernel execution address: 0x80000000
Kernel command line: root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0ff rw console=ttyS0,115200n8


Automatically booting an executable from sd card instead of a kernel:


Boot order: SD, NAND
Boot type: Executable
NAND Parameters (ofs, len): 0, 0 (Disabled)
SD Parameters: Bootme.pxe
Executable load address: 0x80000000
Executable execution address: 0x80000000
MMU Enabled: Yes
Framebuffer cached: Yes (@ 0x87F00000)
CPU Frequency: 600Mhz


Of course, you can just leave the normal settings alone and boot a single image from an sd card using the built in file browser

The System restore option will reflash the nand back to 'factory default' by using an image from an sd card.

Anyone want anything else included?

 

[sehs33]

Just an idea:
Regarding SD boot, is it possible to make it boot from either SD card (not only SD card 1)? You never if one of the two slots broke down so it will be useful being able to use the 2nd slot too.

 

[theoddbot]

Only thing that comes to mind would be a simple way to choose the rootfs partition between nand and sd, not that it's very hard to edit the command line manually, but it could make things easier for some.

Something else would be to detect if another key (F1?) is held during boot and have 'nosplash' or something added to the kernel boot parameters to enable text for the Linux boot.

 

[ldesnogu]

Framebuffer cached: Yes (@ 0x87F00000)

(off-topic)
That looks odd for two reasons: it's one 1MB aligned while FB can be >1MB and cached FB is probably dangerous (you need cache flushing) and useless (cache is write-through; all you want is write merging enabled).

 

[Pleng]

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'

Will SB booting be possible? Not that I can see much use for it, other than booting from a hard disk (!), but then I suppose you could always make a little boot disk for that.

 

[sehs33]

... Will SB booting ...

You must mean to say USB, right? :huh:

 

[Pickle]

I would like ot see the following:
Boot from both SD slots
Boot from USB (memory card, maybe even HD or CD/DVD)
Boot from WIFI
WIFI Setup: DHCP or Static IP (what about encryption? or are you going to leave that at the linux level?)
WIFI ON/OFF button combination
A max overclock keep from overclocking past the soc limits, might be nice. gmenu2x does it if you dont know what i mean
If the options get to many, create mutiple pages just you would have with a PC bios
A security password option? have to type in password at bios boot
Allow for editing/modifying the options from within the these bios screens.
Maybe some power settings. For example like ive heard of a sleep mode when its shut, give an option to turn it off or on.

 

[Tinnus]

Those WiFi options are too high-level to be controlled by the BIOS. I like the password idea though

 

[Arialia]

USB boot ? why not :rolleyes:

for me boot default order must be NAND, SD1, USB but of course could must be modify by user

Nand is faster to read than SD, i think than 256 mb is enough for kernel and important lib , right ?



settings of button OS ( you know the button Pandora)

settings of TV out ( PAL, NTSC ..... 4:3, 16:9 ) or in software settings

 

[Pickle]

Those WiFi options are too high-level to be controlled by the BIOS. I like the password idea though

I think your right, i wondered same. Maybe the IP shouldnt be shown at the bios level even if it static?

 

[Exophase]

Framebuffer cached: Yes (@ 0x87F00000)

(off-topic)
That looks odd for two reasons: it's one 1MB aligned while FB can be >1MB and cached FB is probably dangerous (you need cache flushing) and useless (cache is write-through; all you want is write merging enabled).

I'm probably missing something as usual so I'll give you due opportunity to correct me, but..

Is cached framebuffer necessarily useless if the framebuffer can fit in L2 cache (I'm assuming hardware scaled framebuffers here), and if cache is write-through then why do you need cache flushing for it to work any better than write buffering it would?

 

[ldesnogu]

I'm probably missing something as usual so I'll give you due opportunity to correct me, but..
Nah, you're right doing that especially on a Sunday morning when my fingers type faster than my brain can think
QUOTE
Is cached framebuffer necessarily useless if the framebuffer can fit in L2 cache (I'm assuming hardware scaled framebuffers here)
Do you think the HW FB of the PowerVR does this? I would be surprised and I would find this very inconvenient, I want my linear framebuffer at full resolution
And 800x480x16 bit is much bigger than the 256 KB L2 cache.
QUOTE
and if cache is write-through then why do you need cache flushing for it to work any better than write buffering it would?
L1 is write-through, for L2 it depends on its configuration (ref).
If L2 is configured for write-allocate and you do random writes to your FB, you may have to do line fills for each of your writes. And when you're done, of course you will have to flush.

Now I am not sure how the write buffers behave for non-cacheable accesses on Cortex-A8 (I have been spoiled by some other ARM core). This probably needs some benchmarking on real HW

 

[Firefox]

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...

 

[Exophase]

Do you think the HW FB of the PowerVR does this? I would be surprised and I would find this very inconvenient, I want my linear framebuffer at full resolution

I wouldn't rule out that it can, at least GP2X's framebuffer can. Obviously as an option, there shouldn't be a problem getting a full resolution (or greater resolution?) framebuffer as well.

And 800x480x16 bit is much bigger than the 256 KB L2 cache.

If it doesn't do framebuffer scaling then what the programs view as a framebuffer could be a lower resolution texture that is written to then scaled + blit to the real framebuffer. Of course, this isn't a framebuffer that the boot sequence would refer to, but it could be reasonable to have this in cache if it's small enough.

If L2 is configured for write-allocate and you do random writes to your FB, you may have to do line fills for each of your writes.

Still operating under the assumption that the entity referred to as a framebuffer can fit in cache, in which case those lines should be there (unless driven out by something else).

And when you're done, of course you will have to flush.

If it isn't write allocate then they'll never show up in L2 to begin with (unless you read it beforehand, obviously), but if it's write-through then it shouldn't need to be flushed either.

Now I am not sure how the write buffers behave for non-cacheable accesses on Cortex-A8 (I have been spoiled by some other ARM core). This probably needs some benchmarking on real HW

Although I'm looking forward to anything superior to ARM920T, I wouldn't expect a step backwards in this area. Coalescing on more than STMs could be very welcome for things that can't coalesce in software.

 

[ldesnogu]

And 800x480x16 bit is much bigger than the 256 KB L2 cache.
If it doesn't do framebuffer scaling then what the programs view as a framebuffer could be a lower resolution texture that is written to then scaled + blit to the real framebuffer. Of course, this isn't a framebuffer that the boot sequence would refer to, but it could be reasonable to have this in cache if it's small enough.

If L2 is configured for write-allocate and you do random writes to your FB, you may have to do line fills for each of your writes.
Still operating under the assumption that the entity referred to as a framebuffer can fit in cache, in which case those lines should be there (unless driven out by something else).
You are obviously talking about some software handled frame buffer. 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.

QUOTE

And when you're done, of course you will have to flush.
If it isn't write allocate then they'll never show up in L2 to begin with (unless you read it beforehand, obviously), but if it's write-through then it shouldn't need to be flushed either.
Do you know how L2 cache is configured on Pandora?

QUOTE

Now I am not sure how the write buffers behave for non-cacheable accesses on Cortex-A8 (I have been spoiled by some other ARM core). This probably needs some benchmarking on real HW
Although I'm looking forward to anything superior to ARM920T, I wouldn't expect a step backwards in this area. Coalescing on more than STMs could be very welcome for things that can't coalesce in software.

In an ideal world yes. Cortex-A8 TRM is very confusing

 

[Ayla]

What I want to see when I switch on my pandora is a nice animation, like the dreamcast or gamecube ones. I really miss it on the Wii for example...

 

[fusion_power]

What do you expect to see in it? (Keep in mind that this needs to be <= 128KB in length, so don't ask for things like MP3 players or video players)

Hm, interesting question. What SHOULD I see normaly onto a Pandora boot? Becasue I'm a normal User and command-line-allergic (especially these cryptic Linux-Boot-Messages), a simple Picture or a nice, small (3D) Animation would be good enough. 3D instantly shows the Potential of the Pandora and Animation shortens the Time while waiting.
I hope this boot Menu will be user friendly and not a cold Linux command Line where we have to wite the commands per hand etc. (I know many Linux-Fans do love command lines and Bash consoles and shun every GUI-like thing ) Of course it is good to have a Handheld Console with a Command line Console just in case ^_^

 

[sindbad]

Hm, interesting question. What SHOULD I see normaly onto a Pandora boot? Becasue I'm a normal User and command-line-allergic, a simple Picture or a nice, small (3D) Animation would be good enough. 3D instantly shows the Potential of the Pandora and Animation shortens the Time while waiting.
Nothing's wrong with command line!

On that same note, is there any graphical version of Uboot, similar to grubfx?

 

[Squidge]

Regarding SD boot, is it possible to make it boot from either SD card (not only SD card 1)? You never if one of the two slots broke down so it will be useful being able to use the 2nd slot too.

Sure

Only thing that comes to mind would be a simple way to choose the rootfs partition between nand and sd, not that it's very hard to edit the command line manually, but it could make things easier for some.

Yes, but I'm thinking people who put there own rootfs on a sd card will probably not want to do it like the bios allows - they may want more flexibility.

Something else would be to detect if another key (F1?) is held during boot and have 'nosplash' or something added to the kernel boot parameters to enable text for the Linux boot.

Yes, I agree there.

Framebuffer cached: Yes (@ 0x87F00000)

(off-topic)
That looks odd for two reasons: it's one 1MB aligned while FB can be >1MB and cached FB is probably dangerous (you need cache flushing) and useless (cache is write-through; all you want is write merging enabled).

The way it works at the moment is that 800x480x2 = 750KB. Also do note that it only applies to running executables - Linux apps will obviously completely ignore that setting. If your writing apps which run on the hardware directly (without an OS), you probably don't mind flushing or altering the caching parameters.

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

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.

Will USB booting be possible? Not that I can see much use for it, other than booting from a hard disk (!), but then I suppose you could always make a little boot disk for that.

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.

Boot from WIFI
WIFI Setup: DHCP or Static IP (what about encryption? or are you going to leave that at the linux level?)
WIFI ON/OFF button combination
A max overclock keep from overclocking past the soc limits, might be nice. gmenu2x does it if you dont

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).

A security password option? have to type in password at bios boot
Maybe some power settings. For example like ive heard of a sleep mode when its shut, give an option to turn it off or on.

Password is possible, power settings are same reason as above - they would be configured from within Linux, as the BIOS is no longer running once Linux is.

settings of button OS ( you know the button Pandora)
settings of TV out ( PAL, NTSC ..... 4:3, 16:9 ) or in software settings

Again, those kind of settings should really be handled by the OS Kernel.


QUOTE
What I want to see when I switch on my pandora is a nice animation, like the dreamcast or gamecube ones.

Possible, should there be enough space left over. What we don't want to do is slow down the boot process due to the fact it's loading too much data before handing control to the Linux kernel.
QUOTE
On that same note, is there any graphical version of Uboot, similar to grubfx?

Yes, this is it

 

[Rayek]

What I want to see when I switch on my pandora is a nice animation, like the dreamcast or gamecube ones. I really miss it on the Wii for example...

I want the opposite... I want to see text when I boot up a system... An option to disable the splash screen and/or whatever snazzy animation comes up during boot, and just show the boot process.

Edit: Also, I second the option for a password. It would be neat