Crosscompiling to Orange Pi PC

I installed W95 from floppies. That probably wasn’t much faster when you factor disc changes and the fact that once you got beyond about disc 25, it seemed to request them randomly, including ones it had already asked for… :-/

By that time (actually Win3.11) I’d created a network boot floppy that ran a batch file that loaded the across the network from a shared drive. Life’s too short and I was doing builds on 16-20 machines at once.

I installed W95 from floppies. That probably wasn’t much faster when you factor disc changes and the fact that once you got beyond about disc 25, it seemed to request them randomly, including ones it had already asked for… :-/

That doesn’t sound right! Especially since 95 “only” had 13 (for the upgrade version) or 14 (for the “full” version) floppies in the first place :)

Was it maybe 98 instead? I’m not sure whether it was available on floppies but it probably had 25+!

I’m bringing this thread back. What I’m doing is beyond the scope of this thread: ObjAsm Hello, World! help, please?

I’ve been working on properly learning ObjAsm, at least to the degree that I can write things which function. I’ve had limited success.
What keeps biting me is that programs which work in RO seem to fall apart (modified) on the Orange Pi as a U-Boot “stand-alone” application.
Lots of fun like data aborts, and garbage displayed on the UART.

Something wasn’t working right with my recent experiments so I erased the SD card, built a new U-boot and put it on the card. It didn’t have serial transfer ability any more so I tried an old legacy kernel build of Armbian. There was no boot delay so I couldn’t get in to U-Boot.
Frustrated, I just dumped the new build of U-boot back on again. Everything is incompatible so it complains about the partition map, but that’s of little concern because I’m only using U-Boot which isn’t on a partition.
After trying and failing to set up NFS booting, I got tftp booting working. So it now boots from my fileserver, which also has that directory shared via NFS so I can drag’n’drop from RO. There are still some fiddly bits but it’s better than nothing.

I love you hardcore dedication to any problem you encounter, and always enjoying reading your progress updates, even though some of the more technical stuff is way over my head.

I dream of being a proper coder, but at some point in your life you gotta play to your actual strengths rather than your dreams.

As you were!

I’m not a proper coder, at least I haven’t been for a long time. I’m just stubborn.

A few minutes ago there was a moment of clarity with my current Hello, World! program. My remaining error is user error.

So, what I have is a simple program to display some characters and a string via UART sans OS. It hasn’t been working correctly and I couldn’t see why.

The reason being my string “Hello, World!” is being referenced as an absolute address from the literal pool. eg

 LDR R0, =HelloString

The thing is I wrote the code to be position independent. Code dumps didn’t make the problem obvious because the program started at 0×00000000 so nothing looked out of place in the code.

I’m forcing myself to learn ARM ASM properly so I can do a little more than I can with other languages. Like a HAL for RO. What stopped me dead with my C based HAL was irreconcilable linker issues. Everything would build fine, but the branches weren’t lining up to their intended landing points.

obvious because the program started at 0×00000000 so nothing looked out of place in the code.

The Orange Pi is using high vectors? What handles vectors? Does U-Boot set up any default handlers, and do they use space around the first bit of memory?

Also, what is R13 set to? Does U-Boot set the stack pointer to a sensible initial value, or is that something the OS needs to do for itself?

Rick, I should have explained myself a little better.
I’m being a cheaty cheat and loading my binaries to 0×4100 0000. I think uImages are loaded to 0×4200 0000 or something like that. I’m not totally sure of the reason for loading at 0×4100 0000 but it seems to be the done thing. Not sure if it was just my code but it seemed like things break at 0×42...

The Orange Pi is using high vectors? What handles vectors?

Good question. I need to review but I believe the U-Boot vectors are in the first block of SRAM at 0×0000 0000 I don’t advise trying to put a stack there for a simple program.

Resources for the H3 are kind of scattered but they are around. I found Tom’s Electronics Pages a couple of days ago which have been a big help.
Other than that, the Orange Pi / Xunlong Wiki and the U-Boot source have been a help. I can’t really remember where I read the details.

U-boot does have SP set. As far as I know we can use that stack. I’ve switched to my own and it doesn’t seem to make much difference. It seems to hold the start address of the loaded program in R5. Not sure what the others are atm but I believe they can give access to some environment settings, and args passed by a boot script.

It’s totally possible to go lower level without using U-boot. Easiest way is to plug a cable into it’s USB OTG cable and use a special disk image which just forces the ROM into FEL mode so a binary can be loaded directly via USB. Of course this means the binary needs an awful lot more prep so the system is in a sane condition. But it does seem pretty versatile.

Tristan – do you have JTAG in order to observe what the actual processor state is?

Unfortunately not. Although I’m not sure, I believe a SEGGER JTAG would work.

The information I have gleaned is from when I accidentally cause a crash, and U-boot jumps back in with a register dump.

I’m just going to dump some useful (to me) links here. They are as much for myself as anyone else.

GitHub of Orange Pi bare metal programs

Building a custom Linux kernel I used this for building and installing U-Boot

Just some useful U-Boot environment variables

Sunxi tools main page Worth noting is in the source there is a file called uart0-helloworld-sdboot.c which is an example for detecting hardware, and also running a program without U-Boot.

FEL boot over USB

I also want to add I was wrong about the vector table I think. Not 100% though. Checking the platform specific U-Boot source code is probably the best way to do it.

Well, I spent some time today on fiddling with the Orange Pi PC. I’m working on something approximating a proper HAL using what I’ll call an iterative approach. Barest minimum code necessary to call OS_InitARM, OS_AddRAM, and OS_Start and have the whole thing build.
It runs fine up to OS_Start, where I usually just have it in a loop beforehand where it prints “Done!” to UART0 on a new line, has a short delay and repeats.

I’m chugging away slowly with this. Every change I make sure it can still build. I just finished the header for the UART and a stubbed implementation. Pulled the null entries and connected the HAL entries.

I haven’t added the ability to relocate the ROM yet. It’s going to live at 0×41000000 for a while yet.

What I find surprising is it’s really a very easy SoC to fiddle with. I’ve been meaning to work out whether the OPi PC2 is running a 32 or 64 bit bootloader. I read something odd that the H64 defaults to 32 bit mode. The H5 is somewhat of a mutant. It reminds me of one of those Pentium upgrade chips for a 486. It’s an A64 (IIRC) CPU shoved into the H3 (Cortex A7) SoC. I believe the GPU saw upgrading from a Mali400 to a Mali450, but I’ve never had a chance to see that in action because the legacy Linux kernel is so bad. So who really cares.

Just a random thought. 30 years ago U-Boot would be considered an OS. I’ve used worse.