Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
2 user(s) are online (1 user(s) are browsing Forum)

Members: 1
Guests: 1

mordesku, more...

Browsing this Thread:   1 Anonymous Users



(1) 2 3 4 5 »


Raspberry Pi - Operating System Development

Joined:
2004/3/29 12:03
From London - England
Group:
Member
Posts: 476
Offline
I'm splitting my post the porting thread to here. I want his thread to be dedicated to actual development work on bootstrapping the RasPi, with the intention of getting AROS running.

Raspberry Pi - Operating System Development:

Here is the Raspberry Pi boot sequence (From http://raspberrypi.org/phpBB3/viewtopic.php?f=63&t=6685 ):

When the Raspberry Pi is first turned on, the ARM core is off, and the GPU core is on. At this point the SDRAM is disabled.

The GPU starts executing the first stage bootloader, which is stored in ROM on the SoC. The first stage bootloader reads the SD card (Which needs to be FAT32, or at least the first partition does), and loads the second stage bootloader (bootcode.bin) into the L2 cache, and runs it.

bootcode.bin enables SDRAM, and reads the third stage bootloader (loader.bin) from the SD card into RAM, and runs it.

loader.bin reads the GPU firmware (start.elf).

start.elf reads config.txt, cmdline.txt and kernel.img

kernel.img, a binary image of ARM memory starting at physical address 0 from the ARM's perspective. And releases reset on the ARM.

As I understand it, the actual Kernel in the kernel image starts at 0x8000, which is were the first "safe" memory location is...

I'm currently reading https://github.com/dwelch67/raspberrypi which is about running on the bare SoC metal, ie no OS :)

Posted on: 2012/6/11 3:19
Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2004/3/29 12:03
From London - England
Group:
Member
Posts: 476
Offline
There are currently three versions of start.elf and each one sets up the ARM vs GPU memory split differently (128Meg GPU vs 128Meg ARM, 64Meg GPU vs 192Meg ARM, 32Meg vs GPU 224Meg ARM). I think the 32/224 split would be most appropriate for AROS at least now!

What we need to do is build a kernel.img file that bootstraps AROS... Which shouldn't be too difficult as we already have an ARM hosted version... What I need to do is figure out were the RasPi frame buffer is :)

Posted on: 2012/6/11 3:30
Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2008/6/7 13:52
Group:
Member
Posts: 2097
Offline
This work is good for the long term, in the short term I believe the hosted solution is best. I am about to upload a video showing my adapted version of Pascal's AEROS Broadway X which I think is a short term solution to getting people actually porting Aros software to Arm.

It is key to get people excited about Aros and Arm and being able to start working on porting to Aros whilst also having access to the 3d and 1080p video playback is amazing.

However, I hope to raise funds to support native development over the coming months but all native development must be designed to allow adapting to other Arm platforms.

Remember, gfx drivers may be impossible due to the closed nature, I believe the Nic drivers are open however.

Posted on: 2012/6/11 4:14
_________________
Amiga 1000, 3000D and iMica Silent and NVidia version running latest Icaros.
http://www.imica.net

Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2004/3/29 12:03
From London - England
Group:
Member
Posts: 476
Offline
I have nothing against Linux hosted, but X11 on the RasPi is (currently) horrible... And bringing an OS up on real harware seems like the point of the Pi ;)

Posted on: 2012/6/11 5:49
Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2008/6/7 13:52
Group:
Member
Posts: 2097
Offline
I totally agree with you, but having talked to clued up Aros people the work to get Aros native is not small and whilst I am all for it in the long term, we need to have something to show the benefit now, because if developers do not port there software then why bother going native.

This way, if developers do get interested with the potential of this cheap hardware then it can only benefit the native port later.

http://www.youtube.com/watch?v=COUrcZat6oc

Oh, blatant video link to show what I mean for when the other link is gone as it is very relevant.

Posted on: 2012/6/11 7:02
_________________
Amiga 1000, 3000D and iMica Silent and NVidia version running latest Icaros.
http://www.imica.net

Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2004/3/29 12:03
From London - England
Group:
Member
Posts: 476
Offline
The kernel.img is just a flat binary which gets loaded into address space starting from 0x00000000 (the top of memory is 0x10000000, 256meg). The peripherals all start at 0x20000000.

The first 0x20 bytes in that binary is an interrupt vector table (5 vectors?). With the first vector being the reset vector. Once the binary is loaded in, the reset vector is called, so that should point to the start of the kernel/application/startup code.

-edit- the top 32bytes is thr vector table:

0x0: reset
0x4: undefined instruction
0x8: software interrupt
0xC: prefetch abort
0x10: data abort
0x14: ?
0x18 IRQ
0x1C FIQ

-edit2- the top of useable ram is determined by the GPU/ARM memsplit... Therefore if we use a 32/244 split, the top of RAM will be 0xE000000

-edit3- the kernel is actually loaded in at 0x8000, unless disable_commandline_tags=1 is set in commandline.txt

Posted on: 2012/6/11 7:09

Edited by bloodline on 2012/6/11 7:36:17
Edited by bloodline on 2012/6/11 7:39:34
Edited by bloodline on 2012/6/11 8:17:18
Edited by bloodline on 2012/6/11 9:06:44
Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2004/3/29 12:03
From London - England
Group:
Member
Posts: 476
Offline
This is interesting about direct frame buffer access!


/*
* ************************************************************************ *
* **** BCM2835 Specific Stuff **** *
* ************************************************************************ *
* This is where things get interesting (and specific to the BCM2835).
* Most of this was worked out by reading the Linux source code (mostly
* drivers/video/bcm2708_fb.c and arch/arm/mach-bcm2708/) and experimentation.
*
*
* **** Basic procedure to get stuff on screen ****
* The basic procedure to get a frame buffer is:
* 1) Set up a structure with the frame buffer specification (resolution, etc)
* 2) Tell the GPU about this structure by writing to the mailbox
* 3) Wait by reading from the mailbox for the GPU to modify this structure
* 4) Write to the frame buffer at the pointer we got in stage 3
* Only step 4 is required for subsequent writes to the frame buffer. Currently,
* I do not know how to enable the HDMI output, so this will always operate the
* composite, and not the HDMI.
*
*
* **** Mailbox operations ****
* Read/write operatitons on the mailbox consist of transfering data via a
* 32 bit register. 28 bits of this 32 bit register are the data to be sent
* to the receiver, while the lower 4 bits specify the channel (channel 1 is
* the frame buffer, but there are others).
*
* To send data via the mailbox:
* 1) Wait for space in the mailbox
* 2) Write ((data << 4) || channel) to the write register TODO: Make implementation match
*
* To receive data via the mailbox:
* 1) Wait for the mailbox to be non-empty
* 2) Execute a memory barrier
* 3) Read from the read register
* 4) Check the lowest 4 bits of the read value for the correct channel
* 5) If the channel is not the one we wish to read from (i.e: 1), go to step 1
* 6) Return the read value >> 4 TODO: Make implementation match
* Note: This will not work if we're interested in reading from more than one
* channel as it does not handle the reception of other channels' data
*
*
* **** Memory mapped registers ****
* The bus address for the mailbox memory mapped registers is 0x7E00B880.
* This corresponds to an ARM physical address of 0x2000B880 (the address we
* use from the ARM processor, and hence here). We use three registers from
* the mail box:
* - The read register for mailbox 0 at offset 0x00
* - The status register for mailbox 0 at offset 0x1C
* - The write register for mailbox 0 at offset 0x20 (this is actually the read
* register for mailbox 1).
*
*
* **** Notes ****
* - The address of the frame buffer must be at least a multiple of 16 (in
* order to be accurately transmitted in the 28 bits available in the
* mailbox)
* - The 32 bit value we actually send over the mailbox (including the channel)
* is (ADDRESS | 1) where ADDRESS is the address of the structure. This is
* equivalent to sending as the data (ADDRESS >> 4) (remember we do data << 4)
* - This works if we set vwidth = width, vheight = height, x = 0, y = 0.
* - I haven't managaged to make anything but 24 bit depth work, however the
* Linux source seems to use 16 bit?!
* - Sometimes the procedure described to get stuff on the screen doesn't
* work first time. I've hacked around this by repeating until it does work.
* - The two conditions for successfully acquiring a frame buffer are:
* - The data read from the mailbox (with the 4 least significant bits set
* to zero) is 0 (or 1 including the channel)
* - The pointer in the structure is non-zero after the mailbox read
* - Once we have the frame buffer, we can just write to it. The pixels (in
* 24 bit mode) are RGB ordered by y then x coordinate. The address of a
* subpixel is given by: y * pitch + x * 3 + rgb_channel, where rgb_channel
* is 0 for red, 1 for green, and 2 for blue.
*/

