From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 06652C433F5 for ; Sat, 9 Apr 2022 15:06:21 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C5A6483B0D; Sat, 9 Apr 2022 17:05:57 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=kojedz.in Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (4096-bit key; secure) header.d=kojedz.in header.i=@kojedz.in header.b="DTxGqW7b"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 57F7F83BF6; Sat, 9 Apr 2022 09:30:21 +0200 (CEST) Received: from pi.kojedz.in (pi.kojedz.in [IPv6:2a01:be00:10:201:0:80:0:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6419783AFF for ; Sat, 9 Apr 2022 09:30:18 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=kojedz.in Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=richard@kojedz.in Received: from webmail.srv.kojedz.in (BC9CDDBA.catv.pool.telekom.hu [188.156.221.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) (Authenticated sender: richard@kojedz.in) by pi.kojedz.in (Postfix) with ESMTPSA id 88B251421A; Sat, 9 Apr 2022 09:30:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kojedz.in; s=mail; t=1649489417; bh=RL5HMKtd29aJecxnHH35fhOecJa2Ms69hmqL/wqmYR8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DTxGqW7bJjj2kYXmRz7dTetmlZWNK5G5pISdNLloxLjDRflusvtIorT8zA50DW/9i rzY+Eb7b/k2yiC1SftkFREk6+bThEU6Q4T4Fjrj/pNBV1V+15ntjzWi9xGMzYDctEa M/Z8BmeJti220LWDmERrnqg252ELUISlmD4YmQ9PNdxw5lm9iEWROE8A1Pk4to7Hxz 6v6Lbr3hyJirLVBlyquHJWlPHITPcWQdTzjBw1PFaGz0X+uKpXAcVyb1VZa7WKuaOh 9OdnWiN+K48oI+A8WBDLDeFzVjv4tZL7iadmvuz+ydH2nkNeof2i9dgMOTeROMIB6i kiGlvd4iQcb1DdOvjsyEzVROzqkBrRuVgtEkjp1elS4lUVSSr/DSdPw5TxmwndR31P ExkW8oZT3UvuIUwQVvS056ZdudsCQNQtQMntDHsoaCM5HRMPW58iuK6g2icHX9ywcN JMV7ihSw7W8KmVR+gUaAc8nopSegBS4BP5014GPyEH22bZ7pT+nGEDBgsE3o02mKKF 5GZT3XN188+wjzlPzhGTJm/K4EaWlxkmzGyQqyTheVq3/k0ADVNi4jgDcSfcORDhAl oxD9Kt9MMLIlIKcVjnDjrHSmKiVB1m00WtTaUZSBiCqleMRkELv7/DVCD9i9i/qk5w mrK96q8vfdGwwwvSF8HCTM3A= MIME-Version: 1.0 Date: Sat, 09 Apr 2022 09:30:16 +0200 From: Richard Kojedzinszky To: Kever Yang Cc: u-boot@lists.denx.de Subject: Re: Radxa rock-pi-3a In-Reply-To: <82c4f930b321e5e255c9941511755e9a@kojedz.in> References: <774b3ce33306097071e79a6b9bb3b092@kojedz.in> <14352ea0-9883-a9e3-034c-2443d622f7d9@rock-chips.com> <82c4f930b321e5e255c9941511755e9a@kojedz.in> Message-ID: <041a7bd3fed0a384184cd1f16f5fcc53@kojedz.in> X-Sender: richard@kojedz.in Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 09 Apr 2022 17:05:48 +0200 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Dear Kever, I've tried the patch, and now U-Boot sees the whole 8G. It can boot linux directly, that works now. Great! Howewer, booting linux through grub-efi (/boot/efi/EFI/debian/grubaa64.efi) does not work. Grub itself starts, shows the menu, but booting linux stops. Booting from console looks like: grub> linux (hd0,gpt2)/boot/vmlinuz-5.15.32 grub> linux (hd0,gpt2)/boot/vmlinuz-5.15.32 root=/dev/mmcblk1p2 console=ttyS2,1500000 rootwait grub> initrd (hd0,gpt2)/boot/initrd.img-5.15.32 grub> boot EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... These are the last lines. I see no sign of the kernel booting. For example, ethernet leds are not turned on. This u-boot+efi setup works on other boards, and also it worked before the patch, with 1G visible ram only. Thanks in advance, Richard 2022-04-09 06:56 időpontban Richard Kojedzinszky ezt írta: > Hi Kever, > > Thanks for your reply! I greatly appreciate your work, really. > Additionally, can you please provide me sources of documentations, on > which you base your work? I am totally blind in this area, and I would > be interested in reading such kind of documentation of the SoCs. > > Many thanks, > Richard > > 2022-04-09 04:28 időpontban Kever Yang ezt írta: >> Hi Richard, >> >>     The ATAGs to pass the parameters is not available on the mainline >> U-Boot, and only use os_regs for the ram size for now, it do have the >> limitation for max 4GB now. >> >>     There is a fix for this  on the list, you can try it: >> >> https://patchwork.ozlabs.org/project/uboot/patch/20220222013131.3114990-12-pgwipeout@gmail.com/ >> >> >> >> Thanks, >> >> - Kever >> >> On 2022/4/8 15:44, Richard Kojedzinszky wrote: >>> Dear community, >>> >>> I own a rock-pi-3a board with 8G ram. Right now, radxa's u-boot is >>> capable of detecting the whole amount during boot. Upstream u-boot >>> shows 1G of dram installed. >>> >>> I've started with evb-rk3568_defconfig. >>> >>> What I would like to achieve is that u-boot load grub-efi, to finally >>> boot the operating system. Howewer, with radxa uboot, and using >>> grub-efi, the kernel sees 4G only. If I boot the kernel image >>> directly from radxa u-boot, the whole 8G is visible. I assume that >>> efi is broken somehow, as I get multiple warnings from kernel >>> regarding EFI firmware. >>> >>> >>> Reading radxa's u-boot, it seems that it uses ATAGs do detect memory >>> size. Am I in the right way? >>> >>> Would it be beneficial to port some of that code to upstream u-boot, >>> or are there other solutions to detect correct memory size? >>> >>> >>> Thanks in advance, >>> Richard