Orange Pi
183 posts, 15 voices
Tristan M. (2946)
1039 posts
|
I haven’t had much time to look at this recently. It’s not stalled or in the “Too hard” basket. Today besides shifting my source tree in a way that will probably bite me later I found out about a useful tool in linux that I didn’t know about. readelf. When I can work out these issues it should be pretty straightforward. My ld version looks good in disassembly. Things are more or less in the right order and everything is linking well. Generally what I write for it works. There are exceptions. Hdr:System and Hdr:Proc cause macro errors. I can’t go much further without them I think? |
|
Tristan M. (2946)
1039 posts
|
Last night I had an idea. A fresh copy of the RPi source got downloaded and checked for sanity. It then had the minor changes to my OPi makefile applied to it. To avoid confusion, I have been working with a stripped down OMAP3 source tree. The BCM2835 tree is a part of a larger idea. I’m going to apply some of the concepts of what I have been doing to the BCM tree to ensure they function on a known good system. Doing this has already paid off it would seem.
|
Colin Ferris (399)
1814 posts
|
If you are having problems with ‘AsAsm’ – perhaps you could do a quick change/test with the ROOL/Acorn version. Or perhaps you could have a word about ‘AsAsm’ with one of the maintainers – ‘The one in a Comfy Chair’ |
|
Tristan M. (2946)
1039 posts
|
Way ahead of you with asm substitution. It goes down in flames at link time because ld doesn’t recognise the object format of the DDE assembler. I’m sure it can be converted or whatever, but I don’t know how to do that yet. Right now I’m suffering from my code looking like Someone Else’s Code because I’ve been away from it for a few weeks. I need to work out how the linking stage of my makefile works again because I need to disable the ld version of the output so I can see if the Link version can be seen through to completion with DDE assembler. The current version of asasm has broken vfp support, or at least the flag for it. It’s a known issue. I followed the workaround of grabbing a copy from GCC4.1.?. If I can get the broken System.Hdr to work even if it means using the DDE assembler (Doesn’t OMAP4 use asasm?) I think I might change my approach a little. I’m thinking if I can work past this Hdr issue I might plop what little HAL I have into an RPi build tree and start wholesale gutting and rewriting the sections to remove the concessions for VC and altered memory map. It’s really not a lot of work to shift trees. Just about all I’ve done is trying to piece together a method that allows development that also utilises GCC. It pretty much works. What I’ve done assembles / compiles and links into something which I can manually load with u-boot and see running. |
|
Tristan M. (2946)
1039 posts
|
Way ahead of you with asm substitution. It goes down in flames at link time because ld doesn’t recognise the object format of the DDE assembler. I’m sure it can be converted or whatever, but I don’t know how to do that yet. Right now I’m suffering from my code looking like Someone Else’s Code because I’ve been away from it for a few weeks. I need to work out how the linking stage of my makefile works again because I need to disable the ld version of the output so I can see if the Link version can be seen through to completion with DDE assembler. The current version of asasm has broken vfp support, or at least the flag for it. It’s a known issue. I followed the workaround of grabbing a copy from GCC4.1.?. If I can get the broken System.Hdr to work even if it means using the DDE assembler (Doesn’t OMAP4 use asasm?) I think I might change my approach a little. I’m thinking if I can work past this Hdr issue I might plop what little HAL I have into an RPi build tree and start wholesale gutting and rewriting the sections to remove the concessions for VC and altered memory map. It’s really not a lot of work to shift trees. Just about all I’ve done is trying to piece together a method that allows development that also utilises GCC. It pretty much works. What I’ve done assembles / compiles and links into something which I can manually load with u-boot and see running. |
Jeffrey Lee (213)
6048 posts
|
SCSI::FC_USB.$.RODev.BCM2835Dev.Export.APCS-32.Hdr.Global.CPU.Generic32:907:39: Error: Skipping extra characters '$mode, $regtmp, $oldpsr' That will be a bug/limitation in asasm. It looks like it’s upset because the macro definitions have a parameter (“$op”) that’s a suffix on the macro name/mnemonic – objasm supports this but I guess asasm doesn’t. If you’re only seeing that error now then I guess you must have been using some pretty old code before (those macros went in over a year ago) – or maybe it’s a side-effect of using the older asasm? SCSI::FC_USB.$.RODev.BCM2835Dev.mixed.RiscOS.Sources.HAL.BCM2835.hdr.BCM2835:34:10: Fatal error: Illegal expression
called from line 35 from file SCSI::FC_USB.$.RODev.BCM2835Dev.mixed.RiscOS.Sources.HAL.BCM2835.s.Touch
[ :LNOT :DEF: BCM2835_Hdr
----------^
This one’s a mistake in the OS sources, it should be
No. Possibly it’s one of the platforms that asasm was tested with many years ago. Currently I don’t think we have anything in CVS which uses asasm (we used to use it with some of the GCC-built apps, but the bug with being unable to specify the floating point ABI meant that when I recently upgraded everything to GCC 4.7.4r3 I ended up either converting any assembler bits to C or converting to gas syntax)
By “decent amount in common” do you mean that they look like each other and contain a Cortex-A53 CPU? Because as far as the HAL is concerned that’s diddly-squat. I’d wager that for any HAL, no more than 5% of the code is concerned with the CPU. The vast majority of the code will relate to the other components of the SoC / system – basic bootstrapping, physical memory map, interrupt handling, custom drivers (timers, UART, I2C, RTC, GPIO, audio), and light/medium-weight HAL devices for standardised peripherals (USB, SD, SATA, etc.) Compared to the OMAP4 HAL, I’d say that switching to the Pi HAL would represent a step backwards, precisely because the Pi is such a weird system.
|
Rick Murray (539)
13840 posts
|
When he says “most platforms”, he means practically everything on earth made in recent years. I’m actually really surprised the non-rubbish ☺ Pi serial port isn’t Yet Another 16550 Clone. ARM documents this somewhat amusingly:
My emphasis. I mean – WTF? That’s like saying “The Z80 varies from the 6502 as follows: Everything is different.” Duh! |
|
Tristan M. (2946)
1039 posts
|
The Pi UART is horrible. End of story. No wait. There’s a sequel calld the USB controller.
Not that old. Remember I’m being stupid and tackling two things at once. Utilising GCC and porting. Getting things working a piece at a time. It’s not so much getting the hardware working as making thi work in the build system. Building the HAL on a PC with dummy stubs on the RO build so a pre compiled HAL (That’d be a blob, wouldn’t it?) could be used would almost be easier, but I want to make a solution where it can be built 100% on an RO machine. That presented it’s own unique challenges like not all compiler flag I needed work in !GCC, so I’ve spent many, many hours looking at disassemblies and tweaking just so the resultant binary is linked in a way that will actually work. Fair enough wth the BCMnnnn chipset. Lucky I didn’t really pursue it. stll, OMAPn is really different on a low level to the AllWinner chips. Enough that in pretty much every case I’e scrapped the OMAP code completely bec’s just way too diferent. I do belive however I will steal its UART asm at least for now. Mine is in C but way less complete. For the most part the OMAP implementation is similar enough to be used. Raising the noob white flag again on it though. I don’t understand how the UART hardware base address is set up on the OMAP UART.s Again USBBB on Pi is awful. 3 Pis, multiple keboards, cables, power upplies and it still skips characters or repeats randomly or just loses the devices. |
|
Rick Murray (539)
13840 posts
|
Aaaaand… That’s why we have a HAL. Unlike the PC world where there is some basic consistency at boot time, the ARM SoCs just… Aren’t. I believe one of Linus’s shouty rants is about exactly this. So every supported ARM board needs its own build of RISC OS tailored to the system in question… |
|
Rick Murray (539)
13840 posts
|
As for the UARTs, at a guess I’d say &4806A000 for UART1 and &4806C000 for UART2. These may well be physical addresses, not logical. |
|
Tristan M. (2946)
1039 posts
|
Well, now I knowwhat I read about the OMAP builds and asasm is osolete it’s made things a little easier for me. I’m not chasng ghoss any more. I justquckly commented out the GNU ld stuf from my makfile, changed from using asasm, uncommented the hds which were breaking the buld and my progress worked. OMG I ant to throw the Pi in the bin. No time to edit all the keyboard error sory. |
|
Tristan M. (2946)
1039 posts
|
So after the last post I got pretty angry and went and got yet another mouse, keyboard and USB hub. So far, so good. I don’t recommend programming when peripherals misbehave like that. I have to replace the stupid things multiple times a year. I could have bought another Pi3 for less :( For now everything builds but I still have the annoying .bss alignment issue with one file. I need to try a few other methods to force it. While I’m asking, can DDE’s assembler do ELF format objects? The linker seems to support them. If it did, or if there is a way to convert to ELF it’d make my life easier because ld is very versatile and lets me give it linker scripts which are very helpful for organising the linked binary the way I want. Again just about out of time, but being able to input things correctly is a major bonus. Before anyone suggests it I just want to mention I tried multiple keyboards and mice with and without various hubs, powered and unpowered with different supplies. The keyboard which I am currently typing with is the same model as a previous one that started giving me grief. They all just seem to stop working properly on the Pis after a while. So strange… What I tried to say in the last post was that I removed the GNU tool chain things from my makefile except for GCC, and used the DDE linker. I no longer get the macro errors because the DDE assembler supports them of course. This gets me past a wall that has halted progress for a while now. Thanks, Jeffrey and Rick for keeping me on the right track! Hopefully now I can push forward and make some useful progress. Apparently I’ve developed a phobia of the backspace key in the process. It is the worst key to go into repeat mode when coding. |
Chris Mahoney (1684)
2165 posts
|
I beg to differ. I had ^K get stuck once, but fortunately I was able to stop it before it systematically deleted too many files… |
Steve Pampling (1551)
8170 posts
|
That’s where Fred’s Transient and TrapDelete are absolutely the thing to have running. What it means is that “Del” just moves things onto the Transient directory for later clearance and “Shift-Del” actually deletes permanently. Rather like other OS’s. |
|
Chris Mahoney (1684)
2165 posts
|
I’ve installed Transient through PackMan but can’t find a “TrapDelete”; is it an option somewhere in Transient or a separate app? |
|
Jeffrey Lee (213)
6048 posts
|
There are a few hoops it jumps through in order to get the address. As Rick pointed out, the (physical) addresses of the UARTs are defined in a header like this (L4_UART1, etc.). The HAL workspace contains a board config struct which stores these addresses, and is how the UART code will find them; initially they’ll be physical addresses (to allow for debug output pre-MMU) but then later on they’ll get translated to logical. But if you search for L4_UART1 you won’t find any reference to it – that’s because the board config structure is actually initialised using a big ugly macro that fills in the addresses according to the contents of a string. This makes it easier to describe (some of) the differences between the different boards that the HALs support. For OMAP4 there are only a couple of different boards which are supported (see the bottom of that file), but for OMAP3 there are six different boards supported, so being able to describe at least some of the properties in a concise way is very useful (unfortunately the code is still littered with little bits of logic along the lines of “if this board, do this” – e.g. you’ll notice that there’s no differentiation in the board config listing for BeagleBoard vs BB-xM or PandaBoard vs. PB ES)
I don’t believe it supports ELF output, but I haven’t checked. |
Fred Graute (114)
645 posts
|
The regular release of Transient has no support for my TrapDelete module. You’ll need to download the test release of Transient + TrapDelete from my website. |
|
Chris Mahoney (1684)
2165 posts
|
Thanks. I must be blind; I definitely looked there! |
|
Steve Pampling (1551)
8170 posts
|
It may not have been there when you looked. I’m not sure how many people have had access to the “alpha” release. |
|
Fred Graute (114)
645 posts
|
Steve’s right, it wasn’t there when you looked. As he keeps pushing me to make it more visible I decided to add it to the software available from my website. ;-)
It’s unlikely to continue in its current form. Although AppBasic is fine for the interface, the restore ‘database’ and BASIC aren’t a good match. It works but it’s rather cumbersome. What is really required is to rewrite Transient in a language that supports more advanced data structures. I’m considering to create AppLua, which will be similar to AppBasic but based on (Risc)Lua. |
|
Tristan M. (2946)
1039 posts
|
I like the sound of that. Tonight I managed to get a little time to work on it. Almost all the time was spent searching for the definition of RISCOS_AddRAM. Only when my time was up I realised why. Because the name is irrelevent. It slipped my mind that it’s an entry point to RISC OS. Trying to make headway with this is like wading through treacle. The AllWinner SoCs seem really simple to work with compared to the rather complex OMAPs and the weird Broadcom chipsets, but learning the nuts and bolts of how RISC OS is put together is no small task. If / when I can get the code into a less embarrassing state it’ll probably go up on GitHub or something. |
|
Steve Pampling (1551)
8170 posts
|
Two of the old interview questions were: “what do you consider to be your strongest trait?” and “what do you consider to be your main weakness?” |
|
Chris Mahoney (1684)
2165 posts
|
That would explain it! Meanwhile, Steve’s second post explains why I found it vaguely familiar… |
|
Tristan M. (2946)
1039 posts
|
Always learning. If anyone is wondering, no. There’s no magic involved. I have no idea if it’s even possible to do CallOSM OS_AddRAM from C. I’m just using an assembly routine. The way I’m writing this… If I were me I wouldn’t do it the way I am. Or rather trying to write this HAL port I can see much better ways of organising everything. Perhaps after it’s able to boot successfully it’ll get rearranged. e: Got all that sorted. Back to good old user error now.
I can live with this. It was expected. Also I just learned that I can highlight a block of text in StrongEd and just drag it on to the reply box instead of copy pasting. That’s really useful. |
|
Rick Murray (539)
13840 posts
|
Hard coded #define values have no type. They are not even seen by the compiler. The preprocessor will replace occurrences of the name with the value given, so if you have: #define MEH 1234 unsigned long myval = MEH + MEH; the compiler will see: unsigned long myval = 1234 + 1234; The compiler will take standard type rules for integer literals/constants, namely the value will be assumed to be the first type in which the number will fit; decimal integers are signed, hex ones are unsigned. 1234 will therefore be considered a signed int, calculated as such, and then cast to unsigned long for assignment to the variable. As such, you might prefer to force the type by implied casting: #define MEH 1234ul or: #define MEH ((unsigned long)1234) or, of course, force casting at the point where the defined values are used: unsigned long myval = (unsigned long)MEH + (unsigned long)MEH; |
