GP2X U-boot, Open2x, Hh, Img, Gcc, Cont

[dwelch]

Oh, no, not dwelch again!

Yep! Apparently it is bad form to continue old threads but instead splinter off new ones to continue the discussion...

U-boot. What is the status of u-boot? You probably only have to read a few post to see that I am mostly interested in HH. I found open2x and more info on a modified u-boot today and have some questions. Can we use u-boot with GPH's 2.x linux? Is the install still the same? where are the latest-greatest files? I think one of the art links is gone/broken.

Okay I started by asking what the format of the .img file is, but just found something on it, so, say for example I wanted u-boot to boot an img off of the sd instead of nand. And I basically wanted a wee little program that shoved a few bytes into the uart (which is clearly already setup), perhaps "Hello World" for example. Can anyone give me some advice on how to do that or a simple example (something simpler than the entire linux kernel source, which I already have). I am assuming the binary associated with this (is it elf or just bytes?) is setup to be branched into at address 0x8000 and does not have a vector table, just an entry point?

How much memory is u-boot using (so I can stay out of its way)? < 0x8000 I assume

About building gcc. I think I saw open2x related pages saying it could build gcc with cygwin. but then another comment that it so far doesnt work on windows. I have been building gcc since 2.95.3, but somewhere in the 3.x days it stopped working for me and I just went with linux (where it still works for me). I greatly prefer mingw, but even a cygwin build of gcc 4.x would be nice. Anyone know the tricks? binutils I have building no problem, but not gcc, nor newlib (I prefer newlib to glibc).

And I am going back to the data/sales/marketing sheet...again... (mesdigital MMSP2 data sheet) "It also supports a H/W Bootdown function that allows a PC to update the system program memory contents directly via the UART I/F port." Anyone know anything about that? Is that possible with this unit (vs using jtag), or is it one of those you have to short pin 27 before reset kind of things (where we dont have access to pin 27 without cracking the case)? Just curious, if I brick this thing would like to use this feature over buying/building a jtag programmer. (In theory if I get the u-boot with selectable boot options on, then I can boot from the sd for testing/fun and leave the nand for the GPH linux and filesystem and wont have to deal with it again).

I noticed when booting it says:

### main_loop: bootcmd="bootm"
Hit any key to stop autoboot: 0
## Booting image at 01000000 ...

How do you do that? I held buttons down on the gp2x and held a key down on the pc in hyperterm, kept booting...Oh, I guess I see that one, bootdelay is zero and they didnt build with CONFIG_ZERO_BOOTDELAY_CHECK, or I couldnt get a "key press" in there in time.

#else
printf("Hit any key to stop autoboot: %2d ", bootdelay);
#endif

#if defined CONFIG_ZERO_BOOTDELAY_CHECK
/*
* Check if key already pressed
* Don't check if bootdelay < 0
*/
if (bootdelay >= 0) {
if (tstc()) { /* we got a key press */
(void) getc(); /* consume input */
printf ("\b\b\b 0");
abort = 1; /* don't auto boot */
}
}
#endif

while ((bootdelay > 0) && (!abort)) {
int i;

--bootdelay;
/* delay 100 * 10ms */
for (i=0; !abort && i<100; ++i) {
if (tstc()) { /* we got a key press */
abort = 1; /* don't auto boot */
bootdelay = 0; /* no more delay */
# ifdef CONFIG_MENUKEY
menukey = getc();
# else
(void) getc(); /* consume input */
# endif
break;
}
udelay (10000);
}

printf ("\b\b\b%2d ", bootdelay);
}

 

[Robster]

I don't really know about hacking u-boot or .img files, so I'll leave those to others. But you obviously didn't read the boot log very well, because right at the start it says:

U-Boot 1.0.0 (Apr 20 2006 - 12:51:09)

U-Boot code: 03E00000 -> 03E49610  BSS: -> 03E82208
IRQ Stack: 03ea3204
FIQ Stack: 03ea4204
DRAM Configuration:
Bank #0: 00100000 63 MB

