Some news here. With help of Diego I found, that GP partition can be addressed:
This works with
Zynq> mmc dev 0 4
MMC: block number 0x1 exceeds max(0x0)
switch to partitions #4, OK
mmc0(part 4) is current device
(0 is the user data area, 1 and 2 the first and second boot partitions, 3 the
RPMB partition and 4, 5, 6 and 7 the up to four general purpose partitions).
Still a potential problem is the message "MMC: block number 0x1 exceeds
max(0x0)"
After that I can see the capacity:
Zynq> mmc info
Device: sdhci@e0100000
Manufacturer ID: 13
OEM: 14e
Name: Q1J54
Tran Speed: 52000000
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 1.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 0 Bytes WRREL
Boot Capacity: 2 MiB ENH
RPMB Capacity: 512 KiB ENH
GP1 Capacity: 1.8 GiB ENH WRREL
But even after activating the GP partition a load fails, neither
load mmc 0:1 80000000 /bin/busy nor
load mmc 0:4 80000000 /bin/busy nor
load mmc 0:0 80000000 /bin/busy give anything else back than
** Bad device size - mmc 0 **
And: "mmc info", shows that this command switches back to user mode, as
capacity is zero again.
Even this seems not ok to me:
Zynq> mmc dev 0 4
MMC: block number 0x1 exceeds max(0x0)
switch to partitions #4, OK
mmc0(part 4) is current device
Zynq> mmc dev
MMC: block number 0x1 exceeds max(0x0)
switch to partitions #0, OK
mmc0(part 0) is current device
It should just sow the partition, not set it again (without parameter)
Best regards
Arno
> Gesendet: Freitag, 07. April 2017 um 04:07 Uhr
> Von: "Jaehoon Chung" <jh80.ch...@samsung.com>
> An: "Arno Steffens" <s...@gmx.li>
> Betreff: Re: [U-Boot] Bug in emmc subsystem
>
> Hi Arno,
>
> On 04/07/2017 04:36 AM, Arno Steffens wrote:
> > Dear Jeahoon Chung,
> >
> > I am in office earliest on Monday.
> >
> > From what I remember there is not much additional debug information to be
> > expected (from the code I have in mind). But I will check this to give you
> > as much support as I can.
> > Which files do you want me to enable debug and what command shall I send to
> > create useful information for you?
>
> If enabled CONFIG_DEBUG, maybe all debug message will be printed.
> I want to see the mmc command's debug message.
>
> Which u-boot version do you use? Well, i can't check in more detail on today.
> :)
> But i think this is not bug..because my all boards are working fine with
> SD-card and eMMC4.41/4.5/5.0.
>
> If it's bug in subsystem, maybe i might see the similar thing...but it's just
> assumption..
> So i need to check whether it's really mmc subsystem bug or not.
>
> >
> > This board is a custom board - most eval boards have SDcard instead of
> > fixed emmc.
>
> Do you use SD-card? Not eMMC?
>
> > Is there any trick to get access to the GP partition?
> > I couldn't found something about this.
> >
> > So before converting to GP / pseudoSingleLevelCell-mode (to extend
> > reliablility) I accessed it with
> > “if ext4load mmc 0:1 ${addr_ld} /{file_name} … ”, but this doesn’t work
> > anymore - it returns with: ** Bad device size - mmc 0 **
> >
> > But maybe I just have to use other command for accessing GP?
> >
> > Best regards
> > Arno
> >
> >
> > Am 06.04.2017 um 14:08 schrieb Jaehoon Chung:
> >> Hi,
> >>
> >> On 04/06/2017 03:55 AM, Arno Steffens wrote:
> >>> There seems to be a problem handling emmc with configured GP partition.
> >>>
> >>> Below the "mmc info". The problem might be that user capacity is
> >>> calculated/shown as "0".
> >>> At least it shows the GP1 partition with correct size - which is not the
> >>> case for "mmc hwpartition" - it denies its existence ;)
> >>>
> >>> Can someone help me to fix this?
> >>
> >> Which board do you use? It seems that the initializing mmc might be failed.
> >> After enabling debug option, share the log about mmc.
> >>
> >> Best Regards,
> >> Jaehoon Chung
> >>
> >>>
> >>> Thanks a lot.
> >>> - Arno
> >>>
> >>>
> >>>> mmc info
> >>> Device: sdhci at e0100000
> >>> Manufacturer ID: 13
> >>> OEM: 14e
> >>> Name: Q1J54
> >>> Tran Speed: 52000000
> >>> Rd Block Len: 512
> >>> MMC version 5.0
> >>> High Capacity: Yes
> >>> Capacity: 0 Bytes
> >>> Bus Width: 4-bit
> >>> Erase Group Size: 512 KiB
> >>> HC WP Group Size: 8 MiB
> >>> User Capacity: 0 Bytes WRREL
> >>> Boot Capacity: 2 MiB ENH
> >>> RPMB Capacity: 512 KiB ENH
> >>> GP1 Capacity: 1.8 GiB ENH WRREL
> >>>
> >>>> mmc hwpartition
> >>> Partition configuration:
> >>> No enhanced user data area
> >>> No GP1 partition
> >>> No GP2 partition
> >>> No GP3 partition
> >>> No GP4 partition
> >>> Card already partitioned
> >>> Failed!
> >>>
> >>>> mmc read 0 0 1
> >>> MMC read: dev # 0, block # 0, count 1 ... MMC: block number 0x1 exceeds
> >>> max(0x0)
> >>> 0 blocks read: ERROR
> >>>
> >>>> mmc dev 0 0
> >>> MMC: block number 0x1 exceeds max(0x0)
> >>> switch to partitions #0, OK
> >>> mmc0(part 0) is current device
> >>>
> >>> BTW:
> >>> The GP partiton was created in Linux by the mmc-utils with
> >>> “mmc gp create -y 1908736 1 1 0 /dev/mmcblk0”
> >>>
> >>> Linux can handle this as you can see in boot message:
> >>> [ 1.248426] mmc0: new high speed MMC card at address 0001
> >>> [ 1.264301] mmcblk0: mmc0:0001 Q1J54A 0 B
> >>> [ 1.268525] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
> >>> [ 1.284605] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
> >>> [ 1.300666] mmcblk0gp0: mmc0:0001 Q1J54A partition 4 1.82 GiB
> >>> [ 1.316563] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
> >>> [ 1.325255] mmcblk0gp0: p1 p2 p3
> >>> …
> >>> [ 3.083325] EXT4-fs (mmcblk0gp0p1): INFO: recovery required on
> >>> readonly filesystem
> >>> [ 3.090893] EXT4-fs (mmcblk0gp0p1): write access will be enabled
> >>> during recovery
> >>> [ 3.189597] EXT4-fs (mmcblk0gp0p1): recovery complete
> >>> [ 3.196310] EXT4-fs (mmcblk0gp0p1): mounted filesystem with ordered
> >>> data mode. Opts: (null)
> >>> _______________________________________________
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
