[opensuse-arm] Re: [obs submit-request 141568] openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox: created by babelworx
On 16.11.2012, at 15:56, Ciaran Farrell wrote:
home:babelworx:branches:openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox -> openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox
https://build.opensuse.org/request/diff/141568
Description: Get CuBox working w/o manual uboot intervention
@@ -3,19 +3,39 @@ set -x
file=boot/boot.script +echo 'resetenv' >> $file +echo 'setenv kerneladdr 0x2000000' >> $file +echo 'setenv ramdiskaddr 0x3000000' >> $file +echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file +echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file +echo -n 'setenv bootargs "' >> $file +echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file +echo 'bootm 0x2000000 0x3000000' >> $file +echo 'boot' >> $file
Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM? Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot. Furthermore, this change only gets 12.2 working for you, but still fails on Factory. We should certainly find out why it doesn't work for you and get a generic solution up and rolling, so that Factory works too :). Alex
-echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file -echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file +#echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file +#echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file # CuBox Hack -echo 'if itest 1$arcNumber == 13905; then' >> $file -echo ' setenv kerneladdr 0x2000000' >> $file -echo ' setenv ramdiskaddr 0x3000000' >> $file -echo 'fi' >> $file -echo -n 'setenv bootcmd "' >> $file -echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file -echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file -echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file -echo 'boot' >> $file +#echo 'if itest 1$arcNumber == 13905; then' >> $file +#echo ' setenv kerneladdr 0x2000000' >> $file +#echo ' setenv ramdiskaddr 0x3000000' >> $file +#echo 'fi' >> $file +#echo -n 'setenv bootcmd "' >> $file +#echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file +#echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file +#echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file +#echo 'boot' >> $file + + +#echo '======== Setting bootargs ========' >> $file +#echo -n 'setenv bootargs "' >> $file +#echo -n 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 ' >> $file +#echo 'rootdelay=2 --no-log --verbose"' >> $file +#echo '======== Loading kernel ========' >> $file +#echo 'ext2load mmc 0:1 0x00200000 /boot/uImage' >> $file +#echo '======== Booting kernel ========' >> $file +#echo 'bootm' >> $file +
#========================================== # Create machine readable uboot format
To REVIEW against the previous version: osc request show --diff 141568
To ACCEPT the request: osc request accept 141568 --message="reviewed ok."
To DECLINE the request: osc request decline 141568 --message="declined for reason xyz (see ... for background / policy / ...)."
To REVOKE the request: osc request revoke 141568 --message="retracted because ..., sorry / thx / see better version ..."
-- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) Collaboration: http://en.opensuse.org/Build_Service/Collaboration
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19/11/12 11:32, Alexander Graf wrote:
On 16.11.2012, at 15:56, Ciaran Farrell wrote:
home:babelworx:branches:openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox -> openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox
https://build.opensuse.org/request/diff/141568
Description: Get CuBox working w/o manual uboot intervention
@@ -3,19 +3,39 @@ set -x
file=boot/boot.script +echo 'resetenv' >> $file +echo 'setenv kerneladdr 0x2000000' >> $file +echo 'setenv ramdiskaddr 0x3000000' >> $file +echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file +echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file +echo -n 'setenv bootargs "' >> $file +echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file +echo 'bootm 0x2000000 0x3000000' >> $file +echo 'boot' >> $file Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot.
Furthermore, this change only gets 12.2 working for you, but still fails on Factory. We should certainly find out why it doesn't work for you and get a generic solution up and rolling, so that Factory works too :). Sure, but I have absolutely no idea how to do that :-) The problem I was having with the original version of the bootscript was this: http://pastebin.com/hHxiZJ5C
It would boot as far as "Starting kernel ... Uncompressing Linux... done, booting the kernel." and then hang indefinitely. I blamed the errors: Loading file "/boot.scr" from mmc device 0:1 (mmcda1) 641 bytes read ## Executing script at 02000000 ## Error: "kerneladdr" not defined ## Error: "ramdiskaddr" not defined And tried to rectify this by hardcoding the kerneladdr and ramdiskaddr in boot.scr. For whatever reason (maybe just luck), it booted and got me into yast2-firstboot. I think that I rebooted it since then (though I could be wrong) - I'll reboot ASAP to see what happends. mmeister has a CuBox on his desk - I'll head down and see if it works for him after a reboot... Ciaran
Alex
-echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file -echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file +#echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file +#echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file # CuBox Hack -echo 'if itest 1$arcNumber == 13905; then' >> $file -echo ' setenv kerneladdr 0x2000000' >> $file -echo ' setenv ramdiskaddr 0x3000000' >> $file -echo 'fi' >> $file -echo -n 'setenv bootcmd "' >> $file -echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file -echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file -echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file -echo 'boot' >> $file +#echo 'if itest 1$arcNumber == 13905; then' >> $file +#echo ' setenv kerneladdr 0x2000000' >> $file +#echo ' setenv ramdiskaddr 0x3000000' >> $file +#echo 'fi' >> $file +#echo -n 'setenv bootcmd "' >> $file +#echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file +#echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file +#echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file +#echo 'boot' >> $file + + +#echo '======== Setting bootargs ========' >> $file +#echo -n 'setenv bootargs "' >> $file +#echo -n 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 ' >> $file +#echo 'rootdelay=2 --no-log --verbose"' >> $file +#echo '======== Loading kernel ========' >> $file +#echo 'ext2load mmc 0:1 0x00200000 /boot/uImage' >> $file +#echo '======== Booting kernel ========' >> $file +#echo 'bootm' >> $file +
#========================================== # Create machine readable uboot format
To REVIEW against the previous version: osc request show --diff 141568
To ACCEPT the request: osc request accept 141568 --message="reviewed ok."
To DECLINE the request: osc request decline 141568 --message="declined for reason xyz (see ... for background / policy / ...)."
To REVOKE the request: osc request revoke 141568 --message="retracted because ..., sorry / thx / see better version ..."
-- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) Collaboration: http://en.opensuse.org/Build_Service/Collaboration
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19.11.2012, at 11:45, Ciaran Farrell wrote:
On 19/11/12 11:32, Alexander Graf wrote:
On 16.11.2012, at 15:56, Ciaran Farrell wrote:
home:babelworx:branches:openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox -> openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox
https://build.opensuse.org/request/diff/141568
Description: Get CuBox working w/o manual uboot intervention
@@ -3,19 +3,39 @@ set -x
file=boot/boot.script +echo 'resetenv' >> $file +echo 'setenv kerneladdr 0x2000000' >> $file +echo 'setenv ramdiskaddr 0x3000000' >> $file +echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file +echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file +echo -n 'setenv bootargs "' >> $file +echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file +echo 'bootm 0x2000000 0x3000000' >> $file +echo 'boot' >> $file Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot.
Furthermore, this change only gets 12.2 working for you, but still fails on Factory. We should certainly find out why it doesn't work for you and get a generic solution up and rolling, so that Factory works too :). Sure, but I have absolutely no idea how to do that :-) The problem I was having with the original version of the bootscript was this: http://pastebin.com/hHxiZJ5C
It would boot as far as "Starting kernel ... Uncompressing Linux... done, booting the kernel." and then hang indefinitely. I blamed the errors: Loading file "/boot.scr" from mmc device 0:1 (mmcda1) 641 bytes read ## Executing script at 02000000 ## Error: "kerneladdr" not defined ## Error: "ramdiskaddr" not defined
These are actually ok messages. The script checks for existence of these variables and defines them differently if they don't exist. The CuBox specific bit is where it checks for the $arcNumber and overrides that whole logic. The only major difference I can see in your patch is that instead of running into that code path, you just replace all variable use with the same addresses the variables would expand to if you get into the $arcnumber==3905 case. Could you please check what the value of $arcNumber is for you? Alex
And tried to rectify this by hardcoding the kerneladdr and ramdiskaddr in boot.scr.
For whatever reason (maybe just luck), it booted and got me into yast2-firstboot. I think that I rebooted it since then (though I could be wrong) - I'll reboot ASAP to see what happends. mmeister has a CuBox on his desk - I'll head down and see if it works for him after a reboot...
Ciaran
Alex
-echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file -echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file +#echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file +#echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file # CuBox Hack -echo 'if itest 1$arcNumber == 13905; then' >> $file -echo ' setenv kerneladdr 0x2000000' >> $file -echo ' setenv ramdiskaddr 0x3000000' >> $file -echo 'fi' >> $file -echo -n 'setenv bootcmd "' >> $file -echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file -echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file -echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file -echo 'boot' >> $file +#echo 'if itest 1$arcNumber == 13905; then' >> $file +#echo ' setenv kerneladdr 0x2000000' >> $file +#echo ' setenv ramdiskaddr 0x3000000' >> $file +#echo 'fi' >> $file +#echo -n 'setenv bootcmd "' >> $file +#echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file +#echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file +#echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file +#echo 'boot' >> $file + + +#echo '======== Setting bootargs ========' >> $file +#echo -n 'setenv bootargs "' >> $file +#echo -n 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 ' >> $file +#echo 'rootdelay=2 --no-log --verbose"' >> $file +#echo '======== Loading kernel ========' >> $file +#echo 'ext2load mmc 0:1 0x00200000 /boot/uImage' >> $file +#echo '======== Booting kernel ========' >> $file +#echo 'bootm' >> $file +
#========================================== # Create machine readable uboot format
To REVIEW against the previous version: osc request show --diff 141568
To ACCEPT the request: osc request accept 141568 --message="reviewed ok."
To DECLINE the request: osc request decline 141568 --message="declined for reason xyz (see ... for background / policy / ...)."
To REVOKE the request: osc request revoke 141568 --message="retracted because ..., sorry / thx / see better version ..."
-- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) Collaboration: http://en.opensuse.org/Build_Service/Collaboration
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19/11/12 12:13, Alexander Graf wrote:
On 19.11.2012, at 11:45, Ciaran Farrell wrote:
On 19/11/12 11:32, Alexander Graf wrote:
On 16.11.2012, at 15:56, Ciaran Farrell wrote:
home:babelworx:branches:openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox -> openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox
https://build.opensuse.org/request/diff/141568
Description: Get CuBox working w/o manual uboot intervention @@ -3,19 +3,39 @@ set -x
file=boot/boot.script +echo 'resetenv' >> $file +echo 'setenv kerneladdr 0x2000000' >> $file +echo 'setenv ramdiskaddr 0x3000000' >> $file +echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file +echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file +echo -n 'setenv bootargs "' >> $file +echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file +echo 'bootm 0x2000000 0x3000000' >> $file +echo 'boot' >> $file Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot.
Furthermore, this change only gets 12.2 working for you, but still fails on Factory. We should certainly find out why it doesn't work for you and get a generic solution up and rolling, so that Factory works too :). Sure, but I have absolutely no idea how to do that :-) The problem I was having with the original version of the bootscript was this: http://pastebin.com/hHxiZJ5C
It would boot as far as "Starting kernel ... Uncompressing Linux... done, booting the kernel." and then hang indefinitely. I blamed the errors: Loading file "/boot.scr" from mmc device 0:1 (mmcda1) 641 bytes read ## Executing script at 02000000 ## Error: "kerneladdr" not defined ## Error: "ramdiskaddr" not defined These are actually ok messages. The script checks for existence of these variables and defines them differently if they don't exist. The CuBox specific bit is where it checks for the $arcNumber and overrides that whole logic.
The only major difference I can see in your patch is that instead of running into that code path, you just replace all variable use with the same addresses the variables would expand to if you get into the $arcnumber==3905 case. You mean $arcnumber==13905, right? The test was:
'if itest 1$arcNumber == 13905; then' I'm just double checking that it wasn't due to a typo.. Ciaran
Could you please check what the value of $arcNumber is for you?
Alex
And tried to rectify this by hardcoding the kerneladdr and ramdiskaddr in boot.scr.
For whatever reason (maybe just luck), it booted and got me into yast2-firstboot. I think that I rebooted it since then (though I could be wrong) - I'll reboot ASAP to see what happends. mmeister has a CuBox on his desk - I'll head down and see if it works for him after a reboot...
Ciaran
Alex
-echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file -echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file +#echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file +#echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file # CuBox Hack -echo 'if itest 1$arcNumber == 13905; then' >> $file -echo ' setenv kerneladdr 0x2000000' >> $file -echo ' setenv ramdiskaddr 0x3000000' >> $file -echo 'fi' >> $file -echo -n 'setenv bootcmd "' >> $file -echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file -echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file -echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file -echo 'boot' >> $file +#echo 'if itest 1$arcNumber == 13905; then' >> $file +#echo ' setenv kerneladdr 0x2000000' >> $file +#echo ' setenv ramdiskaddr 0x3000000' >> $file +#echo 'fi' >> $file +#echo -n 'setenv bootcmd "' >> $file +#echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file +#echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file +#echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file +#echo 'boot' >> $file + + +#echo '======== Setting bootargs ========' >> $file +#echo -n 'setenv bootargs "' >> $file +#echo -n 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 ' >> $file +#echo 'rootdelay=2 --no-log --verbose"' >> $file +#echo '======== Loading kernel ========' >> $file +#echo 'ext2load mmc 0:1 0x00200000 /boot/uImage' >> $file +#echo '======== Booting kernel ========' >> $file +#echo 'bootm' >> $file +
#========================================== # Create machine readable uboot format
To REVIEW against the previous version: osc request show --diff 141568
To ACCEPT the request: osc request accept 141568 --message="reviewed ok."
To DECLINE the request: osc request decline 141568 --message="declined for reason xyz (see ... for background / policy / ...)."
To REVOKE the request: osc request revoke 141568 --message="retracted because ..., sorry / thx / see better version ..."
-- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) Collaboration: http://en.opensuse.org/Build_Service/Collaboration
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19.11.2012, at 17:18, Ciaran Farrell wrote:
On 19/11/12 12:13, Alexander Graf wrote:
On 19.11.2012, at 11:45, Ciaran Farrell wrote:
On 19/11/12 11:32, Alexander Graf wrote:
On 16.11.2012, at 15:56, Ciaran Farrell wrote:
home:babelworx:branches:openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox -> openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox
https://build.opensuse.org/request/diff/141568
Description: Get CuBox working w/o manual uboot intervention @@ -3,19 +3,39 @@ set -x
file=boot/boot.script +echo 'resetenv' >> $file +echo 'setenv kerneladdr 0x2000000' >> $file +echo 'setenv ramdiskaddr 0x3000000' >> $file +echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file +echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file +echo -n 'setenv bootargs "' >> $file +echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file +echo 'bootm 0x2000000 0x3000000' >> $file +echo 'boot' >> $file Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot.
Furthermore, this change only gets 12.2 working for you, but still fails on Factory. We should certainly find out why it doesn't work for you and get a generic solution up and rolling, so that Factory works too :). Sure, but I have absolutely no idea how to do that :-) The problem I was having with the original version of the bootscript was this: http://pastebin.com/hHxiZJ5C
It would boot as far as "Starting kernel ... Uncompressing Linux... done, booting the kernel." and then hang indefinitely. I blamed the errors: Loading file "/boot.scr" from mmc device 0:1 (mmcda1) 641 bytes read ## Executing script at 02000000 ## Error: "kerneladdr" not defined ## Error: "ramdiskaddr" not defined These are actually ok messages. The script checks for existence of these variables and defines them differently if they don't exist. The CuBox specific bit is where it checks for the $arcNumber and overrides that whole logic.
The only major difference I can see in your patch is that instead of running into that code path, you just replace all variable use with the same addresses the variables would expand to if you get into the $arcnumber==3905 case. You mean $arcnumber==13905, right? The test was:
'if itest 1$arcNumber == 13905; then'
I'm just double checking that it wasn't due to a typo..
$arcNumber==3905 :). The 1 is there so that the check with $arcNumber==3905 would expand to: itest 13905 == 13905 and with $arcNumber== to: itest 1 == 13905 so that we always have a valid integer comparison. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19/11/12 17:20, Alexander Graf wrote:
On 19.11.2012, at 17:18, Ciaran Farrell wrote:
On 19/11/12 12:13, Alexander Graf wrote:
On 19.11.2012, at 11:45, Ciaran Farrell wrote:
On 19/11/12 11:32, Alexander Graf wrote:
On 16.11.2012, at 15:56, Ciaran Farrell wrote:
home:babelworx:branches:openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox -> openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox
https://build.opensuse.org/request/diff/141568
Description: Get CuBox working w/o manual uboot intervention @@ -3,19 +3,39 @@ set -x
file=boot/boot.script +echo 'resetenv' >> $file +echo 'setenv kerneladdr 0x2000000' >> $file +echo 'setenv ramdiskaddr 0x3000000' >> $file +echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file +echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file +echo -n 'setenv bootargs "' >> $file +echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file +echo 'bootm 0x2000000 0x3000000' >> $file +echo 'boot' >> $file Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot.
Furthermore, this change only gets 12.2 working for you, but still fails on Factory. We should certainly find out why it doesn't work for you and get a generic solution up and rolling, so that Factory works too :). Sure, but I have absolutely no idea how to do that :-) The problem I was having with the original version of the bootscript was this: http://pastebin.com/hHxiZJ5C
It would boot as far as "Starting kernel ... Uncompressing Linux... done, booting the kernel." and then hang indefinitely. I blamed the errors: Loading file "/boot.scr" from mmc device 0:1 (mmcda1) 641 bytes read ## Executing script at 02000000 ## Error: "kerneladdr" not defined ## Error: "ramdiskaddr" not defined These are actually ok messages. The script checks for existence of these variables and defines them differently if they don't exist. The CuBox specific bit is where it checks for the $arcNumber and overrides that whole logic.
The only major difference I can see in your patch is that instead of running into that code path, you just replace all variable use with the same addresses the variables would expand to if you get into the $arcnumber==3905 case. You mean $arcnumber==13905, right? The test was:
'if itest 1$arcNumber == 13905; then'
I'm just double checking that it wasn't due to a typo.. $arcNumber==3905 :).
The 1 is there so that the check with $arcNumber==3905 would expand to:
itest 13905 == 13905
and with $arcNumber== to:
itest 1 == 13905
so that we always have a valid integer comparison.
Alex
ok - thanks for the tip. I copied the output of printenv on the CuBox to http://pastebin.com/efgGS1Wf - arcNumber is plainly set to 3905. I added a resetenv to the boot.scr (well, to the uboot-setup script that generates that file) - I don't think it actually does anything useful though. I'm going to the original openSUSE image again (the one with the generic boot.scr setup code)... Ciaran -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19/11/12 17:20, Alexander Graf wrote:
Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot.
Hang on a second - why does this break after first reboot? I just rebooted now and it worked fine?
Ciaran -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/20/2012 11:36 AM, Ciaran Farrell wrote:
On 19/11/12 17:20, Alexander Graf wrote:
Mind to explain why exactly you need this? Is $arcNumber not set up correctly on your local NVRAM?
Also, this still breaks after your first reboot, because the boot script gets regenerated on first boot. Hang on a second - why does this break after first reboot? I just rebooted now and it worked fine?
Because on reboot, the boot.scr gets regenerated. Your changes didn't modify that code, so I'm slightly puzzled why it would still work after reboot. Maybe the initial initrd is too big? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19/11/12 17:20, Alexander Graf wrote:
>> >>> It would boot as far as "Starting kernel ... Uncompressing Linux...
>> >>> done, booting the kernel." and then hang indefinitely. I blamed the errors:
>> >>> Loading file "/boot.scr" from mmc device 0:1 (mmcda1)
>> >>> 641 bytes read
>> >>> ## Executing script at 02000000
>> >>> ## Error: "kerneladdr" not defined
>> >>> ## Error: "ramdiskaddr" not defined
> >> These are actually ok messages. The script checks for existence of these variables and defines them differently if they don't exist. The CuBox specific bit is where it checks for the $arcNumber and overrides that whole logic.
> >>
> >> The only major difference I can see in your patch is that instead of running into that code path, you just replace all variable use with the same addresses the variables would expand to if you get into the $arcnumber==3905 case.
I just checked this again with the original 12.2 image from opensuse.org
- arcNumber is 3905 (I checked with printenv before booting). The
situation is the same - it gets as far as "done, booting the kernel" and
then it hangs there. Just for kicks, I inserted the other SD card - the
one with my image on it - that boots fine. How can I debug this further?
Here is diff -Nurbs cubox-opensuse.txt cubox-ciaran.txt:
cfarrell@linux-bwve:/tmp> diff -Nurbs cubox-opensuse.txt cubox-ciaran.txt
--- cubox-opensuse.txt 2012-11-20 13:26:35.689283094 +0100
+++ cubox-ciaran.txt 2012-11-20 13:27:14.617798125 +0100
@@ -1,4 +1,4 @@
-CuBox>> printenv
+uBox>> printenv
baudrate=115200
loads_echo=0
ipaddr=192.168.15.223
@@ -37,7 +37,7 @@
standalone=fsload 0x2000000 ${image_name};setenv bootargs ${console}
${mtdparts} root=/dev/mtdblock0 rw
ip=${ipaddr}:${serverip}${bootargs_end} usb0Mode=${usb0Mode}
usb1Mode=${usb1Mode}
video=dovefb:lcd0:${lcd0_params},lcd1:${lcd1_params}
clcd.lcd0_enable=${lcd0_enable} clcd.lcd1_enable=${lcd1_enable}; bootm
0x2000000;
bootdelay=3
disaMvPnp=no
-ethaddr=00:50:43:3b:2b:19
+ethaddr=00:50:43:b4:06:1e
usb0Mode=host
usb1Mode=host
yuk_ethaddr=00:00:00:EE:51:81
--
Ciaran Farrell, Attorney at Law
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer "The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution." With ext4 support it isn't necessary to have a separate ext2 partition to boot from. You can boot from the /boot directory in the root partition. It also seems like the newer u-boot loads itself at 0x3600000. This causes problems if you try to load a ramdisk image at 0x3000000. I don't understand why you need a initrd image to boot from some media and not others, but you don't need one to boot from a mmc. It seems to me that life would be easier if everybody was using the new u-boot so everybody can boot the same. They could either install it themselves, using solid run's installer, or we could install it for them during our first boot. Here is the code the solid run installer uses, in u-boot. https://github.com/rabeeh/cubox-installer/blob/master/board/cubox/boot.scr.s... That would require we keep the ext2 boot partition, put a copy of the new u-boot code there, install it if necessary (followed by a reset), then boot opensuse from the ext4 partition. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 20/11/12 17:10, Bill Merriam wrote:
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer
"The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution."
With ext4 support it isn't necessary to have a separate ext2 partition to boot from. You can boot from the /boot directory in the root partition.
It also seems like the newer u-boot loads itself at 0x3600000. This causes problems if you try to load a ramdisk image at 0x3000000.
I don't understand why you need a initrd image to boot from some media and not others, but you don't need one to boot from a mmc.
It seems to me that life would be easier if everybody was using the new u-boot so everybody can boot the same. They could either install it themselves, using solid run's installer, or we could install it for them during our first boot. Here is the code the solid run installer uses, in u-boot. Do you have any suggestions about how I could try out this new uboot without needing to download one of the CuBox "official linux ports"? Could I just run the installer and try to stop it once uboot is flashed, or would that leave me with a horribly corrupted system?
Ciaran
That would require we keep the ext2 boot partition, put a copy of the new u-boot code there, install it if necessary (followed by a reset), then boot opensuse from the ext4 partition.
Bill
-- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, 21 Nov 2012 15:57:41 +0100
Ciaran Farrell
On 20/11/12 17:10, Bill Merriam wrote:
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer
"The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution."
Do you have any suggestions about how I could try out this new uboot without needing to download one of the CuBox "official linux ports"? Could I just run the installer and try to stop it once uboot is flashed, or would that leave me with a horribly corrupted system?
Ciaran
Ciaran, The uboot update is done by the uboot process, as driven by the boot.scr file. After it updates uboot it restarts and then launches a special linux system that gives you a menu and asks you if you want to install a linux distro. You can just quit at the point and you have the new uboot but get to keep opensuse. The "uboot installer" is an image you put on a USB stick. The cubox will boot from the usb stick instead of the mmc card. I hope I made that clear. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/20/2012 05:10 PM, Bill Merriam wrote:
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer
"The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution."
With ext4 support it isn't necessary to have a separate ext2 partition to boot from. You can boot from the /boot directory in the root partition.
The more generic we can be across platforms, the happier I am. Marcus decided we want to use /boot partition, so we have one :).
It also seems like the newer u-boot loads itself at 0x3600000. This causes problems if you try to load a ramdisk image at 0x3000000.
I don't understand why you need a initrd image to boot from some media and not others, but you don't need one to boot from a mmc.
We need the initrd for image resizing and other first boot magic.
It seems to me that life would be easier if everybody was using the new u-boot so everybody can boot the same. They could either install it themselves, using solid run's installer, or we could install it for them during our first boot. Here is the code the solid run installer uses, in u-boot. https://github.com/rabeeh/cubox-installer/blob/master/board/cubox/boot.scr.s...
That would require we keep the ext2 boot partition, put a copy of the new u-boot code there, install it if necessary (followed by a reset), then boot opensuse from the ext4 partition.
I'd prefer to just fix the issue at hand rather that mess with non-reversible system updates when all you want is boot openSUSE :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, 21 Nov 2012 16:01:15 +0100
Alexander Graf
On 11/20/2012 05:10 PM, Bill Merriam wrote:
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer
"The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution."
With ext4 support it isn't necessary to have a separate ext2 partition to boot from. You can boot from the /boot directory in the root partition.
The more generic we can be across platforms, the happier I am. Marcus decided we want to use /boot partition, so we have one :).
It also seems like the newer u-boot loads itself at 0x3600000. This causes problems if you try to load a ramdisk image at 0x3000000.
I don't understand why you need a initrd image to boot from some media and not others, but you don't need one to boot from a mmc.
We need the initrd for image resizing and other first boot magic.
It seems to me that life would be easier if everybody was using the new u-boot so everybody can boot the same. They could either install it themselves, using solid run's installer, or we could install it for them during our first boot. Here is the code the solid run installer uses, in u-boot. https://github.com/rabeeh/cubox-installer/blob/master/board/cubox/boot.scr.s...
That would require we keep the ext2 boot partition, put a copy of the new u-boot code there, install it if necessary (followed by a reset), then boot opensuse from the ext4 partition.
I'd prefer to just fix the issue at hand rather that mess with non-reversible system updates when all you want is boot openSUSE :)
Alex
Okay, consistency across hardware platforms makes sense. I will try to figure out what addresses to use for the kernel and initrd that work with the newer uboot. Then either those addresses will work with the older uboot or we will need to test the uboot version in boot.scr and act accordingly. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 20/11/12 17:10, Bill Merriam wrote:
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer
"The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution."
With ext4 support it isn't necessary to have a separate ext2 partition to boot from. You can boot from the /boot directory in the root partition.
It also seems like the newer u-boot loads itself at 0x3600000. This causes problems if you try to load a ramdisk image at 0x3000000. You mean this commit: https://github.com/rabeeh/u-boot/commit/ca0c0b763601606e8f85c61774060ef92770...
If we change ramdiskaddr to 0x500 (to accomodate this) will that also (fatally) affect older versions of uboot? Ciaran -- Ciaran Farrell, Attorney at Law SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11/28/2012 12:03 PM, Ciaran Farrell wrote:
On 20/11/12 17:10, Bill Merriam wrote:
I want to join the discussion about booting the cubox. Solid Run has an updated version on u-boot available to install. http://www.solid-run.com/mw/index.php/CuBox_Installer
"The CuBox Installer contains a newer version of U-Boot. This version adds support for EXT4 file systems, fast ethernet, and the bootcmd command. Follow the instructions for CuBox Installer. If an older version of U-Boot is detected, the installer will upgrade this first. After that, it is possible to quit to installer without installing a distribution."
With ext4 support it isn't necessary to have a separate ext2 partition to boot from. You can boot from the /boot directory in the root partition.
It also seems like the newer u-boot loads itself at 0x3600000. This causes problems if you try to load a ramdisk image at 0x3000000. You mean this commit: https://github.com/rabeeh/u-boot/commit/ca0c0b763601606e8f85c61774060ef92770...
If we change ramdiskaddr to 0x500 (to accomodate this) will that also (fatally) affect older versions of uboot?
I don't see why it would :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Bill Merriam -
Ciaran Farrell