How to force SAM9G45 to boot sam-ba monitor instead of firmware

[framp]

I try to help somebody to recover lost data which hopefully is still available in NAND of SAM9G45. Therefore I installed SAM-BA 2.18 for Linux on my Laptop in order to connect via USB CDC to SAM9 and dump all the data from NAND via SAM-BA on my system for further data recovery actions.

Now I have to get SAM9 to enter monitor mode and the SAM-BA GUI and/or CLI can access the system via /dev/ttyACM0 to dump all the data.

I started to ask for help on this issue in another forum and got following instructions from fzabkar how to achieve this:

The Soc has a mask ROM which enables it to POST and set up the USB port. It also contains the code for the SAM-BA monitor. At the time of manufacture, the NAND flash is vacant

During the post, the SoC looks for boot devices. If it doesn't find any, it invokes its SAM-BA monitor and waits for commands from the USB-serial device. The designer then uploads his application code (eg JamMan) into block #0 of the NAND flash memory using an appropriate SAM-BA tool. He could alternatively use the SAM-BA commands directly, but the tool makes this a lot easier and safer. Block #0 is guaranteed to be good by the NAND manufacturer. The remainder of the NAND is used to stored the guitar loops.

AISI, you need to temporarily ground the NAND's Ready/Busy* pin during the POST in order to invalidate it. The SoC is then unable to find a boot device, which then causes it to invoke its SAM-BA monitor. AFAICT, you should be able to confirm that SAM-BA is active by typing "V" (Display Version) via a terminal program such as PuTTY or HyperTerminal.

If you get this far, then you should be able to read and write to NAND flash. You may need to configure the address spaces first, though.

As for the OS, ISTM that this is transparent and therefore irrelevant.

I should add that R/B* should only be grounded until the monitor is active. It should then be released from ground.

Once again, I think that the AT91 forum is a much better place for support. I would at least ask for confirmation from one of their engineers before proceeding with my suggestions.

Can you please confirm his instructions are the right way to get SAM9 to boot in monitor mode without cleaning the NAND data?

Thank you very much.

[nferre]

Hi,

What fzabkar says is right. You can confirm this by reading the "11. Boot Strategies" chapter in the sam9g45 datasheet where the NAND flash boot process is explained.

to confirm that SAM-BA is active by typing "V" (Display Version) via a terminal program

One precision, it's "V#" that has to be entered on the RomCode command line to display version (Chapter "11.5.1 Command list" of the datasheet). Indeed, it's a very good way to know that your boot code doesn't run anymore and that you can connect to SAM-BA monitor to be able to launch SAM-BA host program.
Once you have confirmed, keep the same setup and reset the SoC so that you can connect SAM-BA through USB.
Once your SAM-BA program is connected to the SoC, you can replace the NAND CS so that you regain access to that flash and its content.

Best regards,
Nicolas

[framp]

Great! Thank you very much for confirming. I now have a much better feeling I will be able to access the NAND data

I already tried to understand the boot strategies (It's Chapter 10 in my doc, not 11 (Atmel-6438O-ATARM-SAM9G45-Datasheet_08-Dec-15.)) and have a rough idea how it works. But I wasn't able to confirm the temporary grounding of R/B* will disable the NVM detection. In particular because R/B* is marked as an output signal. I would expect it to be an input signal.

I also checked https://4donline.ihs.com/images/VipMast ... 9293-1.pdf for the two pins I have to connect: R/B* and Vss and I noticed R/B* is Pin 7 and Vss is available on Pin 13,25,36 and 48. I'm a SW engineer but no electrical engineer and have no experience how to connect these two pins during POST without touching other pins by error. I'd appreciate to get any advice on this

Once your SAM-BA program is connected to the SoC, you can replace the NAND CS so that you regain access to that flash

Do I get it right CS is the chip select line and in this case is just to remove the ground from R/B* when the POST finished or do you mean something else?

[blue_z]

I now have a much better feeling I will be able to access the NAND data

I think you're underestimating the task, and may be using the wrong approach.

The SAM-BA utility only supports Atmel evaluation boards/kits.
You would need to study the application note on SAM-BA 2.x customization, and modify the program to support the JamMan board.
A salient difference is that the Atmel boards AFAIK only use 8-bit NAND interfaces, whereas the JamMan has a 16-bit interface.

IMO blindly dumping the NAND flash entails more work than necessary.
Fzabkar has several erroneous assumptions (e.g. the OS (when there is one) is not "irrelevant", and block #0 does not contain the JamMan application code but instead a small bootloader program), and seems to apply micro-controller concepts to this board.

The first thing I always look for on the board is the serial console header, which is typically 3 or 4 pins (but the photos of the JamMan indicate there may not be one).
You probably need to probe the 5 pins labeled "PA2" with a 'scope to determine if that is a USB port or the DBGU port.
Obtaining the boot log, determining if the system is executing a standalone or a Linux application, and maybe even logging into the system can save a lot of time over reviewing a NAND dump.

Regards

[framp]

IMO blindly dumping the NAND flash entails more work than necessary.
...
The first thing I always look for on the board is the serial console header, which is typically 3 or 4 pins (but the photos of the JamMan indicate there may not be one).
You probably need to probe the 5 pins labeled "PA2" with a 'scope to determine if that is a USB port or the DBGU port.
Obtaining the boot log, determining if the system is executing a standalone or a Linux application, and maybe even logging into the system can save a lot of time over reviewing a NAND dump.

Frankly this was also my initial thought: Just connect via a serial console and login into the running os and hope it's a Linux. Then it may be relatively easy to dump the data on the external SD card. This also has the advantage I don't have to connect two pins to force a boot in SAM monitor mode - given the fact I have no idea until now how to get this done fail safe.
I didn't see the PA2 pins which may be an USB or DBGU port. Unfortunately I neither have any scope nor any idea how to analyze the signals on the pins

Yes, you are right, JamMan uses a 16bit NAND. Why do you thing this will complicate the dump of the NAND data with SAM MON?

[blue_z]

Unfortunately I neither have any scope nor any idea how to analyze the signals on the pins

At the very least you could measure the voltages of each pin with a voltmeter/multimeter. (There's really no excuse for not having a multimeter; it doesn't have to be a $200 Fluke.)

Yes, you are right, JamMan uses a 16bit NAND. Why do you thing this will complicate the dump of the NAND data with SAM MON?

(SAM MON? Don't start making up your own names.)
The SAM-BA monitor only provides a simple interface to read and write memory, and transfer memory data with the host.
To properly utilize this interface you need the SAM-BA utility, which executes on a PC host.

The memory data transfer capability is exploited by the SAM-BA utility to download & execute "applets", which are simple standalone programs compiled for the ARM target board.
The SAM-BA utility only has applets written and built for existing Atmel boards (i.e. the list of supported boards).
To connect to the JamMan board with the SAM-BA utility, you need customized applets, such as a NAND initialization code that is unlike any Atmel board.
This is all described in the application note that I already mentioned.

FYI data stored in NAND flash is not directly accessible from the ARM processor's address space.
Therefore the SAM-BA monitor cannot simply "read" NAND data using its basic R/W capabilities.
You need to use an applet (or NAND device driver) to retrieve the contents of NAND flash.

Regards

[framp]

At the very least you could measure the voltages of each pin with a voltmeter/multimeter. (There's really no excuse for not having a multimeter; it doesn't have to be a $200 Fluke.)

That's a good idea. I have a multimeter

(SAM MON? Don't start making up your own names.)

My fault. I meant SAM-BA which I already installed on my Linux Laptop.

FYI data stored in NAND flash is not directly accessible from the ARM processor's address space.
Therefore the SAM-BA monitor cannot simply "read" NAND data using its basic R/W capabilities.
You need to use an applet (or NAND device driver) to retrieve the contents of NAND flash.

As far as I understand the SAM-BA actually uses existing applets to retrieve the data from NAND. I already checked some applets and saw they are written in TCL. Sound's I may have to customize them for 16bit.
When you talk about a NAND device driver I think you mean a Linux device driver. That's an advantage if there is a Linux up and running.

Unfortunately I cannot continue to follow your advises on this issue for now because I will get physical access in two months time.

Maybe I start learning and programming in TCL

[blue_z]

As far as I understand the SAM-BA actually uses existing applets to retrieve the data from NAND.

What is the source of your understanding?
SAM-BA documentatiton states:

Customers can use SAM-BA as a tool to program their own board, designed by themselves. But, SAM-BA default settings are based on Atmel ARM-based evaluation kits and customers might have different crystals and memories on their own design. In that case SAM-BA needs to be customized.

I already checked some applets and saw they are written in TCL.

Then you have not found the SAM-BA applets, which are written in C and the source code resides in the sam-ba_XXX/applets/ subdirectory.
SAM-BA documentatiton states:

In case users want to use SAM-BA on their own custom board, which is different from the Atmel Evaluation Kit, they may need to adapt the code of the applets and recompile some of them. All the sources are provided with the SAM-BA installer, and the applets are written in C.

When you talk about a NAND device driver I think you mean a Linux device driver.

No, you are thinking incorrectly. I am referring to a generic driver that could be in the Atmel Software Package or U-Boot or any kernel.

Unfortunately I cannot continue to follow your advises on this issue for now because I will get physical access in two months time.

Then the experience of trying fzabkar's (inaccurate) advice is postponed.
The Ready/Busy* signal is not a defined or requisite input to this SoC's NAND interface, so the ROM bootloader ignores any activity on that pin.

Regards

[framp]

I understand now it's most probably not that easy to use the existing SAM-BA OOTB but requires customization . So I will first try to get access to the system via the PA2 pins if that's possible and secondly go the SAM-BA path.

Then the experience of trying fzabkar's (inaccurate) advice is postponed.
The Ready/Busy* signal is not a defined or requisite input to this SoC's NAND interface, so the ROM bootloader ignores any activity on that pin.

As I wrote the SAM-BA path is my second preference now. But I'm also confused now @nferre confirmed the instructions from @fzabkar are correct but you tell me any activity on R/B* will be ignored. Who is right? Do you know how to force SAM9G45 to boot SAM-BA monitor instead of the firmware other than to set R/B* to ground?

[nferre]

Hi,

Sorry for the confusion: R/B* is often ignored indeed, as blue_z says.

I had in mind the use of CE line actually. And indeed, by removing the CE signal you're able to prevent the access to NAND flash chip. I was more concentrated on the possibility to prevent access to the NAND flash chip than being accurate about the signal to remove for doing so.
I don't know if it's doable to have an action on Chip-Enable on your board though.

Best regards,
Nicolas

[framp]

The first thing I always look for on the board is the serial console header, which is typically 3 or 4 pins (but the photos of the JamMan indicate there may not be one).
You probably need to probe the 5 pins labeled "PA2" with a 'scope to determine if that is a USB port or the DBGU port.
Obtaining the boot log, determining if the system is executing a standalone or a Linux application, and maybe even logging into the system can save a lot of time over reviewing a NAND dump.

I now have physical access to the board .
Next step was to install windows10 in a VM on my Linux box and install a windows app which allows to manage the data on the box. I connected the box via USB on my VM and ran a serial data analyzer when copying existing data from internal storage to an external SD card. Most of the data was binary but some plain text showed up

Code: Select all

/mnt/nandfs/JamManStereo
/mnt/sdfs/JamManStereo/

That's Unix naming of mounts which proves there is some Unix OS running on the box - most probably a Linux OS. That's why I now want to go your path @blue_z and check whether there is some way to connect via a serial console.

Actually I'm now OT because I don't follow the sam-ba boot path of my thread subject any more. But I continue for now because @blue_z suggested to use a multimeter to check the 5 pins labeled "PA2". Would be great to detect a Unix serial console there and use Unix commands to inspect the nandfs. Unfortunately I have no clue how to discover the different RS232 pins with a multimeter. I appreciate any advice on this.

If that's a boring question for you just let me know.

[blue_z]

That's Unix naming of mounts which proves there is some Unix OS running on the box - most probably a Linux OS.
...
Would be great to detect a Unix serial console there and use Unix commands to inspect the nandfs.

Do not conflate Unix and Linux.
The user API is very similar since they're both POSIX compliant, but the kernels and licensing are quite different.

...because @blue_z suggested to use a multimeter to check the 5 pins labeled "PA2".

Actually I mentioned a preference for using a 'scope.
So did you measure any voltages?

Regards

[framp]

At the very least you could measure the voltages of each pin with a voltmeter/multimeter. (There's really no excuse for not having a multimeter; it doesn't have to be a $200 Fluke.)

In order to measure the voltage I identified the leftmost pin as ground.
Voltage is (from left to right)

Code: Select all

Pin   Vcc
1        0 
2        3.32V
3        0
4        0.94V
5        3.32 (squared pin hole)

I noticed the resistance from pin 1 (gnd) to the other pins is 0 Ohms. For pin 5 it was approx 600 Ohms when I initially just measured the resistances between the pins and later on, when I had turned on the box and measured voltage and then turned the box off again I measured approx 1.2 kOhms

As far as I understand I should measure -3 to -15V or +3 to +15V on the pins (TX,RX, RTR,CTS). Now the question is which pin has or may have which function. Any hint is greatly appreciated.

The user API is very similar since they're both POSIX compliant, but the kernels and licensing are quite different.

I know. That's why Linux is omnipresent in most embedded systems.

[blue_z]

In order to measure the voltage I identified the leftmost pin as ground.

Or even better, use a known ground point such as at the power connector.

Voltage is (from left to right)

Code: Select all

Pin   Vcc
1        0 
2        3.32V
3        0
4        0.94V
5        3.32 (squared pin hole)

You've numbered the holes in reverse order.
The hole with the square solder-pad is for pin number 1.

Those voltages are not appropriate for a USB port.
They could represent a UART interface (plus power), i.e. the serial console.

As far as I understand I should measure -3 to -15V or +3 to +15V on the pins (TX,RX, RTR,CTS). Now the question is which pin has or may have which function. Any hint is greatly appreciated.

You're confusing RS-232 voltage levels with UART TTL voltages.
RS-232 requires an additional chip (a line-driver/receiver chip aka transceiver) which is rarely installed for a port that does not have an exposed (DB9) connector.

One of those 3.3V contacts could be Vcc, and the other could be TxD.
The 1 volt contact could be RxD.
I prefer to use a 'scope to detect the UART TxD signal.
If you presume that the TxD is 115200 8N1, then you could try connecting a USB-to-TTL_serial converter or a TTL-to-RS232 converter.

Regards

[framp]

Thank you very much blue_z for you comments. I see I'm off the track with RS232 and I have to go with UART TTL. So I have to buy an USB UART TTL converter and connect it to the pins the right way. Do you have any converter you can recommend?

I found some which have GND, RxD, TxD, DTR/RTR and CTS and Vcc (3.3 V or 5 V) . As far as I understand I have to use a Vcc 3.3 V converter. You mentioned Pin 1 or Pin 4 to be Vcc. This makes me nervous because I don't want to create a short circuit and destroy the UART interface electronic and I have to be carefully with GND and Vcc.

I understand a scope will help to better identify the pins. Do you have any recommendation for a cheap scope I can buy?