GP2X Open2x Build #1: Close, But No Cigar ..


torpor

hack hack hack, the little machines fight back
Joined
Oct 21, 2005
Messages
2,475
Location
vienna, austria
Website
w1xer.at
Okay, after some extensive hacking around, some superlative help from DJWillis on the compiler-front, and some tweaking of the SVN builscripts, we now have gcc 2.95.3 folded into the toolchains for Open2X .. which means we can:

0. Build "One Toolchain To Build Everything" (for now, 2.95.3, but we shoot for an 3.x.x gcc ASAP)
1. Build the Kernel, plus modules.
2. Build the libs.
3. Assemble a kernel.img file .. boot it ..

First attempt at a test:

Code:
U-Boot 1.0.0 (Mar 22 2006 - 12:52:24)

U-Boot code: 03D00000 -> 03D4575C  BSS: -> 03D7930C
DRAM Configuration:
Bank #0: 00100000 63 MB
Flash:  0 kB
NAND:Probing at 0x9c000000
Flash chip found:
		 Manufacturer ID: 0xEC, Chip ID: 0x76 (Samsung K9F1208 64Mb)
1 flash chips found. Total nand_chip size: 64 MB
Get Environment from NAND offset 0x70000 ...
*** Warning - bad CRC, using default environment

In:	serial
Out:   serial
Err:   serial
reading kernel.img

1188016 bytes read
### main_loop: bootcmd="bootm"
Hit any key to stop autoboot:  0
## Booting image at 01000000 ...
   Image Name:   linux-2.4.25--jv
   Created:	  2006-08-21  12:21:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:	1187952 Bytes =  1.1 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux....................................................................................... done, booting the .Linux version 2.4.25 (torpor@jdev) (gcc version 2.95.3 20010315 (release)) #3066 Mon Aug 21 14:21:14 CEST 2006
CPU: Arm920Tid(wb) revision 0
Machine: MagicEye-MDK
Warning: bad configuration page, trying to continue
MP2520F FCLK: 199065600 Hz, M = 0x49 P = 1 S = 0
MP2520F UCLK:  95846400 Hz, M = 0x60 P = 0 S = 2
MP2520F ACLK: 147456000 Hz, M = 0x98 P = 0 S = 2
MP2520F PCLK:  49766400 Hz
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mmcsd2 rw
Console: colour dummy device 80x30
Calibrating delay loop... 99.32 BogoMIPS
Memory: 32MB = 32MB total
Memory: 29432KB available (1782K code, 814K data, 300K init)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
CPU: Testing write buffer: pass
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mmsp2_usbh.c: initializing MMSP2 USB host PCI-DMA workaround
MMSP2 USB Controller Core Initialized
cs89x0:cs89x0_probe(0x0)
0xf3000300
cs89x0: no	  cs8900 or cs8920 detected.  Be sure to disable PnP with SETUP
get_random_bytes called before random driver initialization
usbctl: usb-eth registered.
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
I2C: MMSP2 algorithm module loaded.
 <6>I2C: Adding MMSP2-I2C-Adapter.
I2C: Successfully added bus
ttyS0 at MMIO 0xc0001200 (irq = 48) is a MMSP2
ttyS1 at MMIO 0xc0001220 (irq = 52) is a MMSP2
ttyS2 at MMIO 0xc0001240 (irq = 56) is a MMSP2
IRQ_DISP Number = 0
Console: switching to colour frame buffer device 40x30
MMSP2 mmsp2_RGB0 framebuffer driver start
MMSP2 mmsp2_RGB1 framebuffer driver start
pty: 256 Unix98 ptys configured
MMSP2 DualCPU Interface Driver
 unable to get major 89 for
MMSP2 Video Post Processor Driver
 register device MMSP2 GPIO KEY OK
MMSP2 battery check Driver
MMSP2 Real Time Clock driver
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
ac97_codec: AC97 Audio codec, id: WML18 (Wolfson WM9711/9712)
mp2520f.c: Using NAND S/W ECC
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)
Creating 7 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00080000 : "Bootloader"
0x00080000-0x000a0000 : "Param"
0x000a0000-0x001a0000 : "Kernel"
0x001a0000-0x019a0000 : "Filesystem"
0x019a0000-0x029a0000 : "Open2x"
0x029a0000-0x039a0000 : "Spare"
0x039a0000-0x04000000 : "Extend"
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
f_fact = 4, f_clk = 49766400, f_err = +1766400
a_fact = 3, a_clk = 49152000, a_err = +1152000
u_fact = 1, u_clk = 95846400, u_err = +47846400
host/usb-ohci.c: USB OHCI at membase 0xf0004300, IRQ 13
usb.c: new USB bus registered, assigned bus number 1
Product: USB OHCI Root Hub
SerialNumber: f0004300
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver serial
usbserial.c: USB Serial Driver core v1.4
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
net2272: PLX NET2272 USB Peripheral Controller
net2272: irq 222, mapped mem c2804000, chip rev 0011
net2272: running in 16-bit, byte normal bus mode
net2272: version: 2005 Sept 08
Linux video capture interface: v1.00
CX25874 ID = c3
mice: PS/2 mouse device common for all mice
MMC/SD Slot initialized
MMC/SD Card Detected
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.97 (double precision)
Partition check:
 mmcsda:<7>hub.c: port 1, portstatus 101, change 1, 12 Mb/s
 p1 p2
Register SD: 243MB
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Mounted devfs on /dev
Freeing init memory: 300K
hub.c: new USB device 1, assigned address 2
Product: USB2.0 Hub
hub.c: USB hub found
hub.c: 4 ports detected
INIT: <7>hub.c: port 2, portstatus 301, change 1, 1.5 Mb/s
 version 2.84 booting
<7>hub.c: port 2, portstatus 301, change 0, 1.5 Mb/s
hub.c: new USB device 2, assigned address 3
usb.c: USB device not accepting new address=3 (error=-110)
hub.c: new USB device 2, assigned address 4
usb.c: USB device not accepting new address=4 (error=-110)
hub.c: new USB device 1.1, assigned address 5
Manufacturer: Midiman
Product: Midisport 2x2
SerialNumber: Copyright (GPLv2) 2001 by Lars Doelle <lars.doelle@on-line.de>
usb.c: USB device 5 (vend/prod 0x763/0x1110) is not claimed by any active driver.
  Length			  = 18
  DescriptorType	  = 01
  USB version		 = 1.10
  Vendor:Product	  = 0763:1110
  MaxPacketSize0	  = 64
  NumConfigurations   = 1
  Device version	  = 0.01
  Device Class:SubClass:Protocol = 00:00:00
	Per-interface classes
Configuration:
  bLength			 =	9
  bDescriptorType	 =   02
  wTotalLength		= 0085
  bNumInterfaces	  =   02
  bConfigurationValue =   01
  iConfiguration	  =   00
  bmAttributes		=   00
  MaxPower			=  100mA

  Interface: 0
  Alternate Setting:  0
	bLength			 =	9
	bDescriptorType	 =   04
	bInterfaceNumber	=   00
	bAlternateSetting   =   00
	bNumEndpoints	   =   00
	bInterface Class:SubClass:Protocol =   01:01:00
	iInterface		  =   00

  Interface: 1
  Alternate Setting:  0
	bLength			 =	9
	bDescriptorType	 =   04
	bInterfaceNumber	=   01
	bAlternateSetting   =   00
	bNumEndpoints	   =   02
	bInterface Class:SubClass:Protocol =   01:03:00
	iInterface		  =   00
	Endpoint:
	  bLength			 =	9 (Audio)
	  bDescriptorType	 =   05
	  bEndpointAddress	=   01 (out)
	  bmAttributes		=   02 (Bulk)
	  wMaxPacketSize	  = 0040
	  bInterval		   =   00
	  bRefresh			=   00
	  bSynchAddress	   =   00
	Endpoint:
	  bLength			 =	9 (Audio)
	  bDescriptorType	 =   05
	  bEndpointAddress	=   81 (in)
	  bmAttributes		=   02 (Bulk)
	  wMaxPacketSize	  = 0040
	  bInterval		   =   00
	  bRefresh			=   00
	  bSynchAddress	   =   00
 devfsd v1.3.25  started for /dev<
7>hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: new USB device 1.4, assigned address 6
Manufacturer: Griffin Technology, Inc.
Product: Griffin PowerMate
usb.c: USB device 6 (vend/prod 0x77d/0x410) is not claimed by any active driver.
  Length			  = 18
  DescriptorType	  = 01
  USB version		 = 1.00
  Vendor:Product	  = 077d:0410
  MaxPacketSize0	  = 8
  NumConfigurations   = 1
  Device version	  = 1.09
  Device Class:SubClass:Protocol = 00:00:00
	Per-interface classes
Configuration:
  bLength			 =	9
  bDescriptorType	 =   02
  wTotalLength		= 0022
  bNumInterfaces	  =   01
  bConfigurationValue =   01
  iConfiguration	  =   04
  bmAttributes		=   80
  MaxPower			=  100mA

  Interface: 0
  Alternate Setting:  0
	bLength			 =	9
	bDescriptorType	 =   04
	bInterfaceNumber	=   00
	bAlternateSetting   =   00
	bNumEndpoints	   =   01
	bInterface Class:SubClass:Protocol =   03:01:02
	iInterface		  =   05
	Endpoint:
	  bLength			 =	7
	  bDescriptorType	 =   05
	  bEndpointAddress	=   81 (in)
	  bmAttributes		=   03 (Interrupt)
	  wMaxPacketSize	  = 0003
	  bInterval		   =   0a
Setting up MIDI hardware ...
microcontroller type: fx
single stage:  load on-chip memory
open RAM hexfile image /usr/share/firmware/ezusbmidi2x2.ihx
stop CPU
write on-chip, addr 0x0000 len	4 (0x0004)
write on-chip, addr 0x000b len	1 (0x0001)
write on-chip, addr 0x0013 len	1 (0x0001)
write on-chip, addr 0x001b len	1 (0x0001)
write on-chip, addr 0x0023 len	3 (0x0003)
write on-chip, addr 0x002b len	1 (0x0001)
write on-chip, addr 0x0033 len	1 (0x0001)
write on-chip, addr 0x003b len	3 (0x0003)
write on-chip, addr 0x0043 len	3 (0x0003)
write on-chip, addr 0x0e3a len   71 (0x0047)
write on-chip, addr 0x004b len 1008 (0x03f0)
write on-chip, addr 0x043b len 1008 (0x03f0)
write on-chip, addr 0x082b len 1008 (0x03f0)
write on-chip, addr 0x0c1b len  543 (0x021f)
... WROTE: 3656 bytes, 14 segments, avg 261
reset CPU
usb.c: USB disconnect on device 1.1 address 5
usb.c: registered new driver midi
Setting up MidiShare...
hub.c: new USB device 1.1, assigned address 7
Manufacturer: Midiman
Product: Midisport 2x2
SerialNumber: Copyright (GPLv2) 2001 by Lars Doelle <lars.doelle@on-line.de>
usb-midi: Found MIDISTREAMING on dev 0763:1110, iface 1
usb-midi: Found MIDIStreaming device corresponding to Release 1.00 of spec.
usb-midi: Found IN Jack 0x01 EMBEDDED
usb-midi: Found IN Jack 0x02 EXTERNAL
usb-midi: Found IN Jack 0x03 EMBEDDED
usb-midi: Found IN Jack 0x04 EXTERNAL
usb-midi: Found OUT Jack 0x05 EMBEDDED, 1 pins
usb-midi: Found OUT Jack 0x06 EXTERNAL, 1 pins
usb-midi: Found OUT Jack 0x07 EMBEDDED, 1 pins
usb-midi: Found OUT Jack 0x08 EXTERNAL, 1 pins
usb-midi: fetchString(2)
usb-midi: fetchString = 13
usbmidi: found [ Midisport 2x2 ] (0x0763:0x1110), attached:
usbmidi A: /dev/midi00: in (ep:81 cid: 0 bufsiz:64) out (ep:01 cid: 0 bufsiz:64)
usbmidi A: /dev/midi01: in (ep:81 cid: 1 bufsiz:64) out (ep:01 cid: 1 bufsiz:64)
INIT:  Entering runlevel: 3


BusyBox v1.1.0 (2006.02.23-04:45+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/ash: can't access tty; job control turned off
[root@gipi /]$

BusyBox v1.1.0 (2006.02.23-04:45+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

[root@gipi /]$ /usr/local/bin/OPEN2XTester.gpe
+ MIDI: ref 1, MidiShare version 1.88
SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 16192x61424 (ilace = 0)
SDL_GP2X: Looking for a mouse
SDL_GP2X: No mice found
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMc

*** CRASH HANG BASH ***

This shows:

1. Our kernel is booting.
2. USB Host and MIDI drivers work, and MidiShare is loading. (This was already working before)
3. OPEN2XTester shows that MidiShare works (this is good, because MidiShare is a kernel module + libMidiShare)
4. Huston, we have a problem:

Code:
SDL_GP2X: Physical screen = 16192x61424 (ilace = 0)

That doesn't look too good .. and after having a look at the GP2X-specific code for SDL. courtesy of the wizardly paeryn, we see this (sorry for the long paste, just want to make it easy to understand..):

Code:
// Set up hardware
static int GP2X_VideoInit(_THIS, SDL_PixelFormat *vformat)
{
  SDL_PrivateVideoData *data = this->hidden;
  int i;
#ifdef GP2X_DEBUG
  fputs("SDL_GP2X: VideoInit\n", stderr);
#endif

#ifndef DISABLE_THREADS
  // Create hardware surface lock mutex
  data->hw_lock = SDL_CreateMutex();
  if (data->hw_lock == NULL) {
	SDL_SetError("Unable to create lock mutex");
	GP2X_VideoQuit(this);
	return -1;
  }
#endif

  data->memory_fd = open("/dev/mem", O_RDWR, 0);
  if (data->memory_fd < 0) {
	SDL_SetError("Unable to open /dev/mem");
	return -1;
  }
  data->fbcon_fd = open("/dev/fb0", O_RDWR, 0);
  if (data->fbcon_fd < 0) {

	SDL_SetError("Unable to open /dev/fb0");
	return -1;
  }
  data->vmem = mmap(NULL, GP2X_VIDEO_MEM_SIZE, PROT_READ|PROT_WRITE,
			MAP_SHARED, data->memory_fd, 0x3101000);
  if (data->vmem == (char *)-1) {
	SDL_SetError("Unable to get video memory");
	data->vmem = NULL;
	GP2X_VideoQuit(this);
	return -1;
  }
  data->io = mmap(NULL, 0x10000, PROT_READ|PROT_WRITE,
		  MAP_SHARED, data->memory_fd, 0xc0000000);
  if (data->io == (unsigned short *)-1) {
	SDL_SetError("Unable to get hardware registers");
	data->io = NULL;
	GP2X_VideoQuit(this);
	return -1;
  }
  data->fio = mmap(NULL, 0x100, PROT_READ|PROT_WRITE,
		  MAP_SHARED, data->memory_fd, 0xe0020000);
  if (data->fio == (unsigned int *)-1) {
	SDL_SetError("Unable to get blitter registers");
	data->fio = NULL;
	GP2X_VideoQuit(this);
	return -1;
  }

  // Determine the screen depth (gp2x defaults to 16-bit depth)
  // we change this during the SDL_SetVideoMode implementation...
  vformat->BitsPerPixel = 16;
  vformat->BytesPerPixel = 2;
  vformat->Rmask = 0x1f00;
  vformat->Gmask = 0x07e0;
  vformat->Bmask = 0x001f;
  vformat->Amask = 0;

  this->info.wm_available = 0;
  this->info.hw_available = 1;


  this->info.video_mem = GP2X_VIDEO_MEM_SIZE / 1024;
  //  memset(data->vmem, GP2X_VIDEO_MEM_SIZE, 0);
  // Save hw register data that we clobber
  data->fastioclk = data->io[SYSCLKENREG] & FASTIOCLK;
  data->grpclk = data->io[VCLKENREG] & GRPCLK;
  // Need FastIO for blitter
  data->io[SYSCLKENREG] |= FASTIOCLK;
  // and enable graphics clock
  data->io[VCLKENREG] |= GRPCLK;

  // Save display registers so we can restore screen to original state
  data->stl_cntl =   data->io[MLC_STL_CNTL];
  data->stl_mixmux = data->io[MLC_STL_MIXMUX];
  data->stl_alphal = data->io[MLC_STL_ALPHAL];
  data->stl_alphah = data->io[MLC_STL_ALPHAH];
  data->stl_hsc =	data->io[MLC_STL_HSC];
  data->stl_vscl =   data->io[MLC_STL_VSCL];
  // HW bug - MLC_STL_VSCH returns VSCL instead
  data->stl_vsch =   0;//data->io[MLC_STL_VSCH];
  data->stl_hw =	 data->io[MLC_STL_HW];
  data->stl_oadrl =  data->io[MLC_STL_OADRL];
  data->stl_oadrh =  data->io[MLC_STL_OADRH];
  data->stl_eadrl =  data->io[MLC_STL_EADRL];
  data->stl_eadrh =  data->io[MLC_STL_EADRH];
  // save the 4 region areas
  for (i = 0; i < 16; i++)
	data->stl_regions[i] = data->io[MLC_STL1_STX + i];
  data->mlc_ovlay_cntr = data->io[MLC_OVLAY_CNTR];

  // Save vsync polarity (since GPH change it in different firmwares)
  data->vsync_polarity = data->io[DPC_V_SYNC] & DPC_VSFLDPOL;
  // Check what video mode we're in (LCD, NTSC or PAL)
  data->phys_width = data->io[DPC_X_MAX] + 1;
  data->phys_height = data->io[DPC_Y_MAX] + 1;
  data->phys_ilace = (data->io[DPC_CNTL] & DPC_INTERLACE) ? 1 : 0;
#ifdef GP2X_DEBUG
  fprintf(stderr, "SDL_GP2X: Physical screen = %dx%d (ilace = %d)\n",
	  data->phys_width, data->phys_height, data->phys_ilace);
#endif

.. soo .. either:

1) something is awry with the kernel config that doesn't let the mmap() succeed/do what its supposed to do, or
2) something is awry with the SDL build config, using gcc-2.95.3, which clobbers something ..

I asked around a bit among the #gp2xdev crowd, and gfoot has this to say:

Code:
175243 < gfoot> torpor, I just glanced at the logs, are you having issues building SDL with a 2.9.5 gcc?
175344 <@DJWillis> gfoot: yep, goes freakadoodle when run (I think on allocating the screens)
175408 < gfoot> it's the bug I've found in that compiler twice now
175435 < gfoot> if you point a short* at hardware registers, when it accesses it, it does so as two 8-bit reads/writes, which just doesn't work on hardware registers
...
180052 < gfoot> torpor, I don't know of a workaround other than to recode your hardware register access using your own inline assembly
...
180228 < gfoot> if you're looking at 3.3 series compilers, I'd check how they output this code too - it got changed to proper 16-bit instructions in the open2x toolchain, but I don't know whether that's a core code-gen change or just a result of the way you configure the compiler

so .. some more compiler hacking to do .. but we are getting closer and closer .. any comments greatly appreciated ..
 
That looks very impressive!

For those of us who are basically clueless about this system-level stuff, could you briefly explain the purpose of this project?
 
From what I can gather..
It looks to be a completely open replacement for the 2x's firmware/operating system.
It would mean that dev's would have unrestricted access to the hardware of the 2x & would be able to write software that would take full advantage of the system.

Nice work so far :D
 
torpor posted on Aug 21 2006 at 05:12 PM said:
Code:
SDL_GP2X: Physical screen = 16192x61424 (ilace = 0)
That doesn't look too good .. and after having a look at the GP2X-specific code for SDL. courtesy of the wizardly paeryn, we see this (sorry for the long paste, just want to make it easy to understand..):
so .. some more compiler hacking to do .. but we are getting closer and closer .. any comments greatly appreciated ..
As gfoot said, there is a problem with 2.95 and register access. All access to the registers from within the kernel goes through these macros
Code:
#if 0
#define __REG(x)	(*((volatile u32 *)io_p2v(x)))
#else
/*
 * This __REG() version gives the same results as the one above,  except
 * that we are fooling gcc somehow so it generates far better and smaller
 * assembly code for access to contigous registers.  It's a shame that gcc
 * doesn't guess this by itself
 */
#include <asm/types.h>
typedef struct { volatile u32 offset[4096]; } __regbase;
#define __REGP(x)	((__regbase *)((x)&~4095))->offset[((x)&4095)>>2]
#define __REG(x)	__REGP(io_p2v(x))
#endif

#define __REGL(x)	(*(volatile u32 *)io_p2v(x))
#define __REGW(x)	(*(volatile u16 *)io_p2v(x))
#define __REGb(x)	(*(volatile u8 *)io_p2v(x))
#define __PREG(x)	(io_v2p((u32)&(x)))
Where io_p2v() is just a macro to convert the physical address into a virtual one.
I hope this helps, I can't verify whether it works or not as I use gcc 4.
 
Last edited by a moderator:
Tripmonkey_uk posted on Aug 21 2006 at 12:00 PM said:
From what I can gather..
It looks to be a completely open replacement for the 2x's firmware/operating system.
It would mean that dev's would have unrestricted access to the hardware of the 2x & would be able to write software that would take full advantage of the system.

Nice work so far :D
Oh, I see -- so this is the same thing as the "HH mode" that has been discussed? If so, that's cool. Games using that mode should be able to avoid the annoying stuttering effect (occasional pauses) that is currently unavoidable. I'm sure there must be some other advantages too.
 
Last edited by a moderator:
paeryn: Where io_p2v() is just a macro to convert the physical address into a virtual one.
I hope this helps, I can't verify whether it works or not as I use gcc 4.

It sure helps to know, and since we at least have a 'partially unbroken' build system, we are now moving the compiler as far forward as we can on the whole tree, building as we go ..

Dzz: For those of us who are basically clueless about this system-level stuff, could you briefly explain the purpose of this project?

Well, the purpose is simply to fulfill the actual 'Open' nature of the GP2X OS .. that is to say, produce a runnable image which can be built, and modified, by anyone. Hopefully this will work well enough that folks will want to maintain it concurrently, moving things forward ..

The goal for now is to get a stable and functional replacment for the factory firmware buildable by anyone savvy enough to check out the Open2X SVN tree. Maybe we don't need the 'best' compiler to build a firmware release, just a good one .. but its good to know 2.95.3 is a dead bird beyond the kernel. :p
 
torpor posted on Aug 21 2006 at 12:29 PM said:
ell, the purpose is simply to fulfill the actual 'Open' nature of the GP2X OS .. that is to say, produce a runnable image which can be built, and modified, by anyone.
Ok, that sounds like it could be useful for people who want to tinker with their OS. I had thought that GPH released buildable kernel source, but maybe it isn't "easily buildable"...
 
Last edited by a moderator:
Dzz posted on Aug 21 2006 at 06:35 PM said:
Ok, that sounds like it could be useful for people who want to tinker with their OS.

Well, as a community it'd be useful as well, since the goal for the open2x script is: it must work. ;)

I had thought that GPH released buildable kernel source, but maybe it isn't "easily buildable"...

The point is not just the kernel, but the rest of the host OS as well .. if we have a common 'complete build' to rally around, we can push it forward on many points ..
 
Last edited by a moderator:
how much is actually different from the GPH kernel to the standard 2.4 kernel its based on? would it be possible to move onto a newer kernel and add the needed changes so we can compile it and its required libs including SDL with GCC 3 or 4? because that would be a lot better overall :)
 
