umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
LeSpocky has quit [Ping timeout: 268 seconds]
LeSpocky has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
lucascastro has joined #u-boot
mrnuke has joined #u-boot
lucascastro has quit [Ping timeout: 252 seconds]
vagrantc has quit [Quit: leaving]
thopiekar has joined #u-boot
xroumegue has quit [Ping timeout: 268 seconds]
xroumegue has joined #u-boot
Xeroine has joined #u-boot
monstr has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
Xeroine has quit [Ping timeout: 252 seconds]
alan_ has joined #u-boot
alan_o has quit [Remote host closed the connection]
swiftgeek has quit [Ping timeout: 268 seconds]
swiftgeek has joined #u-boot
gsz has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
sszy has joined #u-boot
pymp has joined #u-boot
mrnuke has quit [Ping timeout: 268 seconds]
<pymp>
hi, i am working on a zynq-7000, and i'd like to flash the eMMC easily. AMD/Xilinx provides a program to flash the QSPI flash but i cannot find anything about the eMMC. JTAG works fine, i can boot to u-boot, push the kernel in memory and issue some commands to u-boot to jump on it. One question, does u-boot provides some kind of buffer/rpc
<pymp>
mechanismes to issue command by polling the memory or something, so i can push commands using JTAG, ideally i'd like to send keystrokes, but idk, any ideas ?
mrnuke has joined #u-boot
GNUtoo has joined #u-boot
apritzel has joined #u-boot
frieder has joined #u-boot
<hramrach>
while you push the u-boot maybe you can push a script a well, and run it right away
<marex>
monstr: doesn't vivado support writing emmc these days ?
<marex>
pymp: you can try and have a look at 'ums' command , that lets you export block device as USB mass storage via USB peripheral (the DWC2 controller in zynq I think)
<monstr>
marex: on som there is utility which allows you to write wic image to emmc
<monstr>
and in vivado/vitis there was in past option to write boot.bin to small or bigger fat partition on emmc
<monstr>
but I don't think you can really write whatever you want
<pymp>
hramrach: i might do this
<marex>
oh doh, or ... tftp the file.gz into DRAM and then use 'gzwrite' command to unpack and write to block device
<pymp>
monstr: vivado is piece a cr** imo
<marex>
milkylainen: ^
<marex>
pymp: unfortunatelly I agree with your opinion ... for years
<pymp>
i hope AMD will tidy things a bit and make this whole ecosystem more opensource / user friendly
<marex>
pymp: btw about the sending keystrokes, it is possible to rebuild that miniuboot xilinx uses and have it drop into shell
<marex>
then you can control it over the DDC channel
<marex>
but I don't remember whether it supports SD/MMC access, probably not
<pymp>
what they call the FSBL
<marex>
pymp: on zynq7000 you can use plain u-boot SPL and then u-boot, no need for FSBL if I recall it right
<marex>
I take it you're trying to find the best way to commission board(s) in factory, aren't you ?
<pymp>
FSBL is useful if you want to push a bitstream in the PL before u-boot i guess
<marex>
iirc SPL can do that for you too, but better talk to monstr about the details
<pymp>
marex: i am not there yet, just trying to implement a usecase
<marex>
there are many options how to go about this, with that xilinx miniuboot and xsdb (I think) even more
<pymp>
anyway thanks for the ideas, and all, i'll have a look at the mini u-boot just in case... but what someone did with https://github.com/raczben/zynq_flash would be a cool feature to add to u-boot maybe
<pymp>
(to interrupt to the autoboot and send commands)
<marex>
isnt this exactly what xsdb does already (for QSPI NOR) ?
<marex>
ah
<pymp>
i dont know much about wsdb, i guess it might run under hood of vivado, i use xsct to push commands to it
<marex>
xsdb% jtagterminal
<marex>
try ^ that
<marex>
that might give you access to the miniuboot console
<pymp>
s/wsdb/wsdb/
<pymp>
s/wsdb/xsdb/ sorry
<marex>
I think I am misusing vivado left and right myself
<marex>
*shrug*
<pymp>
using jtagterminal? uhm might be easier to send keystrokes directly over /dev/ttyUSB1 :)
<pymp>
marex: me too i think ^^
<marex>
pymp: the miniuboot communicates only over ARM DDC (the in-band in-JTAG debug channel)
<marex>
that's why the jtagterminal
<marex>
but I think the jtagterminal is some tcl script, so you might be able to tap into that somehow and interact with the miniuboot outside of it
<marex>
the jtagterminal is probably the keyword to look for
<marex>
if your rebuild the miniuboot with UART support, sure, you can load it via xsdb, start it, and operate it via UART
<pymp>
i guess that's how flash_program works under the hood
<marex>
these are my notes for zynqmp ... its likely similar for zynq7000
<pymp>
and the documentation of flash_program says eMMC flashing is only available for UltraScale, so i guess it's a dead end
<marex>
I wonder
<marex>
look at this:
<marex>
xsdb% rst -processor
<marex>
xsdb% dow fsbl/executable.elf
<marex>
xsdb% con
<marex>
xsdb% stop
<marex>
xsdb% mwr -bin -file BOOT.bin 0xffdc0000
<marex>
xsdb% jtagterminal
<marex>
xsdb% dow u-boot
<marex>
xsdb% con
<marex>
I _think_ that's a way to start FSBL, make it init HW, then start U-Boot proper
<marex>
once in U-Boot, you can write the eMMC
<pymp>
does u-boot supports DDC out of the box ?
<marex>
I _think_ so, the miniuboot shouldn't be all that alien
<marex>
iirc xilinx is trying to keep things reasonably in sync with upstream
<marex>
so yes, you might even be able to avoid connecting the UART
<marex>
but remember, download via this xilinx platform cable is painfully slow, so you might want ethernet/usb/whatever connected to the board for any larger transfers
<pymp>
that would be neat, i'll try this, if it works i'll give you feedback on this if you are interested
<pymp>
it's slow but the OS is small so...
<marex>
note that I never worked with zynq7000 ;-)
<marex>
all my notes above are from zynqmp (ultrascale)
<pymp>
according to your TCL script, it looks like it gives control to the parent process of xsdb, interesting...
<milkylainen>
marex: Sorry. I'm not following. Was there a question regarding the ps/pl in zynqmp?
<milkylainen>
I haven't dealt with them in a while.
<pymp>
i was just looking for a way to program the eMMC over JTAG (maybe using u-boot)
<milkylainen>
Hmm. I think I was using qspi when bumping my head with zynqmp.
<pymp>
qspi works :)
<milkylainen>
remember putting the bitsteam in pl via fsbl, because we had to do an early load.
<milkylainen>
I was looking for a way to do late loading via overlays. But had several issues at that point in time.,
Skiper has joined #u-boot
Skiper has quit [Client Quit]
Skiper has joined #u-boot
<marex>
milkylainen: nope, I just recall you complaining about vivado
<milkylainen>
marex: I commend your memory banks. High quality retainment. :)
<milkylainen>
Yeah. Vivado ¤"#%&#¤&/¤
<marex>
heh
<pymp>
good memories apparently ^^
<marex>
sadly I don't remember who ever praised vivado for its quality ...
<milkylainen>
marex: Regarding stm32mp157f-dk2 (atleast). Lets just say I have a hard time not follow STs recommended ecosystem versions for TF-A, U-boot and kernel. ST is also ditching sp_min and going for a full op-tee only iiuc in the next ecosystem version.
<marex>
ugh
<milkylainen>
There is just so much interaction between the three I get stuck at various bits and pieces whatever I try to replace with vanilla.
<marex>
milkylainen: I had the same problem, since then I just stopped using the remaining two unless absolutelly necessary
<marex>
U-Boot does provide PSCI interface for this platform, including suspend/resume
<milkylainen>
I even doubt they have done a good job validating sp_min (which still should be supported) in the current ecosystem. Because I just can't get it to work. I mean. How hard can tf-a without tbbr be? (like a few options and you're done).
<milkylainen>
marex :\
<marex>
milkylainen: it seems to me like this sp-min/atf stuff is not entirely coming from st, but I might be wrong
<milkylainen>
marex: I understand why you ended up there. I've wasted so much time. Unfortunately, I can only recommend stuff to my customer. Technically U-Boot spl with a signed fsbl should cover their checkbox of "secure boot". They have no intrisic requirement of "TF-A/TBB"
<monstr>
pymp: marex: There are a lot of things you discussed
<monstr>
jtagterminal is just tcl script which access arm dcc port via jtag
<monstr>
program_flash is using mini u-boot configuration with console over dcc to program devices by chucks stored in ocm
<monstr>
IIRC emmc case is also using DDR for that specific designs
<monstr>
xsdb/xsct - they are keep changing names but xsct have xsdb inside. It is just user interface for hw_server which manage communication over jtag
<monstr>
zynq is using cse configuration but technique is the same
<monstr>
one thing what program_flash is using and the second what mini u-boot configuration can support
<monstr>
but I can't see any reason for you to use mini configurations for emmc programming. Mini configurations are small to fit to OCM and not to deal with different DDR configurations that's why it is generic for all targets
<monstr>
you likely target your boards and you can boot directly to full u-boot running out of DDR and do programming
<monstr>
in past I was designing this in a way to have boot.bin on SD with emmc image on SD and u-boot just load it from SD and program it to EMMC
<monstr>
on manufacturing IIRC just emmc image is provided and manufacturer do programming self
<monstr>
maybe even before emmc is soldered down on the board
<monstr>
ddc/uart - both consoles are supported - you can just point to that consoles and should work out of box
persmule has quit [Remote host closed the connection]
<monstr>
pymp: tbh I am not sure if zynq was capable to boot out of EMMC. If you want to use jtag for programming I would recommend you to buy smartlynq cable which will save money when you do programming over jtag
<monstr>
but it more or less depends on your board and configurations
<pymp>
thanks monstr
<pymp>
jtag is integrated on the board, so it costs a USB cable
<monstr>
but normally if you take a look at xilinx boards jtag is over usb via ftdi chips but there is also pc4 connector
<monstr>
and ftdi based cables are slower then other jtag solutions. It means if you pay for manufacturing time and save 20seconds on thusands of boards you save a lot of money at the end
<pymp>
i dont think the customer is planning to produce a large amount, it's a bit specific
<pymp>
but i may be wrong
<milkylainen>
Strange. When I use the kernels stm32mp157-dk2-scmi.dts I get an error reserving fdt memory region. But not when I use the non-scmi counterpart?
<monstr>
what interfaces do you have on that board?
<pymp>
monstr: i had continuous integration in mind
<monstr>
just jtag or ethernet, sd, usb?
<pymp>
right now it's just a bow with USB, but it's a trenz module with a trenz carrier board inside (integration at its best)
<milkylainen>
62390 bytes dtb vs 63263 bytes scmi dtb.
<pymp>
s/bow/box/
<monstr>
is that usb for jtag, uart or usb as host?
<monstr>
or usb device
<pymp>
it's JTAG+UART over USB
<pymp>
maybe JTAG over UART + UART over USB
<monstr>
it will be visible from schematics
<monstr>
ok - then sort of you have only jtag options
<pymp>
lsub tells me 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC
<monstr>
how big is that image to emmc you want to write?
<pymp>
small enought to fit twice inside QSPI
<monstr>
ok then your situtation is very simple
<monstr>
load fsbl
<monstr>
load emmc image to ddr
<monstr>
load u-boot to DDR with preboot command setup to take emmc_image from DDR and burnt it to emmc and that's it
<monstr>
is it file in any filesystem or you want to use it in raw mode?
lucascastro has joined #u-boot
<pymp>
yes that was my initial plan, but i wanted to avoid typing commands on UART, so i was asking for a way to take over u-boot control from a JTAG/TCL script (hence the talk about jtagterminal)
<monstr>
or you want emmc to be used for booting (not sure if possible on zynq as I wrote above)
<monstr>
use preboot - you don't need to write anything there
<monstr>
or use boot script and load it before u-boot and let u-boot to pick it up automatically
<pymp>
it would be FSBL + u-boot in QSPI, then u-boot loads a fitImage from the eMMC
<monstr>
and from raw emmc or ext2/3/fat in emmc?
<pymp>
fitImage is small, the rest of the eMMC is for storage, it just needs a partitioning
<monstr>
your linux image at first boot will create FS or extend storage partition
<pymp>
i'd say raw emmc, since the OS should run in ram, placing the kernel on a partition might be useless at this point, but who knows...
<pymp>
yeah that's the idea
<monstr>
u-boot is not capable to format any filesystem. It means if you want to have fit image in fat. Create it on x86 and not write fit image but fat partition with fit image inside
<monstr>
ok - then your task is not complicated.
<monstr>
xsdb
<monstr>
dow fsbl
<pymp>
still i don't know why they want the kernel+ramfs on the eMMC, it adds complexity for nothing. An other option would be to have the kernel on the rootfs on the eMMC, so the user can update kernel more easily...
<monstr>
delay 5s
<monstr>
stop
<monstr>
dow -data boot.bin-for-qspi 0x....
<monstr>
dow -data ext.img 0x...
<monstr>
dow -data boot.script 0x...
<monstr>
dow u-boot.elf
<monstr>
run
<pymp>
atm the boot script is located inside the FSBL, not sure if i should take it out
<monstr>
and configure u-boot to way to remove bootdelay - set it up to 1 or 0, configure bootscript pick up address (if it is not already properly configured)
<monstr>
and in boot script write. sf probe 0, sf erase 0 +size, sf write ddr_qspi_addr 0 size
<monstr>
and then the same for emmc
<pymp>
no i am wrong the boot script is located on the QSPI
<monstr>
but that's bootscript for booting system. I am talking about programming script
<monstr>
and keep console over uart to be able to see that process all the time
<monstr>
and if you need to program that boot script to qspi - just load it to ddr and write it to location you like
<monstr>
in 30 mins you are done
<monstr>
:-)
<pymp>
i think i have mostly everything done already, but i need to reconfigure u-boot to load it's bootscript from ram first, then, if it fails, use the one on the QSPI, correct ?
<monstr>
I would separate that two u-boot from each other
<pymp>
i see
<monstr>
but you can do whatever you like :-)
<pymp>
the QSPI boot script could check at an address for another boot script... but this would add delay at normal boot
mmu_man has joined #u-boot
<monstr>
distroboot is enabled - that's why u-boot should find out if you boot from jtag or qspi
<monstr>
and based on that do action
<monstr>
I can double but I think we are also exporting u-boot variables based on boot mode you use
<pymp>
i need to rtfm distroboot now, thanks :)
<monstr>
case ZYNQ_BM_JTAG:
<monstr>
mode = "jtag pxe dhcp";
<monstr>
env_set("modeboot", "jtagboot");
<monstr>
break;
<pymp>
ha yes it's this variable ok i see
<monstr>
modeboot is that variable which you can use
<pymp>
hum, so i only need to place jtag before qspi in boot_targets
<pymp>
or leave it like and clear the QSPI first...
<pymp>
too many options... thanks
<monstr>
when you boot from jtag - jtag is the first, when you boot from qspi, qspi is the first
<monstr>
board code has logic how to setup boot_targets at run time
<pymp>
booted u-boot from jtag, i don't jtag first...