Whoops. Been hiding myself in a darkened room away from the pandora forums with Minecraft andassignments.
I for one, would be extremely excited to see even a simple "HELLO WORLD" running on the bare metal with no overhead OS. I don't know how the ARM processor works, but the x86 platform immediately starts executing code at the address F000:FFF0. I'm sure something like that must exist on the ARM as well. So how many instructions would it take to display 11 characters, while advancing a memory pointer and a frame buffer pointer after each?
Don't mind me, I dream out loud sometimes! :lol:
It WILL be done. Don't ask when, but hell, man, it WILL be done.
Too bad on x86 it ain't ACTUALLY as easy as starting at F000:FFF0, since the BIOS does its magic voodoo dance lameness. But you are correct, of course, i'm not refuting your statement
.
And, yeah, pretty sure we don't get a VGA textbuffer like we do on x86 (A000/B800 - man, BEST idea EVER in x86 was how the text works. That's rather sad...)
In theory about 10-20, depending on what setup the screen needs
...I've got a demo I've been meaning to run, but need to know how to tell uboot to run it from an SD card XD
(no crying emote) don't you hate it when you're held up by just ONE thing, something that in theory is quite trivial?
. s the issue telling uboot that your SD card has shit on it, or telling uboot it should look for it? EvilDragon mentioned some button combo for when doing hotfixes - here we are:
Hold R-Shoulder button while booting.
I for one, would be extremely excited to see even a simple "HELLO WORLD" running on the bare metal with no overhead OS.<snip>
Throwing hello world out of the hardware serial port is propably the shortest thing you can do*, but it's not really visible if you dont have the needed hardware. Initializing the LCD is - well truth to be said a bit complicated (if you want to know, the code is in our u-boot tree...). After that you would need to get a hold of some font to draw text in (eg. include in your app) and then some code to blit the given text into the framebuffer ...
* Oh, blinking one of the omap-attached LEDs might be easier.
I had a look at what's in u-boot. Damn right it's complicated
.
here's a chunk(I'd attach the whole file to the end, but I last gitted the source like ages ago, so it's probably outdated...):
Code:
static void draw_logo(void)
{
DECLARE_GLOBAL_DATA_PTR;
unsigned short *dest = (void *)gd->fb_base;
unsigned short *logo = (unsigned short *)logo_data;
int i;
dest += 800 * 480/2 + 800/2;
dest -= 800 * logo_height/2;
dest -= logo_width/2;
for (i = 0; i < logo_height; i++, dest += 800, logo += logo_width)
memcpy(dest, logo, logo_width * 2);
}
Framebuffer!
And nice job, whoever wrote that chunk, for making it nice and readable (no sarcasm - I'd have written a chunk of obfuscation-contest material. Starting with magicnumbers instead of the dest+= bit).
Anyone know:
- where struct (pointer) 'gd' is defined? //curiosity: does it mean 'global descriptor' (not like the x86 GDT of course)? by grepping I've seen mentions of it holding the board type, etc.
- how/if struct (pointer) 'gd' is passed to the OS/etc?
- where my aspirins are hiding (lol, jk, I'm not even started yet)
This sounds like a job for the world's favorite superhero, GREPMan! (hint - not in the boards/pandora directory)
Results:
(root)lib_arm/board.c
gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
Yeah, this is about as far as I'll go tonight. Long day.
I hope it's as simple as grub's magicnumber passing. If not, with a bit of haxing, we can pull it out of the rubble
.
Has anyone got a copy of/room for the Pandora Linux kernel source? Honestly, I do NOT have the disk space. Gotta dig out my external hdd cable...
Can we even do hardware blitting? I'll admit I still have not had the time to search deep myself, but in case you already know - do tell please
. If you're unsure, do not do any research - aw, well, you CAN of course, but...gah, you know what I mean.
