The MayGion camera PCBs have three connectors for limit switches.  One is three-wire and yes it's common + limit sense in both directions, the other two connectors are exactly the same signals but arranged as two 2-pin connectors, with the common line going to both connectors.

I don't know which pins they are hooked up to though - if they are connected to analogue input pins it's possible you could connect a pot to them instead to get more accurate measurement perhaps.  But in all my cases with normal security style IP cameras they are just connected to normal microswitches.

Have you seen a camera with sense pots?  All mine just have switches at the extremities of the pan position, and nothing at all for tilt.

One firmware I have actually pans all the way around until it hits the limit switch at power on, so that it can count the number of steps to a given position to allow presets.

But if you move the camera by hand this all gets thrown off since there aren't any position sensors.  So unless you're proposing to add some pots, I think reading the signals sent to the motor controllers would be the simplest.  (Reading the voltages on the motors themselves would work too, but then you'd need to handle higher voltages and multiple signals.  Some motor controllers accept pulses as input which would be much easier to read if that's the case here.)

You can download these from www.maygion.com - first news item has a firmware download link.

Hmm well, in that case I would probably tap into the lines that connect the camera's processor to the motor controllers.  Then you can monitor what commands are being sent to the motor controller.

It's a bit hard to offer any more advice without knowing why you need the information in the first place!  What is the microcontroller for?  What will it do?

Thanks for the BusyBox binary.  The kernel gets further than before - it actually recognises it as BFLT and downloads the whole file and tries to run it, but then it can't run it and I get a kernel panic "not syncing: Attempted to kill init! exitcode=0x00000004"

It may have been compiled with the old ARM ABI as I think I am using the new one with this kernel.

Yes there is another repo for just the Linux kernel.  It's in the other thread, it was the first one I posted: https://github.com/Malvineous/linux-nuc700  The buildroot repo downloads this one when the time comes to compile the kernel.

I very much doubt the errors you are seeing are due to insufficient memory.  If this were the case you would see log messages about the kernel OOM (out-of-memory) handler killing random processes.

It is *much* more likely that the errors you are seeing are due to the CPU not having an MMU.  This means certain multitasking functions like fork() are unavailable, and AFAIK it is not possible to use the mmap() function either.  It is odd that you are getting a kernel panic though - normally it's just a userspace segfault when a program tries to use one of these functions (if that program can even be compiled in the first place.)

Have you tried compiling the git repo of my kernel port?  That might give you another data point as to whether it is the kernel or busybox at fault.  On that note, is there any chance you can post the BFLT BusyBox binary you are using? (maybe over in the other thread.)  I can't finish porting the rest of the kernel until I can boot it to userspace, and I can't do that because I'm still unable to produce any BFLT binaries.  Perhaps if I can run yours I will be able to finish the port.

Ah right - yes if there is a specific 'make xipImage' command then I would imagine that takes care of making an uncompressed image.  Otherwise you should still be able to find the uncompressed one somewhere in arch/arm/boot/

6MB is just the size of the kernel I was building, which didn't have a whole lot of drivers in it, but had a fair bit of everything else.  If you take out things you won't need (iptables firewall, IPv6, FAT filesystem for SD cards, etc.) then you can of course shrink it down further.  I'm not sure what the minimum size would be.  Also I think I may have been including a BusyBox binary in the initramfs, which would also make the kernel a bit larger but is kind of a requirement, unless you are using root-over-NFS.

It sounds like the start address is not the one you should be changing, given the effect it has had.  Which option are you actually setting?  Looking at the kernel config, under "Boot options", selecting "Kernel Execute-In-Place from ROM" reveals an option just below it called "XIP Kernel Physical Location".  I would think this is the place to set it?

But remember that at the end of the day, the only benefit of using a XIP kernel is to free up more RAM, so are you short of RAM to begin with?  If your running system has plenty of free memory, then all a XIP kernel is going to do is give you even more unused memory, at the expense of making the kernel less functional.