What is needed to persuade the loader (?) to populate the ATAG and command line structure at 0x100 please?. Is it just blank space at 0x100 in one's image (I use my own 'first32k') or are there some magic bytes needed in the image. I have put in place the AT 1 and AT 2 tags found in args-uncompressed.txt, hoping this would seed things, but to no avail.
it makes no difference whether I have the ignoretags thing in config.txt

I was looking at #38, and it occurs to me that the vchiq code would probably be extremely useful to me. However, I'm working under the BSD license rather than the GPL; would it be envisagable to have dual GPLv2/BSD licensing in order to make things easier for stuff like this?

My own project is distinctly "minority appeal", but getting as many features as possible into, for example, a *BSD port would seem like a reasonable goal, and dual-licensing would permit this

Thanks

Simon

I have two cards, one class 4 with the original image, one Sandisk 32 Gb class 10. Updated to 8th may dated kernel etc in boot partition on the sandisk.

Keyboard and mouse work fine with no network attached, but there are lost keypresses and intermittent stickyness when an network cable is attached.

Keyboard is the Revoo desk set: http://www.maplin.co.uk/mini-wireless-keyboard-and-mouse-deskset-528055

I suspect that the USB keyboard needs a higher priority

Was going to write some udev rules for usb devices and was running command of form
udevadm info -a -p $(udevadm info -q path -n /dev/mouse0)
or
udevadm info -a -p $(udevadm info -q path -n /dev/sda)
and get kernel oops with latest git kernel and raspbian or debian squeeze

dmesg: https://gist.github.com/2761874

Building and making demos in hardfp/opt/vc/src/hello_pi produces errors about attempting to pass args with VFP registers to libilclient.a suggesting it is compiled with the softfloat abi. readelf -A and disassembly appear to confirm this is the case.

I think that enabling these kernel options would have a lot of benefits, cut down on the current confusion about usb support and have few drawbacks (if any).

When I'm downloading a torrent, after sometime, the external hard driver just stops responding, and the wifi dongle also stops working. If I disconnect and connect the hard drive its detected fine. Transmission also crashes when this happens but I guess thats due to the fact that the hard drive is not responding any more and it timeout or something.

here is the dmesg: http://pastebin.com/Y4mnP709

benosteen/linux@067ac7c

This doesn't solve the actual problem, but does allow for smooth control of apparent volume using 'alsamixer' for example.

However, this ALSA control doesn't seem to affect the output volume at all, and it's not something I can debug further without knowing more about what values I should be passing over vcos(?) to the OpenMAX IL side of things to affect volume.

Hi, I'm trying to understand how to use the vc_tvservice APIs and the source code to the binary provided that does most of these already would be greatly helpful if it uses those APIs. The documentation of the APIs while does sort of exist on a per function basis, there's not really any high level overview of how to interact with the APIs, and I've noticed that if you send it the wrong thing (e.g I attempted to send a NULL pointer rather than the pointer to a struct I thought should be optional) that it caused the system to hang on any of the APIs I called later, even the supplied tvservice hangs - also a reason why I'd expect it to help if it uses the same APIs.

Hi,

We have found a serious issue on the raspberry PI USB stack (or at last the HID USB stack). We produce USB device and have found that we often get missing packet.

We have create an specific firmware illustrate the problem. This debug protocol is very simple the Raspberry will send one packet of 64 bytes, then the device will start a burst of USB transaction. Our USB device work in full speed (USB 1.1) and follow the HID protocol. All packets have the same size (64 bytes). the first uint32_t will contain the current packet number and the second uint32_t will contain the number of packet to send. Each packet is numbered and we stop after burst of 4096 packet of on the first missing packet.

The debug program call libusb-1.0, and will look for one of our device with the debug firmware, then send one USB packet to the device to start the burst. Then we will wait for all packet and check that all packet are send. You can download the source here http://www.yoctopuce.com/tmp/debug_libusb.zip

We have test this code and firmware on many linux platform (i386 and x86_64), and on a ARM based NAS (QNAP TS-219P II). We never get any missing packet. but on the Raspberry PI we always get missing packets. We have check with a USB analyser that the missing packet is correctly sent on the wire (the packet has been correctly acked by the Raspberry PI USB host). It seems that the packet is lost by the Raspberry PI firmware.

We have run this test on both the debian and arm-linux image, we have recompile the last version libusb without success. Our customers also have reported this issue.

We are ready to send one of our device to help to reproduce this issue, or to give a remote access to our Raspberry PI (or do any thing that can help you to fix this issue).

The module for the realtek 8192cu/8188cus dongle would not load at all.

Suggestion for property/value message passing interface from ARM to GPU.

We have a generic message passing structure. The first word is always the property of interest (could be small integers or fourcc codes).
The remainder of the structure is property specific data whose length depends on the property. This data is used for both input and output data.

define MBOX_CHAN_GETPROP 8

define MBOX_CHAN_SETPROP 9

// generic property structure
struct property_s {
uint32_t property;
uint32_t data[];
}

// get property
void *property = <>
uint32_t success;
mbox_write(MBOX_CHAN_GETPROP, property);
mbox_read(MBOX_CHAN_GETPROP, &success);

// set property
void *property = <>
uint32_t success;
mbox_write(MBOX_CHAN_SETPROP, property);
mbox_read(MBOX_CHAN_SETPROP, &success);

Example:

define CLOCK_EMMC 1

struct property_one_word_s {
uint32_t property;
uint32_t value;
} *emmc_clock;

uint32_t success;
emmc_clock =
emmc_clock->property = CLOCK_EMMC;
emmc_clock->value = 50000000;
_wmb();
mbox_write(MBOX_CHAN_SETPROP, emmc_clock);
mbox_read(MBOX_CHAN_SETPROP, &success);
_rmb();

We could also use this to handle the existing framebuffer allocation and power control in a more consistent way.

Any config.txt properties can be retrieved with this mechanism. E.g.
struct property_one_word_one_string_s {
uint32_t property;
uint32_t value;
uint8_t string[MAX_STRING];
} *config_txt;

Similarly cmdline.txt and other ATAGs (e.g. memory size) can be got.

Properties that can be got or set:
CLOCK_EMMC
CLOCK_UART
CLOCK_ARM
CLOCK_CORE
CLOCK_V3D
CLOCK_H264
CLOCK_ISP
POWER_CONTROL
FRAMEBUFFER

Properties that can be got:
CMDLINE
CONFIG_STRING
SERIAL_NUM
BOARD_REV
MAC_ADDRESS
DISPLAY_WIDTH
DISPLAY_HEIGHT
DISPLAY_DEPTH
DMA_CHANS
MEMORY_SIZE

