The current build from CVS boots to a * prompt on a DevKit8000

The current version in CVS will boot to a star prompt on the serial port when booted by a DevKit8000. This is an improvement on the previous behaviours where it would hang in init_ram or thereabouts.

No video on either the DVI or LCD, and no USB. I will move my attention from looking at the RAM init problem to looking at the video and usb differences between the two boards.

DevKit8000 is quite like a BeagleBoard but with a Network interface, and in my case I have the optional touch LCD.

My Rev C beagle board and my DevKit8000 are shown side by side here: http://earlthecamel.com/beagleboard/IMG_1142.JPG

General info on the Devkit8000 is here http://www.embedinfo.com/English/Product/devkit8000.asp

I have noticed that the NAND interface is not quite the same between the two, DevKit8000 has the NIC chip and the NAND on the GPMC port, and also neither the RAM or the FLASH are P.O.P.

I would like to get the NAND under control, this might be handy for some eeprom emulation, but also because I want to be able to use RISC OS extension rom formatted images in NAND after the main RISC OS image to support heavily GPL encumbered code. Which for the DevKit means the DM9000 ethernet driver from U-boot.

I am just going to have a go at the NAND code in an assembler module for now, but it strikes me that it may be a candidate for the HAL if a number of different connection schemes and chips are found in the OMAP devices RISC OS ports to.

Alan

PS I haven’t written ARM assembler in ten years or more, and have gained a wife, a house to renovate and a baby to program since then, so progress may not be staggeringly brisk.

The current version in CVS will boot to a star prompt on the serial port when booted by a DevKit8000. This is an improvement on the previous behaviours where it would hang in init_ram or thereabouts.

That’s interesting, since I don’t think I’ve changed anything that could have fixed a hang in init_ram :)

Is there any kind of technical documentation available for the DevKit8000? It would be good to know the precise differences between that and the beagleboard. After a quick skim through I’m sure I’d be able to spot any bits that will require changes to the OS source to work properly (e.g. they could easily be using a different GPIO pin to control power to their DVI framer chip)

Regarding video – it could either be broken because of a differing GPIO config, or it could be the mysterious bug that only allows video to work if we boot RISC OS via u-boot (Does the DevKit8000 version display a splash screen?)

Also for the LCD output, we’d need some fairly significant changes to the video driver (mostly in the realm of using the hardware scaling to adapt whatever video mode RISC OS uses to the native resolution of the LCD, and making sure that the driver always uses the correct timings for the LCD)

I am just going to have a go at the NAND code in an assembler module for now, but it strikes me that it may be a candidate for the HAL if a number of different connection schemes and chips are found in the OMAP devices RISC OS ports to.

Getting NAND working would be fantastic.

I’m still not sure how we’re going to handle different OMAP3 boards (e.g. whether we’ll need seperate HAL/ROM images or whether it’s possible to detect the board variant automatically), but I believe that at least for individual boards it’s possible to probe the GPMC bus for the location of NAND. Although the physical location of NAND differ between the beagleboard and DevKit8000, it’s still connected via the GPMC bus, so there shouldn’t be any major problems with writing a driver that will work with both boards (and for the Pandora, Touch Book, etc.)

For the actual HAL interface, I guess there would be two APIs needed:

1. The HAL NVRAM API. I’m still not sure if we’d want CMOS RAM/NVRAM to always be located in NAND (it could cause issues with people looking to dual-boot with Linux on devices like the Pandora/Touch Book where the manufacturer’s Linux distribution may assume a certain NAND partitioning), but implementing the NVRAM API is probably a good starting point to test out the NAND driver. I haven’t looked at it in too much detail, but I believe it should also be possible to do it using an incremental log based system to avoid wearing out the hardware by performing erase cycles for every CMOS write operation.
2. A new HAL device for NAND devices (which could later be expanded to support other types of flash memory). The API would provide simple block level access, then we’d leave it to RISC OS to decide which bits are to be used for what (file systems, extension ROMs, etc.) – or possibly with the help of a HAL-supplied partition table (which would also be useful for telling RISC OS not to overwrite x-loader/u-boot!)

Good luck!

Sorry I haven’t worked out how to quote here yet…

I haven’t seen any concise doco on DevKit8000, I am going on diffs between the U-boot sources for each board as the primary clues as to what is different.

In earlier versions the DevKit would hang at the end of the numbers that the hal emits during boot and never get to the letters.

I agree that NAND is probably not ideal for NVRAM emulation, and I am only thinking of using since there is nothing else on the board. I think that we would want this to be flexible. The options U-boot has for where it stores its environment are extensive to say the least.

