mandoc -T html default style
The diff inserts some space above the footer.
This improves readability and makes it similar to the other output formats.
Here is an example found in the wild, demonstrating the problem:
https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
Index: html.c
===
RCS file: /cvs/src/usr.bin/mandoc/html.c,v
retrieving revision 1.117
diff -u -p -u -p -r1.117 html.c
--- html.c 15 Dec 2018 23:33:20 - 1.117
+++ html.c 20 Dec 2018 13:38:14 -
@@ -183,6 +183,8 @@ print_gen_head(struct html *h)
t = print_otag(h, TAG_STYLE, "");
print_text(h, "table.head, table.foot { width: 100%; }");
print_endline(h);
+ print_text(h, "table.foot { margin-top: 3em; }");
+ print_endline(h);
print_text(h, "td.head-rtitle, td.foot-os { text-align: right; }");
print_endline(h);
print_text(h, "td.head-vol { text-align: center; }");
Re: mandoc -T html default style
Hi Ingo, On Thu, December 20, 2018 11:53 pm, Ingo Schwarze wrote: > Hi Ted, hi Raphael, > > Ted Unangst wrote on Thu, Dec 20, 2018 at 11:36:06AM -0500: >> Raphael Graf wrote: > >>> The diff inserts some space above the footer. >>> This improves readability and makes it similar to the other output formats. >>> >>> Here is an example found in the wild, demonstrating the problem: >>> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html > > How did that page get generated? By some Github automatic or > half-automatic infrastructure, and if so, how exactly? Or did the > maintainers of "webassembly" simply generate that file by hand? > Also, is that URI linked to from anywhere? It tried clicking around > the "webassembly" website, but failed to find any link to the URI > you cite. I guess the html-pages where generated and copied to the server by hand. It is the result of this pull request: https://github.com/WebAssembly/wabt/pull/979 There are links to these pages here: https://github.com/WebAssembly/wabt > >> So I think one answer to this problem is "use the provided mandoc.css". > > Absolutely. > > Or if it doesn't meet your needs exactly, edit it, then use your > edited version. > > Or if it doesn't meet your needs at all, write your own, using > mandoc.css as documenation of the available classes. > >> However, that's not the default. >> But perhaps it, or a variant of it, should be. > > I certainly love sensible defaults and hate the lack of them, > but in the past, i considered sensible defaults impossible > for "-O style=" because it is kind of hard to guess the file > system layout on the user's system, so we don't know which > absolute path to use in the line > . > Personally, I think having a minimal default inline stylesheet is not that bad. I like the fact that 'mandoc -T html' just works and produces a usable single file by default. (If there is inline css, it should be as minimal as possible because it should not change in the future. Old manpages would need to be regenerated otherwise.) > Let's try again. > What do you think about the following plan: > > 1. Let's install /var/www/htdocs/mandoc.css by default. > > 2. When calling "mandoc -T html" without specifying "-O style=", > fall back to "-O style=/var/www/htdocs/mandoc.css" by default. > That might be sensible because it is adequate for local > viewing of the file, which is likely intended with files > generated in such a manual way. > If the user then goes ahead and copies these files onto a > webserver, they of course cannot work because the document root > must be stripped from the "-O style=" argument in that case. > Also, if the user copies these files onto a non-OpenBSD system, > they stop working there, too. > > 3. To build HTML without any whatsoever, > require "-O style=" to be explicitly specified with an empty path. > > 4. Document all that in the mandoc(1) manual page below "HTML Output". > > 5. In man.cgi(8), we already use the equivalent > of "-O style=/mandoc.css" by default, unless CSS_DIR is > configured in cgi.h. That won't change. > >> I guess one objection to always using mandoc.css is that it's >> another file that may get lost. > > That's not really a counter-argument because nothing becomes worse. > Currently, by default, you never have a good stylesheet, and if you > configure one, it can already get lost, maybe even more easily > because it is not installed by default. With the above plan, you > get a working stylesheet by default for some simple cases, and you > can still build HTML files with a different one or even without any > if you want to. > > By the way, not that man.conf(5) already supports the > > output style /path/to/my.css > > directive. > >> And perhaps it's a touch too large to inline? > > Not a very convincing counter-argument either. If you use an > external stylesheet, which is almost always by far the most sensible > thing to do, nothing gets inlined in the first place. With the > above plan, in the unusual case that the user explicitly request > that no external stylesheet be used, inlining the whole thing is > still better than inlining something stunted, like we do now, i > think. Look at arbitrary websites nowdays: almost all serve > ridiculous amounts of boilerplate styling stuff. The size of > mandoc.css is really not a problem by comparision, and much less > for a corner case that isn't recommended anyway. >
mandoc -T html -O toc, nested anchor tags
The html output contains nested anchor tags if the TABLE OF CONTENTS
has a second level.
For example, see http://man.openbsd.org/mdoc
The diff closes the anchor tag before printing the 'ul' of the second level.
Index: mdoc_html.c
===
RCS file: /cvs/src/usr.bin/mandoc/mdoc_html.c,v
retrieving revision 1.193
diff -u -p -u -p -r1.193 mdoc_html.c
--- mdoc_html.c 15 Dec 2018 23:33:20 - 1.193
+++ mdoc_html.c 22 Dec 2018 14:26:09 -
@@ -507,7 +507,7 @@ static int
mdoc_sh_pre(MDOC_ARGS)
{
struct roff_node*sn, *subn;
- struct tag *t, *tsec, *tsub;
+ struct tag *t, *ta, *tsec, *tsub;
char*id;
int sc;
@@ -532,7 +532,7 @@ mdoc_sh_pre(MDOC_ARGS)
for (sn = n; sn != NULL; sn = sn->next) {
tsec = print_otag(h, TAG_LI, "");
id = html_make_id(sn->head, 0);
- print_otag(h, TAG_A, "hR", id);
+ ta = print_otag(h, TAG_A, "hR", id);
free(id);
print_mdoc_nodelist(meta, sn->head->child, h);
tsub = NULL;
@@ -543,9 +543,11 @@ mdoc_sh_pre(MDOC_ARGS)
id = html_make_id(subn->head, 0);
if (id == NULL)
continue;
- if (tsub == NULL)
+ if (tsub == NULL) {
+ print_tagq(h, ta);
print_otag(h, TAG_UL,
"c", "Bl-compact");
+ }
tsub = print_otag(h, TAG_LI, "");
print_otag(h, TAG_A, "hR", id);
free(id);
video(1) and modesetting driver
Here is an attempt to make video(1) work with the modesetting driver.
See https://marc.info/?l=openbsd-bugs&m=152231686416039&w=2
The general idea:
If there is no common encoding for input (device) and output (Xv), the
encoding is converted to something supported by the output.
No conversion is done if the output is sent to file (options -o/-O).
The option -e is now used as the input format. The output format
is selected automatically (if output goes to Xv).
The following encodings are supported: yuy2, yuyv, uyuy, yv12
yuy2 and yuyv are treated as two different encodings, they share the same
pixelformat, but have different ids. (This behaviour is different from the
current description of '-e' in the manpage)
I have tested on two lenovo laptops using both drivers (modesetting and intel).
On my laptop (lenovo X1 Carbon), with modesetting diver:
yuyv is converted to yv12 before sending to Xv.
On the same laptop With intel driver:
yuyv is converted to yuy2 (no-op)
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 video.c
--- video.c 4 Jan 2019 17:45:00 - 1.26
+++ video.c 16 Jan 2019 11:30:21 -
@@ -38,6 +38,8 @@
#include
#include
+#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
+
/* Xv(3) adaptor properties */
struct xv_adap {
char name[128];
@@ -133,20 +135,23 @@ struct dev {
/* video encodingss */
struct encodings {
char*name;
+ int id;
int bpp;
- int xv_id;
- int dev_id;
#defineSW_DEV 0x1
#defineSW_XV 0x2
#define SW_MASK(SW_DEV | SW_XV)
int flags;
} encs[] = {
#define ENC_YUY2 0
- { "yuy2", 16, -1, -1, 0 },
-#define ENC_UYVY 1
- { "uyvy", 16, -1, -1, 0 },
-#define ENC_LAST 2
- { NULL, 0, 0, 0, 0 }
+ { "yuy2", V_V4L2_PIX_FMT_YUY2, 16, 0 },
+#define ENC_YUYV 1
+ { "yuyv", V4L2_PIX_FMT_YUYV, 16, 0 },
+#define ENC_UYVY 2
+ { "uyvy", V4L2_PIX_FMT_UYVY, 16, 0 },
+#define ENC_YV12 3
+ { "yv12", V4L2_PIX_FMT_YVU420, 12, 0 },
+#define ENC_LAST 4
+ { NULL, 0, 0, 0 }
};
struct video {
@@ -163,8 +168,10 @@ struct video {
int iofile_fd;
char*sz_str;
#defineCONV_SWAP 0x1
+#defineCONV_YV12 0x2
int conv_type;
- int enc;
+ int enc_in;
+ int enc_out;
int full_screen;
int net_wm;
int width;
@@ -216,6 +223,7 @@ int stream(struct video *);
void got_frame(int);
void got_shutdown(int);
int find_enc(char *);
+int find_by_id(int);
void usage(void);
static volatile sig_atomic_t play, shutdown, hold, wout;
@@ -242,6 +250,17 @@ find_enc(char *name)
}
int
+find_enc_by_id(int id)
+{
+ int i;
+
+ for (i = 0; i < ENC_LAST; i++)
+ if (encs[i].id == id)
+ break;
+ return i;
+}
+
+int
xv_get_info(struct video *vid)
{
struct xdsp *x = &vid->xdsp;
@@ -251,7 +270,6 @@ xv_get_info(struct video *vid)
struct xv_adap *adap;
unsigned int nenc, p;
int num_xvformats, nadaps, i, j, ret;
- char fmtName[5];
if ((x->dpy = XOpenDisplay(NULL)) == NULL) {
warnx("cannot open display %s", XDisplayName(NULL));
@@ -312,16 +330,9 @@ xv_get_info(struct video *vid)
&num_xvformats);
adap->nfmts = 0;
for (j = 0; j < num_xvformats; j++) {
- snprintf(fmtName, sizeof(fmtName), "%c%c%c%c",
- xvformats[j].id & 0xff,
- (xvformats[j].id >> 8) & 0xff,
- (xvformats[j].id >> 16) & 0xff,
- (xvformats[j].id >> 24) & 0xff);
- if (!strcmp(fmtName, "YUY2")) {
- encs[ENC_YUY2].xv_id = xvformats[j].id;
- adap->fmts[adap->nfmts++] = xvformats[j].id;
- } else if (!strcmp(fmtName, "UYVY")) {
- encs[ENC_UYVY].xv_id = xvformats[j].id;
+ int enc = find_enc_by_id(xvformats[j].id);
+ if (enc < ENC_LAST) {
+ encs[enc].flags |= SW_XV;
adap->fmts[adap->nfmts++] = xvformats[j].id;
}
if (adap->nfmts >= MAX_FMTS)
@@ -369,20 +380,20 @@ xv_sel_adap(struct video *vid)
x->cur_adap = i;
adap = &x->adaps[i];
for (i = 0; i < adap->nfmts; i++) {
- if (adap->fmts[i] == encs[vid->enc].xv_id)
+ if (adap->fmts[i] == encs[vid->enc_out].id
Re: video(1) and modesetting driver
Hi Martin,
Thanks for your feedback!
On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> Hello Raphael,
>
> On 16/01/19(Wed) 12:41, Raphael Graf wrote:
> > Here is an attempt to make video(1) work with the modesetting driver.
> > See https://marc.info/?l=openbsd-bugs&m=152231686416039&w=2
> >
> > The general idea:
> > If there is no common encoding for input (device) and output (Xv), the
> > encoding is converted to something supported by the output.
> > No conversion is done if the output is sent to file (options -o/-O).
> >
> > The option -e is now used as the input format. The output format
> > is selected automatically (if output goes to Xv).
> >
> > The following encodings are supported: yuy2, yuyv, uyuy, yv12
>
> Did you test all of them?
Yes, I have tested all encodings with these two devices:
uvideo0 at uhub0 port 6 configuration 1 interface 0
"Chicony Electronics Co., Ltd. product 0x480c" rev 2.00/31.34 addr 2
uvideo0 at uhub1 port 8 configuration 1 interface 0 "SC20A38485AA4629RX
Integrated Camera" rev 2.00/0.21 addr 4
>
> > yuy2 and yuyv are treated as two different encodings, they share the same
> > pixelformat, but have different ids. (This behaviour is different from the
> > current description of '-e' in the manpage)
>
> What about fixing the manpage then? ;)
The new diff below contains the changes to the manpage.
>
> > I have tested on two lenovo laptops using both drivers (modesetting and
> > intel).
> >
> > On my laptop (lenovo X1 Carbon), with modesetting diver:
> > yuyv is converted to yv12 before sending to Xv.
> >
> > On the same laptop With intel driver:
> > yuyv is converted to yuy2 (no-op)
>
> Nice work, some comments below.
>
> Make sure the code you're writing follows style(9) :o)
>
> > Index: video.c
> > ===
> > RCS file: /cvs/xenocara/app/video/video.c,v
> > retrieving revision 1.26
> > diff -u -p -u -p -r1.26 video.c
> > --- video.c 4 Jan 2019 17:45:00 - 1.26
> > +++ video.c 16 Jan 2019 11:30:21 -
> > @@ -38,6 +38,8 @@
> > #include
> > #include
> >
> > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
>
> Why do we need this define and not the others? Aren't we missing an
> include?
Actually, I don't know why this define is missing in videoio.h.
This YUY2 format (id:0x32595559) is reported by Xv.
The uvideo(4) driver reports YUYV which has a define in videoio.h.
(YUY2 and YUYV are equivalent)
In the new diff, I have changed the variable names enc_in/enc_out to enc/enc_xv
as the second 'enc' is only used for Xv output.
I also fixed the style(9) issues and added a CONV_NONE define.
Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
correct in respect to color theory..
(It is a conversion from 16 to 12 bits/pixel)
Sorry, it is still a big diff, feedback is welcome.
Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 video.1
--- video.1 4 Jun 2016 07:44:32 - 1.13
+++ video.1 25 Jan 2019 09:51:12 -
@@ -84,18 +84,19 @@ The default is 0, the first adaptor repo
.It Fl e Ar encoding
Lowercase FOURCC name of video encoding to use.
Valid arguments are
+.Ql yuyv ,
+.Ql yuy2 ,
.Ql uyvy
and
-.Ql yuy2 .
+.Ql yv12 .
The default is
-.Ql yuy2
-unless
-.Ar file
-is being used and only supports
-.Ql uyvy ,
-in which case
-.Ql uyvy
-will be used by default.
+.Ql yuyv .
+If reading from a
+.Xr video 4
+device and
+.Ql yuyv
+is not supported, the default is
+.Ql uyvy .
.It Fl f Ar file
.Xr video 4
device from which frames will be read.
@@ -338,6 +339,6 @@ Note that with the first three commands,
does not support 640x480 pixels sized frames, the largest frame size
smaller than 640x480 will be used, and if
.Ar /dev/video
-does not support yuy2 encoding, uyvy will be used.
+does not support yuyv encoding, uyvy will be used.
.Sh SEE ALSO
.Xr video 4
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 video.c
--- video.c 22 Jan 2019 20:02:40 - 1.27
+++ video.c 25 Jan 2019 09:51:12 -
@@ -38,6 +38,8 @@
#include
#include
+#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
+
/* Xv(3) adaptor properties */
struct xv_adap {
char name[128];
@@ -133,20 +135,23 @@ struct dev {
/* video encodingss */
Re: video(1) and modesetting driver
On Fri, Jan 25, 2019 at 09:09:29AM -0200, Martin Pieuchot wrote:
> On 25/01/19(Fri) 11:16, Raphael Graf wrote:
> > On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > > Index: video.c
> > > > ===
> > > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 video.c
> > > > --- video.c 4 Jan 2019 17:45:00 - 1.26
> > > > +++ video.c 16 Jan 2019 11:30:21 -
> > > > @@ -38,6 +38,8 @@
> > > > #include
> > > > #include
> > > >
> > > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > >
> > > Why do we need this define and not the others? Aren't we missing an
> > > include?
> >
> > Actually, I don't know why this define is missing in videoio.h.
> > This YUY2 format (id:0x32595559) is reported by Xv.
> > The uvideo(4) driver reports YUYV which has a define in videoio.h.
> > (YUY2 and YUYV are equivalent)
>
> I see. I believe you're being too clever her. XvListImageFormats(3)
> returns you a list with an Id in FourCC format and you're using V4L2
> defines to match these IDs.
>
> I'd suggest you define only one encoding "yuy2" or "yuyv" and make the
> matching function, find_enc_by_id() a bit more clever. That would
> explicitly document that Xv and V4L2 use different names for the same
> format. On top of that you'll get rid of your conversion code :)
>
I actually tried to do this, but it's not trivial.
The current code had only one entry for yuy2/yuyv in 'encs[]' and handled the
situation by having xv_id and dev_id in 'struct encodings':
struct encodings {
char*name;
int bpp;
int xv_id;
int dev_id;
int flags;
}
But this approach does not work when 'bpp' changes for the output.
There is also the case of '-O' where output goes to 'Xv' and 'file'
simultanously, using different encodings for the two outputs.
When using the modesetting driver, Xv output needs yv12, and the file is
written in yuy2.
(It would be possible to add xv_bpp and dev_bpp to 'struct encodings', but this
would be a bit hacky, I think)
> > In the new diff, I have changed the variable names enc_in/enc_out to
> > enc/enc_xv
> > as the second 'enc' is only used for Xv output.
> > I also fixed the style(9) issues and added a CONV_NONE define.
>
> I find enc_in/enc_out more explicit, but let's keep it like that for
> now. This also makes the diff smaller :)
>
> > Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> > correct in respect to color theory..
> > (It is a conversion from 16 to 12 bits/pixel)
>
> I'm sure you can find some good documentation and/or example about that
> on the Web or in the existing freesoftware ecosystem.
I'll do some more research on this topic.
>
> > Index: video.1
> > ===
> > RCS file: /cvs/xenocara/app/video/video.1,v
> > retrieving revision 1.13
> > diff -u -p -u -p -r1.13 video.1
> > --- video.1 4 Jun 2016 07:44:32 - 1.13
> > +++ video.1 25 Jan 2019 09:51:12 -
> > @@ -84,18 +84,19 @@ The default is 0, the first adaptor repo
> > .It Fl e Ar encoding
> > Lowercase FOURCC name of video encoding to use.
> > Valid arguments are
> > +.Ql yuyv ,
> > +.Ql yuy2 ,
> > .Ql uyvy
> > and
> > -.Ql yuy2 .
> > +.Ql yv12 .
> > The default is
> > -.Ql yuy2
> > -unless
> > -.Ar file
> > -is being used and only supports
> > -.Ql uyvy ,
> > -in which case
> > -.Ql uyvy
> > -will be used by default.
> > +.Ql yuyv .
> > +If reading from a
> > +.Xr video 4
> > +device and
> > +.Ql yuyv
> > +is not supported, the default is
> > +.Ql uyvy .
> > .It Fl f Ar file
> > .Xr video 4
> > device from which frames will be read.
> > @@ -338,6 +339,6 @@ Note that with the first three commands,
> > does not support 640x480 pixels sized frames, the largest frame size
> > smaller than 640x480 will be used, and if
> > .Ar /dev/video
> > -does not support yuy2 encoding, uyvy will be used.
> > +does not support yuyv encoding, uyvy will be used.
> > .Sh SEE ALSO
> > .Xr video 4
> > Index: video.c
> >
Re: video(1) and modesetting driver
On Fri, Jan 25, 2019 at 12:52:38PM +0200, Artturi Alm wrote:
> On Fri, Jan 25, 2019 at 11:16:49AM +0100, Raphael Graf wrote:
> > Hi Martin,
> > Thanks for your feedback!
> >
> > On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > Hello Raphael,
> > >
> > > On 16/01/19(Wed) 12:41, Raphael Graf wrote:
> > > > Here is an attempt to make video(1) work with the modesetting driver.
> > > > See https://marc.info/?l=openbsd-bugs&m=152231686416039&w=2
> > > >
> > > > The general idea:
> > > > If there is no common encoding for input (device) and output (Xv), the
> > > > encoding is converted to something supported by the output.
> > > > No conversion is done if the output is sent to file (options -o/-O).
> > > >
> > > > The option -e is now used as the input format. The output format
> > > > is selected automatically (if output goes to Xv).
> > > >
> > > > The following encodings are supported: yuy2, yuyv, uyuy, yv12
> > >
> > > Did you test all of them?
> >
> > Yes, I have tested all encodings with these two devices:
> >
> > uvideo0 at uhub0 port 6 configuration 1 interface 0
> > "Chicony Electronics Co., Ltd. product 0x480c" rev 2.00/31.34 addr 2
> >
> > uvideo0 at uhub1 port 8 configuration 1 interface 0 "SC20A38485AA4629RX
> > Integrated Camera" rev 2.00/0.21 addr 4
> >
> > >
> > > > yuy2 and yuyv are treated as two different encodings, they share the
> > > > same
> > > > pixelformat, but have different ids. (This behaviour is different from
> > > > the
> > > > current description of '-e' in the manpage)
> > >
> > > What about fixing the manpage then? ;)
> >
> > The new diff below contains the changes to the manpage.
> >
> > >
> > > > I have tested on two lenovo laptops using both drivers (modesetting and
> > > > intel).
> > > >
> > > > On my laptop (lenovo X1 Carbon), with modesetting diver:
> > > > yuyv is converted to yv12 before sending to Xv.
> > > >
> > > > On the same laptop With intel driver:
> > > > yuyv is converted to yuy2 (no-op)
> > >
> > > Nice work, some comments below.
> > >
> > > Make sure the code you're writing follows style(9) :o)
> > >
> > > > Index: video.c
> > > > ===
> > > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 video.c
> > > > --- video.c 4 Jan 2019 17:45:00 - 1.26
> > > > +++ video.c 16 Jan 2019 11:30:21 -
> > > > @@ -38,6 +38,8 @@
> > > > #include
> > > > #include
> > > >
> > > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > >
> > > Why do we need this define and not the others? Aren't we missing an
> > > include?
> >
> > Actually, I don't know why this define is missing in videoio.h.
> > This YUY2 format (id:0x32595559) is reported by Xv.
> > The uvideo(4) driver reports YUYV which has a define in videoio.h.
> > (YUY2 and YUYV are equivalent)
> >
> > In the new diff, I have changed the variable names enc_in/enc_out to
> > enc/enc_xv
> > as the second 'enc' is only used for Xv output.
> > I also fixed the style(9) issues and added a CONV_NONE define.
> >
> > Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> > correct in respect to color theory..
> > (It is a conversion from 16 to 12 bits/pixel)
> >
> > Sorry, it is still a big diff, feedback is welcome.
> >
> >
>
> Hi,
>
> got one question below.
>
> -Artturi
>
> [...snip...]
>
> > @@ -1633,6 +1631,34 @@ got_shutdown(int s)
> > }
> >
> > int
> > +yuy2_to_yv12(uint8_t *src, uint8_t *dst, int width, int height)
> > +{
> > + int row, col, c, o;
> > + int iy = 0;
> > + int iu = width * height;
> > + int iv = iu + iu / 4;
> > +
> > + for (row = 0; row < height * 2; row += 2) {
> > + c = row * width;
> > + for (col = 0; col < width * 2 ; col += 4) {
> > + o = c + col;
> > + dst[iy++] = src[o];
> > + dst[iy++] = src[o + 2];
> > + if ((row & 0x03) == 0) {
> > + o++;
> > + dst[iv++] = (src[o] + src[o + width * 2]) / 2;
> > + o += 2;
> > + dst[iu++] = (src[o] + src[o + width * 2]) / 2;
> > + if (o + width * 2 >= iu*2)
> > + printf("hello\n");
>
> is that a placeholder for something relevant, or what does hello mean here?
Oups, sorry, can you ignore that for now? I'll remove this in the next
iteration.
>
> > + }
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +int
> > stream(struct video *vid)
> > {
> > struct xdsp *x = &vid->xdsp;
>
> [...snip...]
Re: pckbc(4) diff
On Mon, Jan 28, 2019 at 08:14:09PM +0100, Marcus Glocker wrote:
> On some machines when the pckbc(4) keyboard controller driver attaches
> to the console, it's possible to inject characters by moving your mouse
> in to the keyboard channel. When injecting enough noise the keyboard
> will stop operating at some point. A nice way to test this, e.g. on my
> ThinkPad, is by entering in to UKC at boot time and then move your
> mouse.
>
> This diff will discard characters coming from the aux slot which are
> mixed in to the keyboard slot when we're still in console mode.
>
> This issue has been reported by deraadt@ who already has OK'ed the diff.
>
> Comments? Testing? More OKs?
I can confirm this fixes the issue on a lenovo X1 Carbon.
>
> Thanks,
> Marcus
>
>
> Index: sys/dev/ic/pckbc.c
> ===
> RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
> retrieving revision 1.50
> diff -u -p -u -p -r1.50 pckbc.c
> --- sys/dev/ic/pckbc.c11 Mar 2017 11:55:03 - 1.50
> +++ sys/dev/ic/pckbc.c27 Jan 2019 09:01:31 -
> @@ -161,6 +161,9 @@ pckbc_poll_data1(bus_space_tag_t iot, bu
> if (slot == PCKBC_AUX_SLOT) {
> DPRINTF("lost kbd 0x%x\n", c);
> continue;
> + } else if (stat & KBS_AUXDATA) {
> + DPRINTF("discard aux data 0x%x\n", c);
> + continue;
> }
> }
> return (c);
>
Re: video(1) and modesetting driver
On Fri, Jan 25, 2019 at 09:09:29AM -0200, Martin Pieuchot wrote:
> On 25/01/19(Fri) 11:16, Raphael Graf wrote:
> > On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > > Index: video.c
> > > > ===
> > > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 video.c
> > > > --- video.c 4 Jan 2019 17:45:00 - 1.26
> > > > +++ video.c 16 Jan 2019 11:30:21 -
> > > > @@ -38,6 +38,8 @@
> > > > #include
> > > > #include
> > > >
> > > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > >
> > > Why do we need this define and not the others? Aren't we missing an
> > > include?
> >
> > Actually, I don't know why this define is missing in videoio.h.
> > This YUY2 format (id:0x32595559) is reported by Xv.
> > The uvideo(4) driver reports YUYV which has a define in videoio.h.
> > (YUY2 and YUYV are equivalent)
>
> I see. I believe you're being too clever her. XvListImageFormats(3)
> returns you a list with an Id in FourCC format and you're using V4L2
> defines to match these IDs.
>
> I'd suggest you define only one encoding "yuy2" or "yuyv" and make the
> matching function, find_enc_by_id() a bit more clever. That would
> explicitly document that Xv and V4L2 use different names for the same
> format. On top of that you'll get rid of your conversion code :)
>
The new diff below solves this yuy2/yuyv problem by defining them both under
the same name 'yuy2'.
The only change to the manpage is now the addition of yv12 to the list of
valid encodings.
The trickiest part is the 'choose_enc' function where encodings are chosen
based on device capabilities.
The following conversions are now possible:
yuy2 -> uyvy
yuy2 -> yv12
uyvy -> yuy2
uyvy -> yv12
As my webcam only provides yuy2, I have used input-files for testing:
$ video -i test.yuy2
$ video -i test.uyvy -e uyvy
$ video -i test.yv12 -e yv12
These examples work for me with both drivers (modesetting and intel).
The conversion to yv12 has a small performance impact, of course. Do you think
the performance is acceptable?
> > In the new diff, I have changed the variable names enc_in/enc_out to
> > enc/enc_xv
> > as the second 'enc' is only used for Xv output.
> > I also fixed the style(9) issues and added a CONV_NONE define.
>
> I find enc_in/enc_out more explicit, but let's keep it like that for
> now. This also makes the diff smaller :)
>
> > Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> > correct in respect to color theory..
> > (It is a conversion from 16 to 12 bits/pixel)
>
> I'm sure you can find some good documentation and/or example about that
> on the Web or in the existing freesoftware ecosystem.
>
Yes, there are libraries like 'libyuv' doing it in the same way.
(they also have optimized versions (SSE etc.))
Any comments, questions or feedback?
Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 video.1
--- video.1 4 Jun 2016 07:44:32 - 1.13
+++ video.1 7 Feb 2019 12:08:37 -
@@ -84,9 +84,10 @@ The default is 0, the first adaptor repo
.It Fl e Ar encoding
Lowercase FOURCC name of video encoding to use.
Valid arguments are
-.Ql uyvy
+.Ql uyvy ,
+.Ql yuy2
and
-.Ql yuy2 .
+.Ql yv12 .
The default is
.Ql yuy2
unless
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 video.c
--- video.c 22 Jan 2019 20:02:40 - 1.27
+++ video.c 7 Feb 2019 12:08:37 -
@@ -38,6 +38,9 @@
#include
#include
+/* Synonym for YUYV */
+#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
+
/* Xv(3) adaptor properties */
struct xv_adap {
char name[128];
@@ -133,20 +136,22 @@ struct dev {
/* video encodingss */
struct encodings {
char*name;
+ int id;
int bpp;
- int xv_id;
- int dev_id;
-#defineSW_DEV 0x1
-#defineSW_XV 0x2
-#define SW_MASK(SW_DEV | SW_XV)
+#defineSUP_DEV 0x1
+#defineSUP_XV 0x2
int flags;
} encs[] = {
+#define ENC_YUYV 1
+ { "yuy2", V4L2_PIX_FMT_YUYV, 16, 0 },
#define ENC_YUY2 0
-
Re: video(1) and modesetting driver
On Wed, Feb 13, 2019 at 04:09:10PM -0200, Martin Pieuchot wrote: > On 07/02/19(Thu) 13:52, Raphael Graf wrote: > > [...] > > The new diff below solves this yuy2/yuyv problem by defining them both under > > the same name 'yuy2'. > > That's great. I would just change the comment to explain that it's due > to an incoherency between the names reported by XvListImageFormats(3) and > V4L2 :) I'll do this when the general idea of the diff gets accepted.. > > > The only change to the manpage is now the addition of yv12 to the list of > > valid encodings. > > Fine, I just missed the point: why do we need to support yv12? The support for yv12 as an input encoding is actually a side effect of the implementation. Webcams (video(4)) do not provide yv12, but is now possible to read and display yv12 encoded files. > > > The trickiest part is the 'choose_enc' function where encodings are chosen > > based on device capabilities. > > The following conversions are now possible: > > yuy2 -> uyvy > > yuy2 -> yv12 > > uyvy -> yuy2 > > uyvy -> yv12 > > > > As my webcam only provides yuy2, I have used input-files for testing: > > $ video -i test.yuy2 > > $ video -i test.uyvy -e uyvy > > $ video -i test.yv12 -e yv12 > > > > These examples work for me with both drivers (modesetting and intel). > > The conversion to yv12 has a small performance impact, of course. Do you > > think > > the performance is acceptable? > > Do you think it is? When is the conversion needed? > Conversion to yv12 is needed when Xv does neither support yuy2 nor uyvy. This is the case when the modesetting driver is in use (see output of xvinfo). I think the performance is acceptable, it is hardly noticable on my laptops.
Re: run(4) firmware update; please test
On Thu, May 15, 2014 11:35 am, Stefan Sperling wrote: > This firmware update to version 0.33 is a prequisite for > newer run(4) devices which are not yet supported. > > Can active users of run(4) devices please test this update > to make sure no regressions are introduced for already working > devices? I don't have a supported run(4) device to test with. > This one keeps working as expected: run0 at uhub13 port 1 "Belkin Belkin Enhanced Wireless USB Adapter" rev 2.00/1.01 addr 2 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 00:22:75:f5:df:b8
Re: Patch: fix high capacity (> 2GB) eMMC support
On Sat, September 20, 2014 7:45 pm, Jonathan Gray wrote:
> On Sat, Sep 20, 2014 at 06:01:51PM +0200, Cédric Tessier wrote:
>> Hi,
>>
>> I've bought a BeagleBone Black rev. C board, and I was trying to install
>> OpenBSD on it, but the internal eMMC was causing errors.
>>
>> sdmmc1: unknown CARD_TYPE 0x17
>> scsibus1 at sdmmc1: 2 targets, initiator 0
>> sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed
>> sd1: 1024MB, 512 bytes/sector, 2097152 sectors
>>
>> Card type and sectors count were wrong, and accessing the device was
>> causing I/O errors.
>>
>> I've investigated the problem, and it looks like the support of
>> High Capacity eMMC (> 2GB) is missing.
>>
>> I've written a quick and dirty patch (tested on 5.5 and snapshot) which fix
>> all my issues.
>>
>> Modifications:
>> - mask reserved bits for card type value
>
> These bits do not appear to be reserved. In your case bit 4
> seems to indicate HS200/200 MHz clock capable.
>
> Bit 5 is HS400/400 MHz clock capable.
>
>> - read sectors count from EXT_CSD
>> - fix sectors count and enable SDHC if High Capacity eMMC is detected
>
> Is the old method of reading the block length still supported
> with emmc and csd ver > 2? That wasn't the case for normal sd card.
>
> It seems the emmc situation is a bit different as the capacity
> stored in a seperate place.
>
>> +
>> +if (ext_csd[EXT_CSD_REV] >= 2) {
>> +sectors = ext_csd[EXT_CSD_SEC_COUNT + 0] << 0 |
>> +ext_csd[EXT_CSD_SEC_COUNT + 1]
>> << 8 |
>> +ext_csd[EXT_CSD_SEC_COUNT + 2]
>> << 16 |
>> +ext_csd[EXT_CSD_SEC_COUNT + 3]
>> << 24;
>> +/*
>> + * High capacity MMC seems to report a "magic" 4096 *
>> 512 bytes
>> + * capacity in csd, but ext_csd contains the real
>> sectors count
>> + */
>> +if ((sf->csd.capacity == (4096 * 512)) &&
>> +(sectors > (2u * 1024 * 1024 * 1024) / 512)) {
>> +sf->flags |= SFF_SDHC;
>> +sf->csd.capacity = sectors;
>> +}
>
> I think this should change to
>
> if (sectors > (2u * 1024 * 1024 * 1024) / 512)
> sf->flags |= SFF_SDHC;
> sf->csd.capacity = sectors;
>
> All csd rev > 2 cards should report valid sectors in the extended space.
>
This seems not to be the case, the EXT_CSD_SEC_COUNT is only valid for
capacities over 2G. I'd use this field only if it's not zero, like freebsd does.
Instead of masking the EXT_CSD_CARD_TYPE field, it may be better to just check
for the relevant bits as in the diff below.
Does this still work for you, Cédric?
Index: sys/dev/sdmmc/sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.19
diff -u -p -r1.19 sdmmc_mem.c
--- sys/dev/sdmmc/sdmmc_mem.c 12 Jul 2014 18:48:52 - 1.19
+++ sys/dev/sdmmc/sdmmc_mem.c 21 Sep 2014 12:02:35 -
@@ -428,6 +428,7 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
u_int8_t ext_csd[512];
int speed = 0;
int hs_timing = 0;
+ u_int32_t sectors = 0;
if (sf->csd.mmcver >= MMC_CSD_MMCVER_4_0) {
/* read EXT_CSD */
@@ -439,18 +440,12 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
return error;
}
- switch (ext_csd[EXT_CSD_CARD_TYPE]) {
- case EXT_CSD_CARD_TYPE_26M:
- speed = 26000;
- break;
- case EXT_CSD_CARD_TYPE_52M:
- case EXT_CSD_CARD_TYPE_52M_V18:
- case EXT_CSD_CARD_TYPE_52M_V12:
- case EXT_CSD_CARD_TYPE_52M_V12_18:
+ if (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_52M) {
speed = 52000;
hs_timing = 1;
- break;
- default:
+ } else if (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_26M) {
+ speed = 26000;
+ } else {
printf("%s: unknown CARD_TYPE 0x%x\n", DEVNAME(sc),
ext_csd[EXT_CSD_CARD_TYPE]);
}
@@ -487,6 +482,16 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
printf("%s, HS_TIMING set failed\n",
DEVNAME(sc));
return EINVAL;
}
+ }
+
+ sectors = ext_csd[EXT_CSD_SEC_COUNT + 0] << 0 |
+ ext_csd[EXT_CSD_SEC_COUNT + 1] << 8 |
+ ext_csd[EXT_CSD_SEC_COUNT + 2] << 16 |
+ ext_csd[EXT_CSD_SEC_COUNT + 3] << 24;
+
+ if (sectors != 0) {
+ sf->fl
Re: Patch: fix high capacity (> 2GB) eMMC support
On Sun, September 21, 2014 2:09 pm, Raphael Graf wrote:
> On Sat, September 20, 2014 7:45 pm, Jonathan Gray wrote:
>> On Sat, Sep 20, 2014 at 06:01:51PM +0200, Cédric Tessier wrote:
>>> Hi,
>>>
>>> I've bought a BeagleBone Black rev. C board, and I was trying to install
>>> OpenBSD on it, but the internal eMMC was causing errors.
>>>
>>> sdmmc1: unknown CARD_TYPE 0x17
>>> scsibus1 at sdmmc1: 2 targets, initiator 0
>>> sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed
>>> sd1: 1024MB, 512 bytes/sector, 2097152 sectors
>>>
>>> Card type and sectors count were wrong, and accessing the device was
>>> causing I/O errors.
>>>
>>> I've investigated the problem, and it looks like the support of
>>> High Capacity eMMC (> 2GB) is missing.
>>>
>>> I've written a quick and dirty patch (tested on 5.5 and snapshot) which fix
>>> all my issues.
>>>
>>> Modifications:
>>> - mask reserved bits for card type value
>>
>> These bits do not appear to be reserved. In your case bit 4
>> seems to indicate HS200/200 MHz clock capable.
>>
>> Bit 5 is HS400/400 MHz clock capable.
>>
>>> - read sectors count from EXT_CSD
>>> - fix sectors count and enable SDHC if High Capacity eMMC is detected
>>
>> Is the old method of reading the block length still supported
>> with emmc and csd ver > 2? That wasn't the case for normal sd card.
>>
>> It seems the emmc situation is a bit different as the capacity
>> stored in a seperate place.
>>
>>> +
>>> + if (ext_csd[EXT_CSD_REV] >= 2) {
>>> + sectors = ext_csd[EXT_CSD_SEC_COUNT + 0] << 0 |
>>> + ext_csd[EXT_CSD_SEC_COUNT + 1]
>>> << 8 |
>>> + ext_csd[EXT_CSD_SEC_COUNT + 2]
>>> << 16 |
>>> + ext_csd[EXT_CSD_SEC_COUNT + 3]
>>> << 24;
>>> + /*
>>> +* High capacity MMC seems to report a "magic" 4096 *
>>> 512 bytes
>>> +* capacity in csd, but ext_csd contains the real
>>> sectors count
>>> +*/
>>> + if ((sf->csd.capacity == (4096 * 512)) &&
>>> + (sectors > (2u * 1024 * 1024 * 1024) / 512)) {
>>> + sf->flags |= SFF_SDHC;
>>> + sf->csd.capacity = sectors;
>>> + }
>>
>> I think this should change to
>>
>> if (sectors > (2u * 1024 * 1024 * 1024) / 512)
>> sf->flags |= SFF_SDHC;
>> sf->csd.capacity = sectors;
>>
>> All csd rev > 2 cards should report valid sectors in the extended space.
>>
>
> This seems not to be the case, the EXT_CSD_SEC_COUNT is only valid for
> capacities over 2G. I'd use this field only if it's not zero, like freebsd
> does.
>
> Instead of masking the EXT_CSD_CARD_TYPE field, it may be better to just check
> for the relevant bits as in the diff below.
>
> Does this still work for you, Cédric?
>
>
> Index: sys/dev/sdmmc/sdmmc_mem.c
> ===
> RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 sdmmc_mem.c
> --- sys/dev/sdmmc/sdmmc_mem.c 12 Jul 2014 18:48:52 - 1.19
> +++ sys/dev/sdmmc/sdmmc_mem.c 21 Sep 2014 12:02:35 -
> @@ -428,6 +428,7 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
> u_int8_t ext_csd[512];
> int speed = 0;
> int hs_timing = 0;
> + u_int32_t sectors = 0;
>
> if (sf->csd.mmcver >= MMC_CSD_MMCVER_4_0) {
> /* read EXT_CSD */
> @@ -439,18 +440,12 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
> return error;
> }
>
> - switch (ext_csd[EXT_CSD_CARD_TYPE]) {
> - case EXT_CSD_CARD_TYPE_26M:
> - speed = 26000;
> - break;
> - case EXT_CSD_CARD_TYPE_52M:
> - case EXT_CSD_CARD_TYPE_52M_V18:
> - case EXT_CSD_CARD_TYPE_52M_V12:
> - case EXT_CSD_CARD_TYPE_52M_V12_18:
> + if (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_52M) {
> speed = 52000;
>
Re: armv7: banana pi, Allwinner A20 board
On Thu, October 16, 2014 11:40 pm, Patrick Wildt wrote:
> I do believe that this is a pmap issue.
>
> I just got hands on an Allwinner A20 and suffered the same issues:
> pool_setlowat crashing randomly, same for ahci and so on.
>
> I believe we are not syncing the PTEs correctly.
>
> Here?s the snippet from PTE_SYNC(), but PTE_SYNC_RANGE() has
> the same issue:
>
> #define PTE_SYNC(pte)
> \
> do { \
> if (PMAP_NEEDS_PTE_SYNC) { \
> paddr_t pa; \
> cpu_drain_writebuf(); \
> cpu_dcache_wb_range((vaddr_t)(pte), sizeof(pt_entry_t));\
> if (cpu_sdcache_enabled()) {\
> (void)pmap_extract(pmap_kernel(), (vaddr_t)(pte), &pa); \
> cpu_sdcache_wb_range((vaddr_t)(pte), (paddr_t)(pa), \
> sizeof(pt_entry_t));\
> }; \
> cpu_drain_writebuf(); \
> } \
> } while (/*CONSTCOND*/0)
>
> I believe that when we change things in the pagetables, we need to make
> sure the tables are synced before we?re going to use them. In our case
> we believe that we are using uncached pagetables, which means that
> every write will directly hit the tables.
>
> But that does not have an affect on the write buffer. The write buffer is
> still
> there and has to be cleared manually. If it isn?t, and something accesses
> an area which was just mapped, then we?re fucked.
>
> Therefore I firmly believe that the cpu_drain_writebuf() call has to be made
> regardless of PMAP_NEEDS_PTE_SYNC and that it has to be called before
> that if-clause.
>
> Doing that fixes my issues.
>
> \Patrick
>
I think this is correct. With the diff below, my A20 board doesn't panic
anymore.
I still get a lot of messages like the following though:
pmap_fault_fixup: va 8000 ftype 1 u pte 7f24f02e
Index: sys/arch/arm/include/pmap.h
===
RCS file: /cvs/src/sys/arch/arm/include/pmap.h,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 pmap.h
--- sys/arch/arm/include/pmap.h 7 Oct 2014 10:10:58 - 1.27
+++ sys/arch/arm/include/pmap.h 20 Oct 2014 09:33:14 -
@@ -328,9 +328,9 @@ extern int pmap_needs_pte_sync;
#definePTE_SYNC(pte)
\
do { \
+ cpu_drain_writebuf(); \
if (PMAP_NEEDS_PTE_SYNC) { \
paddr_t pa; \
- cpu_drain_writebuf(); \
cpu_dcache_wb_range((vaddr_t)(pte), sizeof(pt_entry_t));\
if (cpu_sdcache_enabled()) {\
(void)pmap_extract(pmap_kernel(), (vaddr_t)(pte), &pa); \
@@ -343,9 +343,9 @@ do {
\
#definePTE_SYNC_RANGE(pte, cnt)
\
do { \
+ cpu_drain_writebuf(); \
if (PMAP_NEEDS_PTE_SYNC) { \
paddr_t pa; \
- cpu_drain_writebuf(); \
cpu_dcache_wb_range((vaddr_t)(pte), \
(cnt) << 2); /* * sizeof(pt_entry_t) */ \
if (cpu_sdcache_enabled()) {\
azalia acer quirks
Without this diff, I just get silence from an Acer Extensa 6700. I don't know if this is the right way to fix it.. Comments? Index: sys/dev/pci/azalia_codec.c === RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v retrieving revision 1.154 diff -u -p -u -p -r1.154 azalia_codec.c --- sys/dev/pci/azalia_codec.c 27 May 2013 21:19:31 - 1.154 +++ sys/dev/pci/azalia_codec.c 14 Sep 2013 10:41:31 - @@ -74,6 +74,8 @@ azalia_codec_init_vtbl(codec_t *this) break; case 0x10ec0260: this->name = "Realtek ALC260"; + if (this->subid == 0x008f1025) + this->qrks |= AZ_QRK_GPIO_UNMUTE_0; break; case 0x10ec0262: this->name = "Realtek ALC262"; azalia0 at pci0 dev 27 function 0 "Intel 82801FB HD Audio" rev 0x04: msi azalia0: codecs: Realtek ALC260, Conexant/0x2bfa, using Realtek ALC260 audio0 at azalia0 Domain /dev/pci0: 0:0:0: Intel 82915GM Host 0x: Vendor ID: 8086 Product ID: 2590 0x0004: Command: 0106 Status: 2090 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1025 Product ID: 008f 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel 82915GM Video 0x: Vendor ID: 8086 Product ID: 2592 0x0004: Command: 0007 Status: 0090 0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xb008/0x0008 0x0014: BAR io addr: 0x1800/0x0008 0x0018: BAR mem prefetchable 32bit addr: 0xc000/0x1000 0x001c: BAR mem 32bit addr: 0xb000/0x0004 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1025 Product ID: 008f 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00 0x00d0: Capability 0x01: Power Management 0:2:1: Intel 82915GM Video 0x: Vendor ID: 8086 Product ID: 2792 0x0004: Command: Status: 0090 0x0008: Class: 03 Subclass: 80 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0x/0x0008 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1025 Product ID: 008f 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00d0: Capability 0x01: Power Management 0:27:0: Intel 82801FB HD Audio 0x: Vendor ID: 8086 Product ID: 2668 0x0004: Command: 0006 Status: 0010 0x0008: Class: 04 Subclass: 03 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xd000c000/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1025 Product ID: 008f 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 00 Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management 0x0060: Capability 0x05: Message Signaled Interrupts (MSI) 0x0070: Capability 0x10: PCI Express 0:28:0: Intel 82801FB PCIE 0x: Vendor ID: 8086 Product ID: 2660 0x0004: Command: Status: 0010 0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 04 0x000c: BIST: 00 Header Type: 81 Latency Timer: 00 Cache Line Size: 08 0x0010: 0x0014: 0x0018: Primary Bus: 0 Secondary Bus: 9 Subordinate Bus: 9 Secondary Latency Timer: 00 0x001c: I/O Base: 00 I/O Limit: 00 Secondary Status: 2000 0x0020: Memory Base: fff0 Memory Limit: 0x0024: Prefetch Memory Base: fff1 Prefetch Memory Limit: 0001 0x0028: Prefetch Memory Base Upper 3
Re: Update the sdmmmc stack to take care of the SMC_CAPS_SINGLE_ONLY capability
On Fri, October 18, 2013 9:54 am, Sylvestre Gallon wrote:
> Hi tech@
>
> Here is a diff to allow the sdmmc SMC_CAPS_SINGLE_ONLY caps to do
> something. The bits I take are from NetBSD and it works well with
> ommmc(4) on my Beagle Bone Black.
>
> This capability force the sdmmc stack to only issue single blocks
> transfers. It is usefull for debug purpose and/or for broken sdmmmc
> controller.
>
> Any OK/Comments ?
This looks good to me. I have tested it with ommmc(4), if needed I can
test with pxammc(4) next week.
>
> Cheers,
>
> Index: sdmmc_mem.c
> ===
> RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
> retrieving revision 1.17
> diff -u -p -u -p -r1.17 sdmmc_mem.c
> --- sdmmc_mem.c 12 Sep 2013 11:54:04 - 1.17
> +++ sdmmc_mem.c 18 Oct 2013 09:31:15 -
> @@ -42,6 +42,14 @@ intsdmmc_mem_mmc_switch(struct sdmmc_fu
>
> int sdmmc_mem_sd_init(struct sdmmc_softc *, struct sdmmc_function *);
> int sdmmc_mem_mmc_init(struct sdmmc_softc *, struct sdmmc_function *);
> +int sdmmc_mem_single_read_block(struct sdmmc_function *, int, u_char *,
> + size_t);
> +int sdmmc_mem_read_block_subr(struct sdmmc_function *, int, u_char *,
> + size_t);
> +int sdmmc_mem_single_write_block(struct sdmmc_function *, int, u_char *,
> + size_t);
> +int sdmmc_mem_write_block_subr(struct sdmmc_function *, int, u_char *,
> + size_t);
>
> #ifdef SDMMC_DEBUG
> #define DPRINTF(s) printf s
> @@ -551,14 +559,13 @@ sdmmc_mem_set_blocklen(struct sdmmc_soft
> }
>
> int
> -sdmmc_mem_read_block(struct sdmmc_function *sf, int blkno, u_char *data,
> +sdmmc_mem_read_block_subr(struct sdmmc_function *sf, int blkno, u_char *data,
> size_t datalen)
> {
> struct sdmmc_softc *sc = sf->sc;
> struct sdmmc_command cmd;
> int error;
>
> - rw_enter_write(&sc->sc_lock);
>
> if ((error = sdmmc_select_card(sc, sf)) != 0)
> goto err;
> @@ -602,20 +609,53 @@ sdmmc_mem_read_block(struct sdmmc_functi
> } while (!ISSET(MMC_R1(cmd.c_resp), MMC_R1_READY_FOR_DATA));
>
> err:
> - rw_exit(&sc->sc_lock);
> - return error;
> + return (error);
> }
>
> int
> -sdmmc_mem_write_block(struct sdmmc_function *sf, int blkno, u_char *data,
> +sdmmc_mem_single_read_block(struct sdmmc_function *sf, int blkno, u_char
> *data,
> +size_t datalen)
> +{
> + int error;
> + int i;
> +
> + for (i = 0; i < datalen / sf->csd.sector_size; i++) {
> + error = sdmmc_mem_read_block_subr(sf, blkno + i, data + i *
> + sf->csd.sector_size, sf->csd.sector_size);
> + if (error)
> + break;
> + }
> +
> + return (error);
> +}
> +
> +int
> +sdmmc_mem_read_block(struct sdmmc_function *sf, int blkno, u_char *data,
> size_t datalen)
> {
> struct sdmmc_softc *sc = sf->sc;
> - struct sdmmc_command cmd;
> int error;
>
> rw_enter_write(&sc->sc_lock);
>
> + if (ISSET(sc->sc_caps, SMC_CAPS_SINGLE_ONLY)) {
> + error = sdmmc_mem_single_read_block(sf, blkno, data, datalen);
> + } else {
> + error = sdmmc_mem_read_block_subr(sf, blkno, data, datalen);
> + }
> +
> + rw_exit(&sc->sc_lock);
> + return (error);
> +}
> +
> +int
> +sdmmc_mem_write_block_subr(struct sdmmc_function *sf, int blkno, u_char
> *data,
> +size_t datalen)
> +{
> + struct sdmmc_softc *sc = sf->sc;
> + struct sdmmc_command cmd;
> + int error;
> +
> if ((error = sdmmc_select_card(sc, sf)) != 0)
> goto err;
>
> @@ -657,6 +697,41 @@ sdmmc_mem_write_block(struct sdmmc_funct
> } while (!ISSET(MMC_R1(cmd.c_resp), MMC_R1_READY_FOR_DATA));
>
> err:
> + return (error);
> +}
> +
> +int
> +sdmmc_mem_single_write_block(struct sdmmc_function *sf, int blkno, u_char
> *data,
> +size_t datalen)
> +{
> + int error;
> + int i;
> +
> + for (i = 0; i < datalen / sf->csd.sector_size; i++) {
> + error = sdmmc_mem_write_block_subr(sf, blkno + i, data + i *
> + sf->csd.sector_size, sf->csd.sector_size);
> + if (error)
> + break;
> + }
> +
> + return (error);
> +}
> +
> +int
> +sdmmc_mem_write_block(struct sdmmc_function *sf, int blkno, u_char *data,
> +size_t datalen)
> +{
> + struct sdmmc_softc *sc = sf->sc;
> + int error;
> +
> + rw_enter_write(&sc->sc_lock);
> +
> + if (ISSET(sc->sc_caps, SMC_CAPS_SINGLE_ONLY)) {
> + error = sdmmc_mem_single_write_block(sf, blkno, data, datalen);
> + } else {
> + error = sdmmc_mem_write_block_subr(sf, blkno, data, datalen);
> + }
> +
> rw_exit(&sc->sc_lock);
> - return error;
> + return (error);
> }
>
>
Re: Update the sdmmmc stack to take care of the SMC_CAPS_SINGLE_ONLY capability
On Tue, October 22, 2013 12:10 pm, Sylvestre Gallon wrote: > On Sat, Oct 19, 2013 at 1:51 PM, Raphael Graf wrote: >> On Fri, October 18, 2013 9:54 am, Sylvestre Gallon wrote: >>> Hi tech@ >>> >>> Here is a diff to allow the sdmmc SMC_CAPS_SINGLE_ONLY caps to do >>> something. The bits I take are from NetBSD and it works well with >>> ommmc(4) on my Beagle Bone Black. >>> >>> This capability force the sdmmc stack to only issue single blocks >>> transfers. It is usefull for debug purpose and/or for broken sdmmmc >>> controller. >>> >>> Any OK/Comments ? >> >> This looks good to me. I have tested it with ommmc(4), if needed I can >> test with pxammc(4) next week. >> > > If you can give it a try with pxammc(4) it would be awesome :) It seems to work fine with pxammc(4) on zaurus sl-c3000.
beaglebone JTAG (FT2232H)
The diff below makes the jtag and serial interfaces of the beaglebone (FT2232H)
work simultaneously.
This is how the beaglebone shows up:
uhub8 at uhub0 port 1 "Standard Microsystems product 0x2412" rev 2.00/b.b2 addr
3
uftdi0 at uhub8 port 1 configuration 1 interface 1 "FTDI BeagleBone/XDS100V2"
rev 2.00/7.00 addr 4
ucom0 at uftdi0 portno 2
ugen0 at uhub8 port 1 configuration 1 "FTDI BeagleBone/XDS100V2" rev 2.00/7.00
addr 4
Like this, openocd (using ugen) and cu both work.
It is just assumed that interface 0 is used for jtag, not sure if this is
always true. I'm also unsure if the diff would break other devices.
Can someone comment on this?
Thanks
Index: uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- uftdi.c 11 Sep 2012 16:04:44 - 1.63
+++ uftdi.c 27 Jan 2013 13:20:53 -
@@ -748,28 +748,21 @@ int
uftdi_match(struct device *parent, void *match, void *aux)
{
struct usb_attach_arg *uaa = aux;
- usbd_status err;
u_int8_t nifaces;
if (usb_lookup(uftdi_devs, uaa->vendor, uaa->product) == NULL)
return (UMATCH_NONE);
/* Get the number of interfaces. */
- if (uaa->iface != NULL) {
+ if (uaa->iface != NULL)
nifaces = uaa->nifaces;
- } else {
- err = usbd_set_config_index(uaa->device, UFTDI_CONFIG_INDEX, 1);
- if (err)
- return (UMATCH_NONE);
- err = usbd_interface_count(uaa->device, &nifaces);
- if (err)
- return (UMATCH_NONE);
- usbd_set_config_index(uaa->device, USB_UNCONFIG_INDEX, 1);
- }
+ else
+ return UMATCH_NONE;
/* JTAG on USB interface 0 */
if (uaa->vendor == USB_VENDOR_FTDI &&
- uaa->product == USB_PRODUCT_FTDI_OPENRD &&
+ (uaa->product == USB_PRODUCT_FTDI_OPENRD ||
+ uaa->product == USB_PRODUCT_FTDI_SERIAL_2232C) &&
uaa->ifaceno == 0)
return (UMATCH_NONE);
Re: beaglebone JTAG (FT2232H)
On Mon, January 28, 2013 11:29 am, Stuart Henderson wrote:
> Have you checked if this is still necessary? libusb on OpenBSD is now able to
> talk to devices claimed by drivers other than ugen.
Yes, I suspect it is still necessary to use ugen.
It seems like libusb does not support bulk transfers otherwise.
uhub8 at uhub0 port 1 "Standard Microsystems product 0x2412" rev 2.00/b.b2 addr
3
uftdi0 at uhub8 port 1 configuration 1 interface 0 "FTDI BeagleBone/XDS100V2"
rev 2.00/7.00 addr 4
ucom0 at uftdi0 portno 1
uftdi1 at uhub8 port 1 configuration 1 interface 1 "FTDI BeagleBone/XDS100V2"
rev 2.00/7.00 addr 4
ucom1 at uftdi1 portno 2
$ openocd -f /usr/local/share/openocd/scripts/board/ti_beaglebone.cfg
Open On-Chip Debugger 0.6.1 (2013-01-29-22:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 16000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Warn : unable to open ftdi device (trying more): device not found
Error: ftdi_write_data: usb bulk write failed
Error: couldn't initialize data bits low byte
Error: couldn't initialize FT2232 with 'xds100v2' layout
in procedure 'init'
>
>
> Raphael Graf wrote:
>
>>The diff below makes the jtag and serial interfaces of the beaglebone
>>(FT2232H)
>>work simultaneously.
>>This is how the beaglebone shows up:
>>
>>uhub8 at uhub0 port 1 "Standard Microsystems product 0x2412" rev
>>2.00/b.b2 addr 3
>>uftdi0 at uhub8 port 1 configuration 1 interface 1 "FTDI
>>BeagleBone/XDS100V2" rev 2.00/7.00 addr 4
>>ucom0 at uftdi0 portno 2
>>ugen0 at uhub8 port 1 configuration 1 "FTDI BeagleBone/XDS100V2" rev
>>2.00/7.00 addr 4
>>
>>Like this, openocd (using ugen) and cu both work.
>>
>>It is just assumed that interface 0 is used for jtag, not sure if this
>>is
>>always true. I'm also unsure if the diff would break other devices.
>>Can someone comment on this?
>>
>>Thanks
>>
>>
>>Index: uftdi.c
>>===
>>RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
>>retrieving revision 1.63
>>diff -u -p -r1.63 uftdi.c
>>--- uftdi.c 11 Sep 2012 16:04:44 - 1.63
>>+++ uftdi.c 27 Jan 2013 13:20:53 -
>>@@ -748,28 +748,21 @@ int
>> uftdi_match(struct device *parent, void *match, void *aux)
>> {
>> struct usb_attach_arg *uaa = aux;
>>- usbd_status err;
>> u_int8_t nifaces;
>>
>> if (usb_lookup(uftdi_devs, uaa->vendor, uaa->product) == NULL)
>> return (UMATCH_NONE);
>>
>> /* Get the number of interfaces. */
>>- if (uaa->iface != NULL) {
>>+ if (uaa->iface != NULL)
>> nifaces = uaa->nifaces;
>>- } else {
>>- err = usbd_set_config_index(uaa->device, UFTDI_CONFIG_INDEX, 1);
>>- if (err)
>>- return (UMATCH_NONE);
>>- err = usbd_interface_count(uaa->device, &nifaces);
>>- if (err)
>>- return (UMATCH_NONE);
>>- usbd_set_config_index(uaa->device, USB_UNCONFIG_INDEX, 1);
>>- }
>>+ else
>>+ return UMATCH_NONE;
>>
>> /* JTAG on USB interface 0 */
>> if (uaa->vendor == USB_VENDOR_FTDI &&
>>- uaa->product == USB_PRODUCT_FTDI_OPENRD &&
>>+ (uaa->product == USB_PRODUCT_FTDI_OPENRD ||
>>+ uaa->product == USB_PRODUCT_FTDI_SERIAL_2232C) &&
>> uaa->ifaceno == 0)
>> return (UMATCH_NONE);
>
>
Re: beaglebone JTAG (FT2232H)
On Thu, January 31, 2013 10:31 am, Martin Pieuchot wrote:
> On 30/01/13(Wed) 13:19, Raphael Graf wrote:
>> On Wed, January 30, 2013 10:52 am, Martin Pieuchot wrote:
>> > On 27/01/13(Sun) 16:13, Raphael Graf wrote:
>> >> The diff below makes the jtag and serial interfaces of the beaglebone
>> >> (FT2232H)
>> >> work simultaneously.
>> >> This is how the beaglebone shows up:
>> >>
>> >> uhub8 at uhub0 port 1 "Standard Microsystems product 0x2412" rev
>> >> 2.00/b.b2 addr 3
>> >> uftdi0 at uhub8 port 1 configuration 1 interface 1 "FTDI
>> >> BeagleBone/XDS100V2" rev 2.00/7.00 addr 4
>> >> ucom0 at uftdi0 portno 2
>> >> ugen0 at uhub8 port 1 configuration 1 "FTDI BeagleBone/XDS100V2" rev
>> >> 2.00/7.00 addr 4
>> >>
>> >> Like this, openocd (using ugen) and cu both work.
>> >>
>> >> It is just assumed that interface 0 is used for jtag, not sure if this is
>> >> always true. I'm also unsure if the diff would break other devices.
>> >> Can someone comment on this?
>> >
>> > Your diff looks correct and after looking at how the USB drivers are
>> > matched it seems obvious to me that changing the configuration in this
>> > function is not the right thing to do.
>> >
>> > I just rewrote your diff to keep only one (iface == NULL) check, I think
>> > it is clearer like that. Are you ok with this version?
>>
>> Yes, thanks.
>> Could you take a quick look at the uftdi_attach function?
>> I think some 'if (uaa->iface == NULL)' code could be removed there.
>
> Right, here's an updated diff, is it still ok for you?
Yes, i've tested it again with the beaglebone.
Thanks!
r
>
> M.
>
> Index: uftdi.c
> ===
> RCS file: /home/ncvs/src/sys/dev/usb/uftdi.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 uftdi.c
> --- uftdi.c 11 Sep 2012 16:04:44 - 1.63
> +++ uftdi.c 31 Jan 2013 08:59:50 -
> @@ -748,39 +748,29 @@ int
> uftdi_match(struct device *parent, void *match, void *aux)
> {
> struct usb_attach_arg *uaa = aux;
> - usbd_status err;
> - u_int8_t nifaces;
>
> - if (usb_lookup(uftdi_devs, uaa->vendor, uaa->product) == NULL)
> + /*
> + * Only match when looping against interfaces to allow ugen(4)
> + * to take over the interface 0, JTAG on USB, on some models.
> + */
> + if (uaa->iface == NULL)
> return (UMATCH_NONE);
>
> - /* Get the number of interfaces. */
> - if (uaa->iface != NULL) {
> - nifaces = uaa->nifaces;
> - } else {
> - err = usbd_set_config_index(uaa->device, UFTDI_CONFIG_INDEX, 1);
> - if (err)
> - return (UMATCH_NONE);
> - err = usbd_interface_count(uaa->device, &nifaces);
> - if (err)
> - return (UMATCH_NONE);
> - usbd_set_config_index(uaa->device, USB_UNCONFIG_INDEX, 1);
> - }
> + if (usb_lookup(uftdi_devs, uaa->vendor, uaa->product) == NULL)
> + return (UMATCH_NONE);
>
> /* JTAG on USB interface 0 */
> if (uaa->vendor == USB_VENDOR_FTDI &&
> - uaa->product == USB_PRODUCT_FTDI_OPENRD &&
> + (uaa->product == USB_PRODUCT_FTDI_OPENRD ||
> + uaa->product == USB_PRODUCT_FTDI_SERIAL_2232C) &&
> uaa->ifaceno == 0)
> return (UMATCH_NONE);
>
> - if (nifaces <= 1)
> + if (uaa->nifaces <= 1)
> return (UMATCH_VENDOR_PRODUCT);
>
> /* Dual UART chip */
> - if (uaa->iface != NULL)
> - return (UMATCH_VENDOR_IFACESUBCLASS);
> - else
> - return (UMATCH_NONE);
> + return (UMATCH_VENDOR_IFACESUBCLASS);
> }
>
> void
> @@ -789,34 +779,15 @@ uftdi_attach(struct device *parent, stru
> struct uftdi_softc *sc = (struct uftdi_softc *)self;
> struct usb_attach_arg *uaa = aux;
> usbd_device_handle dev = uaa->device;
> - usbd_interface_handle iface;
> + usbd_interface_handle iface = uaa->iface;
> usb_interface_descriptor_t *id;
> usb_endpoint_descriptor_t *ed;
> char *devname = sc->sc_dev.dv_xname;
> int i;
> - usbd_status err;
> struct ucom_attach_args uca;
>
> DPRINTFN(10,("\nuftdi_attach: sc=%p\n", sc));
>
> - if (uaa->iface == NULL) {
> -
beaglebone
I have a beaglebone (AM3359) running OpenBSD, see below. Is there any interest in such code? OpenBSD/beagle booting ... arg0 0x0 arg1 0xe05 arg2 0x8100 atag core flags 0 pagesize 0 rootdev 0 atag mem start 0x8000 size 0x1000 atag cmdline [sd0] bootfile: sd0 bootargs: memory size derived from u-boot bootconf.mem[0].address = 8000 pages 65536/0x1000 Allocating page tables freestart = 0x00621000, free_pages = 530911 (0x000819df) IRQ stack: p0x81fd1000 v0xc1fd1000 ABT stack: p0x81fd v0xc1fd UND stack: p0x81fcf000 v0xc1fcf000 SVC stack: p0x81fcd000 v0xc1fcd000 Creating L1 page table at 0x81ffc000 Mapping kernel Constructing L2 page tables undefined page pmap [ no symbol table formats found ] board type: beaglebone Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.3-current (GENERIC) #0: Thu Apr 25 10:51:58 MDT 2013 r...@noname.my.domain:/usr/src/sys/arch/beagle/compile/GENERIC real mem = 268435456 (256MB) avail mem = 255819776 (243MB) mainbus0 at root cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache omap0 at mainbus0: BeagleBone prcm0 at omap0 rev 0.2 intc0 at omap0 rev 5.0 dmtimer0 at omap0 rev 0.1 dmtimer1 at omap0 rev 0.1 omdog0 at omap0 rev 0.1 ommmc0 at omap0 rev 3.1 sdmmc0 at ommmc0 com0 at omap0: ti16750, 64 byte fifo com0: console /dev/ksyms: Symbol table not valid. scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: SCSI2 0/direct fixed sd0: 7580MB, 512 bytes/sector, 15523840 sectors vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets boot device: sd0 root on sd0a (2579d6d61b20ccb7.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! Automatic boot in progress: starting file system checks. /dev/rsd0a: file system is clean; not checking setting tty flags pf enabled ddb.console: 0 -> 1 starting network starting early daemons: syslogd pflogd. starting RPC daemons:. savecore: no core dump checking quotas: done. kvm_mkdb: can't open /dev/ksyms clearing /tmp starting pre-securelevel daemons:. setting kernel security level: kern.securelevel: 0 -> 1 creating runtime link editor directory cache. preserving editor files. starting network daemons: sshd sendmail inetd sndiod. starting local daemons: cron. Thu Apr 25 11:02:09 MDT 2013 OpenBSD/beagle (noname.my.domain) (console) login:
Re: beaglebone
On Thu, April 25, 2013 7:30 pm, Alexey E. Suslikov wrote:
> Raphael Graf undefined.ch> writes:
>
>> I have a beaglebone (AM3359) running OpenBSD, see below.
>> Is there any interest in such code?
>
> Diffs are interesting. Teasers are not.
>
So here's what I have at the moment.
Some parts are just horrible hacks (notably the prcm stuff), beware.
I'll start sending (smaller) diffs when ready.
Index: beagle/beagle_machdep.c
===
RCS file: /cvs/src/sys/arch/beagle/beagle/beagle_machdep.c,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 beagle_machdep.c
--- beagle/beagle_machdep.c 30 Aug 2012 15:51:13 - 1.15
+++ beagle/beagle_machdep.c 26 Apr 2013 14:43:24 -
@@ -882,6 +882,9 @@ initarm(void *arg0, void *arg1, void *ar
case BOARD_ID_OMAP3_BEAGLE:
printf("board type: beagle\n");
break;
+ case BOARD_ID_AM335X_BEAGLEBONE:
+ printf("board type: beaglebone\n");
+ break;
case BOARD_ID_OMAP3_OVERO:
printf("board type: overo\n");
break;
@@ -979,6 +982,9 @@ consinit(void)
case BOARD_ID_OMAP3_BEAGLE:
case BOARD_ID_OMAP3_OVERO:
paddr = 0x4902;
+ break;
+ case BOARD_ID_AM335X_BEAGLEBONE:
+ paddr = 0x44E09000; /* UART0 */
break;
case BOARD_ID_OMAP4_PANDA:
paddr = 0x4802;
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/beagle/conf/GENERIC,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 GENERIC
--- conf/GENERIC27 Sep 2012 14:01:35 - 1.14
+++ conf/GENERIC26 Apr 2013 14:43:24 -
@@ -68,6 +68,7 @@ prcm* at soc? # power/clock controlle
omdog* at soc? # watchdog timer
omgpio*at soc? # user-visible GPIO pins?
gptimer* at soc? # general purpose timers
+dmtimer* at soc? # general purpose timers
ommmc* at soc? # SD/MMC card controller
omusbtll* at soc?
Index: conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/beagle/conf/RAMDISK,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 RAMDISK
--- conf/RAMDISK27 Sep 2012 14:01:35 - 1.16
+++ conf/RAMDISK26 Apr 2013 14:43:24 -
@@ -73,6 +73,7 @@ prcm* at soc? # power/clock controlle
omdog* at soc? # watchdog timer
omgpio*at soc? # user-visible GPIO pins?
gptimer* at soc? # general purpose timers
+dmtimer* at soc? # general purpose timers
ommmc* at soc? # SD/MMC card controller
omusbtll* at soc?
Index: conf/files.beagle
===
RCS file: /cvs/src/sys/arch/beagle/conf/files.beagle,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 files.beagle
--- conf/files.beagle 27 Mar 2013 17:33:13 - 1.12
+++ conf/files.beagle 26 Apr 2013 14:43:24 -
@@ -31,6 +31,7 @@ attach omap at mainbus
file arch/beagle/dev/omap.c omap
file arch/beagle/dev/omap3.c omap
file arch/beagle/dev/omap4.c omap
+file arch/beagle/dev/am335x.comap
# cortex based peripherals
device ampintc
@@ -62,6 +63,10 @@ file arch/beagle/dev/intc.c intc
device gptimer
attach gptimer at soc
file arch/beagle/dev/gptimer.c gptimer
+
+device dmtimer
+attach dmtimer at soc
+file arch/beagle/dev/dmtimer.c dmtimer
device omdog
attach omdog at soc
Index: dev/am335x.c
===
RCS file: dev/am335x.c
diff -N dev/am335x.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/am335x.c26 Apr 2013 14:43:24 -
@@ -0,0 +1,161 @@
+/* $OpenBSD: omap3.c,v 1.4 2011/11/10 23:43:01 uwe Exp $ */
+
+/*
+ * Copyright (c) 2011 Uwe Stuehler
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONN
FTDI FT2232H
This adds support for the FT2232H and FT4232H serial adapters.
(FT2232H found on the BeagleBone).
These devices have a 120MHz base clock for the baud rate generator
and need a different encoding for the baud rate divisor.
The values for ibufsize/obufsize are now taken from the endpoint descriptors.
I can't be sure that this does not break anything. It would have to be
tested on various devices.
Regards
Raphael
Index: sys/dev/usb/uftdireg.h
===
RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
retrieving revision 1.12
diff -u -p -r1.12 uftdireg.h
--- sys/dev/usb/uftdireg.h 5 Jul 2008 14:41:28 - 1.12
+++ sys/dev/usb/uftdireg.h 8 Sep 2012 14:32:13 -
@@ -35,7 +35,8 @@
enum uftdi_type {
UFTDI_TYPE_SIO,
- UFTDI_TYPE_8U232AM
+ UFTDI_TYPE_8U232AM,
+ UFTDI_TYPE_2232H
};
/*
@@ -91,7 +92,8 @@ enum {
ftdi_sio_b115200 = 9
};
-#define FTDI_8U232AM_FREQ 300
+#define FTDI_8U232AM_FREQ 300 /* (48MHz / 16) */
+#define FTDI_2232H_FREQ 1200 /* (120MHz / 10) */
/* Bounds for normal divisors as 4-bit fixed precision ints. */
#define FTDI_8U232AM_MIN_DIV 0x20
Index: sys/dev/usb/uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.62
diff -u -p -r1.62 uftdi.c
--- sys/dev/usb/uftdi.c 28 Oct 2011 01:45:55 - 1.62
+++ sys/dev/usb/uftdi.c 8 Sep 2012 14:32:14 -
@@ -105,6 +105,7 @@ voiduftdi_write(void *sc, int portno, u
u_int32_t *count);
void uftdi_break(void *sc, int portno, int onoff);
intuftdi_8u232am_getrate(speed_t speed, int *rate);
+intuftdi_2232h_getrate(speed_t speed, int *rate);
struct ucom_methods uftdi_methods = {
uftdi_get_status,
@@ -824,6 +825,9 @@ uftdi_attach(struct device *parent, stru
if (uaa->release < 0x0200) {
sc->sc_type = UFTDI_TYPE_SIO;
sc->sc_hdrlen = 1;
+ } else if (uaa->release == 0x0700 || uaa->release == 0x0800) {
+ sc->sc_type = UFTDI_TYPE_2232H;
+ sc->sc_hdrlen = 0;
} else {
sc->sc_type = UFTDI_TYPE_8U232AM;
sc->sc_hdrlen = 0;
@@ -842,11 +846,16 @@ uftdi_attach(struct device *parent, stru
addr = ed->bEndpointAddress;
dir = UE_GET_DIR(ed->bEndpointAddress);
attr = ed->bmAttributes & UE_XFERTYPE;
- if (dir == UE_DIR_IN && attr == UE_BULK)
+ if (dir == UE_DIR_IN && attr == UE_BULK) {
uca.bulkin = addr;
- else if (dir == UE_DIR_OUT && attr == UE_BULK)
+ uca.ibufsize = (UGETW(ed->wMaxPacketSize) > 0) ?
+ UGETW(ed->wMaxPacketSize) : UFTDIIBUFSIZE;
+ } else if (dir == UE_DIR_OUT && attr == UE_BULK) {
uca.bulkout = addr;
- else {
+ uca.obufsize = (UGETW(ed->wMaxPacketSize) > 0) ?
+ UGETW(ed->wMaxPacketSize) : UFTDIOBUFSIZE;
+ uca.obufsize-= sc->sc_hdrlen;
+ } else {
printf("%s: unexpected endpoint\n", devname);
goto bad;
}
@@ -867,9 +876,7 @@ uftdi_attach(struct device *parent, stru
else
uca.portno = FTDI_PIT_SIOA + id->bInterfaceNumber;
/* bulkin, bulkout set above */
- uca.ibufsize = UFTDIIBUFSIZE;
- uca.obufsize = UFTDIOBUFSIZE - sc->sc_hdrlen;
- uca.ibufsizepad = UFTDIIBUFSIZE;
+ uca.ibufsizepad = uca.ibufsize;
uca.opkthdrlen = sc->sc_hdrlen;
uca.device = dev;
uca.iface = iface;
@@ -1076,11 +1083,15 @@ uftdi_param(void *vsc, int portno, struc
if (uftdi_8u232am_getrate(t->c_ospeed, &rate) == -1)
return (EINVAL);
break;
+ case UFTDI_TYPE_2232H:
+ if (uftdi_2232h_getrate(t->c_ospeed, &rate) == -1)
+return (EINVAL);
+ break;
}
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = FTDI_SIO_SET_BAUD_RATE;
USETW(req.wValue, rate);
- USETW(req.wIndex, portno);
+ USETW(req.wIndex, ((rate >> 8) & 0xFF00) | portno);
USETW(req.wLength, 0);
DPRINTFN(2,("uftdi_param: reqtype=0x%02x req=0x%02x value=0x%04x "
"index=0x%04x len=%d\n", req.bmRequestType, req.bRequest,
@@ -1249,4 +1260,34 @@ uftdi_8u232am_getrate(speed_t speed, int
done:
*rate = result;
return (0);
+}
+
+int
+uftdi_2232h_getrate(speed_t speed, int *rate)
+{
+ char sub[8] = {0, 3, 2, 4, 1, 5, 6, 7};
+ int n = (FTDI_2232H_FREQ << 3) / speed;
+ int s = n & 7;
+ int result = (n >> 3) | (sub[s] << 14);
+ int resultspeed, accuracy;
+
+ /* Special cases */
+ if (result ==
uftdi baud rates
This diff is about the baud rate divisor calculation.
The driver should now support the full range of possible baud rates for
FT232BM and later devices.
(The calculation is described in the document "AN_120 Aliasing VCP
Baud Rates" from ftdi.)
Index: sys/dev/usb/uftdireg.h
===
RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
retrieving revision 1.13
diff -u -p -r1.13 uftdireg.h
--- sys/dev/usb/uftdireg.h 11 Sep 2012 16:04:44 - 1.13
+++ sys/dev/usb/uftdireg.h 20 Sep 2012 21:42:51 -
@@ -36,6 +36,7 @@
enum uftdi_type {
UFTDI_TYPE_SIO,
UFTDI_TYPE_8U232AM,
+ UFTDI_TYPE_232BM,
UFTDI_TYPE_2232H
};
Index: sys/dev/usb/uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- sys/dev/usb/uftdi.c 11 Sep 2012 16:04:44 - 1.63
+++ sys/dev/usb/uftdi.c 20 Sep 2012 21:42:52 -
@@ -105,7 +105,7 @@ voiduftdi_write(void *sc, int portno, u
u_int32_t *count);
void uftdi_break(void *sc, int portno, int onoff);
intuftdi_8u232am_getrate(speed_t speed, int *rate);
-intuftdi_2232h_getrate(speed_t speed, int *rate);
+intuftdi_232bm_getrate(speed_t speed, int freq, int *rate);
struct ucom_methods uftdi_methods = {
uftdi_get_status,
@@ -821,17 +821,19 @@ uftdi_attach(struct device *parent, stru
sc->sc_udev = dev;
sc->sc_iface = iface;
+ sc->sc_hdrlen = 0;
if (uaa->release < 0x0200) {
sc->sc_type = UFTDI_TYPE_SIO;
sc->sc_hdrlen = 1;
- } else if (uaa->release == 0x0700 || uaa->release == 0x0800) {
+ } else if (uaa->release < 0x0500)
+ sc->sc_type = UFTDI_TYPE_8U232AM;
+ else if (uaa->release < 0x0700)
+ sc->sc_type = UFTDI_TYPE_232BM;
+ else if (uaa->release < 0x0A00)
sc->sc_type = UFTDI_TYPE_2232H;
- sc->sc_hdrlen = 0;
- } else {
+ else
sc->sc_type = UFTDI_TYPE_8U232AM;
- sc->sc_hdrlen = 0;
- }
uca.bulkin = uca.bulkout = -1;
for (i = 0; i < id->bNumEndpoints; i++) {
@@ -1083,9 +1085,19 @@ uftdi_param(void *vsc, int portno, struc
if (uftdi_8u232am_getrate(t->c_ospeed, &rate) == -1)
return (EINVAL);
break;
+ case UFTDI_TYPE_232BM:
+ if (uftdi_232bm_getrate(t->c_ospeed, FTDI_8U232AM_FREQ, &rate)
== -1)
+ return (EINVAL);
case UFTDI_TYPE_2232H:
- if (uftdi_2232h_getrate(t->c_ospeed, &rate) == -1)
-return (EINVAL);
+ if (t->c_ospeed <= FTDI_8U232AM_FREQ) {
+ if (uftdi_232bm_getrate(t->c_ospeed, FTDI_8U232AM_FREQ,
&rate) == -1)
+ return (EINVAL);
+ } else {
+ if (uftdi_232bm_getrate(t->c_ospeed, FTDI_2232H_FREQ,
&rate) == -1)
+ return (EINVAL);
+ /* Set this bit to turn off a divide by 2.5 */
+ rate|= 0x0002;
+ }
break;
}
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
@@ -1263,31 +1275,37 @@ done:
}
int
-uftdi_2232h_getrate(speed_t speed, int *rate)
+uftdi_232bm_getrate(speed_t speed, int freq, int *rate)
{
char sub[8] = {0, 3, 2, 4, 1, 5, 6, 7};
- int n = (FTDI_2232H_FREQ << 3) / speed;
+ int n = ((freq << 3) + (speed >> 1)) / speed;
int s = n & 7;
- int result = (n >> 3) | (sub[s] << 14);
+ int resultint = (n >> 3);
+ int result = resultint | (sub[s] << 14);
int resultspeed, accuracy;
/* Special cases */
- if (result == 1)
- result = 0;
- else if (result == 0x4001)
+ if (resultint == 0 || resultint > 16384)
+ return -1;
+ else if (speed > 200 * 97 / 100 && speed < 200 * 103 / 100) {
result = 1;
+ goto done;
+ }
+ else if (resultint == 1) {
+ result = 0;
+ s = 0;
+ }
/* Check if resulting baud rate is within 3%. */
- if (result == 0)
+ if (resultint == 0)
goto done;
- resultspeed = (FTDI_2232H_FREQ << 3) /
- (((result & 0x3FFF) << 3) | s);
+ resultspeed = (freq << 3) /
+ ((resultint << 3) | s);
accuracy = (abs(speed - resultspeed) * 100) / speed;
- if (accuracy > 3)
+ if (accuracy >= 3)
return -1;
done:
- result|= 0x0002; /* Set this bit to turn off a divide by 2.5 */
*rate = result;
return 0;
}
