Message ID | 1452555198-11860-1-git-send-email-dwesterg@gmail.com |
---|---|
State | Superseded |
Headers | show |
On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See wrote: > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang See wrote: > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen wrote: > [...] > > > btw. Completely off-topic, but is there any chance altera will > > release the > > algorithm to compute these magic values which are in the header files > > from > > the base values inserted into the HPS component in QSys ? > > I would not suggesting that as Qsys and Quartus are doing heavylifting > tasks there. The value would depends on the options being choosed, > device type, device revision (if any). They also being patched from > time to time too. Is it all really _that_ complicated ? That's why I'd like to see the code that's doing all that computation. Even if it's done at compile-time, it'd still be better than the horrible headers which we have to use now. > > I think we might > > just put these values into OF and do the computation in U-Boot on-the > > -fly. > > This would also remove the need for this script. > > Slightly off topic, I am thinking to move all these generated files > into DTS too. This will have some out of box experience as Arria10 SoC. > But that might be challenging in term of resources. We might still > stick with this script for good. See above. Best regards, Marek Vasut
On Tue, 2016-01-12 at 03:48 +0100, Marek Vasut wrote: > On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See wrote: > > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang See > > > wrote: > > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen wrote: > > [...] > > > > > btw. Completely off-topic, but is there any chance altera will > > > release the > > > algorithm to compute these magic values which are in the header > > > files > > > from > > > the base values inserted into the HPS component in QSys ? > > > > I would not suggesting that as Qsys and Quartus are doing > > heavylifting > > tasks there. The value would depends on the options being choosed, > > device type, device revision (if any). They also being patched from > > time to time too. > > Is it all really _that_ complicated ? That's why I'd like to see the > code > that's doing all that computation. Actually more challenges is that the code is proprietary. We might get stopped by legal team before making this happen too. > Even if it's done at compile-time, it'd > still be better than the horrible headers which we have to use now. > I believe DTS would be better format than header file. Thanks Chin Liang
On Wednesday, January 13, 2016 at 03:05:40 AM, Chin Liang See wrote: > On Tue, 2016-01-12 at 03:48 +0100, Marek Vasut wrote: > > On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See wrote: > > > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang See > > > > > > > > wrote: > > > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen wrote: > > > [...] > > > > > > > btw. Completely off-topic, but is there any chance altera will > > > > release the > > > > algorithm to compute these magic values which are in the header > > > > files > > > > from > > > > the base values inserted into the HPS component in QSys ? > > > > > > I would not suggesting that as Qsys and Quartus are doing > > > heavylifting > > > tasks there. The value would depends on the options being choosed, > > > device type, device revision (if any). They also being patched from > > > time to time too. > > > > Is it all really _that_ complicated ? That's why I'd like to see the > > code > > that's doing all that computation. > > Actually more challenges is that the code is proprietary. We might get > stopped by legal team before making this happen too. What's proprietary about it ? Isn't that SDRAM controller made in-house by Altera ? > > Even if it's done at compile-time, it'd > > still be better than the horrible headers which we have to use now. > > I believe DTS would be better format than header file. Coming up with sensible bindings would be hard though. Best regards, Marek Vasut
On Wed, 2016-01-13 at 03:07 +0100, Marek Vasut wrote: > On Wednesday, January 13, 2016 at 03:05:40 AM, Chin Liang See wrote: > > On Tue, 2016-01-12 at 03:48 +0100, Marek Vasut wrote: > > > On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See > > > wrote: > > > > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > > > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang See > > > > > > > > > > wrote: > > > > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen wrote: > > > > [...] > > > > > > > > > btw. Completely off-topic, but is there any chance altera > > > > > will > > > > > release the > > > > > algorithm to compute these magic values which are in the > > > > > header > > > > > files > > > > > from > > > > > the base values inserted into the HPS component in QSys ? > > > > > > > > I would not suggesting that as Qsys and Quartus are doing > > > > heavylifting > > > > tasks there. The value would depends on the options being > > > > choosed, > > > > device type, device revision (if any). They also being patched > > > > from > > > > time to time too. > > > > > > Is it all really _that_ complicated ? That's why I'd like to see > > > the > > > code > > > that's doing all that computation. > > > > Actually more challenges is that the code is proprietary. We might > > get > > stopped by legal team before making this happen too. > > What's proprietary about it ? Isn't that SDRAM controller made in > -house > by Altera ? Oh seems we might discussing slightly different things. I am referring to IOCSR which is the bitstream for setting up the IO buffers. I presume you are referring to SDRAM configuration, right? > > > Even if it's done at compile-time, it'd > > > still be better than the horrible headers which we have to use > > > now. > > > > I believe DTS would be better format than header file. > > Coming up with sensible bindings would be hard though. > Yah, that why this is get rid when we switch to Arria 10 SoC :) Thanks Chin Liang > Best regards, > Marek Vasut
On Wednesday, January 13, 2016 at 03:23:38 AM, Chin Liang See wrote: > On Wed, 2016-01-13 at 03:07 +0100, Marek Vasut wrote: > > On Wednesday, January 13, 2016 at 03:05:40 AM, Chin Liang See wrote: > > > On Tue, 2016-01-12 at 03:48 +0100, Marek Vasut wrote: > > > > On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See > > > > > > > > wrote: > > > > > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > > > > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang See > > > > > > > > > > > > wrote: > > > > > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen wrote: > > > > > [...] > > > > > > > > > > > btw. Completely off-topic, but is there any chance altera > > > > > > will > > > > > > release the > > > > > > algorithm to compute these magic values which are in the > > > > > > header > > > > > > files > > > > > > from > > > > > > the base values inserted into the HPS component in QSys ? > > > > > > > > > > I would not suggesting that as Qsys and Quartus are doing > > > > > heavylifting > > > > > tasks there. The value would depends on the options being > > > > > choosed, > > > > > device type, device revision (if any). They also being patched > > > > > from > > > > > time to time too. > > > > > > > > Is it all really _that_ complicated ? That's why I'd like to see > > > > the > > > > code > > > > that's doing all that computation. > > > > > > Actually more challenges is that the code is proprietary. We might > > > get > > > stopped by legal team before making this happen too. > > > > What's proprietary about it ? Isn't that SDRAM controller made in > > -house > > by Altera ? > > Oh seems we might discussing slightly different things. I am referring > to IOCSR which is the bitstream for setting up the IO buffers. I > presume you are referring to SDRAM configuration, right? Yeah, I'm talking about the SDRAM controller configuration values. I know the IOCSR is a problem. I am reverse engineering the Cyclone IV bitstream format in my free time now and then, but I didn't have time to look at C V and I don't plan to do it any soon. I think even my C/IV activity might trigger someone in Altera once I get around to releasing it ;-) > > > > Even if it's done at compile-time, it'd > > > > still be better than the horrible headers which we have to use > > > > now. > > > > > > I believe DTS would be better format than header file. > > > > Coming up with sensible bindings would be hard though. > > Yah, that why this is get rid when we switch to Arria 10 SoC :) Well you'll still need to configure the HardIP which does the DDR calib with some DDR config values, so you cannot get rid of it entirely. Unless you pull these values from SPD, which I doubt would be the case, since the A10 would be mostly embedded chip. Best regards, Marek Vasut
On Wed, 2016-01-13 at 03:34 +0100, Marek Vasut wrote: > On Wednesday, January 13, 2016 at 03:23:38 AM, Chin Liang See wrote: > > On Wed, 2016-01-13 at 03:07 +0100, Marek Vasut wrote: > > > On Wednesday, January 13, 2016 at 03:05:40 AM, Chin Liang See > > > wrote: > > > > On Tue, 2016-01-12 at 03:48 +0100, Marek Vasut wrote: > > > > > On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See > > > > > > > > > > wrote: > > > > > > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > > > > > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang > > > > > > > See > > > > > > > > > > > > > > wrote: > > > > > > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen > > > > > > > > wrote: > > > > > > [...] > > > > > > > > > > > > > btw. Completely off-topic, but is there any chance altera > > > > > > > will > > > > > > > release the > > > > > > > algorithm to compute these magic values which are in the > > > > > > > header > > > > > > > files > > > > > > > from > > > > > > > the base values inserted into the HPS component in QSys ? > > > > > > > > > > > > I would not suggesting that as Qsys and Quartus are doing > > > > > > heavylifting > > > > > > tasks there. The value would depends on the options being > > > > > > choosed, > > > > > > device type, device revision (if any). They also being > > > > > > patched > > > > > > from > > > > > > time to time too. > > > > > > > > > > Is it all really _that_ complicated ? That's why I'd like to > > > > > see > > > > > the > > > > > code > > > > > that's doing all that computation. > > > > > > > > Actually more challenges is that the code is proprietary. We > > > > might > > > > get > > > > stopped by legal team before making this happen too. > > > > > > What's proprietary about it ? Isn't that SDRAM controller made in > > > -house > > > by Altera ? > > > > Oh seems we might discussing slightly different things. I am > > referring > > to IOCSR which is the bitstream for setting up the IO buffers. I > > presume you are referring to SDRAM configuration, right? > > Yeah, I'm talking about the SDRAM controller configuration values. Cool, let me take a look on the SDRAM handoff we have today. > > I know the IOCSR is a problem. I am reverse engineering the Cyclone > IV > bitstream format in my free time now and then, but I didn't have time > to look at C V and I don't plan to do it any soon. I think even my > C/IV > activity might trigger someone in Altera once I get around to > releasing > it ;-) haha :) There are various knob in Quartus that might change the IOCSR itself. Shall let the tools to handle it for better user experience. > > > > > > Even if it's done at compile-time, it'd > > > > > still be better than the horrible headers which we have to > > > > > use > > > > > now. > > > > > > > > I believe DTS would be better format than header file. > > > > > > Coming up with sensible bindings would be hard though. > > > > Yah, that why this is get rid when we switch to Arria 10 SoC :) > > Well you'll still need to configure the HardIP which does the DDR > calib > with some DDR config values, so you cannot get rid of it entirely. > Unless > you pull these values from SPD, which I doubt would be the case, > since > the A10 would be mostly embedded chip. Nope, its part of bitstream. Bitstream will contain the information on the DDR devices on the board. This is similar to what being implemented in traditional FPGA devices. Thanks Chin Liang > > Best regards, > Marek Vasut
On Wednesday, January 13, 2016 at 03:45:46 AM, Chin Liang See wrote: > On Wed, 2016-01-13 at 03:34 +0100, Marek Vasut wrote: > > On Wednesday, January 13, 2016 at 03:23:38 AM, Chin Liang See wrote: > > > On Wed, 2016-01-13 at 03:07 +0100, Marek Vasut wrote: > > > > On Wednesday, January 13, 2016 at 03:05:40 AM, Chin Liang See > > > > > > > > wrote: > > > > > On Tue, 2016-01-12 at 03:48 +0100, Marek Vasut wrote: > > > > > > On Tuesday, January 12, 2016 at 01:50:18 AM, Chin Liang See > > > > > > > > > > > > wrote: > > > > > > > On Tue, 2016-01-12 at 01:31 +0100, Marek Vasut wrote: > > > > > > > > On Tuesday, January 12, 2016 at 01:26:58 AM, Chin Liang > > > > > > > > See > > > > > > > > > > > > > > > > wrote: > > > > > > > > > On Mon, 2016-01-11 at 15:33 -0800, Dalon Westergreen > > > > > > > > > > > > > > > > wrote: > > > > > > > [...] > > > > > > > > > > > > > > > btw. Completely off-topic, but is there any chance altera > > > > > > > > will > > > > > > > > release the > > > > > > > > algorithm to compute these magic values which are in the > > > > > > > > header > > > > > > > > files > > > > > > > > from > > > > > > > > the base values inserted into the HPS component in QSys ? > > > > > > > > > > > > > > I would not suggesting that as Qsys and Quartus are doing > > > > > > > heavylifting > > > > > > > tasks there. The value would depends on the options being > > > > > > > choosed, > > > > > > > device type, device revision (if any). They also being > > > > > > > patched > > > > > > > from > > > > > > > time to time too. > > > > > > > > > > > > Is it all really _that_ complicated ? That's why I'd like to > > > > > > see > > > > > > the > > > > > > code > > > > > > that's doing all that computation. > > > > > > > > > > Actually more challenges is that the code is proprietary. We > > > > > might > > > > > get > > > > > stopped by legal team before making this happen too. > > > > > > > > What's proprietary about it ? Isn't that SDRAM controller made in > > > > -house > > > > by Altera ? > > > > > > Oh seems we might discussing slightly different things. I am > > > referring > > > to IOCSR which is the bitstream for setting up the IO buffers. I > > > presume you are referring to SDRAM configuration, right? > > > > Yeah, I'm talking about the SDRAM controller configuration values. > > Cool, let me take a look on the SDRAM handoff we have today. I'm looking forward to your findings :) > > I know the IOCSR is a problem. I am reverse engineering the Cyclone > > IV > > bitstream format in my free time now and then, but I didn't have time > > to look at C V and I don't plan to do it any soon. I think even my > > C/IV > > activity might trigger someone in Altera once I get around to > > releasing > > it ;-) > > haha :) There are various knob in Quartus that might change the IOCSR > itself. Shall let the tools to handle it for better user experience. Is it really that hard ? I'd kinda expect that it's only those bits which you can select in the pin planner and that's very close to what any other SoC can do with the pins. But I'm not really planning to dive into this any soon. > > > > > > Even if it's done at compile-time, it'd > > > > > > still be better than the horrible headers which we have to > > > > > > use > > > > > > now. > > > > > > > > > > I believe DTS would be better format than header file. > > > > > > > > Coming up with sensible bindings would be hard though. > > > > > > Yah, that why this is get rid when we switch to Arria 10 SoC :) > > > > Well you'll still need to configure the HardIP which does the DDR > > calib > > with some DDR config values, so you cannot get rid of it entirely. > > Unless > > you pull these values from SPD, which I doubt would be the case, > > since > > the A10 would be mostly embedded chip. > > Nope, its part of bitstream. Bitstream will contain the information on > the DDR devices on the board. This is similar to what being implemented > in traditional FPGA devices. Hmmmm, I see. That's also why you need to program the FPGA in SPL, right ? Oh, btw, about that, look at CONFIG_CMD_FPGA_LOADMK and CONFIG_CMD_FPGA_LOADBP, I think that functionality is something you might find useful when doing the SPL for A10. So far, it's xilinx specific (tsk, spit :-)~~* ) but it should be easy to adapt.
diff --git a/arch/arm/mach-socfpga/qts-filter.sh b/arch/arm/mach-socfpga/qts-filter.sh index c1640bc..b81a4e1 100755 --- a/arch/arm/mach-socfpga/qts-filter.sh +++ b/arch/arm/mach-socfpga/qts-filter.sh @@ -3,13 +3,15 @@ # # Process iocsr_config_*.[ch] # $1: SoC type -# $2: Input directory -# $3: Output directory +# $2: Input handoff directory +# $3: Input BSP Generated directory +# $4: Output directory # process_iocsr_config() { soc="$1" - in_dir="$2" - out_dir="$3" + in_qts_dir="$2" + in_bsp_dir="$3" + out_dir="$4" ( cat << EOF @@ -26,13 +28,13 @@ EOF # Retrieve the scan chain lengths grep 'CONFIG_HPS_IOCSR_SCANCHAIN[0-9]\+_LENGTH' \ - ${in_dir}/generated/iocsr_config_${soc}.h | tr -d "()" + ${in_bsp_dir}/generated/iocsr_config_${soc}.h | tr -d "()" echo "" # Retrieve the scan chain config and zap the ad-hoc length encoding sed -n '/^const/ !b; :next {/^const/ s/(.*)//;p;n;b next}' \ - ${in_dir}/generated/iocsr_config_${soc}.c + ${in_bsp_dir}/generated/iocsr_config_${soc}.c cat << EOF @@ -49,8 +51,9 @@ EOF # process_pinmux_config() { soc="$1" - in_dir="$2" - out_dir="$3" + in_qts_dir="$2" + in_bsp_dir="$3" + out_dir="$4" ( cat << EOF @@ -67,7 +70,7 @@ EOF # Retrieve the pinmux config and zap the ad-hoc length encoding sed -n '/^unsigned/ !b; :next {/^unsigned/ {s/\[.*\]/[]/;s/unsigned long/const u8/};p;n;b next}' \ - ${in_dir}/generated/pinmux_config_${soc}.c + ${in_bsp_dir}/generated/pinmux_config_${soc}.c cat << EOF @@ -84,8 +87,9 @@ EOF # process_pll_config() { soc="$1" - in_dir="$2" - out_dir="$3" + in_qts_dir="$2" + in_bsp_dir="$3" + out_dir="$4" ( cat << EOF @@ -102,7 +106,7 @@ EOF # Retrieve the pll config and zap parenthesis sed -n '/CONFIG_HPS/ !b; :next {/CONFIG_HPS/ s/[()]//g;/endif/ b;p;n;b next}' \ - ${in_dir}/generated/pll_config.h + ${in_bsp_dir}/generated/pll_config.h cat << EOF @@ -126,8 +130,9 @@ grep_sdram_config() { # process_sdram_config() { soc="$1" - in_dir="$2" - out_dir="$3" + in_qts_dir="$2" + in_bsp_dir="$3" + out_dir="$4" ( cat << EOF @@ -144,29 +149,32 @@ EOF echo "/* SDRAM configuration */" # Retrieve the sdram config, zap broken lines and zap parenthesis - sed -n "/\\\\$/ {N;s/ \\\\\n/\t/};p" ${in_dir}/generated/sdram/sdram_config.h | + sed -n "/\\\\$/ {N;s/ \\\\\n/\t/};p" \ + ${in_bsp_dir}/generated/sdram/sdram_config.h | sed -n '/CONFIG_HPS/ !b; :next {/CONFIG_HPS/ s/[()]//g;/endif/ b;p;n;b next}' | sort -u | grep_sdram_config echo "" echo "/* Sequencer auto configuration */" sed -n "/__RW_MGR/ {s/__//;s/ \+\([^ ]\+\)$/\t\1/p}" \ - ${in_dir}/hps_isw_handoff/*/sequencer_auto.h | sort -u | grep_sdram_config + ${in_qts_dir}/hps_isw_handoff/*/sequencer_auto.h | + sort -u | grep_sdram_config echo "" echo "/* Sequencer defines configuration */" sed -n "/^#define [^_]/ {s/__//;s/ \+\([^ ]\+\)$/\t\1/p}" \ - ${in_dir}/hps_isw_handoff/*/sequencer_defines.h | sort -u | grep_sdram_config + ${in_qts_dir}/hps_isw_handoff/*/sequencer_defines.h | + sort -u | grep_sdram_config echo "" echo "/* Sequencer ac_rom_init configuration */" sed -n '/^const.*\[/ !b; :next {/^const.*\[/ {N;s/\n//;s/alt_u32/u32/;s/\[.*\]/[]/};/endif/ b;p;n;b next}'\ - ${in_dir}/hps_isw_handoff/*/sequencer_auto_ac_init.c + ${in_qts_dir}/hps_isw_handoff/*/sequencer_auto_ac_init.c echo "" echo "/* Sequencer inst_rom_init configuration */" sed -n '/^const.*\[/ !b; :next {/^const.*\[/ {N;s/\n//;s/alt_u32/u32/;s/\[.*\]/[]/};/endif/ b;p;n;b next}'\ - ${in_dir}/hps_isw_handoff/*/sequencer_auto_inst_init.c + ${in_qts_dir}/hps_isw_handoff/*/sequencer_auto_inst_init.c cat << EOF @@ -176,30 +184,34 @@ EOF } usage() { - echo "$0 [soc_type] [input_dir] [output_dir]" + echo "$0 [soc_type] [input_qts_dir] [input_bsp_dir] [output_dir]" echo "Process QTS-generated headers into U-Boot compatible ones." echo "" - echo " soc_type\t\tType of SoC, either 'cyclone5' or 'arria5'," - echo " input_dir\t\tDirectory with the QTS project." - echo " output_dir\t\tDirectory to store the U-Boot compatible headers." + echo " soc_type - Type of SoC, either 'cyclone5' or 'arria5'," + echo " input_qts_dir - Directory with compiled Quartus project." + echo " input_bsp_dir - Directory with generated output from" + echo " the bsp-editor." + echo " output_dir - Directory to store the U-Boot compatible headers." echo "" } soc="$1" -in_dir="$2" -out_dir="$3" +in_qts_dir="$2" +in_bsp_dir="$3" +out_dir="$4" -if [ "$#" -ne 3 ] ; then +if [ "$#" -ne 4 ] ; then usage exit 1 fi -if [ ! -d "${in_dir}" -o ! -d "${out_dir}" -o -z "${soc}" ] ; then +if [ ! -d "${in_qts_dir}" -o ! -d "${in_bsp_dir}" -o \ + ! -d "${out_dir}" -o -z "${soc}" ] ; then usage exit 3 fi -process_iocsr_config "${soc}" "${in_dir}" "${out_dir}" -process_pinmux_config "${soc}" "${in_dir}" "${out_dir}" -process_pll_config "${soc}" "${in_dir}" "${out_dir}" -process_sdram_config "${soc}" "${in_dir}" "${out_dir}" +process_iocsr_config "${soc}" "${in_qts_dir}" "${in_bsp_dir}" "${out_dir}" +process_pinmux_config "${soc}" "${in_qts_dir}" "${in_bsp_dir}" "${out_dir}" +process_pll_config "${soc}" "${in_qts_dir}" "${in_bsp_dir}" "${out_dir}" +process_sdram_config "${soc}" "${in_qts_dir}" "${in_bsp_dir}" "${out_dir}"