V6 ability for pcm hammer.

[NSFW]

Well ive got a kernel loading comes up as kernel version 0000000 tries to read but can't find any info

[05:46:11:811] Kernel Version: 00000000
[05:46:11:819] kernel uploaded to PCM succesfully. Requesting data...

The "version 0000" thing might be due to the app not getting a response from the version request. That would also count as a bug in the app, and I'd want to fix it...

What version number is the kernel expected to send back? If the kernel isn't able to send messages to the app, that would explain the errors in that log.

I haven't been following the V6 thread, do you guys know the addresses of the registers of the data link controller chip? And do you know whether it's the same DLC chip as the P01 and P59 PCMs?

The communications code was one of the harder parts of the kernel to get right, because there's no way to get information about what's going wrong until it finally works. But once that's working, it gets a lot easier to work on the rest of it.

[Vampyre]

yeah we have all the correct data for comms now just gotta implement it

[Gampy]

Yea, and has already been identified as requiring a pretty heavy re-write of PcmHammer and Kernel.

All due to the fact that the factory mode 36 in the P04 is limited to 1 packet of 4096 (I believe) bytes or less.

Combine that with a packet size limit of 1024 bytes (to work with most tools).

That means PcmHammer would need to be re-written to handle a main kernel and sub kernels.

The main kernel (first kernel uploaded) would be a mode 36 kernel that can handle multiple packets ...
Then it can receive larger kernels.

This mode 36 kernel is likely going to have to be done in Assembly to fit in a 1024 byte packet.

All this has already been covered in this thread.

Not to mention the following issue ...
The most likely reason for the 000000 kernel version is the DLC code (WriteMessage() specific) for it does not play well with the P04.

[Vampyre]

hey gampy did i get these correct?

#define DLC_CONFIGURATION (*(unsigned char *)0x00FFE800)
#define DLC_INTERRUPTCONFIGURATION (*(unsigned char *)0x00FFE800)
#define DLC_TRANSMIT_COMMAND (*(unsigned char *)0x00FFE800)
#define DLC_TRANSMIT_FIFO (*(unsigned char *)0x00FFE801)
#define DLC_STATUS (*(unsigned char *)0x00FFE800)
#define DLC_RECEIVE_FIFO (*(unsigned char *)0x00FFE801)
#define WATCHDOG1 (*(unsigned char *)0x00FFFA27)
#define WATCHDOG2 (*(unsigned char *)0x00FFC006)

[Vampyre]

im having a hard time getting my kernel to even compile half the time. I remove a small piece of data I feel has no relevance and would make the kernel smaller and poof wont compile.
any thing I try and remove in red wont allow compile even though I can find any other reference to it to cause errors.
// Lock and unlock refers to the internal +12v supply to the flash chip, needed for erasing and writing.
void FlashLock();
void FlashUnlock();

// Functions prefixed with Intel512 work with this chip ID
#define FLASH_ID_INTEL_512 0x00894471

#define FLASH_ID_INTEL_1024 0x0089889D
uint32_t Intel_GetFlashId();
uint8_t Intel_EraseBlock(uint32_t address);
uint8_t Intel_WriteToFlash(unsigned int payloadLengthInBytes, unsigned int startAddress, unsigned char *payloadBytes, int testWrite);

// Functions prefixed with Amd1024 work with this chip ID
#define FLASH_ID_AMD_1024 0x00012258

uint32_t Amd_GetFlashId();
uint8_t Amd_EraseBlock(uint32_t address);
uint8_t Amd_WriteToFlash(unsigned int payloadLengthInBytes, unsigned int startAddress, unsigned char* payloadBytes, int testWrite);


[Vampyre]

nsfw I edit hammer14 with the changes you made for the P04 branch and got it all working to distinguish between p01/p59 and p04 even pulls a perfect file with gampys read kernel. few errors with finding chipid and the crc stuff but that can be easily fixed

[NSFW]

Wow, that's great progress.

[Gampy]

Addresses, best to look here

If you remove something and the compiler complains about it, then it still knows about it, thus it has not all been removed!
Keep looking ... Best thing to do is follow the process. IE. learn the code path from the beginning.

Code: Select all

KernelStart(void)

And remember that there is also files other then .c that may contain references to removed code.

few errors with finding chipid and the crc stuff but that can be easily fixed

Not with that test kernel ... never happen, the code just isn't there!

[Vampyre]

gampy for crc and chipId im working on that program side, ive set it up to use hardware ID to ID the chip and crc well tempted to just remove that for now

and thanks gampy I read back through the entire thread and totally missed where you posted that

with compiled kernels im stating to think its issue with the LD file, how do i know what to put here? .kernel_data (0xFFA800) :

did a ton of google searches on how to build kernel from scratch but found nothing even close to what you guys are doing

[Gampy]

how do i know what to put here? .kernel_data (0xFFA800) :

That is where the data segment will be placed in memory.
If it's high it may be out of the memory range, if it's low it will collide with the code segment, and would produce a build error message like,

m68k-elf-ld.exe: section .kernel_data loaded at [00ff9000,00ffa48f] overlaps section .kernel_code loaded at [00ff8000,00ff9ef9]

So, Lets break that down ...

.kernel_code loaded at [00ff8000,00ff9ef9]

The kernel code starts at 00ff8000 and ends at 00ff9ef9
That means the data segment MUST start no lower then 0xff9ef9 + 1 = 0xff9efa

Thus the following would be accurate for this example,

.kernel_data (0xff9efa) :

Although it can be placed higher!

This is where things like the MessageBuffer[...] are placed,

Code: Select all

unsigned char __attribute((section(".kerneldata"))) MessageBuffer[MessageBufferSize];

I suggest placing the data segment after the code segment and removing the data segment address like,

Code: Select all

SECTIONS
{
	.text (0x12340000) :
	{
		main.o
	}

	.kernel_code (0xFF8000) :
	{
		write-kernel.o (.kernelstart)
		write-kernel.o (.text)
		crc.o (.text)
		common.o (.text)
		common-readwrite.o (.text)
		flash.o (.text)
		flash-intel.o (.text)
		flash-amd.o (.text)
	}

	.kernel_data :
	{
		write-kernel.o (.kerneldata)
		common.o (.kerneldata)
		crc.o (.kerneldata)
	}
}

That will stack the data segment at the end of the code segment ... Then it no longer needs to be a concern unless a global variable is added without being properly declared.