So what it's saying is the that U-Boot code is located at 0x03E00000. Actually at boot the CPU hardware loads about 4k of code from Flash address 0 into RAM address 0, and executes it. The code at Flash address 0 is actually part of U-Boot, it's a little bootstrap loader that loads in the rest of U-Boot to 0x03E00000 and executes it. Phew!

The autoboot delay is actually implemented, but the default environment has it set to 0 - see the boot log again:

Get Environment from NAND offset 0x70000 ...
*** Warning - bad CRC, using default environment

To get the delay to work, you need to write a valid environment into Flash at 0x70000. The most reliable way of doing this is from the U-Boot command line, but of course you can't really access that. I did it by corrupting the Linux kernel image so that U-Boot aborted loading it, then setting the environment and writing it to Flash, and then writing a valid kernel image again. That's a fairly extreme procedure just to get a delay, but U-Boot is fun to play with sometimes

Don't know about hardware bootdown via serial port. Philips ARM CPUs (LPC2148 etc) do it, maybe you could find tools or info at Philips?

I don't know if you've seen any of my HH efforts, not that I've done anything lately, but have a look at my last (for now) sdk2x which might give you some ideas.

Also, if you have a look at the "Toolchain" page in the GP32 part of my site, you'll get some info about building gcc on Linux/Cygwin. I'm sure you can figure it out!

This message has exceeded my attention span. Reply if you want more information

 

[dwelch]

I don't really know about hacking u-boot or .img files, so I'll leave those to others. But you obviously didn't read the boot log very well, because right at the start it says:

U-Boot 1.0.0 (Apr 20 2006 - 12:51:09)

U-Boot code: 03E00000 -> 03E49610  BSS: -> 03E82208
IRQ Stack: 03ea3204
FIQ Stack: 03ea4204
DRAM Configuration:
Bank #0: 00100000 63 MB

So what it's saying is the that U-Boot code is located at 0x03E00000. Actually at boot the CPU hardware loads about 4k of code from Flash address 0 into RAM address 0, and executes it. The code at Flash address 0 is actually part of U-Boot, it's a little bootstrap loader that loads in the rest of U-Boot to 0x03E00000 and executes it. Phew!

The autoboot delay is actually implemented, but the default environment has it set to 0 - see the boot log again:

Get Environment from NAND offset 0x70000 ...
*** Warning - bad CRC, using default environment

To get the delay to work, you need to write a valid environment into Flash at 0x70000. The most reliable way of doing this is from the U-Boot command line, but of course you can't really access that. I did it by corrupting the Linux kernel image so that U-Boot aborted loading it, then setting the environment and writing it to Flash, and then writing a valid kernel image again. That's a fairly extreme procedure just to get a delay, but U-Boot is fun to play with sometimes

Don't know about hardware bootdown via serial port. Philips ARM CPUs (LPC2148 etc) do it, maybe you could find tools or info at Philips?

I don't know if you've seen any of my HH efforts, not that I've done anything lately, but have a look at my last (for now) sdk2x which might give you some ideas.

Also, if you have a look at the "Toolchain" page in the GP32 part of my site, you'll get some info about building gcc on Linux/Cygwin. I'm sure you can figure it out!

This message has exceeded my attention span. Reply if you want more information

Obviously, yes, I missed that, although that doesnt cover what happens around address zero, which you have now helped with.

Not sure about the connection between the default environment message and the delay mode. The kernel code I cut and pasted shows you can have a zero delay and still check for a key if the ZERO_BOOTDELAY_CHECK flag is set. I guess if there were a push a key on hyperterm solution to any of this it would be on a web page somewhere, so it probably isnt worth pursuing, just thought there might be a yeah we tried that and it wasnt worth it because...

Yes I have and refer to sdk2x regularly. I think I see the light, trampoline.c now makes a lot more sense. Copy the image to memory and soft reset the machine, I like that...You have it limited to 4mb though, was hoping for complete freedom (56mb), I may be able to use trampoline to load the modified uboot which can load large programs from sd into ram.

Sometimes you have to explain the problem you are having to someone else and then the solution becomes obvious. Looking at the same stuff I looked at before now says something different to me. I am going to go play with this some more.

