00:14 <mmind00> macromorgan_: there is the cpu-id field? i.e. that's the one u-boot can use to generate a mostly unique mac address from

01:34 <macromorgan> mmind00: I was thinking of something more secure (like a unique ID that can only be read from the OTP-S or whatnot). Goal is to have something I can use to program the RPMB in a secure but reproducible manner...

03:57 <lvrp16> macromorgan: how do you write all these DTs without schematics?

08:38 <indy> hi all, do i understand well that rk3399 spi can act as slave?

08:39 <indy> my intention is to hook rockpi-s to rk3399 and boot rockpi-s from rk3399

09:17 <beeble> indy: no real world experience. but the driver allows to configure it via devicetree https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-rockchip.c#L762

09:26 <indy> beeble, so it apply for all rk chips which are using same driver?

09:28 <beeble> yes should be the case

10:23 <indy> beeble, is possible to do this? https://www.corelis.com/education/tutorials/spi-tutorial/#SPI_Bus_3-Wire_and_Multi-IO_Configurations because some time ago i saw openocd-spi fork using for swd spi from raspberry pi

10:24 <indy> https://github.com/lupyuen/openocd-spi

10:51 <beeble> i do not see how this exacly relates. for swd you just need master and this pretty much just replaces the bitbang gpio stuff with a spi master

10:52 <beeble> for slave you need something that reacts quite fast as slave on read commands from the host (rk3399 boot rom in your case)

10:54 <beeble> if you are not planning to change your bootload with every boot i would go the easy route and make your spi flash multi-master accessible. so that you write it from one device and and then not touch it until you write it again (but not sure why you would need something like that all :))

10:55 <indy> i plan to change bootload every boot :)

11:08 <beeble> indy: if you are not explicitly want to test the spi flow i would think that spending the efforts in getting u-boot TPL/SPL to load proper correctly via a maskrom upload would be more beneficial

11:09 <indy> with threadx released with mit license, moved under eclipse umbrella, misra certified and smp documented i would like to play with threadx smp in cortex a35, booting from spi served by rk3399

11:09 <indy> beeble, that's exactly what i want

11:12 <indy> i have bare-rk3308 which enables swd so i can play with default - https://github.com/cz172638/bare-rkxxxx/blob/main/code-rk3308.S

11:13 <indy> i want to load it using spi, instead of usb

11:22 <indy> ultimate goal is to have 'workbench' consisting from rockpi4 hooked to rockpis spi as slave and serial to have output from it and eventually having spi as swd adaptor, and running openocd on rockpi4 without any gpio bitbanging and/or usb probes

11:24 <indy> and vice-versa, having rockpis as openocd/conserver for rk3xxx low-level development

11:25 <beeble> i somehow doubt that this will work timingwise nicely (without a lot of effort) for flash emulation. most of the time you are ending up with sram and a fpga for such applications. but that is only my opinion, maybe somebody has better ideas. wishing you good luck with getting it done

11:30 <indy> how timingwise?

11:32 <indy> spi is not that fast :)

11:33 <indy> beeble, even with pinning such task to isolated core?

11:35 <beeble> you have to serve data immediately after the last address bit. so you get <instruction><address> and with the next spi clock cycle you already have to provide the read data

11:36 <beeble> and you have no clock stretching or ready signal

11:38 <beeble> this might be a challenge, especially if you try to do it via spidev. not saying that it is not possible at all, but i'm doubtful of it being straight forward

11:39 <indy> what about vfio-platform to pass spi device to userspace?

11:42 <beeble> no experience sorry

11:44 <phh> just to be sure i'm understanding correctly: you want to implement a software SPI NOR for the rockpi to boot from?

13:47 <macromorgan> lvrp16: I dump the factory image, decompile the device tree, and then add the devices one by one to make sure each one work

14:48 <robmur01> indy: FWIW I looked into doing the same thing a while ago (but never got round to implementing it). The verdict seemed to be that it is achievable, but only if the access pattern is consistent and predictable (as a boot ROM typically would be)

14:49 <robmur01> basically you don't really emulate the NOR as such, you just replay a canned stream of data to match the commands you know are coming

15:12 <indy> phh: yes

15:17 <phh> afaik there is no wait signal or anything in spi nor so you have to be clock-perfect. as you point out, it's slow enough that it isn't so much an issue of speed, rather than properly syncing, and how to ensure you're correctly in sync? I mean in one single transfer, you receive the address of the read, and send the data

15:18 <indy> robmur01, i was thinking something like usb storage gadget module, where you pass file to serve

15:18 <indy> phh, ^^

15:18 <phh> i'd say your easiest bet would be rpi2040? https://github.com/raspberrypi/pico-examples/issues/26 there are SD emulations examples

15:19 <indy> phh, i'll look at it

15:23 <phh> pls keep us posted ^^