From: Andre Przywara <andre.przywara@arm.com>
To: Stephen Graf <stephen.graf@gmail.com>
Cc: Mikhail Kalashnikov <iuncuim@gmail.com>,
Jagan Teki <jagan@amarulasolutions.com>,
Vignesh R <vigneshr@ti.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
u-boot@lists.denx.de, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support
Date: Tue, 28 Nov 2023 01:29:48 +0000 [thread overview]
Message-ID: <20231128012948.3124e7d2@slackpad.lan> (raw)
In-Reply-To: <d8862c87-072d-4f74-bb37-08f34c610cc8@gmail.com>
On Mon, 27 Nov 2023 12:21:44 -0800
Stephen Graf <stephen.graf@gmail.com> wrote:
Hi Stephen!
> Yes I forgot about the zBIT patch. With this patch also included I built
> and retested u-boot loaded from SPI flash. The two warning/error
> messages disappeared and the flash worked properly and booted from a USB
> device.
Great!
> There was one message that I did not understand:
> "Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment"
This is because there is no environment saved on the SPI flash (yet).
You just copied the U-Boot image, the environment is in a separate
area (behind that), defined by CONFIG_ENV_OFFSET, which is 64K below
1MB. There could be any kind of garbage there, initially, and U-Boot
fortunately protects the environment with a checksum, so detects that
this is not valid data, and falls back to the built-in environment.
And frankly this is probably all you ever need, I think these days
there is little that needs to be saved in the environment.
If you want to give it a try, type "saveenv" on the U-Boot prompt. On
the next boot U-Boot would detect this now properly initialised data
region and you will probably not see the message anymore.
But again this really only makes sense if you *change* something in the
environment and want that preserved across reboots.
> I tried to follow the u-boot documentation on writing the SPI flash but
> had problems with the write command. When issued it returned
> immediately. The erase command took about 5 sec to execute. I researched
> use of mtd commands and got a suggestion to use cat instead, which worked.
Mmh, can you elaborate on that? Did you mean you piped in the data into
the mtd_debug command? Or did you write directly to /dev/mtd0, using
cat? And which version of mtd_debug was this, exactly? I guess the
official one from Debian Bookworm?
Cheers,
Andre
> "root@orangepizero3:~# mtdinfo
> Count of MTD devices: 1
> Present MTD devices: mtd0
> Sysfs interface supported: yes
> root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf0000
> Erased 983040 bytes from address 0x00000000 in flash
> root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf0000
> /home/sysadmin/u-boot-sunxi-with-spl.bin
> file_to_flash: fread, size 0xf0000, n 0xf0000
> fread(): Success
> root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin >
> /dev/mtd0
>
>
> Console log of boot:
>
> U-Boot SPL 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
> -0800)
> DRAM: 1024 MiB
> Trying to boot from sunxi SPI
> NOTICE: BL31: v2.10.0 (debug):v2.10.0
> NOTICE: BL31: Built : 18:07:18, Nov 23 2023
> NOTICE: BL31: Detected Allwinner H616 SoC (1823)
> NOTICE: BL31: Found U-Boot DTB at 0x4a0b2798, model: OrangePi Zero3
> INFO: ARM GICv2 driver initialized
> INFO: Configuring SPC Controller
> INFO: PMIC: Probing AXP305 on RSB
> ERROR: RSB: set run-time address: 0x10003
> INFO: Could not init RSB: -65539
> INFO: BL31: Platform setup done
> INFO: BL31: Initializing runtime services
> INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied
> INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
> INFO: PSCI: Suspend is unavailable
> INFO: BL31: Preparing for EL3 exit to normal world
> INFO: Entry point address = 0x4a000000
> INFO: SPSR = 0x3c9
> INFO: Changed devicetree.
>
>
> U-Boot 2024.01-rc3-00012-g1fcf078f54-dirty (Nov 27 2023 - 10:17:46
> -0800) Allwinner Technology
>
> CPU: Allwinner H616 (SUN50I)
> Model: OrangePi Zero3
> DRAM: 1 GiB
> Core: 57 devices, 25 uclasses, devicetree: separate
> WDT: Not starting watchdog@30090a0
> MMC: mmc@4020000: 0
> Loading Environment from SPIFlash... SF: Detected zb25vq128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
>
> Loading Environment from FAT... Card did not respond to voltage select!
> : -110
> ** Bad device specification mmc 0 **
> In: serial@5000000
> Out: serial@5000000
> Err: serial@5000000
> Allwinner mUSB OTG (Peripheral)
> Net: eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS
> ep2in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> RNDIS ready
> , eth1: usb_ether
> starting USB...
> Bus usb@5200000: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@5200000 for devices... Device NOT ready
> Request Sense returned 02 3A 00
> Device NOT ready
> Request Sense returned 02 3A 00
> Device NOT ready
> Request Sense returned 02 3A 00
> 2 USB Device(s) found
> scanning bus usb@5200400 for devices... 1 USB Device(s) found
> scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot: 0
> Card did not respond to voltage select! : -110
>
> Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC
> Type: Removable Hard Disk
> Capacity: 3828.0 MB = 3.7 GB (7839744 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found U-Boot script /boot.scr
> 1575 bytes read in 1 ms (1.5 MiB/s)
> ## Executing script at 4fc00000
> Mainline u-boot / new-style environment detected.
> This installer medium does not contain a suitable device-tree file for
> this system (allwinner/sun50i-h618-orangepi-zero3.dtb). Aborting boot
> process.
> SCRIPT FAILED: continuing...
> Found U-Boot script /boot/boot.scr
> 621 bytes read in 2 ms (302.7 KiB/s)
> ## Executing script at 4fc00000
> 19472 bytes read in 3 ms (6.2 MiB/s)
> Working FDT set to 4fa00000
> 7088139 bytes read in 326 ms (20.7 MiB/s)
> 22491144 bytes read in 1031 ms (20.8 MiB/s)
> Moving Image from 0x40080000 to 0x40200000, end=41800000
> ## Loading init Ramdisk from Legacy Image at 4ff00000 ...
> Image Name: uInitrd
> Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
> Data Size: 7088075 Bytes = 6.8 MiB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4fa00000
> Booting using the fdt blob at 0x4fa00000
> Working FDT set to 4fa00000
> Loading Ramdisk to 4993d000, end 49fff7cb ... OK
> Loading Device Tree to 00000000498cf000, end 000000004993cfff ... OK
> Working FDT set to 498cf000
>
> Starting kernel ...
>
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> [ 0.000000] Linux version 6.6.2 (orangepi@orangepizero3) (gcc (Debian
> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Sat Nov
> 25 18:37:47 UTC 2023
>
>
> On 2023-11-26 4:23 a.m., Andre Przywara wrote:
> > On Sat, 25 Nov 2023 20:27:05 -0800
> > Stephen Graf <stephen.graf@gmail.com> wrote:
> >
> > Hi Stephen,
> >
> >> I built u-boot with the additional parameter for usb and it works, I think. There was one message that might be of concern "
> >> Card did not respond to voltage select! : -110".
> >
> > This is a normal, though admittedly confusing message if no SD card is
> > inserted. The code tries to (unconditionally) access the SD card, and
> > sees that no card is there, the missing respond to the voltage select
> > command is just the first real proof of this.
> >
> >> I am not sure of the details of the boot.cmd. The output below came from
> >> the supplier image on an SD plugged into a USB card reader. The SD slot of the board was empty.
> >>
> >> I was able to install u-boot to the SPI flash memory and there is a warning message from that also: "
> >> Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 5e, 40, 18
> >> *** Warning - spi_flash_probe_bus_cs() failed, using default environment"
> >
> > So for a start there is no environment on the SPI flash yet, so it
> > wouldn't do anything. But the "unrecognised JEDEC id bytes" message
> > doesn't sound right. Can you dig into this? Do you have patch 1/3
> > applied, which tells U-Boot about 0x5e meaning zBIT?
> >
>
next prev parent reply other threads:[~2023-11-28 1:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 1:31 [PATCH 0/3] sunxi: add OrangePi Zero 3 board support Andre Przywara
2023-11-14 1:31 ` [PATCH 1/3] mtd: spi-nor: Add support for zBIT ZB25VQ128 Andre Przywara
2023-11-14 1:31 ` [PATCH 2/3] sunxi: H616: remove default AXP305 selection Andre Przywara
2023-11-14 13:24 ` Jaehoon Chung
2023-11-14 1:31 ` [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support Andre Przywara
2023-11-25 17:43 ` Mikhail Kalashnikov
2023-11-26 0:23 ` Andre Przywara
2023-11-26 4:27 ` Stephen Graf
2023-11-26 12:23 ` Andre Przywara
2023-11-27 20:21 ` Stephen Graf
2023-11-27 22:31 ` Stephen Graf
2023-11-28 1:37 ` Andre Przywara
2023-11-28 2:35 ` Stephen Graf
2023-11-28 6:03 ` Stephen Graf
2023-11-28 20:07 ` mdt_debug write Stephen Graf
2023-11-29 23:57 ` Andre Przywara
2023-11-30 0:20 ` Stephen Graf
2023-11-30 1:13 ` Stephen Graf
2023-12-01 0:27 ` Andre Przywara
2023-12-01 18:50 ` [PATCH 1/1] correct documentation for SPI flashing Stephen Graf
2023-12-03 23:40 ` Andre Przywara
2023-11-29 18:45 ` OrangePI Zero3 memory timing testing Stephen Graf
2023-11-30 0:10 ` Andre Przywara
2023-11-30 1:15 ` Siarhei Siamashka
2023-11-28 1:29 ` Andre Przywara [this message]
2023-11-26 13:30 ` [PATCH 3/3] sunxi: H616: Add OrangePi Zero 3 board support Mikhail Kalashnikov
2023-11-26 11:45 ` Bob McChesney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231128012948.3124e7d2@slackpad.lan \
--to=andre.przywara@arm.com \
--cc=iuncuim@gmail.com \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=jh80.chung@samsung.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=piotr.oniszczuk@gmail.com \
--cc=stephen.graf@gmail.com \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox