Pandora Pandora. Operating. System. Development.


WizardStan, have you done any operating system development yourself? Or did you just scan wiki.osdev.org? (i'm not trying to insult you in any way by saying you're "Captain Obvious" or anything, it's just that you've said a lot of points that are very fundamental. Were you targetting others as well as me?). Or both? Only curiousity.
I actually wrote three operating systems back in university, one of which I didn't even have to write and didn't even target x86. :D


That was about 7 years ago though, so truth be told I was more writing for my own benefit to remind myself that I still knew mostly what I was talking about before getting excited about someone else's project ;)
Oh, good on you, man :D .


Was it a course on operating systems, or just 'general' comp. sci.?


Just remember don't get too excited, i'll be Pandoraless for a while now(batch2, and I detest upgrading). But I'm still hacking around in x86, I posted a screenie in a thread in Dev Section -> C/C++(where I should not have, but I did ;) ).


Are you going to try something on Pandora too? If you're still Pandoraless, don't go and do any more x86 - it'll drive you insane, and once you've started, it'll be hard to stop(not because it's exactly enjoyable...some of it is, gfx programming sure is, but reading reference manuals is NOT.).


Btw - i've completely halted (before I started, lol!) development on a Pandora OS until I actually have a Pandora, and after the happy Linux honeymoon. So don't expect anything too useful from my keyboard :D ;) .
 
reading reference manuals is NOT
I first read (not linearly through, so propably still only partially) the OMAP3530 TRM for fun because I was so excited about the pandora :p


So, I guess it depends on the person...
 
I'm working on a simple sort of OS / language.


Some of the following are working, others are in design or dream phase:


- runs under a host OS, not standalone (for a beginning), e.g. under Linux.


- Like Inferno, JVM, etc., but not a virtual machine.


- No need to write drivers to get started.


- might develop to an on-metal OS later


- all public domain code (with an explicit grant of freedom for anti-PD realms)


- cooperative scheduler: no pre-emption, but can have multi-processing.


- processes must call yield()


- a time-limit interrupt can stop rogue or untrusted / untested processes


- user can also trigger a 'break' interrupt to stop a rogue process


- no memory protection / hardware segmentation


- use a variant of C that helps to avoid out-of-bounds pointers


- a stricter variant of C can be used to run untrusted code safely


- by default, processes have no access to anything


- shared memory / IPC / inter-process RPC can be very quick and efficient


- 2d graphics: support O(1) hardware scrolling and scaling, if possible


- color balance in hardware, like xgamma - include dimming, inverse video


- unusual contextual GUI system, not much like the normal WIMPy ones.
 
I'm working on a simple sort of OS / language.


Some of the following are working, others are in design or dream phase:


- runs under a host OS, not standalone (for a beginning), e.g. under Linux.


- Like Inferno, JVM, etc., but not a virtual machine.


- No need to write drivers to get started.


- might develop to an on-metal OS later


- all public domain code (with an explicit grant of freedom for anti-PD realms)


- cooperative scheduler: no pre-emption, but can have multi-processing.


- processes must call yield()


- a time-limit interrupt can stop rogue or untrusted / untested processes


- user can also trigger a 'break' interrupt to stop a rogue process


- no memory protection / hardware segmentation


- use a variant of C that helps to avoid out-of-bounds pointers


- a stricter variant of C can be used to run untrusted code safely


- by default, processes have no access to anything


- shared memory / IPC / inter-process RPC can be very quick and efficient


- 2d graphics: support O(1) hardware scrolling and scaling, if possible


- color balance in hardware, like xgamma - include dimming, inverse video


- unusual contextual GUI system, not much like the normal WIMPy ones.

Sorry, should have posted a while ago.


How far have you got?


Please be aware that doing some of this stuff is not actually possible under Linux, unless you're basically emulating the CPU, at least in part.


Any screenshots? Text mode included, even appreciated.


>no memory protection / hardware segmentation


<3, I'll be doing this in the Pandora OS - even when memory protection IS added, there'll be an option to disable it.


BTW - Don't ever rely on a -server- without segmentation, you can very easily get root when you have access to the memory. I've gotten root on my own system by just chmodding (as root) /dev/kmem to world writable. You basically seek to your current shell process and set your UID/GID to 0, and spawn a new shell. Don't know if this works in _Linux_ any more though, this was a fair while ago. Recently came across a zine called the Infinity Concept, which discusses this, as well as lots of crypto. And something about halloween, wtf. Good zine. - note it's an OLD zine. There's a copy here: http://web.textfiles.com/ezines/


>use a variant of C that helps to avoid out-of-bounds pointers


:( Good luck. Compiled (to machine code), or interpreted (bytecode or otherwise)?
 
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:
 
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
 
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.
 
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 :D .


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! :D 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.
 
anyone fancy telling me why my leds don't light up? XD



Code:
int main(void)

{

	void* gpio_4_baseaddr=(void*)GPIO_4_BASEADDR;


	//configure the wifi and bluetooth led gpios as outputs

	*(unsigned int*)(gpio_4_baseaddr + GPIO_OE)|=0x0 << 30;

	*(unsigned int*)(gpio_4_baseaddr + GPIO_OE)|=0x0 << 31;

	//set the wifi and bluetooth leds outputs to 1

	*(unsigned int*)(gpio_4_baseaddr + GPIO_DATAOUT)=0x00000000;

	*(unsigned int*)(gpio_4_baseaddr + GPIO_DATAOUT)=0x00000000;


	while(1);

}



defines are right for the gpio banks (about page 3000 of the development pdf), and it doesn't work with either 0x1 or 0x0 as the output (should be 0 though as it's a pull down to turn on the leds



loading i'm doing this:



Code:
init mmc 0:1

fatload mmc 0:1 0x80300000 core.bin

go 0x80300000

took 0x80300000 as a decent starting point as that's where the uImage is normally loaded


debating whether i should get a beagleboard so i can at least hook it up to a debugger (no i'm not soldering a jtag to my pandora, far to precious :p )
 
Last edited by a moderator:
anyone fancy telling me why my leds don't light up? XD


Code:
int main(void)

{

	void* gpio_4_baseaddr=(void*)GPIO_4_BASEADDR;


	//configure the wifi and bluetooth led gpios as outputs

	*(unsigned int*)(gpio_4_baseaddr + GPIO_OE)|=0x0 << 30; // This is OR 0. Wont do a thing

	*(unsigned int*)(gpio_4_baseaddr + GPIO_OE)|=0x0 << 31; // Here too

	//set the wifi and bluetooth leds outputs to 1

	*(unsigned int*)(gpio_4_baseaddr + GPIO_DATAOUT)=0x00000000;

	*(unsigned int*)(gpio_4_baseaddr + GPIO_DATAOUT)=0x00000000; // You just wrote 0 twice to the same addr, why?


	while(1);

}
 
Last edited by a moderator:
XD oh yes, i just realised that...think when you look at arm asm all day it goes to your head...


edit: that wasn't the problem, think i may have to get a proper debugging setup, to the shelf with it!
 
Last edited by a moderator:
- where struct (pointer) 'gd' is defined?
I suggest you grep for definition of DECLARE_GLOBAL_DATA_PTR :p (and my guess is gd = global data). I'd find it for you but I'm busy and will let you do the research.

Lol, that sure made it easy :D . Thanks urjaman! BTW, I'm not the only one interested in this, so hopefully it doesn't look too much like I'm leeching information for myself! And sorry for asking some dumb questions, I think I need to fetch some awake-juice.


ANd yeah, you're right, it's global data...why the hell did I ever think of typing descriptor?? Wouldn't even make sense.


/include/asm-arm/global.data.h



Code:
typedef	struct	global_data {

	bd_t		*bd;

	unsigned long	flags;

	unsigned long	baudrate;

	unsigned long	have_console;	/* serial_init() was called */

	unsigned long	env_addr;	/* Address  of Environment struct */

	unsigned long	env_valid;	/* Checksum of Environment valid? */

	unsigned long	fb_base;	/* base address of frame buffer */

#ifdef CONFIG_VFD

	unsigned char	vfd_type;	/* display type */

#endif

#ifdef CONFIG_FSL_ESDHC

	unsigned long	sdhc_clk;

#endif

#if 0

	unsigned long	cpu_clk;	/* CPU clock in Hz!		*/

	unsigned long	bus_clk;

	phys_size_t	ram_size;	/* RAM size */

	unsigned long	reset_status;	/* reset status register at boot */

#endif

	void		**jt;		/* jump table */

} gd_t;

Yay! Lots of useful info. Now to find how/if it's passed (rather useless not passing it, and why wouldn't it get passed?)



bd_t:

/include/asm-arm/uboot.h



Code:
typedef struct bd_info {

    int			bi_baudrate;	/* serial console baudrate */

    unsigned long	bi_ip_addr;	/* IP Address */

    struct environment_s	       *bi_env;

    ulong	        bi_arch_number;	/* unique id for this board */

    ulong	        bi_boot_params;	/* where this board expects params */

    struct				/* RAM configuration */

    {

	ulong start;

	ulong size;

    }			bi_dram[CONFIG_NR_DRAM_BANKS];

} bd_t;



environment_s:

include/environment.h



Code:
typedef	struct environment_s {

	uint32_t	crc;		/* CRC32 over data bytes	*/

#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT

	unsigned char	flags;		/* active/obsolete flags	*/

#endif

	unsigned char	data[ENV_SIZE]; /* Environment data		*/

} env_t;

oookay, not sure why they didn't just use env_t in bd_t, but whatever...Compared to these insane guys (in a good way) I'm still a noob. I guess I've never done/never needed 3 layers of struct pointers.
 
Hiiii! I'm moving this thread ahead 6 pages, woo for necroposting.


I went ahead and purchased a Beagleboard... and I have code going on it!


I even wrote a tutorial on getting it all going - but it's not very good yet. http://wiki.osdev.org/ARM_Beagleboard . wiki.osdev.org needed more ARM info, certainly.


Someone please follow it, and submit corrections and stuff.


There is no reason this shouldn't directly run on the Pandora too, except that UART3 probably goes nowhere on the Pandora.


I'll upload my code once it doesn't something useful. I don't like releasing purely dev code. AGPL ftw.


I've fallen in love with ARM Assembly. I fucking LOVE it. I'm considered insane by one of the leading OMAP devs, because I'm writing my entire OS in ASM now. I genuinely don't want to branch to C code. Beware: this could happen to YOU.


pop {r0-r4, pc}
 
Back
Top