[U-Boot] Using sspi for hardware detection?

[Simon Goldschmidt]

On Thu, Nov 28, 2019 at 10:03 AM Romain Naour <romain.naour at smile.fr> wrote:
>
> Hi,
>
> Le 27/11/2019 à 21:13, Simon Goldschmidt a écrit :
> > On Wed, Nov 27, 2019 at 1:58 PM Romain Naour <romain.naour at smile.fr> wrote:
> >>
> >> Hello,
> >>
> >> I'm working on a modular socfpga based system with several optional boards.
> >> Each optional board contain a board ID that can be read through a SPI bus.
> >>
> >> Since we want just read the board ID, we used manually the sspi command,
> >> something like:
> >>
> >> => sspi 1:1.0 8 0
> >> 42
> >>
> >> But it seems that the sspi command can't be used in a uboot script. sspi seems
> >> only used to manually test spi drivers.
> >>
> >>
> >> If we compare with i2c command, we have a i2c read to memory:
> >>
> >> i2c read chip address[.0, .1, .2] length memaddress - read to memory
> >>
> >> Why there is no such feature for spi ?
> >
> > Probably because noone has needed it so far.
> >
> >> Is there an interest to evolve the sspi command to add a read to memory?
> >>
> >> sspi <bus id>: <chip select>.<mode> <bit length> <data> <memaddress>
> >
> > If you need it and provide a decent patch, I could probable get accepted...
>
> Ok I'll take a look how to implement this.
>
> >
> >>
> >> By looking at existing code, it seems that hardware detection in uboot is
> >> handled by architecture/board specific code to set custom environment variable
> >> like "fpgatype" [1] or "unit_ident" "unit_serial" [2] (misc_init_r).
> >>
> >> What do you recommend?
> >> Implement a custom misc_init_r() for hardware detection?
> >
> > How is that related? How does reading to memory help you with knowing the hw
> > type in scripts?
>
> Sorry, actually this is another possibility.
>
> The first possibility is evolve the sspi command to add <memaddress>. This allow
> to use a script working on memory containing the data received from the spi bus.
> For my use case, it would allow to get the board ID in memory and use an uboot
> script analyze which board ID has been read.
>
> The second possibility is to use misc_init_r (or as you suggest board_late_init)
> in a board specific code (board/<customer>/<board_name>/socfpga.c) to access the
> spi bus and set custom environment variable. These environment variable are
> later used by uboot script.
>
> I would like an advice on the best implementation.
> I believe modifying sspi command can be the way to go since it can be used for
> other use case.

Yes, looks to me like that might be a handy thing to have in that command.
Of course that comes at the expand of size increasement when this command
is compiled in, so I can't judge if it's ok to add.

Regards,
Simon

>
> >
> > Anyway, I think board_late_init is a better fit than misc_init_r,
> > which is rather
> > meant to be a platform thing and vining can only use it because socfpga
> > doesn't need it otherwise.
>
> Thanks for your feed back!
>
> Best regards,
> Romain
>
>
> >
> > Regards,
> > Simon
> >
> >>
> >> [1]
> >> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/misc_gen5.c#L139
> >> [2]
> >> https://gitlab.denx.de/u-boot/u-boot/blob/master/board/softing/vining_fpga/socfpga.c#L48
> >>
> >> Best regards,
> >> Romain
> >> _______________________________________________
> >> U-Boot mailing list
> >> U-Boot at lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
>