Dzz posted on Aug 21 2006 at 02:23 PM said:
Tripmonkey_uk posted on Aug 21 2006 at 12:00 PM said:
From what I can gather..
It looks to be a completely open replacement for the 2x's firmware/operating system.
It would mean that dev's would have unrestricted access to the hardware of the 2x & would be able to write software that would take full advantage of the system.

Nice work so far :D
Oh, I see -- so this is the same thing as the "HH mode" that has been discussed? If so, that's cool. Games using that mode should be able to avoid the annoying stuttering effect (occasional pauses) that is currently unavoidable. I'm sure there must be some other advantages too.

I wouldnt say it replaces HH its more like having the source to the OS (which GPH is supposed to deliver) AND being able to build it. AND being able to build applications for it. This is not a simple re-compile of the linux OS on an x86 running debian or slackware (where a few makes will build and install the whole thing). Basically if/when you or I or the next person can download and re-build the os, then, just like linux on debian or slackware, we can control Linux, change the drivers to suit our needs, etc. when someone asks, how much ram do we really have, where is this located, how do I...We can answer those questions. What if I dont want SDL in return for more ram. Well you can do that...

HH is all together different, its a non-OS environment. One of the things I want to see in this thread is the (re-)building of the modified bootloader. I prefer the bootloader that lets me boot a .img file off of the sd card instead of the linux image in the nand flash. this allows for testing of linux builds or non-os hh programs or other oses before commiting them to nand (or never committing them to nand flash). Like dual booting.

