Re: recent rasops commits vs. macppc
Hi, On 2019/08/05 1:29, Michael wrote: On Sun, 4 Aug 2019 11:29:58 +0900 Rin Okuyama wrote: ... I probably found the cause of failure; new rasops allocates buffer and stamp dynamically via kmem_alloc. This may not work in early stages during boot. That would do it - macppc sets up a rasops console *very* early during kernel startup, before uvm is completely initialized. That's why there is a RI_NO_AUTO flag to instruct rasops not to auto-generate line drawing characters ( for fonts that don't have them ), which requires allocating memory. Thank you for your explanation on early console of macppc. Now, I almost believe that the patch should resolve the problem. I will commit it if it actually works for you. On 2019/08/05 15:20, Michael wrote:> On Sun, 4 Aug 2019 10:00:49 -0700 Jason Thorpe wrote: On Aug 4, 2019, at 9:29 AM, Michael wrote: Yeah, I look to forward to playing with it :-). I have a few of them, there are a few quirks you may run into. If you have questions don't hesitate to ask! Make sure you have a good, strong putty knife. Or something equivalent, and several of them. I opened one of mine with a bunch of hair pins, which wasn't fun. Trust me, if your Mini doesn't come with 1GB of RAM, you *will* want to upgrade it ( pretty much any PC2700 or 3200 DDR1 1GB DIMM will do, they can be found for about $20 or less on ebay ). For a small macppc box they can be surprisingly speedy - a 1.5GHz 7447 is nothing to sneeze at ( of course there are faster 32bit macs available, but they're also much more expensive ) - but modern compilers like gcc 7 or clang will eat up a lot of memory, like up to 1GB per compiler instance. Same with the internal disk - IIRC the biggest disk Apple ever shipped in a G4 Mini was 80GB, and the lower end models had 40GB ones. There are bigger and faster options available for not much money. Also, thank you for your advices. It helps me a lot. Although the original owner says it has 1GB memory, I'd like to replace its HDD with SSD by using, probably, an mSATA-IDE converter; after crashing several cards, I don't trust CF or SD card so much ;-). Thanks, rin
Re: recent rasops commits vs. macppc
Hello, On Sun, 4 Aug 2019 10:00:49 -0700 Jason Thorpe wrote: > > On Aug 4, 2019, at 9:29 AM, Michael wrote: > > > >> Yeah, I look to forward to playing with it :-). > > > > I have a few of them, there are a few quirks you may run into. If you > > have questions don't hesitate to ask! > > Make sure you have a good, strong putty knife. Or something equivalent, and several of them. I opened one of mine with a bunch of hair pins, which wasn't fun. Trust me, if your Mini doesn't come with 1GB of RAM, you *will* want to upgrade it ( pretty much any PC2700 or 3200 DDR1 1GB DIMM will do, they can be found for about $20 or less on ebay ). For a small macppc box they can be surprisingly speedy - a 1.5GHz 7447 is nothing to sneeze at ( of course there are faster 32bit macs available, but they're also much more expensive ) - but modern compilers like gcc 7 or clang will eat up a lot of memory, like up to 1GB per compiler instance. Same with the internal disk - IIRC the biggest disk Apple ever shipped in a G4 Mini was 80GB, and the lower end models had 40GB ones. There are bigger and faster options available for not much money. have fun Michael
Re: recent rasops commits vs. macppc
> On Aug 4, 2019, at 9:29 AM, Michael wrote: > >> Yeah, I look to forward to playing with it :-). > > I have a few of them, there are a few quirks you may run into. If you > have questions don't hesitate to ask! Make sure you have a good, strong putty knife. -- thorpej
Re: recent rasops commits vs. macppc
Hello, On Sun, 4 Aug 2019 11:29:58 +0900 Rin Okuyama wrote: > Hi, > > On 2019/08/04 1:00, Michael wrote: > > On Sat, 3 Aug 2019 14:46:32 +0900 > > Rin Okuyama wrote: > > > >> Maybe it's time to remove all non-32bit access to fb. > >> I expect it is not a very hard work for now ;-). > > > > I seriously doubt that's the problem, because: > > - 32bit powerpc doesn't really do 64bit accesses ( unlike sparc for > >example ) and altivec is disabled for kernel code ( since gcc started > >using altivec for optimized, inlined memcpy ) > > - at least one of the putchar_aa() methods used memcpy() in order to > >speed things up by rendering scanlines into cached memory and then > >quickly copying them into slow & uncached video memory, which worked > >just fine everywhere I tried ( that is, mips, powerpc, sparc, sparc64 > >and arm ) > > Thank you for your suggestive comments! > > I probably found the cause of failure; new rasops allocates buffer and > stamp dynamically via kmem_alloc. This may not work in early stages > during boot. That would do it - macppc sets up a rasops console *very* early during kernel startup, before uvm is completely initialized. That's why there is a RI_NO_AUTO flag to instruct rasops not to auto-generate line drawing characters ( for fonts that don't have them ), which requires allocating memory. > I removed dynamical allocations. Could you please test the attached patch? I will, thanks for working on this! > >> PS > >> I ordered Mac Mini G4, although serial console is hopeless... > > > > They're nice little machines which usually don't cause much trouble. > > Opening them is quite painful though. > > Yeah, I look to forward to playing with it :-). I have a few of them, there are a few quirks you may run into. If you have questions don't hesitate to ask! have fun Michael
Re: recent rasops commits vs. macppc
Hi,
On 2019/08/04 1:00, Michael wrote:
On Sat, 3 Aug 2019 14:46:32 +0900
Rin Okuyama wrote:
Maybe it's time to remove all non-32bit access to fb.
I expect it is not a very hard work for now ;-).
I seriously doubt that's the problem, because:
- 32bit powerpc doesn't really do 64bit accesses ( unlike sparc for
example ) and altivec is disabled for kernel code ( since gcc started
using altivec for optimized, inlined memcpy )
- at least one of the putchar_aa() methods used memcpy() in order to
speed things up by rendering scanlines into cached memory and then
quickly copying them into slow & uncached video memory, which worked
just fine everywhere I tried ( that is, mips, powerpc, sparc, sparc64
and arm )
Thank you for your suggestive comments!
I probably found the cause of failure; new rasops allocates buffer and
stamp dynamically via kmem_alloc. This may not work in early stages
during boot.
I removed dynamical allocations. Could you please test the attached patch?
PS
I ordered Mac Mini G4, although serial console is hopeless...
They're nice little machines which usually don't cause much trouble.
Opening them is quite painful though.
Yeah, I look to forward to playing with it :-).
Thanks,
rin
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvsroot/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.108
diff -p -u -r1.108 rasops.c
--- sys/dev/rasops/rasops.c 2 Aug 2019 23:24:37 - 1.108
+++ sys/dev/rasops/rasops.c 4 Aug 2019 02:19:31 -
@@ -50,6 +50,7 @@ __KERNEL_RCSID(0, "$NetBSD: rasops.c,v 1
#define_RASOPS_PRIVATE
#include
+#include/* XXX for MBE */
#ifndef _KERNEL
#include
@@ -69,6 +70,16 @@ struct rasops_matchdata {
int ident;
};
+static const uint32_t rasops_lmask32[4 + 1] = {
+ MBE(0x), MBE(0x00ff), MBE(0x), MBE(0x00ff),
+ MBE(0x),
+};
+
+static const uint32_t rasops_rmask32[4 + 1] = {
+ MBE(0x), MBE(0xff00), MBE(0x), MBE(0xff00),
+ MBE(0x),
+};
+
/* ANSI colormap (R,G,B). Upper 8 are high-intensity */
const uint8_t rasops_cmap[256 * 3] = {
0x00, 0x00, 0x00, /* black */
@@ -429,7 +440,7 @@ rasops_reconfig(struct rasops_info *ri,
/* Clear the entire display */
if ((ri->ri_flg & RI_CLEAR) != 0)
- memset(ri->ri_bits, 0, ri->ri_stride * ri->ri_height);
+ rasops_memset32(ri->ri_bits, 0, ri->ri_stride * ri->ri_height);
/* Now centre our window if needs be */
if ((ri->ri_flg & RI_CENTER) != 0) {
@@ -495,21 +506,6 @@ rasops_reconfig(struct rasops_info *ri,
WSSCREEN_WSCOLORS | WSSCREEN_REVERSE;
}
- if (ri->ri_buf != NULL) {
- kmem_free(ri->ri_buf, ri->ri_buflen);
- ri->ri_buf = NULL;
- }
- len = (ri->ri_flg & RI_FULLCLEAR) ? ri->ri_stride : ri->ri_emustride;
- ri->ri_buflen = len;
- ri->ri_buf = kmem_alloc(len, KM_SLEEP);
-
-#ifndef RASOPS_SMALL
- if (ri->ri_stamp != NULL) {
- kmem_free(ri->ri_stamp, ri->ri_stamp_len);
- ri->ri_stamp = NULL;
- }
-#endif
-
switch (ri->ri_depth) {
#if NRASOPS1 > 0
case 1:
@@ -980,9 +976,8 @@ void
rasops_eraserows(void *cookie, int row, int num, long attr)
{
struct rasops_info *ri = (struct rasops_info *)cookie;
- uint32_t *buf = (uint32_t *)ri->ri_buf;
uint32_t *rp, *hp, clr;
- int stride, cnt;
+ int stride;
hp = NULL; /* XXX GCC */
@@ -1021,13 +1016,10 @@ rasops_eraserows(void *cookie, int row,
hp = (uint32_t *)(ri->ri_hwbits + row * ri->ri_yscale);
}
- for (cnt = 0; cnt < stride >> 2; cnt++)
- buf[cnt] = clr;
-
while (num--) {
- memcpy(rp, buf, stride);
+ rasops_memset32(rp, clr, stride);
if (ri->ri_hwbits) {
- memcpy(hp, buf, stride);
+ memcpy(hp, rp, stride);
DELTA(hp, ri->ri_stride, uint32_t *);
}
DELTA(rp, ri->ri_stride, uint32_t *);
@@ -1042,9 +1034,8 @@ static void
rasops_do_cursor(struct rasops_info *ri)
{
int full, height, cnt, slop1, slop2, row, col;
- uint32_t tmp32, msk1, msk2;
- uint8_t tmp8;
- uint8_t *dp, *rp, *hp;
+ uint32_t mask1, mask2, *dp;
+ uint8_t tmp8, *rp, *hp;
hp = NULL; /* XXX GCC */
@@ -1108,28 +1099,24 @@ rasops_do_cursor(struct rasops_info *ri)
rp = (uint8_t *)((uintptr_t)rp & ~3);
hp = (uint8_t *)((uintptr_t)hp & ~3);
- msk1 = !slop1 ? 0 : be32toh(0xU >> (32 - (8 * slop1)));
- msk2 = !slop2 ? 0 : be32toh(0xU << (32 - (8 * slop2)));
+ mask1 = rasops_lmask32[4 - slop1];
+ mask2 = rasops_rmask32[slop2];
while
Re: recent rasops commits vs. macppc
Hello, On Sat, 3 Aug 2019 14:46:32 +0900 Rin Okuyama wrote: > Maybe it's time to remove all non-32bit access to fb. > I expect it is not a very hard work for now ;-). I seriously doubt that's the problem, because: - 32bit powerpc doesn't really do 64bit accesses ( unlike sparc for example ) and altivec is disabled for kernel code ( since gcc started using altivec for optimized, inlined memcpy ) - at least one of the putchar_aa() methods used memcpy() in order to speed things up by rendering scanlines into cached memory and then quickly copying them into slow & uncached video memory, which worked just fine everywhere I tried ( that is, mips, powerpc, sparc, sparc64 and arm ) > PS > I ordered Mac Mini G4, although serial console is hopeless... They're nice little machines which usually don't cause much trouble. Opening them is quite painful though. have fun Michael
Re: recent rasops commits vs. macppc
Hi,
Could you try the attached patch? It replaces memcpy into 32-bit-wise
copy, at least for 8-bpp framebuffer with 8, 12, or 16-width font.
Thanks,
rin
On 2019/08/03 10:05, Michael wrote:
Hello,
On Sat, 3 Aug 2019 08:58:02 +0900
Rin Okuyama wrote:
Hi Michael,
I'm so sorry for the breakage. I'll investigate it.
Font width is 8?
Doesn't seem to matter, the G5 used Gallant 12x22, the others used an 8
pixels wide font. Colour depth is always 8 though.
PS
I decided to buy my own macppc machine. Could anyone
recommend me a model of
- serial console capable
- newer and smaller as possible
G4 and models don't really have serial ports anymore, unfortunately,
although many can be fitted with a serial port instead of a modem as a
3rd party option.
have fun
Michael
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvsroot/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.108
diff -p -u -r1.108 rasops.c
--- sys/dev/rasops/rasops.c 2 Aug 2019 23:24:37 - 1.108
+++ sys/dev/rasops/rasops.c 3 Aug 2019 14:40:45 -
@@ -50,6 +50,7 @@ __KERNEL_RCSID(0, "$NetBSD: rasops.c,v 1
#define_RASOPS_PRIVATE
#include
+#include/* XXX for MBE */
#ifndef _KERNEL
#include
@@ -69,6 +70,23 @@ struct rasops_matchdata {
int ident;
};
+const uint32_t rasops_lmask32[4 + 1] = {
+ MBE(0x), MBE(0x00ff), MBE(0x), MBE(0x00ff),
+ MBE(0x),
+};
+
+const uint32_t rasops_rmask32[4 + 1] = {
+ MBE(0x), MBE(0xff00), MBE(0x), MBE(0xff00),
+ MBE(0x),
+};
+
+const uint32_t rasops_pmask32[4][4] = {
+ { MBE(0x), MBE(0xff00), MBE(0x), MBE(0x), },
+ { MBE(0x), MBE(0x00ff), MBE(0x0000), MBE(0x00ff), },
+ { MBE(0x), MBE(0xff00), MBE(0x), MBE(0x), },
+ { MBE(0x), MBE(0x00ff), MBE(0x), MBE(0x), },
+};
+
/* ANSI colormap (R,G,B). Upper 8 are high-intensity */
const uint8_t rasops_cmap[256 * 3] = {
0x00, 0x00, 0x00, /* black */
@@ -429,7 +447,8 @@ rasops_reconfig(struct rasops_info *ri,
/* Clear the entire display */
if ((ri->ri_flg & RI_CLEAR) != 0)
- memset(ri->ri_bits, 0, ri->ri_stride * ri->ri_height);
+ rasops_memset32((uint32_t *)ri->ri_bits, 0,
+ ri->ri_stride * ri->ri_height);
/* Now centre our window if needs be */
if ((ri->ri_flg & RI_CENTER) != 0) {
@@ -690,7 +709,7 @@ static void
rasops_copyrows(void *cookie, int src, int dst, int num)
{
struct rasops_info *ri = (struct rasops_info *)cookie;
- uint8_t *sp, *dp, *hp;
+ uint32_t *sp, *dp, *hp;
int n, stride;
hp = NULL; /* XXX GCC */
@@ -723,19 +742,19 @@ rasops_copyrows(void *cookie, int src, i
n = ri->ri_emustride;
stride = ri->ri_stride;
- sp = ri->ri_bits + src * ri->ri_yscale;
- dp = ri->ri_bits + dst * ri->ri_yscale;
+ sp = (uint32_t *)(ri->ri_bits + src * ri->ri_yscale);
+ dp = (uint32_t *)(ri->ri_bits + dst * ri->ri_yscale);
if (ri->ri_hwbits)
- hp = ri->ri_hwbits + dst * ri->ri_yscale;
+ hp = (uint32_t *)(ri->ri_hwbits + dst * ri->ri_yscale);
while (num--) {
- memcpy(dp, sp, n);
- dp += stride;
+ rasops_memcpy32(dp, sp, n);
+ DELTA(dp, stride, uint32_t *);
if (ri->ri_hwbits) {
- memcpy(hp, sp, n);
- hp += stride;
+ rasops_memcpy32(hp, sp, n);
+ DELTA(hp, stride, uint32_t *);
}
- sp += stride;
+ DELTA(sp, stride, uint32_t *);
}
}
@@ -792,9 +811,9 @@ rasops_copycols(void *cookie, int row, i
hp = ri->ri_hwbits + row + dst * ri->ri_xscale;
while (height--) {
- memmove(dp, sp, num);
+ memmove(dp, sp, num); /* XXXRO not 32-bit operation */
if (ri->ri_hwbits) {
- memcpy(hp, dp, num);
+ memcpy(hp, dp, num);/* XXXRO */
hp += ri->ri_stride;
}
dp += ri->ri_stride;
@@ -980,9 +999,8 @@ void
rasops_eraserows(void *cookie, int row, int num, long attr)
{
struct rasops_info *ri = (struct rasops_info *)cookie;
- uint32_t *buf = (uint32_t *)ri->ri_buf;
uint32_t *rp, *hp, clr;
- int stride, cnt;
+ int n, stride;
hp = NULL; /* XXX GCC */
@@ -1008,29 +1026,28 @@ rasops_eraserows(void *cookie, int row,
* the RI_FULLCLEAR flag is set, clear the entire display.
*/
if (num == ri->ri_rows && (ri->ri_flg & RI_FULLCLEAR) != 0) {
- stride = ri->ri_stride;
+ n =
Re: recent rasops commits vs. macppc
Oops, sorry, I didn't notice your reply. Thank you for useful comments! It should help me a lot to know that both 8- and 12-width fonts are NG. rin On 2019/08/03 10:05, Michael wrote: Hello, On Sat, 3 Aug 2019 08:58:02 +0900 Rin Okuyama wrote: Hi Michael, I'm so sorry for the breakage. I'll investigate it. Font width is 8? Doesn't seem to matter, the G5 used Gallant 12x22, the others used an 8 pixels wide font. Colour depth is always 8 though. PS I decided to buy my own macppc machine. Could anyone recommend me a model of - serial console capable - newer and smaller as possible G4 and models don't really have serial ports anymore, unfortunately, although many can be fitted with a serial port instead of a modem as a 3rd party option. have fun Michael
Re: recent rasops commits vs. macppc
Maybe it's time to remove all non-32bit access to fb. I expect it is not a very hard work for now ;-). PS I ordered Mac Mini G4, although serial console is hopeless... Thanks, rin On 2019/08/03 8:58, Rin Okuyama wrote: Hi Michael, I'm so sorry for the breakage. I'll investigate it. Font width is 8? I appreciate a lot if someone could provide dmesg and backtrace when wscons is enabled after boot with serial console. PS I decided to buy my own macppc machine. Could anyone recommend me a model of - serial console capable - newer and smaller as possible Thanks, rin On 2019/08/03 8:07, Michael wrote: Hello, I just tried to update a few macppc machines and found that every one of them crashes early during kernel startup, before the copyright is printed. Rolling back dev/rasops/ to july 1st allowed them to boot. I didn't have time to investigate further but, as a data point, macppc early console uses 8bit colour and a bitmap font, scribbling into a firmware-provided framebuffer. have fun Michael
Re: recent rasops commits vs. macppc
Hello, On Sat, 3 Aug 2019 08:58:02 +0900 Rin Okuyama wrote: > Hi Michael, > > I'm so sorry for the breakage. I'll investigate it. > Font width is 8? Doesn't seem to matter, the G5 used Gallant 12x22, the others used an 8 pixels wide font. Colour depth is always 8 though. > PS > I decided to buy my own macppc machine. Could anyone > recommend me a model of > > - serial console capable > - newer and smaller as possible G4 and models don't really have serial ports anymore, unfortunately, although many can be fitted with a serial port instead of a modem as a 3rd party option. have fun Michael
Re: recent rasops commits vs. macppc
Hi Michael, I'm so sorry for the breakage. I'll investigate it. Font width is 8? I appreciate a lot if someone could provide dmesg and backtrace when wscons is enabled after boot with serial console. PS I decided to buy my own macppc machine. Could anyone recommend me a model of - serial console capable - newer and smaller as possible Thanks, rin On 2019/08/03 8:07, Michael wrote: Hello, I just tried to update a few macppc machines and found that every one of them crashes early during kernel startup, before the copyright is printed. Rolling back dev/rasops/ to july 1st allowed them to boot. I didn't have time to investigate further but, as a data point, macppc early console uses 8bit colour and a bitmap font, scribbling into a firmware-provided framebuffer. have fun Michael