For a moment or two I considered packing the RISC OS eeprom data into a string and storing this in U-boots environment. No conflicts then. But if U-boot is not present then that doesn’t work, so I went away from that idea.

I was thinking along similar lines that a new copy of the emulated eeprom would be written out each time and only when a page full had been written would I do a page erase cycle.

I haven’t read the flash memory data sheet enough times yet to be sure that is a workable strategy.

I agree that only the low level ops should be in the HAL, I would like to have some basic operations available from the CLI such as erase and copy from disk. Similar to those of the U-boot ‘nand’ command. These should be a module that doesn’t have to know the exact NAND architecture if the HAL can present the variations in a uniform fashion.

Alan

I have had a close look at a couple of key files in U-boot and isolated the following
interesting differences between the beagle board and the DevKit8000.

(Source tar file is open in Sparkfs, so RISCOS namespace) 
devkit8000source.u-boot-1/3/3/tar.u-boot-1/3/3.board.omap3devkit8000.omap3devkit8000/c
devkit8000source.u-boot-1/3/3/tar.u-boot-1/3/3.board.omap3530beagle.omap3530beagle/c

         unsigned char byte;
This is present only for the DevKit8000
        /*enable dvi output*/
        byte = 0x80;
        i2c_write(0x49, 0x9B, 1, &byte, 1);
        i2c_write(0x49, 0x9E, 1, &byte, 1);

This is commented out on the DevKit8000
    /*audio_init();*/

This is present only for the DevKit8000
    MUX_VAL(CP(ETK_D12_ES2),    (IEN  | PTU | EN  | M4)) /*GPIO_26*/\

I have been unable to clarify from the cct diagram exactly what this pin is doing.

  U-boot declares 
  int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len);
  Read/Write interface:
    chip:    I2C chip address, range 0..127
    addr:    Memory (register) address within the chip
    alen:    Number of bytes to use for addr (typically 1, 2 for larger
               memories, 0 for register type devices with only one
               register)
    buffer:  Where to read/write the data
    len:     How many bytes to read/write

    Returns: 0 on success, not 0 on failure

Looking at the hal rtc file RiscOS.Source.HAL.OMAP3.s.RTC I speculated that the 
following code might be equivalent.  I am unclear what the v1 and v2 parameters 
to TPSWrite are.

        MOV     a3, #&80
        STR     a3, [sp]
        MOV     a1, #&49*2
        MOV     a4, #&9B
        MOV     a2, sp
        MOV     a3, #1

        BL      TPSWrite

        MOV     a3, #&80
        STR     a3, [sp]
        MOV     a1, #&49*2
        MOV     a4, #&9E
        MOV     a2, sp
        MOV     a3, #1

        BL      TPSWrite

But I failed to drop this into RiscOS.Source.HAL.OMAP3.s.Video as TPSWrite isn't 
exported from s.RTC, and I have run out of time today.

Alan

Sorry I haven’t worked out how to quote here yet…

Prefix the line with “bq.” and it should work :)

For a moment or two I considered packing the RISC OS eeprom data into a string and storing this in U-boots environment. No conflicts then. But if U-boot is not present then that doesn’t work, so I went away from that idea.

One of the good things about the uImage format that u-boot uses is that you can specify the entry point. So we could easily have one entry point for booting via u-boot, which would make use of the kernel boot args that u-boot provides, and another entry point for raw booting without u-boot (which would either have to try auto-detecting features or rely on fixed defaults).

Looking at the hal rtc file RiscOS.Source.HAL.OMAP3.s.RTC I speculated that the following code might be equivalent.

You’re certainly right about that – I2C addresses 48-4b are occupied by the TWL/TPS chip (although I suspect the TPSRead/TPSWrite functions are generic enough to be usable for other chips as well). By checking the TPS manual (available here) I can see that it’s configuiring GPIO7 of the TPS for output and setting the output value to 1. That pin doesn’t seem to be used for anything on the beagleboard, so there shouldn’t be any harm to run the same initialisation code on both the beagleboard & DevKit8000.

I am unclear what the v1 and v2 parameters to TPSWrite are.

v1 is a pointer to the function to use for performing the I2C transfer – in the RTC code this was a pointer supplied by the OS, but for general use you should be able to use RISCOS_IICOpV as the parameters are the same (well, kinda: v2 was a parameter to pass to the I2C function to help it identify the request. But RISCOS_IICOpV doesn’t need anything passing in a3, so you don’t have to worry about setting v2 to anything)

“LDR v1, OSentries+4*OS_IICOpV” should be all that’s needed to get a pointer to RISCOS_IICOpV.

So if you EXPORT TPSWrite from s.RTC (and IMPORT it in s.Video), and remember to SUB sp, sp, #4 before storing the &80 value on the stack (and remember to ADD sp, sp, #4 again once you’re finished!) then your code should work. The TPSRead/TPSWrite functions will probably be moved into their own file at some point in the future, since it looks like they will be needed for a lot more than just the RTC stuff.

Some information I’ve gleaned about the DevKit8000 from the PDF available on the website:

• It looks like they use I2C2 for EDID, whereas the beagleboard uses I2C3. This could be a bit of a nuisance if there’s no automatic way to differentiate between the board types. Also I say “looks like” because the block diagram only shows it going to the LCD header, not the HDMI connector – so it may be that I2C2 is used to control the LCD backlight or something (They have a T2C2046 chip on the board for the touchscreen, so I doubt the I2C bus would be used for that).
• They use a “SIP1504” chip for the USB Host PHY, but I can’t find any information about it via Google. How hard did you try to get USB working? Remember that if you are using the debug terminal then USB keyboard input won’t work (until you enter the WIMP, at least). If USB host definitely isn’t working then you may have to do some digging in Linux to find out how it’s configured (which would again cause problems with the beagleboard, since we can’t configure the OMAP for two different USB host modes at once!) However the good news is that once the correct initialisation code is in the kernel (and the OHCI module has been added to the ROM image, if necessary) it should “just work”.
• USB OTG support – it looks like it’s set up in the same way as the beagleboard (and 99% of other OMAP3 boards, I’d expect). Obviously there’s still not host-mode support in RISC OS for the OTG port, but if you connect the board to another computer in peripheral mode (using a male A to male Mini-B cable) then you’ll hopefully see a “RISC OS computer” appear. I don’t think this worked too well the last time I tried it in Windows, but it should work fine on RISC OS.

Ah, forget what I said about USB host – from looking at the eLinux wiki I can see it’s a ISP1504 transceiver. There are also some comments about USB host being broken due to a hardware bug, so it might be that it just doesn’t work at all.

However if it does work under Linux but not under RISC OS then you probably would have to do some digging; possibly it’s just a different GPIO pin that’s used to bring the transceiver out of reset, or possibly some different magic setup code is needed.

Now I have the RISC OS desktop on the DVI Port.

I added the code as mentioned previously but I am not sure that was the answer.

I realised that the SD card I was using to boot both the Beagle and DevKit8000 was built from the instructions here http://www.riscosopen.org/wiki/documentation/pages/Cortex-A8+port and contained the beagleboard’s version of U-boot.

So now I am booting the DevKit from the version of U-boot that shipped with it. It brings up their splash screen on the DVI port so I presume that RISC OS is inheriting the hardware all set up.

I have made some other observations about USB.

If I boot with the Beagleboard U-boot, with a usb hub attached to the mini USB port via the mini-usb to A-type socket lead that came with the devkit8000, I get lights on the hub. (This setup works with Angstrom, so the mini usb/OTG port will work in host mode with Linux. I don’t remember getting the type A host port to work under linux.)

But I don’t get any graphics so I can’t tell if it works under the desktop, no devices show up. Attached are a mouse, keyboard, and flash disk.

*usbdevices
No. Bus Dev Class Description
  1   1   1  9/ 0 EHCI root hub
  2   2   1  9/ 0 MUSBMHDRC root hub
*

I will start looking for differences in the USB interfaces next.

I have uploaded some of the contents of the CD which came with the devkit8000, its just the GPL source, Data sheets and circuit diagrams. http://earlthecamel.com/beagleboard/devkit8000/

It looks like both the LCD and the DVI port use the IIC2 bus, the touch screen seems to be on a SPI port.

Video_init
        Push    "v1,lr" 

