Quote:
Originally Posted by wishindo
scsi_mod: disagrees about version of symbol dump_stack
scsi_mod: Unknown symbol dump_stack
The solution to this seems to be use Module.symvers to build the modules against, but find / -name Module.symvers returns nothing. I might flash a kernel if we can't get the symbol versions.
|
A couple of things that you should do to troubleshoot this:
- What is the output of uname -a and modinfo ${YOUR_KERNEL_MODULE}? The vermagic field from modinfo should match the kernel metadata exactly
- Diff (git diff --no-index config_a config_b) the .config generated from the defconfig for your device on your build PC and the config from /proc/ on the Kindle. Are any config options set on the config from the Kindle that are not set on the config from your build environment?
This article might be helpful too - there's a bit about extracting Modules.symvers from a zImage (you can get this from a uImage by chopping off the first 64 bytes IIRC) :
Building a Linux kernel module without the exact kernel headers
Quote:
Originally Posted by wishindo
I have many USB to UART adapters (including a Bus Pirate v3.6), but what does "some means of recovery" refer to? Also, where is the serial port? Didn't see any labeled test points on the mainboard when I looked at mine.
|
The simplest way would be to backup the existing kernel on your device to your PC and familiarise yourself with booting into diags mode via U-Boot. This means that even if your kernel fails to boot, you can still copy the original kernel back to the Kindle over USB and reflash it using DD. A safer (and probably quicker) way to tackle kernel development and testing is to just load the kernel into memory and boot that instead of flashing it. I
covered this process here but haven't tested if it works on a K3 so, YMMV.
The serial port on K3
is documented here - you want an adapter capable of 1.8v; the baud rate is the usual 115200 8N1.