Any additional suggestions?

Hi gang,

I'm experiencing a crash in pulseaudio which seems to be related to the bcm2835 driver. I'm attempting to stream audio from my android phone over bluetooth using A2DP (doing exactly the same thing with an Ubuntu laptop works as expected). I can connect my phone to the Pi over bluetooth, then issue the following command to connect the A2DP stream up using pulse:

sudo pactl load-module module-loopback source=bluez_source.XX_XX_XX_XX_XX_XX sink=alsa_output.platform-bcm2835_AUD0.0.analog-stereo

This seems to work ok. However, as soon as I hit play on the phone, I get these errors from pulseaudio which then conks out:

pi@raspberrypi:~$ sudo pulseaudio
W: main.c: This program is not intended to be run as root (unless --system is specified).
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
E: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
E: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_bcm2835'. Please report this issue to the ALSA developers.
E: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

In /var/log/messages I get:

Jun 6 22:08:48 raspberrypi kernel: snd_bcm2835_playback_open:97 Alsa open (0) <--- when I call the pactl command
Jun 6 22:09:08 raspberrypi kernel: snd_bcm2835_playback_close:167 Alsa close <--- when I hit play on the phone

I'm using the 19-04-12 Debian image with firmware updated today using Hexxeh's script.

Cheers,

Tim

Does the Pi have any way at all to implement hardware cursor support please?

If you are the kernel, then retrieving the Ethernet MAC address is pretty easy; the binary bootloader passes it to the kernel via ATAGS or command-line (I forget which of those two) or device-tree.

However, if you are U-Boot, then you don't typically receive any of those information sources (well, they're there, but since U-Boot is typically the first code to run on a CPU, or perhaps after just the boot ROM, it would be unprecedented for U-Boot to parse such information). So, if U-Boot wants to use the USB Ethernet controller, how does it determine the MAC address?

I'd rather U-Boot could pull this out of the HW directly, rather than relying on the binary bootloader to pass the information to U-Boot (which in turn would probably depend on the user not breaking config.txt, or even actively configuring it to enable some as-yet-unwritten feature). I assume the MAC must be stored in fuses or similar somewhere, since there doesn't appear to be any non-volatile memory on the RPi board. Either way, can the HW that stores this information please be at least minimally documented? I would hesitate to reverse engineer the binary bootloader; that doesn't seem productive and I'm sure there are all kinds of other issues with that approach.

To replicate:

sudo modprobe snd_bcm2835
ogg123 /path/to/random/oggfile

In another window:

alsamixer

Adjusting the volume while playing can cause the playing process to stall, if volume changes are made too rapidly (ie up/down key held down).

/var/log/kern.log is filled with these responses:

Apr 18 20:46:42 raspberrypi kernel: vcos: [3270]: bcm2835_audio_set_ctls_chan:483 bcm2835_audio_set_ctls_chan: result=-1
Apr 18 20:46:42 raspberrypi kernel: Failed to set ALSA controls..
Apr 18 20:46:42 raspberrypi kernel: vcos: [3270]: bcm2835_audio_set_ctls_chan:483 bcm2835_audio_set_ctls_chan: result=-1
Apr 18 20:46:42 raspberrypi kernel: Failed to set ALSA controls..
Apr 18 20:46:42 raspberrypi kernel: vcos: [3270]: bcm2835_audio_set_ctls_chan:483 bcm2835_audio_set_ctls_chan: result=-1
Apr 18 20:46:42 raspberrypi kernel: Failed to set ALSA controls..
Apr 18 20:46:42 raspberrypi kernel: vcos: [3270]: bcm2835_audio_set_ctls_chan:483 bcm2835_audio_set_ctls_chan: result=-1
Apr 18 20:46:42 raspberrypi kernel: Failed to set ALSA controls..
Apr 18 20:46:42 raspberrypi kernel: vcos: [3270]: bcm2835_audio_set_ctls_chan:483 bcm2835_audio_set_ctls_chan: result=-1
Apr 18 20:46:42 raspberrypi kernel: Failed to set ALSA controls..

while compiling quake3 on the raspbian distrib i encountered build errors due to a missing vcos_platform_types.h / vcos_platform.h

first fix was in opt/vc/include/interface/vcos/vcos_types.h:

• - #include "vcos_platform_types.h"
• + #include "pthreads/vcos_platform_types.h"

second fix would be in all the opt/vc/include/interface/vcos/vcos*.h:

• - #include "vcos_platform.h"
• + #include "pthreads/vcos_platform.h"

but being the lazy fool that i am i just copied the files from the pthreads subfolder there, after noticing that grep gave me to many files to fix that in :-P

i guess this would be just a very dirty fix because noone else reported it yet, and so might even be fixed by some makefile magic or the like in the quake3 repository? i can't imagine this problem to be a global one, probably also just tied to quake3+raspbian?
(i use the raspbian-r3.img from hexxeh)

anyways, with the above mentioned actions quake3 builds again...

When writing to the power channel in the VC mailbox, you typically get a response back which indicates the current (new) power state. However, this response is not sent under either of two conditions:

1. If the message sent ARM->VC is simply 0, there is no response. The only way to turn everything off and still get a response back is by setting some invalid bit in the message sent ARM->VC, since the VC always responds if you set some invalid bit.

This means you need a bit of a hack/kludge in the ARM-side driver if you do want to turn everything off for some reason.

2. If the new requested state is identical to the previously current state.

This makes hand-off between multiple ARM-side firmware difficult. Suppose the first thing to run on the ARM is U-Boot rather than the kernel, and the kernel is loaded over the (USB) network. This requires turning on USB power. Without explicit code, U-Boot would leave the USB power on. When the kernel starts, it assumes that nothing is turned on. When the power driver starts, it will try to turn on USB (since at least in the current older reference kernels, USB is listed as always-on). The power driver will actually send a message to the VC in this case, since it thinks the desired power state is different to the current power state. However, they are in fact identical, so I believe no response will be sent, which would cause the kernel power driver to hang or timeout. To solve this, U-Boot might be coded to power everything back off before starting the kernel, but that requires a workaround for (1).

If the VC would always respond to every power message (including 0), that would simplify the ARM-side logic a lot.

The BCM2835 manual notes a UART0 and a UART1.

From what I can gather, UART0 is the full PL011, and UART1 is the "miniUART" that is supposed to be simpler.

Questions:

