On Thu, Nov 28, 2019 at 10:03 AM Romain Naour <romain.na...@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.na...@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@lists.denx.de > >> https://lists.denx.de/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot