heyrick1973 -at- yahoo -dot- co -dot uk

You are not reading my b.log using HTTPS. You can switch to HTTPS by clicking here.


I have written a short program called "BeagLEDs" which is a RISC OS module for the Beagleboard (any type). It will flash the left user LED on and off second by second, and the right user LED according to filesystem activity.
Note, however, that as we hook into filesystem activity at a fairly high level, it will blink for Ramdisc and ResourceFS accesses just as for real storage.
The blinking is damped, so the indicator will flick on for at least 15cs. This is to minimise lag due to our activities.

You can download a copy of the module.

On the RISC OS Open forum, I said I'd give a run-down of how the module operates, so here it is.


Here's the pre-amble. Basically, after a version comment, I load in four macro files:

  • The first describes data storage in terms that I'm used to from BASIC (EQUD as opposed to DCD, or odd punctuation (=, %, etc)). One that is useful that you'll see here is EQUSZA which is a string, zero terminated, and aligned.
  • Next, generic SWI definitions, tweaked slightly so it has OS_Hardware...
  • Then, a bunch of macros supposed to be for pushing and pulling registers, exiting functions, and so on. I don't tend to use these as I'm used to STMFD R13!, {blah}, however I do use the SetV macro which is a little bit of code to set the V flag.
  • Debug was never used in the end, this ought to be removed in the next build.
The important macro definitions are given at the end, you can collect them all into one file and tweak the stuff below. The SWInames file should be present with your development environment. If you don't have this, you'll need to define the following SWIs: XOS_ReadSysInfo, XOS_Memory, XOS_Hardware, XOS_Module, XOS_Claim, and XOS_Release.

; BeagLEDs
; by Rick Murray
;   Version: 0.01
;   Date   : Monday, 24th May 2012
;   Started: Monday, 21st May 2012

; Our inclusions
        GET   ^.h.equx        ; EQUB, EQUD, EQUSZ, EQUSZA...
        GET   ^.h.SWINames    ; SWI definitions
        GET   ^.h.pushpull    ; Push, Pull, PushLR, PullLR, Return, PullRet...
        GET   ^.h.debug       ; DebugMsg (only used during actual debugging)


Now we define the module name, version, date, and copyright string. Doing it here saves having stuff scattered around the source.

; Version information


CODEDATE SETS "24 May 2012"   ; Date format MUST be "DD Mmm CCYY" for RISC OS to recognise it

CODECOPY SETS " 2012 Rick Murray"


Now follow a number of definitions. These are simply names, so using "TickerV" in the code will result in the assembler swapping in "&1C"; much like #define in C.

; File vector numbers
FileV           * &8
ArgsV           * &9
BGetV           * &A
BPutV           * &B
GBPBV           * &C
FindV           * &D
TickerV         * &1C

; LED mask - USERLED0 = GPIO #149; USERLED1 = GPIO #150.
USERLED0        * 1 << 21    ; User LED0 is for the ticker
USERLED1        * 1 << 22    ; User LED1 is for the fileops

TICKERLED       * USERLED0         ; therefore...

; GPIO5 base address held in code, <GPIO5_BASE>.

; GPIO-specific register offsets (from GPIO base)
GPIO_OE         * &34

; Our status array offsets
LED_TICKERCOUNT * 0          ; Counts down from 100 for timing of blinking LED
LED_FILEOPCOUNT * 4          ; Counts down from 15 for timing of file activity LED
LEDSTATE_TICKER * 8          ; Is '1' or '0' for state of blinking LED
LEDSTATE_FILEOP * 12         ; Is '1' or '0' for state of file activity LED
GPIO_ADDRESS    * 16         ; The mapped-in address of our GPIO

It is worth noting that the OS vectors can be looked up in the RISC OS PRM1; the two LEDs are documented in the Beagle technical guide; the GPIO stuff is from the DM3730 TRM (should be compatible with the earlier DM3530); and the array is ours.


Now for the assembly preamble. We define an area, and mark it as code. Then we tell the assembler where the code entry point is (though, in the context of a RISC OS module, this is defined by convention). We don't mark it as 32 bit as we pass this via the command line in the Makefile. Otherwise, add A32bit to the AREA definition.

; ===========
; Here we go!
; ===========

        AREA     |BeagLEDs$Code|, CODE



Now we define a standard RISC OS module. The start of the file is a header that contains information words and addresses. Refer to the PRMs if you need further details.

        ; Standard RISC OS module header
        EQUD     0                           ; no Start code
	EQUD	 (initialise - entrypoint)   ; Initialise code
	EQUD	 (finalise - entrypoint)     ; Finalise code
	EQUD	 0                           ; no Service call
	EQUD	 (titlestring - entrypoint)  ; Module title string
	EQUD	 (helpstring - entrypoint)   ; Module help string
        EQUD     0                           ; no help/command
	EQUD	 0                           ; no SWI chunk
	EQUD	 0                           ; no SWI handler code
	EQUD	 0                           ; no SWI decoding table
	EQUD	 0                           ; no SWI decoding code
	EQUD	 0                           ; no Messages file
	EQUD	 (thirtytwo - entrypoint)    ; 32bit flag word

        =        CODENAME, 0

        =        CODENAME, 9, CODEVERS, " (", CODEDATE, ") ", CODECOPY

        ; Bit zero set indicates this is a 32bit-compatible module...
        EQUD     1


A word of data holding the address of the GPIO5 register.

        EQUD     &49056000             ; location of GPIO5 registers


The module initialisation function. RISC OS on a Beagleboard is a HAL build of RISC OS (HAL means Hardware Abstraction Layer; as traditional RISC OS used to talk directly to the hardware and was, thus, rather tied to the Acorn chipset). So we look for a HAL version of RISC OS, then knowing we're on something that'll work, we can then ask the HAL directly if we are on a Beagleboard.

; =====================
; =====================

        ; We're in SVC mode, so preserve return address
        STR      R14, [R13, #-4]!

        ; First job - check what platform we're running on.
        ; We need a Platform class of 5 (HAL) at least.

        MOV      R0, #8
        SWI      XOS_ReadSysInfo
        BVS      not_a_beagle                ; code 8 failed? give up
        CMP      R0, #5
        BNE      not_a_beagle                ; not HAL version? give up

        ; Now ask the OS (via HAL) to confirm it is a Beagle.

        MOV      R0, #1024                   ; HALDeviceType_Comms
        ADD      R0, R0, #3                  ; HALDeviceComms_GPIO
        MOV      R1, #0                      ; is our first call (to enum)
        MOV      R8, #4
        SWI      XOS_Hardware                ; OS_Hardware 4 - enumerate devices
        BVS      not_a_beagle                ; fail? abort!

        CMP      R1, #-1                     ; no match?
        BEQ      not_a_beagle                ; abort if no match

        LDR      R0, [R2, #64]               ; boardtype is at offset +64
        CMP      R0, #0                      ; type 0 is Beagle
        BNE      not_a_beagle


The board type is at offset +64, and the board revision is at offset +68. As the Beagles have LED0 and LED1 on the same GPIO, we don't need to look to the revision. Any old Beagle will do.

Here are the currently defined board types and revisions:

00Beagleboard rev A or BUser LED0 on GPIO 149
User LED1 on GPIO 150
1Beagleboard rev C1, C2, or C3
2Beagleboard rev C4
3Beagleboard xM rev A
4Beagleboard xM rev B
5Beagleboard xM rev C
1n/aDevKit8000User LED0 on GPIO 186
User LED1 on GPIO 163
20IGEPv2 rev B or CUser LED0 on GPIO 26 (red, green=27)
User LED1 on GPIO 28 (red, green=complicated)
1IGEPv2 rev C (not compatible with B)
30RaspberryPi model AMoot point, RasberryPi
has no user LEDs onboard...
1RaspberryPi model B


Now we allocate space in the module area for our array (20 bytes) unless we are being re-entered due to *RMTidy or *RMReInit in which case we'll already have a memory block.

        ; Check we have no allocated space from RMTidy op / previous init
        LDR      R2, [R12]
        TEQ      R2, #0
        BNE      skip_mem_allocate

        ; Okay, so claim a cosy little spot in the RMA
        MOV      R0, #6
        MOV      R3, #20                     ; 20 bytes (count x2, tickstate, filestate,
        SWI      XOS_Module                  ;           and GPIO mapped address)
        LDRVS    PC, [R13], #4               ; bomb out if V set

        ; Okay, remember our workspace pointer
        STR      R2, [R12]                   ; R12 points to private word; store memblk
        MOV      R12, R2                     ; R12 now points directly to our memory
After the memory is allocated, we store the address to the word pointed to my R12. This word is our "private word", the address of which is passed to us in R12 on every module entry.
As R12 is the convention, we copy the address to R12...


The next task is to map GPIO5 into the logical memory map. We map it in permanently, to save on having to map/unmap each time we access the LEDs.


        ; Now map in GPIO5 (permanently)
        LDR      R0, =(1 << 17)              ; Page access privilege Read/Write
        ADD      R0, R0, #13                 ; OS_Memory 13, Map in I/O memory
        LDR      R1, GPIO5_BASE              ; Physical address
        MOV      R2, #256                    ; Map in 256 bytes
        SWI      XOS_Memory
        BVS      cant_map_memory             ; die if it didn't work
        STR      R3, [R12, #GPIO_ADDRESS]    ; remember logical address


As the LEDs are "on" when RISC OS starts, it might seem logical to assume they are set as outputs, but we force this just to be certain. Note the logic for handling the AND NOT, and that we keep a copy of the LED bitmask in R3 for later.

        ; Ensure the LEDs are "outputs"
        MOV      R0, R3                      ; copy address
        ADD      R0, R0, #GPIO_OE            ; add in offset to Output Enable register

        MOV      R3, #USERLED0               ; Make a bitmask of LEDs
        ADD      R3, R3, #USERLED1           ; (in R3, we'll need it later)
        MVN      R1, R3                      ; invert bitmask (into R1)

        LDR      R2, [R0]                    ; read in word
        AND      R2, R2, R1                  ; value = value AND NOT LED_bits
        STR      R2, [R0]                    ; write word back


Using the copy of R3 we retained (not the inverted one), we write this to the Clear Data Out register to force both LEDs off.

        ; Now force LEDs OFF
        LDR      R0, [R12, #GPIO_ADDRESS]    ; load address
        ADD      R0, R0, #GPIO_CLRDATAOUT    ; add in offset to Clear Data Output register

        STR      R3, [R0]                    ; write bitmask, turns off LEDs


Now the code to hook into the filesystem vectors. The code looks a little odd because if, for some reason, a vector claim fails, we must release claims made until that point (or it'll all go Bang!).

        ADR      R1, fileop_handler          ; generic handler for fileop vectors
        MOV      R2, R12                     ; pass workspace pointer when called

        MOV      R0, #FileV                  ; Claim FileV
        SWI      XOS_Claim
        BVS      release_none

        MOV      R0, #ArgsV                  ; Claim ArgsV
        SWI      XOS_Claim
        BVS      release_one

        MOV      R0, #BGetV                  ; Claim BGetV
        SWI      XOS_Claim
        BVS      release_two

        MOV      R0, #BPutV                  ; Claim BPutV
        SWI      XOS_Claim
        BVS      release_three

        MOV      R0, #GBPBV                  ; Claim GBPBV
        SWI      XOS_Claim
        BVS      release_four

        MOV      R0, #FindV                  ; Claim FindV
        SWI      XOS_Claim
        BVS      release_five

        ADR      R1, ticker_handler          ; ticker vector handler code
        MOV      R0, #TickerV                ; Claim TickerV
        SWI      XOS_Claim
        BVS      release_six


Our init is almost done. The final task is to set up the memory block. As the LED ticker counts down from 100, we initialise this to be 100. The other values initialise to be zero (fileop counter is zero, both LEDs flagged as off).

        ; Next, initialise our memory block
        MOV      R0, #100
        STR      R0, [R12, #LED_TICKERCOUNT] ; initialise to 100
        MOV      R0, #0
        STR      R0, [R12, #LED_FILEOPCOUNT]
        STR      R0, [R12, #LEDSTATE_TICKER]
        STR      R0, [R12, #LEDSTATE_FILEOP]

        ; Okay, we're done, let's go home...
        LDR      PC, [R13], #4


Here follows error message reporting, and tidying up from the vector claims.

; =====================================================
; =====================================================

        ; set up an error block to flag if we're NOT running on a Beagle.
        ADR      R0, not_a_beagle_error
        LDR      PC, [R13], #4               ; assumes LR previously stacked

        ; set up an error block to flag if OS_Memory for GPIO failed.
        ; RISC OS should release our memory claim for us.
        ADR      R0, cant_map_memory_error
        LDR      PC, [R13], #4               ; assumes LR previously stacked

        ; The releases fall through backwards to error report. If a release
        ; fails, it is not trapped or handled (because the module is about
        ; to die on startup, not a lot we can do except clap twice and pray).
        MOV      R0, #FindV
        SWI      XOS_Release
        MOV      R0, #GBPBV
        SWI      XOS_Release
        MOV      R0, #BPutV
        SWI      XOS_Release
        MOV      R0, #BGetV
        SWI      XOS_Release
        MOV      R0, #ArgsV
        SWI      XOS_Release
        MOV      R0, #FileV
        SWI      XOS_Release

        ; set up an error block to flag if any of the OS_Claims failed.
        ; RISC OS should release our memory claim for us, and we don't
        ; need to release the GPIO mapping (as it is permanent) and we
        ; have been called AFTER previously OS_Claimed vectors (if any)
        ; have already been released.
        ADR      R0, cant_claim_vectors_error
        LDR      PC, [R13], #4               ; assumes LR previously stacked

; Error block messages for the above
; Is the error number (currently "123") relevant? If the module can't
; start, it can't start, and there isn't a hell of a lot the end user
; can do to rectify things, so nothing really needs to know an actual
; error number, just that an error occurred...

        EQUD     123
        EQUSZA   "This module only works on a Beagleboard (original or xM)."

        EQUD     123
        EQUSZA   "Unable to map GPIO memory."

        EQUD     123
        EQUSZA   "Unable to claim necessary vectors."


This is the module finalisation routine. In a nutshell, we release the ticker, then the filesystem vectors, ensure both LEDs are off, then finally release our memory block.

The LDR of R12 from R12 is because R12 on entry is our private workspace word. So we load this into itself to turn it into a pointer to our array.

; ============
; ============

        ; Preserve return
        STR      R14, [R13, #-4]!

        ; Determine our true workspace address
        LDR      R12, [R12]

        ; Release ticker vector
        MOV      R0, #TickerV
        ADR      R1, ticker_handler
        MOV      R2, R12
        SWI      XOS_Release

        ; Release all FileOp vectors
        ADR      R1, fileop_handler
        MOV      R0, #FileV
        SWI      XOS_Release
        MOV      R0, #ArgsV
        SWI      XOS_Release
        MOV      R0, #BGetV
        SWI      XOS_Release
        MOV      R0, #BPutV
        SWI      XOS_Release
        MOV      R0, #GBPBV
        SWI      XOS_Release
        MOV      R0, #FindV
        SWI      XOS_Release

        ; Force the LEDs off

        MOV      R1, #USERLED0               ; Make a bitmask of LEDs
        ADD      R1, R1, #USERLED1
        LDR      R0, [R12, #GPIO_ADDRESS]    ; load address
        ADD      R0, R0, #GPIO_CLRDATAOUT    ; offset to Clear Data Output register
        STR      R1, [R0]                    ; write bitmask, turns off LEDs

        ; And now release the memory block
        MOV      R0, #7
        MOV      R2, R12
        SWI      XOS_Module

        ; That's it. Goodbye and thank you for watching.
        LDR      PC, [R13], #4


The commenting will guide you through the file op vector code. All you must remember at every point is all registers MUST be preserved (except our private R12) and we must be AS FAST AS POSSIBLE.
Note, also, that unlike module code, we specified for R12 to point directly to our array, so we don't need to do the LDR R12 from R12 thing.

; =====================
; =====================
        ; On entry, R12 is a pointer to our array, not our private workspace word.
        ; We are called upon FileV, ArgsV, BGetV, BPutV, GPBPV, and FindV. It is
        ; important to stress how IMPORTANT it is that we execute QUICKLY.
        ; Fastest case: LED is already on. Through in seven instructions.
        ; Otherwise, LED must be switched on. Through in fifteen instructions
        ; (two of which are conditionally not executed).

        ; Is the LED currently on?
        ; If it is, we can handle this and be out in seven instructions
        STR      R0, [R13, #-4]!             ; preserve R0

        MOV      R0, #15                     ; Set/reset ticker value
        STR      R0, [R12, #LED_FILEOPCOUNT]

        LDR      R0, [R12, #LEDSTATE_FILEOP] ; is LED already on?
        CMP      R0, #0                      ; is zero if off
        LDRNE    R0, [R13], #4               ; restore R0
        MOVNE    PC, R14                     ; done, get outta here

        ; The set/reset ticker value above is NOT conditional as ALL
        ; passes through this vector either reset the counter, or set
        ; it for the first time. In both cases, we want it set to its
        ; initial value.
        ; This means we can assume it done for below.

        ; At this point, we can assume LED is off, so switch it on.
        ; This adds a further eight instructions. We corrupt R12
        ; (our private word passed to us on entry) so we don't need
        ; to lose time stacking and restoring another register (which
        ; also means we lose two memory accesses).

        MOV      R0, #1                      ; flag LED is on (here, as
        STR      R0, [R12, #LEDSTATE_FILEOP] ; R12 corrupted below)

        MOV      R0, #FILEOPLED              ; set up for turning on LED
        LDR      R12, [R12, #GPIO_ADDRESS]   ; << this corrupts R12
        ADD      R12, R12, #GPIO_SETDATAOUT
        STR      R0, [R12]                   ; do it

        LDR      R0, [R13], #4               ; restore R0 (from above)
        MOV      PC, R14                     ; done


And here is the code for handling the ticker vector. It is a little more complicated, as the two LEDs can be in a variety of states: Off (disactivated), Counting (counting down to turn on or off), Switching (at zero, switching on or off). The ticker LED can switch on and off, the fileop LED can only switch off.

Here is a diagram of the ticker vector handler:

Ticker vector handler diagram

Note that we are entered in IRQ mode so we cannot call SWIs easily (we don't need to, but if you expand this code, keep this in mind).

; ==========================
; ==========================
        ; We're called a hundred times per second. We'll be in IRQ mode, so
        ; there's no option to call SWIs or such without a lot of faffing.
        ; Case table:
        ;           FileOpLED  Ticker     Instrs  CondNOP  Branches
        ; Quickest  Off        Counting   8       1        0
        ; Middle    Off        Switching  19      4        0
        ; Slow      Counting   Counting   12      0        2
        ; Slower    Switching  Counting   19      1        2
        ; Slowest   Switching  Switching  30      5        2
        ; Therefore, this routine takes from 8 to 30 instructions to
        ; execute.

        STMFD    R13!, {R0-R1, R14}          ; breathing room

        ; Check the FileOp LED
        LDR      R0, [R12, #LEDSTATE_FILEOP]
        CMP      R0, #0                      ; is it zero (off?)
        BLNE     ticker_handler_fileop

        ; Check the ticker LED
        LDR      R0, [R12, #LED_TICKERCOUNT] ; load ticker count value
        SUBS     R0, R0, #1                  ; -1 it
        STRNE    R0, [R12, #LED_TICKERCOUNT] ; if not zero, just write it back
        LDMNEFD  R13!, {R0-R1, PC}           ; and then leave

        ; still here? ticker is zero - so first reset it
        MOV      R0, #99
        STR      R0, [R12, #LED_TICKERCOUNT]

        ; now look to see what to do with the LED, we toggle
        LDR      R0, [R12, #LEDSTATE_TICKER]
        EORS     R0, R0, #1                  ; and update flags
        STR      R0, [R12, #LEDSTATE_TICKER]

        LDR      R1, [R12, #GPIO_ADDRESS]
        ADDEQ    R1, R1, #GPIO_CLRDATAOUT    ; if zero, select CLR register
        ADDNE    R1, R1, #GPIO_SETDATAOUT    ; else, select SET register
        MOV      R0, #TICKERLED              ; which LED
        STR      R0, [R1]                    ; write it

        LDMFD    R13!, {R0-R1, PC}           ; done

        LDR      R0, [R12, #LED_FILEOPCOUNT] ; load ticker count value
        SUBS     R0, R0, #1                  ; -1 it
        STR      R0, [R12, #LED_FILEOPCOUNT] ; write it back (even if zero)
        MOVNE    PC, R14                     ; branch back if non-zero

        ; still here? ticker is zero - so turn off LED
        MOV      R0, #0
        STR      R0, [R12, #LEDSTATE_FILEOP] ; set flag for LED off

        MOV      R0, #FILEOPLED              ; which LED
        LDR      R1, [R12, #GPIO_ADDRESS]
        ADD      R1, R1, #GPIO_CLRDATAOUT    ; CLR register
        STR      R0, [R1]                    ; write it

        MOV      PC, R14


All that remains is to embed a short message to pad out the file to be exactly 1024 bytes. No termination or alignment, as this is neither executed nor read, it's just something stuck at the end.

        EQUS     "Thanks to joe for the Beagle, Jeffrey for "
        EQUS     "s-video, and RISC OS for continuing.:)"

There you have it. ☺


Here, presented as one lump, should be all the macro definitions you'll need. Load this instead of the four GETs at the top, it should work.

; This should be enough to put into one header file to
; build BeagLEDs directly...

; EQUD <value>
        EQUD    $var
        DCD     $var

; EQUS "<value>"
        ; For 'EQUS "something", 13, 0'
        ; you will need use DCB directly.
        EQUS    $var
        DCB     "$var"

; EQUSZA "<value>"
        EQUSZA  $var
        DCB     "$var", 0

; SETV : Set oVerflow flag (on 26 or 32 bit)
$label  CMP      R0, #1<<31
        CMNVC    R0, #1<<31

; minimal SWI defs
; this is taken from the h.SWINames file supplied with the
; Norcroft/Acorn/Castle DDE examples; with the addition
; of a definition for OS_Hardware.
Auto_Error_SWI_bit_number * 17
Auto_Error_SWI_bit * 1 :SHL: Auto_Error_SWI_bit_number

        GBLS    SWIClass
        AddSWI  $SWIName,$value
  [     "$value" = ""
$SWIClass._$SWIName # 1
$SWIClass._$SWIName * $value
X$SWIClass._$SWIName * $SWIClass._$SWIName + Auto_Error_SWI_bit

SWIClass SETS   "OS"
        ^       &1E
        AddSWI  Module                          ; &1E
        AddSWI  Claim                           ; &1F
        AddSWI  Release                         ; &20
        ^       &58
        AddSWI  ReadSysInfo                     ; &58
        ^       &68
        AddSWI  Memory                          ; &68
        ^       &7A
        AddSWI  Hardware                        ; &7A



Finally, the Makefile...

# Project:   BeagLEDs 

# Toolflags:
.SUFFIXES:   .s .o

objasmflags  = -throwback -apcs 3/32bit -desktop -IC:,
linkflags    = -rmf -output BeagLEDs

# A list of assembler files, referred by the resultant object file
s_files      = o.BeagLEDs

BeagLEDs:    $(s_files)
             @echo Linking...
             @link $(s_files) $(linkflags)
             @echo Finished.

# A macro for building the assembler code
.s.o:;       objasm $(objasmflags) -o $@ $<

# Dynamic dependencies:


My Beagle is "dead" again

Something of a misnomer. It isn't dead dead, it just isn't booting. Hooking up a serial terminal, I can see:
Texas Instruments X-Loader 1.5.0 (Mar 27 2011 - 17:37:56)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2011.03-rc1-00000-g9a3cc57-dirty (Apr 01 2011 - 17:41:42)

OMAP36XX/37XX-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB
And that's about as far as it gets. I was running from an iomega Zip power supply, I also tried the +5V line from a PC PSU. The accepted advice is that a meatier power supply is required, but if a PC's lump doesn't have enough oomph!, what would?
Now the interesting thing is that this happened hot on the heels of a Linux kernel panic (some sort of corruption on a replacement microSD while trying to remake an image of the original test card). It might be coincidence, but I can start up RISC OS dozens of times without incident, yet immediately following two kernel panics, the Beagle appears to fail at startup. The first time, as described last week, the board just started up again. This time? It doesn't appear to want to. What the hell does Linux do after reporting a kernel panic?

Am I going to have to UPS the thing back to America? The cheapest UPS were willing to offer me was €168.32 - which is a joke. I must have entered something wrong somewhere.


Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

joe, 29th May 2012, 04:24
I think that your micro SD card was corrupted somehow 
and this is your problem. 
When I was cloning different cards, some were corrupted 
and sometimes I had this kernel panic message, too. 
Sometimes there was maybe one blink and nothing at all, 
unit appeared to be dead. 
If there was something wrong, you wouldn't be able to  
run RISC, you have to try another, working card. 
If you power supply is not overheating, than don't 
worry too much, read the manual: 
Rick, 9th June 2012, 04:55
Just a short note to say that up-and-coming SDFS on the Beagle BOTH LEDs (both flash for writes, one flashes for reads). When I get a working Beagle, I'll have to recode it to do something sexy with the PWM-able LED on the assist-chip. But a filing system hijacking BOTH LEDs? Pffft! There are so many things you could do - like a "you have mail" notification or a blinking "everything's working" (as BeagLEDs was to be originally) or... I'm sure you can think of your own ideas.

Add a comment (v0.08) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 70503 backwards.
Your comment
«   May 2012   »

Japan - can you help? Japanese Red Cross
日本 赤十字社
What the JRC does
Donate to the JRC

Last 5 entries

List all b.log entries

Return to the site index


Search Rick's b.log!


Thank you:
  • Fred
  • Bernard
  • Michael
  • David

Last read at 02:22 on 2017/03/28.

QR code

Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0


© 2012 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.


Have you noticed the watermarks on pictures?
Next entry - 2012/05/30
Return to top of page