Genesi - EFIKA MX Smartbook

build the OMAP rom in RO4 emulated

Is this on your upgraded RiscPC? Anyway, good you’ve got it built.

not managed to turn off the align exceptions on the beagleboard

Funny – are you using this prog? AlignEx is probably the most convenient way. Also, if you’ve got a BeagleBoard running RISC OS, it may possibly be quicker to run the build on that.

First signs of running HAL on EfikaMX :

U-Boot# go 0×90100000

1. Starting application at 0×90100000 …
   EFIKAMX HAL init
   Board config=a

:D

So s.Debug works :)

Cool. Good to see that you’ve sorted out your toolchain problems.

Board config=a

I forced a crash here to make the output stop otherwise it prints trashed memory and loops.
Can someone here paste the first debug output from a beagle ?

From memory, the first couple of lines from a beagleboard should look like this:

OMAP3 HAL init
Board config=Beagleboard

I think the next output after that would only happen once RISC OS calls HAL_Init. But if your HAL is crashing at the “Board config=” bit then it points to a problem with the way the board config structure is being handled.

If you look at the foundconfig code in HAL.OMAP3.s.Top you’ll see that it expects v1 to contain a pointer to the board config struct, which it uses to get the board name (“Beagleboard”, etc.) And the value of v1 is calculated by the selectconfig code just above, which relies on the way the BL statements at HAL_Base have been set up – it uses the value of lr to work out which “BL selectconfig” line the ROM image was entered from, and from there uses that to select the right board config index.

So if you’ve done anything to change the way that code works then that might explain why it’s going wrong. Although to be honest I’m not sure why I’ve got that ENTRY directive just before selectconfig – maybe you (or the assembler/linker) stripped out the preceeding code by accident?

Also be wary of the fact that romlinker writes the size of the ROM image to offset 0×60 of the finished image. So make sure there isn’t any code or data at that address! I’m still not 100% sure why romlinker does this – the only piece of code I could find which relies on the ROM size being patched in that way was an old RiscPC-era test program. At some point I’ll try disabling that code in romlinker (or make it optional) and see if anything breaks.

And finally, if you’re only targeting the EFIKA MX at the moment then you can probably ignore most of the boardconfig code in the OMAP HAL, as you won’t have the same problem I have of having to support a large number of different hardware configurations. Ignoring the boardconfig stuff would also mean you won’t have to find your own solution to how to preserve the boardconfig struct across the call to RISCOS_Start (for the beagleboard I just store it in the 64K of on-chip SRAM, since RISC OS currently doesn’t touch that memory)

And finally, if you’re only targeting the EFIKA MX at the moment then you can probably ignore

I have two targets now , and 3 more to come this summer , so the selection code fits well.
I noticed this:
; r0=0
; r1=machine type ID
; r2=ptr to tag list (linux/include/asm/setup.h)

Where are those set ? I am running the HAL as a pure binary image, so no uImage stuff around it.
I have tried with setting r0 and r1 directly in the code and together with not doing the last two debug prints it gives me:

BBBBoooooaaaarrrrrdddd ccccooooonnnfffffiiiigggg===EEEEEEEfffffiiiiikkkaaaaaaMMMMXXXEEEEEEFFFFFIIIIIKKKKKAAAMMMMMMXXXX

:)

Right but wrong, the EfikaMX string is “correct” so I guess the selection worked.

Where are those set ? I am running the HAL as a pure binary image, so no uImage stuff around it.

Those are what u-boot passes to any uImage it starts. The OMAP ROM supports two different boot methods – the ‘direct boot’ via the selectconfig jump table at HAL_Base, or the uImage boot via an entry point at 0×64 (which branches to the selectconfig_linux code). The selectconfig_linux code only pays attention to R1, so you needn’t worry about setting anything else.

There’s a RISC OS port of mkimage on riscos.info. At some point I might have a go at integrating it into the build system, but for now it’s done as a seperate step by SDCreate, since it’s only the TouchBook that ‘needs’ things to be uImages.

I have fixed the serial output and I now works on the other HAL:s. I want to try to start the kernel and therefore I have tried to set up a haltable with just one HALEntry. However the HALEntry macro bombs on assert. OMAP has SDRC which the i.mx doesn’t. But for now , I skip most checks and just assume that our computers aren’t modified.

Latest serial output:

EFIKAMX HAL init
Board config=EfikaMX
Restart
SVC
Init ram
Copy complete !

A few things to bear in mind:

• The entries in the HALEntryTable need to all be in the right place. Use the list in hdr.HALEntries or on the wiki as a reference. I.e. the first entry must be HAL_Init, the next must be HAL_IRQEnable, etc. Also the HALEntry macro uses the function name to check against the hdr.HALEntries list, so if you’re using a nonstandard name (e.g. EFIKA_Init instead of HAL_Init) then the assert will fire because it won’t be able to find the EntryNo_EFIKA_Init definition.
• Having said that, you can get by with leaving a lot of the entries undefined, by using the NullEntry macro. Have a look at the first version of s.Boot in the OMAP HAL to see how much is/isn’t required.
• For the entries which can’t be left undefined (e.g. the video and keyboard scan ones), you can usually get by with simple generic stub functions. See s.Stubs for the stubs that were used in the first version of the OMAP HAL.
• You might not get very far if you haven’t written the IRQ or timer/counter code yet. But having said that, you can probably get by with some stub functions, as long as you make sure that all the interrupts are masked in the IRQ controller and you don’t make the kernel do anything that will cause it to wait for vsync (I may be wrong, but I think the kernel will fall back on using the 100Hz timer for a fake vsync if those stub video functions are used)

I am inside RISCOS_Start now , thats what I wanted to check , if memory allocation worked , and it seems like it does. Now off to write HAL_IRQ* ..

I get a crash in : Subtractv1v2fromRAMtable right in :
LDR v5, [a4]
SUB v8, a4, v5, LSL #3
10 TEQ v8, a4
MOVEQ pc, lr

Maybe I do something wrong before addram.

Is there anything more than having , startaddress in a2 and endaddress in a3 before calling OS_AddRAM ?

Is there anything more than having , startaddress in a2 and endaddress in a3 before calling OS_AddRAM ?

Any comments on this ?

Whoops, must have missed that question the first time round. Remember that you can always check the wiki, or the kernel sources, when trying to work out how things should work. For OS_AddRAM, the parameters are as follows:

• Flags (in a1). Unless the EFIKA has dedicated VRAM you can just leave the flags as 0.
• Start address (in a2)
• End address (in a3). Remember that the start/end pair are inclusive/exclusive.
• Significant address bits (in a4). This is used to mark any address lines which aren’t used for decoding the address. To be honst I’m not really sure that the OS does with this information, but it’s fairly safe to say that you can just set a4 to -1.
• Reference handle. Since the HAL interface is APCS compliant, and we’ve already used a1-a4, this parameter needs to be pushed onto the stack. It’s also the caller’s responsibility to reclaim that stack space after the call (although I’ve just spotted that the OMAP HAL currently doesn’t bother doing that. But since that part of the HAL doesn’t use the stack for anything else it doesn’t really matter.)
• For the first call to OS_AddRAM use a reference handle of 0. For subsequent calls, use the value that was returned by OS_AddRAM (It returns a new reference handle in a1). Also when you call OS_Start, make sure you pass the final reference handle in a4. Basically the OS uses the reference handle to build up a linked list of RAM blocks.

The final important thing to remember is the stack. Before the first call so OS_AddRAM you need to make sure you’ve got the stack pointer set up, either pointing to an area of RAM which RISC OS won’t be told about, or pointing to 4K within the first RAM block.

Ok , I think I have OS_AddRAM right .. so it has to be something else that is causing the crash in OS_Start mentioned above.

I will do som register dumps and see if I can find anything.

The first thing I like to commit is some more debug functions , that saves and restores the registers etc .. :)

Michael, for anyone¹ wanting to help with testing/debugging, would it be helpful if they were to purchase this debug board too?

¹ Note that I’m not offering to do so myself just yet.

If anyone was still interested in this hardware but didn’t want to spend too much just to experiment with it, you might be interested to know that NewIT has it on sale at the moment: EFIKA MX Smartbook 3G

The Linux distro supplied with it is ancient. I tried running Timothy’s Linux port of RISC OS on a later distro but didn’t get very far. Anyway, perhaps someone will try to start a new native port, or even continue an existing one with a spare machine. :-)

Hi

I am considering restarting this with the i.MX6 port as a base. They are quite similar when it comes to IPU and how things are organised.
I will try to get a datasheet on the LVDS controller.

But my top priority is RK3288 now. It can probably be used on RK3288 based chromebooks later on.

I’m not familiar with kernel programming but it seems that the FreeBSD kernel shares a fair amount of code between i.MX5 and i.MX6. I was able to boot a recent FreeBSD system on the Smartbook with only minor changes, so it sounds like you have a good plan. :-)