That philips arm, LPC2148, is ARM7TDMI based not MP2520F based, so I dont know if it is worth pursuing what could be an entirely different backdoor. Granted they may have both simply purchased this from arm, but you probably have to pull a pin down or up to put it in that mode. What I was fishing for is someone who has a super secret full detail copy of the MP2520F in this unit that could at least give me a go / no go. Like the GBA, some have the real document from Nintendo, some have only reverse engineered works...And of those that have it some might go so far as to say "you know I cant really talk about it much, but you should work on something else"...

I have looked at all of your pages (for the gp2x, and some for the gp32), and I really really appreciate what you have published so far, and may or may not publish in the future.

I did look at your toolchain page, I too was having success with subtle differences with gcc 3.x and newlib, but my tricks dont work anymore with 4.x. I will try your specific configure switches to see if that solves it. gcc 4.x was supposed to have a lot of improvements, I guess I didnt publish the results, but 4.x does out run 3.x from a dhrystone perspective. Hmm, maybe 3.4.6 will build...

 

[dwelch]

Also at if you have a look at the "Toolchain" page in the GP32 part of my site, you'll get some info about building gcc on Linux/Cygwin. I'm sure you can figure it out!

Sometimes you have to explain the problem you are having to someone else and then the solution becomes obvious. Looking at the same stuff I looked at before now says something different to me. I am going to go play with this some more.
...
I did look at your toolchain page, I too was having success with subtle differences with gcc 3.x and newlib, but my tricks dont work anymore with 4.x. I will try your specific configure switches to see if that solves it. gcc 4.x was supposed to have a lot of improvements, I guess I didnt publish the results, but 4.x does out run 3.x from a dhrystone perspective. Hmm, maybe 3.4.6 will build...

You inspired me to try one more time, this time when it failed to build and I did a google search, I landed on pages with good info. (make subtle changes to the google search and you dont get any answers, which must have happened the last time) Apparently the problem, which I saw on 3.4 and 4.1.1 today, is related to mingw or gcc or both or neither and has to do with -I and either a leading ./ or trailing / (really, do the build, then the search, read the pages, sounded like they fixed the bug but didnt know what they were fixing). The key to me was one of them had cut and pasted the command line that caused the error, cleaned up the -I ../../gcc/../this/and/that and it worked. So I tried that, cleaned up the -I lines for that directory, and compiled through that directory, and from there gcc and newlib compiled with no other problems.
I did not use your build script, I did look at it though, some of those items are already defaults or have been taken care of in 4.x for you. It is interesting that pretty much every single gcc cross compiler directions use a slightly different mix of configure switches, etc. One thing your page taught me is that I dont need libgloss from the newlib, had been building newlib and newlibs libgloss with gcc because of how someone elses directions did it not realizing that libgloss doesnt apply to the arm.

Anyway, so now I have a working gcc 4.1.1 that runs on windows.
http://www.dwelchsoftware.com/arm-20060727a.zip
Two example programs are included that build with this compiler (that run on the 940). Pathetically simple examples to you but perhaps useful to others. Next step is to convert at least one of them to use trampoline to run on the 920, then see what if anything I can do with uboot. Still struggling with that one.

 

[dwelch]

All right, I went for it and loaded the open2x uboot, works fine with linux 2.0.0...well so far...

The .img file format is trivial, the mkimage.c program from the bootloader is far from portable so I wrote my own derivative.

Am now building 920 apps that I can load from uboot off of the sd card and have the whole machine / memory space to myself. Now I can "start" working on projects...Start using sdk2x or learn/borrow from it. See if I can get some routines to run completely out of the cache, etc.

http://www.dwelchsoftware.com/arm-20060730a.zip

My gcc compiler build, and some examples including these initial 920 test applications.

So I think I have all of the problems solved, with the exception that running dhrystone still does not come up with the same execution time every time. I assume the video refreshes are stomping on the system bus, maybe I will be able to figure this problem out or I will just have to give up and live with it.

 

[BradN]

It's always exciting programming the bare metal

 

[dwelch]

It's always exciting programming the bare metal

I wouldnt have it any other way...