On 2019-09-24 2:35 p.m., Matwey V. Kornilov wrote> How do you take
NetBSD image?
I've been building my own images from NetBSD-CURRENT, following the
guides [1][2].
There was until recently a buffer-alignment issue in NetBSD's EFI
bootloader that prevented it from working with the current
24.09.2019 20:54, Simon South пишет:
> On 2019-09-24 12:54 p.m., Matwey V. Kornilov wrote:
>> Simon, maybe you'll describe a way to obtain SD card image which you
>> use? For the case if anybody wants to reproduce the issue in situ?
>
> Sure---I'd love for other people to test this, and it's
On 2019-09-24 12:54 p.m., Matwey V. Kornilov wrote:
Simon, maybe you'll describe a way to obtain SD card image which you
use? For the case if anybody wants to reproduce the issue in situ?
Sure---I'd love for other people to test this, and it's pretty easy
since it doesn't require anything
Simon, maybe you'll describe a way to obtain SD card image which you
use? For the case if anybody wants to reproduce the issue in situ?
сб, 21 сент. 2019 г. в 20:15, Matwey V. Kornilov :
>
> сб, 21 сент. 2019 г. в 16:38, Simon South :
> >
> > On 2019-09-21 8:29 a.m., Matwey V. Kornilov wrote:
> >
On 2019-09-19 4:56 a.m., Simon South wrote:
I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0,
Rockchip RK3328) using U-Boot built with its own TPL...
This definitely seems memory-related: After enabling the "mtest" command
(patch attached) and running the memory test at the
сб, 21 сент. 2019 г. в 16:38, Simon South :
>
> On 2019-09-21 8:29 a.m., Matwey V. Kornilov wrote:
> > Could you try to load dtb (and check that dtb is valid) into the other
> > memory location?
>
> Same result: With the U-Boot TPL this fails (the FDT header is corrupt);
> with the Rockchip TPL
On 2019-09-21 8:29 a.m., Matwey V. Kornilov wrote:
Could you try to load dtb (and check that dtb is valid) into the other
memory location?
Same result: With the U-Boot TPL this fails (the FDT header is corrupt);
with the Rockchip TPL this works fine. See below.
I notice though it always
Could you try to load dtb (and check that dtb is valid) into the other
memory location?
For instance into ${kernel_addr_r} which is a place for loading EFI
application binary?
пт, 20 сент. 2019 г. в 20:44, Simon South :
>
> On 2019-09-20 1:37 p.m., Matwey V. Kornilov wrote:
> > What is the
On 2019-09-21 3:47 a.m., Matwey V. Kornilov wrote:
Could you please try to revert this commit and see what's happening then?
Unfortunately undoing that change makes things worse: Either the NetBSD
EFI bootloader hangs immediately on start (without any output) or it
crashes with output like
Could you please try to revert this commit and see what's happening then?
https://github.com/u-boot/u-boot/commit/16593ccd07afdbb24a937eac4ea7e16269ff51e0
пт, 20 сент. 2019, 20:44 Simon South :
> On 2019-09-20 1:37 p.m., Matwey V. Kornilov wrote:
> > What is the difference? In filesize?
>
> The
On 2019-09-20 1:27 p.m., Simon South wrote:
I'm going to apply Elaine's patches and see if that changes things.
Unfortunately no; other than this line now appearing in the output:
PMIC: RK8050 (on=0x10, off=0x04)
nothing seems to have changed. Either the machine hangs or NetBSD's
On 2019-09-20 1:37 p.m., Matwey V. Kornilov wrote:
What is the difference? In filesize?
The EFI bootloader:
205136 bootaa64.efi
The DTB file:
53513 rk3328-rock64.dtb
It's about one quarter the size.
It is strange the EFI bootloader and the kernel both seem always to load
пт, 20 сент. 2019 г. в 20:28, Simon South :
>
> On 2019-09-20 12:43 p.m., Matwey V. Kornilov wrote:
> > Could you please use u-boot console and try to locate and load dtb
> > file manually using `ls` and `load` commands in both scenarios?
>
> Results attached.
>
> I'm using a regular microSD card,
On 2019-09-20 12:43 p.m., Matwey V. Kornilov wrote:
Could you please use u-boot console and try to locate and load dtb
file manually using `ls` and `load` commands in both scenarios?
Results attached.
I'm using a regular microSD card, not eMMC, but you're right: Using the
U-Boot TPL the DTB
пт, 20 сент. 2019 г. в 13:14, Martin Husemann :
>
> On Fri, Sep 20, 2019 at 01:07:12PM +0300, Matwey V. Kornilov wrote:
> > Do you have an idea where is correct FDT supposed to came from in
> > NetBSD case? For Linux, the file is placed on the boot partition and
> > retrieved by u-boot while
On Fri, Sep 20, 2019 at 01:07:12PM +0300, Matwey V. Kornilov wrote:
> Do you have an idea where is correct FDT supposed to came from in
> NetBSD case? For Linux, the file is placed on the boot partition and
> retrieved by u-boot while looking for EFI application, etc.
Same for NetBSD. Assuming
On 2019-09-20 6:03 a.m., Mark Kettenis wrote:
One thing to look at is whether (voltage) regulators and/or clocks are
set up right...
Thanks, Mark. This is helpful.
But I believe the Linux kernel doesn't trust the bootloader and will
configure such a regulator anyway.
This is my assumption
пт, 20 сент. 2019 г. в 12:30, Simon South :
>
> On 2019-09-20 3:39 a.m., Matwey V. Kornilov wrote:
> > Could you please provide us console logs for both successful and
> > unsuccessful cases?
>
> Attached.
>
> The only differences I see are
>
> - The random Ethernet address assigned in each case,
> From: Simon South
> Date: Thu, 19 Sep 2019 04:56:57 -0400
>
> I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0,
> Rockchip RK3328) using U-Boot built with its own TPL, the default since
> commit ff3dd0a474.
>
> The same NetBSD image boots fine using the binary TPL supplied
On 2019-09-20 3:39 a.m., Matwey V. Kornilov wrote:
Could you please provide us console logs for both successful and
unsuccessful cases?
Attached.
The only differences I see are
- The random Ethernet address assigned in each case, and
- The "FDT_ERR_BADMAGIC" error messages that are output
20.09.2019 3:06, Simon South пишет:
> On 2019-09-19 11:48 a.m., Matwey V. Kornilov wrote:
>> I have no idea what is going on. But are you sure that you tested the
>> same u-boot binaries with or without binary TPL?
> I believe so. Here's how I build U-Boot with its own TPL:
>
> make -j2
On 2019-09-19 12:29 p.m., Jagan Teki wrote:
It seems to be a memory overlap or similar. replace TPL with rkbin
would be worth checking since the DRAM is managed by rkbin instead of
TPL here.
rkbin => SPL => U-Boot proper
That configuration works and allows NetBSD to boot just fine. It's only
On 2019-09-19 11:48 a.m., Matwey V. Kornilov wrote:
I have no idea what is going on. But are you sure that you tested the
same u-boot binaries with or without binary TPL?
I believe so. Here's how I build U-Boot with its own TPL:
make -j2 distclean; rm idbloader.img
make -j2
19.09.2019 11:56, Simon South пишет:
> I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0,
> Rockchip RK3328) using U-Boot built with its own TPL, the default since
> commit ff3dd0a474.
>
> The same NetBSD image boots fine using the binary TPL supplied by Rockchip.
>
> The exact
On Thu, Sep 19, 2019 at 4:02 PM Simon South wrote:
>
> I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0,
> Rockchip RK3328) using U-Boot built with its own TPL, the default since
> commit ff3dd0a474.
>
> The same NetBSD image boots fine using the binary TPL supplied by Rockchip.
>
19.09.2019 11:56, Simon South пишет:
> I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0,
> Rockchip RK3328) using U-Boot built with its own TPL, the default since
> commit ff3dd0a474.
>
> The same NetBSD image boots fine using the binary TPL supplied by Rockchip.
>
> The exact
I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0,
Rockchip RK3328) using U-Boot built with its own TPL, the default since
commit ff3dd0a474.
The same NetBSD image boots fine using the binary TPL supplied by Rockchip.
The exact failure varies but it always seems memory-related.
27 matches
Mail list logo
