From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/7] usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command
Date: Tue, 3 Jul 2018 23:33:45 +0200 [thread overview]
Message-ID: <20180703233345.7ada995f@jawa> (raw)
In-Reply-To: <1530644652-12537-3-git-send-email-alberto@amarulasolutions.com>
Hi Alberto,
> Chip Version is a string saved in BOOTROM address space Little Endian.
>
> Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030
> which brings: 320A20140813V200
>
> Note that memory version do invert MSB/LSB so printing the char
> buffer will show: A02341023180002V
>
> Signed-off-by: Alberto Panizzo <alberto@amarulasolutions.com>
> ---
> drivers/usb/gadget/f_rockusb.c | 38
> +++++++++++++++++++++++++++++++++++++- 1 file changed, 37
> insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/f_rockusb.c
> b/drivers/usb/gadget/f_rockusb.c index a39ad51..7612871 100644
> --- a/drivers/usb/gadget/f_rockusb.c
> +++ b/drivers/usb/gadget/f_rockusb.c
> @@ -532,6 +532,42 @@ static void cb_read_storage_id(struct usb_ep
> *ep, struct usb_request *req) CSW_GOOD);
> }
>
> +int __weak rk_get_bootrom_chip_version(unsigned int *chip_info, int
> size) +{
> + return 0;
> +}
> +
> +static void cb_get_chip_version(struct usb_ep *ep, struct
> usb_request *req) +{
> + ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
> + sizeof(struct fsg_bulk_cb_wrap));
> + unsigned int chip_info[4], i;
> +
> + memset(chip_info, 0, sizeof(chip_info));
> + rk_get_bootrom_chip_version(chip_info, 4);
> +
> + /*
> + * Chip Version is a string saved in BOOTROM address space
> Little Endian
> + *
> + * Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030
> + * which brings: 320A20140813V200
> + *
> + * Note that memory version do invert MSB/LSB so printing
> the char
> + * buffer will show: A02341023180002V
> + */
> + printf("read chip version: ");
> + for (i = 0; i < 16; i++) {
> + int shift = (3 - (i % 4)) * 8;
> +
> + printf("%c", (char)((chip_info[i / 4] >> shift) &
> 0xFF));
A lot of magic numbers. Just to ask - isn't this the same type of
conversion as we got with the network code?
Cannot we have simple macro (or static inline) with byte swap called
three times?
> + }
> + printf("\n");
> + memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
> + rockusb_tx_write((char *)chip_info, sizeof(chip_info));
^---- [1]
> + rockusb_tx_write_csw_on_complete(cbw->tag,
^-----[2]
> cbw->data_transfer_length,
> + CSW_GOOD);
Just to be sure if I understand the protocol -> you write the data in
[1]
And then immediately you prepare next block (structure) [2] to be
written back after receiving reply data from host?
Is this behaviour in sync with README in ./doc/README.rockusb ?
> +}
> +
> static void cb_write_lba(struct usb_ep *ep, struct usb_request *req)
> {
> ALLOC_CACHE_ALIGN_BUFFER(struct fsg_bulk_cb_wrap, cbw,
> @@ -670,7 +706,7 @@ static const struct cmd_dispatch_info
> cmd_dispatch_info[] = { },
> {
> .cmd = K_FW_GET_CHIP_VER,
> - .cb = cb_not_support,
> + .cb = cb_get_chip_version,
> },
> {
> .cmd = K_FW_LOW_FORMAT,
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180703/f2cb77ce/attachment.sig>
next prev parent reply other threads:[~2018-07-03 21:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-03 19:02 [U-Boot] [PATCH 0/7] Improve rockusb support in U-Boot Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 1/7] usb: rockchip: fix command failed on host side due to missing data Alberto Panizzo
2018-07-03 21:24 ` Lukasz Majewski
2018-07-04 10:11 ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 2/7] usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command Alberto Panizzo
2018-07-03 21:33 ` Lukasz Majewski [this message]
2018-07-04 13:27 ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 3/7] rockchip: rk3288: implement reading chip version from bootrom code Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 4/7] usb: rockchip: implement K_FW_LBA_READ_10 command Alberto Panizzo
2018-07-03 21:42 ` Lukasz Majewski
2018-07-04 13:36 ` Alberto Panizzo
2018-07-05 1:19 ` Kever Yang
2018-07-05 8:52 ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 5/7] usb: rockchip: implement K_FW_LBA_ERASE_10 command Alberto Panizzo
2018-07-03 21:47 ` Lukasz Majewski
2018-07-03 19:02 ` [U-Boot] [PATCH 6/7] usb: rockchip: be quiet on serial port while transferring data Alberto Panizzo
2018-07-03 21:49 ` Lukasz Majewski
2018-07-04 13:44 ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 7/7] usb: rockchip: boost up write speed from 4MB/s to 15MB/s Alberto Panizzo
2018-07-05 1:15 ` [U-Boot] [PATCH 0/7] Improve rockusb support in U-Boot Kever Yang
2018-07-05 8:39 ` Alberto Panizzo
2018-07-05 9:07 ` Lukasz Majewski
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=20180703233345.7ada995f@jawa \
--to=lukma@denx.de \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.