<tlwoerner>
i'm trying to get 2 sets of pwms working on my radxa-zero-3e
<tlwoerner>
there's a pair on pins 16 & 18 (PWM8_M0 and PWM9_M0 respectively) that work fine
<tlwoerner>
PWM14_M0 on pin 7 works too, but i can't get a 4th pwm working
<tlwoerner>
all the remaining ones have _M1 at the end, but in the dts file their pins are "m0" assignments
<tlwoerner>
e.g. pwm13: pinctrl-0 = <&pwm13m0_pins>;
<tlwoerner>
shouldn't that be <&pwm13m1_pins>?
<tlwoerner>
huh, there's 2 pwm14's: pwm14_m0 and pwm14_m1
<CounterPillow>
the M numbers are the mux settings
<CounterPillow>
you can have a device's signal muxed to a few sets of output pins
<CounterPillow>
so foo_M0 might conflict with bar_M0 and baz_M0, but you can still mux it to foo_M1 etc. In this case, you'll want to choose the different pinmux to expose this function for that particular output pin as opposed to the other function mapped there at the moment
<tlwoerner>
okay. i can see in rk3568-pinctrl.dtsi that pwm14 is defined for both the _m0 and _m1 cases
<tlwoerner>
and the pin assignments match the radxa documentation
<tlwoerner>
but the dts file for this device (radxa-zero-3e, rk356x.dtsi) doesn't offer the two choices
<tlwoerner>
so how would i select pwm14_m1 instead of pwm14_m0?
<tlwoerner>
do i just patch in the second one?
<tlwoerner>
is that an omission in the dts file?
<tlwoerner>
qschulz: by the way, the pwm thing that we were discussing a couple weeks ago (interleaved, coordinated sets of pwms?) i think that's called "charlieplexing"
<tlwoerner>
i think adafruit has a breakout board with a chip that does charlieplexing
<CounterPillow>
you will have to patch in your preferred choice of pin mux with e.g. a DT overlay
<tlwoerner>
ideally, shouldn't these (disabled) alternates be already defined in the dts?
<CounterPillow>
The pin names themselves are defined in the dts (I copy the pin name stuff into the overlay here because the unused ones get trimmed from the compiled dts), but other than that, no, not that I know of.
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 264 seconds]
<tlwoerner>
CounterPillow: thank you. i simply copied the pwm13 stanza, renamed it to pwm13m1 and changed the pins to the m1 variants
<qschulz>
Kwiboo: not sure to understand why CONFIG_SPL_LOAD_FIT_ADDRESS - CFG_SYS_SDRAM_BASE for the offset?
<qschulz>
aaaah, because the addresses in U-Boot are not relative to the start of DRAM at all but the whole address space?
<qschulz>
mmm, getting lost there but I think this is not the right way to do it
<qschulz>
this is basically so we don't have to have a different offset for the USB booted u-boot.itb and the one stored on the MMC?
<qschulz>
I believe we should just concatenate SPL and U-boot.itb (+- alignment maybe)
<qschulz>
to save uploading a few MB of zeroes
<qschulz>
Additionally, Rockchip says that the image should NOT be <something> aligned as this is what the amount the bootrom reads at once
<qschulz>
so it'll read until it receives something that is NOT aligned
<qschulz>
trying to find the information again
<qschulz>
diederik: yep, saw that thanks for the notification. I'm not sure we'll migrate just yet as I'm wondering if we aren't missing scmi clocks on RK3588 as well for CPUfreq
<diederik>
ok
<qschulz>
Kwiboo: darn it, cannot find my source anymore
<qschulz>
Kwiboo: I guess it's something we can fix later on once I find the source again, but it could be quite difficult to debug why an image just doesn't work "bad luck, it turns out it's simply NKB aligned and cannot be"
<qschulz>
Kwiboo: also, this probably works because TF-A reserves the first 2MB in DRAM and because SPL can be running from there until TF-A starts, and that u-boot.itb is stored well after the 2MB mark (**by default**, not the case on RK3399 Puma and PX30 Ringneck for example!)
<qschulz>
we probably don't hit the issue and is why we don't need to relocate u-boot.itb from SPL
<qschulz>
**we** meaning you there, because I haven't tested this just yet :D
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-rockchip
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-rockchip
a3f has quit [Ping timeout: 244 seconds]
shoragan has quit [Ping timeout: 244 seconds]
shoragan has joined #linux-rockchip
a3f has joined #linux-rockchip
stikonas has joined #linux-rockchip
eballetbo has joined #linux-rockchip
<Kwiboo>
qschulz: correct, the offset prop in binman would be offset in the output blob, and SPL_LOAD_FIT_ADDRESS is address in DRAM, current rk aarch64 targets have 0x0 as start DRAM so they will be same, however older socs and rk3576 no longer have 0x0 as start of DRAM
<qschulz>
Kwiboo: we could force the offset at SYS_RAM + 2MB to account for TF-A reserved space and not waste too many MBs of zeroes (or make it configurable through Kconfig and provide that default)
<Kwiboo>
qschulz: if I remember correctly tf-a code/blob will only be placed in 256KB-1MB area however may use up to 2MB for secure area, so before tf-a is loaded we could use that space, the other option would be to keep spl+fit close in blob and memmove away FIT from the tf-a area
<qschulz>
Kwiboo: isn't TF-A supposed to run from SRAM and just have some amount of memory reserved in DRAM for **stuff**?
<Kwiboo>
yea, maskrom code will stop and execute the code when it get send command with data lenght <> 4096 byte
<qschulz>
Kwiboo: we can start with SPL uploaded at DRAM 0 by rkdeveloptool, and then have u-boot.itb at 2MB in DRAM uploaded by rkdeveloptool
<Kwiboo>
only a small part of ft-a is put in sram, the init code is placed at 256KB
<qschulz>
and once we figure out how to memmove, we concatenate spl+u-boot.itb into one binary uploaded by rkdeveloptool
<qschulz>
without padding between the two (or minimal)
<qschulz>
and we memmove stuff from SPL
<qschulz>
re SPL 0 and u-boot.itb at 2MB, they would still be in one binary, just that we would have padding between end of SPL and start of u-boot.itb at 2MB
<qschulz>
for the maskrom requiring non-4KB alignment, we probably should add an option to binman to generate an image that is unaligned :)
<qschulz>
Kwiboo: I would consider the location of u-boot.itb in u-boot-spl-with-fit.bin as not API and would be ok to randomly move it around
<qschulz>
if we ever find the time to memmove stuff
<Kwiboo>
could change SPL_LOAD_FIT_ADDRESS to 2MB instead of 1MB to be fully safe, for the platforms I tested no part of tf-a is placed above 1MB offset
<qschulz>
basically, just want to get the ball rolling and I'm not sure we need an optimized version right now
<qschulz>
Kwiboo: let's play it safe, TF-A does expect to have its first 2MB, and we also make a hole in whatever ATAGS return, so for consistency sake, I believe we should do that
<Kwiboo>
the alignment part is just for the transfer to usb, i.e. rkdeveloptool db and rockusb boot-download take care of that
<qschulz>
Kwiboo: ok, makes sense :)
<qschulz>
Kwiboo: if we're going into nitpicks, we shouldn't have u-boot-spl inside simple-bin-ramboot if there's no TPL
<qschulz>
since SPL would be uploaded as the DRAM init stage to USB 471
<qschulz>
and maybe we should simply call simple-bin-ramboot u-boot-rockchip-usb-472.bin ?
<Kwiboo>
TPL is the 471, SPL+FIT is 472
<qschulz>
yes
<qschulz>
but if there's no TPL, then SPL is 471 and FIT is 472 ?
<qschulz>
or is that not even possible
<qschulz>
mmmm
<qschulz>
probably not because SPL would return to bootrom but something needs to load the TF-A from FIT and execute it
<qschulz>
and that wouldn't be the bootrom for sure
<qschulz>
does this mean for TPL-less systems we would run the SPL twice? once because it's uploaded to 471 and once from 472 to load the FIT part?
<Kwiboo>
yeah, it all depends on how TPL/SPL is configured, you could probably have it work with SPL only, but back to bootrom will not work
<qschulz>
do you know how the upload over USB works?
<qschulz>
I would assume that one upload 471 first, waits for it to return to bootrom, then upload 472 to DRAM and starts it?
<qschulz>
or can you upload stuff to DRAM address space without it being properly init (I would assume not?)
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #linux-rockchip
<Kwiboo>
my understanding is that 471 will send data to sram until an unaligned block, after that bootrom just execute that code, the uploaded code then jumps back to bootrom, that is still in maskrom mode
<Kwiboo>
472 does something similar just load data into start of DRAM, and then jump to code, you could possible jump back to bootrom from that code and run more 472 commands
<tlwoerner>
qschulz: thanks! that's cleaner than what i was doing
<Kwiboo>
rkdeveloptool and rockusb also does a small sleep between 471 and 472, a few ms
<qschulz>
Kwiboo: yeah but that means we would need a small loader at the beginning of DRAM so that when 472 jumps to it it reads u-boot.itb and loads what needs to?
<qschulz>
for TPL-less systems I mean
<Kwiboo>
true, that would not work, or be more complicated, guess that could be one reason why there is separate ddr blob for all socs
<qschulz>
tlwoerner: oh wow, this seems very over engineered at first glance. I;'m wondering if there isn't an easier way for this?
<qschulz>
tlwoerner: I believe it should be much easier to maintain to use device tree overlays instead
<qschulz>
the downside is, you need to update your extlinux.conf to load those overlays I believe
<qschulz>
the bonus point is, when you make a modification to your DT, it won't recompile the whole linux kernel, only that recipe where you do Out-of-Tree device tree overlay builds
<qschulz>
(out-of-tree of the kernel, not out-of-tree of Yocto)
<qschulz>
tlwoerner: also, depending on what exactly you're doing, maybe those changes could be upstreamed so you don't have to maintain them in a few releases?
<qschulz>
tlwoerner: the syntax for device tree overlays is slightly different than a normal device tree but it's mostly some boilerplate
<qschulz>
tlwoerner: oooooh actually they made improvements to the device tree overlays syntax, it's virtually the same thing as writing a device tree now!
<qschulz>
Kwiboo: ok, so maybe we should add a new kconfig option for enabling this usb-472 binary generation and make it depend on TPL=y
<qschulz>
or guard the whole block in the dtsi with #ifdef TPL
stikonas has quit [Ping timeout: 255 seconds]
<qschulz>
tlwoerner: though you'd still need to handle your defconfig fragments within the kernel recipe you want to build, but .scc files should be supported in kernel recipes I believe?
<qschulz>
tlwoerner: in extlinux.conf you can (or supposed to be able to) load overlays with the devicetree-overlays/fdtoverlays entry
<qschulz>
Kwiboo: I was also wondering if there was a way to pass a U-Boot environment via USB too
<qschulz>
which would be useful for example to autostart rockusb/dfu/fastboot and specify on which medium (mmc0/1/sf...)
<qschulz>
instead of having two complete different images
<qschulz>
2+ :)
<qschulz>
like rockchip is doing for example
digetx has quit [Ping timeout: 252 seconds]
digetx has joined #linux-rockchip
<qschulz>
maybe putting the env at a specific address is DRAM + using env import from CLI could be a simple way to do that?
warpme_ has joined #linux-rockchip
warpme_ has quit [Read error: Connection reset by peer]
warpme__ has joined #linux-rockchip
stikonas has joined #linux-rockchip
stikonas_ has quit [Ping timeout: 248 seconds]
digetx has quit [Quit: No Ping reply in 180 seconds.]
digetx has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 252 seconds]
eballetbo has quit [Quit: Connection closed for inactivity]
<Kwiboo>
qschulz: could not see an existing ENV_IS_IN_RAM or similar option, so possible not with help of existing features, not sure what would be the best way to handle such autostart, for CI/labgrid use I guess you would like to have a build that stop at u-boot cli (BOOTDELAY=-1)
<qschulz>
Kwiboo: yeah that's fine with labgrid or such
<qschulz>
but I don't expect customers/users to spawn labgrid just to flash a device :D
<qschulz>
e.g. snagboot comes to mind
<qschulz>
but more simply, having it compatible with rkdeveloptool would probably be nice
<qschulz>
except that you need to start rockusb by specifying which block type and device to use
<qschulz>
(e.g. rockusb 0 mmc 0)
<qschulz>
(well, and also the USB controller to use but eh)
warpme__ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<Kwiboo>
yeah, would be nice to have something like that, to me there is no clear option on how to get there at the moment
<qschulz>
Kwiboo: yeah, baby steps :)
<qschulz>
let's start by finally being able to boot that thing completely over USB and then we can figure out the rest
<Kwiboo>
adding a kconfig option as you suggested is probably good, and maybe a rockchip-ramboot.config fragment or similar to enable the feature
<qschulz>
Kwiboo: I would simply enable it by default on the SoC level
<qschulz>
or even architecture level if there's a CONFIG_ROCKCHIP of some sorts
<qschulz>
and just check if you have TPL enabled
<qschulz>
as opposed to SPI, all Rockchip devices do have some DRAM :)
<qschulz>
so to me this falls in the same category as building an image for the eMMC
<qschulz>
/SD
<qschulz>
even more versatile since not all boards do have eMMC/SD
<Kwiboo>
hehe, yeah, probably easier that, one thing I did not understand was why binman started complain about u-boot-spl/any, hence why I just added the type=blob and filename props
<qschulz>
Kwiboo: mmmm but we didn't need those in the past for the SPI image?
<qschulz>
RK3399 Puma compiles both MMC and SPI images, does it complain without your patches too?
<qschulz>
maybe they changed something in binman "recently"?
<Kwiboo>
yeah, was not needed before, had to add for ramboot output, but when testing the second time it started to complain about spi image
<Kwiboo>
"in entry '/binman/simple-bin-ramboot/u-boot-spl/u-boot-spl-nodtb': Entry 'u-boot-any' not found in list (u-boot-spl-nodtb,u-boot-spl-dtb,u-boot-spl,fit,simple-bin-ramboot)"
<Kwiboo>
probably something recently changed in binman
<qschulz>
we should probably report that before we go too far in the 2025.01 rcs :)
psydroid has joined #linux-rockchip
franoosh has quit [Ping timeout: 248 seconds]
<qschulz>
ah not sure it is related
<qschulz>
but you have u-boot-spl directly under the image for ramboot, while we have it in mkimage entry for spi
<qschulz>
I guess if you have type=blob + filename in ramboot section, you don't need to do any change in spi?
<Kwiboo>
I do not seem to get such issue with latest master, so my other patches or adding the simple-bin-ramboot must affect binman
<Kwiboo>
at first I only had to do that for the ramboot image, but now both spi and ramboot
<Kwiboo>
very strange, and probably buggy behavior, did not try to look into why, adding type=blob+filename was quick and dirty fix :-)
<qschulz>
:)
<qschulz>
it's probably better anyway
<qschulz>
i'm wondering if without it doesn't actually necessarily reuse the same binary
<Kwiboo>
just tested adding a clone of simple-bin-spi named simple-bin-spi2 and get a new issue now:
<Kwiboo>
binman: Node '/binman/simple-bin-spi2/fit': Offset 0x60000 (393216) overlaps with previous entry '/binman/simple-bin-spi2/mkimage' ending at 0x63000 (405504)
<qschulz>
Kwiboo: can you post a git diff somewhere?