• There is only one set of assigned tx and rx pins on the pi / bcm2835... how do you switch the pins between the two uarts?
• I see references to UART0 needs to have gpio 14 and gpio 15 in alt0 mode, is this the change needed to go from miniUART -> full PL011 mode?
• The BCM2835 pdf shows that the gpio 14 and 15 pins need to be "low", is this true?

What I really need is a high level overview of what steps are needed to get a uart to the state needed to output characters.

Could you please add a plain text file within the firmware repository that fully describes the license for redistribution for the firmware? This doesn't appear to be stated anywhere, and would be very useful for people doing packaging.

"Default to DVI for DMT modes. Override with hdmi_drive=2. Add perforce version numbering. Avoid unwanted HDMI clock range check" --> commit ef24397

Using HDMI to an Optima HD600X projector, a mode of "1080i" was chosen by the Pi for display for kernels before this commit.

After the commit, it is using a 720p mode (mode 19 in the list below)

$  /opt/vc/bin/tvservice -m DMT
Group DMT has 17 modes:
           mode 4: 640x480 @ 60Hz, progressive
           mode 5: 640x480 @ 72Hz, progressive
           mode 6: 640x480 @ 75Hz, progressive
           mode 8: 800x600 @ 56Hz, progressive
           mode 9: 800x600 @ 60Hz, progressive
           mode 10: 800x600 @ 72Hz, progressive
           mode 11: 800x600 @ 75Hz, progressive
           mode 13: 800x600 @ 120Hz, progressive
           mode 16: 1024x768 @ 60Hz, progressive
           mode 17: 1024x768 @ 70Hz, progressive
           mode 18: 1024x768 @ 75Hz, progressive
           mode 20: 1024x768 @ 120Hz, progressive
           mode 28: 1280x800 @ 60Hz, progressive
           mode 35: 1280x1024 @ 60Hz, progressive
           mode 36: 1280x1024 @ 75Hz, progressive
           mode 58: 1680x1050 @ 60Hz, progressive
           mode 85: 1280x720 @ 60Hz, progressive
pi@raspberrypi:/opt/vc/src/hello_pi/hello_audio$  /opt/vc/bin/tvservice -m CEA
Group CEA has 16 modes:
           mode 1: 640x480 @ 60Hz, progressive
           mode 2: 720x480 @ 60Hz, progressive
           mode 3: 720x480 @ 60Hz, progressive
           mode 4: 1280x720 @ 60Hz, progressive
           mode 5: 1920x1080 @ 60Hz, interlaced
           mode 7: 720x480 @ 60Hz, interlaced
           mode 16: 1920x1080 @ 60Hz, progressive
           mode 17: 720x576 @ 50Hz, progressive
           mode 18: 720x576 @ 50Hz, progressive
  (native) mode 19: 1280x720 @ 50Hz, progressive
           mode 20: 1920x1080 @ 50Hz, interlaced
           mode 22: 720x576 @ 50Hz, interlaced
           mode 31: 1920x1080 @ 50Hz, progressive
           mode 32: 1920x1080 @ 24Hz, progressive
           mode 33: 1920x1080 @ 25Hz, progressive
           mode 34: 1920x1080 @ 30Hz, progressive
pi@raspberrypi:/opt/vc/src/hello_pi/hello_audio$ /opt/vc/bin/tvservice -s
state 0x12001a, 1280x720 @ 50Hz, progressive

This is probably intended behaviour, if the [native] tag is coming from the projector's EDID (can't check, as tvservice on img doesn't understand '-d')

The BCM2835 boot process at present is very roughly:

• Boot ROM executes on the VC, loads various pieces of SW into RAM, and runs them on the VC.
• Code on the VC loads kernel/... from SD card into RAM, and starts the ARM processor, thus executing the kernel.
• The code on the VC continues to run, and the kernel communicates with it.

Is it possible to invert this process to something more ARM-centric and typical:

• Boot ROM executes on the VC, loads a blob into RAM that contains (a) absolutely minimal SW required to power on and boot the ARM, and (b) and ARM-based bootloader. Nothing else is set up on the VC. The VC goes completely idle once the ARM is started.
• The ARM-based bootloader (e.g. U-Boot) loads the kernel from SD card (or network or wherever), and jumps to it.
• The Linux kernel contains a driver which loads the VC firmware into RAM, and causes the VC to execute it.

This has the following advantages:

• The binary blob the boot ROM loads contains extremely minimal code just to boot the ARM with the concatenated ARM-based boot-loader. As such, all the device tree setup (or whatever else was needed) to boot the Linux kernel (or whatever other OS) would be in a standard ARM-based (and open-source) bootloader, rather than in something that the general community can't easily modify. Moving this code out of the binary bootloader would reduce duplication when people do unexpected things like using U-Boot instead of directly booting a kernel.
• Before the kernel loads any firmware and causes the VC to execute it, it is in complete control of the system (and in particular RAM), so issues such as reducing the memory size the kernel is aware of (or reserving regions of RAM) based on the particular VC firmware used to boot the system, are eliminated. Related to this, it'd be nice if the VC binary blob could be reworked so that Linux was the master and the VC the slave for memory partitioning; VC code determines this at runtime based on a message from ARM rather than at compile-time for example. Perhaps with Linux in charge, the VC wouldn't even need a single contiguous chunk of RAM, but could use arbitrary pages?
• It puts the kernel completely in charge, which is always a good thing. It's much more similar to how any other device that Linux interacts with and contains firmware works.

This would likely mean opening up a lot more documentation though, e.g. Linux (and/or a bootloader such as U-Boot) would have to gain code to directly control the power controller rather than sending messages to the VC to do so on its behalf, and some amount of information would be needed on how to get the VC to execute the downloaded firmware. Without knowledge of what the VC is doing today, it's hard to say what else might have to open up. Perhaps the VC MMU would need to be programmed by the ARM before sending the firmware for example?

hello_audio builds and runs fine (alarmingly loud ;)) but modprobing the new alsa driver in and trying to play a song using mplayer causes a kernel oops:

Init:

• debian image from torrent, 13/04/2012 version
• apt-get install alsa-base mplayer
• random mp3's put into /home/pi/mp3

Then, on SSH terminal or normal terminal:

modprobe snd_bcm2835

mplayer foo.mp3

(mplayer fails to find any audio hw to playback on)

then attempting to ls the mp3 directory will kick off the error.

console log: https://gist.github.com/2400335

On primary tty on the RPi, the main kernel oops is shown:

From /var/log/syslog: https://gist.github.com/2400347

I'm sure there will be other places where you might want to change the API or details on how the firmware works. It's inevitable that this will happen.

Give semantic version numbering for the firmware, and remember to update it. As in addition you could provide a file, which tells how backwards compatibility was broken and why.

Is it / Can it be possible to restart the 'start.elf' (I presume) system to take account of different parameters in the config.txt file. This would be really really helpful. This particularly relevant in relation to the r<->b swapping, and whether ot not to ignore the alpha channel. .. indeed, is 'restarting'the start.elf what is required?

thanks

eglGetProcAddress("eglQueryGlobalImageBRCM"), and possibly other Broadcom extensions will fail.

Using framebuffer_depth=24 in config.txt , there's graphical problems on X. 32bit is even worse.

As 16bit is horrid and the hardware can do 24bit, fixing this and making 24bit the default would make a huge difference.

Hi. I hope this is an appropriate place to ask - I'm working on the HAL for RISCOS. I had a frame buffer that worked more or less OK with firmware from early March. Having finally located this repository, I have tried using the mid may firmware. Many things have moved. e.g. a frame buffer is returned aligned to 0x1000 - That is an improvement, though ideally we require megabyte alignment. What I'm leading to, is, where can I find the changes to the firmware interface as they happen please? It is not much fun chasing a moving target almost blind... Thanks in advance ..

Hello,

I have external USB sound card connected to the board.
But on "aplay -D plughw:0,0 -v ./beep.wav" I got an error:
76.571730 ------------ cut here ------------
76.576553 WARNING: at lib/kref.c:34 kref_get+0x40/0x48()
76.582179 Modules linked in: evdev snd_usb_audio snd_seq snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib snd_rawmidi snd_seq_device snd ipv6 last unloaded: scsi_wait_scan
76.599419 c00153d4 (unwind_backtrace+0x0/0xfc) from c03fba1c (dump_stack+0x20/0x24)
76.608193 c03fba1c (dump_stack+0x20/0x24) from c002d4b0 (warn_slowpath_common+0x5c/0x74)
76.617402 c002d4b0 (warn_slowpath_common+0x5c/0x74) from c002d4f4 (warn_slowpath_null+0x2c/0x34)
76.627329 c002d4f4 (warn_slowpath_null+0x2c/0x34) from c0251530 (kref_get+0x40/0x48)
76.636183 c0251530 (kref_get+0x40/0x48) from c02daafc (usb_get_urb+0x20/0x28)
76.644417 c02daafc (usb_get_urb+0x20/0x28) from c02d9cec (usb_hcd_flush_endpoint+0x110/0x160)
76.654064 c02d9cec (usb_hcd_flush_endpoint+0x110/0x160) from c02dc6ec (usb_disable_endpoint+0x60/0x90)
76.664514 c02dc6ec (usb_disable_endpoint+0x60/0x90) from c02dc768 (usb_disable_interface+0x4c/0x64)
76.674705 c02dc768 (usb_disable_interface+0x4c/0x64) from c02dcdac (usb_set_interface+0x168/0x244)
76.684934 c02dcdac (usb_set_interface+0x168/0x244) from bf0e16b8 (snd_usb_pcm_close.clone.2+0x48/0x74 snd_usb_audio)
76.696960 bf0e16b8 (snd_usb_pcm_close.clone.2+0x48/0x74 snd_usb_audio) from bf0e1728 (snd_usb_playback_close+0x20/0x24 snd_usb_audio)
76.710698 bf0e1728 (snd_usb_playback_close+0x20/0x24 snd_usb_audio) from bf0a6bc0 (snd_pcm_release_substream+0x64/0xb8 snd_pcm)
76.723831 bf0a6bc0 (snd_pcm_release_substream+0x64/0xb8 snd_pcm) from bf0a6c4c (snd_pcm_release+0x38/0x7c snd_pcm)
76.735788 bf0a6c4c (snd_pcm_release+0x38/0x7c snd_pcm) from c00f7f74 (fput+0xc0/0x218)
76.753002 c00f7f74 (fput+0xc0/0x218) from c00f43b4 (filp_close+0x78/0x90)
76.768920 c00f43b4 (filp_close+0x78/0x90) from c00f4488 (sys_close+0xbc/0x118)
76.785391 c00f4488 (sys_close+0xbc/0x118) from c000e140 (ret_fast_syscall+0x0/0x48)
76.802331 --- end trace b01813e49adb0423 ---

Calling "graphics_get_display_size" seems to always return 1920x1080, regardless of the current display size. Is this expected behaviour?

Is there a way to get the true output resolution, in the same manner as the tvservice utility?

eg

#include "bcm_host.h"
...
success = graphics_get_display_size(0 /* LCD */, &width, &height);

width and height seem to return 1920 and 1080 respectively, regardless to output mode. My HDMI is currently set to "state 0x12001a, 1280x720 @ 50Hz, progressive". It returns 1920x1080 even when using composite out.

Up to and including the start.elf file from the 18th April (4712300) I was able to use an HDMI to VGA converter to drive my monitor and I could select the resolution by using a config.txt file with the following contents:

hdmi_drive=2
hdmi_group=2
hdmi_mode=0x10
disable_overscan=1

This doesn't work with any of the later versions - the monitor just stays in standby. It still works with the default configuration (i.e. when there's no config.txt).

Is there something I need to add to config.txt for the later versions?

Hi.

I'm currently building an "alternative" operating system for the Pi. Unfortunately, the firmware changes introduced as as result of raspberrypi/linux#16 have broken booting for me, and everyone apart from the linux developers who haven't been following closely every issue on the linux side of things. Yeah, you can probably colour me unimpressed.

Beforehand, it was clear what needed to be done, viz:

• Standard ARM vector table from 0x0
• If you want to use Atags and commandline, don't use space between 0x100 and 0x4000

the rest is up to you.

It appears that the current bootloader is synthesizing an ARM vector table, and requiring the "application" code to start at 0x8000 (0x100->0x3fff for atags + commandline, 0x4000->0x7fff for initial linux page mapping tables).

As a result of this, stead of building my code (which includes rather more than just a simple "b 0x8000" as the only entry in the vector table), I have to

• be really careful where I put my code entry (not too much of a problem, I had to do that with the vector table anyway)
• before I can enable interrupts, either rebase the vector table or go back and re-synthesize a vector table over the top of the wholly useless one created by the bootloader.

On top of that, and significantly less importantly, I'm "losing" at least 16K (the page table space, I can probably use the atags and command line for my own nefarious purposes).

I am aware of the config.txt option that's supposed to move stuff back to 0x0, but :

a - it does away with the atags and command line
b - it doesn't work reliably, and when you're trying to bring a board up, it's really handy if you can rely on your bootloader to do what it says on the tin.

So. I would propose one of (in order of preference):

• going back to a default of loading at 0x0 /as it was before/ and adding a "boot_linux" (or similar) config entry to enable the new and (for me) undesirable behaviour
• adding a config entry to go back to the original behaviour, which entry is /tested and proven to work reliably/, but which does not preclude the use of atags / command line from 0x100 through 0x3fff
• changing the synthesised vector table to make it easily patchable, as follows:

Instead of making an entry of "b 0x8000" or whatever, make the entries use an indirection via:

_vector_table:
ldr pc, [pc, #24]
ldr pc, [pc, #24]
ldr pc, [pc, #24]
ldr pc, [pc, #24]
ldr pc, [pc, #24]
b .
ldr pc, [pc, #24]
ldr pc, [pc, #24]
__reset_ind:
.word 0x8000
__undef_ind:
.word 0x14
__svc_ind:
.word 0x14
__prefetch_ind:
.word 0x14
__data_ind:
.word 0x14
__unused_ind
.word 0x14
__irq_ind:
.word 0x14
__fiq_ind:
.word 0x14

This way anyone wanting to patch the vector table can do so easily, by simply dumping a handler address into the relevant location from 0x20 onwards. It won't get in the way of atags, it won't hurt linux.

Simon

I'm having problems booting from my SD card (http://www.amazon.co.uk/gp/product/B000Y9TZ9Y/).
It's a quite common problem, but it seems "closer" to working with the latest firmware.
With the firmware that comes with the Debian Squeeze image available on the official site, it fails to even be recognized by my Raspberry Pi (only the red led lights up). However with the latest firmware both the red and green leds light up, however I still see no splash screen on either of video outputs and the OS still fails to boot.

I have ruled out the my Raspberry Pi, as it works perfectly with another sd card.
What could be causing this and is a fix possible? I certainly hope it isn't a hardware limitation.

Calling vc_tv_power_off on a system that has just booted up has no effect on turning off the screen output, even though it returns a successful return code. The state returned by vc_tv_get_state is the same both before and after the call.

However, if a call to set the power on (e.g. tvservice -p ) has been made previously, the vc_tv_power_off call works as expected.

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=7570&p=92870 details user experience with this issue.

Can we have CONFIG_VM_EVENT_COUNTERS=y in future kernel builds? I don't know if it has been enabled previously but in the last kernel I got from the repo it was not set.

It is nice to be able to use tools like vmstat to watch i/o, particularly swap as I am a bit sensitive about tuning that on an SD card.

Internal documentation on what the boot loader is looking for is needed to ensure other platform ports are possible.

Documentation items could include:

• 32k binary blob addition to kernel image?
  • https://github.com/raspberrypi/tools/tree/master/mkimage
• Elf load address expectations.
• Detailed boot procedure diagram.
• Things in general that would enable non-linux operating system ports (BSD, Haiku, etc)
• Maybe a simple example "hello world" kernel with needed build information?

If you add CONFIG_LOCALVERSION="-cutdown" it'd be possible to install modules for both configurations in
/lib/modules/3.1.9+ and /lib/modules/3.1.9+-cutdown.

As per issue title. I'm trying to get Chrome running on the Pi with acceleration by adding the dispmanx specific stuff into Chrome's code as a bit of a hack until we have a better way of doing things, but I'm seeing these errors:

[2020:2020:92746901:ERROR:gles2_cmd_decoder.cc(3031)] GLES2DecoderImpl::ResizeOffscreenFrameBuffer failed because offscreen FBO was incomplete.
[2020:2020:92748510:ERROR:gles2_cmd_decoder.cc(2211)] Could not allocate offscreen buffer storage.
[1996:1996:92759790:ERROR:command_buffer_proxy_impl.cc(134)] Failed to initialize command buffer service.
[1996:1996:92773044:FATAL:image_transport_factory.cc(377)] Failed to make compositor shared context current.

I've asked some of the Chrome devs, and they've suggested I ask whoever wrote the GLESv2 implementation what stencil/depth combinations should work, as apparently this would save me a hell of a lot of time.

The appropriate bit of the Chrome code is here, I think: http://code.google.com/searchframe#OAMlx_jo-ck/src/gpu/command_buffer/service/gles2_cmd_decoder.cc&type=cs&l=2116

I've not really touched GL/GLES/EGL before, so I'm just stabbing in the dark based on triangle.c, so if I'm on completely the wrong track, then apologies for wasting your time... :)

Couple of suggestions for tvservice

-n --name - set HDMI device name - uses hostname if no name given

should be a call to vc_cec_set_osd_name ... with normalised version of given parameter value or hostname if no parameter value given.

For TVs that show the name when selecting the source this would make it more family friendly.

... and how about a way to send text to the screen

"Set OSD String"
-t --text - send text string to display. If no value given then clears text on screen

e.g.
tvservice -t "Eng 1 - 0 Ukr"
tvservice -t ""

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=8685&p=102781

I have installed the git version of the driver and the new .elf file but I just can't get the Pi to play sound on my TV.

The Audiojack works when setting it manually with

amixer cset numid=3 1

I tried a different HDMI cable but that didn't change a thing and I don't a have onther TV to test.

The BUG() in bcm2708_fb_set_par doesn't work because the console is currently locked:

[    1.402692] BCM2708FB: registering framebuffer (1824x1104@16)
[    1.413735] bcm2708_fb_set_par info(cb8c4c00) 1824x1104 (1824x1104), 0, 16
[    1.439038] ------------[ cut here ]------------
[    1.443703] kernel BUG at drivers/video/bcm2708_fb.c:252!
[    1.449132] Internal error: Oops - BUG: 0 [#1] PREEMPT
[    1.454303] CPU: 0    Not tainted  (3.3.0-00040-g7eab884-dirty #14)
[    1.460616] PC is at bcm2708_fb_set_par+0x178/0x184
[    1.465538] LR is at get_parent_ip+0x10/0x2c
[    1.469835] pc : [<c01c5644>]    lr : [<c003ec54>]    psr: 60000013
[    1.469844] sp : cb82dd40  ip : c08a0880  fp : 00000045
[    1.481369] r10: 00000720  r9 : c09662d4  r8 : 00000010
[    1.486620] r7 : cb82dd5c  r6 : 00000000  r5 : ffdff000  r4 : cb8c4c00
[    1.493177] r3 : c0414568  r2 : c0414568  r1 : cb828348  r0 : 00000000
[    1.499736] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    1.507079] Control: 00c5387d  Table: 00004008  DAC: 00000017
[    1.512853] Process swapper (pid: 1, stack limit = 0xcb82c268)
[    1.518715] Stack: (0xcb82dd40 to 0xcb82e000)
[    1.523103] dd40: 00000720 00000450 00000000 00000010 c09662d4 cb806000 cb8c4cc8 00000000
[    1.531329] dd60: cb8c4c00 cb806000 cb8c4c00 cb806000 c04205a0 c09662d4 cb94c000 c01be6bc
[    1.539552] dd80: 000000b2 c004f488 cb8c4c9c 00000000 00000000 00000001 000000e4 c0968288
[    1.547775] dda0: 000000e4 00000045 00000000 cb806000 00000194 cb8062b8 00000154 000001c0
[    1.555996] ddc0: 00000000 00000000 c0968908 c01d7c24 00000001 c0347758 cb806000 00000001
[    1.564217] dde0: c03b1c14 c01d93f8 00000000 00000000 00000001 00000000 0000003e c0968634
[    1.572439] de00: c03b3364 0000003e 00000000 c0347758 00000001 00000000 00000000 00000005
[    1.580662] de20: 00000000 c01daf68 00000001 c04205a0 c0968288 ffffffff 00000000 c01be784
[    1.588884] de40: 00000000 cb82dee0 c04205cc c003b464 ffffffff c04203c8 ffffffff cb82dee0
[    1.597106] de60: 00000005 c04205cc 01d00000 c003b948 00000000 c040e280 00000000 cb8c4c00
[    1.605329] de80: c040e280 cb8c4c0c cb8c4e9c c003b994 00000000 00000000 cb8c4c00 c01b92b8
[    1.613552] dea0: c03b19e0 00000000 00000000 00000000 00000720 00000450 00000000 00000000
[    1.621772] dec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020
[    1.629994] dee0: cb8c4c00 c032e268 cb8c4c00 cb8c4c00 c04131f8 00000000 c0420728 cb8c4c9c
[    1.638218] df00: 3f39322b c01c5380 c0413208 0b94d000 c0413200 c096b9e8 c0413234 00000000
[    1.646441] df20: c042073c c01ec4b8 c01ec4a0 c01eb410 c0413200 c042073c c0413234 00000000
[    1.654664] df40: 00000000 c01eb5ac c042073c c01eb518 00000000 c01e9f30 cb803ea8 cb84e150
[    1.662887] df60: c042073c c0424c88 cb957d80 c01ea76c c039e84c c01a1d64 cb803e00 c042073c
[    1.671110] df80: 00000000 c03f9ed4 00000013 00000000 3f39322b c01ebbec c040b068 00000000
[    1.679332] dfa0: c03f9ed4 00000013 00000000 c03ed768 00000400 00000000 3f39322b 00000000
[    1.687555] dfc0: cb82dfd4 c040b068 c040b134 c000ecd0 00000013 00000000 00000000 00000000
[    1.695776] dfe0: 00000000 c03ed8f4 00000000 00000000 c03ed87c c000ecd0 00000000 00000000
[    1.704034] [<c01c5644>] (bcm2708_fb_set_par+0x178/0x184) from [<c01be6bc>] (fbcon_init+0x460/0x4c4)
[    1.713243] [<c01be6bc>] (fbcon_init+0x460/0x4c4) from [<c01d7c24>] (visual_init+0x78/0xc8)
[    1.721660] [<c01d7c24>] (visual_init+0x78/0xc8) from [<c01d93f8>] (bind_con_driver+0x138/0x308)
[    1.730508] [<c01d93f8>] (bind_con_driver+0x138/0x308) from [<c01daf68>] (take_over_console+0x3c/0x44)
[    1.739879] [<c01daf68>] (take_over_console+0x3c/0x44) from [<c01be784>] (fbcon_takeover+0x64/0xc8)
[    1.748987] [<c01be784>] (fbcon_takeover+0x64/0xc8) from [<c003b464>] (notifier_call_chain+0x74/0xe8)
[    1.758271] [<c003b464>] (notifier_call_chain+0x74/0xe8) from [<c003b948>] (__blocking_notifier_call_chain+0x60/0x94)
[    1.768945] [<c003b948>] (__blocking_notifier_call_chain+0x60/0x94) from [<c003b994>] (blocking_notifier_call_chain+0x18/0x20)
[    1.780407] [<c003b994>] (blocking_notifier_call_chain+0x18/0x20) from [<c01b92b8>] (register_framebuffer+0x170/0x24c)
[    1.791170] [<c01b92b8>] (register_framebuffer+0x170/0x24c) from [<c01c5380>] (bcm2708_fb_probe+0x14c/0x208)
[    1.801068] [<c01c5380>] (bcm2708_fb_probe+0x14c/0x208) from [<c01ec4b8>] (platform_drv_probe+0x18/0x1c)
[    1.810613] [<c01ec4b8>] (platform_drv_probe+0x18/0x1c) from [<c01eb410>] (driver_probe_device+0x90/0x198)
[    1.820329] [<c01eb410>] (driver_probe_device+0x90/0x198) from [<c01eb5ac>] (__driver_attach+0x94/0x98)
[    1.829781] [<c01eb5ac>] (__driver_attach+0x94/0x98) from [<c01e9f30>] (bus_for_each_dev+0x50/0x7c)
[    1.838883] [<c01e9f30>] (bus_for_each_dev+0x50/0x7c) from [<c01ea76c>] (bus_add_driver+0x17c/0x248)
[    1.848073] [<c01ea76c>] (bus_add_driver+0x17c/0x248) from [<c01ebbec>] (driver_register+0x78/0x130)
[    1.857270] [<c01ebbec>] (driver_register+0x78/0x130) from [<c03ed768>] (do_one_initcall+0x50/0x164)
[    1.866462] [<c03ed768>] (do_one_initcall+0x50/0x164) from [<c03ed8f4>] (kernel_init+0x78/0x118)
[    1.875317] [<c03ed8f4>] (kernel_init+0x78/0x118) from [<c000ecd0>] (kernel_thread_exit+0x0/0x8)
[    1.884155] Code: e59412b8 eaffffee ebf95710 ebf9574f (e7f001f2) 
[    1.890694] ---[ end trace d0737ebb5ab15f5f ]---

I have a hack to ensure the console is unlocked before calling BUG(): nomis/linux@a9de8a9

Using the emergency kernel image with the latest firmware binaries results in corrupted graphical output for me.

I can get display out using the normal image by setting hdmi_mode=4, hdmi_drive=2, hdmi_force_hotplug=1, but those don't fix the display using the emergency kernel.

Is the emergency kernel just outdated compared to the firmware files?

vc_tv_get_state reports 720x288i if sdtv_mode=2 (PAL B/G) - I think it should report 720x576i as it (correctly) reports NTSC as 720x480i if sdtv_mode=1.

Steps to reproduce:

1. Lots of files on a USB drive, plugged in and mounted.
2. Begin a download of a large file (100Mb+ is suggested) to that USB drive.
3. During download, try to access large numbers of files (suggestions to follow)

This will at some indeterminate point freeze the system with kernel panics from the USB storage driver - "... not syncing: Fatal exception in interrupt" and kernel errors from the ethernet driver : "kevent may have dropped the interrupt."

Suggested means to replicate step 3)

If rootfs is on USB, apt-get install'ing a group of packages, apt-cache search and so on are good ways to uncover this collision.
Otherwise, searching or grepping through a reasonable number of files on the USB is enough (find . | xargs grep -i "foo") for example.

It is hard to capture this error, as the kern.log doesn't sync the errors to disc, and the errors flash by too fast on tty to see them with any clarity.

Recreated with latest kernel + UAS built in and new modules and with kernel modules from 13/04 - with rootfs on USB and with the stock rootfs on SD. Having the rootfs on SD makes it more difficult to simulate the type of storage demand required to replicate the bug however.

When opening a new connection, the card resets back to its default volume. Eg lower the volume, and then start a process to playback sound - it will play at its default level, until volume is altered, causing a quick change in output volume.

Is this because the hw doesn't persist a value for volume/attentuation between playback connections?

If so, the driver should probably persist a value during its runtime and reapply that to newly opened pcm stream connections before playback.

This is my Terratec Aureon soundcard:

Jan  1 00:00:13 raspberrypi kernel: usb 1-1.2: Product: USB PnP Sound Device
Jan  1 00:00:13 raspberrypi kernel: usb 1-1.2: Manufacturer: C-Media Electronics Inc.      
Jan  1 00:00:13 raspberrypi kernel: input: C-Media Electronics Inc.       USB PnP Sound Device as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2:1.3/input/input0
Jan  1 00:00:13 raspberrypi kernel: generic-usb 0003:0CCD:0077.0001: input: USB HID v1.00 Device [C-Media Electronics Inc.       USB PnP Sound Device] on usb-bcm2708_usb-1.2/input3
Jan  1 00:00:13 raspberrypi kernel: usbcore: registered new interface driver snd-usb-audio

The kernel crashes when using pyo with portaudio through this soundcard under Python. Because this is a custom compiled application I search a way to mimic this behaviour. The kernel also crashes on the same bug when playing a mp3 with mpg123 and aborting after a few seconds:

May 13 20:22:12 raspberrypi kernel: ERROR::dwc_otg_hcd_urb_dequeue:525: **** DWC OTG HCD URB Dequeue has NULL URB
May 13 20:22:12 raspberrypi kernel:
May 13 20:22:12 raspberrypi kernel: ------------[ cut here ]------------
May 13 20:22:12 raspberrypi kernel: WARNING: at lib/kref.c:34 0xc0194350()
May 13 20:22:12 raspberrypi kernel: Modules linked in: fuse snd_usb_audio snd_pcm snd_page_alloc snd_hwdep snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device snd evdev
May 13 20:22:12 raspberrypi kernel: Backtrace: 
May 13 20:22:12 raspberrypi kernel: Function entered at [<c0011a7c>] from [<c03043a4>]
May 13 20:22:12 raspberrypi kernel: r6:00000022 r5:c0194350 r4:00000000 r3:c03a4fa4
May 13 20:22:12 raspberrypi kernel: Function entered at [<c030438c>] from [<c001ed28>]
May 13 20:22:12 raspberrypi kernel: Function entered at [<c001ecd4>] from [<c001ed64>]
May 13 20:22:12 raspberrypi kernel: r8:00000001 r7:c78923a0 r6:c7922eb0 r5:c7922ea0 r4:c7b5b760
May 13 20:22:12 raspberrypi kernel: r3:00000009
May 13 20:22:12 raspberrypi kernel: Function entered at [<c001ed40>] from [<c0194350>]
May 13 20:22:12 raspberrypi kernel: Function entered at [<c0194310>] from [<c020b15c>]
May 13 20:22:12 raspberrypi kernel: r4:c7b5b760 r3:00000000
May 13 20:22:12 raspberrypi kernel: Function entered at [<c020b144>] from [<c020a4e0>]
May 13 20:22:12 raspberrypi kernel: r4:c7b5b760 r3:00000000
May 13 20:22:12 raspberrypi kernel: Function entered at [<c020a42c>] from [<c020c850>]
May 13 20:22:12 raspberrypi kernel: r7:c7921000 r6:00000001 r5:c7922ea0 r4:c7921000
May 13 20:22:12 raspberrypi kernel: Function entered at [<c020c7f8>] from [<c020c8c4>]
May 13 20:22:12 raspberrypi kernel: r6:c7922dc4 r5:00000000 r4:00000000 r3:c7922ea0
May 13 20:22:12 raspberrypi kernel: Function entered at [<c020c880>] from [<c020cee0>]
May 13 20:22:12 raspberrypi kernel: r8:c78923a0 r7:00000001 r6:00000000 r5:00000000 r4:c7921000
May 13 20:22:12 raspberrypi kernel: r3:00000001
May 13 20:22:12 raspberrypi kernel: Function entered at [<c020cd80>] from [<bf05c08c>]
May 13 20:22:12 raspberrypi kernel: Function entered at [<bf05c04c>] from [<bf05c0ec>]
May 13 20:22:12 raspberrypi kernel: r6:c7a72908 r5:c6de31a0 r4:c7b5bb60 r3:bf05c0d4
May 13 20:22:12 raspberrypi kernel: Function entered at [<bf05c0d4>] from [<bf046f1c>]
May 13 20:22:12 raspberrypi kernel: Function entered at [<bf046ec0>] from [<bf046fa0>]
May 13 20:22:12 raspberrypi kernel: r5:c6de31a0 r4:c7a72800
May 13 20:22:12 raspberrypi kernel: Function entered at [<bf046f70>] from [<c008014c>]
May 13 20:22:12 raspberrypi kernel: r8:c6de31a8 r7:00000008 r6:c74f83b8 r5:c7bfd908 r4:c6de31a0
May 13 20:22:12 raspberrypi kernel: r3:bf046f70
May 13 20:22:12 raspberrypi kernel: Function entered at [<c0080094>] from [<c007d0e0>]
May 13 20:22:12 raspberrypi kernel: Function entered at [<c007d070>] from [<c007d190>]
May 13 20:22:12 raspberrypi kernel: r6:0077e1b0 r5:00000001 r4:00000027 r3:00000003
May 13 20:22:12 raspberrypi kernel: Function entered at [<c007d0f8>] from [<c000e220>]
May 13 20:22:12 raspberrypi kernel: r5:00774008 r4:00774008
May 13 20:22:12 raspberrypi kernel: ---[ end trace f1d082aa36270715 ]---

Latest github kernel and modules.

Having successfully compiled squeezeslave http://wiki.slimdevices.com/index.php/SqueezeSlave, appears to work, but after an unknown amount of time the system hangs.
The following kernel output is produced to console.

Linux rasp 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l

Debian GNU/Linux 6.0 rasp ttyAMA0

rasp login: Unable to handle kernel paging request at virtual address 973ed3d0
pgd = c0004000
[973ed3d0] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in: snd_bcm2835 snd_pcm snd_seq snd_timer snd_seq_device snd snd_page_alloc fuse evdev
CPU: 0 Not tainted (3.1.9+ #90)
pc : [] lr : [] psr: 60000193
sp : c0399d9c ip : 00000002 fp : c0399db4
r10: 973ed3d2 r9 : cb919cc8 r8 : cad992e0
r7 : cb919c80 r6 : cad99220 r5 : cb9541e0 r4 : cb918900
r3 : 000000a1 r2 : 346ecf2a r1 : 973ed3d0 r0 : ffdd0000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387d Table: 0bbbc008 DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc0398268)
Stack: (0xc0399d9c to 0xc039a000)
9d80: ffdd0000
9da0: cb918900 c022bda0 c0399dec c0399db8 c0221a3c c022bd9c c0045620 c00174b0
9dc0: c039dac0 00000001 cb919c80 cb9541e0 cb954208 00000000 cb919c90 00000008
9de0: c0399e24 c0399df0 c0222810 c0221658 00000ab3 cb919c98 c03a0500 cb919c80
9e00: e0980000 000014a6 cb919d40 0000004b c03d8a4c c03a2bf0 c0399e44 c0399e28
9e20: c0225994 c0222708 00000000 00000008 cb919c80 00000008 c0399e64 c0399e48
9e40: c0226da0 c02258f4 cb8933a0 a0000193 00000001 00000000 c0399e74 c0399e68
9e60: c022475c c0226ce0 c0399e94 c0399e78 c0203e84 c0224754 c0203e48 cb913c60
9e80: 00000000 00000000 c0399ecc c0399e98 c004e54c c0203e54 00000ab3 13f55e89
9ea0: 60000193 c03a2bf0 0000004b 00000000 c0399f74 00004008 410fb767 003919b0
9ec0: c0399ee4 c0399ed0 c004e6cc c004e504 00020000 c03a2bf0 c0399efc c0399ee8
9ee0: c005010c c004e6a8 c0050084 c03a84d8 c0399f0c c0399f00 c004df84 c0050090
9f00: c0399f2c c0399f10 c000f0dc c004df5c c000f230 c000f234 60000013 f200b200
9f20: c0399f3c c0399f30 c0008190 c000f0b0 c0399f94 c0399f40 c000ddd4 c000818c
9f40: ffffffed 00000000 c0399f88 00000000 c0398000 c03b5dc4 c039cfdc c039cfd4
9f60: 00004008 410fb767 003919b0 c0399f94 c0399f98 c0399f88 c000f230 c000f234
9f80: 60000013 ffffffff c0399fb4 c0399f98 c000f444 c000f214 c039c050 c039a0ac
9fa0: c0392718 c0582960 c0399fc4 c0399fb8 c02fcf10 c000f3b0 c0399ff4 c0399fc8
9fc0: c037b72c c02fcebc c037b1ac 00000000 00000000 c0392718 00000000 00c5387d
9fe0: c039a040 c0392714 00000000 c0399ff8 0000803c c037b50c 00000000 00000000
Backtrace:
Function entered at [] from []
Function entered at [] from []
Function entered at [] from []
Function entered at [] from []
r6:00000008 r5:cb919c80 r4:00000008 r3:00000000
Function entered at [] from []
r7:00000000 r6:00000001 r5:a0000193 r4:cb8933a0
Function entered at [] from []
Function entered at [] from []
r6:00000000 r5:00000000 r4:cb913c60 r3:c0203e48
Function entered at [] from []
Function entered at [] from []
r4:c03a2bf0 r3:00020000
Function entered at [] from []
r4:c03a84d8 r3:c0050084
Function entered at [] from []
Function entered at [] from []
r6:f200b200 r5:60000013 r4:c000f234 r3:c000f230
Function entered at [] from []
Exception stack(0xc0399f40 to 0xc0399f88)
9f40: ffffffed 00000000 c0399f88 00000000 c0398000 c03b5dc4 c039cfdc c039cfd4
9f60: 00004008 410fb767 003919b0 c0399f94 c0399f98 c0399f88 c000f230 c000f234
9f80: 60000013 ffffffff
Function entered at [] from []
Function entered at [] from []
r6:c0582960 r5:c0392718 r4:c039a0ac r3:c039c050
Function entered at [] from []
Function entered at [] from [<0000803c>]
Code: e211c003 0affffc4 e3c11003 e35c0002 (e491e004)
---[ end trace 519aec8eb3f97b25 ]---
Kernel panic - not syncing: Fatal exception in interrupt

I would be very happy, if there would be iptables support in the "official" kernel!
The needed modules are listed e.g. here: https://fermiparadox.wordpress.com/2007/02/04/configuring-an-ipv6-gateway-with-debian/ or here http://www.faqs.org/docs/iptables/kernelsetup.html

I would like to use a RaspberryPi to get IPv6 using a tunnel (already works) and then share that ipv6 connection in the local network (doesn't work yet)

Reverting to an earlier revision of loader.bin corrects the issue.

Sorry, not much helpful information. The failure to boot is just no response (nothing on screen, just a red PWR led.)

When I try to build against libEGL, I get a bunch of errors like this:

lib/libEGL.so: undefined reference to `glxx_client_*'

Unless my grep is failing me, these are not present in any of the libs.