In theory the "mmu hacks" and other such things could be incorporated into the OS instead, so that they are always there. Better or faster or smaller drivers. Sound or video or whatever could be offloaded to the 940 by default instead of making it a project. (well someone has to make it a project once then everyone else can just have it there as a default).

It IS an HH project in the sense that they are trying to run an operating system and drivers that were not the ones that came with the unit, nor were an upgrade from GPH...
 
Last edited by a moderator:
Dzz posted on Aug 21 2006 at 01:23 PM said:
Oh at I see -- so this is the same thing as the "HH mode" that has been discussed? If so, that's cool. Games using that mode should be able to avoid the annoying stuttering effect (occasional pauses) that is currently unavoidable. I'm sure there must be some other advantages too.
Not exactly; HH is a made-up term for 'bare metal' programming of the machine in a minimalistic environment with no real 'operating system' to speak of; you'd bootstrap a custom image that'd just run your program with no OS; you'd ideally work mostly with ASM at a lower level than with Linux/SDL for example. The benefits would be more free CPU time (I would estimate you might see maybe a 10% performance gain, in theory.. maybe less) and about 5MB more free RAM to use, more freedom to customize how memory is laid out .. and most importantly, access to the hardware at the lowest level, talking to it via memory addresses alone, no kernel or drivers in the middle. Given how much can be accomplished through Linux I don't hold 'HH' to be crucial for widespread development, though it may be desirable for some specialized projects with legitimate need for lower-level hardware access.

Open2X as best I understand it would be the framework for one to build their own custom Linux kernel like any usual Linux system with custom drivers for their hardware (things they may wish to connect via USB Host for example), any things they don't need removed to free up kernel-occupied RAM or decrease boot time, et cetera; also allowing easy production of firmware flash images that are intercompatible with GPH's official FW releases' features while allowing easy expansion with new ones.

Once GPH gives up writing new firmware versions (hopefully not too soon) Open2X or a similar project will, in all likelihood, become the dominant and most maintained firmware solution.
 
Last edited by a moderator:
Back
Top