NWR04B: Rebooting, set\_vpp
20 Dec 2005Up way too late for this sort of thing, but I can't sleep.
Managed to get rebooting working. I'd had a jerry-rigged workaround:
use devmem2 to read the magic location, 0x88000004
. The weird thing
was, that was already in the kernel, at
include/asm-armnommu/mach-cx84200/system.h
:
extern inline void arch_reset(char mode)
{
/* REVISIT --gmcnutt */
#define CX84200_RESET 0x88000004
int data;
data = *(__u8 *)(CX84200_RESET);
}
So what the hell? Just for fun, I tried sticking this in at the end of the function:
printk (KERN_EMERG "Did that work? data = 0x%08x\n", data);
And sure enough, bam! There I am rebooting. I'm guessing the compiler was optimizing away the read, since it was never used or returned...but that seems like an obvious thing to overlook. Hm. Can't deny that it's working, though. Interestingly, a simple:
return data;
does not seem to work. The plot thickens.
Also managed to find another chip driver that has to twiddle GPIO in
order to write to flash, and it looks like there's a standard place to
put this: the set_vpp
member (part?) of the map_info
structure
that is deep, deep at the heart of the MTD driver system. Along with
the usual stuff you might expect to find there -- how to read 8 bytes,
how to write 16 bytes, and so on -- there is this bit that the Dilnet
PC board uses to twiddle GPIO in what looks like a most familiar
way. I may manage to soothe baby Linus before long.
Update: Ashtead provided the answer: declare data
as
volatile
, so GCC doesn't optimize away the read.
Add a comment:
Name and email required; email is not displayed.
Related Posts
QRP weekend 08 Oct 2018
Open Source Cubesat Workshop 2018 03 Oct 2018
mpd crash? try removing files in /var/lib/mpd/ 11 Aug 2018