Let's get started with a Pandora port

I think that RPCemu has some different format or something.

I’m pretty sure that’s not the case. However, what you haven’t supplied is any of the errors you’re seeing, which might give some clues. There might be some assumptions about disk geometry, which is causing the problem, or it might not be even recognized properly. But without the precise errors, it’s hard to know.

The only thing I can think, in case you’re unfamiliar with this, is to make sure you’re writing the image to (for example) /dev/sdb not /dev/sdb1. The latter is writing into a DOS partition, so the DOS partition table remains stuffed on the front.

Theo: i have tried both the device /dev/sdb and tried to partition the disk.. Maybe i have more luck when i use partman on a disk under RPCemu and then write that to a USB disk. Whatever the reason i am pretty sure the format differs.

regards,

Jan Rinze.

oh.. just for fun I have built RPCemu on the beagleboard. So now i can say i am the first to run RiscOS 4.39 on the beagleboard :-) RPCemu is dreadfully slow on the beagleboard but it works..

Whatever the reason i am pretty sure the format differs.

You are? Why? There’s simply no reason for RPCEmu to use anything other than a plain disk image. It doesn’t do anything sophisticated like QEmu and other emulators.

Maybe i have more luck when i use partman on a disk under RPCemu and then write that to a USB disk

Maybe, but if it really does differ, then that won’t help, will it? And presumably, you mean HForm?

USB update: I’ve now got a fairly solid idea of how USB works and what the USB OTG driver needs to do. I’ve produced a MUSBDriver module which interfaces with the main USBDriver and provides the software root hub implementation, i.e. the hub appears in the *usbdevices list. Although this is rather less exciting when you realise it’s just a cut-down version of the existing EHCIDriver/OHCIDriver code. Next step is to get it talking to the hardware and get it to detect simple events such as devices being connected/disconected – and then to write the whole heap of code needed to manage device pipes so data can be sent/received through the port.

Hi all,

I have received a USB disk formatted by SCSIform and I have to say that it has a very different format than RPCemu uses. Can’t really say what the differences are but i am looking into the matter.

For now i can say that i have a native riscos disk for my beagleboard and will take a look at a !boot sequence to see if it can run that. Next to that I have now a backup battery connected on the beagle board and see that cmos is not kept by the beagleboard. So maybe the people who do the coding for that can update their code en i will betatest their roms.

Best regards,

Jan Rinze.

Hi all,

since cmos RAM is not kept over a reboot, could someone please adapt the beagleboard RiscOS ROM to have a default setting of filingsystem=SCSI ? That way it will continue to boot to the desktop if there is a valid boot on the USB disk.

I thought of changing a byte in the ROM but i have no idea where in the ROM it is kept..

best regards,

Jan Rinze.

Warning: I’ve just been looking at EtherUSB again and have noticed a nasty bug which can stiff the machine. I’ll upload a new version sometime this week.

Does EtherUSB work? can I get a copy? The USB seems still very slow. Does it support EHCI yet?

You’d have some difficulty getting EtherUSB to work with the beagleboard at the moment since there are no networking modules included in the ROM image. But as far as I know it should work fine on any other machine that uses Castle’s USB stack (apart from the nasty bug James mentions above, unless he’s fixed it by now). You can grab a copy from James’s website here

Noone’s done anything to improve USB performance yet, which is probably why you haven’t noticed any speed gains. However it is on my list of things to look at, so assuming noone gets there before me I’ll eventually get round to doing it (i.e. sometime after I’ve got the USB OTG driver working). Hopefully improving USB performance will just be case of making the driver use DMA, although there’s also some filesystem code that needs looking at considering that it takes two minutes to mount an 8GB FileCore formatted SD card compared to just a second or two for FAT (This is true of both an Iyonix and the beagleboard).

EHCI is certainly supported by the beagleboard port of RISC OS - it’s the only operating mode that the OMAP’s USB host controller supports when used with the beagleboard’s hardware. The only known bug is that, for me at least, device insertion/removal detection seems rather flaky when you’re using a hub.

