* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
@ 2015-09-04 14:44 Stefan Eichenberger
2015-09-04 15:14 ` Stefan Roese
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Eichenberger @ 2015-09-04 14:44 UTC (permalink / raw)
To: u-boot
Hi Stefan,
I have a problem with u-boot compiled from master and the db-88f6820-gp
evaluation board from Marvell. The problem is the reconfiguration of the
base register address (SOC_REGS_PHY_BASE) under u-boot on A38x. Some
functions (e.g. mvebu_soc_family) try to access the new
SOC_REGS_PHY_BASE address before this address is reconfigured which
leads to an exception. U-Boot won't start in this case. I then set the
SOC_REGS_PHY_BASE to 0xd0000000 (same as under SPL) and u-boot starts
successfully. This was only to verify that this is the problem, with the
modification I can't start Linux because Linux expects that the
addresses are reconfigured.
I have to mention, I try to start from a SD Card. So I have changed the
boot configuration of the board with a pull down on DPR6.
This is the output of the SPL when I don't add the modification, u-boot
won't start:
U-Boot SPL 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:01:24)
High speed PHY - Version: 2.0
Initialize DB-GP board topology
Detected Device ID 6828
Lane 5 detection: USB3.0 Host Port 1
Lane 1 detection: SATA0
Lane 2 detection: SATA1
board SerDes lanes topology details:
| Lane # | Speed | Type |
--------------------------------
| 0 | 5 | PCIe0 |
| 1 | 3 | SATA0 |
| 2 | 3 | SATA1 |
| 3 | 3 | SATA3 |
| 4 | 3 | SATA2 |
| 5 | 5 | USB3 HOST1 |
--------------------------------
PCIe, Idx 0: detected no link
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
>>spl:board_init_r()
spl_init()
boot device - 1
spl: mmc boot mode: raw
read sector 1140, count=1
spl: payload image: U-Bo load addr: 0x7fffc0 size: 336772
read 292 sectors to 7fffc0
Jumping to U-Boot
loaded - jumping to U-Boot...image entry point: 0x800000
After I changed SOC_REGS_PHY_BASE u-boot starts correctly:
U-Boot 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:19:09 +0200)
SoC: MV88F6828-A0
I2C: ready
SPI: ready
DRAM: 2 GiB (ECC not enabled)
MMC: mv_sdh: 0
SF: Detected M25P128 with page size 256 Bytes, erase size 256 KiB, total
16 MiB
Board: Marvell DB-88F6820-GP
SCSI: MVEBU SATA INIT
SATA link 0 timeout.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
Net: neta0, neta1
Hit any key to stop autoboot: 0
So it seems that SOC_REGS_PHY_BASE should somehow be changeable during
runtime but I don't think this works with the current design. Do you
have an idea how this could be fixed?
Thanks and best regards,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-04 14:44 [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp Stefan Eichenberger
@ 2015-09-04 15:14 ` Stefan Roese
2015-09-04 16:15 ` Stefan Eichenberger
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Roese @ 2015-09-04 15:14 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 04.09.2015 16:44, Stefan Eichenberger wrote:
> I have a problem with u-boot compiled from master and the db-88f6820-gp
> evaluation board from Marvell. The problem is the reconfiguration of the
> base register address (SOC_REGS_PHY_BASE) under u-boot on A38x. Some
> functions (e.g. mvebu_soc_family) try to access the new
> SOC_REGS_PHY_BASE address before this address is reconfigured which
> leads to an exception. U-Boot won't start in this case. I then set the
> SOC_REGS_PHY_BASE to 0xd0000000 (same as under SPL) and u-boot starts
> successfully. This was only to verify that this is the problem, with the
> modification I can't start Linux because Linux expects that the
> addresses are reconfigured.
>
> I have to mention, I try to start from a SD Card. So I have changed the
> boot configuration of the board with a pull down on DPR6.
>
> This is the output of the SPL when I don't add the modification, u-boot
> won't start:
> U-Boot SPL 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:01:24)
> High speed PHY - Version: 2.0
>
> Initialize DB-GP board topology
> Detected Device ID 6828
> Lane 5 detection: USB3.0 Host Port 1
> Lane 1 detection: SATA0
> Lane 2 detection: SATA1
> board SerDes lanes topology details:
> | Lane # | Speed | Type |
> --------------------------------
> | 0 | 5 | PCIe0 |
> | 1 | 3 | SATA0 |
> | 2 | 3 | SATA1 |
> | 3 | 3 | SATA3 |
> | 4 | 3 | SATA2 |
> | 5 | 5 | USB3 HOST1 |
> --------------------------------
> PCIe, Idx 0: detected no link
> High speed PHY - Ended Successfully
> DDR3 Training Sequence - Ver TIP-1.29.0
> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> DDR3 Training Sequence - Ended Successfully
> >>spl:board_init_r()
> spl_init()
> boot device - 1
> spl: mmc boot mode: raw
> read sector 1140, count=1
> spl: payload image: U-Bo load addr: 0x7fffc0 size: 336772
> read 292 sectors to 7fffc0
> Jumping to U-Boot
> loaded - jumping to U-Boot...image entry point: 0x800000
>
> After I changed SOC_REGS_PHY_BASE u-boot starts correctly:
> U-Boot 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:19:09 +0200)
>
> SoC: MV88F6828-A0
> I2C: ready
> SPI: ready
> DRAM: 2 GiB (ECC not enabled)
> MMC: mv_sdh: 0
> SF: Detected M25P128 with page size 256 Bytes, erase size 256 KiB, total
> 16 MiB
> Board: Marvell DB-88F6820-GP
> SCSI: MVEBU SATA INIT
> SATA link 0 timeout.
> SATA link 1 timeout.
> AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
> flags: 64bit ncq led only pmp fbss pio slum part sxs
> Net: neta0, neta1
> Hit any key to stop autoboot: 0
>
> So it seems that SOC_REGS_PHY_BASE should somehow be changeable during
> runtime but I don't think this works with the current design. Do you
> have an idea how this could be fixed?
Yes, there are some problems with the current mainline version. Good
news though is, that I've already fixed this and posted some patches for
this. And more, e.g. support for DM / dts. I've just uploaded a git
branch for you to test "mvebu-dm-v2-2015-09-04":
https://gitlab.denx.de/sr/u-boot-a38x/commits/mvebu-dm-v2-2015-09-04
This branch should work just fine. Please give it a try and let me know
if this works or not.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-04 15:14 ` Stefan Roese
@ 2015-09-04 16:15 ` Stefan Eichenberger
2015-09-04 16:44 ` Stefan Roese
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Eichenberger @ 2015-09-04 16:15 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 09/04/2015 05:14 PM, Stefan Roese wrote:
> Hi Stefan,
>
> On 04.09.2015 16:44, Stefan Eichenberger wrote:
>> I have a problem with u-boot compiled from master and the db-88f6820-gp
>> evaluation board from Marvell. The problem is the reconfiguration of the
>> base register address (SOC_REGS_PHY_BASE) under u-boot on A38x. Some
>> functions (e.g. mvebu_soc_family) try to access the new
>> SOC_REGS_PHY_BASE address before this address is reconfigured which
>> leads to an exception. U-Boot won't start in this case. I then set the
>> SOC_REGS_PHY_BASE to 0xd0000000 (same as under SPL) and u-boot starts
>> successfully. This was only to verify that this is the problem, with the
>> modification I can't start Linux because Linux expects that the
>> addresses are reconfigured.
>>
>> I have to mention, I try to start from a SD Card. So I have changed the
>> boot configuration of the board with a pull down on DPR6.
>>
>> This is the output of the SPL when I don't add the modification, u-boot
>> won't start:
>> U-Boot SPL 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:01:24)
>> High speed PHY - Version: 2.0
>>
>> Initialize DB-GP board topology
>> Detected Device ID 6828
>> Lane 5 detection: USB3.0 Host Port 1
>> Lane 1 detection: SATA0
>> Lane 2 detection: SATA1
>> board SerDes lanes topology details:
>> | Lane # | Speed | Type |
>> --------------------------------
>> | 0 | 5 | PCIe0 |
>> | 1 | 3 | SATA0 |
>> | 2 | 3 | SATA1 |
>> | 3 | 3 | SATA3 |
>> | 4 | 3 | SATA2 |
>> | 5 | 5 | USB3 HOST1 |
>> --------------------------------
>> PCIe, Idx 0: detected no link
>> High speed PHY - Ended Successfully
>> DDR3 Training Sequence - Ver TIP-1.29.0
>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
>> DDR3 Training Sequence - Ended Successfully
>> >>spl:board_init_r()
>> spl_init()
>> boot device - 1
>> spl: mmc boot mode: raw
>> read sector 1140, count=1
>> spl: payload image: U-Bo load addr: 0x7fffc0 size: 336772
>> read 292 sectors to 7fffc0
>> Jumping to U-Boot
>> loaded - jumping to U-Boot...image entry point: 0x800000
>>
>> After I changed SOC_REGS_PHY_BASE u-boot starts correctly:
>> U-Boot 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:19:09 +0200)
>>
>> SoC: MV88F6828-A0
>> I2C: ready
>> SPI: ready
>> DRAM: 2 GiB (ECC not enabled)
>> MMC: mv_sdh: 0
>> SF: Detected M25P128 with page size 256 Bytes, erase size 256 KiB, total
>> 16 MiB
>> Board: Marvell DB-88F6820-GP
>> SCSI: MVEBU SATA INIT
>> SATA link 0 timeout.
>> SATA link 1 timeout.
>> AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
>> flags: 64bit ncq led only pmp fbss pio slum part sxs
>> Net: neta0, neta1
>> Hit any key to stop autoboot: 0
>>
>> So it seems that SOC_REGS_PHY_BASE should somehow be changeable during
>> runtime but I don't think this works with the current design. Do you
>> have an idea how this could be fixed?
>
> Yes, there are some problems with the current mainline version. Good
> news though is, that I've already fixed this and posted some patches
> for this. And more, e.g. support for DM / dts. I've just uploaded a
> git branch for you to test "mvebu-dm-v2-2015-09-04":
>
> https://gitlab.denx.de/sr/u-boot-a38x/commits/mvebu-dm-v2-2015-09-04
>
> This branch should work just fine. Please give it a try and let me
> know if this works or not.
>
> Thanks,
> Stefan
>
Thanks for the fast response! I've tried this version an was able to run
u-boot as expected. Unfortunately u-boot now hangs if I try to load an
image from the SD-Card:
e.g. if I run the following command u-boot hangs:
ext4load mmc 0:2 0x2000000 /boot/kernel.bin
I don't see why exactly it crashes, it seems for me that it's always at
a different position.
Here are two backtraces, always at a different positions:
Here u-boot stopped automatically:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7ff65d84 in ?? ()
(gdb) backtrace
#0 0x7ff65d84 in ?? ()
#1 0x803663d0 in ?? ()
#2 0x803663d0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
And here I've got perhaps some more information?
Program received signal SIGSTOP, Stopped (signal).
v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
way_shift=<optimized out>, num_ways=<optimized out>,
num_sets=<optimized out>, level=<optimized out>) at
arch/arm/cpu/armv7/cache_v7.c:62
62 for (set = num_sets - 1; set >= 0; set--) {
(gdb) backtrace
#0 v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
way_shift=<optimized out>,
num_ways=<optimized out>, num_sets=<optimized out>,
level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
#1 v7_maint_dcache_level_setway (operation=<optimized out>, level=9) at
arch/arm/cpu/armv7/cache_v7.c:129
#2 v7_maint_dcache_all (operation=2146852864) at
arch/arm/cpu/armv7/cache_v7.c:147
#3 0xfffffbe2 in ?? ()
#4 0xfffffbe2 in ?? ()
Could it be that there is something wrong with cache/dram setup?
I hope I can do some more tests next week.
Best regards,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-04 16:15 ` Stefan Eichenberger
@ 2015-09-04 16:44 ` Stefan Roese
2015-09-11 13:50 ` Stefan Eichenberger
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Roese @ 2015-09-04 16:44 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 04.09.2015 18:15, Stefan Eichenberger wrote:
>> On 04.09.2015 16:44, Stefan Eichenberger wrote:
>>> I have a problem with u-boot compiled from master and the db-88f6820-gp
>>> evaluation board from Marvell. The problem is the reconfiguration of the
>>> base register address (SOC_REGS_PHY_BASE) under u-boot on A38x. Some
>>> functions (e.g. mvebu_soc_family) try to access the new
>>> SOC_REGS_PHY_BASE address before this address is reconfigured which
>>> leads to an exception. U-Boot won't start in this case. I then set the
>>> SOC_REGS_PHY_BASE to 0xd0000000 (same as under SPL) and u-boot starts
>>> successfully. This was only to verify that this is the problem, with the
>>> modification I can't start Linux because Linux expects that the
>>> addresses are reconfigured.
>>>
>>> I have to mention, I try to start from a SD Card. So I have changed the
>>> boot configuration of the board with a pull down on DPR6.
>>>
>>> This is the output of the SPL when I don't add the modification, u-boot
>>> won't start:
>>> U-Boot SPL 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:01:24)
>>> High speed PHY - Version: 2.0
>>>
>>> Initialize DB-GP board topology
>>> Detected Device ID 6828
>>> Lane 5 detection: USB3.0 Host Port 1
>>> Lane 1 detection: SATA0
>>> Lane 2 detection: SATA1
>>> board SerDes lanes topology details:
>>> | Lane # | Speed | Type |
>>> --------------------------------
>>> | 0 | 5 | PCIe0 |
>>> | 1 | 3 | SATA0 |
>>> | 2 | 3 | SATA1 |
>>> | 3 | 3 | SATA3 |
>>> | 4 | 3 | SATA2 |
>>> | 5 | 5 | USB3 HOST1 |
>>> --------------------------------
>>> PCIe, Idx 0: detected no link
>>> High speed PHY - Ended Successfully
>>> DDR3 Training Sequence - Ver TIP-1.29.0
>>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
>>> DDR3 Training Sequence - Ended Successfully
>>> >>spl:board_init_r()
>>> spl_init()
>>> boot device - 1
>>> spl: mmc boot mode: raw
>>> read sector 1140, count=1
>>> spl: payload image: U-Bo load addr: 0x7fffc0 size: 336772
>>> read 292 sectors to 7fffc0
>>> Jumping to U-Boot
>>> loaded - jumping to U-Boot...image entry point: 0x800000
>>>
>>> After I changed SOC_REGS_PHY_BASE u-boot starts correctly:
>>> U-Boot 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:19:09 +0200)
>>>
>>> SoC: MV88F6828-A0
>>> I2C: ready
>>> SPI: ready
>>> DRAM: 2 GiB (ECC not enabled)
>>> MMC: mv_sdh: 0
>>> SF: Detected M25P128 with page size 256 Bytes, erase size 256 KiB, total
>>> 16 MiB
>>> Board: Marvell DB-88F6820-GP
>>> SCSI: MVEBU SATA INIT
>>> SATA link 0 timeout.
>>> SATA link 1 timeout.
>>> AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
>>> flags: 64bit ncq led only pmp fbss pio slum part sxs
>>> Net: neta0, neta1
>>> Hit any key to stop autoboot: 0
>>>
>>> So it seems that SOC_REGS_PHY_BASE should somehow be changeable during
>>> runtime but I don't think this works with the current design. Do you
>>> have an idea how this could be fixed?
>>
>> Yes, there are some problems with the current mainline version. Good
>> news though is, that I've already fixed this and posted some patches
>> for this. And more, e.g. support for DM / dts. I've just uploaded a
>> git branch for you to test "mvebu-dm-v2-2015-09-04":
>>
>> https://gitlab.denx.de/sr/u-boot-a38x/commits/mvebu-dm-v2-2015-09-04
>>
>> This branch should work just fine. Please give it a try and let me
>> know if this works or not.
>>
>> Thanks,
>> Stefan
>>
>
> Thanks for the fast response! I've tried this version an was able to run
> u-boot as expected.
Ufff! ;)
> Unfortunately u-boot now hangs if I try to load an
> image from the SD-Card:
> e.g. if I run the following command u-boot hangs:
> ext4load mmc 0:2 0x2000000 /boot/kernel.bin
>
> I don't see why exactly it crashes, it seems for me that it's always at
> a different position.
>
> Here are two backtraces, always at a different positions:
>
> Here u-boot stopped automatically:
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x7ff65d84 in ?? ()
> (gdb) backtrace
> #0 0x7ff65d84 in ?? ()
> #1 0x803663d0 in ?? ()
> #2 0x803663d0 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> And here I've got perhaps some more information?
> Program received signal SIGSTOP, Stopped (signal).
> v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
> way_shift=<optimized out>, num_ways=<optimized out>,
> num_sets=<optimized out>, level=<optimized out>) at
> arch/arm/cpu/armv7/cache_v7.c:62
> 62 for (set = num_sets - 1; set >= 0; set--) {
> (gdb) backtrace
> #0 v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
> way_shift=<optimized out>,
> num_ways=<optimized out>, num_sets=<optimized out>,
> level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
> #1 v7_maint_dcache_level_setway (operation=<optimized out>, level=9) at
> arch/arm/cpu/armv7/cache_v7.c:129
> #2 v7_maint_dcache_all (operation=2146852864) at
> arch/arm/cpu/armv7/cache_v7.c:147
> #3 0xfffffbe2 in ?? ()
> #4 0xfffffbe2 in ?? ()
>
> Could it be that there is something wrong with cache/dram setup?
Maybe. Hard to tell. Why don't you use "dcache off" before you start the
command. If this works, then we still have a problem with cache (L1 / L2)...
Thanks,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-04 16:44 ` Stefan Roese
@ 2015-09-11 13:50 ` Stefan Eichenberger
2015-09-11 14:24 ` Stefan Roese
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Eichenberger @ 2015-09-11 13:50 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 09/04/2015 06:44 PM, Stefan Roese wrote:
>> Unfortunately u-boot now hangs if I try to load an image from the
>> SD-Card:
>> e.g. if I run the following command u-boot hangs:
>> ext4load mmc 0:2 0x2000000 /boot/kernel.bin
>>
>> I don't see why exactly it crashes, it seems for me that it's always at
>> a different position.
>>
>> Here are two backtraces, always at a different positions:
>>
>> Here u-boot stopped automatically:
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x7ff65d84 in ?? ()
>> (gdb) backtrace
>> #0 0x7ff65d84 in ?? ()
>> #1 0x803663d0 in ?? ()
>> #2 0x803663d0 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt
>> stack?)
>>
>> And here I've got perhaps some more information?
>> Program received signal SIGSTOP, Stopped (signal).
>> v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>> way_shift=<optimized out>, num_ways=<optimized out>,
>> num_sets=<optimized out>, level=<optimized out>) at
>> arch/arm/cpu/armv7/cache_v7.c:62
>> 62 for (set = num_sets - 1; set >= 0; set--) {
>> (gdb) backtrace
>> #0 v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>> way_shift=<optimized out>,
>> num_ways=<optimized out>, num_sets=<optimized out>,
>> level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
>> #1 v7_maint_dcache_level_setway (operation=<optimized out>, level=9) at
>> arch/arm/cpu/armv7/cache_v7.c:129
>> #2 v7_maint_dcache_all (operation=2146852864) at
>> arch/arm/cpu/armv7/cache_v7.c:147
>> #3 0xfffffbe2 in ?? ()
>> #4 0xfffffbe2 in ?? ()
>>
>> Could it be that there is something wrong with cache/dram setup?
>
> Maybe. Hard to tell. Why don't you use "dcache off" before you start
> the command. If this works, then we still have a problem with cache
> (L1 / L2)...
I now did some tests, it seems that the kernel only crashes if I access
the SD-Card, I'm able to load the kernel from an USB-Device. I tried to
disable the dcache but the problem still remains.
Another problem I have is that if I try to start a mainline kernel, it
will crash with the following trace, I think it doesn't find the
devicetree for some reasons:
## Booting kernel from Legacy Image at 02000000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7258976 Bytes = 6.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 03000000
Booting using the fdt blob at 0x3000000
Loading Kernel Image ... OK
Loading Device Tree to 7fb49000, end 7fb4ee70 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.2.0 (eichenberger at gruene) (gcc version
4.6.4 (Marvell GCC release 20150204-c4af733b 645
[ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] Machine model: Marvell Armada 385 Development Board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Unable to handle kernel paging request at virtual address
3fb49000
[ 0.000000] pgd = c0004000
[ 0.000000] [3fb49000] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0 #67
[ 0.000000] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 0.000000] task: c06bd528 ti: c06b8000 task.ti: c06b8000
[ 0.000000] PC is at fdt_check_header+0x0/0x78
[ 0.000000] LR is at __unflatten_device_tree+0x1c/0x12c
[ 0.000000] pc : [<c04d960c>] lr : [<c039419c>] psr: 200001d3
[ 0.000000] sp : c06b9f38 ip : 00000000 fp : ef7fce40
[ 0.000000] r10: c071d2f0 r9 : c05c4d7c r8 : 3fb49000
[ 0.000000] r7 : c069454c r6 : c06be514 r5 : c0712f68 r4 : c069454c
[ 0.000000] r3 : c071d308 r2 : c069454c r1 : c071d2f0 r0 : 3fb49000
[ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM
Segment kernel
[ 0.000000] Control: 10c5387d Table: 0000404a DAC: 00000015
[ 0.000000] Process swapper (pid: 0, stack limit = 0xc06b8220)
[ 0.000000] Stack: (0xc06b9f38 to 0xc06ba000)
[ 0.000000]
9f20: ffffffff
c0700000
[ 0.000000] 9f40: ffff1000 0002f7ff 00001000 00000007 c069e348
c069454c c0712f68 c06be514
[ 0.000000] 9f60: c06c2dc0 c06be514 0000000c c069514c c069e348
c0679448 ffffffff 10c5387d
[ 0.000000] 9f80: 414fc091 00000000 00000000 c005aa68 c05c38cc
c06b9fb4 00000000 00000000
[ 0.000000] 9fa0: 00000001 ffffffff c06f4380 00000000 414fc091
00000000 00000000 c067693c
[ 0.000000] 9fc0: 00000000 00000000 00000000 00000000 00000000
c06a9288 00000000 c06f4614
[ 0.000000] 9fe0: c06ba4c0 c06a9284 c06be624 0000406a 00000000
0000807c 00000000 00000000
[ 0.000000] [<c04d960c>] (fdt_check_header) from [<c039419c>]
(__unflatten_device_tree+0x1c/0x12c)
[ 0.000000] [<c039419c>] (__unflatten_device_tree) from [<c069514c>]
(unflatten_device_tree+0x1c/0x34)
[ 0.000000] [<c069514c>] (unflatten_device_tree) from [<c0679448>]
(setup_arch+0x6e8/0x970)
[ 0.000000] [<c0679448>] (setup_arch) from [<c067693c>]
(start_kernel+0x88/0x3c0)
[ 0.000000] [<c067693c>] (start_kernel) from [<0000807c>] (0x807c)
[ 0.000000] Code: e3e0300d eafbbec4 e3e0300d eafbbec9 (e5903000)
[ 0.000000] ---[ end trace cb88537fdc8fa200 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill
the idle task!
Do you have an idea what I'm doing wrong here? With the SDK U-Boot
everything works fine.
Best regards,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-11 13:50 ` Stefan Eichenberger
@ 2015-09-11 14:24 ` Stefan Roese
2015-09-11 15:02 ` Stefan Eichenberger
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Roese @ 2015-09-11 14:24 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 11.09.2015 15:50, Stefan Eichenberger wrote:
> On 09/04/2015 06:44 PM, Stefan Roese wrote:
>
>>> Unfortunately u-boot now hangs if I try to load an image from the
>>> SD-Card:
>>> e.g. if I run the following command u-boot hangs:
>>> ext4load mmc 0:2 0x2000000 /boot/kernel.bin
>>>
>>> I don't see why exactly it crashes, it seems for me that it's always at
>>> a different position.
>>>
>>> Here are two backtraces, always at a different positions:
>>>
>>> Here u-boot stopped automatically:
>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>> 0x7ff65d84 in ?? ()
>>> (gdb) backtrace
>>> #0 0x7ff65d84 in ?? ()
>>> #1 0x803663d0 in ?? ()
>>> #2 0x803663d0 in ?? ()
>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>> stack?)
>>>
>>> And here I've got perhaps some more information?
>>> Program received signal SIGSTOP, Stopped (signal).
>>> v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>> way_shift=<optimized out>, num_ways=<optimized out>,
>>> num_sets=<optimized out>, level=<optimized out>) at
>>> arch/arm/cpu/armv7/cache_v7.c:62
>>> 62 for (set = num_sets - 1; set >= 0; set--) {
>>> (gdb) backtrace
>>> #0 v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>> way_shift=<optimized out>,
>>> num_ways=<optimized out>, num_sets=<optimized out>,
>>> level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
>>> #1 v7_maint_dcache_level_setway (operation=<optimized out>, level=9) at
>>> arch/arm/cpu/armv7/cache_v7.c:129
>>> #2 v7_maint_dcache_all (operation=2146852864) at
>>> arch/arm/cpu/armv7/cache_v7.c:147
>>> #3 0xfffffbe2 in ?? ()
>>> #4 0xfffffbe2 in ?? ()
>>>
>>> Could it be that there is something wrong with cache/dram setup?
>>
>> Maybe. Hard to tell. Why don't you use "dcache off" before you start
>> the command. If this works, then we still have a problem with cache
>> (L1 / L2)...
>
> I now did some tests, it seems that the kernel only crashes if I access
> the SD-Card, I'm able to load the kernel from an USB-Device. I tried to
> disable the dcache but the problem still remains.
>
> Another problem I have is that if I try to start a mainline kernel, it
> will crash with the following trace, I think it doesn't find the
> devicetree for some reasons:
Didn't you mention above, that booting Linux does work when booted via
USB? Is this crash below a caused by accessing the SD-card?
> ## Booting kernel from Legacy Image at 02000000 ...
> Image Name:
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 7258976 Bytes = 6.9 MiB
> Load Address: 00008000
> Entry Point: 00008000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 03000000
> Booting using the fdt blob at 0x3000000
> Loading Kernel Image ... OK
> Loading Device Tree to 7fb49000, end 7fb4ee70 ... OK
>
> Starting kernel ...
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 4.2.0 (eichenberger at gruene) (gcc version
> 4.6.4 (Marvell GCC release 20150204-c4af733b 645
> [ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7),
> cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [ 0.000000] Machine model: Marvell Armada 385 Development Board
> [ 0.000000] bootconsole [earlycon0] enabled
> [ 0.000000] Memory policy: Data cache writealloc
> [ 0.000000] Unable to handle kernel paging request at virtual address
> 3fb49000
> [ 0.000000] pgd = c0004000
> [ 0.000000] [3fb49000] *pgd=00000000
> [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0 #67
> [ 0.000000] Hardware name: Marvell Armada 380/385 (Device Tree)
> [ 0.000000] task: c06bd528 ti: c06b8000 task.ti: c06b8000
> [ 0.000000] PC is at fdt_check_header+0x0/0x78
> [ 0.000000] LR is at __unflatten_device_tree+0x1c/0x12c
> [ 0.000000] pc : [<c04d960c>] lr : [<c039419c>] psr: 200001d3
> [ 0.000000] sp : c06b9f38 ip : 00000000 fp : ef7fce40
> [ 0.000000] r10: c071d2f0 r9 : c05c4d7c r8 : 3fb49000
> [ 0.000000] r7 : c069454c r6 : c06be514 r5 : c0712f68 r4 : c069454c
> [ 0.000000] r3 : c071d308 r2 : c069454c r1 : c071d2f0 r0 : 3fb49000
> [ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM
> Segment kernel
> [ 0.000000] Control: 10c5387d Table: 0000404a DAC: 00000015
> [ 0.000000] Process swapper (pid: 0, stack limit = 0xc06b8220)
> [ 0.000000] Stack: (0xc06b9f38 to 0xc06ba000)
> [ 0.000000]
> 9f20: ffffffff
> c0700000
> [ 0.000000] 9f40: ffff1000 0002f7ff 00001000 00000007 c069e348
> c069454c c0712f68 c06be514
> [ 0.000000] 9f60: c06c2dc0 c06be514 0000000c c069514c c069e348
> c0679448 ffffffff 10c5387d
> [ 0.000000] 9f80: 414fc091 00000000 00000000 c005aa68 c05c38cc
> c06b9fb4 00000000 00000000
> [ 0.000000] 9fa0: 00000001 ffffffff c06f4380 00000000 414fc091
> 00000000 00000000 c067693c
> [ 0.000000] 9fc0: 00000000 00000000 00000000 00000000 00000000
> c06a9288 00000000 c06f4614
> [ 0.000000] 9fe0: c06ba4c0 c06a9284 c06be624 0000406a 00000000
> 0000807c 00000000 00000000
> [ 0.000000] [<c04d960c>] (fdt_check_header) from [<c039419c>]
> (__unflatten_device_tree+0x1c/0x12c)
> [ 0.000000] [<c039419c>] (__unflatten_device_tree) from [<c069514c>]
> (unflatten_device_tree+0x1c/0x34)
> [ 0.000000] [<c069514c>] (unflatten_device_tree) from [<c0679448>]
> (setup_arch+0x6e8/0x970)
> [ 0.000000] [<c0679448>] (setup_arch) from [<c067693c>]
> (start_kernel+0x88/0x3c0)
> [ 0.000000] [<c067693c>] (start_kernel) from [<0000807c>] (0x807c)
> [ 0.000000] Code: e3e0300d eafbbec4 e3e0300d eafbbec9 (e5903000)
> [ 0.000000] ---[ end trace cb88537fdc8fa200 ]---
> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill
> the idle task!
>
> Do you have an idea what I'm doing wrong here? With the SDK U-Boot
> everything works fine.
Not really. How much RAM is installed on the board? Does booting work
with "mem=2G"?
Thanks,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-11 14:24 ` Stefan Roese
@ 2015-09-11 15:02 ` Stefan Eichenberger
2015-09-14 14:23 ` Stefan Eichenberger
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Eichenberger @ 2015-09-11 15:02 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 09/11/2015 04:24 PM, Stefan Roese wrote:
> Hi Stefan,
>
> On 11.09.2015 15:50, Stefan Eichenberger wrote:
>> On 09/04/2015 06:44 PM, Stefan Roese wrote:
>>
>>>> Unfortunately u-boot now hangs if I try to load an image from the
>>>> SD-Card:
>>>> e.g. if I run the following command u-boot hangs:
>>>> ext4load mmc 0:2 0x2000000 /boot/kernel.bin
>>>>
>>>> I don't see why exactly it crashes, it seems for me that it's
>>>> always at
>>>> a different position.
>>>>
>>>> Here are two backtraces, always at a different positions:
>>>>
>>>> Here u-boot stopped automatically:
>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>> 0x7ff65d84 in ?? ()
>>>> (gdb) backtrace
>>>> #0 0x7ff65d84 in ?? ()
>>>> #1 0x803663d0 in ?? ()
>>>> #2 0x803663d0 in ?? ()
>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>> stack?)
>>>>
>>>> And here I've got perhaps some more information?
>>>> Program received signal SIGSTOP, Stopped (signal).
>>>> v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>>> way_shift=<optimized out>, num_ways=<optimized out>,
>>>> num_sets=<optimized out>, level=<optimized out>) at
>>>> arch/arm/cpu/armv7/cache_v7.c:62
>>>> 62 for (set = num_sets - 1; set >= 0; set--) {
>>>> (gdb) backtrace
>>>> #0 v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>>> way_shift=<optimized out>,
>>>> num_ways=<optimized out>, num_sets=<optimized out>,
>>>> level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
>>>> #1 v7_maint_dcache_level_setway (operation=<optimized out>,
>>>> level=9) at
>>>> arch/arm/cpu/armv7/cache_v7.c:129
>>>> #2 v7_maint_dcache_all (operation=2146852864) at
>>>> arch/arm/cpu/armv7/cache_v7.c:147
>>>> #3 0xfffffbe2 in ?? ()
>>>> #4 0xfffffbe2 in ?? ()
>>>>
>>>> Could it be that there is something wrong with cache/dram setup?
>>>
>>> Maybe. Hard to tell. Why don't you use "dcache off" before you start
>>> the command. If this works, then we still have a problem with cache
>>> (L1 / L2)...
>>
>> I now did some tests, it seems that the kernel only crashes if I access
>> the SD-Card, I'm able to load the kernel from an USB-Device. I tried to
>> disable the dcache but the problem still remains.
>>
>> Another problem I have is that if I try to start a mainline kernel, it
>> will crash with the following trace, I think it doesn't find the
>> devicetree for some reasons:
>
> Didn't you mention above, that booting Linux does work when booted via
> USB? Is this crash below a caused by accessing the SD-card?
Sorry that was unclear. I can load the Linux kernel from USB into RAM
and jump to the load address but then Linux crashes. The SD-card access
seems totally broken.
>
>> ## Booting kernel from Legacy Image at 02000000 ...
>> Image Name:
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 7258976 Bytes = 6.9 MiB
>> Load Address: 00008000
>> Entry Point: 00008000
>> Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 03000000
>> Booting using the fdt blob at 0x3000000
>> Loading Kernel Image ... OK
>> Loading Device Tree to 7fb49000, end 7fb4ee70 ... OK
>>
>> Starting kernel ...
>>
>> [ 0.000000] Booting Linux on physical CPU 0x0
>> [ 0.000000] Linux version 4.2.0 (eichenberger at gruene) (gcc version
>> 4.6.4 (Marvell GCC release 20150204-c4af733b 645
>> [ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7),
>> cr=10c5387d
>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [ 0.000000] Machine model: Marvell Armada 385 Development Board
>> [ 0.000000] bootconsole [earlycon0] enabled
>> [ 0.000000] Memory policy: Data cache writealloc
>> [ 0.000000] Unable to handle kernel paging request at virtual address
>> 3fb49000
>> [ 0.000000] pgd = c0004000
>> [ 0.000000] [3fb49000] *pgd=00000000
>> [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
>> [ 0.000000] Modules linked in:
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0 #67
>> [ 0.000000] Hardware name: Marvell Armada 380/385 (Device Tree)
>> [ 0.000000] task: c06bd528 ti: c06b8000 task.ti: c06b8000
>> [ 0.000000] PC is at fdt_check_header+0x0/0x78
>> [ 0.000000] LR is at __unflatten_device_tree+0x1c/0x12c
>> [ 0.000000] pc : [<c04d960c>] lr : [<c039419c>] psr: 200001d3
>> [ 0.000000] sp : c06b9f38 ip : 00000000 fp : ef7fce40
>> [ 0.000000] r10: c071d2f0 r9 : c05c4d7c r8 : 3fb49000
>> [ 0.000000] r7 : c069454c r6 : c06be514 r5 : c0712f68 r4 :
>> c069454c
>> [ 0.000000] r3 : c071d308 r2 : c069454c r1 : c071d2f0 r0 :
>> 3fb49000
>> [ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM
>> Segment kernel
>> [ 0.000000] Control: 10c5387d Table: 0000404a DAC: 00000015
>> [ 0.000000] Process swapper (pid: 0, stack limit = 0xc06b8220)
>> [ 0.000000] Stack: (0xc06b9f38 to 0xc06ba000)
>> [ 0.000000]
>> 9f20: ffffffff
>> c0700000
>> [ 0.000000] 9f40: ffff1000 0002f7ff 00001000 00000007 c069e348
>> c069454c c0712f68 c06be514
>> [ 0.000000] 9f60: c06c2dc0 c06be514 0000000c c069514c c069e348
>> c0679448 ffffffff 10c5387d
>> [ 0.000000] 9f80: 414fc091 00000000 00000000 c005aa68 c05c38cc
>> c06b9fb4 00000000 00000000
>> [ 0.000000] 9fa0: 00000001 ffffffff c06f4380 00000000 414fc091
>> 00000000 00000000 c067693c
>> [ 0.000000] 9fc0: 00000000 00000000 00000000 00000000 00000000
>> c06a9288 00000000 c06f4614
>> [ 0.000000] 9fe0: c06ba4c0 c06a9284 c06be624 0000406a 00000000
>> 0000807c 00000000 00000000
>> [ 0.000000] [<c04d960c>] (fdt_check_header) from [<c039419c>]
>> (__unflatten_device_tree+0x1c/0x12c)
>> [ 0.000000] [<c039419c>] (__unflatten_device_tree) from [<c069514c>]
>> (unflatten_device_tree+0x1c/0x34)
>> [ 0.000000] [<c069514c>] (unflatten_device_tree) from [<c0679448>]
>> (setup_arch+0x6e8/0x970)
>> [ 0.000000] [<c0679448>] (setup_arch) from [<c067693c>]
>> (start_kernel+0x88/0x3c0)
>> [ 0.000000] [<c067693c>] (start_kernel) from [<0000807c>] (0x807c)
>> [ 0.000000] Code: e3e0300d eafbbec4 e3e0300d eafbbec9 (e5903000)
>> [ 0.000000] ---[ end trace cb88537fdc8fa200 ]---
>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle
>> task!
>> [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill
>> the idle task!
>>
>> Do you have an idea what I'm doing wrong here? With the SDK U-Boot
>> everything works fine.
>
> Not really. How much RAM is installed on the board? Does booting work
> with "mem=2G"?
2 GB are correct unfortuantely the mem=2G option did not help. It seems
that the Linux kernel searches the devicetree at 0x3fb47020 (0x7fb47020
before MMU enabled?) but there are only zeros. U-Boot seems to load the
Devicetree correctly so I will try to debug Linux. Perhaps it clears
this region for some reasons.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp
2015-09-11 15:02 ` Stefan Eichenberger
@ 2015-09-14 14:23 ` Stefan Eichenberger
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Eichenberger @ 2015-09-14 14:23 UTC (permalink / raw)
To: u-boot
Hi Stefan,
On 09/11/2015 05:02 PM, Stefan Eichenberger wrote:
> Hi Stefan,
>
> On 09/11/2015 04:24 PM, Stefan Roese wrote:
>> Hi Stefan,
>>
>> On 11.09.2015 15:50, Stefan Eichenberger wrote:
>>> On 09/04/2015 06:44 PM, Stefan Roese wrote:
>>>
>>>>> Unfortunately u-boot now hangs if I try to load an image from the
>>>>> SD-Card:
>>>>> e.g. if I run the following command u-boot hangs:
>>>>> ext4load mmc 0:2 0x2000000 /boot/kernel.bin
>>>>>
>>>>> I don't see why exactly it crashes, it seems for me that it's
>>>>> always at
>>>>> a different position.
>>>>>
>>>>> Here are two backtraces, always at a different positions:
>>>>>
>>>>> Here u-boot stopped automatically:
>>>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>>>> 0x7ff65d84 in ?? ()
>>>>> (gdb) backtrace
>>>>> #0 0x7ff65d84 in ?? ()
>>>>> #1 0x803663d0 in ?? ()
>>>>> #2 0x803663d0 in ?? ()
>>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>>> stack?)
>>>>>
>>>>> And here I've got perhaps some more information?
>>>>> Program received signal SIGSTOP, Stopped (signal).
>>>>> v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>>>> way_shift=<optimized out>, num_ways=<optimized out>,
>>>>> num_sets=<optimized out>, level=<optimized out>) at
>>>>> arch/arm/cpu/armv7/cache_v7.c:62
>>>>> 62 for (set = num_sets - 1; set >= 0; set--) {
>>>>> (gdb) backtrace
>>>>> #0 v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>>>> way_shift=<optimized out>,
>>>>> num_ways=<optimized out>, num_sets=<optimized out>,
>>>>> level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
>>>>> #1 v7_maint_dcache_level_setway (operation=<optimized out>,
>>>>> level=9) at
>>>>> arch/arm/cpu/armv7/cache_v7.c:129
>>>>> #2 v7_maint_dcache_all (operation=2146852864) at
>>>>> arch/arm/cpu/armv7/cache_v7.c:147
>>>>> #3 0xfffffbe2 in ?? ()
>>>>> #4 0xfffffbe2 in ?? ()
>>>>>
>>>>> Could it be that there is something wrong with cache/dram setup?
>>>>
>>>> Maybe. Hard to tell. Why don't you use "dcache off" before you start
>>>> the command. If this works, then we still have a problem with cache
>>>> (L1 / L2)...
>>>
>>> I now did some tests, it seems that the kernel only crashes if I access
>>> the SD-Card, I'm able to load the kernel from an USB-Device. I tried to
>>> disable the dcache but the problem still remains.
>>>
>>> Another problem I have is that if I try to start a mainline kernel, it
>>> will crash with the following trace, I think it doesn't find the
>>> devicetree for some reasons:
>>
>> Didn't you mention above, that booting Linux does work when booted
>> via USB? Is this crash below a caused by accessing the SD-card?
>
> Sorry that was unclear. I can load the Linux kernel from USB into RAM
> and jump to the load address but then Linux crashes. The SD-card
> access seems totally broken.
If I disable the SDMA then the SD-card access works correctly without
U-Boot crash, no idea what causes the trouble with SDMA enabled.
>
>>
>>> ## Booting kernel from Legacy Image at 02000000 ...
>>> Image Name:
>>> Image Type: ARM Linux Kernel Image (uncompressed)
>>> Data Size: 7258976 Bytes = 6.9 MiB
>>> Load Address: 00008000
>>> Entry Point: 00008000
>>> Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 03000000
>>> Booting using the fdt blob at 0x3000000
>>> Loading Kernel Image ... OK
>>> Loading Device Tree to 7fb49000, end 7fb4ee70 ... OK
>>>
>>> Starting kernel ...
>>>
>>> [ 0.000000] Booting Linux on physical CPU 0x0
>>> [ 0.000000] Linux version 4.2.0 (eichenberger at gruene) (gcc version
>>> 4.6.4 (Marvell GCC release 20150204-c4af733b 645
>>> [ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7),
>>> cr=10c5387d
>>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>>> instruction cache
>>> [ 0.000000] Machine model: Marvell Armada 385 Development Board
>>> [ 0.000000] bootconsole [earlycon0] enabled
>>> [ 0.000000] Memory policy: Data cache writealloc
>>> [ 0.000000] Unable to handle kernel paging request at virtual
>>> address
>>> 3fb49000
>>> [ 0.000000] pgd = c0004000
>>> [ 0.000000] [3fb49000] *pgd=00000000
>>> [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
>>> [ 0.000000] Modules linked in:
>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0 #67
>>> [ 0.000000] Hardware name: Marvell Armada 380/385 (Device Tree)
>>> [ 0.000000] task: c06bd528 ti: c06b8000 task.ti: c06b8000
>>> [ 0.000000] PC is at fdt_check_header+0x0/0x78
>>> [ 0.000000] LR is at __unflatten_device_tree+0x1c/0x12c
>>> [ 0.000000] pc : [<c04d960c>] lr : [<c039419c>] psr: 200001d3
>>> [ 0.000000] sp : c06b9f38 ip : 00000000 fp : ef7fce40
>>> [ 0.000000] r10: c071d2f0 r9 : c05c4d7c r8 : 3fb49000
>>> [ 0.000000] r7 : c069454c r6 : c06be514 r5 : c0712f68 r4 :
>>> c069454c
>>> [ 0.000000] r3 : c071d308 r2 : c069454c r1 : c071d2f0 r0 :
>>> 3fb49000
>>> [ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM
>>> Segment kernel
>>> [ 0.000000] Control: 10c5387d Table: 0000404a DAC: 00000015
>>> [ 0.000000] Process swapper (pid: 0, stack limit = 0xc06b8220)
>>> [ 0.000000] Stack: (0xc06b9f38 to 0xc06ba000)
>>> [ 0.000000]
>>> 9f20: ffffffff
>>> c0700000
>>> [ 0.000000] 9f40: ffff1000 0002f7ff 00001000 00000007 c069e348
>>> c069454c c0712f68 c06be514
>>> [ 0.000000] 9f60: c06c2dc0 c06be514 0000000c c069514c c069e348
>>> c0679448 ffffffff 10c5387d
>>> [ 0.000000] 9f80: 414fc091 00000000 00000000 c005aa68 c05c38cc
>>> c06b9fb4 00000000 00000000
>>> [ 0.000000] 9fa0: 00000001 ffffffff c06f4380 00000000 414fc091
>>> 00000000 00000000 c067693c
>>> [ 0.000000] 9fc0: 00000000 00000000 00000000 00000000 00000000
>>> c06a9288 00000000 c06f4614
>>> [ 0.000000] 9fe0: c06ba4c0 c06a9284 c06be624 0000406a 00000000
>>> 0000807c 00000000 00000000
>>> [ 0.000000] [<c04d960c>] (fdt_check_header) from [<c039419c>]
>>> (__unflatten_device_tree+0x1c/0x12c)
>>> [ 0.000000] [<c039419c>] (__unflatten_device_tree) from [<c069514c>]
>>> (unflatten_device_tree+0x1c/0x34)
>>> [ 0.000000] [<c069514c>] (unflatten_device_tree) from [<c0679448>]
>>> (setup_arch+0x6e8/0x970)
>>> [ 0.000000] [<c0679448>] (setup_arch) from [<c067693c>]
>>> (start_kernel+0x88/0x3c0)
>>> [ 0.000000] [<c067693c>] (start_kernel) from [<0000807c>] (0x807c)
>>> [ 0.000000] Code: e3e0300d eafbbec4 e3e0300d eafbbec9 (e5903000)
>>> [ 0.000000] ---[ end trace cb88537fdc8fa200 ]---
>>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the
>>> idle task!
>>> [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill
>>> the idle task!
>>>
>>> Do you have an idea what I'm doing wrong here? With the SDK U-Boot
>>> everything works fine.
>>
>> Not really. How much RAM is installed on the board? Does booting work
>> with "mem=2G"?
>
> 2 GB are correct unfortuantely the mem=2G option did not help. It
> seems that the Linux kernel searches the devicetree at 0x3fb47020
> (0x7fb47020 before MMU enabled?) but there are only zeros. U-Boot
> seems to load the Devicetree correctly so I will try to debug Linux.
> Perhaps it clears this region for some reasons.
>
> Thanks,
> Stefan
>
I found the reason why the kernel did not boot. Unfortunately U-Boot was
still loading the default env from the SDK where fdt_high was not set to
0x10000000 and therefore the kernel did not find the devicetree. Sorry
for that!
Regards,
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-09-14 14:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-04 14:44 [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp Stefan Eichenberger
2015-09-04 15:14 ` Stefan Roese
2015-09-04 16:15 ` Stefan Eichenberger
2015-09-04 16:44 ` Stefan Roese
2015-09-11 13:50 ` Stefan Eichenberger
2015-09-11 14:24 ` Stefan Roese
2015-09-11 15:02 ` Stefan Eichenberger
2015-09-14 14:23 ` Stefan Eichenberger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.