Pandora Pandora. Operating. System. Development.


doublebeta

Member
Joined
Jun 22, 2010
Messages
194
Warning, if English is NOT your first language, it's probably good to NOT read this. You'll get a headache.


I've no idea how to ask, so please go easy...


RIGHT. SO I just had a huge post here. Huge huge huge. Full of stuff i'd be ashamed of in the morning, like all the 'pleading'... I also mentioned that I had NOT had a look at the Pandora's Linux kernel, because I saw license issues. But, i've decided i'm doing that anyway. Aside from that...


A much revised, but less 'warm' and more rash version is, in lolcat for comic relief:


"Can haz operating system on Pandora tutorial?"


I'm NOT asking for "This is called a computer. This is called a monitor."


or "This is a variable. This is a function"


or even "This is how pointers work"


No. I know how to code. I know how to code pretty damn well. I'm not the best. But i'm not trying to pull a Micro$oft wannabe who decided one day he'd make an OS. I've written games(in SDL). Hell, I have (little, but still enough to get something booted and doing...stuff!) experience writing operating systems on x86.


The text below is borderline bragging and is quite unnessesary and just makes me sound like an asshole. Don't quote it.

I've even written graphics stuff(!) as well as sound(SID POWER!) on the Commodore 64 without an assembler. I converted the opcodes in the manual, in my head most of the time, from hex to decimal and POKE'd in the program from DATA statements. If that doesn't tell you that I'm in this for real, and that I'm NOT (just) some dumb, arrogant noob(not all noobs are dumb and arrogant), then I seriously don't know what will. Maybe programming a PROM or RAM via a switchboard? Well, I know the theory. I have the schematics for building a computer with the Z80 microprocessor, drawn by myself, but i'm stuck waiting for parts.


Now I want to try the Pandora. I've already ordered a Pandora, i'll be using it mostly with GNU/Linux. But I quite like osdev. Yet I hate x86.


What I wish to know is how to draw on the screen. I'm not a http://wiki.osdev.org/James_T._Klik. Text will do to begin with. (actually, i'm a http://wiki.osdev.org/Lino_Commando. Graphics and GUIs will have to follow because face it, it HURTS to write code for years and have noone care because it's 'not pretty'. http://wiki.osdev.org/Eleanore_Semaphore)


I want to know how to handle interrupts.


I want to know how to use disk.


Et Cetera.


Why do I want to write an OS?


Two reasons.


1. For the sheer sake of it. To say I did. To climb everest, and stick my flag (in the hole where someone else's flag once stood before I just took it out and threw it off the side) on the top.


2. To escape from the rules and laws of any kernel running above you(like most rules/laws, most ARE their for your own protection...others I truly believe are there to piss you off). It feels like you're dreaming and anything is possible(UNTIL you hit a point where it doesn't work, you run out of CPU time, or your hacking without rules has resulted in a mega-bug).


Without an OS you can also write interrupt driven programs/games. Threads don't cut it. Like how in Pokemon (GB, GBA, DS), the tiles are animated? That's because (though I haven't read a disassembly, just speculation) an interrupt connected to a timer (or maybe vblank) fires that will change the pointer to the tile (and then that pointer is used by a hardware tiler. We don't have one of those so we'd have to do the tiling in software.) Without an OS you have zero overhead over YOUR code, so you can truly optimise to the full extent of the hardware. Afterall, compare a (non-pandora) gaming console's specs to a PC game's requirements(erm though you can actually blame Microsoft for part of that)...


SO when it finishes downloading(ETA 1 week, lol...0.86kBps down time. Should speed up later.), I will read the Linux kernel source. I'll gather all I can.


The BEST way to learn anything at all is from a living, breathing guru, NOT some manual, or some lump of code. The next best is example code, designed to teach. Doing things yourself, hands-onis part of both methods.


What I wish for, is that if he/she is some spare time, that some wise and knowledgeable write a barebones "Boot and draw an 'A' in the top left corner of the screen" tutorial. You don't owe anyone anything. But it would be nice for those out there like me. Preferably C oriented. Because, err, personally...I don't really know ARM assembly (I can hear you all inhale sharply and begin to weep in desperation...) but all is not lost, I (personallly) can read it, and understand it, with manual in hand, but not really write it just yet. And again, you really do need someone who knows to get the ball rolling for you.


v More stuff that could be taken the wrong way. v

The other issue with using the Linux kernel as reference material is that it kinda destroys one major point of the 'open' Pandora, that you shouldn't have to hack around and reverse-engineer to get your homebrew running. And I suppose, you don't, if you are cool with userspace applications - but sometimes on gaming hardware running without an operating system is desirable. The Pandora already provided what others don't. But can we go further. Unlimited power, truly in control, running on the bare metal, true zero restrictions.



v AN ALTERNATIVE! v

"How to use the Linux kernel as part of your own OS, ditching everything and stuff". It worked for Android but how the hell did they do it? Where the hell did they get their information? Where is the magic book with all the answers (no not the bible, Linux is not in the bible).


I'm NOT demanding answers I'm asking. I just wish I knew how to ask more nicely - i'm not trying to sound rude. I jsut really do not know how to word things. I'll need you, please to just pretend i'm using the most silky smooth, velvet honey voice, no matter how the text is interpreted naturally.


Thankyou for taking the time to read this. I hope that you don't hate me for this post. I did STFW. I downloaded the CPU manuals. It's hard to imagine, the several scrapped posts that were never posted were, no exaggerations, close to 10 times larger...I really apologise for going off topic.


EDIT: Well the Pandora kernel finished downloading, and well, I seem to have forgotten that I actually have no idea what so ever to do. Any book recommendations?


Actually any book recommendations at all?


Anything that could be useful for doing osdev on the Pandora.


Not general osdev, that's pretty useless at the moment, you don't write multitasking until you can draw a smiley and prove it's doing something ;) . Otherwise debugging gets VERY hard.


Or, any good fantasy? I could do with a distraction. No Forgotten Realms, i'm reading all of those anyway :D .


"(puff) Wuut?" --stoner


I think it's about time to go to bed. I started writing this message at 12am(0:00 24h time), it's now 3:30am...


edit2: Anyone know where you can buy a printed copy of the omap35x ref manual? It's huge, so I can't really go down and get it printed anywhere I know, let alone with an inkjet printer - maybe i'll run it off at school without telling anyone :D (HEY WTF WHY IS THERE NO TONER ANYWHERE?). I hate reading datasheets, manuals, etc on a computer screen. Plus it's much MUCH more bearable to sit down comfortably on the couch before you strain your eyes and pain your brain.


edit3: Argh, well it seems emulation is pretty pointless for the Pandora (can emulate arm, not it's hardware - naturally) - so I won't be doing any dev until I get my Pandora(batch2) BUT is there a way to rapidly develop and test code on the Pandora without voiding the warranty? I guess, you just boot an SD card - but maybe we can boot ?over serial? or maybe (shit I doubt it) over LAN?


edit4: ROFL. Disregard that LAN bit, we have no LAN! Only WLAN. ANd there's noway i'd wanna send a kernel over WLAN for debugging :p
 
Last edited by a moderator:
Stop apologizing, I like this idea :) . Unfortunately I'm not the guru you are looking for, but I wanted to express my interest (as a spectator) and support for projects of this kind. I hope you find the answers you are looking for and post your findings here so that others like yourself can benefit. Good luck!
 
Ok, so if I understand your drunken ramblings, you want information on how to write an operating system from scratch for the Pandora? And for some reason you think this will offend people? I'm more offended by your insinuation that it would be offensive then anything you have actually said you think might be offensive :p


A few things to consider

  • Writing an operating system is hard. Be prepared for lots of frustration.
  • Know that you are doing this for yourself, for fun, and don't get upset if no one ever uses your OS, or if it turns out so terrible even you don't want to acknowledge its existence.
  • Know also that if you're writing your own OS you'll need to write all your own applications that run on it, unless you either use the Linux kernel or somehow make your OS compatible with Linux. For the purpose of fun and knowledge I would suggest throwing away compatibility and just make your kernel how you want.



With that in mind, things to know about an OS:

  • A kernel is just a program. It's a very special program with a lot of specific things functioning in certain ways, but a program all the same.
  • Modern kernels are usually written in C. No need to worry about assembly or anything like that if you don't want to.
  • Every bit of hardware is accessed through interrupts or memory locations. These are all listed in the OMAP3430 spec sheet. Like it or not, you've got a LOT of reading ahead of you.
  • A kernel doesn't do everything. It exposes stuff in a standard way that drivers can access. You've got a lot of thinking and planning ahead of you as well.



Your first task: read the data sheet, figure out which memory location corresponds to the frame buffer 0 and its settings. Figure out the code for setting the values appropriately to match the Pandora's resolution and colour depth. When you've got that, I can help you go about writing a very basic kernel that will do something on the screen.
 
I think you can get a lot of basics (like the LCD settings) from the u-boot sources at git.openpandora.org,


and getting yourself familiar with u-boot is a good idea anyways, because I think you really should load your kernel with u-boot (just like linux), because you can do that safely from an SD card with boot.txt - and you wont need to think about a lot of initialization stuff.


Good Luck! :p
 
Stop apologizing, I like this idea :) . Unfortunately I'm not the guru you are looking for, but I wanted to express my interest (as a spectator) and support for projects of this kind. I hope you find the answers you are looking for and post your findings here so that others like yourself can benefit. Good luck!


Perfect, interest is what we need if we wanna convince any gurus out there, thankyou!

Ok, so if I understand your drunken ramblings, you want information on how to write an operating system from scratch for the Pandora? And for some reason you think this will offend people? I'm more offended by your insinuation that it would be offensive then anything you have actually said you think might be offensive :p


A few things to consider

  • Writing an operating system is hard. Be prepared for lots of frustration.
  • Know that you are doing this for yourself, for fun, and don't get upset if no one ever uses your OS, or if it turns out so terrible even you don't want to acknowledge its existence.
  • Know also that if you're writing your own OS you'll need to write all your own applications that run on it, unless you either use the Linux kernel or somehow make your OS compatible with Linux. For the purpose of fun and knowledge I would suggest throwing away compatibility and just make your kernel how you want.



With that in mind, things to know about an OS:

  • A kernel is just a program. It's a very special program with a lot of specific things functioning in certain ways, but a program all the same.
  • Modern kernels are usually written in C. No need to worry about assembly or anything like that if you don't want to.
  • Every bit of hardware is accessed through interrupts or memory locations. These are all listed in the OMAP3430 spec sheet. Like it or not, you've got a LOT of reading ahead of you.
  • A kernel doesn't do everything. It exposes stuff in a standard way that drivers can access. You've got a lot of thinking and planning ahead of you as well.



Your first task: read the data sheet, figure out which memory location corresponds to the frame buffer 0 and its settings. Figure out the code for setting the values appropriately to match the Pandora's resolution and colour depth. When you've got that, I can help you go about writing a very basic kernel that will do something on the screen.

I wasn't actually drunk, but yeah. Probably because I was very tired. My fault. I'm sorry about the rambling, not the idea of writing an OS :D .


I know OSes are hard to write, i've been there. Most of the frustration is finding information. Even worse, is when it's IMPOSSIBLE to get information (like vesa.org having nothing anymore, nVidia/ATI, etc cards don't even fucking release info! I mean wtf, we pay for the card, we should get to know how to use it.). That's part of the reason I want to try the pandora. You don't have to write drivers for every device on the planet, only for the hardware in the Pandora. And there is (hopefully) NO HIDDEN, PROPRIETARY INFORMATION.


I probably won't have to write my own applications (but I will) if I can provide the standard C libraries. Of course, i'll be dropping all support for current graphical libs personally, in my OS because, well, I feel they suck. Maybe i'll port SDL (make wrappers around my draw routines). Binary compat with Linux i'll avoid, because then i'd just be writing Linux again, but in slower code :) (But FreeBSD isn't quite like that, it's just how my code would turn out).


I know noone will ever want to use my OS. I know I probably won't even want to. I just do want to be able to show it to someone, "hey look ma, no Linux!".


While OSes are mostly written in C, at least on x86 you need to write your bootloader, or the glue between GRUB and your main() in ASM, and your ISRs as well (which can call C functions). However, I was asking, if there was a tutorial written by a guru, that the entire thing not be written in ASM.


I know there's a lot of reading to be done (lol, I at first grabbed the wrong pdf, I grabbed the datasheet, not the ref manual - but i've got the ref manual now, trying to find a place to get it printed. Reading pdfs sucks.) Speaking of that, I again apologise for my posts becoming as large as the reference manual :unsure: :rolleyes: .


I know that the information has to be in there somewhere. Obviously I .should. have read all..er...3444 pages before posting here :( . But There's not much point knowing where the framebuffer is when you don't have any means to write to it (need to know how to boot, see below for comment on u-boot). Which is kinda contradictory.


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 think you can get a lot of basics (like the LCD settings) from the u-boot sources at git.openpandora.org,


and getting yourself familiar with u-boot is a good idea anyways, because I think you really should load your kernel with u-boot (just like linux), because you can do that safely from an SD card with boot.txt - and you wont need to think about a lot of initialization stuff.


Good Luck! :p

Right, i'll check out u-boot. A GRUB-like solution like that seems perfect. Thankyou!


Thankyou, all of you for reading my "drunken" ramblings (heh), and taking the time to reply! Thankyou!


I'll just gather information like crazy, maybe run a wiki? or use pandorawiki.org? and dump all useful info there? Comments, suggestions, free stuff, all welcome :p
 
Well assuming you know how to write an OS from scratch (its actually quite simple once you understand the design principles), then all you should need is the instruction set for the omap, mainly for things like interrupts etc, what kind of kernel were you thinking of? Monolithic or micro?
 
I'm not sure whether i'd like to make a micro or monolithic kernel. I'd probably just hack until it does stuff - so, I guess, monolithic.


I'd do something like this:


Kernel:


Set up any dumb stuff that needs to be set up (equivalent of gdt, idt on x86)


Print a message on screen to show i'm alive


open an interrupt, with a handler that executes a certain block of code depending on a certain register (like what Linux does)


load shell.bin from disk, give it a stack, jump to it.


Shell:


Await input by calling the kernel interrupt with the register set to the value for 'gets'


Process data pointed to by certain register set by 'gets'


Check if it's a shell function, like chclr or something


If not, search disk/bin


If found, load it, give it a stack, call it.


If not, print error message, loop.


That'll be enough to release v0.001. And I know what i'm signing up for to do that.


I'll need more than the instruction set, because I need to know how to tell it to execute the big lump of bytes i'm throwing at it. I did start reading the manual, if someone tells me to, i'll refrain from posting until i've read ALL 3444 pages.
 
nVidia/ATI, etc cards don't even fucking release info!
While this is absolutely true with Nvidia, ATI/AMD is definitely a bad example nowadays. By now there's full documentation (except for the UVDs) for all cards up to the Radeon HD 5000 series.


But concerning the SGX you definitely hit the nail on the head...
 
because I need to know how to tell it to execute the big lump of bytes i'm throwing at it.

well, it should just be a matter of loading to ram, then doing a branch:


b 0xF00D00BA


where foodooba is the start of the program, that is assuming you're planning on just having the raw instructions in the file


maybe i'm talking out my ass, but i just spent 6 months doing some work on the l4 microkernel, so maybe not :D


had you thought about things like multitaskting etc? or just aiming for a shell that you can throw syscalls into for now etc?
 
I'll need more than the instruction set, because I need to know how to tell it to execute the big lump of bytes i'm throwing at it. I did start reading the manual, if someone tells me to, i'll refrain from posting until i've read ALL 3444 pages.
u-boot's mission in life is to read and execute a big lump of bytes. Read up on mkimage (tool), bootm (u-boot cmd), etc. The TRM wont tell you much on this. If you need documentation on the Cortex-A8 ARM architechture (registers, etc), then the OMAP3530 TRM is not the best place to look at. ARM has some nice docs on the C-A8 available AFAIK. Of course you will propably need the TRM for implementing the MMC driver - which is propably next thing after you get text on screen - for which you will propably need a font and some console driver...
 
Last edited by a moderator:
Be a real man. Use the Pandora itself to write an OS for the Pandora. No cross-compiler allowed, all sources built on the Pandora, and even the burning of the bootloader should be done *by* the Pandora.


That way we finally achieve a system whereby it has *everything* it needs to write code for itself, onboard.


Oh, how I'd just love to have my Pandora build its own rootfs and boot to it ..
 
Oh, how I'd just love to have my Pandora build its own rootfs and boot to it ..
I'd guess buildroot could work on the pandora, given an entire 8 GB SD (or a mostly-free 16 GB) :p


Anyways, everything I have suggested would work straight on the pandora. You can even read the TRM on the pandora :p


But why would you burn (== first write) your own bootloader when there is a well (wrote full, but then I could think of extensions to it, so...) featured bootloader already available and easily configurable to boot either your experimental new OS kernel or the development OS?
 
First of all, thankyou for still posting!


Eventually I'll do it all, real memory management, multitasking, etc etc.


But you have to crawl before you can walk.


I'll get text drawing - that's a must. After I get that going, i'm going to celebrate. Then i'll get a disk driver(setting up interrupts, + everything else, first is implied) , syscalls and a shitty little shell going before anything else. Then i'll work on a better memory manager than:


void * malloc(size_t amount){


kglobals.lastmem-=amount; //kglobals.lastmem set to highest memory location, behaves like a stack


return kglobals.lastmem


}


and


void free(void * ptr){


}


which is what I did in my x86 OS :D :D :D (temporary, but i've pretty much done a "asm("cli;hlt");" on that OS)


Then i'll port essentials like gcc, bash and do the rest of 'kernel-land' as modules to be loaded in(Linux does this! 'insmod'), if I can find a way to make that work. That'll save me from having to change the base kernel too much, only adding syscalls(and fixing bugs). Though, having GCC and an account of super-supremacy/authority that makes root bow down before it, in theory I can change the kernel during run time, but I won't, because that's just...er...not worth it I guess.


I guess that makes it a monolithic kernel, though I suppose the line between usermode and kernelmode would be thin in my OS, because until someone can convince me why I shouldn't, I'm gonna give 'users' the possibility of direct access to the hardware, interrupts, whatever, because it's not gonna be a server OS which has to be reliable and multi-user. I'm really just making this up as I go, I need to write a spec.

Be a real man. Use the Pandora itself to write an OS for the Pandora. No cross-compiler allowed, all sources built on the Pandora, and even the burning of the bootloader should be done *by* the Pandora.


That way we finally achieve a system whereby it has *everything* it needs to write code for itself, onboard.


Oh, how I'd just love to have my Pandora build its own rootfs and boot to it ..

Torpor, maybe once i've got a kernel going, and gcc ported to my operating system. If you've ever done OSdev (I'm NOT calling you a noob!) you'd know using your dev machine as your test bed is a recipe for disaster - Not only does the constant on/off degrade the device that has all your code on it, but it's sloow. Best thing would be an emulator, but we know that's not really going to work, so we're doing option 2, a dev machine injecting a test bed(does anyone else feel a little uncomfortable after typing something like that? Kind of in a 'that's what she said' way?) with code. Thanks, torpor, for your input, and I love your setup for doing Pandora-Linux dev on the Pandora itself. I'll be doing that, too :p . I don't think it IS possible to burn the bootloader ON the Pandora...especially not under the Linux kernel, unless you found a vulnerability in the kernel (if you do, keep quiet. Fix the code yourself or tell some kernel devs, not the whole world like those dumb ass 'security professionals' that always end up helping noone but skript kiddies. </rant>)


"That way we finally achieve a system whereby it has *everything* it needs to write code for itself, onboard." Yeah, how about we finally achieve a system whereby it writes its own code for itself, so programmers like you and I don't have to do anything but hit the red button and watch the money come rolling in? :D . No but seriously, that would be good (your idea). And what money, no good devs ever make money. Look at (most of) the Linux kernel devs, they don't have loads of money, Micro$oft however is the richest company in the world (but then again, the devs that actually did any work are probably paid close to minimum wage :eek: ). No more M$ h8ring in this thread from now on. I shouldn't have mentioned that...


I forgot to quote the others, but


gfrancisdev -- You worked on L4? NICE! The ASM version, or one of the C++ implementations? What you said about loading memory and branching (or jumping , wait, branching == call, right? But you'd never need to return from your kernel, so er, time to break out the manual - but I get your point), is spot on what i'd be doing but loading memory is the issue XD. I'm sorry, I mustn't have made it clear. I feel kinda silly. I've thought about multitasking. I've decided i'll do everything. But, crawl before I can walk. Do the silly little shell thing, then build upon it for all eternity.


urjaman -- I've read about u-boot, it's exactly what I need, it seems. So i'll be using that for loading my kernel. Seems you can put stuff in memory(RAM) over a serial link - PERFECT!!(Well, not perfect but better than JTAG/constant imaging of an SD card) - time to make a EXT connector breakout board(for connecting to a USB->Serial TTL device or serial port via MAX232?) Too bad the TVout doesn't provide the serial(/gpio) pins.


Letalis Sonus -- OK, I looked in the ref manual briefly, and it seems there is enough info on the SGX to suggest that it's open enough to write drivers for it (er how else was there a Pandora-Linux driver?)(while there doesn't really seem to be enough information in the "OMAP35x Technical Reference Manual (Rev. M)" , but here's what I wrote before:


"Erm, by hitting the nail on the head with the SGX do you mean there's no info, or there's plentiful information? If there's no information(i'll look), i'm NOT going to write a Pandora OS - i'll still do info gathering for those who do, but if there's anything major that has little/no docs it's just as bad as x86 and i'll wait 10 years and see if there's a clean platform by that point."


Is there anyone interested in testing/sharing code, like drivers, potential optimisations(future), etc(public domain/BSD-style preferred)(seems there is interest in the idea, but any further?)?


Noone's going to force anyone here, but how much interest is there, in osdev?


As for writing original, main code, in particular I want to work on 'my' OS by myself, i.e. be the only coder, but I don't have to be the only one doing this, and would hold no secrets/source to anyone who asked for it. Not sure what i'd actually license my OS under, NOT strictly proprietary, but probably GPL. I won't be using BSD, because I would rather not allow people to take my code and turn it into a product where I can't see the code. It's unbalanced. Unfair.


So - thanks for posting! I will RTFM, read every FM I can find. I'll call it a night for now, and I won't be near a computer tomorrow(unless the weather's terrible - yep it's summer in Aust, and I need some sunlight.) but i'll continue research on Saturday (Eastern Australian time).


EDIT: Took a peek at git://openpandora.org/pandora-u-boot.git - looked in the boards/pandora directory (downloaded the whole git). Seems at least part of it, likely all of it (in the pandora directory) was written/adapted by Notaz, who luckily is still with us. I won't pm him, I find that's really rude, but maybe he might stumble upon this thread and enlighten us. A man can dream :D .


Notaz, you're awesome. Line 5, pandora.c


" * Derived from Beagle Board, 3430 SDP, and OMAP3EVM code by "


A pointer for more research.


Line 43:


"#define FRAMEBUFFER_ADDRESS 0x86000000"


If these values are the same after uboot has done its thing and loaded and jumped to a kernel, we now have our framebuffer address. Yay, I actually did some meaningful research...or, well, everyone who told me to use u-boot did, especially urjaman, for telling me to actually look at the code.


I'll do further looking, maybe edit this post more, maybe something else to be defined at run-time :D .


EDIT: just noticed something about the TI ref manual. In the glossary, they define 'BIOS' as Built-in Operating System, in x86 i've always heard 'Basic Input Output System'. Heh, interesting. I guess since the BIOS isn't really gonna be used in the OMAP for i/o, it's good but could they have use another acronym?


EDIT: Check this out


menu.c


#include <common.h>


#include <asm/io.h>


#include <hush.h>


#include <malloc.h>


#include <lcd.h>


#include <twl4030.h>


there's a lot of printfs throughout menu.c too, seems there is already everything we need for text output. Maybe I can make a start using uboot directly as a base. I'll have to read its license info...
 
Last edited by a moderator:
gfrancisdev -- You worked on L4? NICE! The ASM version, or one of the C++ implementations? What you said about loading memory and branching (or jumping , wait, branching == call, right? But you'd never need to return from your kernel, so er, time to break out the manual - but I get your point), is spot on what i'd be doing but loading memory is the issue XD. I'm sorry, I mustn't have made it clear. I feel kinda silly. I've thought about multitasking. I've decided i'll do everything. But, crawl before I can walk. Do the silly little shell thing, then build upon it for all eternity.

well most of it is in C/asm, but it's mashed together with a proprietry system i can't discuss for pretty much everything above the scheduler, this was on an armv7(close to is that is), so pretty close to the omap in terms of hardware.


the initialisation goes somethign like this:


start


initialise mmu/interrupts


kick off the timers (the hardware timers, loop round once per tick/other time unit)


synchronise with other cores if there are any


branch to the start of the kernel, instruction after this is an emergency stop of the main clock, so it all freezes and the stack can be looked at if this ever happens (no idea if the omap has the instruction, and can't remember what it is :p )


in theory you should be able to just pass u-boot an elf/similar file of the kernel, which it'll load then try and execute, i've somehow managed to avoid using any form of real bootloader as everything runs on bare metal in phones


once the kernel runs, it should be a matter of setting any lcd registers for brightness/sync/etc (already setup by u-boot? as the boot menu can display), then write to wherever the lcds buffer is to display things. after that it's all just writing the scheduler and all that fancy bollocks


it's quite surprising how simple an os can be, even when it's supposed to be small and simple like l4. you'll be needing a liberal splash of assembly in places though, so keep reading the docs :D


edit: oh and i think you can enable the serial console on the usb port, pretty sure i saw that in the u-boot menu at least
 
Last edited by a moderator:
edit: oh and i think you can enable the serial console on the usb port, pretty sure i saw that in the u-boot menu at least
That's because u-boot has usb otg drivers for that. Means that usb serial is not trivial stuff.


For serial port: http://openpandora.ca/schematic/AV_Board_schematic.pdf - so you could roll it with the connector (which you will propably need to wait month(s) for atm) + MAX3381E + LP2992 (1.8V reg) + some passive components + DE-9 connector. OTOH the MAX3381E is so expensive that I remember counting that it might be cheaper to roll with TXB0104 + 1.8V reg + 5V booster + MAX232 :p
 
Letalis Sonus -- OK, I looked in the ref manual briefly, and it seems there is enough info on the SGX to suggest that it's open enough to write drivers for it (er how else was there a Pandora-Linux driver?)
The Pandora's SGX driver isn't open, it's proprietary => no public documentations needed.


And of course I meant that there's only few documentations, else there would be a usable open driver for it as SGX GPUs are very common in mobile devices. Just look at the whole Poulsbo mess (Intel's GMA 500 == PowerVR SGX 535). They certainly have released enough information to code a proper 2D driver, but 3D is an entirely different story...
 
I had a big day today, lots of activity IRL, so nothing useful to contribute tonight :p .

well most of it is in C/asm, but it's mashed together with a proprietry system i can't discuss for pretty much everything above the scheduler, this was on an armv7(close to is that is), so pretty close to the omap in terms of hardware.


the initialisation goes somethign like this:


start


initialise mmu/interrupts


kick off the timers (the hardware timers, loop round once per tick/other time unit)


synchronise with other cores if there are any


branch to the start of the kernel, instruction after this is an emergency stop of the main clock, so it all freezes and the stack can be looked at if this ever happens (no idea if the omap has the instruction, and can't remember what it is :p )


in theory you should be able to just pass u-boot an elf/similar file of the kernel, which it'll load then try and execute, i've somehow managed to avoid using any form of real bootloader as everything runs on bare metal in phones


once the kernel runs, it should be a matter of setting any lcd registers for brightness/sync/etc (already setup by u-boot? as the boot menu can display), then write to wherever the lcds buffer is to display things. after that it's all just writing the scheduler and all that fancy bollocks


it's quite surprising how simple an os can be, even when it's supposed to be small and simple like l4. you'll be needing a liberal splash of assembly in places though, so keep reading the docs :D


edit: oh and i think you can enable the serial console on the usb port, pretty sure i saw that in the u-boot menu at least

Yeah, in a device where you directly program the memory via JTAG/etc (or to a PROM-like device in the factory) you there's no need for any bootloader bullshit. But in a device such as the Pandora or PC - where your kernels/OSes are huge and stored in slower memory...it gets more complicated. I know what to do when I can get booted, it's just a matter of executing a payload - which I think is sorted - the answer is a German submarine - u-boot.


About the serial console via usb, I saw something like that too but ignored it for the moment, i'm too tired tonight to look at what it can do. If the Pandora can behave as a USB->Serial device, that can be written to with kermit/minicom/cat! i'll have a huge smile across my face. Maybe, that can be an OS feature.

That's because u-boot has usb otg drivers for that. Means that usb serial is not trivial stuff.


For serial port: http://openpandora.ca/schematic/AV_Board_schematic.pdf - so you could roll it with the connector (which you will propably need to wait month(s) for atm) + MAX3381E + LP2992 (1.8V reg) + some passive components + DE-9 connector. OTOH the MAX3381E is so expensive that I remember counting that it might be cheaper to roll with TXB0104 + 1.8V reg + 5V booster + MAX232 :p

eh?


I saw that schemo before, we don't need the whole board to grab serial - in fact, if we're lucky(outputs are open drain(10k pullup to 5v = instant level shift), inputs are 5v tolerant - doubt that, pretty sure Michael Weston's "Hacker's Guide" says that we should not give the omap more than 1.8v. Resistors? Hehe, i'm kidding. But no, a 1.8v regulator and a transistor switch should do the trick - because we have 5v supply/logic, it's easy to go down(True RS232 is a lot harder). The issue is converting the output voltage to TTL/RS232. It's pretty easy to get TTL from an open-drain output. The MIDIBOX STM32-version Core module does this. If they're not open drain, we can probably make a switch that takes a 1.8v input, provides TTL out - and still be less complex than the MAX232 circuit.), we can just use a USB->TTL Serial converter for serial links. (I edited stuff into this, so it's out of order. best read it twice.)


Please note, doing any of this, even the official breakout board will no doubt void your warranty.

The Pandora's SGX driver isn't open, it's proprietary => no public documentations needed.


And of course I meant that there's only few documentations, else there would be a usable open driver for it as SGX GPUs are very common in mobile devices. Just look at the whole Poulsbo mess (Intel's GMA 500 == PowerVR SGX 535). They certainly have released enough information to code a proper 2D driver, but 3D is an entirely different story...

...fuck.


Well, as much as that pisses me off - it's lucky that I don't personally want/need 3D, but you say (I won't get mad if there's not, lol :D ) there's enough for 2D, which is absolutely necessary. I mean, I honestly can't see why they wouldn't release specs. Is their memory map patented or something :p ? "NO YOU CAN'T PUT YOUR SUPER-LAME-MODE AT 0x13377175 -we wanted it really bad and patented it!". Really great that there IS info on 2d - doing 2d blitting in software is sloooow.


doublebeta's CrappyComparison:


Software SDL Surface in Linux, AMD Athlon 3200+ 64-bit at 2050Mhz, bogomips 4100.55 reports 20%-30% CPU util whilst running my RPG (with a rather confusing fps setting - while not doing anything, SDL_Flip is called 5 times a second, to make sure you can see stuff if you move the window out of view, and back again. When walking, the screen is flipped at 25FPS., after blitting everything useful to the screen It's actually pretty optimised, in functionally at least, if the code isn't so great.) is terrible.(cpu utilisation isn't the best meter of game performance, I know, and bogomips means nothing) Hardware SDL Surface in Windows(can't get hardware surface under X via sdl, apparently), Intel Core 2 Duo (forgotten rest) reports 1% cpu usage, peak. - When compiled by mingw32 under a Linux host, with dynamically linked sdl(static in Linux). And there's no multithreading in my game when I made this test.


It surprises me, i'll add while we're talking about game cpu usage, that some people redraw constantly in their gamesZ(on PC, I know nothing about games currently running on Pandora). Do they not realise, that more cpu usage = faster battery drain/more power consumed, and that they really can't acheive more than a certain FPS without tearing?


BTW, I put 'Poulsbo' into firefox's address bar (<3), got http://en.wikipedia.org/wiki/System_Controller_Hub. I'm not sure what mess you were really referring to - that it only works under the older kernel?, but I saw this which provided a little bit of 'lol'.


"A proprietary driver was shipped with Dell's adaptation of Ubuntu 8.04.1 Netbook Remix, which provides 2D hardware acceleration (although users reported serious stability issues[5]) under Linux kernel 2.6.24"


That's what's so WRONG about proprietary drivers - they're always fucked, and we can't do anything about it. They'd save so much hassles for themselves, programmers, and even the end-user if they'd just make a damn spec sheet > :( .


I wonder if it's truly legal, to take a chunk of proprietary driver binary, and write code around it to make it usable. I mean, what would their motive be, trying to take someone to court for that? "WRAAR YOU BOUGHT OUR PRODUCT AND TRIED TO ACTUALLY USE IT! FEEL OUR WRATH!"





...I really should try everything possible BEFORE I begin to type.


http://www.phoronix.com/scan.php?page=news_item&px=NzAyOQ


http://www.happyassassin.net/2009/01/30/intel-gma-500-poulsbo-graphics-on-linux-a-precise-and-comprehensive-summary-as-to-why-youre-screwed/ <-- Love the title.


Yeah, I see what you mean. Ugh. Things got really fucked up in the way of video cards, hey. Is there a single video chip, on the market today, that isn't full of proprietary bs?


Let's blame Micro$oft. It's their fault, somehow (smile), even though it seems it's not, because normally there's _only_ a Windows driver :p . But the situation isn't any better. There's a Linux driver, which is useless to other OS devs/users (except maybe FreeBSD/DragonflyBSD could potentially use them), which also is crap. I actually do think it's their(M$'s) acceptance of proprietary drivers, and teh ability to wrap them up in tiny .inf+.dll packages that allow companies to do stuff like this without going bankrupt. Back in DOS, programs often wrote their own drivers(see pretty much any demo with sound in the demoscene, you'll see maybe a GUS driver, or SB, or maybe even a http://en.wikipedia.org/wiki/Covox_Speech_Thing driver(man that'd be easy to work with.) - to do so they needed the manual. It worked. Why change a working system?


I hope sound is not this bad. I've neglected to research this yet. But at least, there is a fallback if we can't use the audio DAC - we have PWM! (smile). A lot of PC sound cards are really just PWM, btw, so it could sound decent, the downside being that there needs to be some cable hacking to use the PWM channels (but you don't have to open your pandora, thank god). Luckily, though it pains me as a musician/music lover to say it, sound is NOT important until I can do everything else. Though impossible due to having to port Qt (stuff that), i'd love to see LMMS run, just to show how much it's not just *L*MMS like it used to be (which was awesome, it actually was the single cause for some switching to Linux!), it's now been ported to Windows. I think that's kinda lame. Though I do get to mess around at school now :) .


Thanks for posting, your input is much appreciated, and very useful. Let's pray we can get through hardware hell.


Note that I'm quite powerless without a Pandora, I can't really confirm anything at all without hardware to test (do NOT give me priority, I could never do that. And I was never suggesting that someone should send a test unit :p ). So i'll repeat, what i'll do now, is accumulate information, get all the tools I need, and maybe proto some code.


You have posted a message with more emoticons that this board allows. Please reduce the number of emoticons you've added to the message (I so would otherwise put a sad face at the end of this statement.)
 
Last edited by a moderator:
anyone happen to know exactly what the boot.txt should be to load a binary and jump to it? should just be that simple hopefully


and while i'm at it, does anyone know where the u-boot is in terms of address? wouldn't want to flash over it (when it came to flashing stage :D )


i'll see if i can throw a simple while(1) binary at u-boot sometime, see what happens...hopefully an infinite loop XD
 
anyone happen to know exactly what the boot.txt should be to load a binary and jump to it? should just be that simple hopefully


and while i'm at it, does anyone know where the u-boot is in terms of address? wouldn't want to flash over it (when it came to flashing stage :D )


i'll see if i can throw a simple while(1) binary at u-boot sometime, see what happens...hopefully an infinite loop XD

Better to not flash at all, ever - apparently we can write to RAM over serial. This would be best until we know what we're doing.


But in case you do want to run from flash, maybe instead of a simple while(1) do-nothing loop, how about fill all RAM with 0, then 1...255- you would see stuff happening (wait until you hit the framebuffer :D ). I guess, it'd make debugging a nightmare if you didn't see stuff happening :eek: .


EDIT: If we do manage to brick our Pandoras, via software, is our warranty still valid? Can we ship them back(we pay shipping) to be reflashed? Or, if I remember correctly, we just make an SD card which is autobooted no matter what, that will reflash = not bricked?
 
Last edited by a moderator:
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 ;)
 
Back
Top