[U-Boot] avr32 atmel ngw100 support question
Hi U-Boot Hackers,
I have some problem regarding DHCP on my Atmel NGW100 board, when using dnsmasq on the server side. I want to use the device for some kind of automatic test suite runs.
Does the support for this device is known to work in 2015.01? Can I update the old existing U-Boot boot loader directly or should I use FlashUpgrade tool from Atmel? (http://mirror.egtvedt.no/avr32linux.org/twiki/bin/view/Main/FlashUpgradeUsag...)
The existing version is: U-Boot 1.1.4-at0 (Jan 3 2007 - 10:30:09)
Any help would be really appreciated.
best regards Waldemar, who still wants to post the patches about fw_printenv...
Hi Waldemar,
On 13.01.15 22:31, Waldemar Brodkorb wrote:
Hi U-Boot Hackers,
I have some problem regarding DHCP on my Atmel NGW100 board, when using dnsmasq on the server side. I want to use the device for some kind of automatic test suite runs.
Does the support for this device is known to work in 2015.01?
I have not tested and do not own a ngw100 but it is likely that it is still working. Avr32 in general has had very little changes in the past. I personally have access to a ngw100mkII, grasshopper and stk1002 board. They are tested from time to time. AFAIR there was no breakage in the last two or three years. I have to admit not all of these boards tested with 2015.01 yet. But I do not expect any surprise here.
Can I update the old existing U-Boot boot loader directly or should I use FlashUpgrade tool from Atmel? (http://mirror.egtvedt.no/avr32linux.org/twiki/bin/view/Main/FlashUpgradeUsag...)
I always do it directly or with my jtag ICE. It seems the FlashUpgrade is just some scripting to advise u-boot to do the update. I would prefer to do it for my own.
The existing version is: U-Boot 1.1.4-at0 (Jan 3 2007 - 10:30:09)
This is quite old. There where maybe a change of flash partitioning in between. This means that your existing environment partition may not be read in the newer version. I recommend to save the environment as a text file on your host before doing the update.
best regards
Andreas Bießmann
Hi Andreas, Andreas Bießmann wrote,
Hi Waldemar,
On 13.01.15 22:31, Waldemar Brodkorb wrote:
Hi U-Boot Hackers,
I have some problem regarding DHCP on my Atmel NGW100 board, when using dnsmasq on the server side. I want to use the device for some kind of automatic test suite runs.
Does the support for this device is known to work in 2015.01?
I have not tested and do not own a ngw100 but it is likely that it is still working. Avr32 in general has had very little changes in the past. I personally have access to a ngw100mkII, grasshopper and stk1002 board. They are tested from time to time. AFAIR there was no breakage in the last two or three years. I have to admit not all of these boards tested with 2015.01 yet. But I do not expect any surprise here.
Can I update the old existing U-Boot boot loader directly or should I use FlashUpgrade tool from Atmel? (http://mirror.egtvedt.no/avr32linux.org/twiki/bin/view/Main/FlashUpgradeUsag...)
I always do it directly or with my jtag ICE. It seems the FlashUpgrade is just some scripting to advise u-boot to do the update. I would prefer to do it for my own.
Thanks for the advice. So I put my u-boot.bin file on tftp and do following: tftp 0x10400000 u-boot.bin protect off 0x0 0x1ffff erase 0x0 0x1ffff cp.b 0x10000000 0x0 0x1975c protect on 0x0 0x1ffff reset
While 0x1975c is the size I get after loading the u-boot.bin file via tftp?
Uboot> setenv ipaddr 10.0.0.11 Uboot> tftp 0x010400000 u-boot.bin macb0: Starting autonegotiation... macb0: Autonegotiation timed out (status=0x7849) macb0: link down (status: 0x7849) macb1: Starting autonegotiation... macb1: Autonegotiation complete macb1: link up, 100Mbps full-duplex (lpa: 0x45e1) Using macb1 device TFTP from server 10.0.0.1; our IP address is 10.0.0.11 Filename 'u-boot.bin'. Load address: 0x10400000 Loading: T ############################ done Bytes transferred = 138784 (21e20 hex)
So 0x21e20 ?
The existing version is: U-Boot 1.1.4-at0 (Jan 3 2007 - 10:30:09)
This is quite old. There where maybe a change of flash partitioning in between. This means that your existing environment partition may not be read in the newer version. I recommend to save the environment as a text file on your host before doing the update.
Okay, I made a copy of the information.
Thanks a lot for your time, Waldemar
Hi Waldemar,
On 13.01.15 23:59, Waldemar Brodkorb wrote:
Hi Andreas, Andreas Bießmann wrote,
Hi Waldemar,
On 13.01.15 22:31, Waldemar Brodkorb wrote:
Hi U-Boot Hackers,
I have some problem regarding DHCP on my Atmel NGW100 board, when using dnsmasq on the server side. I want to use the device for some kind of automatic test suite runs.
Does the support for this device is known to work in 2015.01?
I have not tested and do not own a ngw100 but it is likely that it is still working. Avr32 in general has had very little changes in the past. I personally have access to a ngw100mkII, grasshopper and stk1002 board. They are tested from time to time. AFAIR there was no breakage in the last two or three years. I have to admit not all of these boards tested with 2015.01 yet. But I do not expect any surprise here.
Can I update the old existing U-Boot boot loader directly or should I use FlashUpgrade tool from Atmel? (http://mirror.egtvedt.no/avr32linux.org/twiki/bin/view/Main/FlashUpgradeUsag...)
I always do it directly or with my jtag ICE. It seems the FlashUpgrade is just some scripting to advise u-boot to do the update. I would prefer to do it for my own.
Thanks for the advice. So I put my u-boot.bin file on tftp and do following: tftp 0x10400000 u-boot.bin protect off 0x0 0x1ffff erase 0x0 0x1ffff cp.b 0x10000000 0x0 0x1975c
ouch, copy from should be 0x10400000
protect on 0x0 0x1ffff reset
While 0x1975c is the size I get after loading the u-boot.bin file via tftp?
looks good. You could use some variables here:
tftp 0x10400000 u-boot.bin protect off 0x0 +${filesize} erase 0x0 +${filesize} cp.b ${fileaddr} 0x0 ${fielsize} protect on 0x0 +${filesize} reset
fileaddr/filesize env will be set after successful transfer, please check with your running version if they are set correctly first.
Uboot> setenv ipaddr 10.0.0.11 Uboot> tftp 0x010400000 u-boot.bin macb0: Starting autonegotiation... macb0: Autonegotiation timed out (status=0x7849) macb0: link down (status: 0x7849) macb1: Starting autonegotiation... macb1: Autonegotiation complete macb1: link up, 100Mbps full-duplex (lpa: 0x45e1) Using macb1 device TFTP from server 10.0.0.1; our IP address is 10.0.0.11 Filename 'u-boot.bin'. Load address: 0x10400000 Loading: T ############################ done Bytes transferred = 138784 (21e20 hex)
So 0x21e20 ?
0x21e20 is the transferred file size, env filesize should be set accordingly.
Best regards
Andreas Bießmann
Hi Andreas, Andreas Bießmann wrote,
Hi Waldemar,
On 13.01.15 23:59, Waldemar Brodkorb wrote:
Hi Andreas, Andreas Bießmann wrote,
Hi Waldemar,
On 13.01.15 22:31, Waldemar Brodkorb wrote:
Hi U-Boot Hackers,
I have some problem regarding DHCP on my Atmel NGW100 board, when using dnsmasq on the server side. I want to use the device for some kind of automatic test suite runs.
Does the support for this device is known to work in 2015.01?
I have not tested and do not own a ngw100 but it is likely that it is still working. Avr32 in general has had very little changes in the past. I personally have access to a ngw100mkII, grasshopper and stk1002 board. They are tested from time to time. AFAIR there was no breakage in the last two or three years. I have to admit not all of these boards tested with 2015.01 yet. But I do not expect any surprise here.
Can I update the old existing U-Boot boot loader directly or should I use FlashUpgrade tool from Atmel? (http://mirror.egtvedt.no/avr32linux.org/twiki/bin/view/Main/FlashUpgradeUsag...)
I always do it directly or with my jtag ICE. It seems the FlashUpgrade is just some scripting to advise u-boot to do the update. I would prefer to do it for my own.
Thanks for the advice. So I put my u-boot.bin file on tftp and do following: tftp 0x10400000 u-boot.bin protect off 0x0 0x1ffff erase 0x0 0x1ffff cp.b 0x10000000 0x0 0x1975c
ouch, copy from should be 0x10400000
Ah, you are right. Copy and paste from some info from the net. I used 0x10400000 to load the linux kernel.
protect on 0x0 0x1ffff reset
While 0x1975c is the size I get after loading the u-boot.bin file via tftp?
looks good. You could use some variables here:
tftp 0x10400000 u-boot.bin protect off 0x0 +${filesize} erase 0x0 +${filesize} cp.b ${fileaddr} 0x0 ${fielsize} protect on 0x0 +${filesize} reset
fileaddr/filesize env will be set after successful transfer, please check with your running version if they are set correctly first.
Yes, fileaddr and filesize seemed to be set correctly. Uboot> printenv baudrate=115200 ethaddr=00:04:25:1C:5A:AC eth1addr=00:04:25:1C:5A:AD bootcmd=fsload;bootm bootdelay=3 bootargs=console=ttyS0 root=/dev/nfs ip=dhcp bootfile=iod stdin=serial stdout=serial stderr=serial ethact=macb1 filesize=21e20 fileaddr=10400000 gatewayip=10.0.0.1 netmask=255.255.255.0 ipaddr=10.0.0.11 serverip=10.0.0.1
Environment size: 323/65532 bytes Uboot> protect off 0x0 +${filesize} Un-Protected 10 sectors Uboot> erase 0x0 +${filesize} Erasing sector 0...Erasing sector 1...Erasing sector 2...Erasing sector 3...Erasing sector 4...Erasing sector 5...Erasing sector 6...Erasing sector 7...Erasing sector 8...Erasing sector 9...
But unfortunately the device is dead after the erase command.
Where do you live with your JTAG programmer? ;) Is a AVR dragon device usable to reprogram the NGW100? Or what is my cheapest choice now?
best regards Waldemar
Hi Waldemar,
On 14.01.15 00:23, Waldemar Brodkorb wrote:
Hi Andreas, Andreas Bießmann wrote,
Yes, fileaddr and filesize seemed to be set correctly. Uboot> printenv baudrate=115200 ethaddr=00:04:25:1C:5A:AC eth1addr=00:04:25:1C:5A:AD bootcmd=fsload;bootm bootdelay=3 bootargs=console=ttyS0 root=/dev/nfs ip=dhcp bootfile=iod stdin=serial stdout=serial stderr=serial ethact=macb1 filesize=21e20 fileaddr=10400000 gatewayip=10.0.0.1 netmask=255.255.255.0 ipaddr=10.0.0.11 serverip=10.0.0.1
Environment size: 323/65532 bytes Uboot> protect off 0x0 +${filesize} Un-Protected 10 sectors Uboot> erase 0x0 +${filesize} Erasing sector 0...Erasing sector 1...Erasing sector 2...Erasing sector 3...Erasing sector 4...Erasing sector 5...Erasing sector 6...Erasing sector 7...Erasing sector 8...Erasing sector 9...
But unfortunately the device is dead after the erase command.
Damn, this damn old code run completely from NOR. Current u-boot versions relocate itself to ram after the very first bootstrap. Sorry, I did not know that these old versions do not relocate itself.
Where do you live with your JTAG programmer? ;)
In Germany near Nuremberg.
Is a AVR dragon device usable to reprogram the NGW100?
I think the dragon should work too. I dunno which software to use then but basically the dragon supports avr32.
Or what is my cheapest choice now?
You could send me the board. I feel sad breaking your board :( So I'd pay the postage back (france, right?).
Best regards
Andreas Bießmann
Hi Andreas, Andreas Bießmann wrote,
But unfortunately the device is dead after the erase command.
Damn, this damn old code run completely from NOR. Current u-boot versions relocate itself to ram after the very first bootstrap. Sorry, I did not know that these old versions do not relocate itself.
So after some unsuccessful tries with AVR Dragon, I got my hands on a AVR STK600 from my working place. With this I got it working. As a reference, I used AVR32 Studio 2.7 beta (Eclipse based) under Windows and updated the firmware of STK600. Then I connected the NGW100 via JTAG to the STK600. Under Linux I used following, I couldn't choose NGW100 in the AVR32 Studio under Windows: sudo ./avr32program -x avr32 -p stk600 erase -fcfi@0 Connected to STK600 (rev D). Firmware version 0x020b. Unlocking flash: ================================================== 100.0% Erasing flash: done sudo avr32program -x avr32 -p stk600 program -F bin -vfcfi@0 u-boot.bin Connected to STK600 (rev D). Firmware version 0x020b. Unlocking flash: ================================================== 100.0% Programming 138784 bytes in 1 segment. Verifying flash: ================================================== 100.0%
And indeed my NGW100 boots up fine again: U-Boot 2015.01 (Jan 14 2015 - 13:29:06)
U-Boot code: 00000000 -> 0001727c data: 0001f668 -> 00055a78 VMR table @ 0x11fc9688 DMA: Using memory from 0x11f66000 to 0x11f6a000 Flash: 8 MiB at address 0x00000000 DRAM Configuration: Bank #0: 10000000 32 MiB In: serial Out: serial Err: serial Net: macb0, macb1 mci: 0 Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Press SPACE to abort autoboot in 1 seconds
Do I need to take any action so that board support is not removed?
Thanks Andreas for some hints about avr32program via private mail.
best regards Waldemar
Hi Waldemar,
On 19.01.15 21:24, Waldemar Brodkorb wrote:
Hi Andreas, Andreas Bießmann wrote,
But unfortunately the device is dead after the erase command.
Damn, this damn old code run completely from NOR. Current u-boot versions relocate itself to ram after the very first bootstrap. Sorry, I did not know that these old versions do not relocate itself.
So after some unsuccessful tries with AVR Dragon, I got my hands on a AVR STK600 from my working place. With this I got it working.
I'm glad you got it working again.
As a reference, I used AVR32 Studio 2.7 beta (Eclipse based) under Windows and updated the firmware of STK600. Then I connected the NGW100 via JTAG to the STK600. Under Linux I used following, I couldn't choose NGW100 in the AVR32 Studio under Windows: sudo ./avr32program -x avr32 -p stk600 erase -fcfi@0 Connected to STK600 (rev D). Firmware version 0x020b. Unlocking flash: ================================================== 100.0% Erasing flash: done sudo avr32program -x avr32 -p stk600 program -F bin -vfcfi@0 u-boot.bin Connected to STK600 (rev D). Firmware version 0x020b. Unlocking flash: ================================================== 100.0% Programming 138784 bytes in 1 segment. Verifying flash: ================================================== 100.0%
And indeed my NGW100 boots up fine again: U-Boot 2015.01 (Jan 14 2015 - 13:29:06)
U-Boot code: 00000000 -> 0001727c data: 0001f668 -> 00055a78 VMR table @ 0x11fc9688 DMA: Using memory from 0x11f66000 to 0x11f6a000 Flash: 8 MiB at address 0x00000000 DRAM Configuration: Bank #0: 10000000 32 MiB In: serial Out: serial Err: serial Net: macb0, macb1 mci: 0 Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Press SPACE to abort autoboot in 1 seconds
Do I need to take any action so that board support is not removed?
You have to test the ngw100 once I've got the generic board support patches for avr32 ready, hopefully next week. I'll cc you then!
Best regards,
Andreas
participants (2)
-
Andreas Bießmann -
Waldemar Brodkorb