#define MAIL_BASE 0xB880 /* This is the base address for the mailbox registers
(actually, there's more than one mailbox, but this is the one we care about) */

/* Registers from mailbox 0 that we use */
#define MAIL_READ 0x00 /* We read from this register */
#define MAIL_WRITE 0x20 /* This is where we write to; it is actually the read/write of the other mailbox */
#define MAIL_STATUS 0x18 /* Status register for this mailbox */
//#define MAIL_CONFIG 0x1C - we don't actually use this, but it exists

//This bit is set in the status register if there is no space to write into the mailbox
#define MAIL_FULL 0x80000000
//This bit is set if there is nothing to read from the mailbox
#define MAIL_EMPTY 0x40000000

#define MAIL_FB 1 /* The frame buffer uses channel 1 */

struct Bcm2835FrameBuffer
{
uint32_t width; //Width of the frame buffer (pixels)
uint32_t height; //Height of the frame buffer
uint32_t vwidth; //Simplest thing to do is to set vwidth = width
uint32_t vheight; //Simplest thing to do is to set vheight = height
uint32_t pitch; //GPU fills this in; set to zero
uint32_t depth; //Bits per pixel; set to 24
uint32_t x; //Offset in x direction. Simplest thing to do is set to zero
uint32_t y; //Offset in y direction. Simplest thing to do is set to zero
uint32_t pointer; //GPU fills this in to be a pointer to the frame buffer
//I find this is usually (always?) 0x4F...TODO: Finish
uint32_t size; //GPU fills this in //TODO: Finish
};

static uint32_t mbox_read()
{
uint32_t r = 0;
do {
while (ReadMmReg32(MAIL_BASE, MAIL_STATUS) & MAIL_EMPTY);//wait for data
r = ReadMmReg32(MAIL_BASE, MAIL_READ); //Read the data
} while ((r & 0xF) != MAIL_FB); //Loop until we received something from the
//frame buffer channel
return r & 0xFFFFFFF0;
}

static void mbox_write(uint32_t v)
{
while (ReadMmReg32(MAIL_BASE, MAIL_STATUS) & MAIL_FULL); //wait for space
//Write the value to the frame buffer channel
WriteMmReg32(MAIL_BASE, MAIL_WRITE, MAIL_FB | (v & 0xFFFFFFF0));
}

static int TryInitFb()
{
//Some (or even all?) of these memory barriers can probably be omitted safely
MemoryBarrier();

//We need to put the frame buffer structure somewhere with the lower 4 bits zero.
volatile struct Bcm2835FrameBuffer *fb = (volatile struct Bcm2835FrameBuffer *)(1 << 22);
//See the comments for Bcm2835FrameBuffer
fb->width = 640;
fb->height = 480;
fb->vwidth = fb->width;
fb->vheight = fb->height;
fb->pitch = 0;
fb->depth = 24;
fb->x = 0;
fb->y = 0;
fb->pointer = 0;
fb->size = 0;

MemoryBarrier();
mbox_write(ArmToVc((void *)fb)); //Tell the GPU the address of the structure
//memory barrier is in the register read/write functions
MemoryBarrier(); //also an explicit one we probably don't need
uint32_t r = mbox_read(); //Wait for the GPU to respond, and get its response
MemoryBarrier();

if (r){ //If r != 0, some kind of error occured
WriteGpio(17);
return -1;
}

if (!fb->pointer){ //if the frame buffer pointer is zero, an error occured
WriteGpio(18);
return -2;
}

//Write a pattern for us to see this is working
MemoryBarrier();
volatile unsigned char *fbmem = (volatile unsigned char *)fb->pointer;
for (unsigned int i = 0; i < 800*200; i++){
switch(i % 3){
case 0: fbmem[i] = 63; break;
case 1: fbmem[i] = 127; break;
case 2: fbmem[i] = 255; break;
}
}
MemoryBarrier();

//Set up our frame buffer information
fbinfo.width = fb->width;
fbinfo.height = fb->height;
fbinfo.pitch = fb->pitch;
fbinfo.pointer = fbmem;

fbinfo.cb = (struct FrameBufferCharacter *)(1 << 23);
fbinfo.line_pos = 0;
fbinfo.charpix = (unsigned char *)0x10000; //We put the character map here
//For some reason, this does not work if we include a C file
//representation (that afaik is correct) - the character map ends up
//slightly jumbled as if it's being read at an offset

fbinfo.xoffs = 0; //It works in the x direction nicely (no overscanning)
fbinfo.yoffs = CHAR_HEIGHT; //cope with overscanning by adding 1 char border
fbinfo.cbwidth = fb->width / CHAR_WIDTH;
fbinfo.cbheight = (fb->height / CHAR_HEIGHT) - 2; //add 1 char border at the top and bottom

return 0;
}

void InitFb()
{
while (TryInitFb()); //Keep trying to make the frame buffer until it works
ClearScreen();
UpdateFb();
}

Posted on: 2012/6/11 7:46
Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2008/6/7 13:52
Group:
Member
Posts: 2097
Offline
@ bloodline

If I can help in any non coding ways please let me know.

Posted on: 2012/6/11 7:54
_________________
Amiga 1000, 3000D and iMica Silent and NVidia version running latest Icaros.
http://www.imica.net

Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2004/3/29 12:03
From London - England
Group:
Member
Posts: 476
Offline
Getting stuff runnin on the bare hardware is not too difficult, and the graphics interface is usable... Now I stumble as te keyboard and mouse are USB only... These I guess will require a proper USB stack... I also haven't had a look at how to access the Boot file system, yet... There isn't really a BIOS to help here :-/

I'm now thinking more seriously about looking into DirectFB and using the Linux kernel as a HAL :-/

Posted on: 2012/6/13 6:26
Transfer the post to other applications Transfer


Re: Raspberry Pi - Operating System Development

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 997
Offline
We only need hardware drivers for the usb ports. Are there Pi versions with both down and upstream ports? We would then need some utility to change what usb device the Pi emulates.

Posted on: 2012/6/13 8:06
_________________
Jyrki.J.Koivisto
Transfer the post to other applications Transfer



(1) 2 3 4 5 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
4341
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3887
4 nikolaos
nikolaos
3677
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2623
7 mazze
mazze
2213
8 clusteruk
clusteruk
2097
9 Kalamatee
Kalamatee
2023
10 damocles
damocles
1789
© 2004-2017 AROS Exec