;ajw trying this here:
;/*
; DevKit8000 requires this initialisation for the dvi interface according to U-boot
;  byte = 0x80;
;  i2c_write(0x49, 0x9B, 1, &byte, 1);
;  i2c_write(0x49, 0x9E, 1, &byte, 1);
;
;  U-boot declares
;  int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len);
; * Read/Write interface:
; *   chip:    I2C chip address, range 0..127
; *   addr:    Memory (register) address within the chip
; *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
; *              memories, 0 for register type devices with only one
; *              register)
; *   buffer:  Where to read/write the data
; *   len:     How many bytes to read/write
; *
; *   Returns: 0 on success, not 0 on failure
;
;*/

        SUB     sp, sp, #4 ; temp small buffer on stack

        MOV     a3, #&80
        STR     a3, [sp]
        MOV     a1, #&49*2
        MOV     a4, #&9B
        MOV     a2, sp
        MOV     a3, #1

        LDR    v1,OSentries+4*OS_IICOpV
        BL      TPSWrite

        MOV     a3, #&80
        STR     a3, [sp]
        MOV     a1, #&49*2
        MOV     a4, #&9E
        MOV     a2, sp
        MOV     a3, #1

        LDR    v1,OSentries+4*OS_IICOpV
        BL      TPSWrite

        ADD     sp, sp, #4

        ; omap_dss_probe()

Alan

Now I have the RISC OS desktop on the DVI Port.

Excellent!

As long as it’s working, I wouldn’t worry too much about why it works at this stage (unless you’re planning on running the ROM image without going through U-boot).

You’re right about RISC OS inheriting some of the hardware setup from U-boot. This isn’t really intentional, as I was initially hoping for a ROM image that could be booted directly by x-loader, but after I gave up trying to find the piece of code in U-boot that was allowing DVI output to work in RISC OS I also gave up testing of ROM images that were loaded by x-loader. In general RISC OS won’t assume that hardware is in a suitable state, but I wouldn’t be surprised if more code starts slipping into the ROM image that won’t work properly if the board isn’t booted via U-boot (Until we find a compelling reason to fix it all, of course!)

But I don’t get any graphics so I can’t tell if it works under the desktop, no devices show up. Attached are a mouse, keyboard, and flash disk.

I wouldn’t worry too much about the OTG port not working in host mode under RISC OS yet, since I haven’t finished the drivers ;)

But if you’re able to test the OTG port in peripheral mode while RISC OS is running then that would be great – chances are that if it works properly in peripheral mode (i.e. a ‘RISC OS computer’ appears when you connect the board to a host machine) then it will work properly in host mode once I finish the drivers (which hopefully won’t be too long now).

I have uploaded some of the contents of the CD which came with the devkit8000, its just the GPL source, Data sheets and circuit diagrams. http://earlthecamel.com/beagleboard/devkit8000/

Excellent! Those docs look like they’ll be very helful :)

Judging by the board schematic, it looks like that code you added to Video_init should be enough to turn on the DVI output. But I guess it doesn’t matter that much if U-boot is doing it for you now :)

You’re right about RISC OS inheriting some of the hardware setup from U-boot. This isn’t really intentional, as I was initially hoping for a ROM image that could be booted directly by x-loader, but after I gave up trying to find the piece of code in U-boot that was allowing DVI output to work in RISC OS I also gave up testing of ROM images that were loaded by x-loader. In general RISC OS won’t assume that hardware is in a suitable state, but I wouldn’t be surprised if more code starts slipping into the ROM image that won’t work properly if the board isn’t booted via U-boot (Until we find a compelling reason to fix it all, of course!)

Agreed, there is going to be quite a lot in the ‘come back later and fix it when we have more working’ category I suspect. Presently if the monitor is not plugged in at power up its never going to work. We are going to need to deal with monitors coming, going, changing and swapping between monitor/lcd/both for the more laptop-like devices. That’s while ignoring the svideo port.

But if you’re able to test the OTG port in peripheral mode while RISC OS is running then that would be great – chances are that if it works properly in peripheral mode (i.e. a ‘RISC OS computer’ appears when you connect the board to a host machine) then it will work properly in host mode once I finish the drivers (which hopefully won’t be too long now).

If I boot the DevKit8000 from its U-boot to the RISC OS desktop, and plug the OTG port into my PC laptop, nothing happens.

If I boot the DevKit8000 from the Beagleboard U-boot the PC says

“Found new hardware OMAP3430” and then a bit later “Found new hardware USB Device”

I am going to have a look at the source to the version of U-Boot the Beagleboard uses (U-Boot 2009.01-dirty (Feb 19 2009 – 12:23:21) and see how the usb init differs from the U-boot the DevKit uses (U-Boot 1.3.3-svn239 (Apr 17 2009 – 10:43:28)) Actually I might see if I can bring them both up-to-date first. The U-boot site lists u-boot-2009.08-rc2.tar.bz2 as the latest.

Alan

Alan, have you had a chance to do any work on the NAND drivers yet? I was thinking of looking at the NAND next, until I came back to this thread and saw that you were intending to look at it yourself.