I tried these changes on a Zybo and it works fine.

Tested on a Zybo board (armv7) and it boots.

In D34687#786708, @mhorne wrote:

Hi, the patch does not apply correctly to the main branch. Can you rebase and re-upload the diff with context?

I tested this yesterday on a Zybo and it autoloaded just fine.

• Address review feed-back on iicoc driver.

In D31562#714069, @jrtc27 wrote:

Please elaborate on "Fix a bug in sifive_spi.c." when committing, and please mark for MFC (I have yet to do the big batch of MFCs for the other commits to stable/13 but will get round to it soon).

• Address revision feedback.

• Enable 4-byte addressing for is25wp256 flash.

• Address some revision feedback.

cgem: fix media changes on SiFive platforms.

How would that look? The gemgxclk clock driver in fu540_prci.c calls a routine here to set the clock select bit?

In D31148#701041, @jrtc27 wrote:

In D31148#701028, @skibo wrote:

In D31148#700947, @jrtc27 wrote:

I was thinking it would be better to shim the clock like Linux does so cgem_mediachange doesn't need to be changed and all the new logic is localised

I thought this is how the Linux driver handles it. The "management" block registers are in this driver's device-tree node and the tx clock select is set in the Linux driver in fu540_macb_tx_set_rate().

Which is called via the set_rate member of their fu540_c000_ops clk_ops struct, ie their equivalent of clknode's set_freq. Their macb_set_tx_clk (equivalent of mediachange) just blindly calls clk_set_rate, i.e. our clk_set_freq.

In D31148#700947, @jrtc27 wrote:

I was thinking it would be better to shim the clock like Linux does so cgem_mediachange doesn't need to be changed and all the new logic is localised

I have tested this revision on both Zybo (arm32) and a Zynq Ultrascale (arm64) a while ago.

In D24304#626425, @mhorne wrote:

Makefile update looks good to me! You might want to bump .Dd when you commit.

• Bump date in man4/cgem.4.

• Use MACHINE_CPUARCH in share/man/man4/Makefile.

In D24304#626223, @skibo wrote:

Use MACHINE_CPUARCH in share/man/man4/Makefile.

Use MACHINE_CPUARCH in share/man/man4/Makefile.

In D24304#626062, @mhorne wrote:

Hi @skibo , is there any remaining work to be done on this patch? It appears to be ready to go, other than one small nitpick. It would be nice to see it committed before stable/13 branches later this month.

Incorporate suggested fixes to man page.

Simplify support for 64-bit systems.
This diff got ugly because I was trying to support the case of a 32-bit
device in a 64-bit kernel. But, I don't think that would work anyway and
I think it's safe to assume that any 64-bit system (arm64 or riscv64) will
have a 64-bit capable gem core. Also, I have added support for using the
clock infrastructure for changing the transmit reference clock which I need
for my zynqmp implementation.

Add device id definitions to zy7_slcr.h and clean up style and white-spaces.

In D14429#548577, @jmg wrote:

Thanks, tried to do this from FreeBSD, but couldn't figure out how to dump the entire register:

Zynq> md 0xf8f00004 1
f8f00004: 00000511                               ....
Zynq> md 0xf8000530 1
f8000530: 13723093                               .0r.

Hmm.. that sysctl didn't work, but there was pssid:

freebsd@generic:~ % sysctl hw.zynq.pssid
hw.zynq.pssid: 0x13723093: manufacturer: 0x49 device: 0x3 family: 0x1b sub-family: 0x9 rev: 0x1

Check SLCR.PSS_IDCODE to determine if this is a single-core Zynq chip.

In D14429#548354, @jmg wrote:

I just tested this on my Cora Z7-07S board, and it looks like there's a hardware bug that prevents this patch from working.

I added a printf to dump mp_maxid and mp_ncpus, and I get 1 and 2 respectively, which per the TRM indicates that it's suppose to have 2 cpus instead of 1.

Pull URL to next line in if_cgem_hw.h.

In D24304#539618, @philip wrote:

I am a little dubious about the many instances of #if INTPTR_MAX == INT64_MAX compile-time gymnastics.

Remove some local changes that leaked into last update.

Tweak cgem description in config files. Correct man page with regards to which
devices the rxhangwar is enabled.

Update stale patch.

Ok, roast me!

Change clk_reg_val to uint32_t.

Remove mx25l from GENERIC conf. Tweak compatible strings for flash memory in zedboard/zynq .dts files so that devd can find the mx25l module.

I'll look into submitting the fix to u-boot but it won't appear until 2020.04.

This diff is no longer valid because the Zynq u-boot ports have been removed.

Minor style tweaks and whitespace clean-up.

Add device to GENERIC kernel.

Fix tiny regression in documentation reference.

Style changes.

I had the incorrect clock value for Zybo. It uses a 200 Mhz reference clock just like the Zedboard. So put default reference clock value and spi clock value into zynq-7000.dtsi

Also, u-boot-master/Makefile creates a boot.scr for all arm boards but the zynq boards ignore it and don't need it. Should we come up with an exception for zynq boards?

Remove uEnv.txt.

Cleaning up very old stuff. We don't need ubldr on arm64.

Indentation, cite updated reference manual w.r.t. transmit fifo quirk.

Change driver declaration to fix a bug that caused the wrong kind of spibus to attach. Thanks, Ian Lepore.

I've made suggested changes but the driver has regressed: the flash device doesn't get recognized. I'm looking into it.

Add sys/dev/flash/mx25lreg.h which has two new flash commands added.

Take driver out of GENERIC kerne. Make other minor fix-ups.

Any chance of getting this committed before code freeze? I think it's ready. I'm not comfortable making the changes to mx25l.c to support dual stacked memories (I have no hardware to test that) but I've left in the hooks needed in this driver.

Add compatible string for Zynq Ultrascale which uses same qspi device.

Fix support for dual parallel and stacked memories (changes provided by John Sears). Change config option from zy7_qspi to just qspi.

Add license identifier. Add comment saying what this is. Move forward declaration of zy7_detach. Add MODULE_DEPEND and DRIVER_MODULE.

Add driver to GENERIC kernel. Add untested support for dual parallel and stacked memories.

In D14698#311089, @manu wrote:

Why do we still use a non-GENERIC kernel config and custom DTS for this board ?

Properly free resources if zy7_qspi_init_hw() fails.

In D5512#142566, @lattera-gmail.com wrote:

Is there any objection to this getting committed? This may help with the RPI3 work we're doing at BSDCan right now.

I did not know about the clock framework. I can look into migrating the Zynq stuff to it but I may not get to it in time for 11.0-RELEASE. I'd like to see this committed and treat migrating to the gnu dts as a separate project.

In D6095#129897, @andrew wrote:

Have you tried using the Linux dts files in sys/gnu/dts/arm? I prefer us moving towards using them over our non-standard entries.

In D5512#119500, @mst_semihalf.com wrote:

I noticed there was still one compilation error not resolved here, namely:

sys/boot/uboot/lib/disk.c:160:7: error: format specifies type 'int' but the argument has type 'size_t' (aka 'unsigned long') [-Werror,-Wformat]

size, SI(dev).bsize);

Changing the format specifier for 'size' from %d to %zu should make it work on all archs.

In D5512#119387, @andrew wrote:

If you need to load something at a specific address I would prefer it was a boot1 like tool. This would then load ubldr from UFS and branch to it.

Alternatively, what's wrong with loading the .bin file & running it with go?

In D5512#119480, @mst_semihalf.com wrote:

Yes you can always just run the .bin file. Just wanted to point out that the '-pie' version will possibly never work with U-Boot, while the non-pie version would be nice to keep as it is confirmed to be working. I remember when I tested the initial patches by Thomas (version from the mailing list) on my ARM64 board I could not get the .bin version to work - it got to the prompt but loading the kernel via network hanged indefinitely. The ELF version , however, loaded and booted the kernel.

Missed a clean file.