Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added script to prepare bcm43438 ucode for disassembling #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

DanielAW
Copy link

The format of the bcm43438 ucode used in the Raspberry Pi 3 needs preparation before it can be disassembled. This is handled in the ARM firmware before copying the code to the d11 core.

With this script I was able to disassemble bcm43438 ucode. During disassembling I got the following Warnings:

Disassembler warning:
  NAP: invalid first argument 0x0000

Disassembler warning:
  NAP: invalid second argument 0x0000

Disassembler warning:
  NAP: invalid first argument 0x0000

Disassembler warning:
  NAP: invalid second argument 0x0000

Disassembler warning:
  NAP: invalid first argument 0x0000

Disassembler warning:
  NAP: invalid second argument 0x0000

I was also able to assemble the resulting code back to a binary and using the script to get the code back to the original binary representation. Despite the missing argument for the NAP instruction, the reassembled code runs fine on the Rapsberry Pi 3.

@DanielAW
Copy link
Author

Its a Perl script for now, @mbuesch already mentioned that it would be the best to have some kind of parameter in the disassembler and assembler comand in the future.

I'm not sure if a automatic detection is possible.

@mbuesch
Copy link
Owner

mbuesch commented Aug 24, 2016

  • I don't think it's safe to use "I" packing. That depends on the host endianness.
  • Why do you use sprintf and then hex string packing. That seems overly complex.
  • and I don't really get why the forward path does +=7, but the backward path does +=8, but only writes 7 bytes.

But as I said, I won't merge this. We leave have it here on github as a hack, but a proper fix would simply fix the disassembler/assembler code read/write routines.

@DanielAW
Copy link
Author

and I don't really get why the forward path does +=7, but the backward path does +=8, but only writes 7 bytes.

They sort of throw the 8th byte away, I think its for saving space. The other way arround: I think they have to add a zero byte for padding.

But as I said, I won't merge this. We leave have it here on github as a hack, but a proper fix would simply fix the disassembler/assembler code read/write routines.

Totally fine by me 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants