RE: [PATCH v2 6/6] cmd: nand: Add new optional sub-command 'onfi'

2024-03-22 Thread Mihai.Sain
Hi Michael,

---

I think this command can be really useful.
Let try to have more testing on more boards

-

I managed to test the command on sama7g54-curiosity board.

I also forced timing mode 5 from controller driver (conf->timings.sdr.tRC_min < 
2).

=> nand onfi 0
=> hsmc decode

MCK rate: 200 MHz

HSMC_SETUP3:0x0004
HSMC_PULSE3:0x140a140a
HSMC_CYCLE3:0x00140014
HSMC_TIMINGS3:  0x880805f4
HSMC_MODE3: 0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 20 (100 ns), hold: 0 (0 ns), cycle: 20 (100 ns)
   NRD: setup: 0 (0 ns), pulse: 10 (50 ns), hold: 10 (50 ns), cycle: 20 (100 ns)
NCS_WR: setup: 0 (0 ns), pulse: 20 (100 ns), hold: 0 (0 ns), cycle: 20 (100 ns)
   NWE: setup: 4 (20 ns), pulse: 10 (50 ns), hold: 6 (30 ns), cycle: 20 (100 ns)
TDF optimization enabled
TDF cycles: 15 (75 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal
NFSEL (NAND Flash Selection) is set
OCMS (Off Chip Memory Scrambling) is disabled
TWB (WEN High to REN to Busy): 64 (320 ns)
TRR (Ready to REN Low Delay):  64 (320 ns)
TAR (ALE to REN Low Delay):5 (25 ns)
TADL (ALE to Data Start):  71 (355 ns)
TCLR (CLE to REN Low Delay):   4 (20 ns)

=> time nand torture 0x100 0x100

NAND torture: device 0 offset 0x100 size 0x100 (block size 0x4)
 Passed: 64, failed: 0

time: 22.638 seconds

=> nand onfi 5
=> hsmc decode

MCK rate: 200 MHz

HSMC_SETUP3:0x0001
HSMC_PULSE3:0x07040502
HSMC_CYCLE3:0x00070005
HSMC_TIMINGS3:  0x880402f2
HSMC_MODE3: 0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
   NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns)
NCS_WR: setup: 0 (0 ns), pulse: 5 (25 ns), hold: 0 (0 ns), cycle: 5 (25 ns)
   NWE: setup: 1 (5 ns), pulse: 2 (10 ns), hold: 2 (10 ns), cycle: 5 (25 ns)
TDF optimization enabled
TDF cycles: 15 (75 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal
NFSEL (NAND Flash Selection) is set
OCMS (Off Chip Memory Scrambling) is disabled
TWB (WEN High to REN to Busy): 64 (320 ns)
TRR (Ready to REN Low Delay):  4 (20 ns)
TAR (ALE to REN Low Delay):2 (10 ns)
TADL (ALE to Data Start):  71 (355 ns)
TCLR (CLE to REN Low Delay):   2 (10 ns)

=> time nand torture 0x100 0x100

NAND torture: device 0 offset 0x100 size 0x100 (block size 0x4)
 Passed: 64, failed: 0

time: 11.661 seconds

=> nand info

Device 0: nand0, sector size 256 KiB
  Manufacturer  MACRONIX
  Model MX30LF4G28AD
  Device size512 MiB
  Page size 4096 b
  OOB size   256 b
  Erase size  262144 b
  ecc strength 8 bits
  ecc step size  512 b
  subpagesize   4096 b
  options   0x40004200
  bbt options   0x00028000

Best regards,
Mihai Sain


RE: [PATCH v2 6/6] cmd: nand: Add new optional sub-command 'onfi'

2024-03-20 Thread Mihai.Sain
Hi Alex,



Override the ONFI timing mode at runtime.

Signed-off-by: Alexander Dahl 
---

I used the same board sam9x75-curiosity to test mode 5 

I forced in nfc driver the mode 5:
+   if (conf->timings.sdr.tRC_min < 2)

And I ran the nand torture on 16 MiB:

=> nand onfi 0
=> hsmc decode

MCK rate: 270 MHz

SMC_SETUP2: 0x0007
SMC_PULSE2: 0x22112211
SMC_CYCLE2: 0x00220022
SMC_MODE2:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 34 (102 ns), hold: 0 (0 ns), cycle: 34 (102 ns)
   NRD: setup: 0 (0 ns), pulse: 17 (51 ns), hold: 17 (51 ns), cycle: 34 (102 ns)
NCS_WR: setup: 0 (0 ns), pulse: 34 (102 ns), hold: 0 (0 ns), cycle: 34 (102 ns)
   NWE: setup: 7 (21 ns), pulse: 17 (51 ns), hold: 10 (30 ns), cycle: 34 (102 
ns)
Standard read applied
TDF optimization enabled
TDF cycles: 15 (45 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

=> time nand torture 0x80 0x100

NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4)
 Passed: 64, failed: 0

time: 30.152 seconds

=> nand onfi 5
=> hsmc decode

MCK rate: 270 MHz

SMC_SETUP2: 0x0001
SMC_PULSE2: 0x0b060804
SMC_CYCLE2: 0x000b0008
SMC_MODE2:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 11 (33 ns), hold: 0 (0 ns), cycle: 11 (33 ns)
   NRD: setup: 0 (0 ns), pulse: 6 (18 ns), hold: 5 (15 ns), cycle: 11 (33 ns)
NCS_WR: setup: 0 (0 ns), pulse: 8 (24 ns), hold: 0 (0 ns), cycle: 8 (24 ns)
   NWE: setup: 1 (3 ns), pulse: 4 (12 ns), hold: 3 (9 ns), cycle: 8 (24 ns)
Standard read applied
TDF optimization enabled
TDF cycles: 15 (45 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

=> time nand torture 0x80 0x100

NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4)
 Passed: 64, failed: 0

time: 15.891 seconds

Best regards,
Mihai Sain


RE: [PATCH v2 6/6] cmd: nand: Add new optional sub-command 'onfi'

2024-03-20 Thread Mihai.Sain
Hi Alex,

--

Override the ONFI timing mode at runtime.

Signed-off-by: Alexander Dahl 
---

Tested-by: Mihai Sain 

I tested your new command on a new board/soc sam9x75-curiosity 
I find it very very useful !
I also rounded the master clock to 270 MHz 
Thanks.

=> nand info

Device 0: nand0, sector size 256 KiB
  Manufacturer  MACRONIX
  Model MX30LF4G28AD
  Device size512 MiB
  Page size 4096 b
  OOB size   256 b
  Erase size  262144 b
  ecc strength 8 bits
  ecc step size  512 b
  subpagesize   4096 b
  options   0x40004200
  bbt options   0x00028000

=> hsmc decode

MCK rate: 270 MHz

SMC_SETUP2: 0x0004
SMC_PULSE2: 0x0c070d05
SMC_CYCLE2: 0x000c000d
SMC_MODE2:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 12 (36 ns), hold: 0 (0 ns), cycle: 12 (36 ns)
   NRD: setup: 0 (0 ns), pulse: 7 (21 ns), hold: 5 (15 ns), cycle: 12 (36 ns)
NCS_WR: setup: 0 (0 ns), pulse: 13 (39 ns), hold: 0 (0 ns), cycle: 13 (39 ns)
   NWE: setup: 4 (12 ns), pulse: 5 (15 ns), hold: 4 (12 ns), cycle: 13 (39 ns)
Standard read applied
TDF optimization enabled
TDF cycles: 15 (45 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

=> nand onfi 2
=> hsmc decode

MCK rate: 270 MHz

SMC_SETUP2: 0x0003
SMC_PULSE2: 0x0e090e06
SMC_CYCLE2: 0x000e000e
SMC_MODE2:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 14 (42 ns), hold: 0 (0 ns), cycle: 14 (42 ns)
   NRD: setup: 0 (0 ns), pulse: 9 (27 ns), hold: 5 (15 ns), cycle: 14 (42 ns)
NCS_WR: setup: 0 (0 ns), pulse: 14 (42 ns), hold: 0 (0 ns), cycle: 14 (42 ns)
   NWE: setup: 3 (9 ns), pulse: 6 (18 ns), hold: 5 (15 ns), cycle: 14 (42 ns)
Standard read applied
TDF optimization enabled
TDF cycles: 15 (45 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

=> nand onfi 1
=> hsmc decode

MCK rate: 270 MHz

SMC_SETUP2: 0x0003
SMC_PULSE2: 0x110a1109
SMC_CYCLE2: 0x00110011
SMC_MODE2:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 17 (51 ns), hold: 0 (0 ns), cycle: 17 (51 ns)
   NRD: setup: 0 (0 ns), pulse: 10 (30 ns), hold: 7 (21 ns), cycle: 17 (51 ns)
NCS_WR: setup: 0 (0 ns), pulse: 17 (51 ns), hold: 0 (0 ns), cycle: 17 (51 ns)
   NWE: setup: 3 (9 ns), pulse: 9 (27 ns), hold: 5 (15 ns), cycle: 17 (51 ns)
Standard read applied
TDF optimization enabled
TDF cycles: 15 (45 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

=> nand onfi 3
=> hsmc decode

MCK rate: 270 MHz

SMC_SETUP2: 0x0004
SMC_PULSE2: 0x0c070d05
SMC_CYCLE2: 0x000c000d
SMC_MODE2:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 12 (36 ns), hold: 0 (0 ns), cycle: 12 (36 ns)
   NRD: setup: 0 (0 ns), pulse: 7 (21 ns), hold: 5 (15 ns), cycle: 12 (36 ns)
NCS_WR: setup: 0 (0 ns), pulse: 13 (39 ns), hold: 0 (0 ns), cycle: 13 (39 ns)
   NWE: setup: 4 (12 ns), pulse: 5 (15 ns), hold: 4 (12 ns), cycle: 13 (39 ns)
Standard read applied
TDF optimization enabled
TDF cycles: 15 (45 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

=> nand torture 0x80 0x80

NAND torture: device 0 offset 0x80 size 0x80 (block size 0x4)
 Passed: 32, failed: 0

=> clk dump

2400  1|   |-- mainck
 108000   1|   |   |-- plla_fracck
 108000   1|   |   |   |-- plla_divpmcck
 108000   1|   |   |   |   `-- mck_pres
 270008|   |   |   |   `-- mck_div

Best regards,
Mihai Sain


RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-20 Thread Mihai.Sain
Hi Alex,

> > Also I recommend to print the master clock in MHz, and to print the master 
> > clock name/label from ccf driver:
> > https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5.
> > c#L410
>
> Should be possible.  I could do this and send a v2?
>
>   Yes Please 
>   Also please note that older SAM9/SAMA5 series have no ccf drivers ☹
>   Only SAM9X6+ and SAMA7 series have ccf 

Okay I thought this would be easy, but it seems not.  This is what I came up 
with:

-printf("mck clock rate: %lu\n", clk_get_rate(nc->mck));
+printf("%s rate: %lu MHz\n",
+   nc->mck->dev->name ? nc->mck->dev->name : "mck clock",
+   clk_get_rate(nc->mck) / 100);

And this is the output on sam9x60 with CONFIG_CLK_CCF enabled:

pmc@fc00 rate: 200 MHz

The corresponding line from `clk dump` is:

 25|   |   |   `-- mck_div

That name, I don't get it where to get that one.

You can revert to initial print and add MHz 
MCK rate: 200 MHz
Thanks.



RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-18 Thread Mihai.Sain
Hi Alexander,

>   Maybe we should add an automatic fallback for timing mode in 
> nand-controller.c 
>   As of now the driver is forcing tRC_min to 30ns (mode 3), which is not 
> reliable for sama7 nfc controller ☹
>   
> https://github.com/u-boot/u-boot/blob/master/drivers/mtd/nand/raw/nand_timings.c#L167
>   The nand torture command helped me to manually force tRC_min to 35ns 
> (mode 2).

This sounds like the same problem encountered in
https://github.com/linux4sam/at91bootstrap/issues/174 and the fix proposed 
there works in Linux and U-Boot as well.  I consider the original commit 
message of the patch attached to that ticket not easy to understand however, so 
I wrote what I think is the problem.  Could you please test the patch attached 
to this mail which does the same thing and should apply to U-Boot cleanly?  I 
tested that on sam9x60 and sama5, but have no other boards/socs to test with.  
If that works on sama7, I will propose it on U-Boot, too.

(I hope it is okay to attach it as an attachment for now, it's not ready for 
submission anyways.)

I tested your patch on sama7g54-curiosity board.
I also reverted to (conf->timings.sdr.tRC_min < 3), to force mode 3 

Indeed the decode command reports tighter timings.
I tested using nand torture on 16MiB and 32MiB sizes.

U-Boot> nand info

Device 0: nand0, sector size 256 KiB
  Manufacturer  MACRONIX
  Model MX30LF4G28AD
  Device size512 MiB
  Page size 4096 b
  OOB size   256 b
  Erase size  262144 b
  ecc strength 8 bits
  ecc step size  512 b
  subpagesize   4096 b
  options   0x40004200
  bbt options   0x00028000

U-Boot> hsmc decode

mck clock rate: 2

HSMC_SETUP3:0x0002
HSMC_PULSE3:0x07040703
HSMC_CYCLE3:0x00070007
HSMC_TIMINGS3:  0x880402f2
HSMC_MODE3: 0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
   NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns)
NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
   NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 ns)
TDF optimization enabled
TDF cycles: 15 (75 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

U-Boot> nand torture 0x80 0x100

NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4)
 Passed: 64, failed: 0

U-Boot> nand torture 0x80 0x200

NAND torture: device 0 offset 0x80 size 0x200 (block size 0x4)
 Passed: 128, failed: 0

Tested-by: Mihai Sain 

Best regards,
Mihai Sain


RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-18 Thread Mihai.Sain
Hi Alexander,

I'm sorry for quoting because the email is sent from Outlook ☹

> > U-Boot> nand info
> >
> > Device 0: nand0, sector size 256 KiB
> >   Manufacturer  MACRONIX
> >   Model MX30LF4G28AD
> >   Device size512 MiB
> >   Page size 4096 b
> >   OOB size   256 b
> >   Erase size  262144 b
> >   ecc strength 8 bits
> >   ecc step size  512 b
> >   subpagesize   4096 b
> >   options   0x4200
> >   bbt options   0x00028000
>
> This seems to be the same NAND chip as on the sam9x60 curiosity, but your 
> output has three additional lines, see mine:
> Do you have some additional patches printing manufacturer, model, and 
> device size?  I can't see those lines printed in
> nand_print_and_set_info() here.
>
> Yes. I have 
> + printf("  Manufacturer  %s \n", chip->onfi_params.manufacturer);
> + printf("  Model %s \n", chip->onfi_params.model);
> + printf("  Device size   %8d MiB\n", (int)(chip->chipsize >> 20));

This is nice, and I think it would be valuable to have upstream.
Maybe you could send a patch for that?
Sure. I will send the patch !

> > U-Boot> hsmc decode
> >
> > mck clock rate: 2
> >
> > HSMC_SETUP3:0x0001
> > HSMC_PULSE3:0x07040804
> > HSMC_CYCLE3:0x00070008
> > HSMC_TIMINGS3:  0x880402f2
> > HSMC_MODE3: 0x001f0003
> > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
> >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7
> > (35 ns)
> > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
> >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8
> > (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus
> > Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE 
> > signal Read operation controlled by NRD signal
>
> This is also interesting.  Given the mck clock rate is the same as on 
> sam9x60, I would have guessed the timings set by
> atmel_smc_nand_prepare_smcconf() should give the same results, both for ONFI 
> timiming mode 3, which is the fastest mode the (H)SMC supports according to 
> comments in the driver.  This is the output with the patch in question 
> applied on next for sam9x60:
>
> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> SMC_SETUP3: 0x0002
> SMC_PULSE3: 0x06030703
> SMC_CYCLE3: 0x00060007
> SMC_MODE3:  0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30 
> ns)
>NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6 (30 
> ns)
> NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 
> ns)
>NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 
> ns)
> Standard read is applied.
> TDF optimization enabled
> TDF cycles: 15 (75 ns)
> Data Bus Width: 8-bit bus
> NWAIT Mode: 0
> Write operation controlled by NWE signal
> Read operation controlled by NRD signal
>
> Notice the pulse times for read are one clock cycle smaller than in your 
> output, and the timings for write are also different.  Do you have changes 
> for atmel_smc_nand_prepare_smcconf() applied which are not upstream yet?  Or 
> is the HSMC on sama7g54 somehow different than on older SoCs?
>
> Yes. I force timing mode 2 in nand-controller.c:
> + if (conf->timings.sdr.tRC_min < 30001) // force timing mode 2, 
> + 35ns for read/write cycle
>
> This will pass the nand torture test 
>
> U-Boot> nand torture 0x80 0x100
>
> NAND torture: device 0 offset 0x80 size 0x100 (block size 
> 0x4)
>  Passed: 64, failed: 0

Ah okay.  I have another patch here for manually setting the ONFI timing mode 
from commandline.  This is probably too late for some scenarios, but it helped 
me when testing.  If you're interested I could send it to the public.
Yes. I'm very interested !
Maybe we should add an automatic fallback for timing mode in 
nand-controller.c 
As of now the driver is forcing tRC_min to 30ns (mode 3), which is not 
reliable for sama7 nfc controller ☹

https://github.com/u-boot/u-boot/blob/master/drivers/mtd/nand/raw/nand_timings.c#L167
The nand torture command helped me to manually force tRC_min to 35ns 
(mode 2).
Thanks.

Greets
Alex

>
> Note: I'm currently testing a patch changing the computation of the read 
> pulse cycles based on a patch for at91bootstrap [1], but that is not applied 
> here for the output quoted above.
>
> Greets
> Alex
>
> [1] 
> https://github.com/linux4sam/at91bootstrap/issues/174#issuecomment-197
> 0698527
>
> >
> > Best regards,
> > Mihai Sain


RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-18 Thread Mihai.Sain

> The command is very useful.
> I would like to have also the ONFI timing mode printed for nand-flash 
> 

As far as I can see the actually set mode is not stored anywhere.  One could 
print it after it was successfully set, but that would be in nand base, not in 
the atmel driver.

OK. Understood.
Thanks.

> Also I recommend to print the master clock in MHz, and to print the master 
> clock name/label from ccf driver:
> https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5.
> c#L410

Should be possible.  I could do this and send a v2?

Yes Please 
Also please note that older SAM9/SAMA5 series have no ccf drivers ☹
Only SAM9X6+ and SAMA7 series have ccf 
Thanks.


Greets
Alex

>
> Tested-by: Mihai Sain 
>
> Best regards,
> Mihai Sain


RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-18 Thread Mihai.Sain
> Hi Alexander,
>
> I tested your work on sama7g54-curiosity board:
>
> U-Boot> nand info
>
> Device 0: nand0, sector size 256 KiB
>   Manufacturer  MACRONIX
>   Model MX30LF4G28AD
>   Device size512 MiB
>   Page size 4096 b
>   OOB size   256 b
>   Erase size  262144 b
>   ecc strength 8 bits
>   ecc step size  512 b
>   subpagesize   4096 b
>   options   0x4200
>   bbt options   0x00028000
>
> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> HSMC_SETUP3:0x0001
> HSMC_PULSE3:0x07040804
> HSMC_CYCLE3:0x00070008
> HSMC_TIMINGS3:  0x880402f2
> HSMC_MODE3: 0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
>NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 
> (35 ns)
> NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
>NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 
> (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus 
> Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE 
> signal Read operation controlled by NRD signal
>
> Best regards,
> Mihai Sain

Hello Mihai,

If you have any suggestions for improvement, changes, or you are happy with 
this command, is it useful ?
You can provide your Tested-by then if you consider this is useful

Eugen

--

Hello Eugen,

Yes.
The command is very useful.
I would like to have also the ONFI timing mode printed for nand-flash 
Also I recommend to print the master clock in MHz, and to print the master 
clock name/label from ccf driver:
https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5.c#L410

Tested-by: Mihai Sain 

Best regards,
Mihai Sain


RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-18 Thread Mihai.Sain
> U-Boot> nand info
>
> Device 0: nand0, sector size 256 KiB
>   Manufacturer  MACRONIX
>   Model MX30LF4G28AD
>   Device size512 MiB
>   Page size 4096 b
>   OOB size   256 b
>   Erase size  262144 b
>   ecc strength 8 bits
>   ecc step size  512 b
>   subpagesize   4096 b
>   options   0x4200
>   bbt options   0x00028000

This seems to be the same NAND chip as on the sam9x60 curiosity, but your 
output has three additional lines, see mine:
Do you have some additional patches printing manufacturer, model, and device 
size?  I can't see those lines printed in
nand_print_and_set_info() here.

Yes. I have 
+   printf("  Manufacturer  %s \n", chip->onfi_params.manufacturer);
+   printf("  Model %s \n", chip->onfi_params.model);
+   printf("  Device size   %8d MiB\n", (int)(chip->chipsize >> 20));

> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> HSMC_SETUP3:0x0001
> HSMC_PULSE3:0x07040804
> HSMC_CYCLE3:0x00070008
> HSMC_TIMINGS3:  0x880402f2
> HSMC_MODE3: 0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
>NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 
> (35 ns)
> NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
>NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 
> (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus 
> Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE 
> signal Read operation controlled by NRD signal

This is also interesting.  Given the mck clock rate is the same as on sam9x60, 
I would have guessed the timings set by
atmel_smc_nand_prepare_smcconf() should give the same results, both for ONFI 
timiming mode 3, which is the fastest mode the (H)SMC supports according to 
comments in the driver.  This is the output with the patch in question applied 
on next for sam9x60:

U-Boot> hsmc decode

mck clock rate: 2

SMC_SETUP3: 0x0002
SMC_PULSE3: 0x06030703
SMC_CYCLE3: 0x00060007
SMC_MODE3:  0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30 ns)
   NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6 (30 ns)
NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
   NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 
ns)
Standard read is applied.
TDF optimization enabled
TDF cycles: 15 (75 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

Notice the pulse times for read are one clock cycle smaller than in your 
output, and the timings for write are also different.  Do you have changes for 
atmel_smc_nand_prepare_smcconf() applied which are not upstream yet?  Or is the 
HSMC on sama7g54 somehow different than on older SoCs?

Yes. I force timing mode 2 in nand-controller.c:
+   if (conf->timings.sdr.tRC_min < 30001) // force timing mode 2, 35ns for 
read/write cycle

This will pass the nand torture test 

U-Boot> nand torture 0x80 0x100

NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4)
 Passed: 64, failed: 0

Note: I'm currently testing a patch changing the computation of the read pulse 
cycles based on a patch for at91bootstrap [1], but that is not applied here for 
the output quoted above.

Greets
Alex

[1] 
https://github.com/linux4sam/at91bootstrap/issues/174#issuecomment-1970698527

>
> Best regards,
> Mihai Sain


RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands

2024-03-18 Thread Mihai.Sain
On 3/7/24 11:10, Alexander Dahl wrote:
> For now adds one new command 'hsmc' with a single subcommand 'decode' 
> to read and display the content of the registers of the Static Memory 
> Controllers (SMC/HSMC) found in different at91 SoCs.  Needed to get a 
> better picture on what raw nand core and atmel nand controller driver 
> try to set as timings based on ONFI parameters of the connected NAND 
> chip.
>
> Tested on SAMA5D2 and SAM9X60 based boards.  Example output:
>
> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> SMC_SETUP3: 0x0002
> SMC_PULSE3: 0x07040703
> SMC_CYCLE3: 0x00070007
> SMC_MODE3:  0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 
> ns)
>NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 
> ns)
> NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 
> ns)
>NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 
> ns)
> Standard read is applied.
> TDF optimization enabled
> TDF cycles: 15 (75 ns)
> Data Bus Width: 8-bit bus
> NWAIT Mode: 0
> Write operation controlled by NWE signal
> Read operation controlled by NRD signal

Adding Mihai as he is usually very interested in such debug information and 
methods.

-

Hi Alexander,

I tested your work on sama7g54-curiosity board:

U-Boot> nand info

Device 0: nand0, sector size 256 KiB
  Manufacturer  MACRONIX
  Model MX30LF4G28AD
  Device size512 MiB
  Page size 4096 b
  OOB size   256 b
  Erase size  262144 b
  ecc strength 8 bits
  ecc step size  512 b
  subpagesize   4096 b
  options   0x4200
  bbt options   0x00028000

U-Boot> hsmc decode

mck clock rate: 2

HSMC_SETUP3:0x0001
HSMC_PULSE3:0x07040804
HSMC_CYCLE3:0x00070008
HSMC_TIMINGS3:  0x880402f2
HSMC_MODE3: 0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
   NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns)
NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
   NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 (40 ns)
TDF optimization enabled
TDF cycles: 15 (75 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal

Best regards,
Mihai Sain


RE: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91

2023-11-17 Thread Mihai.Sain
Hi Eugen,

I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, 
sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board.
I used the latest u-boot/master branch for this test.
I noticed that the file size of the binaries have beed reduced with aprox 
150KiB due to CONFIG_SYS_THUMB_BUILD=y.
After flashing the new binaries on these boards I can confirm that on all 
boards the linux kernel was booted properly from mmc, qspi-flash, nand-flash 
and usb.
I tested using bootm and bootz commands.

Best regards,
Mihai Sain



On 11/16/23 20:47, Tom Rini wrote:
> On Sat, Nov 04, 2023 at 10:27:42PM -0400, Sean Anderson wrote:
>
>> Several AT91 boards are quite close to their SPL size limit. For 
>> example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit 
>> and doesn't even fit with older GCCs.
>>
>> All AT91 processors should have thumb support. Enable 
>> SYS_THUMB_BUILD. This shrinks SPL by around 30%.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>> This has been BUILD TESTED ONLY!
>
> We in turn need this for Sean's other cleanup series to go in. Is this 
> OK? Would it be safer if it was only for CPU_V7A ? I do have 
> recollections of thumb being sometimes buggy prior to v7a cores. Thanks!
>

Hi Tom,

I would like this to be tested on a few boards at least. There are boards with 
Cortex A5, A7 and ARM926 which are important, one of each of them and booting 
Linux should be enough I think.
Nicolas, Aubin ? I remember you guys have also a CI tool that is fairly easy to 
use if you just push a branch/commit.

+ Mihai as well.

Eugen


RE: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60

2023-08-08 Thread Mihai.Sain
Hi Alex,

Please find bellow my answer:

--

Added Mihai who tested this a lot at some point in time

Eugen

On 8/8/23 16:02, Alexander Dahl wrote:
> Hello everyone,
>
> this is a patch series wtih some real fixes _and_ a question or some 
> kind of support request in the cover letter.  I would be happy if 
> anyone could read the cover letter carefully and answer to that one 
> what might be the problem I see. O:-)
>
> I'm currently working on the sam9x60-curiosity board and especially 
> trying to get it booting from onboard raw NAND flash.  As reported in 
> my last series I got the flash recognized already.  However 
> interacting with it was terribly slow, because nand_wait_ready() 
> calling
> atmel_nand_dev_ready() ran into a 400ms timeout in several occasions, 
> especially when reading from the device.  Reading a single block 
> triggered that timeout two times per page, which summed up to over 50 
> seconds for 64 × 4096 = 256k Bytes!
>
> (You can have U-Boot print that warning from nand_wait_ready() by 
> increasing the console log level to at least "warn".)
>
> Note: the dts from atmel/next seems correct to me, I double checked 
> that again.  My own debug log messages showed the GPIO is accessed, 
> and if you add enough debug messages sometimes the timeout is not 
> reached, so I'm sure the NAND chip eventually switches that R/B line 
> and the code correctly sees that, that line level change however takes 
> ages, something between 400ms and 500ms most of the times.
>
> I vaguely remembered on SAMA5D2 the old atmel raw nand driver is used 
> which does not support reading the R/B signal, but nevertheless works.
> I'm not familiar in detail with those raw NAND flash chips, but as far 
> as I can understand, there are other ways to determine if the chip is 
> ready or busy.  So after I removed that rb-gpio parameter from 
> 'at91-sam9x60_curiosity.dts' I ran into the bug fixed by patch 2.
>
> With that patch applied _and_ rb-gpio still removed from dts, raw NAND 
> access is reasonably fast on sam9x60-curiosity board.  (You might want 
> to rebase to atmel/next for testing this.)  Not sure if I should send 
> a patch for that dts change, because I suppose it's a workaround only 
> and not addressing the actual cause?
>
> I think the fix is correct in itself, I tested different combinations 
> and compared with the driver in Linux, however …
>
> Can anyone explain to me, why flash access is sooo slow if the R/B 
> gpio is used?  Especially in comparision to Linux, where I don't need 
> to remove that thing from dts and it works reasonably fast?

// I'm sorry for quoting (email is sent from Outlook)
# Please add in your board dts: atmel,rb = <0>
# nand@3 {
#   reg = <0x3 0x0 0x80>;
#   atmel,rb = <0>;
#   cs-gpios = < 4 GPIO_ACTIVE_HIGH>;
#   rb-gpios = < 5 GPIO_ACTIVE_HIGH>;
#   nand-bus-width = <8>;
#   nand-ecc-mode = "hw";
#   nand-ecc-strength = <8>;
#   nand-ecc-step-size = <512>;
#   nand-on-flash-bbt;>

> The actual flash chip is a Macronix MX30LF4G28AD, 512 MiB, SLC, erase
> size: 256 KiB, page size: 4096, OOB size: 256.
>
> Greets
> Alex
>
> P.S.: although not returned by get_maintainer.pl I added Eugen to Cc 
> because he is maintainer of the at91 and might have some insight if it 
> is a general problem of the nand controller in at91 socs?
>
> Alexander Dahl (2):
>mtd: nand: raw: atmel: Remove duplicate line
>mtd: nand: raw: atmel: Add error handling when rb-gpios missing
>
>   drivers/mtd/nand/raw/atmel/nand-controller.c | 12 +++-
>   1 file changed, 7 insertions(+), 5 deletions(-)
>
>
> base-commit: a169438411f9277cc689c14078151aa1d1caae3c



RE: [PATCH] configs: at91: sama5d2_icp_mmc: Enable CONFIG_LTO

2023-07-24 Thread Mihai.Sain
Hello Eugen,

I have successfully tested the binary on sama5d2_icp board.
Board is booting OK the zImage from fat (SD-card).

Tested-by: Mihai Sain 

Best regards,
Mihai Sain

-Original Message-
From: Eugen Hristev  
Sent: Monday, July 24, 2023 2:08 PM
To: u-boot@lists.denx.de; Mihai Sain - M19926 
Cc: Pali Rohár ; Stefan Roese 
Subject: Re: [PATCH] configs: at91: sama5d2_icp_mmc: Enable CONFIG_LTO

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

On 4/27/23 11:59, Stefan Roese wrote:
> Adding just a tiny bit more code for sama5d2_icp_mmc leads to a SRAM 
> image overflow. Fix this by enabling LTO for this board, so that such 
> changes still can be made to the common U-Boot code.
>
> Signed-off-by: Stefan Roese 
> Cc: Tudor Ambarus 
> Cc: Eugen Hristev 
> Cc: Sergiu Moga 
> Cc: Pali Rohár 
> ---
>   configs/sama5d2_icp_mmc_defconfig | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/configs/sama5d2_icp_mmc_defconfig 
> b/configs/sama5d2_icp_mmc_defconfig
> index e1b602d8e5ec..a3c57a3f1250 100644
> --- a/configs/sama5d2_icp_mmc_defconfig
> +++ b/configs/sama5d2_icp_mmc_defconfig
> @@ -9,9 +9,11 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
>   CONFIG_SPL_LIBGENERIC_SUPPORT=y
>   CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20003ef0
> +CONFIG_SF_DEFAULT_SPEED=6600
>   CONFIG_ENV_SIZE=0x4000
>   CONFIG_DM_GPIO=y
>   CONFIG_DEFAULT_DEVICE_TREE="at91-sama5d2_icp"
> +CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_SPL_MMC=y
>   CONFIG_SPL_SERIAL=y
>   CONFIG_SPL_DRIVERS_MISC=y
> @@ -24,6 +26,7 @@ CONFIG_SPL_FS_FAT=y
>   CONFIG_SPL_LIBDISK_SUPPORT=y
>   CONFIG_SYS_LOAD_ADDR=0x2200
>   CONFIG_DEBUG_UART=y
> +CONFIG_LTO=y
>   CONFIG_ENV_VARS_UBOOT_CONFIG=y
>   CONFIG_SYS_MONITOR_LEN=524288
>   CONFIG_FIT=y
> @@ -86,7 +89,6 @@ CONFIG_MMC_SDHCI=y
>   CONFIG_MMC_SDHCI_ATMEL=y
>   CONFIG_DM_SPI_FLASH=y
>   CONFIG_SF_DEFAULT_BUS=2
> -CONFIG_SF_DEFAULT_SPEED=6600
>   CONFIG_SPI_FLASH_SFDP_SUPPORT=y
>   CONFIG_SPI_FLASH_ATMEL=y
>   CONFIG_SPI_FLASH_MACRONIX=y
> @@ -110,5 +112,4 @@ CONFIG_TIMER=y
>   CONFIG_SPL_TIMER=y
>   CONFIG_ATMEL_TCB_TIMER=y
>   CONFIG_SPL_ATMEL_TCB_TIMER=y
> -CONFIG_OF_LIBFDT_OVERLAY=y
>   # CONFIG_EFI_LOADER_HII is not set

Mihai (added to the thread) tested this patch on sama5d2_icp.

Mihai, can you add your Tested-by tag then?
This is the original LTO patch for sama5d2_icp that we discussed about.

Thanks, Eugen


RE: [PATCH] configs: sama5d2: enable CONFIG_LTO

2023-07-24 Thread Mihai.Sain
Hello Eugen,

I have successfully tested the binary on sama5d2_xplained board.
Board is booting OK the zImage from fat (eMMC).

Tested-by: Mihai Sain 

Best regards,
Mihai Sain

-Original Message-
From: Eugen Hristev  
Sent: Monday, July 24, 2023 1:08 PM
To: u-boot@lists.denx.de; Mihai Sain - M19926 
Cc: Eugen Hristev 
Subject: [PATCH] configs: sama5d2: enable CONFIG_LTO

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

arm-none-linux-gnueabihf-ld.bfd: u-boot-spl section `__u_boot_list' will not 
fit in region `.sram'
arm-none-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 100 bytes

SPL is at limit so to stop seeing above error in built, enable link time 
optimizations CONFIG_LTO.

Signed-off-by: Eugen Hristev 
Tested-by: Mihai Sain 
---
Hello Mihai,

Can you please test also this patch, that sama5d2_xplained boots correctly ?

With the current tree, sama5d2_xplained configs no longer build as the SPL is 
overflown.

Thanks !
Eugen

 configs/sama5d2_xplained_emmc_defconfig  | 1 +
 configs/sama5d2_xplained_mmc_defconfig   | 1 +
 configs/sama5d2_xplained_qspiflash_defconfig | 1 +  
configs/sama5d2_xplained_spiflash_defconfig  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/sama5d2_xplained_emmc_defconfig 
b/configs/sama5d2_xplained_emmc_defconfig
index e33dcb8fb80a..9ef0ff4aa9a7 100644
--- a/configs/sama5d2_xplained_emmc_defconfig
+++ b/configs/sama5d2_xplained_emmc_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SYS_LOAD_ADDR=0x2200
 CONFIG_DEBUG_UART=y
+CONFIG_LTO=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_FIT=y
 CONFIG_SD_BOOT=y
diff --git a/configs/sama5d2_xplained_mmc_defconfig 
b/configs/sama5d2_xplained_mmc_defconfig
index acd75174f7d6..aed9edafdf70 100644
--- a/configs/sama5d2_xplained_mmc_defconfig
+++ b/configs/sama5d2_xplained_mmc_defconfig
@@ -29,6 +29,7 @@ CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SYS_LOAD_ADDR=0x2200
 CONFIG_DEBUG_UART=y
+CONFIG_LTO=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_FIT=y
 CONFIG_SD_BOOT=y
diff --git a/configs/sama5d2_xplained_qspiflash_defconfig 
b/configs/sama5d2_xplained_qspiflash_defconfig
index 6346e5315bf1..c9a20723f5a1 100644
--- a/configs/sama5d2_xplained_qspiflash_defconfig
+++ b/configs/sama5d2_xplained_qspiflash_defconfig
@@ -29,6 +29,7 @@ CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SYS_LOAD_ADDR=0x2200
 CONFIG_DEBUG_UART=y
+CONFIG_LTO=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_FIT=y
 CONFIG_QSPI_BOOT=y
diff --git a/configs/sama5d2_xplained_spiflash_defconfig 
b/configs/sama5d2_xplained_spiflash_defconfig
index 76fa56ebeb53..c01a0c4cc7c8 100644
--- a/configs/sama5d2_xplained_spiflash_defconfig
+++ b/configs/sama5d2_xplained_spiflash_defconfig
@@ -31,6 +31,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y  CONFIG_SPL_SPI=y
 CONFIG_SYS_LOAD_ADDR=0x2200
 CONFIG_DEBUG_UART=y
+CONFIG_LTO=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_FIT=y
 CONFIG_SPI_BOOT=y
--
2.34.1



RE: [u-boot][PATCH] board: at91: sama5d29_curiosity: add initial support for sama5d29_curiosity

2023-07-24 Thread Mihai.Sain
Hello Eugen,

Thank you for applying the patch.

For this board we don't want to use SPL.
I will send v2 patch to remove the custom prompt.
Thanks.

Best regards,
Mihai Sain

-Original Message-
From: Eugen Hristev  
Sent: Monday, July 24, 2023 11:13 AM
To: Mihai Sain - M19926 ; u-boot@lists.denx.de
Cc: Cristian Birsan - M91496 
Subject: Re: [u-boot][PATCH] board: at91: sama5d29_curiosity: add initial 
support for sama5d29_curiosity

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

Hello Mihai,

Thank you for the patch.

However, the at91 maintainer tree nowadays has a big problem, I cannot apply 
patches because the size of the SPL will overflow.
There is a pending patch that fixes it, but it has not been tested.
Here you can help, and test this integration branch (at least on sama5d2 ICP, 
but if you can test on multiple boards, it's even better) :

https://source.denx.de/u-boot/custodians/u-boot-at91/-/tree/testing?ref_type=heads

Once this is tested you can reply with a Tested-by: tag, and we can move along.
Without testing the patch that fixes the size restraint (it's the CONFIG_LTO 
patch), the tree is stalled.

One small nitpick below, and I am looking forward for your reply,

Eugen


On 7/20/23 10:54, Mihai Sain wrote:
> Add initial support for sama5d29_curiosity board.
>
> Hardware:
> SoC: SAMA5D29 500 MHz
> DRAM: LPDDR2 512 MiB
> PMIC: MCP16502
> Debug: UART0
> Flash: QSPI NOR 8 MiB
> RGB LCD connector
> Mikrobus connectors x 2
> SD-Card connectors x 2
> USB 2.0 x 2
>
> Signed-off-by: Mihai Sain 
> ---

> +CONFIG_SYS_PROMPT="[root@sama5d29 ~]$ "

Can you remove this. It looks like a Linux prompt and might be confusing for 
people

(and everywhere below)


Re: USB mass storage gadget on SAMA5D2

2023-05-26 Thread Mihai.Sain
Hi Zixun,

I recommend to use sam-ba in order to flash the eMMC partitions: boot1, boot2, 
user0.
sam-ba download links:
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareLibraries/Firmware/sam-ba_v3.7-linux_x86_64.tar.gz
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareLibraries/Firmware/sam-ba_v3.7-win32.zip

For writing the bootstrap binary into boot1 partition, run the following 
command:

sam-ba -p serial -d sama5d2:0:1 -a sdmmc:0:1:1:8:4 -c writeboot:boot.bin -c 
enablebootpartition:1

For help please run:

sam-ba -p serial -d sama5d2 -a sdmmc:help

Syntax: sdmmc:[]:[]:[]:[]:[]
Parameters:
instance   SDMMC controller number
ioset  SDMMC I/O set
partition  Partition number (0=user partition, x>0=boot partition x)
bus_width  Data bus width (0=controller max, 1=1-bit, 4=4-bit, 8=8-bit)
voltages   Supported voltages (bitfield: 1=1.8V, 2=3.0V, 4=3.3V)

Regards,
Mihai


From: admin LI 
Sent: Friday, May 26, 2023 15:13
To: Cristian Birsan - M91496 
Cc: eugen.hris...@collabora.com ; lu...@denx.de 
; ma...@denx.de ; u-boot@lists.denx.de 
; Mihai Sain - M19926 
Subject: Re: USB mass storage gadget on SAMA5D2

You don't often get email from ad...@hifiphile.com. Learn why this is 
important
EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe
Hi Cristian,

> What are you trying to achieve ? If you want to just program the eMMC you can 
> do it easily with SAM-BA[1].
On our board the MPU boot from the eMMC boot partition, by exposing the whole 
user partition as a block device we can modify the target system easily, like 
modifying the partition table.

I've tested the gadget works well in Linux, but it's not possible to expose the 
whole disk.

For reference I've implemented at91bootstrap eMMC boot partition support, both 
at91bootstrap and U-Boot are inside the boot partition.
https://github.com/linux4sam/at91bootstrap/pull/163
https://github.com/linux4sam/at91bootstrap/pull/164

Regards,
Zixun

On Thu, May 25, 2023 at 7:16 PM 
mailto:cristian.bir...@microchip.com>> wrote:
Hi,

On 5/22/23 12:00, admin LI wrote:
>
>
> I think there may be some racing in the driver. (Purely assumption as a 
> tinyusb maintainer)
> If I enable DBG_ALL in atmel_usba_udc.h, the block device is enermurated 
> although with I/O error.

What are you trying to achieve ? If you want to just program the eMMC you can 
do it easily with SAM-BA[1].

The mass storage gadget works well in Linux kernel. You can have a look at the 
driver we have in the kernel
here[2].


[1] https://www.microchip.com/en-us/development-tool/SAM-BA-In-system-Programmer
[2] 
https://github.com/linux4microchip/linux/blob/linux-6.1-mchp/drivers/usb/gadget/udc/atmel_usba_udc.c

Regards,
Cristian

>
> [1337613.189788] usb 1-1: new high-speed USB device number 7 using xhci_hcd
> [1337613.674551] usb 1-1: New USB device found, idVendor=dead, 
> idProduct=beef, bcdDevice= 2.17
> [1337613.674565] usb 1-1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [1337613.674568] usb 1-1: Product: USB download gadget
> [1337613.674572] usb 1-1: Manufacturer: U-Boot
> [1337613.866033] usb-storage 1-1:1.0: USB Mass Storage device detected
> [1337613.866645] scsi host0: usb-storage 1-1:1.0
> [1337614.997803] scsi 0:0:0:0: Direct-Access LinuxUMS disk 0   
>  PQ: 0 ANSI: 2
> [1337615.230004] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337615.706637] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337616.183308] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337616.659937] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337617.140086] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337617.616632] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337618.073323] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337618.549927] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337619.026540] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337619.499944] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337619.976679] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337620.453285] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337620.916597] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337621.393267] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337621.869676] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337622.346597] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337622.823361] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337623.293287] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337623.635357] sd 0:0:0:0: [sda] Read Capacity(10)