coreboot and u-boot integration x86: "No tick base available"

Hi.

I'm trying to use u-boot as a payload to coreboot. Problem is that when coreboot starts u-boot, it fails with panic("No tick base available");

When looking at the backtrace this gives a recursive error, as panic calls __udelay and get_ticks, which again panics. I heard this was because u-boot overwrote the memory location of coreboot, and that there have been some patches going around that fixes this issue, but have not made it upstream. As far as I can tell, chromebook v2 uses these patches to make their stuff boot. Can anyone point me in the right direction for those patches? I have tried finding them myself, but can't seem to find them.

Hi Martin,

Quoted 5 lines · Martin Erts?s

Hi.

I'm trying to use u-boot as a payload to coreboot. Problem is that when coreboot starts u-boot, it fails with panic("No tick base available");

Quoted 9 lines

When looking at the backtrace this gives a recursive error, as panic calls __udelay and get_ticks, which again panics. I heard this was because u-boot overwrote the memory location of coreboot, and that there have been some patches going around that fixes this issue, but have not made it upstream. As far as I can tell, chromebook v2 uses these patches to make their stuff boot. Can anyone point me in the right direction for those patches? I have tried finding them myself, but can't seem to find them.

It probably means that Coreboot is not passing its timing data to U-Boot. You need to enable a timestamp option in Coreboot to do this.

You could patch it to remove this panic and just use 0 in this case.

Regards,
Simon

Quoted 20 lines · Simon Glass

Hi Martin,

Quoted 5 lines · Martin Erts?s

Hi.

I'm trying to use u-boot as a payload to coreboot. Problem is that when coreboot starts u-boot, it fails with panic("No tick base available");

Quoted 9 lines

When looking at the backtrace this gives a recursive error, as panic calls __udelay and get_ticks, which again panics. I heard this was because u-boot overwrote the memory location of coreboot, and that there have been some patches going around that fixes this issue, but have not made it upstream. As far as I can tell, chromebook v2 uses these patches to make their stuff boot. Can anyone point me in the right direction for those patches? I have tried finding them myself, but can't seem to find them.

It probably means that Coreboot is not passing its timing data to U-Boot. You need to enable a timestamp option in Coreboot to do this.

Quoted 4 lines

You could patch it to remove this panic and just use 0 in this case.

Regards,
Simon

Thanks. I'll look into the timestamp option. So using 0 as the tick value should work?

Hi Martin,

Quoted 21 lines · Martin Erts?s

Quoted 20 lines · Simon Glass

Hi Martin,

Quoted 5 lines · Martin Erts?s

Hi.

I'm trying to use u-boot as a payload to coreboot. Problem is that when coreboot starts u-boot, it fails with panic("No tick base available");

Quoted 9 lines

When looking at the backtrace this gives a recursive error, as panic calls __udelay and get_ticks, which again panics. I heard this was because u-boot overwrote the memory location of coreboot, and that there have been some patches going around that fixes this issue, but have not made it upstream. As far as I can tell, chromebook v2 uses these patches to make their stuff boot. Can anyone point me in the right direction for those patches? I have tried finding them myself, but can't seem to find them.

It probably means that Coreboot is not passing its timing data to U-Boot. You need to enable a timestamp option in Coreboot to do this.

Quoted 6 lines

Quoted 4 lines

You could patch it to remove this panic and just use 0 in this case.

Regards,
Simon

Thanks. I'll look into the timestamp option. So using 0 as the tick value should work?

Yes, although you won't get boot timing from Coreboot then. One of the engineers favoured a panic() to avoid accidentally dropping the function from Coreboot's build. Perhaps it could be changed to be a default in Coreboot? This is the second time the issue has come up in U-Boot.

Also I'd be happy with printing a warning in this case if you want to do a patch.

Regards,

Quoted 36 lines · Simon Glass

Hi Martin,

Quoted 21 lines · Martin Erts?s

Quoted 20 lines · Simon Glass

Hi Martin,

Quoted 5 lines · Martin Erts?s

Hi.

I'm trying to use u-boot as a payload to coreboot. Problem is that when coreboot starts u-boot, it fails with panic("No tick base available");

Quoted 9 lines

When looking at the backtrace this gives a recursive error, as panic calls __udelay and get_ticks, which again panics. I heard this was because u-boot overwrote the memory location of coreboot, and that there have been some patches going around that fixes this issue, but have not made it upstream. As far as I can tell, chromebook v2 uses these patches to make their stuff boot. Can anyone point me in the right direction for those patches? I have tried finding them myself, but can't seem to find them.

It probably means that Coreboot is not passing its timing data to U-Boot. You need to enable a timestamp option in Coreboot to do this.

Quoted 6 lines

Quoted 4 lines

You could patch it to remove this panic and just use 0 in this case.

Regards,
Simon

Thanks. I'll look into the timestamp option. So using 0 as the tick value should work?

Yes, although you won't get boot timing from Coreboot then. One of the engineers favoured a panic() to avoid accidentally dropping the function from Coreboot's build. Perhaps it could be changed to be a default in Coreboot? This is the second time the issue has come up in U-Boot.

Quoted 4 lines

Also I'd be happy with printing a warning in this case if you want to do a patch.

Regards,

Ok. Looked into enabeling it in coreboot though, but couldn't find a way to do it with a qemu machine. Guess I'll have to nag the coreboot developers a bit :)

In one way it was kind of frustrating, but I do see the reason for having it as a panic though. You have probably done something wrong if you forgot to enable ticks. I don't feel like I know u-boot well enough to make a decision if it should be a panic or a warning though. If you would preffer a warning I can make the patch.