Can't boot newer kernel on Armada 370 dev board
Hello,
I have an Armada 370 dev board (DB-88F6710-BP) running Marvell kernel 3.2.
Now I'm a bit puzzled because I'd like to use newer kernel (i.e 3.12) on my board, so I tried several repositories (vanilla and linux-mvebu) with no success! :'(
I read on the net that it should work, but after using the bootz command everything hangs:
Marvell>> tftp $loadaddr zImage-cyone
Using egiga0 device
TFTP from server 192.168.32.38; our IP address is 192.168.32.25 Filename 'zImage-cyone'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
######## done
Bytes transferred = 2701021 (2936dd hex)
Marvell>> bootz $loadaddr
Starting kernel ...
File zImage-cyone is made with command:
giometti at hulk:~/Projects/linux-mvebu[mvebu-dt-3.14]$ cat arch/arm/boot/zImage arch/arm/boot/dts/armada-370-db.dtb > /srv/tftp/zImage-cyone
Someone have some advise for me! :)
Thanks in advance,
Rodolfo
Signature · 5 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
Quoted 32 lines · Rodolfo Giometti
Hello,
I have an Armada 370 dev board (DB-88F6710-BP) running Marvell kernel 3.2.
Now I'm a bit puzzled because I'd like to use newer kernel (i.e 3.12) on my board, so I tried several repositories (vanilla and linux-mvebu) with no success! :'(
I read on the net that it should work, but after using the bootz command everything hangs:
Marvell>> tftp $loadaddr zImage-cyone Using egiga0 device TFTP from server 192.168.32.38; our IP address is 192.168.32.25 Filename 'zImage-cyone'. Load address: 0x2000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######## done Bytes transferred = 2701021 (2936dd hex) Marvell>> bootz $loadaddr Starting kernel ...
Quoted 5 lines
File zImage-cyone is made with command:
giometti at hulk:~/Projects/linux-mvebu[mvebu-dt-3.14]$ cat
arch/arm/boot/zImagearch/arm/boot/dts/armada-370-db.dtb>/srv/tftp/zImage-cyoneSomeone have some advise for me! :)
Hi Redolfo
What version of u-boot do you have? There has been a change in u-boot so that the registers are mapped to a different address. Old u-boot with new kernel causes instant lockup on boot as soon as it tries to access the wrong address space.
Andrew
Quoted 4 lines · Andrew Lunn
Hi Redolfo
What version of u-boot do you have?
U-Boot 2011.12 (Dec 24 2013 - 16:16:38) Marvell version: v2011.12 2013_Q3.0
Quoted 4 lines
There has been a change in u-boot
so that the registers are mapped to a different address. Old u-boot with new kernel causes instant lockup on boot as soon as it tries to access the wrong address space.
I see. Where can I get newer u-boot releases in order to avoid this problem? :-)
Thanks in advance,
Rodolfo
Signature · 5 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
Quoted 13 lines · Rodolfo Giometti
Quoted 4 lines · Andrew Lunn
Hi Redolfo
What version of u-boot do you have?
U-Boot 2011.12 (Dec 24 2013 - 16:16:38) Marvell version: v2011.12 2013_Q3.0
Quoted 4 lines
There has been a change in u-boot
so that the registers are mapped to a different address. Old u-boot with new kernel causes instant lockup on boot as soon as it tries to access the wrong address space.
Quoted 4 lines
I see. Where can I get newer u-boot releases in order to avoid this problem? :-)
From Marvell.
It is also possible to modify the DT to use the old address. I think there is a thread somewhere with Thomas Petazzoni telling somebody what changes need to be made for Armada XP. 370 should be very similar.
Basically you need to change 0xF1000000 to 0xD0000000.
Andrew
Andrew, Rodolfo,
Quoted 10 lines · Andrew Lunn
Quoted 9 lines
U-Boot 2011.12 (Dec 24 2013 - 16:16:38) Marvell version: v2011.12 2013_Q3.0
Quoted 4 lines
There has been a change in u-boot
so that the registers are mapped to a different address. Old u-boot with new kernel causes instant lockup on boot as soon as it tries to access the wrong address space.I see. Where can I get newer u-boot releases in order to avoid this problem? :-)
Quoted 8 lines
From Marvell.
It is also possible to modify the DT to use the old address. I think there is a thread somewhere with Thomas Petazzoni telling somebody what changes need to be made for Armada XP. 370 should be very similar.
Basically you need to change
0xF1000000to0xD0000000.
No, that's the opposite.
The mainline kernel uses 0xD0000000 for this board, because originally the Marvell Armada 370 DB was shipped with an old U-Boot, which was mapping registers at 0xD0000000.
Apparently, they are now shipping these boards with a more recent version of U-Boot that uses 0xF1000000. Therefore, Rodolfo should change the kernel from 0xD0000000 to 0xF1000000.
The change to be applied is:
arch/arm/boot/dts/armada-370-db.dts +1 -1
@@ -30,7 +30,7 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000 MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>; internal-regs {
Also, if you have earlyprintk enabled, make sure you have CONFIG_DEBUG_MVEBU_UART_ALTERNATE enabled and CONFIG_DEBUG_MVEBU_UART disabled.
Let me know if that works for you.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Quoted 10 lines · Thomas Petazzoni
No, that's the opposite.
The mainline kernel uses
0xD0000000for this board, because originally the Marvell Armada 370 DB was shipped with an old U-Boot, which was mapping registers at0xD0000000.Apparently, they are now shipping these boards with a more recent version of U-Boot that uses
0xF1000000. Therefore, Rodolfo should change the kernel from0xD0000000to0xF1000000.
Yes, looking at u-boot code I found that my u-boot uses 0xF1000000 addresses.
Quoted 7 lines
The change to be applied is:
arch/arm/boot/dts/armada-370-db.dts +0
-0
arch/arm/boot/dts/armada-370-db.dts line 36
Quoted 8 lines
arch/arm/boot/dts/armada-370-db.dts +1
-1@@ -30,7 +30,7 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000 + ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000 MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>; internal-regs {
Done.
Quoted 3 lines
Also, if you have earlyprintk enabled, make sure you have
CONFIG_DEBUG_MVEBU_UART_ALTERNATEenabled andCONFIG_DEBUG_MVEBU_UARTdisabled.
Done.
Quoted 1 line
Let me know if that works for you.
It works! :-)
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.13.0-rc6-dirty (giometti at hulk) (gcc version 4.7.3 (Ubuntu/Linaro
4.7.3-1ubuntu1) ) #20 SMP Tue Dec 31 11:32:33 CET 2013
CPU: ARMv7 Processor [561f5811] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache Machine model: Marvell Armada 370 Evaluation Board bootconsole [earlycon0] enabled
Memory policy: Data cache writeback
On node 0 totalpages: 262144
Thanks a lot!
Rodolfo
Signature · 5 lines
GNU/Linux Solutions e-mail: giometti at enneenne.com Linux Device Driver giometti at linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
Quoted 25 lines · Thomas Petazzoni
Andrew, Rodolfo,
Quoted 10 lines · Andrew Lunn
Quoted 9 lines
U-Boot 2011.12 (Dec 24 2013 - 16:16:38) Marvell version: v2011.12 2013_Q3.0
Quoted 4 lines
There has been a change in u-boot
so that the registers are mapped to a different address. Old u-boot with new kernel causes instant lockup on boot as soon as it tries to access the wrong address space.I see. Where can I get newer u-boot releases in order to avoid this problem? :-)
Quoted 8 lines
From Marvell.
It is also possible to modify the DT to use the old address. I think there is a thread somewhere with Thomas Petazzoni telling somebody what changes need to be made for Armada XP. 370 should be very similar.
Basically you need to change
0xF1000000to0xD0000000.No, that's the opposite.
Quoted 7 lines
The mainline kernel uses
0xD0000000for this board, because originally the Marvell Armada 370 DB was shipped with an old U-Boot, which was mapping registers at0xD0000000.Apparently, they are now shipping these boards with a more recent version of U-Boot that uses
0xF1000000. Therefore, Rodolfo should change the kernel from0xD0000000to0xF1000000.
Ah, O.K. Good to know.
I think we need to better document this. For example put a comment in the top of each .dts file about the issues and which u-boot version is known to work, and which version needs an alternative .dts file. Maybe also how you can tell from a running system, eg what to look for in /proc/iomem.
Andrew