OK, I’ve uploaded EtherUSB 0.04 which fixed the above mentioned bug. I’ve also added the shell of Pegasus backend and have made it easier to prefix the raw ethernet packet with a small header before sending it to the device.

I’ve got a Pegasus device here and have had a brief play with it, though I didn’t really get anywhere. I won’t do any work on Pegasus if you’re interested and instead will have a look at some of the core bits of EtherUSB which never really got finished.

There is also a partial attempt at a CDC Ethernet backend which I started when I noticed thay my old NTL cable modem claimed to support it. It was not completed as it wouldn’t let me open one of the BULK endpoints.

It does work BTW, I’ve using it now, with an ASIX adapter.

Hi James,

any clue on which devices have this ASIX chip? I would like to test the EtherUSB :-)

best regards, Jan Rinze.

The OMAP ROM seems to be missing a lot of modules and so networking won’t be possible on the beagleboard.

the following modules are missing i.m.h.o.:

AUNMsgs BootNet DHCP DMAManager Freeway IIC Internet LanManFS MbufManager MimeMap Net NetFiler NetFS NetPrint NetStatus NetUtils Resolver ShareFS Squash

I could find Squash as a module in the CVS repository. The others I did not find. Any reason for excluding them?

Best regards,

Jan Rinze.

I could find Squash as a module in the CVS repository. The others I did not find. Any reason for excluding them?

Why would you expect to? The point of the sources is that they are sources – the modules are built from them. The only reason you see the squash module is that ROOL do not (IIRC) presently have permission to distribute the sources. I don’t know which other modules/binaries are in CVS (my source true is full of modules that have been built, so I can’t immediately see), but it would not be many.

Hi Peter, I expected that the ROM build for OMAP would have these modules included. The OMAP source tar.bz2 file does not include sources for these modules either. So I wonder if the modules fail to build for the OMAP or that there is another reason that they have been excluded for the OMAP ROM.

Jan, if it is just TCP/IP needed initially, I’ve have thought that DHCP, Internet, MbufManager, Resolver is all you need.

James, your EtherUSB does not recognize my CDC_Ether device. According to !USBinfo it is: Class 255 , SubClass 255, Protocol 255, Vendor ID “ALi Corp” 0×402 , Product ID 0×5632 , “USB 2.0 Data Link” Any idea if EtherUSB can be adapted/used for this device?

I expected that the ROM build for OMAP would have these modules included.

I did say in my previous post that the OMAP ROM doesn’t contain any networking modules yet!

The reason for this is simply that none of us (who are able to build OMAP ROMs) think that testing network functionality is a priority at this point. If I had a LAN adaptor that was supported by EtherUSB then I might have tried it and included the modules if they worked, but since I don’t I figured it would be better to leave it for now and work on something else. Especially since there are still numerous compatability issues that can/will prevent programs from running, so even if the networking modules worked there’d be no guarantee that any useful network programs would function.

I know you want to help out by testing ROMs, and I’ll be happy to help you with that later on, but at the moment I think that ROOL, Uwe Kalle, and any other owners of revision B boards would rather have me working on the USB OTG driver instead. So until someone who can compile the source code offers to help you I think you’ll be out of luck with most of your requests to add modules or functionality.

Sorry for the misunderstanding.

By no means I am trying to put any workload on you people. I was merely curious whether the modules were excluded because of problems. Not asking anyone to start working on anything.

It seriously bothers me that people here think that I am ordering them around. I am just looking at what is already here and trying to get a grasp on how everything hangs together. I hope to add something valuable once I have gotten familiar with all these sources and the way it is built. It is really complex from my perspective.

Regards,

Jan Rinze.

That’s OK - I think it’s just the impressive number of posts that you make that causes me to overreact a bit after a long day at work :)

I hope to add something valuable once I have gotten familiar with all these sources and the way it is built. It is really complex from my perspective.

The build system isn’t really too complex once you get to know it. Unfortunately the only real way to learn about it is to see !Builder in action.

As a brief rundown:

• There are the Products files in the Products folder in the root of CVS. These do nothing more than tell the CVS scripts what components & versions go into each product, so that if you use one of the CVS scripts to get the source from CVS you’ll have the right code that you need (particularly if some of the components need to come from a different branch)
• Then there’s the Components files in castle/BuildSys/Components, and the module database in castle/BuildSys/ModuleDB. Each components file tells !Builder what to build for each ROM image/disc image/etc., along with any extra parameters to pass to the makefile. The ’-type EXP’ parameter indicates that the component is required but it should not be built into the final image (e.g. it’s only needed for the header export stage in order to provide header files containing SWI numbers, APIs, etc.) The ModuleDB file converts the internal name as listed in the components file into a file path within the source tree, where the component should be installed in a disc image, the name of the module so that the ROM linker can find it, etc.
• It’s also important to note at this stage that in order for !Builder to function, the contents of the castle, gpl, netbsd, mixed, and cddl folders must be merged together (Which I’m presuming is a throwback to the time before ROOL when everything was in a private CVS and Castle didn’t have to worry too much about storing source code under different licenses in different locations)
• There are various build steps which !Builder allos you to select.
  • The header export stage copies any relevant C and assembler header files from each component into the RiscOS.Export folder, providing a central location for any components that need to know SWI numbers, APIs, etc. Some of these header files are programmatically generated (e.g. the C header file exported by RISC OS Lib/the Shared C Library that contains all the known SWI numbers). If you see an assembler file include something from Hdr:, then it will be including one of the files from RiscOS.Export. I believe the majority of the assembler headers get copied there from RiscOS.Sources.Programmer.HdrSrc, so if you’re looking for a particular file it might be worth looking there first.
  • The library export stage compiles and copies any staticly linked libraries (I think!)
  • The resources export stage generates all the files for the Resources filesystem and copies them to a staging area, ready for the ResourceFS module to build them into its image when it gets compiled
  • There are the ‘Make ROM’, ‘Install ROM’, and ‘Join ROM’ options which are used for building a ROM image once all the export stages have been done. Just don’t ask me what each individual step does because I haven’t worked that out yet ;)
  • Finally there’s an option for building a disc image, although you’ve got to make sure that you have the right components file selected for this, since there are seperate components files for building ROM images and building disc images. In the case of RISC OS, a disc image is just everything that you’d have installed on the hard disc by standard – the !Boot sequence and any bundled apps that were too big to fit in ROM.
• If you’re looking around in the source code for a component and trying to understand how the build system works then don’t pay any attention to the !MkDebug, etc. command files – those are only used if you want to build a component manually to make sure that it compiles OK, or to generate the human-readable debug symbols/map file (something that !Builder doesn’t seem to contain an option for at the moment). !Builder (or rather srcbuild, which !Builder is just a frontend for) calls the makefiles directly.

Hope that helps!

Hi Jeffrey,

Thanks for all that info!

One of the reasons I have suggested a irc channel is because many ‘newbies’ like me may ask a lot of silly questions. That way the forum will stay clean of those chat like question-and-answer stuff of people who need to catch up.

Best regards,

Jan Rinze.

The quick answer to a lot of those ‘silly’ questions is to read the documentation on our wiki… such as here

:)

I had some problems with the linux part of the ‘get the sources bring it to my old RPC and build it’ thread so Jan helped me and i updated the according parts in Jeffrey’s Cortex port documentation page . Maybe somebody could reread and comment?

Looks OK - although I’ve just tweaked it a bit by adding a link to Alex Waugh’s Sunfish and Moonfish which I use for running an NFS client & server on RISC OS. In my experience Sunfish works fine with reading/writing to files hosted by Ubuntu, so it might be worth giving that a go if you haven’t already. Sunfish also works OK with the Truegrid NFS server on Windows, except I often have to chmod the source tree to make sure Truegrid/Windows will let my Iyonix read/write the files after downloading them from CVS.

Also – does this mean you’re fully set up to compile the code now? :)