S32G3 RDB3 loads sja1110 firmware

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32G3 RDB3 loads sja1110 firmware

Jump to solution
247 Views
XD
Contributor I

Hi,

I built the SJA1110 firmware using the s32g_vnp_rdb example from the SJA1110 S32SDK (v1.0.2), with the default PHY/port configuration matching the Ethernet Enablement User Guide(configuration 1). I followed the guide's steps, copying 'flash_image.bin' to '/lib/firmware' and renaming it to 'sja1110_uc.bin'. I also shorted J189 pins 1-2 and 3-4 as instructed.

However, after the system boots, I am encountering the following error.

I am using BSP 41, rdb3 board. Could you advise on the issue?

 

 

 

root@s32g399ardb3:~# dmesg | grep sja
[    0.593176] gpio-24 (sja1110-rst-phy-t1): hogged as output/low
[    0.598590] gpio-81 (sja1110-rst-core): hogged as output/low
[    0.662639] sja1110-sw@1 enforce active low on chipselect handle
[    6.526684] sja1110: loading out-of-tree module taints kernel.
[    6.527145] SPI driver sja1110 has no spi_device_id for nxp,sja1110-switch
[    6.527150] SPI driver sja1110 has no spi_device_id for nxp,sja1110-uc
[    6.527222] sja1110 spi5.0: probing uc
[    6.527312] sja1110 spi5.1: probing switch
[    6.527523] sja1110 spi5.1: Could not get GPIO from device tree
[    6.528761] sja1110 spi5.1: [sja1110_post_probe_upload_worker] Trying to initialize switch
[    6.528863] sja1110 spi5.1: Direct firmware load for sja1110_switch.bin failed with error -2
[    6.528875] sja1110 spi5.1: request_firmware failed with -2
[    6.528881] sja1110 spi5.0: [sja1110_post_probe_upload_worker] Trying to initialize uC
[    6.529254] sja1110 spi5.0: [sja1110_init_hw] loaded fw 'sja1110_uc.bin'
[    6.529261] sja1110 spi5.0: [sja1110_pre_uc_upload] Found firmware of size 126400
[    6.529267] sja1110 spi5.0: Invalid firmware header
[    6.529271] sja1110 spi5.0: checking firmware failed with -22
root@s32g399ardb3:~#
root@s32g399ardb3:~# ls /lib/firmware/sja*
/lib/firmware/sja1110_uc.bin
root@s32g399ardb3:~#

 

 

 

Thanks,

XD

0 Kudos
Reply
1 Solution
221 Views
GuilhermeS32G3
Contributor III

Hello @XD ,

 

We can take a look at this piece of code:

https://github.com/nxp-archive/autoivnsw_sja1110_linux/blob/master/sja1110_init.c#L533-L549

It first calls the function sja1110_uc_read_status(sja1110, &uc_status); for reading the status of the SJA1110 uC.

For some reason, it is returning a non-zero value, that indicates an error.

The reason why you are seeing so many status errors is due to the number of retries:

retry = 10;

It will try to read the status for 10 times, and if it does not work, it eventually gives up.

 

Then, to answer your other question, why the switch seems to work even if the firmware uploads failed, I think it is related to this part of the code (lines 704-709):

out_release:
	release_firmware(fw);
out_return:
	mutex_unlock(&sja1110->lock);
	return ret;
}

 

It only uses the new firmware when it was successfully uploaded and verified (release_firmware).

If there is an error, I believe it will still load the default firmware from the NOR-flash memory.

 

Please take a look at the @Celeste_Liu reply on my previous question:

It seems your output now is the same as she shows before the successful upload.

I would recommend verify that the J189 pins are indeed short and to verify that the problem is not your firmware use the one from NXP GoldVIP binaries.

 

Best regards,

Guilherme

View solution in original post

0 Kudos
Reply
4 Replies
228 Views
GuilhermeS32G3
Contributor III

Hello @XD ,

 

Thanks for your post.

The error that you are seeing is

[    6.529267] sja1110 spi5.0: Invalid firmware header

For a better understanding, please take a look at this source code:

https://github.com/nxp-archive/autoivnsw_sja1110_linux/blob/master/sja1110_init.c#L513-L522

When reading the firmware, the sja1110 kernel module starts by comparing the first bytes to the expected header, defined here:

https://github.com/nxp-archive/autoivnsw_sja1110_linux/blob/master/sja1110_init.h#L51

#define IMAGE_VALID_MARKER   {0x6A,0xA6,0x6A,0xA6,0x6A,0xA6,0x6A,0xA6}

If you have access to a Hex editor, in Linux you may use:

hd -C sja1110_uc.bin

for displaying the Hex contents of the file. On Windows, I suggest HxD.

The first 8 bytes of the firmware should be:

00000000 6a a6 6a a6 6a a6 6a a6

 If this is not the case, then our firmware is not valid.

Some suggestions:

  • When you build a new firmware using the S32 SDK for SJA1110, make sure you press the button "Update Code", so that any changes are accounted in the generation of the new firmware;
  • You may also download these firmware files from the GoldVIP-S32G3 binaries from NXP Software Package Manager:

https://www.nxp.com/app-autopackagemgr/software-package-manager:AUTO-SW-PACKAGE-MANAGER?currentTab=0

GuilhermeS32G3_0-1728607773420.png

GuilhermeS32G3_1-1728607807110.png

and use them to compare the output with the current firmware.

 

Best regards,

Guilherme

 

0 Kudos
Reply
224 Views
XD
Contributor I

Hi @GuilhermeS32G3 

Thank you for your suggestion. 

You were right—the file contents seem to have been invalid, possibly because I power cycled the board too early before the file system had time to sync. After redoing the file copy, I encountered a different error message. Do you have any insight into why there are so many status errors, eventually leading to a -22 return code?

Also, it's interesting that regardless of whether the firmware loads correctly, the PFE0 port always works. I believe it's connected to switch port 4. Does this imply that the switch can operate in unmanaged mode without the firmware being loaded? I was expecting the port to remain down in this case.

 

[    0.593408] gpio-24 (sja1110-rst-phy-t1): hogged as output/low
[    0.598822] gpio-81 (sja1110-rst-core): hogged as output/low
[    0.662918] sja1110-sw@1 enforce active low on chipselect handle
[    6.590973] sja1110: loading out-of-tree module taints kernel.
[    6.591398] SPI driver sja1110 has no spi_device_id for nxp,sja1110-switch
[    6.591402] SPI driver sja1110 has no spi_device_id for nxp,sja1110-uc
[    6.591466] sja1110 spi5.0: probing uc
[    6.591534] sja1110 spi5.1: probing switch
[    6.591731] sja1110 spi5.1: Could not get GPIO from device tree
[    6.591750] sja1110 spi5.1: [sja1110_post_probe_upload_worker] Trying to initialize switch
[    6.591820] sja1110 spi5.1: Direct firmware load for sja1110_switch.bin failed with error -2
[    6.591829] sja1110 spi5.1: request_firmware failed with -2
[    6.591835] sja1110 spi5.0: [sja1110_post_probe_upload_worker] Trying to initialize uC
[    6.600417] sja1110 spi5.0: [sja1110_init_hw] loaded fw 'sja1110_uc.bin'
[    6.600427] sja1110 spi5.0: [sja1110_pre_uc_upload] Found firmware of size 126400
[    6.606948] sja1110 spi5.0: [sja1110_pre_uc_upload] firmware appears to be valid
[    6.613448] sja1110 spi5.0: [sja1110_pre_uc_upload] \xc2\xb5C not ready for download (Status=0x31)
[    6.617179] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.617185] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.617190] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.621261] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.621267] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.621272] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.627161] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.627167] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.627172] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.635410] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.635416] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.635421] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.643830] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.643836] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.643841] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.649383] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.649389] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.649394] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.657467] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.657474] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.657478] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.664234] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.664240] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.664245] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.664292] sja1110 spi5.0: [sja1110_uc_parse_status] Invalid status header (0xfb)
[    6.664297] sja1110 spi5.0: [sja1110_uc_read_status] Parsing uC status failed with -22
[    6.664302] sja1110 spi5.0: [sja1110_pre_uc_upload] Could not read \xc2\xb5C status
[    6.664306] sja1110 spi5.0: checking firmware failed with -22

 

Thanks,

XD

 

0 Kudos
Reply
222 Views
GuilhermeS32G3
Contributor III

Hello @XD ,

 

We can take a look at this piece of code:

https://github.com/nxp-archive/autoivnsw_sja1110_linux/blob/master/sja1110_init.c#L533-L549

It first calls the function sja1110_uc_read_status(sja1110, &uc_status); for reading the status of the SJA1110 uC.

For some reason, it is returning a non-zero value, that indicates an error.

The reason why you are seeing so many status errors is due to the number of retries:

retry = 10;

It will try to read the status for 10 times, and if it does not work, it eventually gives up.

 

Then, to answer your other question, why the switch seems to work even if the firmware uploads failed, I think it is related to this part of the code (lines 704-709):

out_release:
	release_firmware(fw);
out_return:
	mutex_unlock(&sja1110->lock);
	return ret;
}

 

It only uses the new firmware when it was successfully uploaded and verified (release_firmware).

If there is an error, I believe it will still load the default firmware from the NOR-flash memory.

 

Please take a look at the @Celeste_Liu reply on my previous question:

It seems your output now is the same as she shows before the successful upload.

I would recommend verify that the J189 pins are indeed short and to verify that the problem is not your firmware use the one from NXP GoldVIP binaries.

 

Best regards,

Guilherme

0 Kudos
Reply
183 Views
XD
Contributor I

Hi @GuilhermeS32G3 

You are absolutely right. After I switched to the smaller jumper that came with the RDB box, the firmware loading behavior is as expected. Both the default 2.5G and 1G config firmware appear to be working now. Thank you for your help; I really appreciate it.

Thanks,

XD

0 Kudos
Reply