- OpenBIOS - mail.coreboot.org

[commit] r1157 - trunk/openbios-devel/arch/unix
by repository service 23 Jun '13

23 Jun '13

Author: agraf Date: Sun Jun 23 00:30:31 2013 New Revision: 1157 URL: http://tracker.coreboot.org/trac/openbios/changeset/1157 Log: Unix build: Add is_machine helpers When building the unix target on PPC, our #ifdef'ery thinks we can properly use the is_machine helpers and act accordingly to implement hacks. Expose these helpers in the unix target as well, just always define them as false. That way we safe compilation without adding too much logic to deal with unimportant corner cases. Signed-off-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/unix/unix.c Modified: trunk/openbios-devel/arch/unix/unix.c ============================================================================== --- trunk/openbios-devel/arch/unix/unix.c Sun Jun 9 14:25:46 2013 (r1156) +++ trunk/openbios-devel/arch/unix/unix.c Sun Jun 23 00:30:31 2013 (r1157) @@ -82,6 +82,26 @@ } #endif +#ifdef CONFIG_PPC +/* Expose system level is_machine helpers to make generic code easier */ + +#include "drivers/drivers.h" +int is_apple(void) +{ + return 0; +} + +int is_oldworld(void) +{ + return 0; +} + +int is_newworld(void) +{ + return 0; +} +#endif + #if 0 static void write_dictionary(char *filename) {

1 0

Re: [OpenBIOS] [Qemu-ppc] Changing CD-ROM path
by Alexander Graf 22 Jun '13

22 Jun '13

On 22.06.2013, at 18:50, Programmingkid wrote: > Mac OS 10.2 requires the boot CD-ROM to be located here: /pci/mac-io/ide@1000/@0:9. It is currently located here: /pci@80000000/pci-ata@4/ata-2@500/cdrom@0. How would I go about changing the CD-ROM to this location? I'm looking for a specific file or files to make this change. This is an OF path, which is up to OpenBIOS to construct. What makes you think that Mac OS searches at that exact location? Alex

1 0

[PATCHv2 00/20] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 22 Jun '13

22 Jun '13

As mentioned previously on-list, OpenBIOS currently contains two consoles - a C based console and a Forth based console. The Forth based console is currently broken, but is more feature complete than the C console, whilst also being more portable across different architectures. This patchset performs the following functions: - Fix various bugs in the Forth console - Optimise performance using low-level C graphics routines - Add simple IEEE1275-like initialisers for TCX and VGA graphics - Switch TCX and VGA drivers over to use the new console using the standard is-install word Once this patchset is committed, a further patchset will follow to remove all of the duplicate C console code, remove packages/video.c and unify the console input/routines into libopenbios. Changes since v1: - Rebase onto SVN trunk - Various minor bugfixes/tidy-ups - Fix CSI n;mH and CSI n;mf as reported by Blue Swirl - Implementation of remaining missing fb8-* defer words: fb8-insert-lines fb8-insert-characters fb8-delete-characters Mark Cave-Ayland (20): display.fs: Fix up default-font word. display.fs: Fix fb8-delete-lines within the inbuilt Forth terminal emulator. terminal.fs: Fix linefeeds on the bottom line of the Forth console. terminal.fs: Fix backspace sequence in Forth terminal. video: Create new video_common.c file for shared video primitive routines. video_common.c: Move primitive graphic operations into libopenbios/video_common.c. pci: Modify PCI display devices so that open and close words are not created automatically during initialisation. video: Create tcx.fs and vga.fs to simulate Fcode video initialisation code. display.fs: pass the colour depth and line bytes to the Forth terminal routines. video_common.c: create low-level video_mask_blit() function. video_common.c: create low-level video_invert_rect() function. display.fs: Fix fb8 routines to work with bit depths > 8. video_common.c: create low-level video_fill_rect() function. display.fs: optimise scrolling by copying/deleting multiple scanlines at once. display.fs: Add vertical font-spacing as per the existing C console implementation. terminal.fs: handle all cursor positioning within the terminal package. terminal.fs: Fix CSI n;mH and CSI n;mf control sequences. display.fs: add implementation of fb8-insert-lines. display.fs: add implementation of fb8-insert-characters and fb8-delete-characters. video: switch VGA and TCX drivers over to Forth console using is-install. openbios-devel/arch/sparc32/console.c | 12 - openbios-devel/arch/sparc32/openbios.c | 2 +- openbios-devel/drivers/build.xml | 2 + openbios-devel/drivers/pci.c | 14 +- openbios-devel/drivers/pci.h | 1 + openbios-devel/drivers/sbus.c | 2 + openbios-devel/drivers/tcx.fs | 13 + openbios-devel/drivers/vga.fs | 13 + openbios-devel/drivers/vga_vbe.c | 2 +- openbios-devel/forth/device/display.fs | 228 +++++++------- openbios-devel/forth/device/font.fs | 4 + openbios-devel/forth/device/terminal.fs | 67 +++- openbios-devel/include/libopenbios/video.h | 24 ++ openbios-devel/include/packages/video.h | 6 +- openbios-devel/libopenbios/build.xml | 1 + openbios-devel/libopenbios/console_common.c | 1 + openbios-devel/libopenbios/video_common.c | 446 +++++++++++++++++++++++++++ openbios-devel/packages/video.c | 279 +---------------- 18 files changed, 700 insertions(+), 417 deletions(-) create mode 100644 openbios-devel/drivers/tcx.fs create mode 100644 openbios-devel/drivers/vga.fs create mode 100644 openbios-devel/include/libopenbios/video.h create mode 100644 openbios-devel/libopenbios/video_common.c -- 1.7.10.4

3 25

[PATCH 00/20] Video/console cleanup patch
by Mark Cave-Ayland 15 Jun '13

15 Jun '13

This patch expands on the work from the last patchset and makes the following changes: - Remove the now-obsolete C console files/functions - Separate out the video routines into MOL, TCX and VGA paths - Unify the video descriptor with Forth (instead of having both a C struct and Forth variables holding video information, have the C struct members point directly to the relevant dictionary cells) - Fix any bugs found as a result of the refactoring above - Add new debug-type and debug-cr words for debugging over the serial port even when video mode is enabled - Remove the cls() from the serial console for SPARC32/64 - Fix a decode-string off-by-one property bug The next stage after this will be to switch the TCX video initialisation path over to use Forth FCode evaluation in conjunction with a set of new probe functions. Mark Cave-Ayland (20): video_common.c: remove video_open() and video_write() methods libopenbios: remove the C terminal emulator file console_common.c packages: rename video.c to molvideo.c ready for MOL-specific video routines video_common.c: remove manual screen clear since fb8-erase-screen does this now video_common.c: move startup_splash() and refresh_palette() to packages/molvideo.c video_common.c: now fill_rect() is no longer called directly, merge it into the video_fill_rect() video_common.c: remove video_scroll1() and draw_pixel() as they are no longer needed video_common.c: rename get_color() and set_color() functions video_common.c: Move osi_fb_info_t struct contents directly into the video_info struct video_common.c: unify the video_info structure with Forth video_common.c: split video setup routines into setup_video() video_common.c: remove the video_get_res() function video_common.c: move colour palette code into individual devices sbus.c: fix TCX24 initialisation video_common.c: fix 32-bit display modes on 64-bit architectures video_common.c: remove init_video() function console: remove libopenbios/console.h bootstrap.fs: add debug-type and debug-cr words SPARC: remove cls() from the console startup property.fs: fix off-by-one error in decode-string openbios-devel/arch/sparc32/boot.h | 3 - openbios-devel/arch/sparc32/console.c | 36 +-- openbios-devel/arch/sparc32/openbios.c | 4 +- openbios-devel/arch/sparc64/console.c | 12 - openbios-devel/arch/sparc64/openbios.c | 2 - openbios-devel/arch/x86/openbios.c | 8 +- openbios-devel/config/scripts/switch-arch | 4 + openbios-devel/drivers/sbus.c | 13 + openbios-devel/drivers/vga_vbe.c | 87 +++--- openbios-devel/forth/bootstrap/bootstrap.fs | 2 + openbios-devel/forth/device/display.fs | 38 ++- openbios-devel/forth/device/property.fs | 2 +- openbios-devel/include/arch/sparc32/io.h | 7 + openbios-devel/include/drivers/drivers.h | 1 + openbios-devel/include/libopenbios/console.h | 9 - openbios-devel/include/libopenbios/video.h | 48 +-- openbios-devel/libopenbios/build.xml | 1 - openbios-devel/libopenbios/console_common.c | 416 -------------------------- openbios-devel/libopenbios/video_common.c | 377 +++++++---------------- openbios-devel/packages/build.xml | 2 +- openbios-devel/packages/molvideo.c | 172 +++++++++++ openbios-devel/packages/video.c | 90 ------ 22 files changed, 442 insertions(+), 892 deletions(-) delete mode 100644 openbios-devel/include/libopenbios/console.h delete mode 100644 openbios-devel/libopenbios/console_common.c create mode 100644 openbios-devel/packages/molvideo.c delete mode 100644 openbios-devel/packages/video.c -- 1.7.10.4

1 20

[PATCH] macio: Rename arch_nvram_{put,get,size}()
by Andreas Färber 09 Jun '13

09 Jun '13

PReP does not have MacIO, so don't call its functions arch_*. Instead indirect from arch_* functions to macio_* functions via is_apple(). Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> --- arch/ppc/qemu/qemu.c | 22 ++++++++++++++++++++++ drivers/macio.c | 6 +++--- include/drivers/drivers.h | 5 +++++ 3 files changed, 30 insertions(+), 3 deletions(-) diff --git a/arch/ppc/qemu/qemu.c b/arch/ppc/qemu/qemu.c index 208669c..bed5bb3 100644 --- a/arch/ppc/qemu/qemu.c +++ b/arch/ppc/qemu/qemu.c @@ -76,3 +76,25 @@ printk( const char *fmt, ... ) } return i; } + +int arch_nvram_size(void) +{ + if (is_apple()) { + return macio_nvram_size(); + } + return 0; +} + +void arch_nvram_put(char *buf) +{ + if (is_apple()) { + macio_nvram_put(buf); + } +} + +void arch_nvram_get(char *buf) +{ + if (is_apple()) { + macio_nvram_get(buf); + } +} diff --git a/drivers/macio.c b/drivers/macio.c index 59ad1f6..c6aee0a 100644 --- a/drivers/macio.c +++ b/drivers/macio.c @@ -35,7 +35,7 @@ static char *nvram; int -arch_nvram_size( void ) +macio_nvram_size(void) { if (is_oldworld()) return OW_IO_NVRAM_SIZE >> OW_IO_NVRAM_SHIFT; @@ -100,7 +100,7 @@ dump_nvram(void) void -arch_nvram_put( char *buf ) +macio_nvram_put(char *buf) { int i; unsigned int it_shift; @@ -119,7 +119,7 @@ arch_nvram_put( char *buf ) } void -arch_nvram_get( char *buf ) +macio_nvram_get(char *buf) { int i; unsigned int it_shift; diff --git a/include/drivers/drivers.h b/include/drivers/drivers.h index d139ace..5e1f9f1 100644 --- a/include/drivers/drivers.h +++ b/include/drivers/drivers.h @@ -123,6 +123,11 @@ int keyboard_dataready(void); unsigned char keyboard_readdata(void); #endif #endif +#ifdef CONFIG_DRIVER_MACIO +int macio_nvram_size(void); +void macio_nvram_put(char *buf); +void macio_nvram_get(char *buf); +#endif /* drivers/timer.c */ void setup_timers(void); -- 1.8.1.4

2 1

[commit] r1156 - in trunk/openbios-devel: arch/sparc32 drivers
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:46 2013 New Revision: 1156 URL: http://tracker.coreboot.org/trac/openbios/changeset/1156 Log: video: switch VGA and TCX drivers over to Forth console using is-install. Here we install the Forth terminal console instead of the C console for the VGA and TCX drivers. Note that this patch also disables video output for SPARC32 when CONFIG_DEBUG_CONSOLE_VIDEO is enabled, since these routines write directly to the screen instead of using the Forth bindings causing some display issues. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/console.c trunk/openbios-devel/drivers/pci.c trunk/openbios-devel/drivers/sbus.c Modified: trunk/openbios-devel/arch/sparc32/console.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/console.c Sun Jun 9 14:25:43 2013 (r1155) +++ trunk/openbios-devel/arch/sparc32/console.c Sun Jun 9 14:25:46 2013 (r1156) @@ -30,15 +30,6 @@ unsigned char *vmem; volatile uint32_t *dac; -static void video_putchar(int c) -{ - char buf; - - buf = c & 0xff; - - console_draw_fstr(&buf, 1); -} - static void video_cls(void) { memset((void *)vmem, 0, VMEM_SIZE); @@ -63,9 +54,6 @@ #ifdef CONFIG_DEBUG_CONSOLE_SERIAL serial_putchar(c); #endif -#ifdef CONFIG_DEBUG_CONSOLE_VIDEO - video_putchar(c); -#endif return c; } Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Sun Jun 9 14:25:43 2013 (r1155) +++ trunk/openbios-devel/drivers/pci.c Sun Jun 9 14:25:46 2013 (r1156) @@ -764,12 +764,16 @@ int vga_config_cb (const pci_config_t *config) { - if (config->assigned[0] != 0x00000000) + if (config->assigned[0] != 0x00000000) { vga_vbe_init(config->path, pci_bus_addr_to_host_addr(config->assigned[0] & ~0x0000000F), config->sizes[0], pci_bus_addr_to_host_addr(config->assigned[1] & ~0x0000000F), config->sizes[1]); + + feval("['] qemu-vga-driver-init is-install"); + } + return 0; } Modified: trunk/openbios-devel/drivers/sbus.c ============================================================================== --- trunk/openbios-devel/drivers/sbus.c Sun Jun 9 14:25:43 2013 (r1155) +++ trunk/openbios-devel/drivers/sbus.c Sun Jun 9 14:25:46 2013 (r1156) @@ -329,6 +329,8 @@ fword("property"); } + feval("['] qemu-tcx-driver-init is-install"); + chosen = find_dev("/chosen"); push_str(path); fword("open-dev");

1 0

[commit] r1155 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:43 2013 New Revision: 1155 URL: http://tracker.coreboot.org/trac/openbios/changeset/1155 Log: display.fs: add implementation of fb8-insert-characters and fb8-delete-characters. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:39 2013 (r1154) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:43 2013 (r1155) @@ -175,7 +175,12 @@ frame-buffer-adr + window-left depth-bytes * + ; - + +: fb8-curpos2addr ( col line -- addr ) + char-height * fb8-line2addr + swap char-width * depth-bytes * + +; + : fb8-copy-lines ( count from to -- ) fb8-line2addr swap fb8-line2addr swap @@ -253,9 +258,41 @@ ; : fb8-insert-characters ( n -- ) - ; + \ numcopy = ( #columns - column# - n ) + #columns over - column# - + char-width * depth-bytes * ( n numbytescopy ) + + over column# + line# fb8-curpos2addr + column# line# fb8-curpos2addr ( n numbytescopy destaddr srcaddr ) + char-height 0 do + 3dup swap rot move + line-bytes + swap line-bytes + swap + loop 3drop + background-color + column# char-width * window-left + line# char-height * window-top + + 3 pick char-width * char-height + fb8-fillrect + drop + ; + : fb8-delete-characters ( n -- ) + \ numcopy = ( #columns - column# - n ) + #columns over - column# - + char-width * depth-bytes * ( n numbytescopy ) + + over column# + line# fb8-curpos2addr + column# line# fb8-curpos2addr swap ( n numbytescopy destaddr srcaddr ) + char-height 0 do + 3dup swap rot move + line-bytes + swap line-bytes + swap + loop 3drop + + background-color + over #columns swap - char-width * window-left + line# char-height * window-top + + 3 pick char-width * char-height + fb8-fillrect + drop ; : fb8-insert-lines ( n -- )

1 0

[commit] r1154 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:39 2013 New Revision: 1154 URL: http://tracker.coreboot.org/trac/openbios/changeset/1154 Log: display.fs: add implementation of fb8-insert-lines. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:36 2013 (r1153) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:39 2013 (r1154) @@ -259,6 +259,14 @@ ; : fb8-insert-lines ( n -- ) + \ numcopy = ( #lines - n ) + #lines over - char-height * + over line# char-height * + swap char-height * over + + fb8-copy-lines + + char-height * line# char-height * + fb8-clear-lines ; : fb8-delete-lines ( n -- )

1 0

[commit] r1153 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:36 2013 New Revision: 1153 URL: http://tracker.coreboot.org/trac/openbios/changeset/1153 Log: terminal.fs: Fix CSI n;mH and CSI n;mf control sequences. Fix an off-by-one error in the lines/columns calculations and also ensure that we correctly interpret control sequences when not all of the optional parameters are present. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/terminal.fs Modified: trunk/openbios-devel/forth/device/terminal.fs ============================================================================== --- trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:25:33 2013 (r1152) +++ trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:25:36 2013 (r1153) @@ -97,17 +97,39 @@ endof ascii f of 2 (esc-number) - 2 = if - #columns 1- min to column# - #lines 1- min to line# - then + case + 2 of + 1- #columns 1- min to column# + 1- #lines 1- min to line# + endof + 1 of + 0 to column# + 1- #lines 1- min to line# + endof + 0 of + 0 to column# + 0 to line# + drop + endof + endcase endof ascii H of - 2 (esc-number) - 2 = if - #columns 1- min to column# - #lines 1- min to line# - then + 2 (esc-number) + case + 2 of + 1- #columns 1- min to column# + 1- #lines 1- min to line# + endof + 1 of + 0 to column# + 1- #lines 1- min to line# + endof + 0 of + 0 to column# + 0 to line# + drop + endof + endcase endof ascii J of 0 to (escseq)

1 0

[commit] r1152 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:33 2013 New Revision: 1152 URL: http://tracker.coreboot.org/trac/openbios/changeset/1152 Log: terminal.fs: handle all cursor positioning within the terminal package. Currently the column positioning is handled by the framebuffer code in display.fs where it shouldn't really be. This also fixes a crash bug when window-top is set and a line wraps onto the line beneath it. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/forth/device/terminal.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:30 2013 (r1151) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:33 2013 (r1152) @@ -210,20 +210,6 @@ swap then fb8-blitmask - \ now advance the position - column# 1+ - dup #columns = if - drop 0 to column# - line# 1+ - dup #lines >= if - line# - 0 to line# - 1 delete-lines - then - to line# - else - to column# - then ; : fb8-reset-screen ( -- ) Modified: trunk/openbios-devel/forth/device/terminal.fs ============================================================================== --- trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:25:30 2013 (r1151) +++ trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:25:33 2013 (r1152) @@ -229,12 +229,13 @@ then endof a of \ LF - line# 1+ to line# 0 to column# + line# 1+ to line# + 0 to column# line# #lines >= if - line# 1- 0 to line# 1 delete-lines - to line# + #lines 1- to line# + toggle-cursor exit then endof b of \ VT @@ -253,7 +254,21 @@ 1b (sequence) c! 1 to (escseq) endof + + \ draw character and advance position + column# #columns >= if + 0 to column# + line# 1+ to line# + line# #lines >= if + 0 to line# + 1 delete-lines + #lines 1- to line# + then + then + dup draw-character + column# 1+ to column# + endcase toggle-cursor ;

1 0

[commit] r1151 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:30 2013 New Revision: 1151 URL: http://tracker.coreboot.org/trac/openbios/changeset/1151 Log: display.fs: Add vertical font-spacing as per the existing C console implementation. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:27 2013 (r1150) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:30 2013 (r1151) @@ -44,6 +44,7 @@ 0 value foreground-color 0 value background-color +2 value font-spacing 0 value depth-bytes 0 value line-bytes @@ -82,7 +83,7 @@ to char-num to char-min to fontbytes - to char-height + font-spacing + to char-height to char-width to font ; @@ -192,12 +193,17 @@ ; : fb8-draw-character ( char -- ) + \ erase the current character + background-color + column# char-width * window-left + + line# char-height * window-top + + char-width char-height fb8-fillrect \ draw the character: >font line# char-height * window-top + screen-width * depth-bytes * column# char-width * depth-bytes * window-left depth-bytes * + + frame-buffer-adr + - swap char-width char-height + swap char-width char-height font-spacing - \ normal or inverse? foreground-color background-color inverse? if @@ -234,7 +240,7 @@ : fb8-toggle-cursor ( -- ) column# char-width * window-left + line# char-height * window-top + - char-width char-height + char-width char-height font-spacing - foreground-color background-color fb8-invertrect ;

1 0

[commit] r1150 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:27 2013 New Revision: 1150 URL: http://tracker.coreboot.org/trac/openbios/changeset/1150 Log: display.fs: optimise scrolling by copying/deleting multiple scanlines at once. Change fb8-copy-line and fb8-clear-line so that they can operate on multiple lines at once, renaming to fb8-copy-lines and fb8-clear-lines respectively. Integrate these new functions into fb8-delete-lines so that they are used when scrolling the display. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:25 2013 (r1149) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:27 2013 (r1150) @@ -175,17 +175,20 @@ window-left depth-bytes * + ; -: fb8-copy-line ( from to -- ) - fb8-line2addr swap - fb8-line2addr swap - #columns char-width * depth-bytes * move +: fb8-copy-lines ( count from to -- ) + fb8-line2addr swap + fb8-line2addr swap + #columns char-width * depth-bytes * + 3 pick * move drop ; -: fb8-clear-line ( line -- ) - fb8-line2addr - #columns char-width * depth-bytes * - background-color fill -\ 0 fill +: fb8-clear-lines ( count line -- ) + background-color 0 + 2 pick window-top + + #columns char-width * + 5 pick + fb8-fillrect + 2drop ; : fb8-draw-character ( char -- ) @@ -269,20 +272,14 @@ : fb8-delete-lines ( n -- ) \ numcopy = ( #lines - ( line# + n )) * char-height #lines over line# + - char-height * - - ( numcopy ) 0 ?do - dup line# + char-height * i + - line# char-height * i + - fb8-copy-line - loop - - #lines over - char-height * - over char-height * - 0 ?do - dup i + fb8-clear-line - loop + over line# + char-height * + line# char-height * + fb8-copy-lines - 2drop + #lines over - char-height * + dup #lines char-height * swap - swap + fb8-clear-lines + drop ;

1 0

[commit] r1149 - in trunk/openbios-devel: forth/device include/libopenbios libopenbios packages
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:25 2013 New Revision: 1149 URL: http://tracker.coreboot.org/trac/openbios/changeset/1149 Log: video_common.c: create low-level video_fill_rect() function. Switch fb8-erase-screen in display.fs over to use it. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/include/libopenbios/video.h trunk/openbios-devel/libopenbios/video_common.c trunk/openbios-devel/packages/video.c Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:22 2013 (r1148) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:25 2013 (r1149) @@ -165,6 +165,7 @@ \ bind to low-level C function later defer fb8-blitmask +defer fb8-fillrect defer fb8-invertrect : fb8-line2addr ( line -- addr ) @@ -236,14 +237,13 @@ ; : fb8-erase-screen ( -- ) - frame-buffer-adr - screen-height screen-width * inverse-screen? if foreground-color else background-color then - fill + 0 0 screen-width screen-height + fb8-fillrect ; : fb8-invert-screen ( -- ) Modified: trunk/openbios-devel/include/libopenbios/video.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:22 2013 (r1148) +++ trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:25 2013 (r1149) @@ -9,6 +9,7 @@ void fill_rect(int col_ind, int x, int y, int w, int h); void video_mask_blit(void); void video_invert_rect(void); +void video_fill_rect(void); typedef struct osi_fb_info { unsigned long mphys; Modified: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:22 2013 (r1148) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:25 2013 (r1149) @@ -339,6 +339,19 @@ PUSH(len); } +/* ( color_ind x y width height -- ) (?) */ +void +video_fill_rect(void) +{ + int h = POP(); + int w = POP(); + int y = POP(); + int x = POP(); + int color_ind = POP(); + + fill_rect( color_ind, x, y, w, h ); +} + void init_video( unsigned long fb, int width, int height, int depth, int rb ) { @@ -391,6 +404,9 @@ PUSH( pointer2cell(video_mask_blit) ); fword("is-noname-cfunc"); feval("to fb8-blitmask"); + PUSH( pointer2cell(video_fill_rect) ); + fword("is-noname-cfunc"); + feval("to fb8-fillrect"); PUSH( pointer2cell(video_invert_rect) ); fword("is-noname-cfunc"); feval("to fb8-invertrect"); Modified: trunk/openbios-devel/packages/video.c ============================================================================== --- trunk/openbios-devel/packages/video.c Sun Jun 9 14:25:22 2013 (r1148) +++ trunk/openbios-devel/packages/video.c Sun Jun 9 14:25:25 2013 (r1149) @@ -71,19 +71,6 @@ refresh_palette(); } -/* ( color_ind x y width height -- ) (?) */ -static void -video_fill_rect( void ) -{ - int h = POP(); - int w = POP(); - int y = POP(); - int x = POP(); - int color_ind = POP(); - - fill_rect( color_ind, x, y, w, h ); -} - NODE_METHODS( video ) = { {"dimensions", video_dimensions }, {"set-colors", video_set_colors },

1 0

[commit] r1148 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:22 2013 New Revision: 1148 URL: http://tracker.coreboot.org/trac/openbios/changeset/1148 Log: display.fs: Fix fb8 routines to work with bit depths > 8. The IEEE1275 specification suggests that the fb8-* routines can be coerced into working for framebuffers with greater bit depths. Make sure that we also support this. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:20 2013 (r1147) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:22 2013 (r1148) @@ -169,20 +169,20 @@ : fb8-line2addr ( line -- addr ) window-top + - screen-width * + screen-width * depth-bytes * frame-buffer-adr + - window-left + + window-left depth-bytes * + ; : fb8-copy-line ( from to -- ) fb8-line2addr swap fb8-line2addr swap - #columns char-width * move + #columns char-width * depth-bytes * move ; : fb8-clear-line ( line -- ) fb8-line2addr - #columns char-width * + #columns char-width * depth-bytes * background-color fill \ 0 fill ; @@ -190,8 +190,9 @@ : fb8-draw-character ( char -- ) \ draw the character: >font - line# char-height * window-top + screen-width * - column# char-width * window-left + + frame-buffer-adr + + line# char-height * window-top + screen-width * depth-bytes * + column# char-width * depth-bytes * + window-left depth-bytes * + + frame-buffer-adr + swap char-width char-height \ normal or inverse? foreground-color background-color

1 0

[commit] r1147 - in trunk/openbios-devel: forth/device include/libopenbios libopenbios
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:20 2013 New Revision: 1147 URL: http://tracker.coreboot.org/trac/openbios/changeset/1147 Log: video_common.c: create low-level video_invert_rect() function. Switch display.fs over to use it. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/include/libopenbios/video.h trunk/openbios-devel/libopenbios/video_common.c Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:17 2013 (r1146) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:20 2013 (r1147) @@ -165,6 +165,7 @@ \ bind to low-level C function later defer fb8-blitmask +defer fb8-invertrect : fb8-line2addr ( line -- addr ) window-top + @@ -226,15 +227,11 @@ ; : fb8-toggle-cursor ( -- ) - line# char-height * window-top + screen-width * - column# char-width * window-left + + frame-buffer-adr + - char-height 0 ?do - char-width 0 ?do - dup i + dup c@ invert ff and swap c! - loop - screen-width + - loop - drop + column# char-width * window-left + + line# char-height * window-top + + char-width char-height + foreground-color background-color + fb8-invertrect ; : fb8-erase-screen ( -- ) @@ -249,20 +246,14 @@ ; : fb8-invert-screen ( -- ) - frame-buffer-adr - screen-height screen-width * - bounds ?do - i c@ case - foreground-color of background-color endof - background-color of foreground-color endof - dup - endcase - i c! - loop + 0 0 screen-width screen-height + background-color foreground-color + fb8-invertrect ; : fb8-blink-screen ( -- ) - fb8-invert-screen fb8-invert-screen + fb8-invert-screen 2000 ms + fb8-invert-screen ; : fb8-insert-characters ( n -- ) Modified: trunk/openbios-devel/include/libopenbios/video.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:17 2013 (r1146) +++ trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:20 2013 (r1147) @@ -8,6 +8,7 @@ void video_scroll(int height); void fill_rect(int col_ind, int x, int y, int w, int h); void video_mask_blit(void); +void video_invert_rect(void); typedef struct osi_fb_info { unsigned long mphys; Modified: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:17 2013 (r1146) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:20 2013 (r1147) @@ -184,6 +184,61 @@ } } +/* ( x y w h fgcolor bgcolor -- ) */ + +void +video_invert_rect( void ) +{ + ucell bgcolor = POP(); + ucell fgcolor = POP(); + int h = POP(); + int w = POP(); + int y = POP(); + int x = POP(); + char *pp; + + bgcolor = get_color(bgcolor); + fgcolor = get_color(fgcolor); + + if (!video.has_video || x < 0 || y < 0 || w <= 0 || h <= 0 || + x + w > video.fb.w || y + h > video.fb.h) + return; + + pp = (char*)video.fb.mvirt + video.fb.rb * y; + for( ; h--; pp += video.fb.rb ) { + int ww = w; + if( video.fb.depth == 24 || video.fb.depth == 32 ) { + unsigned long *p = (unsigned long*)pp + x; + while( ww-- ) { + if (*p == fgcolor) { + *p++ = bgcolor; + } else if (*p == bgcolor) { + *p++ = fgcolor; + } + } + } else if( video.fb.depth == 16 || video.fb.depth == 15 ) { + unsigned short *p = (unsigned short*)pp + x; + while( ww-- ) { + if (*p == (unsigned short)fgcolor) { + *p++ = bgcolor; + } else if (*p == (unsigned short)bgcolor) { + *p++ = fgcolor; + } + } + } else { + char *p = (char *)(pp + x); + + while( ww-- ) { + if (*p == (char)fgcolor) { + *p++ = bgcolor; + } else if (*p == (char)bgcolor) { + *p++ = fgcolor; + } + } + } + } +} + void draw_pixel( int x, int y, int colind ) { @@ -336,6 +391,9 @@ PUSH( pointer2cell(video_mask_blit) ); fword("is-noname-cfunc"); feval("to fb8-blitmask"); + PUSH( pointer2cell(video_invert_rect) ); + fword("is-noname-cfunc"); + feval("to fb8-invertrect"); PUSH((video.fb.depth + 1) >> 3); feval("to depth-bytes");

1 0

[commit] r1146 - in trunk/openbios-devel: forth/device include/libopenbios libopenbios
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:17 2013 New Revision: 1146 URL: http://tracker.coreboot.org/trac/openbios/changeset/1146 Log: video_common.c: create low-level video_mask_blit() function. Switch display.fs over to use it. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/include/libopenbios/video.h trunk/openbios-devel/libopenbios/video_common.c Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:14 2013 (r1145) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:17 2013 (r1146) @@ -163,45 +163,8 @@ \ 5.3.6.3.3 Generic eight-bit frame-buffer support -\ The following two functions are unrolled for speed. - - -\ blit 8 continuous pixels described by the 8bit -\ value in bitmask8. The most significant bit is -\ painted first. - -\ this function should honour fg and bg colors - -: fb8-write-mask8 ( bitmask8 faddr -- ) - over 1 and 0<> over 7 + c! - over 2 and 0<> over 6 + c! - over 4 and 0<> over 5 + c! - over 8 and 0<> over 4 + c! - over 10 and 0<> over 3 + c! - over 20 and 0<> over 2 + c! - over 40 and 0<> over 1 + c! - over 80 and 0<> over 0 + c! - 2drop - ; - -: fb8-blitmask ( fbaddr mask-addr width height -- ) - over >r \ save width ( -- R: width ) - * 3 >> \ fbaddr mask-addr width*height/8 - bounds \ fbaddr mask-end mask - r> 0 2swap \ fbaddr width 0 mask-end mask - ?do \ ( fbaddr width l-cnt ) - 2 pick over + \ fbaddr-current - i c@ \ bitmask8 - swap fb8-write-mask8 - ( fbaddr width l-cnt ) - 8 + 2dup = if - drop swap screen-width + - swap 0 - then - ( fbaddr width l-cnt ) - loop - 2drop drop - ; +\ bind to low-level C function later +defer fb8-blitmask : fb8-line2addr ( line -- addr ) window-top + @@ -229,6 +192,11 @@ line# char-height * window-top + screen-width * column# char-width * window-left + + frame-buffer-adr + swap char-width char-height + \ normal or inverse? + foreground-color background-color + inverse? if + swap + then fb8-blitmask \ now advance the position column# 1+ Modified: trunk/openbios-devel/include/libopenbios/video.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:14 2013 (r1145) +++ trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:17 2013 (r1146) @@ -7,6 +7,7 @@ void draw_pixel(int x, int y, int colind); void video_scroll(int height); void fill_rect(int col_ind, int x, int y, int w, int h); +void video_mask_blit(void); typedef struct osi_fb_info { unsigned long mphys; Modified: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:14 2013 (r1145) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:17 2013 (r1146) @@ -134,6 +134,56 @@ return 0; } +/* ( fbaddr maskaddr width height fgcolor bgcolor -- ) */ + +void +video_mask_blit(void) +{ + ucell bgcolor = POP(); + ucell fgcolor = POP(); + ucell height = POP(); + ucell width = POP(); + unsigned char *mask = (unsigned char *)POP(); + unsigned char *fbaddr = (unsigned char *)POP(); + + ucell color; + unsigned char *dst, *rowdst; + int x, y, m, b, d, depthbytes; + + fgcolor = get_color(fgcolor); + bgcolor = get_color(bgcolor); + d = video.fb.depth; + depthbytes = (video.fb.depth + 1) >> 3; + + dst = fbaddr; + for( y = 0; y < height; y++) { + rowdst = dst; + for( x = 0; x < (width + 1) >> 3; x++ ) { + for (b = 0; b < 8; b++) { + m = (1 << (7 - b)); + + if (*mask & m) { + color = fgcolor; + } else { + color = bgcolor; + } + + if( d >= 24 ) + *((unsigned long*)dst) = color; + else if( d >= 15 ) + *((short*)dst) = color; + else + *dst = color; + + dst += depthbytes; + } + mask++; + } + dst = rowdst; + dst += video.fb.rb; + } +} + void draw_pixel( int x, int y, int colind ) { @@ -283,6 +333,10 @@ feval("to frame-buffer-adr"); /* Set global variables ready for fb8-install */ + PUSH( pointer2cell(video_mask_blit) ); + fword("is-noname-cfunc"); + feval("to fb8-blitmask"); + PUSH((video.fb.depth + 1) >> 3); feval("to depth-bytes"); PUSH(video.fb.rb);

1 0

[commit] r1145 - in trunk/openbios-devel: forth/device libopenbios
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:14 2013 New Revision: 1145 URL: http://tracker.coreboot.org/trac/openbios/changeset/1145 Log: display.fs: pass the colour depth and line bytes to the Forth terminal routines. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/libopenbios/video_common.c Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:11 2013 (r1144) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:14 2013 (r1145) @@ -44,6 +44,9 @@ 0 value foreground-color 0 value background-color +0 value depth-bytes +0 value line-bytes + \ internal values read from QEMU firmware interface 0 value qemu-video-addr 0 value qemu-video-height Modified: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:11 2013 (r1144) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:14 2013 (r1145) @@ -283,6 +283,10 @@ feval("to frame-buffer-adr"); /* Set global variables ready for fb8-install */ + PUSH((video.fb.depth + 1) >> 3); + feval("to depth-bytes"); + PUSH(video.fb.rb); + feval("to line-bytes"); PUSH((ucell)fontdata); feval("to (romfont)"); PUSH(FONT_HEIGHT);

1 0

[commit] r1144 - in trunk/openbios-devel: drivers forth/device libopenbios packages
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:11 2013 New Revision: 1144 URL: http://tracker.coreboot.org/trac/openbios/changeset/1144 Log: video: Create tcx.fs and vga.fs to simulate Fcode video initialisation code. The IEEE1275 is-install routine needs to call a basic initialisation routine for each driver as typically supplied as an Fcode ROM. Provide a suitable set of basic initialisers for a QEMU host. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Added: trunk/openbios-devel/drivers/tcx.fs trunk/openbios-devel/drivers/vga.fs Modified: trunk/openbios-devel/drivers/build.xml trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/libopenbios/video_common.c trunk/openbios-devel/packages/video.c Modified: trunk/openbios-devel/drivers/build.xml ============================================================================== --- trunk/openbios-devel/drivers/build.xml Sun Jun 9 14:25:08 2013 (r1143) +++ trunk/openbios-devel/drivers/build.xml Sun Jun 9 14:25:11 2013 (r1144) @@ -29,6 +29,8 @@ <object source="pci.fs" condition="DRIVER_PCI"/> <object source="sbus.fs" condition="DRIVER_SBUS"/> <object source="esp.fs" condition="DRIVER_ESP"/> + <object source="tcx.fs" condition="DRIVER_SBUS"/> + <object source="vga.fs" condition="DRIVER_VGA"/> </dictionary> </build> Added: trunk/openbios-devel/drivers/tcx.fs ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/drivers/tcx.fs Sun Jun 9 14:25:11 2013 (r1144) @@ -0,0 +1,13 @@ +\ +\ Fcode payload for QEMU TCX graphics card +\ +\ This is the Forth source for an Fcode payload to initialise +\ the QEMU TCX graphics card. +\ + +: qemu-tcx-driver-init ( -- ) + qemu-video-addr to frame-buffer-adr + default-font set-font + qemu-video-width qemu-video-height over char-width / over char-height / + fb8-install +; Added: trunk/openbios-devel/drivers/vga.fs ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/drivers/vga.fs Sun Jun 9 14:25:11 2013 (r1144) @@ -0,0 +1,13 @@ +\ +\ Fcode payload for QEMU VGA graphics card +\ +\ This is the Forth source for an Fcode payload to initialise +\ the QEMU VGA graphics card. +\ + +: qemu-vga-driver-init ( -- ) + qemu-video-addr to frame-buffer-adr + default-font set-font + qemu-video-width qemu-video-height over char-width / over char-height / + fb8-install +; Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:08 2013 (r1143) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:25:11 2013 (r1144) @@ -44,6 +44,10 @@ 0 value foreground-color 0 value background-color +\ internal values read from QEMU firmware interface +0 value qemu-video-addr +0 value qemu-video-height +0 value qemu-video-width \ The following wordset is called the "defer word interface" of the \ terminal-emulator support package. It gets overloaded by fb1-install @@ -102,6 +106,8 @@ s" open" header 1 , \ colon definition , + ['] (lit) , + -1 , ['] (semis) , reveal s" : write dup >r bounds do i c@ fb-emit loop r> ; " evaluate @@ -242,6 +248,10 @@ false to inverse-screen? 0 to foreground-color d# 15 to background-color + + \ override with OpenBIOS defaults + fe to background-color + 0 to foreground-color ; : fb8-toggle-cursor ( -- ) @@ -363,4 +373,9 @@ then to foreground-color to background-color + \ ... but let's override with some better defaults + fe to background-color + 0 to foreground-color + + fb8-erase-screen ; Modified: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:08 2013 (r1143) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:11 2013 (r1144) @@ -16,6 +16,8 @@ #include "config.h" #include "libopenbios/bindings.h" +#include "libopenbios/console.h" +#include "libopenbios/fontdata.h" #include "libopenbios/ofmem.h" #include "libopenbios/video.h" #include "packages/video.h" @@ -212,6 +214,26 @@ #endif } +static void +video_open(void) +{ + PUSH(-1); +} + +/* ( addr len -- actual ) */ +static void +video_write(void) +{ + char *addr; + int len; + + len = POP(); + addr = (char *)cell2pointer(POP()); + + console_draw_fstr(addr, len); + PUSH(len); +} + void init_video( unsigned long fb, int width, int height, int depth, int rb ) { @@ -242,6 +264,15 @@ set_int_property( ph, "address", video.fb.mvirt ); activate_dev(ph); + + if (!find_package_method("open", ph)) { + bind_func("open", video_open); + } + + if (!find_package_method("write", ph)) { + bind_func("write", video_write); + } + molvideo_init(); } video.has_video = 1; @@ -251,6 +282,20 @@ PUSH(video.fb.mvirt); feval("to frame-buffer-adr"); + /* Set global variables ready for fb8-install */ + PUSH((ucell)fontdata); + feval("to (romfont)"); + PUSH(FONT_HEIGHT); + feval("to (romfont-height)"); + PUSH(FONT_WIDTH); + feval("to (romfont-width)"); + PUSH(video.fb.mvirt); + feval("to qemu-video-addr"); + PUSH(video.fb.w); + feval("to qemu-video-width"); + PUSH(video.fb.h); + feval("to qemu-video-height"); + #if defined(CONFIG_OFMEM) && defined(CONFIG_DRIVER_PCI) size = ((video.fb.h * video.fb.rb) + 0xfff) & ~0xfff; Modified: trunk/openbios-devel/packages/video.c ============================================================================== --- trunk/openbios-devel/packages/video.c Sun Jun 9 14:25:08 2013 (r1143) +++ trunk/openbios-devel/packages/video.c Sun Jun 9 14:25:11 2013 (r1144) @@ -84,26 +84,11 @@ fill_rect( color_ind, x, y, w, h ); } -/* ( addr len -- actual ) */ -static void -video_write(void) -{ - char *addr; - int len; - - len = POP(); - addr = (char *)cell2pointer(POP()); - - console_draw_fstr(addr, len); - PUSH(len); -} - NODE_METHODS( video ) = { {"dimensions", video_dimensions }, {"set-colors", video_set_colors }, {"fill-rectangle", video_fill_rect }, {"color!", video_color_bang }, - {"write", video_write }, };

1 0

[commit] r1143 - trunk/openbios-devel/drivers
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:08 2013 New Revision: 1143 URL: http://tracker.coreboot.org/trac/openbios/changeset/1143 Log: pci: Modify PCI display devices so that open and close words are not created automatically during initialisation. This is because the work needs to be done by the "is-install" word as per the IEEE1275 specification. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/pci.c trunk/openbios-devel/drivers/pci.h Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Sun Jun 9 14:25:03 2013 (r1142) +++ trunk/openbios-devel/drivers/pci.c Sun Jun 9 14:25:08 2013 (r1143) @@ -44,6 +44,7 @@ DECLARE_UNNAMED_NODE( ob_pci_bus_node, INSTALL_OPEN, 2*sizeof(int) ); DECLARE_UNNAMED_NODE( ob_pci_simple_node, INSTALL_OPEN, 2*sizeof(int) ); +DECLARE_UNNAMED_NODE( ob_pci_empty_node, 0, 2*sizeof(int) ); const pci_arch_t *arch; @@ -342,6 +343,10 @@ { "close", ob_pci_close }, }; +NODE_METHODS(ob_pci_empty_node) = { + { NULL, ob_pci_initialize } +}; + static void pci_set_bus_range(const pci_config_t *config) { phandle_t dev = find_dev(config->path); @@ -1229,6 +1234,9 @@ REGISTER_NAMED_NODE_PHANDLE(ob_pci_bus_node, config.path, phandle); } break; + case PCI_CLASS_DISPLAY: + REGISTER_NAMED_NODE_PHANDLE(ob_pci_empty_node, config.path, phandle); + break; default: REGISTER_NAMED_NODE_PHANDLE(ob_pci_simple_node, config.path, phandle); break; Modified: trunk/openbios-devel/drivers/pci.h ============================================================================== --- trunk/openbios-devel/drivers/pci.h Sun Jun 9 14:25:03 2013 (r1142) +++ trunk/openbios-devel/drivers/pci.h Sun Jun 9 14:25:08 2013 (r1143) @@ -27,6 +27,7 @@ #define PCI_REVISION_ID 0x08 /* Revision ID */ +#define PCI_CLASS_DISPLAY 0x03 #define PCI_CLASS_PROG 0x09 #define PCI_CLASS_DEVICE 0x0a #define PCI_CACHE_LINE_SIZE 0x0c /* 8 bits */

1 0

[commit] r1142 - in trunk/openbios-devel: arch/sparc32 drivers include/libopenbios include/packages libopenbios packages
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:25:03 2013 New Revision: 1142 URL: http://tracker.coreboot.org/trac/openbios/changeset/1142 Log: video_common.c: Move primitive graphic operations into libopenbios/video_common.c. Remove several more low-level graphic primitives from packages/video.c into libopenbios/video_common.c. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/openbios.c trunk/openbios-devel/drivers/vga_vbe.c trunk/openbios-devel/include/libopenbios/video.h trunk/openbios-devel/include/packages/video.h trunk/openbios-devel/libopenbios/video_common.c trunk/openbios-devel/packages/video.c Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Sun Jun 9 14:24:59 2013 (r1141) +++ trunk/openbios-devel/arch/sparc32/openbios.c Sun Jun 9 14:25:03 2013 (r1142) @@ -22,7 +22,7 @@ #include "boot.h" #include "romvec.h" #include "openprom.h" -#include "packages/video.h" +#include "libopenbios/video.h" #define NO_QEMU_PROTOS #include "arch/common/fw_cfg.h" #include "arch/sparc32/ofmem_sparc32.h" Modified: trunk/openbios-devel/drivers/vga_vbe.c ============================================================================== --- trunk/openbios-devel/drivers/vga_vbe.c Sun Jun 9 14:24:59 2013 (r1141) +++ trunk/openbios-devel/drivers/vga_vbe.c Sun Jun 9 14:25:03 2013 (r1142) @@ -25,7 +25,7 @@ #include "asm/io.h" #include "libc/vsprintf.h" #include "drivers/vga.h" -#include "packages/video.h" +#include "libopenbios/video.h" #include "libopenbios/ofmem.h" /* VGA init. We use the Bochs VESA VBE extensions */ Modified: trunk/openbios-devel/include/libopenbios/video.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:24:59 2013 (r1141) +++ trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:25:03 2013 (r1142) @@ -1,7 +1,12 @@ +void init_video(unsigned long fb, int width, int height, int depth, int rb); unsigned long get_color(int col_ind); void set_color(int ind, unsigned long color); -void video_mask_blit(void); +void refresh_palette(void); +int video_get_res(int *w, int *h); +void draw_pixel(int x, int y, int colind); +void video_scroll(int height); +void fill_rect(int col_ind, int x, int y, int w, int h); typedef struct osi_fb_info { unsigned long mphys; Modified: trunk/openbios-devel/include/packages/video.h ============================================================================== --- trunk/openbios-devel/include/packages/video.h Sun Jun 9 14:24:59 2013 (r1141) +++ trunk/openbios-devel/include/packages/video.h Sun Jun 9 14:25:03 2013 (r1142) @@ -2,9 +2,6 @@ #define VIDEO_SUBR_H /* packages/video.c */ -int video_get_res(int *w, int *h); -void draw_pixel(int x, int y, int colind); -void video_scroll(int height); -void init_video(unsigned long fb, int width, int height, int depth, int rb); +void molvideo_init(void); #endif /* VIDEO_SUBR_H */ Modified: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:24:59 2013 (r1141) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:25:03 2013 (r1142) @@ -16,6 +16,7 @@ #include "config.h" #include "libopenbios/bindings.h" +#include "libopenbios/ofmem.h" #include "libopenbios/video.h" #include "packages/video.h" #include "drivers/vga.h" @@ -63,3 +64,207 @@ (color & 0xff)); #endif } + +static void +startup_splash( void ) +{ +#ifdef CONFIG_MOL + int fd, s, i, y, x, dx, dy; + int width, height; + char *pp, *p; + char buf[64]; +#endif + + /* only draw logo in 24-bit mode (for now) */ + if( video.fb.depth < 15 ) + return; +#ifdef CONFIG_MOL + for( i=0; i<2; i++ ) { + if( !BootHGetStrResInd("bootlogo", buf, sizeof(buf), 0, i) ) + return; + *(!i ? &width : &height) = atol(buf); + } + + if( (s=width * height * 3) > 0x20000 ) + return; + + if( (fd=open_io("pseudo:,bootlogo")) >= 0 ) { + p = malloc( s ); + if( read_io(fd, p, s) != s ) + printk("bootlogo size error\n"); + close_io( fd ); + + dx = (video.fb.w - width)/2; + dy = (video.fb.h - height)/3; + + pp = (char*)video.fb.mvirt + dy * video.fb.rb + dx * (video.fb.depth >= 24 ? 4 : 2); + + for( y=0 ; y<height; y++, pp += video.fb.rb ) { + if( video.fb.depth >= 24 ) { + unsigned long *d = (unsigned long*)pp; + for( x=0; x<width; x++, p+=3, d++ ) + *d = ((int)p[0] << 16) | ((int)p[1] << 8) | p[2]; + } else if( video.fb.depth == 15 ) { + unsigned short *d = (unsigned short*)pp; + for( x=0; x<width; x++, p+=3, d++ ) { + int col = ((int)p[0] << 16) | ((int)p[1] << 8) | p[2]; + *d = ((col>>9) & 0x7c00) | ((col>>6) & 0x03e0) | ((col>>3) & 0x1f); + } + } + } + free( p ); + } +#else + /* No bootlogo support yet on other platforms */ + return; +#endif +} + +int +video_get_res( int *w, int *h ) +{ + if( !video.has_video ) { + *w = *h = 0; + return -1; + } + *w = video.fb.w; + *h = video.fb.h; + return 0; +} + +void +draw_pixel( int x, int y, int colind ) +{ + char *p = (char*)video.fb.mvirt + video.fb.rb * y; + int color, d = video.fb.depth; + + if( x < 0 || y < 0 || x >= video.fb.w || y >=video.fb.h ) + return; + color = get_color( colind ); + + if( d >= 24 ) + *((unsigned long*)p + x) = color; + else if( d >= 15 ) + *((short*)p + x) = color; + else + *(p + x) = color; +} + +void +video_scroll( int height ) +{ + int i, offs, size, *dest, *src; + + if (height <= 0 || height >= video.fb.h) { + return; + } + offs = video.fb.rb * height; + size = (video.fb.h * video.fb.rb - offs)/16; + dest = (int*)video.fb.mvirt; + src = (int*)(video.fb.mvirt + offs); + + for( i=0; i<size; i++ ) { + dest[0] = src[0]; + dest[1] = src[1]; + dest[2] = src[2]; + dest[3] = src[3]; + dest += 4; + src += 4; + } +} + +void +fill_rect( int col_ind, int x, int y, int w, int h ) +{ + char *pp; + unsigned long col = get_color(col_ind); + + if (!video.has_video || x < 0 || y < 0 || w <= 0 || h <= 0 || + x + w > video.fb.w || y + h > video.fb.h) + return; + + pp = (char*)video.fb.mvirt + video.fb.rb * y; + for( ; h--; pp += video.fb.rb ) { + int ww = w; + if( video.fb.depth == 24 || video.fb.depth == 32 ) { + unsigned long *p = (unsigned long*)pp + x; + while( ww-- ) + *p++ = col; + } else if( video.fb.depth == 16 || video.fb.depth == 15 ) { + unsigned short *p = (unsigned short*)pp + x; + while( ww-- ) + *p++ = col; + } else { + char *p = (char *)(pp + x); + + while( ww-- ) + *p++ = col; + } + } +} + +void +refresh_palette( void ) +{ +#ifdef CONFIG_MOL + if( video.fb.depth == 8 ) + OSI_RefreshPalette(); +#endif +} + +void +init_video( unsigned long fb, int width, int height, int depth, int rb ) +{ + int i; +#if defined(CONFIG_OFMEM) && defined(CONFIG_DRIVER_PCI) + int size; +#endif + phandle_t ph=0, saved_ph=0; + + video.fb.mphys = video.fb.mvirt = fb; + +#if defined(CONFIG_SPARC64) + /* Fix virtual address on SPARC64 somewhere else */ + video.fb.mvirt = 0xfe000000; +#endif + + video.fb.w = width; + video.fb.h = height; + video.fb.depth = depth; + video.fb.rb = rb; + + saved_ph = get_cur_dev(); + while( (ph=dt_iterate_type(ph, "display")) ) { + set_int_property( ph, "width", video.fb.w ); + set_int_property( ph, "height", video.fb.h ); + set_int_property( ph, "depth", video.fb.depth ); + set_int_property( ph, "linebytes", video.fb.rb ); + set_int_property( ph, "address", video.fb.mvirt ); + + activate_dev(ph); + molvideo_init(); + } + video.has_video = 1; + video.pal = malloc( 256 * sizeof(unsigned long) ); + activate_dev(saved_ph); + + PUSH(video.fb.mvirt); + feval("to frame-buffer-adr"); + +#if defined(CONFIG_OFMEM) && defined(CONFIG_DRIVER_PCI) + size = ((video.fb.h * video.fb.rb) + 0xfff) & ~0xfff; + + ofmem_claim_phys( video.fb.mphys, size, 0 ); + ofmem_claim_virt( video.fb.mvirt, size, 0 ); + ofmem_map( video.fb.mphys, video.fb.mvirt, size, ofmem_arch_io_translation_mode(video.fb.mphys) ); +#endif + + for( i=0; i<256; i++ ) + set_color( i, i * 0x010101 ); + + set_color( 254, 0xffffcc ); + fill_rect( 254, 0, 0, video.fb.w, video.fb.h ); + + refresh_palette(); + startup_splash(); +} Modified: trunk/openbios-devel/packages/video.c ============================================================================== --- trunk/openbios-devel/packages/video.c Sun Jun 9 14:24:59 2013 (r1141) +++ trunk/openbios-devel/packages/video.c Sun Jun 9 14:25:03 2013 (r1142) @@ -25,153 +25,6 @@ #include "drivers/vga.h" -int -video_get_res( int *w, int *h ) -{ - if( !video.has_video ) { - *w = *h = 0; - return -1; - } - *w = video.fb.w; - *h = video.fb.h; - return 0; -} - -static void -startup_splash( void ) -{ -#ifdef CONFIG_MOL - int fd, s, i, y, x, dx, dy; - int width, height; - char *pp, *p; - char buf[64]; -#endif - - /* only draw logo in 24-bit mode (for now) */ - if( video.fb.depth < 15 ) - return; -#ifdef CONFIG_MOL - for( i=0; i<2; i++ ) { - if( !BootHGetStrResInd("bootlogo", buf, sizeof(buf), 0, i) ) - return; - *(!i ? &width : &height) = atol(buf); - } - - if( (s=width * height * 3) > 0x20000 ) - return; - - if( (fd=open_io("pseudo:,bootlogo")) >= 0 ) { - p = malloc( s ); - if( read_io(fd, p, s) != s ) - printk("bootlogo size error\n"); - close_io( fd ); - - dx = (video.fb.w - width)/2; - dy = (video.fb.h - height)/3; - - pp = (char*)video.fb.mvirt + dy * video.fb.rb + dx * (video.fb.depth >= 24 ? 4 : 2); - - for( y=0 ; y<height; y++, pp += video.fb.rb ) { - if( video.fb.depth >= 24 ) { - unsigned long *d = (unsigned long*)pp; - for( x=0; x<width; x++, p+=3, d++ ) - *d = ((int)p[0] << 16) | ((int)p[1] << 8) | p[2]; - } else if( video.fb.depth == 15 ) { - unsigned short *d = (unsigned short*)pp; - for( x=0; x<width; x++, p+=3, d++ ) { - int col = ((int)p[0] << 16) | ((int)p[1] << 8) | p[2]; - *d = ((col>>9) & 0x7c00) | ((col>>6) & 0x03e0) | ((col>>3) & 0x1f); - } - } - } - free( p ); - } -#else - /* No bootlogo support yet on other platforms */ - return; -#endif -} - -void -draw_pixel( int x, int y, int colind ) -{ - char *p = (char*)video.fb.mvirt + video.fb.rb * y; - int color, d = video.fb.depth; - - if( x < 0 || y < 0 || x >= video.fb.w || y >=video.fb.h ) - return; - color = get_color( colind ); - - if( d >= 24 ) - *((unsigned long*)p + x) = color; - else if( d >= 15 ) - *((short*)p + x) = color; - else - *(p + x) = color; -} - -static void -fill_rect( int col_ind, int x, int y, int w, int h ) -{ - char *pp; - unsigned long col = get_color(col_ind); - - if (!video.has_video || x < 0 || y < 0 || w <= 0 || h <= 0 || - x + w > video.fb.w || y + h > video.fb.h) - return; - - pp = (char*)video.fb.mvirt + video.fb.rb * y; - for( ; h--; pp += video.fb.rb ) { - int ww = w; - if( video.fb.depth == 24 || video.fb.depth == 32 ) { - unsigned long *p = (unsigned long*)pp + x; - while( ww-- ) - *p++ = col; - } else if( video.fb.depth == 16 || video.fb.depth == 15 ) { - unsigned short *p = (unsigned short*)pp + x; - while( ww-- ) - *p++ = col; - } else { - char *p = (char *)(pp + x); - - while( ww-- ) - *p++ = col; - } - } -} - -static void -refresh_palette( void ) -{ -#ifdef CONFIG_MOL - if( video.fb.depth == 8 ) - OSI_RefreshPalette(); -#endif -} - -void -video_scroll( int height ) -{ - int i, offs, size, *dest, *src; - - if (height <= 0 || height >= video.fb.h) { - return; - } - offs = video.fb.rb * height; - size = (video.fb.h * video.fb.rb - offs)/16; - dest = (int*)video.fb.mvirt; - src = (int*)(video.fb.mvirt + offs); - - for( i=0; i<size; i++ ) { - dest[0] = src[0]; - dest[1] = src[1]; - dest[2] = src[2]; - dest[3] = src[3]; - dest += 4; - src += 4; - } -} - /************************************************************************/ /* OF methods */ /************************************************************************/ @@ -259,54 +112,7 @@ /************************************************************************/ void -init_video( unsigned long fb, int width, int height, int depth, int rb ) +molvideo_init(void) { - int i; -#if defined(CONFIG_OFMEM) && defined(CONFIG_DRIVER_PCI) - int size; -#endif - phandle_t ph=0; - - video.fb.mphys = video.fb.mvirt = fb; - -#if defined(CONFIG_SPARC64) - /* Fix virtual address on SPARC64 somewhere else */ - video.fb.mvirt = 0xfe000000; -#endif - - video.fb.w = width; - video.fb.h = height; - video.fb.depth = depth; - video.fb.rb = rb; - while( (ph=dt_iterate_type(ph, "display")) ) { - set_int_property( ph, "width", video.fb.w ); - set_int_property( ph, "height", video.fb.h ); - set_int_property( ph, "depth", video.fb.depth ); - set_int_property( ph, "linebytes", video.fb.rb ); - set_int_property( ph, "address", video.fb.mvirt ); - } - video.has_video = 1; - video.pal = malloc( 256 * sizeof(unsigned long) ); - - PUSH(video.fb.mvirt); - feval("to frame-buffer-adr"); - -#if defined(CONFIG_OFMEM) && defined(CONFIG_DRIVER_PCI) - size = ((video.fb.h * video.fb.rb) + 0xfff) & ~0xfff; - - ofmem_claim_phys( video.fb.mphys, size, 0 ); - ofmem_claim_virt( video.fb.mvirt, size, 0 ); - ofmem_map( video.fb.mphys, video.fb.mvirt, size, ofmem_arch_io_translation_mode(video.fb.mphys) ); -#endif - - for( i=0; i<256; i++ ) - set_color( i, i * 0x010101 ); - - set_color( 254, 0xffffcc ); - fill_rect( 254, 0, 0, video.fb.w, video.fb.h ); - - refresh_palette(); - startup_splash(); - REGISTER_NODE( video ); }

1 0

[commit] r1141 - in trunk/openbios-devel: include/libopenbios include/packages libopenbios packages
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:24:59 2013 New Revision: 1141 URL: http://tracker.coreboot.org/trac/openbios/changeset/1141 Log: video: Create new video_common.c file for shared video primitive routines. Start by moving the get_color() and set_color() functions into the library. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Added: trunk/openbios-devel/include/libopenbios/video.h trunk/openbios-devel/libopenbios/video_common.c Modified: trunk/openbios-devel/include/packages/video.h trunk/openbios-devel/libopenbios/build.xml trunk/openbios-devel/libopenbios/console_common.c trunk/openbios-devel/packages/video.c Added: trunk/openbios-devel/include/libopenbios/video.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/include/libopenbios/video.h Sun Jun 9 14:24:59 2013 (r1141) @@ -0,0 +1,16 @@ + +unsigned long get_color(int col_ind); +void set_color(int ind, unsigned long color); +void video_mask_blit(void); + +typedef struct osi_fb_info { + unsigned long mphys; + unsigned long mvirt; + int rb, w, h, depth; +} osi_fb_info_t; + +extern struct video_info { + int has_video; + osi_fb_info_t fb; + unsigned long *pal; /* 256 elements */ +} video; Modified: trunk/openbios-devel/include/packages/video.h ============================================================================== --- trunk/openbios-devel/include/packages/video.h Sun Jun 9 14:24:57 2013 (r1140) +++ trunk/openbios-devel/include/packages/video.h Sun Jun 9 14:24:59 2013 (r1141) @@ -4,7 +4,6 @@ /* packages/video.c */ int video_get_res(int *w, int *h); void draw_pixel(int x, int y, int colind); -void set_color(int ind, unsigned long color); void video_scroll(int height); void init_video(unsigned long fb, int width, int height, int depth, int rb); Modified: trunk/openbios-devel/libopenbios/build.xml ============================================================================== --- trunk/openbios-devel/libopenbios/build.xml Sun Jun 9 14:24:57 2013 (r1140) +++ trunk/openbios-devel/libopenbios/build.xml Sun Jun 9 14:24:59 2013 (r1141) @@ -20,6 +20,7 @@ <object source="linuxbios_info.c" condition="LINUXBIOS"/> <object source="ofmem_common.c" condition="OFMEM"/> <object source="xcoff_load.c" condition="LOADER_XCOFF"/> + <object source="video_common.c"/> </library> <dictionary name="openbios" target="forth"> Modified: trunk/openbios-devel/libopenbios/console_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/console_common.c Sun Jun 9 14:24:57 2013 (r1140) +++ trunk/openbios-devel/libopenbios/console_common.c Sun Jun 9 14:24:59 2013 (r1141) @@ -16,6 +16,7 @@ #include "libopenbios/bindings.h" #include "libopenbios/fontdata.h" #include "libopenbios/console.h" +#include "libopenbios/video.h" #include "packages/video.h" #define FONT_ADJ_HEIGHT (FONT_HEIGHT + 2) Added: trunk/openbios-devel/libopenbios/video_common.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/libopenbios/video_common.c Sun Jun 9 14:24:59 2013 (r1141) @@ -0,0 +1,65 @@ +/* + * Creation Date: <2002/10/23 20:26:40 samuel> + * Time-stamp: <2004/01/07 19:39:15 samuel> + * + * <video_common.c> + * + * Shared video routines + * + * Copyright (C) 2002, 2003, 2004 Samuel Rydh (samuel(a)ibrium.se) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation + * + */ + +#include "config.h" +#include "libopenbios/bindings.h" +#include "libopenbios/video.h" +#include "packages/video.h" +#include "drivers/vga.h" + +struct video_info video; + +unsigned long +get_color( int col_ind ) +{ + unsigned long col; + if( !video.has_video || col_ind < 0 || col_ind > 255 ) + return 0; + if( video.fb.depth == 8 ) + return col_ind; + col = video.pal[col_ind]; + if( video.fb.depth == 24 || video.fb.depth == 32 ) + return col; + if( video.fb.depth == 15 ) + return ((col>>9) & 0x7c00) | ((col>>6) & 0x03e0) | ((col>>3) & 0x1f); + return 0; +} + +void +set_color( int ind, unsigned long color ) +{ + if( !video.has_video || ind < 0 || ind > 255 ) + return; + video.pal[ind] = color; + +#ifdef CONFIG_MOL + if( video.fb.depth == 8 ) + OSI_SetColor( ind, color ); +#elif defined(CONFIG_SPARC32) +#if defined(CONFIG_DEBUG_CONSOLE_VIDEO) + if( video.fb.depth == 8 ) { + dac[0] = ind << 24; + dac[1] = ((color >> 16) & 0xff) << 24; // Red + dac[1] = ((color >> 8) & 0xff) << 24; // Green + dac[1] = (color & 0xff) << 24; // Blue + } +#endif +#else + vga_set_color(ind, ((color >> 16) & 0xff), + ((color >> 8) & 0xff), + (color & 0xff)); +#endif +} Modified: trunk/openbios-devel/packages/video.c ============================================================================== --- trunk/openbios-devel/packages/video.c Sun Jun 9 14:24:57 2013 (r1140) +++ trunk/openbios-devel/packages/video.c Sun Jun 9 14:24:59 2013 (r1141) @@ -20,21 +20,10 @@ #include "libopenbios/ofmem.h" #include "drivers/drivers.h" #include "packages/video.h" +#include "libopenbios/video.h" #include "libopenbios/console.h" #include "drivers/vga.h" -typedef struct osi_fb_info { - unsigned long mphys; - unsigned long mvirt; - int rb, w, h, depth; -} osi_fb_info_t; - -static struct { - int has_video; - osi_fb_info_t fb; - unsigned long *pal; /* 256 elements */ -} video; - int video_get_res( int *w, int *h ) @@ -103,22 +92,6 @@ #endif } -static unsigned long -get_color( int col_ind ) -{ - unsigned long col; - if( !video.has_video || col_ind < 0 || col_ind > 255 ) - return 0; - if( video.fb.depth == 8 ) - return col_ind; - col = video.pal[col_ind]; - if( video.fb.depth == 24 || video.fb.depth == 32 ) - return col; - if( video.fb.depth == 15 ) - return ((col>>9) & 0x7c00) | ((col>>6) & 0x03e0) | ((col>>3) & 0x1f); - return 0; -} - void draw_pixel( int x, int y, int colind ) { @@ -176,32 +149,6 @@ #endif } -void -set_color( int ind, unsigned long color ) -{ - if( !video.has_video || ind < 0 || ind > 255 ) - return; - video.pal[ind] = color; - -#ifdef CONFIG_MOL - if( video.fb.depth == 8 ) - OSI_SetColor( ind, color ); -#elif defined(CONFIG_SPARC32) -#if defined(CONFIG_DEBUG_CONSOLE_VIDEO) - if( video.fb.depth == 8 ) { - dac[0] = ind << 24; - dac[1] = ((color >> 16) & 0xff) << 24; // Red - dac[1] = ((color >> 8) & 0xff) << 24; // Green - dac[1] = (color & 0xff) << 24; // Blue - } -#endif -#else - vga_set_color(ind, ((color >> 16) & 0xff), - ((color >> 8) & 0xff), - (color & 0xff)); -#endif -} - void video_scroll( int height ) {

1 0

[commit] r1140 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:24:57 2013 New Revision: 1140 URL: http://tracker.coreboot.org/trac/openbios/changeset/1140 Log: terminal.fs: Fix backspace sequence in Forth terminal. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/terminal.fs Modified: trunk/openbios-devel/forth/device/terminal.fs ============================================================================== --- trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:24:54 2013 (r1139) +++ trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:24:57 2013 (r1140) @@ -215,9 +215,9 @@ endof 8 of \ BS column# 0<> if - column# 1- dup + column# dup to column# - 20 draw-character + 20 draw-character 1- to column# then endof

1 0

[commit] r1139 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:24:54 2013 New Revision: 1139 URL: http://tracker.coreboot.org/trac/openbios/changeset/1139 Log: terminal.fs: Fix linefeeds on the bottom line of the Forth console. Fix cursor position when a linefeed is entered on the bottom line. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/terminal.fs Modified: trunk/openbios-devel/forth/device/terminal.fs ============================================================================== --- trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:24:52 2013 (r1138) +++ trunk/openbios-devel/forth/device/terminal.fs Sun Jun 9 14:24:54 2013 (r1139) @@ -230,6 +230,12 @@ endof a of \ LF line# 1+ to line# 0 to column# + line# #lines >= if + line# 1- + 0 to line# + 1 delete-lines + to line# + then endof b of \ VT line# 0<> if

1 0

[commit] r1138 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:24:52 2013 New Revision: 1138 URL: http://tracker.coreboot.org/trac/openbios/changeset/1138 Log: display.fs: Fix fb8-delete-lines within the inbuilt Forth terminal emulator. This enables us to provide a basic scrolling console terminal. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:24:50 2013 (r1137) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:24:52 2013 (r1138) @@ -226,12 +226,12 @@ dup #columns = if drop 0 to column# line# 1+ - dup #lines = if - drop - \ FIXME move up screen (and keep position) - else - to #lines + dup #lines >= if + line# + 0 to line# + 1 delete-lines then + to line# else to column# then @@ -295,12 +295,12 @@ : fb8-delete-lines ( n -- ) \ numcopy = ( #lines - ( line# + n )) * char-height - #lines over #line + - char-height * + #lines over line# + - char-height * ( numcopy ) 0 ?do dup line# + char-height * i + line# char-height * i + - swap fb8-copy-line + fb8-copy-line loop #lines over - char-height *

1 0

[commit] r1137 - trunk/openbios-devel/forth/device
by repository service 09 Jun '13

09 Jun '13

Author: mcayland Date: Sun Jun 9 14:24:50 2013 New Revision: 1137 URL: http://tracker.coreboot.org/trac/openbios/changeset/1137 Log: display.fs: Fix up default-font word. This enables us to execute "default-font set-font" as per the the IEEE1275 specification. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/display.fs trunk/openbios-devel/forth/device/font.fs Modified: trunk/openbios-devel/forth/device/display.fs ============================================================================== --- trunk/openbios-devel/forth/device/display.fs Sat May 4 13:01:04 2013 (r1136) +++ trunk/openbios-devel/forth/device/display.fs Sun Jun 9 14:24:50 2013 (r1137) @@ -68,7 +68,7 @@ \ : default-font ( -- addr width height advance min-char #glyphs ) - \ (romfont-8x16) 8 10 10 0 100 + (romfont) (romfont-width) (romfont-height) (romfont-height) 0 100 ; : set-font ( addr width height advance min-char #glyphs -- ) Modified: trunk/openbios-devel/forth/device/font.fs ============================================================================== --- trunk/openbios-devel/forth/device/font.fs Sat May 4 13:01:04 2013 (r1136) +++ trunk/openbios-devel/forth/device/font.fs Sun Jun 9 14:24:50 2013 (r1137) @@ -9,5 +9,9 @@ \ the copyright and warranty status of this work. \ +0 value (romfont) +0 value (romfont-width) +0 value (romfont-height) + \ encode-file romfont.bin \ drop value (romfont-8x16)

1 0

Re: [OpenBIOS] [PATCHv2 00/20] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 02 Jun '13

02 Jun '13

On 01/06/13 17:21, Blue Swirl wrote: (lots cut) > Otherwise the patches look fine. Thanks for the review. I've fixed up the whitespace and linker issues, which leaves only the Debian 3.1r1 character issue (which is probably an unimplemented escape code). Are you happy for me to fix that up a bit later? At the moment I've got several in-progress patchsets related to the terminal/console of which this is the biggest, so it would help a lot to get it committed. ATB, Mark.

2 1

[PATCH] Building OpenBIOS on Mac OS X
by Programmingkid 10 May '13

10 May '13

This patch allows for building OpenBIOS on Mac OS X, but without the "Trying" output. It has been tested on Mac OS 10.6 and Debian Linux. signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Index: trunk/openbios-devel/config/scripts/switch-arch =================================================================== --- trunk/openbios-devel/config/scripts/switch-arch (revision 1133) +++ trunk/openbios-devel/config/scripts/switch-arch (working copy) @@ -89,15 +89,25 @@ archname() { - HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ - -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ - -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ - -e "s/Power Macintosh/ppc/"` + OS_NAME=`uname` + if test "$OS_NAME" = "Darwin"; then # Can't depend on uname -m on Mac OS X + IS_64BIT=`sysctl hw.cpu64bit_capable` + if test "$IS_64BIT" = "hw.cpu64bit_capable: 1"; then + HOSTARCH="amd64" + else + HOSTARCH="x86" + fi + else + HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ + -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ + -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ + -e "s/Power Macintosh/ppc/"` + fi } select_prefix() { - for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- ppc-elf- do if type ${TARGET}gcc > /dev/null 2>&1 then

3 2

Re: [OpenBIOS] [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation
by Blue Swirl 09 May '13

09 May '13

On Tue, May 7, 2013 at 5:48 AM, Hervé Poussineau <hpoussin(a)reactos.org> wrote: > Andreas Färber a écrit : > >> Am 06.05.2013 22:57, schrieb Hervé Poussineau: >>> >>> Alexander Graf a écrit : >>>> >>>> On 05/03/2013 07:57 AM, Hervé Poussineau wrote: >>>>> >>>>> Alexander Graf a écrit : >>>>>> >>>>>> Am 02.05.2013 um 22:08 schrieb Hervé Poussineau >>>>>> <hpoussin(a)reactos.org>: >>>>>> >>>>>>> Non-contiguous I/O is not implemented. >>>>>>> >>>>>>> There is also somewhere a bug in the memory controller, which means >>>>>>> that some real firmwares may not detect the correct amount of memory. >>>>>>> This can be bypassed by adding '-m 1G' on the command line. >>>>>>> >>>>>>> Add x-auto-conf property, to automatically configure the memory >>>>>>> controller at startup. This will be required by OpenBIOS, which >>>>>>> doesn't know how to do it. >>>>>> >>>>>> Why not teach it? I'd prefer to see that logic in firmware. >>>>> >>>>> Me too, but I'm not confident enough in my capabilities to do it. >>>> >>>> Huh? Why not? Most of the device initialization code in OpenBIOS >>>> happens in C, so you don't even have to touch Forth code :). >>>> >>>>> Autoconfiguration is only in one place of the code, so I think it can >>>>> be removed easily once OpenBIOS has this logic. >>>> >>>> I'd prefer if we could come up with a clean model from the start. It >>>> really shouldn't be hard at all. >>>> >>> I thought that for all other usages of OpenBIOS in QEMU, RAM was >>> supposed to be available as soon as machine was powered on. >>> >>> However, I checked OpenBIOS code: >>> One of the first things done in arch/ppc/qemu/start.S is to copy the >>> exception vectors. So, I should add code before it to detect memory >>> controller, detect ram size and configure memory controller? >> >> >> No. Why? QEMU does not depend on the memory controller being >> initialized, only the OS might expect some registers to be filled in. So >> you should look at or add the MPC105 PHB initialization hook in >> OpenBIOS' PCI code, long after the memory is set up. > > > OpenBIOS depends of memory being available (at least the first KB/MB) even > at its very startup, in arch/ppc/qemu/start.S. PCI initialization code comes > much later. OpenBIOS for Sparc32 and Sparc64 does not use RAM before RAM size has been read from fw_cfg. A check for QEMU signature is done and machine ID is also read before that. arch/sparc32/entry.S arch/sparc64/entry.S It should be easy to change PPC to check the machine ID before accessing RAM. > At boot, MPC105 datasheet says that memory controller is not configured, ie > you have to not use RAM in OpenBIOS before PCI initialization. The memory controller should be initialized much earlier than PCI. > > For other PPC targets (mac99, g3beige) using OpenBIOS, RAM is accessible at > startup, so that's not a problem for OpenBIOS. > > So, no, QEMU does not depend of the memory controller being initialized, but > OpenBIOS depends of the RAM being accessible ways before PCI initialization. > I don't speak of the OS which might (or might not) expect some registers to > be filled in. > x-auto-conf property correctly sets some registers, so that memory is > available at startup (like on mac99, g3beige emulations). > > Hervé >

1 0

Re: [OpenBIOS] Patch that allows for building OpenBIOS on Mac OS X!
by Segher Boessenkool 09 May '13

09 May '13

>>> archname() >>> { >>> - HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ >>> - -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ >>> - -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ >>> - -e "s/Power Macintosh/ppc/"` >>> + OS_NAME=`uname` >>> + if test "$OS_NAME" = "Darwin"; then # Can't depend on uname >>> -m on Mac OS X >>> + IS_64BIT=`sysctl hw.cpu64bit_capable` >>> + if test "$IS_64BIT" = "hw.cpu64bit_capable: 1"; then >>> + HOSTARCH="amd64" >>> + else >>> + HOSTARCH="x86" >>> + fi >>> + else >>> + HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ >>> + -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ >>> + -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ >>> + -e "s/Power Macintosh/ppc/"` >>> + fi >>> } >> >> This is wrong. "uname" does not tell you the machine architecture; >> "uname -m" does, at least on my PowerPC Macs. Also: > > Who said I was trying to obtain the machine architecture? That is what this function does. > As I said in the comment you can't depend on uname -m on Mac OS X. > It will not tell you if the architecture is 64 bit or 32 bit. And ignoring it does not tell you if the machine is x86 at all, which you just blindly assume. It might work for you, but it is just wrong and breaks things for other people. > Do you even use Mac OS X? Yes I do. > The hw.cpu64bit_capable will tell you that information. > >> $ sysctl hw.cpu64bit_capable >> second level name cpu64bit_capable in hw.cpu64bit_capable is invalid > > I don't know what you are using, but on Mac OS 10.6 and up it is > valid. Are you even using Mac OS X? If so, what version? It might > be possible to build OpenBIOS on Mac OS 10.5, but I really doubt > anything before that would work. It is not valid on any OSX version; it is only valid on x86. Everything builds fine on 10.3 and 10.4, fwiw. >>> select_prefix() >>> { >>> - for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}- >>> linux- ${1}-elf- ${1}-eabi- >>> + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}- >>> linux- ${1}-elf- ${1}-eabi- ppc-elf- >> >> This is also wrong. ppc-elf is neither a canonical nor a common >> prefix. >> Whoever built your toolchain was hellbent on making life difficult >> for >> the users of said toolchain. > > WHAT? Just because you don't like the name doesn't make it wrong. Let's add a "butterfly-cherry-blossom-sortofelf-" prefix as well! I have many toolchains with custom program prefixes; I don't expect the openbios scripts to automatically pick those up, either. It is not going to scale... > In the end you are wrong about most of the issues you brought up. I > would appreciate it if you kept your comments to yourself. Thank you. Segher

1 0

OpenBIOS 1.1 release
by Mark Cave-Ayland 04 May '13

04 May '13

After 4 years of hard work, the OpenBIOS team are proud to announce the release of OpenBIOS 1.1. Since the last release, over 600 commits have been made to the SVN repository with a wealth of improvements and new features. As a result of these changes, the ability of OpenBIOS 1.1 to boot various kernels under QEMU has significantly improved. Multi-architecture features =========================== - Internal memory API (OFMEM) implementation All main architectures in OpenBIOS have been migrated to a new shared OFMEM API rather than maintaining their own individual implementations. This API handles both internal and external memory allocations, and automatically handles generation of the relevant memory and virtual-memory node properties required for clients. - Forth Source Debugger A basic Forth source debugger is included that can be used to step through Forth words which are marked using the debug word. Once the source debugger has been entered, it is possible to step up, step down, drop to a Forth interpreter shell or continue execution whilst viewing the current stack contents. - 64-bit 1275 6d5 implementation OpenBIOS now contains the additional 64-bit word set required by some bootloaders. - Forth Local Variables In order to support bootloaders such as Apple's BootX, OpenBIOS now contains an implementation of Forth local variables. - Internal libopenbios code reorganisation Over time, a lot of the code related to loading executable files had been forked for each individual architecture, e.g. ELF loader. The codebase has been substantially refactored so that the individual forks have been combined in a centralised libopenbios meaning that a substantial portion of duplicate code has been removed from each architecture. SPARC32 compatibility ===================== OpenBIOS SPARC32 is currently able to boot the following OS/kernels: * Linux * NetBSD * OpenBSD * Some later versions of Solaris (Solaris 8 and early Solaris 9 are known to work) SPARC64 compatibility ===================== OpenBIOS SPARC64 is currently able to boot the following OS/kernels: * Linux (with virtio drivers) Many thanks to Artyom Tarasenko for making this possible. PPC compatibility ================= OpenBIOS PPC is currently able to boot the following OS/kernels: * Linux * HelenOS The following kernels will partially boot, but still suffer from some emulation bugs under QEMU: * FreeBSD * NetBSD * Darwin/OS X Many thanks to William Hahne and his mentor, Natalia Portillo, for contributing the patches required to support Darwin/OS X kernel boot in OpenBIOS as part of the Google Summer Of Code. PPC64 compatibility =================== OpenBIOS PPC64 is currently experimental but should be capable of executing some bootloaders. Please report details of any testing to the OpenBIOS/QEMU mailing lists. Credits ======= Many thanks to everyone who has contributed to OpenBIOS by providing bug reports, patches or testing. In particular the team would like to thank (in alphabetical order): John Arbuckle Segher Boessenkool Mark Cave-Ayland Olivier Danet Andreas Färber Alexander Graf William Hahne Igor Kovalenko Tarl Neustaedter Natalia Portillo Stefan Reinauer Amadeusz Sławiński Blue Swirl Artyom Tarasenko Andreas Tober Laurent Vivier Please visit http://www.openfirmware.info/ for more information on OpenBIOS.

1 0

[commit] r1136 - tags/openbios-1.1
by repository service 04 May '13

04 May '13

Author: blueswirl Date: Sat May 4 13:01:04 2013 New Revision: 1136 URL: http://tracker.coreboot.org/trac/openbios/changeset/1136 Log: Tag version 1.1 Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Added: tags/openbios-1.1/ - copied from r1135, trunk/openbios-devel/

1 0

[commit] r1135 - trunk/openbios-devel
by repository service 04 May '13

04 May '13

Author: blueswirl Date: Sat May 4 12:56:49 2013 New Revision: 1135 URL: http://tracker.coreboot.org/trac/openbios/changeset/1135 Log: Bump version to 1.1 Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/VERSION Modified: trunk/openbios-devel/VERSION ============================================================================== --- trunk/openbios-devel/VERSION Fri May 3 23:45:00 2013 (r1134) +++ trunk/openbios-devel/VERSION Sat May 4 12:56:49 2013 (r1135) @@ -1 +1 @@ -1.0 +1.1

1 0

About udelay
by Programmingkid 04 May '13

04 May '13

I see that you used a loop to simulate a wait time. I think there must be a better way of doing it. Doesn't the Sparc emulator have access to a hardware clock that we can use instead of a loop?

3 3

[commit] r1134 - trunk/openbios-devel/arch/sparc64
by repository service 03 May '13

03 May '13

Author: mcayland Date: Fri May 3 23:45:00 2013 New Revision: 1134 URL: http://tracker.coreboot.org/trac/openbios/changeset/1134 Log: SPARC64: Add trivial implementation of udelay() The OpenBIOS IDE driver calls udelay() in order to wait for IDE transfers to complete. Without an implementation of udelay(), the IDE timeout is too low causing sporadic errors during periods of high I/O activity. As reported by Artyom Tarasenko. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc64/openbios.c Modified: trunk/openbios-devel/arch/sparc64/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/openbios.c Sat Apr 27 13:42:18 2013 (r1133) +++ trunk/openbios-devel/arch/sparc64/openbios.c Fri May 3 23:45:00 2013 (r1134) @@ -547,6 +547,9 @@ void udelay(unsigned int usecs) { + volatile int i; + + for (i = 0; i < usecs * 100; i++); } static void init_memory(void)

1 0

Re: [OpenBIOS] Read errors from SILO booting Debian Wheezy/sparc64
by Mark Cave-Ayland 28 Apr '13

28 Apr '13

On 27/04/13 07:06, Artyom Tarasenko wrote: >> Is this a regression? If so, what was the last know good revision? > > Doesn't look like a regression. Checked the OpenBIOS image packaged with QEMU > (they didn't update it recently) and it fails too. > Just haven't tested it before. Usually I boot from a CD/DVD image or > load the kernel directly with the -kernel option. Ha okay - I finally figured this one out with a reproducible test case like this: 1) First drop the Linux filesystem cache: echo 3 > /proc/sys/vm/drop_caches 2) Start up QEMU - this now blows up in SILO: ./qemu-system-sparc64 -hda /home/build/src/qemu/image/sparc64/debian-wheezy.qcow2 -boot c -nographic -snapshot 3) Load the debian-wheezy.qcow2 image into the filesystem cache cat debian-wheezy.qcow2 > /dev/null 4) Restart QEMU again and the image boots ./qemu-system-sparc64 -hda /home/build/src/qemu/image/sparc64/debian-wheezy.qcow2 -boot c -nographic -snapshot Once I could reproduce this at will, I recompiled OpenBIOS with CONFIG_DEBUG_IDE enabled and got the following output: Jumping to entry point 0000000000004000 for type 0000000000000005... switching to new context: entry point 0x4000 stack 0x00000000ffe86a39 SIDE - ob_ide_open: opening channel -1539032 unit 0 IDE DRIVE @ffe88428: unit: 0 present: 1 type: 1 media: 32 model: QEMU HARDDISK nr: 0 cyl: 8322 head: 16 sect: 63 bs: 512 IDE - ob_ide_block_size: ob_ide_block_size: block size 200 IDE - ob_ide_max_transfer: max_transfer 1fe00 IDE - ob_ide_read_blocks: ob_ide_read_blocks ffe86b20 block=0 n=1 IDE - ob_ide_read_sectors: ob_ide_read_sectors: block=0 sectors=1 IDE - ob_ide_read_blocks: ob_ide_read_blocks ffe86b20 block=0 n=1 IDE - ob_ide_read_sectors: ob_ide_read_sectors: block=0 sectors=1 IDE - ob_ide_read_blocks: ob_ide_read_blocks ffea9e98 block=2 n=2 IDE - ob_ide_read_sectors: ob_ide_read_sectors: block=2 sectors=2 IDE - ob_ide_read_blocks: ob_ide_read_blocks 41dc block=5248 n=1 IDE - ob_ide_read_sectors: ob_ide_read_sectors: block=5248 sectors=1 IDE - ob_ide_error: ob_ide_error drive<0>: timed out waiting for BUSY clear: IDE - ob_ide_error: cmd=20, stat=d0IDE - ob_ide_error: IDE - ob_ide_pio_data_in: bytes=512, stat=d0 IDE - ob_ide_read_blocks: ob_ide_read_blocks: error EXIT 0 > Looking at drivers/ide.c, it was apparent that we were timing out waiting for the IDE event to finish: /* * wait for BUSY clear */ if (ob_ide_wait_stat(drive, 0, BUSY_STAT | ERR_STAT, &stat)) { ob_ide_error(drive, stat, "timed out waiting for BUSY clear"); cmd->stat = stat; break; } And ob_ide_wait_stat() has a loop that looks like this: for (i = 0; i < 5000; i++) { stat = ob_ide_pio_readb(drive, IDEREG_STATUS); if (!(stat & BUSY_STAT)) break; udelay(1000); } This led me to wonder if there was a problem with udelay() returning too quickly and so I had a look at the implementation in arch/sparc64/openbios.c which looks like this: void udelay(unsigned int usecs) { } Ah. So the problem is that we are not waiting long enough for the IDE command to finish which is why we are getting the error. A quick patch to get things working again for me is: --- a/openbios-devel/arch/sparc64/openbios.c +++ b/openbios-devel/arch/sparc64/openbios.c @@ -547,6 +547,9 @@ void setup_timers(void) void udelay(unsigned int usecs) { + volatile int i; + + for (i = 0; i < usecs * 100; i++); } But we probably need a better solution for this that works for both SPARC32 and SPARC64. I've seen some code that waits for the RTC to tick 1s and measures the number of loop iterations within that time to find a basic timing constant which looks quite appealing as it is simple and will work across both SPARC32 and SPARC64 (SPARC32 doesn't have a %tick register). Blue - any thoughts on how to implement this? ATB, Mark.

2 1

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Artyom Tarasenko 28 Apr '13

28 Apr '13

On Sat, Apr 20, 2013 at 1:05 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Fri, Apr 19, 2013 at 9:10 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Mon, May 14, 2012 at 8:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> On Mon, May 14, 2012 at 1:49 PM, Mark Cave-Ayland >>> <mark.cave-ayland(a)ilande.co.uk> wrote: >>>> On 14/05/12 14:28, Artyom Tarasenko wrote: >>>> >>>>>>> It's to avoid VGA legacy mapping at 0xa0000. If I change >>>>>>> hwdefs.pci.pci_mem_base in arch/sparc64/openbios.c to 0, OpenBIOS will >>>>>>> crash during VGA init. Previously this worked because the PCI devices >>>>>>> were mapped somewhat randomly and by chance, VGA legacy low mem area >>>>>>> was avoided. >>>>>>> >>>>>>> I think the correct fix is to make QEMU VGA device disable the legacy >>>>>>> mapping unless explicitly enabled. Alternatively the child base >>>>>>> arithmetic could be fixed in OpenBIOS like proposed by Jakub. >>>>>> >>>>>> >>>>>> >>>>>> Did a patch ever come out of this discussion in the end? >>>>>> >>>>> >>>>> No. :-) Feel free to fix it, unless Blue prefers fixing it himself... >>>> >>>> >>>> I'm not sure I'm confident enough with PCI to do this, and I'm also not sure >>>> what Blue's recommended fix actually is? Is it to increase parent_base by >>>> 0x1000 or set child_base to zero? >>> >>> The best solution is to fix VGA (assuming my analysis was right) and >>> set child_base to zero. >> >> Blue, do you know whether the QOMification improved the situation with >> the legacy VGA low mem area? > > I don't think it had any effect, but PCI bridging code was fixed recently. > > There are still some problems, if I move most devices behind the first > bridge with this patch, Sparc64 does not boot anymore: > diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c > index 0d29620..8bf7230 100644 > --- a/hw/sparc64/sun4u.c > +++ b/hw/sparc64/sun4u.c > @@ -813,7 +813,7 @@ static void sun4uv_init(MemoryRegion *address_space_mem, > M48t59State *nvram; > unsigned int i; > uint64_t initrd_addr, initrd_size, kernel_addr, kernel_size, kernel_entry; > - PCIBus *pci_bus, *pci_bus2, *pci_bus3; > + PCIBus *pci_bus2, *pci_bus3; > ISABus *isa_bus; > qemu_irq *ivec_irqs, *pbm_irqs; > DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS]; > @@ -829,12 +829,11 @@ static void sun4uv_init(MemoryRegion *address_space_mem, > prom_init(hwdef->prom_addr, bios_name); > > ivec_irqs = qemu_allocate_irqs(cpu_set_ivec_irq, cpu, IVEC_MAX); > - pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, ivec_irqs, > &pci_bus2, > - &pci_bus3, &pbm_irqs); > - pci_vga_init(pci_bus); > + pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, ivec_irqs, &pci_bus2, > + &pci_bus3, &pbm_irqs); > + pci_vga_init(pci_bus2); > > - // XXX Should be pci_bus3 > - isa_bus = pci_ebus_init(pci_bus, -1, pbm_irqs); > + isa_bus = pci_ebus_init(pci_bus2, -1, pbm_irqs); > > i = 0; > if (hwdef->console_serial_base) { > @@ -859,7 +858,7 @@ static void sun4uv_init(MemoryRegion *address_space_mem, > > ide_drive_get(hd, MAX_IDE_BUS); > > - pci_cmd646_ide_init(pci_bus, hd, 1); > + pci_cmd646_ide_init(pci_bus2, hd, 1); > > isa_create_simple(isa_bus, "i8042"); > for(i = 0; i < MAX_FD; i++) { > > Also ethernet is using the main PCI bus instead of the bridged version: > (qemu) info pci > Bus 0, device 0, function 0: > Host bridge: PCI device 108e:a000 > id "" > Bus 0, device 1, function 0: > PCI bridge: PCI device 108e:5000 > BUS 0. > secondary bus 1. > subordinate bus 255. > IO range [0x0000, 0x0fff] > memory range [0x00000000, 0x000fffff] > prefetchable memory range [0x00000000, 0x000fffff] > id "" > Bus 1, device 0, function 0: > VGA controller: PCI device 1234:1111 > BAR0: 32 bit prefetchable memory at 0x01000000 [0x01ffffff]. > BAR2: 32 bit memory at 0x02000000 [0x02000fff]. > BAR6: 32 bit memory at 0x02010000 [0x0201ffff]. > id "" > Bus 1, device 1, function 0: > Bridge: PCI device 108e:1000 > BAR0: 32 bit memory at 0xffffffffffffffff [0x00fffffe]. > BAR1: 32 bit memory at 0xffffffffffffffff [0x007ffffe]. > id "" > Bus 1, device 2, function 0: > IDE controller: PCI device 1095:0646 > IRQ 0. > BAR0: I/O at 0xffffffffffffffff [0x0006]. > BAR1: I/O at 0xffffffffffffffff [0x0002]. > BAR2: I/O at 0xffffffffffffffff [0x0006]. > BAR3: I/O at 0xffffffffffffffff [0x0002]. > BAR4: I/O at 0xffffffffffffffff [0x000e]. > id "" > Bus 0, device 1, function 1: > PCI bridge: PCI device 108e:5000 > BUS 0. > secondary bus 0. > subordinate bus 0. > IO range [0x0000, 0x0fff] > memory range [0x00000000, 0x000fffff] > prefetchable memory range [0x00000000, 0x000fffff] > id "" > Bus 0, device 2, function 0: > ^ should be bus 1. But in your patch above you didn't touch the Ethernet, only cmd646 and vga, or am I missing something? Another question - is VGA legacy low mem area turned on by the PCI feature called "DOS Compatibility" in the PBM and APB docs? Both PBM and APB docs say that they don't have "DOS Compatibility" feature. Maybe it's possible to tell the VGA card, that we don't need the low mem area? > > Ethernet controller: PCI device 10ec:8029 > IRQ 0. > BAR0: I/O at 0xffffffffffffffff [0x00fe]. > BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. > id "" > >> -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 1/3] sparc64: use direct interrupt mapping for PCI devices
by Mark Cave-Ayland 27 Apr '13

27 Apr '13

On 27/04/13 12:47, Blue Swirl wrote: > Maybe we should make a macro similar to OLDWORLD() and NEWWORLD() for Sparc64? Hmmm yes. That could be a nice tidy-up... ATB, Mark.

1 0

Re: [OpenBIOS] [PATCH 1/3] sparc64: use direct interrupt mapping for PCI devices
by Mark Cave-Ayland 27 Apr '13

27 Apr '13

On 27/04/13 06:58, Artyom Tarasenko wrote: Hi Artyom, Nice patchset! > Every PCI Slot in PBM has 4 directly mapped IRQ lines. > Use the IRQ routing schema 0bssnn (Bus, Slot, interrupt Number) > described in Section 19.3.3 of UltraSPARC™-IIi User's Manual. > > Please note that this patch requires the QEMU counterpart patch. > > Signed-off-by: Artyom Tarasenko<atar4qemu(a)gmail.com> > --- > drivers/pci.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci.c b/drivers/pci.c > index 5c487c1..ec1a810 100644 > --- a/drivers/pci.c > +++ b/drivers/pci.c > @@ -854,7 +854,14 @@ static void ob_pci_add_properties(phandle_t phandle, > if (config->irq_pin) { > OLDWORLD(set_int_property(dev, "AAPL,interrupts", > config->irq_line)); > +#if defined(CONFIG_SPARC64) > + /* direct mapping bssnn (Bus, Slot, interrupt Number */ > + set_int_property(get_cur_dev(), "interrupts", Any reason why this invokes get_cur_dev() rather than just using dev as per the OLDWORLD/NEWWORLD calls? > + ((((config->dev>> 11)<< 2) > + + config->irq_pin - 1)& 0x1f)); > +#else > NEWWORLD(set_int_property(dev, "interrupts", config->irq_pin)); > +#endif > } > > set_int_property(dev, "min-grant", pci_config_read8(addr, PCI_MIN_GNT)); ATB, Mark.

1 0

Re: [OpenBIOS] [PATCH 1/3] sparc64: use direct interrupt mapping for PCI devices
by Blue Swirl 27 Apr '13

27 Apr '13

On Sat, Apr 27, 2013 at 5:58 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > Every PCI Slot in PBM has 4 directly mapped IRQ lines. > Use the IRQ routing schema 0bssnn (Bus, Slot, interrupt Number) > described in Section 19.3.3 of UltraSPARC™-IIi User's Manual. > > Please note that this patch requires the QEMU counterpart patch. > > Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> > --- > drivers/pci.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci.c b/drivers/pci.c > index 5c487c1..ec1a810 100644 > --- a/drivers/pci.c > +++ b/drivers/pci.c > @@ -854,7 +854,14 @@ static void ob_pci_add_properties(phandle_t phandle, > if (config->irq_pin) { > OLDWORLD(set_int_property(dev, "AAPL,interrupts", > config->irq_line)); > +#if defined(CONFIG_SPARC64) > + /* direct mapping bssnn (Bus, Slot, interrupt Number */ > + set_int_property(get_cur_dev(), "interrupts", > + ((((config->dev >> 11) << 2) > + + config->irq_pin - 1) & 0x1f)); > +#else Maybe we should make a macro similar to OLDWORLD() and NEWWORLD() for Sparc64? > NEWWORLD(set_int_property(dev, "interrupts", config->irq_pin)); > +#endif > } > > set_int_property(dev, "min-grant", pci_config_read8(addr, PCI_MIN_GNT)); > -- > 1.7.1 >

1 0

[PATCH 0/3] sparc64 pci irq mapping and virtio fixes
by Artyom Tarasenko 27 Apr '13

27 Apr '13

The patches 1/3 and 2/3 are depending on the QEMU pbm patch. Together they allow using multiple PCI (virtio) devices simultaneously. Tested on installing Debian Wheezy / sparc64. http://tyom.blogspot.de/2013/03/debiansparc64-wheezy-under-qemu-how-to.html… Without the patches the install process hangs at random places between 6% and 60%. The patch 3/3 is a trivial rename patch. Artyom Tarasenko (3): sparc64: use direct interrupt mapping for PCI devices sparc64: remove hacks for the "interrupts" property use the proper name for the virtio-blk devices drivers/ide.c | 2 -- drivers/pci.c | 15 +++++++-------- drivers/pci_database.c | 6 +++--- drivers/pci_database.h | 1 - 4 files changed, 10 insertions(+), 14 deletions(-)

2 4

[commit] r1133 - trunk/openbios-devel/drivers
by repository service 27 Apr '13

27 Apr '13

Author: blueswirl Date: Sat Apr 27 13:42:18 2013 New Revision: 1133 URL: http://tracker.coreboot.org/trac/openbios/changeset/1133 Log: use the proper name for the virtio-blk devices The name 'virtio-scsi' is misleading, since there is another device called 'virtio-scsi' in QEMU. Use the name 'virtio-blk' instead. Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/drivers/pci_database.c Modified: trunk/openbios-devel/drivers/pci_database.c ============================================================================== --- trunk/openbios-devel/drivers/pci_database.c Sat Apr 27 13:42:16 2013 (r1132) +++ trunk/openbios-devel/drivers/pci_database.c Sat Apr 27 13:42:18 2013 (r1133) @@ -49,7 +49,7 @@ { /* Virtio-block controller */ PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_DEVICE_ID_VIRTIO_BLOCK, - NULL, "virtio-scsi", NULL, + NULL, "virtio-blk", NULL, "pci1af4,1001\0pci1af4,1001\0pciclass,01018f\0", 0, 0, 0, NULL, NULL,

1 0

[commit] r1132 - trunk/openbios-devel/drivers
by repository service 27 Apr '13

27 Apr '13

Author: blueswirl Date: Sat Apr 27 13:42:16 2013 New Revision: 1132 URL: http://tracker.coreboot.org/trac/openbios/changeset/1132 Log: sparc64: remove hacks for the "interrupts" property Forcing the "interrupts" property to the value of zero is not necessary, and is incompatible with the IRQ mapping schema introduced in the previous commit Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/drivers/ide.c trunk/openbios-devel/drivers/pci.c trunk/openbios-devel/drivers/pci_database.c trunk/openbios-devel/drivers/pci_database.h Modified: trunk/openbios-devel/drivers/ide.c ============================================================================== --- trunk/openbios-devel/drivers/ide.c Sat Apr 27 13:42:14 2013 (r1131) +++ trunk/openbios-devel/drivers/ide.c Sat Apr 27 13:42:16 2013 (r1132) @@ -1432,8 +1432,6 @@ props[0]=14; props[1]=0; set_property(dnode, "interrupts", (char *)&props, 2*sizeof(props[0])); -#elif defined(CONFIG_SPARC64) - set_int_property(get_cur_dev(), "interrupts", 0); #endif props[0] = __cpu_to_be32(chan->io_regs[0]); Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Sat Apr 27 13:42:14 2013 (r1131) +++ trunk/openbios-devel/drivers/pci.c Sat Apr 27 13:42:16 2013 (r1132) @@ -537,14 +537,6 @@ return 0; } -int virtio_config_cb(const pci_config_t *config) -{ -#if defined(CONFIG_SPARC64) - set_int_property(get_cur_dev(), "interrupts", 0); -#endif - return 0; -} - int ide_config_cb2 (const pci_config_t *config) { ob_ide_init(config->path, Modified: trunk/openbios-devel/drivers/pci_database.c ============================================================================== --- trunk/openbios-devel/drivers/pci_database.c Sat Apr 27 13:42:14 2013 (r1131) +++ trunk/openbios-devel/drivers/pci_database.c Sat Apr 27 13:42:16 2013 (r1132) @@ -52,7 +52,7 @@ NULL, "virtio-scsi", NULL, "pci1af4,1001\0pci1af4,1001\0pciclass,01018f\0", 0, 0, 0, - virtio_config_cb, NULL, + NULL, NULL, }, { 0xFFFF, 0xFFFF, @@ -134,7 +134,7 @@ NULL, "virtio-net", NULL, "pci1af4,1000\0pci1af4,1000\0pciclass,020000\0", 0, 0, 0, - virtio_config_cb, NULL, + NULL, NULL, }, { 0xFFFF, 0xFFFF, Modified: trunk/openbios-devel/drivers/pci_database.h ============================================================================== --- trunk/openbios-devel/drivers/pci_database.h Sat Apr 27 13:42:14 2013 (r1131) +++ trunk/openbios-devel/drivers/pci_database.h Sat Apr 27 13:42:16 2013 (r1132) @@ -28,7 +28,6 @@ const void *private; }; -extern int virtio_config_cb(const pci_config_t *config); extern int ide_config_cb2(const pci_config_t *config); extern int eth_config_cb(const pci_config_t *config); extern int macio_heathrow_config_cb(const pci_config_t *config);

1 0

[commit] r1131 - trunk/openbios-devel/drivers
by repository service 27 Apr '13

27 Apr '13

Author: blueswirl Date: Sat Apr 27 13:42:14 2013 New Revision: 1131 URL: http://tracker.coreboot.org/trac/openbios/changeset/1131 Log: sparc64: use direct interrupt mapping for PCI devices Every PCI Slot in PBM has 4 directly mapped IRQ lines. Use the IRQ routing schema 0bssnn (Bus, Slot, interrupt Number) described in Section 19.3.3 of UltraSPARC™-IIi User's Manual. Please note that this patch requires the QEMU counterpart patch. Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/drivers/pci.c Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Sat Apr 27 13:30:16 2013 (r1130) +++ trunk/openbios-devel/drivers/pci.c Sat Apr 27 13:42:14 2013 (r1131) @@ -854,7 +854,14 @@ if (config->irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts", config->irq_line)); +#if defined(CONFIG_SPARC64) + /* direct mapping bssnn (Bus, Slot, interrupt Number */ + set_int_property(get_cur_dev(), "interrupts", + ((((config->dev >> 11) << 2) + + config->irq_pin - 1) & 0x1f)); +#else NEWWORLD(set_int_property(dev, "interrupts", config->irq_pin)); +#endif } set_int_property(dev, "min-grant", pci_config_read8(addr, PCI_MIN_GNT));

1 0

Re: [OpenBIOS] [commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32
by Mark Cave-Ayland 27 Apr '13

27 Apr '13

On 26/04/13 23:21, Artyom Tarasenko wrote: >> In that case can you just try removing this part of the address reservation >> code from SVN trunk like this: >> >> --- a/openbios-devel/arch/sparc32/openbios.c >> +++ b/openbios-devel/arch/sparc32/openbios.c >> @@ -820,9 +820,6 @@ static void init_memory(void) >> >> /* Generate the mapping (and lock translation into the TLBs) */ >> ofmem_map(phys, virt, MEMORY_SIZE, >> ofmem_arch_default_translation_mode(phys)); >> >> - /* Mark everything up until OFMEM_VIRT_TOP as in use */ >> - ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE - >> OFMEM_VIRT_TOP, 0); >> - >> /* we push start and end of memory to the stack >> * so that it can be used by the forth word QUIT >> * to initialize the memory allocator >> >> Now the only remaining memory reserved in that region is at the very top >> end, and is just the 128K Forth dictionary which from your tests before >> should work. > > Yes, I figured that too. Did some testing yesterday night, and it looked ok. > As for the exact value of OFMEM_VIRT_TOP, I'm not sure any more that > 0xff000000 is better than the current value. I think SunOS might behave > differently just because of conflicting with OpenBIOS memory mappings. Great! I've just committed a patch to remove these lines to SVN trunk. ATB, Mark.

1 0

[commit] r1130 - trunk/openbios-devel/arch/sparc32
by repository service 27 Apr '13

27 Apr '13

Author: mcayland Date: Sat Apr 27 13:30:16 2013 New Revision: 1130 URL: http://tracker.coreboot.org/trac/openbios/changeset/1130 Log: SPARC32: Remove high memory virtual memory reservation The high memory virtual memory reservation introduced in r1114 was a mistake. We need to leave this area as available for clients but simply not allocate from it so that the 0xffc00000 area is free for kadb on older versions of SunOS. Since this part is already handled by the introduction of OFMEM_VIRT_TOP in the same commit then the behaviour is already correct. As reported by Artyom Tarasenko. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/openbios.c Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Fri Apr 26 11:53:43 2013 (r1129) +++ trunk/openbios-devel/arch/sparc32/openbios.c Sat Apr 27 13:30:16 2013 (r1130) @@ -820,9 +820,6 @@ /* Generate the mapping (and lock translation into the TLBs) */ ofmem_map(phys, virt, MEMORY_SIZE, ofmem_arch_default_translation_mode(phys)); - /* Mark everything up until OFMEM_VIRT_TOP as in use */ - ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE - OFMEM_VIRT_TOP, 0); - /* we push start and end of memory to the stack * so that it can be used by the forth word QUIT * to initialize the memory allocator

1 0

[PATCH 2/2] sparc64: add a eeprom node to the device tree
by Artyom Tarasenko 27 Apr '13

27 Apr '13

Add eeprom node to the device tree to make device visible for the guest OS. Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> --- arch/sparc64/openbios.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index 2e70a9d..22bcc39 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -450,6 +450,27 @@ void arch_nvram_get(char *data) ob_mmu_init(cpu->name, ram_size); + push_str("/pci@1fe,0/ebus"); + fword("find-device"); + fword("new-device"); + PUSH(0x000001fe); + fword("encode-int"); + PUSH(0x02002000); + fword("encode-int"); + fword("encode+"); + PUSH(NVRAM_SIZE); + fword("encode-int"); + fword("encode+"); + push_str("reg"); + fword("property"); + + push_str("mk48t59"); + fword("model"); + + push_str("eeprom"); + fword("device-name"); + fword("finish-device"); + /* Setup nvram variables */ push_str("/options"); fword("find-device"); -- 1.7.1

1 0

[PATCH 1/2] sparc64: use MMIO for NVRAM access
by Artyom Tarasenko 27 Apr '13

27 Apr '13

Use MMIO for accessing the m48t08 NVRAM chip. This patch is a counterpart of a QEMU change. Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> --- arch/sparc64/openbios.c | 30 ++++++++---------------------- 1 files changed, 8 insertions(+), 22 deletions(-) diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index a6c956a..2e70a9d 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -26,9 +26,7 @@ #define UUID_FMT "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" -#define NVRAM_ADDR_LO 0x74 -#define NVRAM_ADDR_HI 0x75 -#define NVRAM_DATA 0x77 +#define NVRAM_BASE 0x02000 #define APB_SPECIAL_BASE 0x1fe00000000ULL #define APB_MEM_BASE 0x1ff00000000ULL @@ -40,7 +38,7 @@ #define NVRAM_IDPROM 0x1fd8 #define NVRAM_IDPROM_SIZE 32 #define NVRAM_OB_START (0) -#define NVRAM_OB_SIZE ((0x1fd0 - NVRAM_OB_START) & ~15) +#define NVRAM_OB_SIZE ((NVRAM_IDPROM - NVRAM_OB_START) & ~15) static uint8_t idprom[NVRAM_IDPROM_SIZE]; @@ -333,34 +331,22 @@ id_cpu(void) for (;;); } -static uint8_t nvram_read_byte(uint16_t offset) -{ - outb(offset & 0xff, NVRAM_ADDR_LO); - outb(offset >> 8, NVRAM_ADDR_HI); - return inb(NVRAM_DATA); -} - static void nvram_read(uint16_t offset, char *buf, unsigned int nbytes) { unsigned int i; - for (i = 0; i < nbytes; i++) - buf[i] = nvram_read_byte(offset + i); -} - -static void nvram_write_byte(uint16_t offset, uint8_t val) -{ - outb(offset & 0xff, NVRAM_ADDR_LO); - outb(offset >> 8, NVRAM_ADDR_HI); - outb(val, NVRAM_DATA); + for (i = 0; i < nbytes; i++) { + buf[i] = inb(NVRAM_BASE + offset + i); + } } static void nvram_write(uint16_t offset, const char *buf, unsigned int nbytes) { unsigned int i; - for (i = 0; i < nbytes; i++) - nvram_write_byte(offset + i, buf[i]); + for (i = 0; i < nbytes; i++) { + outb(buf[i], NVRAM_BASE + offset + i); + } } static uint8_t qemu_uuid[16]; -- 1.7.1

1 0

Re: [OpenBIOS] Read errors from SILO booting Debian Wheezy/sparc64
by Mark Cave-Ayland 27 Apr '13

27 Apr '13

On 26/04/13 23:12, Artyom Tarasenko wrote: > With the current OpenBIOS (svn.r1129) there are errors reading initrd > from an ext2 partition using SILO. Hi Artyom, Is this a regression? If so, what was the last know good revision? ATB, Mark.

2 1

Re: [OpenBIOS] [commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32
by Mark Cave-Ayland 27 Apr '13

27 Apr '13

On 24/04/13 22:57, Artyom Tarasenko wrote: >> So just to clarify: is what you're saying that a checkout of OpenBIOS r1114 >> fails? In that case can you confirm what value of ofmem_arch_get_virt_top() >> that you were using in the URL above when kadb did work? > > The value (ucell)0xff000000 which you suggested in the SunOS thread, > seems to work > better than the current OFMEM_VIRT_TOP. If I revert the two lines to > the state before r1114: > > - virt = ofmem_claim_virt(OF_CODE_START - MEMORY_SIZE, MEMORY_SIZE, 0); > + virt = ofmem_claim_virt(-1, MEMORY_SIZE, PAGE_SIZE); > > - ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE - > OFMEM_VIRT_TOP, 0); > > then kadb starts with both (ucell)0xff000000 and OFMEM_VIRT_TOP, but > with the later, the kernel dies a bit earlier. Wait a minute - I think this might be a bit of brain-fade on my part. I was thinking that we need to reserve the 0xffc00000 region so that it wouldn't be allocated out to clients, but in actual fact we *do* want clients to use it. We just need to make sure that OpenBIOS itself doesn't return blocks from that region, which is why OFMEM_VIRT_TOP was introduced. In that case can you just try removing this part of the address reservation code from SVN trunk like this: --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -820,9 +820,6 @@ static void init_memory(void) /* Generate the mapping (and lock translation into the TLBs) */ ofmem_map(phys, virt, MEMORY_SIZE, ofmem_arch_default_translation_mode(phys)); - /* Mark everything up until OFMEM_VIRT_TOP as in use */ - ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE - OFMEM_VIRT_TOP, 0); - /* we push start and end of memory to the stack * so that it can be used by the forth word QUIT * to initialize the memory allocator Now the only remaining memory reserved in that region is at the very top end, and is just the 128K Forth dictionary which from your tests before should work. ATB, Mark.

2 1

Read errors from SILO booting Debian Wheezy/sparc64
by Artyom Tarasenko 27 Apr '13

27 Apr '13

With the current OpenBIOS (svn.r1129) there are errors reading initrd from an ext2 partition using SILO. Steps to reproduce: 1. Install Debian Wheezy RC1 (e.g. as described here http://tyom.blogspot.de/2013/03/debiansparc64-wheezy-under-qemu-how-to.html ) using the standard partition layout ( i.e. /boot parttion with an ext2 file system). 2. Try to boot from the wheezy disk, using it as a -hda image. Below is the boot log with OFMEM_DEBUG enabled. $ sparc64-softmmu/qemu-system-sparc64 -bios /path-to/openbios-devel/obj-sparc64/openbios-builtin.elf -m 384 -nographic -hda /path/debian-wheezy.qcow2 SILO Version 1.4.14 boot: OFMEM: ofmem_map_page_range 0000000040000000 -> 0000000000400000 0000000004000000 mode 0000000000000027 Allocated 64 Megs of memory at 0x40000000 for kernel Uncompressing image... Loaded kernel version 3.2.35 OFMEM: ofmem_map: Bad parameters (0000000004400000 0000000040C00000 000000000094DFFF) ^^^^^^ what happens here? OFMEM: ofmem_map_page_range 0000000040c00000 -> 0000000004400000 000000000094e000 mode 0000000000000027 OFMEM: mapping altered virt=0000000040c00000) Loading initial ramdisk (9747774 bytes at 0x4400000 phys, 0x40C00000 virt)... | Read error on block 1296 (tried 262144, got 4294967295) Read error on block 1296 (tried 262144, got 4294967295) | Read error on block 1810 (tried 262144, got 4294967295) Read error on block 1810 (tried 262144, got 4294967295) \ Read error on block 2324 (tried 242688, got 4294967295) Read error on block 2324 (tried 242688, got 4294967295) | Read error on block 3468 (tried 262144, got 4294967295) Read error on block 3468 (tried 262144, got 4294967295) Read error on block 3468 (tried 262144, got 4294967295) | Read error on block 4239 (tried 262144, got 4294967295) Read error on block 4239 (tried 262144, got 4294967295) \ Read error on block 5780 (tried 1024, got 4294967295) | Read error on block 5524 (tried 262144, got 4294967295) | Read error on block 6295 (tried 262144, got 4294967295) Read error on block 6295 (tried 262144, got 4294967295) OFMEM: ofmem_unmap 0000000040c00000 000000000094dfff [...] [ 17.710187] Unpacking initramfs... [ 17.861207] Initramfs unpacking failed: broken padding [ 17.861323] Freeing initrd memory: 9519k freed -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[commit] r1129 - trunk/openbios-devel/drivers
by repository service 26 Apr '13

26 Apr '13

Author: mcayland Date: Fri Apr 26 11:53:43 2013 New Revision: 1129 URL: http://tracker.coreboot.org/trac/openbios/changeset/1129 Log: SPARC: Another escc alignment fix for escc_keyboard Further tests show that the Sun ESCC serial driver routines are also used for the keyboard device. Hence we also need to update the escc_keyboard bindings declaration to use ucell instead of phys_addr_t. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/escc.c Modified: trunk/openbios-devel/drivers/escc.c ============================================================================== --- trunk/openbios-devel/drivers/escc.c Sun Apr 21 10:27:23 2013 (r1128) +++ trunk/openbios-devel/drivers/escc.c Fri Apr 26 11:53:43 2013 (r1129) @@ -305,7 +305,7 @@ } } -DECLARE_UNNAMED_NODE(escc_keyboard, INSTALL_OPEN, sizeof(phys_addr_t)); +DECLARE_UNNAMED_NODE(escc_keyboard, INSTALL_OPEN, sizeof(ucell)); NODE_METHODS(escc_keyboard) = { { "open", escc_open },

1 0

Re: [OpenBIOS] [commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32
by Mark Cave-Ayland 24 Apr '13

24 Apr '13

On 23/04/13 22:54, Artyom Tarasenko wrote: > Sorry, somehow I missed testing this patch. > It breaks loading kadb: > > 0> boot disk kadb -kdvs Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 Ah okay. I thought that the post below was an ack from you that 128K was still okay to run kadb with an unmodified ofmem_arch_get_virt_top(): http://www.openfirmware.info/pipermail/openbios/2013-April/007606.html I also can't see any memory regions in the output above that would overlap 0xffc00000 - has any of the output been removed? So just to clarify: is what you're saying that a checkout of OpenBIOS r1114 fails? In that case can you confirm what value of ofmem_arch_get_virt_top() that you were using in the URL above when kadb did work? ATB, Mark.

2 1

[commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32
by repository service 23 Apr '13

23 Apr '13

Author: mcayland Date: Tue Apr 9 20:32:53 2013 New Revision: 1114 URL: http://tracker.coreboot.org/trac/openbios/changeset/1114 Log: SPARC32: Move Forth dictionary location to a fixed location. Instead of using the automatic allocator to determine the location of the Forth dictionary, allocate it at a fixed location just underneath the ROM itself at 0xffd00000. This patch also prevents corruption within the RAM of the Forth machine by ensuring that we allocate virtual memory outside of OpenBIOS itself, plus reduces the size of the Forth dictionary to 128K so that it meets the memory constraints required to boot Linux and also kadb from older versions of SunOS (as reported by Artyom Tarasenko). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c trunk/openbios-devel/arch/sparc32/openbios.c trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Tue Apr 9 20:32:49 2013 (r1113) +++ trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Tue Apr 9 20:32:53 2013 (r1114) @@ -61,7 +61,7 @@ ucell ofmem_arch_get_virt_top(void) { - return (ucell)TOP_OF_RAM; + return (ucell)OFMEM_VIRT_TOP; } phys_addr_t ofmem_arch_get_phys_top(void) Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Tue Apr 9 20:32:49 2013 (r1113) +++ trunk/openbios-devel/arch/sparc32/openbios.c Tue Apr 9 20:32:53 2013 (r1114) @@ -25,9 +25,9 @@ #include "packages/video.h" #define NO_QEMU_PROTOS #include "arch/common/fw_cfg.h" -#include "libopenbios/ofmem.h" +#include "arch/sparc32/ofmem_sparc32.h" -#define MEMORY_SIZE (512*1024) /* 512K ram for hosted system */ +#define MEMORY_SIZE (128*1024) /* 128K ram for hosted system */ #define UUID_FMT "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" #define FW_CFG_SUN4M_DEPTH (FW_CFG_ARCH_LOCAL + 0x00) @@ -813,13 +813,16 @@ if (!phys) printk("panic: not enough physical memory on host system.\n"); - virt = ofmem_claim_virt(-1, MEMORY_SIZE, PAGE_SIZE); + virt = ofmem_claim_virt(OF_CODE_START - MEMORY_SIZE, MEMORY_SIZE, 0); if (!virt) printk("panic: not enough virtual memory on host system.\n"); /* Generate the mapping (and lock translation into the TLBs) */ ofmem_map(phys, virt, MEMORY_SIZE, ofmem_arch_default_translation_mode(phys)); + /* Mark everything up until OFMEM_VIRT_TOP as in use */ + ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE - OFMEM_VIRT_TOP, 0); + /* we push start and end of memory to the stack * so that it can be used by the forth word QUIT * to initialize the memory allocator Modified: trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h ============================================================================== --- trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h Tue Apr 9 20:32:49 2013 (r1113) +++ trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h Tue Apr 9 20:32:53 2013 (r1114) @@ -16,6 +16,9 @@ #include "libopenbios/ofmem.h" +#define OF_CODE_START 0xffd00000 +#define OFMEM_VIRT_TOP 0xfe000000 + struct mem; extern struct mem cdvmem;

2 1

[commit] r1128 - trunk/openbios-devel/drivers
by repository service 21 Apr '13

21 Apr '13

Author: mcayland Date: Sun Apr 21 10:27:23 2013 New Revision: 1128 URL: http://tracker.coreboot.org/trac/openbios/changeset/1128 Log: SPARC: Fix escc instance structure alignment When binding C functions to Forth words using NODE_METHODs for the SPARC ESCC serial driver, the C instance parameter pointer was set to be a pointer to a phys_addr_t. This is incorrect in the case where sizeof(phys_addr_t) != sizeof(cell) such as on SPARC32, as the address allocated from the Forth machine would be aligned to sizeof(cell); hence an alignment exception could be generated on random occasions on SPARC32 when the allocated address generated by Forth when opening the device was aligned to just 4 bytes (and not also 8 bytes) when dereferencing the instance parameter pointer. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/escc.c Modified: trunk/openbios-devel/drivers/escc.c ============================================================================== --- trunk/openbios-devel/drivers/escc.c Sun Apr 21 10:27:21 2013 (r1127) +++ trunk/openbios-devel/drivers/escc.c Sun Apr 21 10:27:23 2013 (r1128) @@ -131,7 +131,7 @@ /* ( addr len -- actual ) */ static void -escc_read(phys_addr_t *address) +escc_read(ucell *address) { char *addr; int len; @@ -152,7 +152,7 @@ /* ( addr len -- actual ) */ static void -escc_write(phys_addr_t *address) +escc_write(ucell *address) { unsigned char *addr; int i, len; @@ -172,7 +172,7 @@ } static void -escc_open(phys_addr_t *address) +escc_open(ucell *address) { #ifdef CONFIG_DRIVER_ESCC_SUN int len; @@ -199,7 +199,7 @@ RET ( -1 ); } -DECLARE_UNNAMED_NODE(escc, INSTALL_OPEN, sizeof(phys_addr_t)); +DECLARE_UNNAMED_NODE(escc, INSTALL_OPEN, sizeof(ucell)); NODE_METHODS(escc) = { { "open", escc_open },

1 0

[commit] r1127 - trunk/openbios-devel/packages
by repository service 21 Apr '13

21 Apr '13

Author: mcayland Date: Sun Apr 21 10:27:21 2013 New Revision: 1127 URL: http://tracker.coreboot.org/trac/openbios/changeset/1127 Log: disk-label.c: Fix opening of raw block devices If open-dev is called on a raw block device such as cdrom, the current code will always attempt to interpose a partition handler for the first valid partition table type it finds. This is incorrect when opening a raw block device directly as it means we "fall into" the first valid partition that can be found, rather than using the full raw device. Fix this by only attempting to interpose a partition handler if the package arguments are not empty. This fixes the NetBSD SPARC64 bootloader as reported by Martin Husemann in https://bugs.launchpad.net/qemu/+bug/1169856. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/packages/disk-label.c Modified: trunk/openbios-devel/packages/disk-label.c ============================================================================== --- trunk/openbios-devel/packages/disk-label.c Fri Apr 19 09:05:33 2013 (r1126) +++ trunk/openbios-devel/packages/disk-label.c Sun Apr 21 10:27:21 2013 (r1127) @@ -73,63 +73,70 @@ di->filesystem_ph = 0; di->parent_seek_xt = find_parent_method("seek"); di->parent_tell_xt = find_parent_method("tell"); - di->parent_read_xt = find_parent_method("read"); + di->parent_read_xt = find_parent_method("read"); - /* Read first block from parent device */ - DPUSH(0); - call_package(di->parent_seek_xt, my_parent()); - POP(); - - PUSH(pointer2cell(block0)); - PUSH(sizeof(block0)); - call_package(di->parent_read_xt, my_parent()); - status = POP(); - if (status != sizeof(block0)) - goto out; - - /* Find partition handler */ - PUSH( pointer2cell(block0) ); - selfword("find-part-handler"); - ph = POP_ph(); - if( ph ) { - /* We found a suitable partition handler, so interpose it */ - DPRINTF("Partition found on disk - scheduling interpose with ph " FMT_ucellx "\n", ph); - - push_str(path); - PUSH_ph(ph); - fword("interpose"); + /* If arguments have been passed, determine the partition/filesystem type */ + if (path && strlen(path)) { - success = 1; - } else { - /* unknown (or missing) partition map, - * try the whole disk - */ - - DPRINTF("Unknown or missing partition map; trying whole disk\n"); - - /* Probe for filesystem from start of device */ - DPUSH ( 0 ); - PUSH_ih( my_self() ); - selfword("find-filesystem"); + /* Read first block from parent device */ + DPUSH(0); + call_package(di->parent_seek_xt, my_parent()); + POP(); + + PUSH(pointer2cell(block0)); + PUSH(sizeof(block0)); + call_package(di->parent_read_xt, my_parent()); + status = POP(); + if (status != sizeof(block0)) + goto out; + + /* Find partition handler */ + PUSH( pointer2cell(block0) ); + selfword("find-part-handler"); ph = POP_ph(); if( ph ) { - /* If we have been asked to open a particular file, interpose the filesystem package with the passed filename as an argument */ - di->filesystem_ph = ph; - - DPRINTF("Located filesystem with ph " FMT_ucellx "\n", ph); - DPRINTF("path: %s length: %d\n", path, strlen(path)); + /* We found a suitable partition handler, so interpose it */ + DPRINTF("Partition found on disk - scheduling interpose with ph " FMT_ucellx "\n", ph); - if (path && strlen(path)) { - DPRINTF("INTERPOSE!\n"); - - push_str( path ); - PUSH_ph( ph ); - fword("interpose"); + push_str(path); + PUSH_ph(ph); + fword("interpose"); + + success = 1; + } else { + /* unknown (or missing) partition map, + * try the whole disk + */ + + DPRINTF("Unknown or missing partition map; trying whole disk\n"); + + /* Probe for filesystem from start of device */ + DPUSH ( 0 ); + PUSH_ih( my_self() ); + selfword("find-filesystem"); + ph = POP_ph(); + if( ph ) { + /* If we have been asked to open a particular file, interpose the filesystem package with the passed filename as an argument */ + di->filesystem_ph = ph; + + DPRINTF("Located filesystem with ph " FMT_ucellx "\n", ph); + DPRINTF("path: %s length: %d\n", path, strlen(path)); + + if (path && strlen(path)) { + DPRINTF("INTERPOSE!\n"); + + push_str( path ); + PUSH_ph( ph ); + fword("interpose"); + } + } else if (path && strcmp(path, "%BOOT") != 0) { + goto out; } - } else if (path && strcmp(path, "%BOOT") != 0) { - goto out; - } + success = 1; + } + } else { + /* No arguments were passed, so we just use the parent raw device directly */ success = 1; }

1 0

[PATCH] SPARC: Fix escc instance structure alignment
by Mark Cave-Ayland 20 Apr '13

20 Apr '13

When binding C functions to Forth words using NODE_METHODs for the SPARC ESCC serial driver, the C instance parameter pointer was set to be a pointer to a phys_addr_t. This is incorrect in the case where sizeof(phys_addr_t) != sizeof(cell) such as on SPARC32, as the address allocated from the Forth machine would be aligned to sizeof(cell); hence an alignment exception could be generated on random occasions on SPARC32 when the allocated address generated by Forth when opening the device was aligned to just 4 bytes (and not also 8 bytes) when derefencing the instance parameter pointer. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/drivers/escc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/openbios-devel/drivers/escc.c b/openbios-devel/drivers/escc.c index 892dc8c..9973fe1 100644 --- a/openbios-devel/drivers/escc.c +++ b/openbios-devel/drivers/escc.c @@ -131,7 +131,7 @@ void serial_cls(void) /* ( addr len -- actual ) */ static void -escc_read(phys_addr_t *address) +escc_read(ucell *address) { char *addr; int len; @@ -152,7 +152,7 @@ escc_read(phys_addr_t *address) /* ( addr len -- actual ) */ static void -escc_write(phys_addr_t *address) +escc_write(ucell *address) { unsigned char *addr; int i, len; @@ -172,7 +172,7 @@ escc_close(void) } static void -escc_open(phys_addr_t *address) +escc_open(ucell *address) { #ifdef CONFIG_DRIVER_ESCC_SUN int len; @@ -199,7 +199,7 @@ escc_open(phys_addr_t *address) RET ( -1 ); } -DECLARE_UNNAMED_NODE(escc, INSTALL_OPEN, sizeof(phys_addr_t)); +DECLARE_UNNAMED_NODE(escc, INSTALL_OPEN, sizeof(ucell)); NODE_METHODS(escc) = { { "open", escc_open }, -- 1.7.10.4

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Blue Swirl 20 Apr '13

20 Apr '13

On Fri, Apr 19, 2013 at 9:10 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Mon, May 14, 2012 at 8:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Mon, May 14, 2012 at 1:49 PM, Mark Cave-Ayland >> <mark.cave-ayland(a)ilande.co.uk> wrote: >>> On 14/05/12 14:28, Artyom Tarasenko wrote: >>> >>>>>> It's to avoid VGA legacy mapping at 0xa0000. If I change >>>>>> hwdefs.pci.pci_mem_base in arch/sparc64/openbios.c to 0, OpenBIOS will >>>>>> crash during VGA init. Previously this worked because the PCI devices >>>>>> were mapped somewhat randomly and by chance, VGA legacy low mem area >>>>>> was avoided. >>>>>> >>>>>> I think the correct fix is to make QEMU VGA device disable the legacy >>>>>> mapping unless explicitly enabled. Alternatively the child base >>>>>> arithmetic could be fixed in OpenBIOS like proposed by Jakub. >>>>> >>>>> >>>>> >>>>> Did a patch ever come out of this discussion in the end? >>>>> >>>> >>>> No. :-) Feel free to fix it, unless Blue prefers fixing it himself... >>> >>> >>> I'm not sure I'm confident enough with PCI to do this, and I'm also not sure >>> what Blue's recommended fix actually is? Is it to increase parent_base by >>> 0x1000 or set child_base to zero? >> >> The best solution is to fix VGA (assuming my analysis was right) and >> set child_base to zero. > > Blue, do you know whether the QOMification improved the situation with > the legacy VGA low mem area? I don't think it had any effect, but PCI bridging code was fixed recently. There are still some problems, if I move most devices behind the first bridge with this patch, Sparc64 does not boot anymore: diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c index 0d29620..8bf7230 100644 --- a/hw/sparc64/sun4u.c +++ b/hw/sparc64/sun4u.c @@ -813,7 +813,7 @@ static void sun4uv_init(MemoryRegion *address_space_mem, M48t59State *nvram; unsigned int i; uint64_t initrd_addr, initrd_size, kernel_addr, kernel_size, kernel_entry; - PCIBus *pci_bus, *pci_bus2, *pci_bus3; + PCIBus *pci_bus2, *pci_bus3; ISABus *isa_bus; qemu_irq *ivec_irqs, *pbm_irqs; DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS]; @@ -829,12 +829,11 @@ static void sun4uv_init(MemoryRegion *address_space_mem, prom_init(hwdef->prom_addr, bios_name); ivec_irqs = qemu_allocate_irqs(cpu_set_ivec_irq, cpu, IVEC_MAX); - pci_bus = pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, ivec_irqs, &pci_bus2, - &pci_bus3, &pbm_irqs); - pci_vga_init(pci_bus); + pci_apb_init(APB_SPECIAL_BASE, APB_MEM_BASE, ivec_irqs, &pci_bus2, + &pci_bus3, &pbm_irqs); + pci_vga_init(pci_bus2); - // XXX Should be pci_bus3 - isa_bus = pci_ebus_init(pci_bus, -1, pbm_irqs); + isa_bus = pci_ebus_init(pci_bus2, -1, pbm_irqs); i = 0; if (hwdef->console_serial_base) { @@ -859,7 +858,7 @@ static void sun4uv_init(MemoryRegion *address_space_mem, ide_drive_get(hd, MAX_IDE_BUS); - pci_cmd646_ide_init(pci_bus, hd, 1); + pci_cmd646_ide_init(pci_bus2, hd, 1); isa_create_simple(isa_bus, "i8042"); for(i = 0; i < MAX_FD; i++) { Also ethernet is using the main PCI bus instead of the bridged version: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 108e:a000 id "" Bus 0, device 1, function 0: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 1. subordinate bus 255. IO range [0x0000, 0x0fff] memory range [0x00000000, 0x000fffff] prefetchable memory range [0x00000000, 0x000fffff] id "" Bus 1, device 0, function 0: VGA controller: PCI device 1234:1111 BAR0: 32 bit prefetchable memory at 0x01000000 [0x01ffffff]. BAR2: 32 bit memory at 0x02000000 [0x02000fff]. BAR6: 32 bit memory at 0x02010000 [0x0201ffff]. id "" Bus 1, device 1, function 0: Bridge: PCI device 108e:1000 BAR0: 32 bit memory at 0xffffffffffffffff [0x00fffffe]. BAR1: 32 bit memory at 0xffffffffffffffff [0x007ffffe]. id "" Bus 1, device 2, function 0: IDE controller: PCI device 1095:0646 IRQ 0. BAR0: I/O at 0xffffffffffffffff [0x0006]. BAR1: I/O at 0xffffffffffffffff [0x0002]. BAR2: I/O at 0xffffffffffffffff [0x0006]. BAR3: I/O at 0xffffffffffffffff [0x0002]. BAR4: I/O at 0xffffffffffffffff [0x000e]. id "" Bus 0, device 1, function 1: PCI bridge: PCI device 108e:5000 BUS 0. secondary bus 0. subordinate bus 0. IO range [0x0000, 0x0fff] memory range [0x00000000, 0x000fffff] prefetchable memory range [0x00000000, 0x000fffff] id "" Bus 0, device 2, function 0: ^ should be bus 1. Ethernet controller: PCI device 10ec:8029 IRQ 0. BAR0: I/O at 0xffffffffffffffff [0x00fe]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. id "" > > > -- > Regards, > Artyom Tarasenko > > linux/sparc and solaris/sparc under qemu blog: > http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Patch that allows for building OpenBIOS on Mac OS X!
by Programmingkid 20 Apr '13

20 Apr '13

This patch allows users to build OpenBIOS on Mac OS X! The user just needs to install the elf cross compiler before applying this patch. signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Index: config/scripts/switch-arch =================================================================== --- config/scripts/switch-arch (revision 1117) +++ config/scripts/switch-arch (working copy) @@ -89,16 +89,27 @@ archname() { - HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ - -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ - -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ - -e "s/Power Macintosh/ppc/"` + OS_NAME=`uname` + if test "$OS_NAME" = "Darwin"; then # Can't depend on uname -m on Mac OS X + IS_64BIT=`sysctl hw.cpu64bit_capable` + if test "$IS_64BIT" = "hw.cpu64bit_capable: 1"; then + HOSTARCH="amd64" + else + HOSTARCH="x86" + fi + else + HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ + -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ + -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ + -e "s/Power Macintosh/ppc/"` + fi } select_prefix() { - for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- ppc-elf- do + echo "Trying ${TARGET}gcc" if type ${TARGET}gcc > /dev/null 2>&1 then return

2 1

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Artyom Tarasenko 19 Apr '13

19 Apr '13

On Mon, May 14, 2012 at 8:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Mon, May 14, 2012 at 1:49 PM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> On 14/05/12 14:28, Artyom Tarasenko wrote: >> >>>>> It's to avoid VGA legacy mapping at 0xa0000. If I change >>>>> hwdefs.pci.pci_mem_base in arch/sparc64/openbios.c to 0, OpenBIOS will >>>>> crash during VGA init. Previously this worked because the PCI devices >>>>> were mapped somewhat randomly and by chance, VGA legacy low mem area >>>>> was avoided. >>>>> >>>>> I think the correct fix is to make QEMU VGA device disable the legacy >>>>> mapping unless explicitly enabled. Alternatively the child base >>>>> arithmetic could be fixed in OpenBIOS like proposed by Jakub. >>>> >>>> >>>> >>>> Did a patch ever come out of this discussion in the end? >>>> >>> >>> No. :-) Feel free to fix it, unless Blue prefers fixing it himself... >> >> >> I'm not sure I'm confident enough with PCI to do this, and I'm also not sure >> what Blue's recommended fix actually is? Is it to increase parent_base by >> 0x1000 or set child_base to zero? > > The best solution is to fix VGA (assuming my analysis was right) and > set child_base to zero. Blue, do you know whether the QOMification improved the situation with the legacy VGA low mem area? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

OpenBIOS as a boot manager
by Mark Morgan Lloyd 19 Apr '13

19 Apr '13

I've got OpenFirmware as a boot manager on a couple of machines (i.e. resident on its own partition on disc), but is it possible to use OpenBIOS for this on a PPC Mac (specifically, a beige Old World G3?). Is there any chance that this would drive a DVD drive sufficient to install OS X? I'm not intending this for heavy use, but simply to provide a test target for another open-source project. I try to keep an eye on this mailing list, but please could somebody point me to the current homepage and download location. Google, Wp etc. links to http://www.openfirmware.info/Welcome_to_OpenBIOS which is well out of date. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

2 2

[PATCH] disk-label.c: Fix opening of raw block devices
by Mark Cave-Ayland 19 Apr '13

19 Apr '13

If open-dev is called on a raw block device such as cdrom, the current code will always attempt to interpose a partition handler for the first valid partition table type it finds. This is incorrect when opening a raw block device directly as it means we "fall into" the first valid partition that can be found, rather than using the full raw device. Fix this by only attempting to interpose a partition handler if the package arguments are not empty. This fixes the NetBSD SPARC64 bootloader as reported by Martin Husemann in https://bugs.launchpad.net/qemu/+bug/1169856. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/packages/disk-label.c | 105 ++++++++++++++++++---------------- 1 file changed, 56 insertions(+), 49 deletions(-) diff --git a/openbios-devel/packages/disk-label.c b/openbios-devel/packages/disk-label.c index 44b9f9e..1c18d74 100644 --- a/openbios-devel/packages/disk-label.c +++ b/openbios-devel/packages/disk-label.c @@ -73,63 +73,70 @@ dlabel_open( dlabel_info_t *di ) di->filesystem_ph = 0; di->parent_seek_xt = find_parent_method("seek"); di->parent_tell_xt = find_parent_method("tell"); - di->parent_read_xt = find_parent_method("read"); + di->parent_read_xt = find_parent_method("read"); - /* Read first block from parent device */ - DPUSH(0); - call_package(di->parent_seek_xt, my_parent()); - POP(); - - PUSH(pointer2cell(block0)); - PUSH(sizeof(block0)); - call_package(di->parent_read_xt, my_parent()); - status = POP(); - if (status != sizeof(block0)) - goto out; - - /* Find partition handler */ - PUSH( pointer2cell(block0) ); - selfword("find-part-handler"); - ph = POP_ph(); - if( ph ) { - /* We found a suitable partition handler, so interpose it */ - DPRINTF("Partition found on disk - scheduling interpose with ph " FMT_ucellx "\n", ph); - - push_str(path); - PUSH_ph(ph); - fword("interpose"); + /* If arguments have been passed, determine the partition/filesystem type */ + if (path && strlen(path)) { - success = 1; - } else { - /* unknown (or missing) partition map, - * try the whole disk - */ + /* Read first block from parent device */ + DPUSH(0); + call_package(di->parent_seek_xt, my_parent()); + POP(); - DPRINTF("Unknown or missing partition map; trying whole disk\n"); + PUSH(pointer2cell(block0)); + PUSH(sizeof(block0)); + call_package(di->parent_read_xt, my_parent()); + status = POP(); + if (status != sizeof(block0)) + goto out; - /* Probe for filesystem from start of device */ - DPUSH ( 0 ); - PUSH_ih( my_self() ); - selfword("find-filesystem"); + /* Find partition handler */ + PUSH( pointer2cell(block0) ); + selfword("find-part-handler"); ph = POP_ph(); if( ph ) { - /* If we have been asked to open a particular file, interpose the filesystem package with the passed filename as an argument */ - di->filesystem_ph = ph; - - DPRINTF("Located filesystem with ph " FMT_ucellx "\n", ph); - DPRINTF("path: %s length: %d\n", path, strlen(path)); - - if (path && strlen(path)) { - DPRINTF("INTERPOSE!\n"); - - push_str( path ); - PUSH_ph( ph ); - fword("interpose"); + /* We found a suitable partition handler, so interpose it */ + DPRINTF("Partition found on disk - scheduling interpose with ph " FMT_ucellx "\n", ph); + + push_str(path); + PUSH_ph(ph); + fword("interpose"); + + success = 1; + } else { + /* unknown (or missing) partition map, + * try the whole disk + */ + + DPRINTF("Unknown or missing partition map; trying whole disk\n"); + + /* Probe for filesystem from start of device */ + DPUSH ( 0 ); + PUSH_ih( my_self() ); + selfword("find-filesystem"); + ph = POP_ph(); + if( ph ) { + /* If we have been asked to open a particular file, interpose the filesystem package with the passed filename as an argument */ + di->filesystem_ph = ph; + + DPRINTF("Located filesystem with ph " FMT_ucellx "\n", ph); + DPRINTF("path: %s length: %d\n", path, strlen(path)); + + if (path && strlen(path)) { + DPRINTF("INTERPOSE!\n"); + + push_str( path ); + PUSH_ph( ph ); + fword("interpose"); + } + } else if (path && strcmp(path, "%BOOT") != 0) { + goto out; } - } else if (path && strcmp(path, "%BOOT") != 0) { - goto out; - } + success = 1; + } + } else { + /* No arguments we passed, so we just use the parent raw device directly */ success = 1; } -- 1.7.10.4

1 0

[commit] r1126 - trunk/openbios-devel/arch/sparc64
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:05:33 2013 New Revision: 1126 URL: http://tracker.coreboot.org/trac/openbios/changeset/1126 Log: SPARC64: Remove limit on kernel command line length caused by using a static buffer Instead use malloc() so that we can dynamically allocate the string ourselves. As reported by Rob Landley <rob(a)landley.net>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc64/openbios.c Modified: trunk/openbios-devel/arch/sparc64/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/openbios.c Fri Apr 19 09:05:30 2013 (r1125) +++ trunk/openbios-devel/arch/sparc64/openbios.c Fri Apr 19 09:05:33 2013 (r1126) @@ -42,9 +42,6 @@ #define NVRAM_OB_START (0) #define NVRAM_OB_SIZE ((0x1fd0 - NVRAM_OB_START) & ~15) -#define OBIO_CMDLINE_MAX 256 -static char obio_cmdline[OBIO_CMDLINE_MAX]; - static uint8_t idprom[NVRAM_IDPROM_SIZE]; struct hwdef { @@ -370,6 +367,7 @@ void arch_nvram_get(char *data) { + char *obio_cmdline; uint32_t size = 0; const struct cpudef *cpu; char buf[256]; @@ -401,12 +399,13 @@ kernel_image = fw_cfg_read_i64(FW_CFG_KERNEL_ADDR); size = fw_cfg_read_i32(FW_CFG_CMDLINE_SIZE); - if (size > OBIO_CMDLINE_MAX - 1) - size = OBIO_CMDLINE_MAX - 1; if (size) { + obio_cmdline = (char *)malloc(size + 1); fw_cfg_read(FW_CFG_CMDLINE_DATA, obio_cmdline, size); + obio_cmdline[size] = '\0'; + } else { + obio_cmdline = strdup(""); } - obio_cmdline[size] = '\0'; qemu_cmdline = (uint64_t)obio_cmdline; cmdline_size = size; boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE);

1 0

[commit] r1125 - trunk/openbios-devel/arch/sparc32
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:05:30 2013 New Revision: 1125 URL: http://tracker.coreboot.org/trac/openbios/changeset/1125 Log: SPARC32: Remove limit on kernel command line length caused by using a static buffer Instead use strdup() so that we can dynamically allocate the string ourselves. As reported by Rob Landley <rob(a)landley.net>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/openbios.c Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Fri Apr 19 09:04:40 2013 (r1124) +++ trunk/openbios-devel/arch/sparc32/openbios.c Fri Apr 19 09:05:30 2013 (r1125) @@ -835,8 +835,7 @@ static void arch_init( void ) { - static char cmdline[128]; - int size = 0; + char *cmdline; const char *kernel_cmdline; uint32_t temp; uint16_t machine_id; @@ -897,11 +896,11 @@ kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); if (kernel_cmdline) { - size = strlen(kernel_cmdline); - memcpy(cmdline, kernel_cmdline, size); + cmdline = strdup(kernel_cmdline); obp_arg.argv[1] = cmdline; - } - cmdline[size] = '\0'; + } else { + cmdline = strdup(""); + } qemu_cmdline = (uint32_t)cmdline; /* Setup nvram variables */

1 0

[commit] r1124 - trunk/openbios-devel/arch/ppc/qemu
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:04:40 2013 New Revision: 1124 URL: http://tracker.coreboot.org/trac/openbios/changeset/1124 Log: PPC: Remove zero page mapping from MMU to enable detection of NULL pointer dereferences Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Fri Apr 19 09:04:32 2013 (r1123) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Fri Apr 19 09:04:40 2013 (r1124) @@ -549,9 +549,14 @@ { ofmem_t *ofmem = ofmem_arch_get_private(); - ofmem_claim_phys(0, get_ram_bottom(), 0); - ofmem_claim_virt(0, get_ram_bottom(), 0); - ofmem_map(0, 0, get_ram_bottom(), 0); + /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ + ofmem_claim_phys(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_claim_virt(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_map(PAGE_SIZE, PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + + /* Mark the first page as non-free */ + ofmem_claim_phys(0, PAGE_SIZE, 0); + ofmem_claim_virt(0, PAGE_SIZE, 0); /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0);

1 0

[commit] r1123 - trunk/openbios-devel/arch/sparc32
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:04:32 2013 New Revision: 1123 URL: http://tracker.coreboot.org/trac/openbios/changeset/1123 Log: SPARC32: Remove zero page mapping from MMU to enable detection of NULL pointer dereferences Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Acked-by: Artyom Tarasenko <atar4qemu(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 19 09:04:25 2013 (r1122) +++ trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 19 09:04:32 2013 (r1123) @@ -393,9 +393,9 @@ ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); - // 1:1 mapping for RAM - ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); - ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + // 1:1 mapping for RAM (don't map page 0 to allow catching of NULL dereferences) + ofmem_arch_map_pages(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); /* * Flush cache Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Fri Apr 19 09:04:25 2013 (r1122) +++ trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Fri Apr 19 09:04:32 2013 (r1123) @@ -238,6 +238,9 @@ memset(&s_ofmem_data, 0, sizeof(s_ofmem_data)); s_ofmem_data.ofmem.ramsize = qemu_mem_size; + /* Mark the first page as non-free */ + ofmem_claim_virt(0, PAGE_SIZE, 0); + /* Claim reserved physical addresses at top of RAM */ ofmem_claim_phys(ofmem_arch_get_phys_top(), s_ofmem_data.ofmem.ramsize - ofmem_arch_get_phys_top(), 0);

1 0

[commit] r1122 - trunk/openbios-devel/arch/sparc32
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:04:25 2013 New Revision: 1122 URL: http://tracker.coreboot.org/trac/openbios/changeset/1122 Log: SPARC32: Remove manual fix for bad alignments passed into the romvec malloc() functions Since the handling of bad alignments is now internal to OFMEM, there is no need for the SPARC32 malloc() functions to have to do this any more. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/lib.c Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 19 09:03:59 2013 (r1121) +++ trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 19 09:04:25 2013 (r1122) @@ -285,28 +285,14 @@ char *obp_dumb_memalloc(char *va, unsigned int size) { - unsigned long align; - int i; + unsigned long align = size; DPRINTF("obp_dumb_memalloc: virta 0x%x, sz %d\n", (unsigned int)va, size); - /* Solaris seems to assume that the returned value is physically aligned to size. For - example, not having this here causes the Solaris 8 kernel to fault because the - IOMMU page table base address is calculated incorrectly. */ - - /* Enforce a minimum alignment of CONFIG_OFMEM_MALLOC_ALIGN, and choose an alignment - which is the next power of 2 higher than the specified size */ - align = size; - if (align <= CONFIG_OFMEM_MALLOC_ALIGN) { - align = CONFIG_OFMEM_MALLOC_ALIGN; - } else { - align--; - for (i = 1; i < sizeof(unsigned long) * 8; i<<=1) { - align |= align >> i; - } - align++; - } - + /* Solaris seems to assume that the returned value is physically aligned to size. + e.g. it is used for setting up page tables. Fortunately this is now handled by + ofmem_claim_phys() above. */ + return obp_memalloc(va, size, align); }

1 0

[commit] r1121 - trunk/openbios-devel/libopenbios
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:03:59 2013 New Revision: 1121 URL: http://tracker.coreboot.org/trac/openbios/changeset/1121 Log: OFMEM: Fix bad alignments passed into the OFMEM claim words If a memory claim is made with an alignment that is not an exact power of 2, round up to the nearest power of 2 as per the IEEE1275 specification rather than switching to a 4K default. Also we make sure that the minimum alignment is equivalent to PAGE_SIZE. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/libopenbios/ofmem_common.c Modified: trunk/openbios-devel/libopenbios/ofmem_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/ofmem_common.c Fri Apr 19 09:03:38 2013 (r1120) +++ trunk/openbios-devel/libopenbios/ofmem_common.c Fri Apr 19 09:03:59 2013 (r1121) @@ -425,13 +425,27 @@ { phys_addr_t base = min; range_t *r2; + ucell old_align; + int i; if( (align & (align-1)) ) { - OFMEM_TRACE("bad alignment " FMT_ucell "\n", align); - align = 0x1000; + + /* As per IEEE1275 specification, round up to the nearest power of 2 */ + old_align = align; + if (old_align <= PAGE_SIZE) { + align = PAGE_SIZE; + } else { + align--; + for (i = 1; i < sizeof(ucell) * 8; i<<=1) { + align |= align >> i; + } + align++; + } + + OFMEM_TRACE("warning: bad alignment " FMT_ucellx " rounded up to " FMT_ucellx "\n", old_align, align); } if( !align ) - align = 0x1000; + align = PAGE_SIZE; base = reverse ? max - size : min; r2 = reverse ? NULL : r;

1 0

[commit] r1120 - in trunk/openbios-devel: arch/sparc32 forth/device
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:03:38 2013 New Revision: 1120 URL: http://tracker.coreboot.org/trac/openbios/changeset/1120 Log: Remove /chosen "memory" property from the default device tree. Similar to the earlier commit for "mmu", do the same for /chosen "memory" property. Hence all architectures that want the "pretty" memory properties can provide suitable ihandles if required, and those that don't will not fail with a NULL pointer dereference from a zero ihandle. While we're here, correct the SPARC32 initialiser to point to the correct /virtual-memory node for "mmu" so that once again we can get "pretty" memory properties on SPARC32. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/init.fs trunk/openbios-devel/forth/device/tree.fs Modified: trunk/openbios-devel/arch/sparc32/init.fs ============================================================================== --- trunk/openbios-devel/arch/sparc32/init.fs Fri Apr 19 09:03:26 2013 (r1119) +++ trunk/openbios-devel/arch/sparc32/init.fs Fri Apr 19 09:03:38 2013 (r1120) @@ -32,7 +32,7 @@ \ preopen device nodes (and store the ihandles under /chosen) :noname " memory" " /memory" preopen - " mmu" " /cpus/@0" preopen + " mmu" " /virtual-memory" preopen ; SYSTEM-initializer device-end Modified: trunk/openbios-devel/forth/device/tree.fs ============================================================================== --- trunk/openbios-devel/forth/device/tree.fs Fri Apr 19 09:03:26 2013 (r1119) +++ trunk/openbios-devel/forth/device/tree.fs Fri Apr 19 09:03:38 2013 (r1120) @@ -53,7 +53,6 @@ 0 encode-int " stdout" property \ " hda1:/boot/vmunix" encode-string " bootpath" property \ " -as" encode-string " bootargs" property - 0 encode-int " memory" property finish-device \ END

1 0

[commit] r1119 - trunk/openbios-devel/libopenbios
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:03:26 2013 New Revision: 1119 URL: http://tracker.coreboot.org/trac/openbios/changeset/1119 Log: OFMEM: Fix selection of reusable memory areas from the internal malloc() freelist. The existing code would incorrectly allow freelist memory to be reused if the requested size were 0x1000 greater than the freelist item size, rather than the freelist item size being 0x1000 greater than the requested size. Since internal memory allocations could be smaller than requested, it would be possible for a caller to clobber over the internal memory heap causing a crash or internal memory corruption. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/libopenbios/ofmem_common.c Modified: trunk/openbios-devel/libopenbios/ofmem_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/ofmem_common.c Fri Apr 19 09:03:20 2013 (r1118) +++ trunk/openbios-devel/libopenbios/ofmem_common.c Fri Apr 19 09:03:26 2013 (r1119) @@ -107,7 +107,7 @@ } /* waste at most 4K by taking an entry from the freelist */ - if( *pp && (**pp).size < size + 0x1000 ) { + if( *pp && (**pp).size > size + 0x1000 ) { /* Alignment should be on physical not virtual address */ pa = va2pa((uintptr_t)*pp + sizeof(alloc_desc_t)); pa = align_ptr(pa, alignment);

1 0

[commit] r1118 - trunk/openbios-devel/arch/sparc32
by repository service 19 Apr '13

19 Apr '13

Author: mcayland Date: Fri Apr 19 09:03:20 2013 New Revision: 1118 URL: http://tracker.coreboot.org/trac/openbios/changeset/1118 Log: SPARC32: Add debugging output for calls to the romvec obp_memalloc() and obp_dumb_memalloc() functions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/lib.c Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Tue Apr 9 21:25:48 2013 (r1117) +++ trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 19 09:03:20 2013 (r1118) @@ -269,6 +269,8 @@ phys_addr_t phys; ucell virt; + DPRINTF("obp_memalloc: virta 0x%x, sz %d, align %d\n", (unsigned int)va, size, align); + /* Claim physical memory */ phys = ofmem_claim_phys(-1, size, align); @@ -286,6 +288,8 @@ unsigned long align; int i; + DPRINTF("obp_dumb_memalloc: virta 0x%x, sz %d\n", (unsigned int)va, size); + /* Solaris seems to assume that the returned value is physically aligned to size. For example, not having this here causes the Solaris 8 kernel to fault because the IOMMU page table base address is calculated incorrectly. */

1 0

[PATCH 0/7] Assorted OpenBIOS memory fixes
by Mark Cave-Ayland 14 Apr '13

14 Apr '13

This patchset fixes various issues found working with the removal of the zero page mapping for SPARC32/PPC in order to catch NULL pointer dereferences. With all patches applied, I see no regressions in any of my SPARC32 or PPC test images. Mark Cave-Ayland (7): SPARC32: Add debugging output for calls to the romvec obp_memalloc() and obp_dumb_memalloc() functions. OFMEM: Fix selection of reusable memory areas from the internal malloc() freelist. Remove /chosen "memory" property from the default device tree. OFMEM: Fix bad alignments passed into the OFMEM claim words SPARC32: Remove manual fix for bad alignments passed into the romvec malloc() functions SPARC32: Remove zero page mapping from MMU to enable detection of NULL pointer dereferences PPC: Remove zero page mapping from MMU to enable detection of NULL pointer dereferences openbios-devel/arch/ppc/qemu/ofmem.c | 11 ++++++--- openbios-devel/arch/sparc32/init.fs | 2 +- openbios-devel/arch/sparc32/lib.c | 34 ++++++++++----------------- openbios-devel/arch/sparc32/ofmem_sparc32.c | 3 +++ openbios-devel/forth/device/tree.fs | 1 - openbios-devel/libopenbios/ofmem_common.c | 22 +++++++++++++---- 6 files changed, 42 insertions(+), 31 deletions(-) -- 1.7.10.4

2 8

Re: [OpenBIOS] [PATCH 2/2] SPARC64: Remove limit on kernel command line length caused by using a static buffer
by Mark Cave-Ayland 13 Apr '13

13 Apr '13

On 13/04/13 10:07, Blue Swirl wrote: >> Instead use strdup() so that we can dynamically allocate the string ourselves. As > > Actually there's no call to strdup()... > >> reported by Rob Landley<rob(a)landley.net>. >> >> Signed-off-by: Mark Cave-Ayland<mark.cave-ayland(a)ilande.co.uk> >> --- >> openbios-devel/arch/sparc64/openbios.c | 11 ++++------- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/openbios-devel/arch/sparc64/openbios.c b/openbios-devel/arch/sparc64/openbios.c >> index 3b372b9..440e505 100644 >> --- a/openbios-devel/arch/sparc64/openbios.c >> +++ b/openbios-devel/arch/sparc64/openbios.c >> @@ -42,9 +42,6 @@ >> #define NVRAM_OB_START (0) >> #define NVRAM_OB_SIZE ((0x1fd0 - NVRAM_OB_START)& ~15) >> >> -#define OBIO_CMDLINE_MAX 256 >> -static char obio_cmdline[OBIO_CMDLINE_MAX]; >> - >> static uint8_t idprom[NVRAM_IDPROM_SIZE]; >> >> struct hwdef { >> @@ -370,6 +367,7 @@ static uint8_t qemu_uuid[16]; >> >> void arch_nvram_get(char *data) >> { >> + char *obio_cmdline = { '\0' }; > > Isn't this allocated in the stack? So ... > >> uint32_t size = 0; >> const struct cpudef *cpu; >> char buf[256]; >> @@ -401,12 +399,11 @@ void arch_nvram_get(char *data) >> kernel_image = fw_cfg_read_i64(FW_CFG_KERNEL_ADDR); >> >> size = fw_cfg_read_i32(FW_CFG_CMDLINE_SIZE); >> - if (size> OBIO_CMDLINE_MAX - 1) >> - size = OBIO_CMDLINE_MAX - 1; >> if (size) { >> + obio_cmdline = (char *)malloc(size + 1); >> fw_cfg_read(FW_CFG_CMDLINE_DATA, obio_cmdline, size); >> - } >> - obio_cmdline[size] = '\0'; >> + obio_cmdline[size] = '\0'; >> + } > > ... I'd add an 'else' case here with something like obio_cmdline = strdup(""). > >> qemu_cmdline = (uint64_t)obio_cmdline; >> cmdline_size = size; >> boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE); Thanks for the feedback - I've just posted a revised v2 patch to the list based upon your comments. ATB, Mark.

1 0

[v2 1/2] SPARC32: Remove limit on kernel command line length caused by using a static buffer
by Mark Cave-Ayland 13 Apr '13

13 Apr '13

Instead use strdup() so that we can dynamically allocate the string ourselves. As reported by Rob Landley <rob(a)landley.net>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/sparc32/openbios.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c index 95a5d37..de23a6f 100644 --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -835,8 +835,7 @@ static void init_memory(void) static void arch_init( void ) { - static char cmdline[128]; - int size = 0; + char *cmdline; const char *kernel_cmdline; uint32_t temp; uint16_t machine_id; @@ -897,11 +896,11 @@ arch_init( void ) kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); if (kernel_cmdline) { - size = strlen(kernel_cmdline); - memcpy(cmdline, kernel_cmdline, size); + cmdline = strdup(kernel_cmdline); obp_arg.argv[1] = cmdline; - } - cmdline[size] = '\0'; + } else { + cmdline = strdup(""); + } qemu_cmdline = (uint32_t)cmdline; /* Setup nvram variables */ -- 1.7.10.4

1 1

[PATCH 1/2] SPARC32: Remove limit on kernel command line length caused by using a static buffer
by Mark Cave-Ayland 13 Apr '13

13 Apr '13

Instead use strdup() so that we can dynamically allocate the string ourselves. As reported by Rob Landley <rob(a)landley.net>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/sparc32/openbios.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c index 95a5d37..56bafe8 100644 --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -835,8 +835,7 @@ static void init_memory(void) static void arch_init( void ) { - static char cmdline[128]; - int size = 0; + char *cmdline = { '\0' }; const char *kernel_cmdline; uint32_t temp; uint16_t machine_id; @@ -897,11 +896,9 @@ arch_init( void ) kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); if (kernel_cmdline) { - size = strlen(kernel_cmdline); - memcpy(cmdline, kernel_cmdline, size); + cmdline = strdup(kernel_cmdline); obp_arg.argv[1] = cmdline; } - cmdline[size] = '\0'; qemu_cmdline = (uint32_t)cmdline; /* Setup nvram variables */ -- 1.7.10.4

2 2

Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Mark Cave-Ayland 11 Apr '13

11 Apr '13

On 09/04/13 20:49, Artyom Tarasenko wrote: >> I've just committed a patch to fix this (on a second attempt as I >> accidentally caught the NULL dereference patch in there too) so please feel >> free to test. > > But we still don't need ihandle>phandle in (.property-by-name), do we? Yes, because the properties in /chosen are ihandles (see page 23 of the IEEE1275 specification). So if you are still seeing strange behaviour that could be another bug - if you can post a test case, I'll take a look. ATB, Mark.

3 4

Re: [OpenBIOS] [PATCH] Remove zero page mapping from all architectures to allow detection of NULL pointer dereferences.
by Mark Cave-Ayland 10 Apr '13

10 Apr '13

On 09/04/13 21:00, Artyom Tarasenko wrote: > You seem not to like my > > #define LOWMEM_START PAGE_SIZE > > ? I think it would have made distinguishing between the page size and > the offset parameters more obvious. When I took a look at your patch, I felt that with a comment and PAGE_SIZE on its own that it was fairly obvious what was happening (as I can't see it being something that people would want to keep changing). I don't feel overwhelmingly strongly about it, so if you or anyone else feel there is a good case for doing it that way then I'm happy to be persuaded. I think the most important thing at the moment is to work out why SPARC64 dereferences a NULL pointer during PCI enumeration though :/ ATB, Mark.

1 0

[PATCH] Remove zero page mapping from all architectures to allow detection of NULL pointer dereferences.
by Mark Cave-Ayland 09 Apr '13

09 Apr '13

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/ppc/qemu/ofmem.c | 7 ++++--- openbios-devel/arch/sparc32/lib.c | 6 +++--- openbios-devel/arch/sparc64/ofmem_sparc64.c | 4 ++-- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/openbios-devel/arch/ppc/qemu/ofmem.c b/openbios-devel/arch/ppc/qemu/ofmem.c index 0161a17..429f43b 100644 --- a/openbios-devel/arch/ppc/qemu/ofmem.c +++ b/openbios-devel/arch/ppc/qemu/ofmem.c @@ -549,9 +549,10 @@ ofmem_init(void) { ofmem_t *ofmem = ofmem_arch_get_private(); - ofmem_claim_phys(0, get_ram_bottom(), 0); - ofmem_claim_virt(0, get_ram_bottom(), 0); - ofmem_map(0, 0, get_ram_bottom(), 0); + /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ + ofmem_claim_phys(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_claim_virt(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_map(PAGE_SIZE, PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index c0df654..4ff3619 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -403,9 +403,9 @@ init_mmu_swift(void) ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); - // 1:1 mapping for RAM - ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); - ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + // 1:1 mapping for RAM (don't map page 0 to allow catching of NULL dereferences) + ofmem_arch_map_pages(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); /* * Flush cache diff --git a/openbios-devel/arch/sparc64/ofmem_sparc64.c b/openbios-devel/arch/sparc64/ofmem_sparc64.c index 50224e6..ece51f9 100644 --- a/openbios-devel/arch/sparc64/ofmem_sparc64.c +++ b/openbios-devel/arch/sparc64/ofmem_sparc64.c @@ -365,8 +365,8 @@ void ofmem_init( void ) /* inherit translations set up by entry.S */ ofmem_walk_boot_map(remap_page_range); - /* Map the memory */ - ofmem_map_page_range(0, 0, qemu_mem_size, 0x36); + /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ + ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, qemu_mem_size - PAGE_SIZE, 0x36); if (!(retained->magic == RETAIN_MAGIC)) { OFMEM_TRACE("ofmem_init: no retained magic found, creating\n"); -- 1.7.10.4

2 1

Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Mark Cave-Ayland 09 Apr '13

09 Apr '13

On 08/04/13 21:25, Artyom Tarasenko wrote: >> You're probably calling ihandle>phandle with a phandle. I would expect the >> return from active-package to be a phandle, not an ihandle. > > You are absolutely right. Removing ihandle>phandle helped. > Thanks a lot! Actually the fix is much easier than this: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 9 2013 18:40 Type 'help' for detailed information 0 > cd /chosen ok 0 > .properties name "chosen" stdin ffce26f4 stdout ffce278c memory ffce29c4 mmu 0 screen ffce2610 ok 0 > According to the sample prtconf output, SPARC32 doesn't have an "mmu" chosen handle so we should just remove it. Now currently the property lives in forth/device/tree.fs so it exists across all architectures, however SPARC64 and PPC are fine because they create the property on demand during initialisation. I've just committed a patch to fix this (on a second attempt as I accidentally caught the NULL dereference patch in there too) so please feel free to test. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 09 Apr '13

09 Apr '13

On 08/04/13 20:03, Artyom Tarasenko wrote: > Yes. It still can load kadb. The patchset looks good (although now I > have to rebase mine 2/2). I've just sent a patch out to the list to disable zero page mapping for all architectures; as far as I can tell SPARC32 and PPC are fine, whereas SPARC64 segfaults during PCI bus enumeration on bus 0 device 3. I don't have any time left to look at this today, but I'd definitely be interested to apply this soon if you can figure out what's going wrong. ATB, Mark.

1 0

[commit] r1117 - trunk/openbios-devel/forth/device
by repository service 09 Apr '13

09 Apr '13

Author: mcayland Date: Tue Apr 9 21:25:48 2013 New Revision: 1117 URL: http://tracker.coreboot.org/trac/openbios/changeset/1117 Log: Remove /chosen "mmu" property from the default device tree (second attempt). Not all architectures have an "mmu" property in /chosen, and having a NULL value causes the internal property formatting nodes to invoke a NULL ihandle reference. The architectures that require it already add it into the device tree as required during initialisation, so there should be no change in behaviour. As reported by Artyom Tarasenko. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/device/tree.fs Modified: trunk/openbios-devel/forth/device/tree.fs ============================================================================== --- trunk/openbios-devel/forth/device/tree.fs Tue Apr 9 21:25:46 2013 (r1116) +++ trunk/openbios-devel/forth/device/tree.fs Tue Apr 9 21:25:48 2013 (r1117) @@ -54,7 +54,6 @@ \ " hda1:/boot/vmunix" encode-string " bootpath" property \ " -as" encode-string " bootargs" property 0 encode-int " memory" property - 0 encode-int " mmu" property finish-device \ END

1 0

[commit] r1116 - in trunk/openbios-devel: arch/ppc/qemu arch/sparc32 arch/sparc64 forth/device
by repository service 09 Apr '13

09 Apr '13

Author: mcayland Date: Tue Apr 9 21:25:46 2013 New Revision: 1116 URL: http://tracker.coreboot.org/trac/openbios/changeset/1116 Log: Revert "Remove /chosen "mmu" property from the default device tree." This reverts commit 0bfdafe64f0e7e0a3a692292c82ed22df4d2188b as it accidentally contained parts of a subsequent patch. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c trunk/openbios-devel/forth/device/tree.fs Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Tue Apr 9 21:17:02 2013 (r1115) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Tue Apr 9 21:25:46 2013 (r1116) @@ -549,10 +549,9 @@ { ofmem_t *ofmem = ofmem_arch_get_private(); - /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ - ofmem_claim_phys(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - ofmem_claim_virt(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); - ofmem_map(PAGE_SIZE, PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_claim_phys(0, get_ram_bottom(), 0); + ofmem_claim_virt(0, get_ram_bottom(), 0); + ofmem_map(0, 0, get_ram_bottom(), 0); /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Tue Apr 9 21:17:02 2013 (r1115) +++ trunk/openbios-devel/arch/sparc32/lib.c Tue Apr 9 21:25:46 2013 (r1116) @@ -403,9 +403,9 @@ ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); - // 1:1 mapping for RAM (don't map page 0 to allow catching of NULL dereferences) - ofmem_arch_map_pages(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); - ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); + // 1:1 mapping for RAM + ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); /* * Flush cache Modified: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Tue Apr 9 21:17:02 2013 (r1115) +++ trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Tue Apr 9 21:25:46 2013 (r1116) @@ -365,8 +365,8 @@ /* inherit translations set up by entry.S */ ofmem_walk_boot_map(remap_page_range); - /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ - ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, qemu_mem_size - PAGE_SIZE, 0x36); + /* Map the memory */ + ofmem_map_page_range(0, 0, qemu_mem_size, 0x36); if (!(retained->magic == RETAIN_MAGIC)) { OFMEM_TRACE("ofmem_init: no retained magic found, creating\n"); Modified: trunk/openbios-devel/forth/device/tree.fs ============================================================================== --- trunk/openbios-devel/forth/device/tree.fs Tue Apr 9 21:17:02 2013 (r1115) +++ trunk/openbios-devel/forth/device/tree.fs Tue Apr 9 21:25:46 2013 (r1116) @@ -54,6 +54,7 @@ \ " hda1:/boot/vmunix" encode-string " bootpath" property \ " -as" encode-string " bootargs" property 0 encode-int " memory" property + 0 encode-int " mmu" property finish-device \ END

1 0

[commit] r1115 - in trunk/openbios-devel: arch/ppc/qemu arch/sparc32 arch/sparc64 forth/device
by repository service 09 Apr '13

09 Apr '13

Author: mcayland Date: Tue Apr 9 21:17:02 2013 New Revision: 1115 URL: http://tracker.coreboot.org/trac/openbios/changeset/1115 Log: Remove /chosen "mmu" property from the default device tree. Not all architectures have an "mmu" property in /chosen, and having a NULL value causes the internal property formatting nodes to invoke a NULL ihandle reference. The architectures that require it already add it into the device tree as required during initialisation, so there should be no change in behaviour. As reported by Artyom Tarasenko. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c trunk/openbios-devel/forth/device/tree.fs Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Tue Apr 9 20:32:53 2013 (r1114) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Tue Apr 9 21:17:02 2013 (r1115) @@ -549,9 +549,10 @@ { ofmem_t *ofmem = ofmem_arch_get_private(); - ofmem_claim_phys(0, get_ram_bottom(), 0); - ofmem_claim_virt(0, get_ram_bottom(), 0); - ofmem_map(0, 0, get_ram_bottom(), 0); + /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ + ofmem_claim_phys(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_claim_virt(PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); + ofmem_map(PAGE_SIZE, PAGE_SIZE, get_ram_bottom() - PAGE_SIZE, 0); /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Tue Apr 9 20:32:53 2013 (r1114) +++ trunk/openbios-devel/arch/sparc32/lib.c Tue Apr 9 21:17:02 2013 (r1115) @@ -403,9 +403,9 @@ ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); - // 1:1 mapping for RAM - ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); - ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + // 1:1 mapping for RAM (don't map page 0 to allow catching of NULL dereferences) + ofmem_arch_map_pages(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, LOWMEMSZ - PAGE_SIZE, ofmem_arch_default_translation_mode(0)); /* * Flush cache Modified: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Tue Apr 9 20:32:53 2013 (r1114) +++ trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Tue Apr 9 21:17:02 2013 (r1115) @@ -365,8 +365,8 @@ /* inherit translations set up by entry.S */ ofmem_walk_boot_map(remap_page_range); - /* Map the memory */ - ofmem_map_page_range(0, 0, qemu_mem_size, 0x36); + /* Map the memory (don't map page 0 to allow catching of NULL dereferences) */ + ofmem_map_page_range(PAGE_SIZE, PAGE_SIZE, qemu_mem_size - PAGE_SIZE, 0x36); if (!(retained->magic == RETAIN_MAGIC)) { OFMEM_TRACE("ofmem_init: no retained magic found, creating\n"); Modified: trunk/openbios-devel/forth/device/tree.fs ============================================================================== --- trunk/openbios-devel/forth/device/tree.fs Tue Apr 9 20:32:53 2013 (r1114) +++ trunk/openbios-devel/forth/device/tree.fs Tue Apr 9 21:17:02 2013 (r1115) @@ -54,7 +54,6 @@ \ " hda1:/boot/vmunix" encode-string " bootpath" property \ " -as" encode-string " bootargs" property 0 encode-int " memory" property - 0 encode-int " mmu" property finish-device \ END

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 09 Apr '13

09 Apr '13

On 08/04/13 20:03, Artyom Tarasenko wrote: > Yes. It still can load kadb. The patchset looks good (although now I > have to rebase mine 2/2). Great - thanks for testing! I've committed this so it should help you moving forward. ATB, Mark.

1 0

[commit] r1113 - trunk/openbios-devel/arch/sparc32
by repository service 09 Apr '13

09 Apr '13

Author: mcayland Date: Tue Apr 9 20:32:49 2013 New Revision: 1113 URL: http://tracker.coreboot.org/trac/openbios/changeset/1113 Log: SPARC32: Fix OFMEM mappings for OpenBIOS so that they show up in the translations property. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/lib.c Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Sat Apr 6 19:31:25 2013 (r1112) +++ trunk/openbios-devel/arch/sparc32/lib.c Tue Apr 9 20:32:49 2013 (r1113) @@ -401,9 +401,11 @@ size = (unsigned long)&_end - (unsigned long)&_start; pa = va2pa(va); ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); + ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); // 1:1 mapping for RAM ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); /* * Flush cache

1 0

Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Tarl Neustaedter 08 Apr '13

08 Apr '13

On 2013-Apr-8 15:00 , Artyom Tarasenko wrote: > I guess ihandle>phandle shouldn't be called for the root entry. What > do you think? You're probably calling ihandle>phandle with a phandle. I would expect the return from active-package to be a phandle, not an ihandle.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 08 Apr '13

08 Apr '13

On 07/04/13 21:10, Artyom Tarasenko wrote: >> Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough for >> kadb to work in your SunOS image? If that works, I'll create another patch >> series for you to test. > > You mean, instead of modifying ofmem_arch_get_virt_top, right? > Yes, this seems to be enough, kadb starts. Actually both are needed as I discovered that the virtual memory allocator starts at the top of the Forth machine RAM and works down, so at some point it would end up clobbering some Forth internals :/ Can you try the revised patchset I'm about to post on top of SVN trunk and http://www.openfirmware.info/pipermail/openbios/2013-April/007572.html and confirm that your kadb still loads? This works for me on my current SPARC32 test suite of Linux, Solaris 8 and NetBSD. Many thanks, Mark.

2 1

Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Artyom Tarasenko 08 Apr '13

08 Apr '13

On Sat, Apr 6, 2013 at 3:57 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > > Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> > --- > arch/sparc32/lib.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/sparc32/lib.c b/arch/sparc32/lib.c > index 483069c..215ddcc 100644 > --- a/arch/sparc32/lib.c > +++ b/arch/sparc32/lib.c > @@ -19,6 +19,8 @@ > > #define NCTX_SWIFT 0x100 > #define LOWMEMSZ 32 * 1024 * 1024 > +/* Avoid mapping the first page to make NULL-dereferencing more obvious */ > +#define LOWMEM_START PAGE_SIZE > > #ifdef CONFIG_DEBUG_MEM > #define DPRINTF(fmt, args...) \ > @@ -403,7 +405,8 @@ init_mmu_swift(void) > ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); > > // 1:1 mapping for RAM > - ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); > + ofmem_arch_map_pages(LOWMEM_START, LOWMEM_START, LOWMEMSZ, > + ofmem_arch_default_translation_mode(LOWMEM_START)); > > /* > * Flush cache Found one bug in Forth code using this patch: 0 > debug (.property-by-name) Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > cd / ok 0 > .properties name : (.property-by-name) ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ) ffd30c00: 2over ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e398 4 ) ffd30c04: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e398 4 ffd30c0c 3 ) ffd30c10: strcmp ( ffd2e398 4 ffd2e398 4 ffd3872c 14 1 ) ffd30c14: 0= ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 ) ffd30c18: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ) ffd30c38: active-package ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e318 ) ffd30c3c: get-nodename ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd3872c 13 ) ffd30c40: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd3872c 13 ffd30c48 6 ) ffd30c50: strcmp ( ffd2e398 4 ffd2e398 4 ffd3872c 14 1 ) ffd30c54: 0= ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 ) ffd30c58: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ) ffd30ca0: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd30ca8 7 ) ffd30cb0: find-dev ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ffffffff ) ffd30cb4: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ) ffd30cbc: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ffd30cc4 3 ) ffd30cc8: rot ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd30cc4 3 ffd2e6f8 ) ffd30ccc: get-package-property ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 0 ) ffd30cd0: 0= ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 ffffffff ) ffd30cd4: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 ) ffd30cdc: decode-int ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c8 0 0 ) ffd30ce0: nip ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c8 0 ) ffd30ce4: nip ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 ) ^^^^ here we have a null-pointer de-referencing. ffd30ce8: ihandle>phandle Unhandled Exception 0x00000009 PC = 0xffd07f74 NPC = 0xffd07f78 I guess ihandle>phandle shouldn't be called for the root entry. What do you think? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[PATCH 1/2] SPARC32: Fix OFMEM mappings for OpenBIOS so that they show up in the translations property.
by Mark Cave-Ayland 08 Apr '13

08 Apr '13

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/sparc32/lib.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 483069c..c0df654 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -401,9 +401,11 @@ init_mmu_swift(void) size = (unsigned long)&_end - (unsigned long)&_start; pa = va2pa(va); ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); + ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); // 1:1 mapping for RAM ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); /* * Flush cache -- 1.7.10.4

1 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 07 Apr '13

07 Apr '13

On 06/04/13 20:34, Artyom Tarasenko wrote: > Unfortunately not: > > OFMEM: ofmem_map_page_range ffdd3000 -> 050800000 000c0000 mode 0000003c > OFMEM: mapping altered virt=ffdd3000) > OFMEM: ofmem_map_page_range ffe93000 -> 050200000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe94000 -> 071000000 00001000 mode 0000003c > > OFMEM: ofmem_claim phys=ffffffffffffffff size=00080000 align=00001000 > OFMEM: ofmem_claim_virt virt=ffc80000 size=00080000 align=00000000 > > ^^^^ this one > > OFMEM: ofmem_map_page_range ffc80000 -> 006f80000 00080000 mode 000000bc > OFMEM: ofmem_map_page_range ffe95000 -> d00000000 00001000 mode 0000003c > Configuration device id QEMU version 1 machine id 32 > OFMEM: ofmem_map_page_range ffe96000 -> 010000000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe97000 -> 071100000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe98000 -> 071000000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe99000 -> 071200000 00002000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9b000 -> 071400000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9c000 -> 071900000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9d000 -> 071910000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9e000 -> 071f00000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9f000 -> 071d00000 00011000 mode 0000003c > OFMEM: ofmem_map_page_range ffeb0000 -> 071e00000 00011000 mode 0000003c > OFMEM: ofmem_map_page_range ffec1000 -> 007fff000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec2000 -> 010001000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec3000 -> 078400000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec4000 -> 078800000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec5000 -> 078400000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec6000 -> 078c00000 00001000 mode 0000003c > CPUs: 1 x FMI,MB86904 > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Mar 28 2013 13:34 > Type 'help' for detailed information > > > 0> boot disk kadb -kdvs Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fefff000 -> 006f7f000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range feffe000 -> 006f7e000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range feffd000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00002000 > OFMEM: ofmem_map_page_range fefe8000 -> 006f60000 00014000 mode 000000bc > Boot Release 4.1.4 (sun4m) #2: Fri Oct 14 11:07:52 PDT 1994 > Copyright (c) 1983-1990, Sun Microsystems, Inc. > Boot: Romvec version 3. > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range feffc000 -> 006f7c000 00001000 mode 000000bc > root on /iommu/sbus/espdma/esp/sd@0,0 fstype 4.2 > Boot: kadb > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fefe7000 -> 006f7b000 00001000 mode 000000bc > .Size: 121296............................+103120+14200 bytes > Statistics: > OFMEM: ofmem_claim phys=ffffffffffffffff size=0003c000 align=00040000 > OFMEM: ofmem_claim_virt virt=ffc00000 size=0003c000 align=00000000 > OFMEM: ofmem_map_page_range ffc00000 -> 006f00000 0003c000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fefe6000 -> 006f7a000 00001000 mode 000000bc > kadb: > kadb: vmunix > .Size: 1548288......................................................................................................................................................................................................................................................+463688+225704 > bytes > OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000 > OFMEM: ofmem_claim_virt virt=ffc3c000 size=00003000 align=00000000 > OFMEM: ofmem_map_page_range ffc3c000 -> 006f74000 00003000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=ffc3f000 size=00001000 align=00000000 > OFMEM: ofmem_map_page_range ffc3f000 -> 006f79000 00001000 mode 000000bc > .OFMEM: ofmem_claim phys=ffffffffffffffff size=0001c000 align=00020000 > OFMEM: ofmem_claim_virt virt=ffc40000 size=0001c000 align=00000000 > OFMEM: ofmem_map_page_range ffc40000 -> 006f40000 0001c000 mode 000000bc > ................OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 > align=00001000 > OFMEM: ofmem_claim_virt virt=ffc5c000 size=00001000 align=00000000 > OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc5f000 -> 006f5c000 00002000 mode 000000bc > .....OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc61000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc61000 -> 006f3e000 00002000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc63000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc63000 -> 006f3c000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc65000 -> 006efe000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc67000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc67000 -> 006efc000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc69000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc69000 -> 006efa000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc6b000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc6b000 -> 006ef8000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc6d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc6d000 -> 006ef6000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc6f000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc6f000 -> 006ef4000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc71000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc71000 -> 006ef2000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc73000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc73000 -> 006ef0000 00002000 mode 000000bc > ....OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000 > OFMEM: ofmem_claim_virt virt=ffc75000 size=00003000 align=00000000 > OFMEM: ofmem_map_page_range ffc75000 -> 006eec000 00003000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc78000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc78000 -> 006eea000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000 > OFMEM: ofmem_claim_virt virt=ffc7a000 size=00003000 align=00000000 > OFMEM: ofmem_map_page_range ffc7a000 -> 006ee4000 00003000 mode 000000bc > ....OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc7d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc7d000 -> 006ee8000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc7f000 size=00002000 align=00000000 > OFMEM: Non-free virtual memory claimed! > > ^^^^^ overlaps with this one. Hmmm so a quick look at the Linux source code (and some dumps from QEMU's "info tlb") showed me what has happening here. The problem is that Linux doesn't read the value of the "translations" property from OpenBIOS when taking over the MMU page table - instead it performs a manual scan of the existing page table between a range of addresses. It looks as if the range is from 0xfe400000 to 0xfff00000, however the lower ends of these ranges seem to be repurposed for debuggers and I/O memory - so it means that if we keep anything too far outside of the PROM range 0xffd00000 to 0xfff00000 then we're going to be in trouble. Unfortunately because we map the entire framebuffer directly then we don't have much memory to play with :( I think the only solution is to reduce the amount of memory for the Forth machine for SPARC32 by changing MEMORY_SIZE in arch/sparc32/openbios.c, and then tucking it underneath 0xffd00000 as per my last patchset. So far I can get away with reducing it to 128K, and Bob's original test case for increasing the Forth machine memory (because of lack of memory for the Fcode table) still runs, e.g. fd000000 1000 l! 00000020 1004 l! 12095145 1008 l! 4d552c74 100c l! 65737401 1010 l! 1412046e 1014 l! 616d6501 1018 l! 10000000 101c l! cd /iommu/sbus " /iommu/sbus" select-dev new-device 1000 1 byte-load Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough for kadb to work in your SunOS image? If that works, I'll create another patch series for you to test. ATB, Mark.

2 1

Re: [OpenBIOS] [PATCH 1/2] Fix NULL-dereferencing in sunparts_open
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 18:42, Artyom Tarasenko wrote: >> Thanks - this is a similar bug to the one that was in mac-parts.c so I've >> applied it. > > I've found it after applying the patch preventing mapping of the page > 0 and looking what breaks. > It may be a good idea not to map the page 0 on other architectures too. Yeah I'd be quite tempted to make this the default (and it's probably why load-base is often set to 0x4000 so page 0 can be unmapped). Blue - what do you think? ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 10:46, Artyom Tarasenko wrote: >> Yes! In kadb I get! >> >> FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc >> .vmunix loaded - 0x7c000 bytes used >> >> Unfortunately it's not as helpful as it became under Solaris 2.6+ : > > Especially when someone hasn't use it for the long time. Actually it's > pretty good: > > kadb> :c > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc > Begin traceback... sp = f0186b20 > Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 > Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 > f0186d88 f01e2ff4 > Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 > ff000008 ff000008 4400fe1 > Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 > Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 > Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 > Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0 > Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0 > f01e2b1c ffffffff > Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570 > Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1 > End traceback... > fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874 > stopped at 0: unimp 0x0 > kadb> $c > PR_BASE() + 0 > kadb> f0054f44?ai > _writekmsg+0x68: _writekmsg+0x68: call > _mpprom_write_nl7 > kadb> f0005250?ai > _firsthighinstr+0xd8: _firsthighinstr+0xd8: call > _early_startup > kadb> > > Woo-hoo! Hi Artyom, I've just posted a patchset to lower the virtual memory allocation range - can you test with that patchset applied, plus my patch in http://www.openfirmware.info/pipermail/openbios/2013-April/007572.html means that you can still load kadb on your image? If that works, I'll put together a patch to move the alignment rounding up behaviour in core OFMEM, as detailed in the specification. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 11:07 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>>> >>>> [...] >>> You might change that patch rather than rounding up to the next 2^n, don't >>> bother aligning to anything more than 0x2000. >> >> You mean >> >> } else if ( align > 0x2000) { >> align = 0x2000; >> } else { > > This would probably break allocation for IOMMU table, it needs to be > aligned (physically) to table size (like 32MB). The patch actually changes only the virtual alignment. It seems to work without this part though. -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[PATCH 1/3] SPARC32: Fix OpenBIOS ROM in RAM copy mapping.
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

This ensures that the physical and virtual addresses for OpenBIOS itself are marked as in use, and also appear in the translations property so they can be maintained by client programs. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/sparc32/ofmem_sparc32.c | 6 ++++-- openbios-devel/include/arch/sparc32/ofmem_sparc32.h | 4 +++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/openbios-devel/arch/sparc32/ofmem_sparc32.c b/openbios-devel/arch/sparc32/ofmem_sparc32.c index e2f4159..a6557df 100644 --- a/openbios-devel/arch/sparc32/ofmem_sparc32.c +++ b/openbios-devel/arch/sparc32/ofmem_sparc32.c @@ -241,6 +241,8 @@ void ofmem_init( void ) /* Claim reserved physical addresses at top of RAM */ ofmem_claim_phys(ofmem_arch_get_phys_top(), s_ofmem_data.ofmem.ramsize - ofmem_arch_get_phys_top(), 0); - /* Claim OpenBIOS reserved space */ - ofmem_claim_virt(0xffd00000, 0x300000, 0); + /* Map OpenBIOS ROM in RAM copy */ + ofmem_claim_phys(va2pa(OF_CODE_START), s_ofmem_data.ofmem.ramsize - va2pa(OF_CODE_START), 0); + ofmem_claim_virt(OF_CODE_START, (ucell)-1, 0); + ofmem_map_page_range(va2pa(OF_CODE_START), OF_CODE_START, s_ofmem_data.ofmem.ramsize - va2pa(OF_CODE_START), ofmem_arch_default_translation_mode(OF_CODE_START)); } diff --git a/openbios-devel/include/arch/sparc32/ofmem_sparc32.h b/openbios-devel/include/arch/sparc32/ofmem_sparc32.h index 7a35b44..6ffa172 100644 --- a/openbios-devel/include/arch/sparc32/ofmem_sparc32.h +++ b/openbios-devel/include/arch/sparc32/ofmem_sparc32.h @@ -16,6 +16,8 @@ #include "libopenbios/ofmem.h" +#define OF_CODE_START 0xffd00000 + struct mem; extern struct mem cdvmem; @@ -25,4 +27,4 @@ extern unsigned long find_pte(unsigned long va, int alloc); void mem_init(struct mem *t, char *begin, char *limit); void *mem_alloc(struct mem *t, int size, int align); -#endif /* _H_OFMEM_SPARC32 */ \ No newline at end of file +#endif /* _H_OFMEM_SPARC32 */ -- 1.7.10.4

1 2

Re: [OpenBIOS] [PATCH 1/2] Fix NULL-dereferencing in sunparts_open
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 02:57, Artyom Tarasenko wrote: > Signed-off-by: Artyom Tarasenko<atar4qemu(a)gmail.com> > --- > packages/sun-parts.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/packages/sun-parts.c b/packages/sun-parts.c > index 2ee9613..272f7c0 100644 > --- a/packages/sun-parts.c > +++ b/packages/sun-parts.c > @@ -109,7 +109,7 @@ sunparts_open( sunparts_info_t *di ) > [(id)][,][filespec] > */ > > - if ( strlen(str) ) { > + if ( str&& strlen(str) ) { > /* Detect the arguments */ > if ((*str>= '0'&& *str<= '9') || (*str>= 'a'&& *str< ('a' + 8)) || (*str == ',')) { > push_str(str); Thanks - this is a similar bug to the one that was in mac-parts.c so I've applied it. ATB, Mark.

2 1

[commit] r1112 - trunk/openbios-devel/packages
by repository service 06 Apr '13

06 Apr '13

Author: mcayland Date: Sat Apr 6 19:31:25 2013 New Revision: 1112 URL: http://tracker.coreboot.org/trac/openbios/changeset/1112 Log: sun-parts.c: Fix NULL-dereferencing in sunparts_open Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/packages/sun-parts.c Modified: trunk/openbios-devel/packages/sun-parts.c ============================================================================== --- trunk/openbios-devel/packages/sun-parts.c Fri Apr 5 12:34:38 2013 (r1111) +++ trunk/openbios-devel/packages/sun-parts.c Sat Apr 6 19:31:25 2013 (r1112) @@ -109,7 +109,7 @@ [(id)][,][filespec] */ - if ( strlen(str) ) { + if ( str && strlen(str) ) { /* Detect the arguments */ if ((*str >= '0' && *str <= '9') || (*str >= 'a' && *str < ('a' + 8)) || (*str == ',')) { push_str(str);

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 10:27 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sat, Apr 6, 2013 at 9:16 AM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> On 05/04/13 21:08, Tarl Neustaedter wrote: >> >>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>>> >>>> [...] >>>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 >>>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 >>>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc >>>> >>>> ^^^^ this one >>> >>> >>> Wherever that's coming from, that looks like an allocator doing >>> descending addresses. >>> >>>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 >>>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc >>>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 >>>> OFMEM: Non-free virtual memory claimed! >>>> >>>> ^^^^ overlaps with this one. >>> >>> >>> This allocator, whatever it is has been doing ascending addresses. This >>> actually looks like you simply ran out of room. >> >> >> Ah now I see. It looks as if kadb assumes that it has free use of the region >> from 0xffc00000 but the OFMEM allocator starts auto-allocating memory from >> beneath the internal heap which is below the ROM image at 0xffd00000. As >> Tarl rightly points out, as the allocations grow then kadb tries to grab an >> area of memory we have already claimed which causes the overlap error. >> >> Does the attached patch against SVN trunk enable you to get into kadb? It's >> the same as my last patch except for the following addition: >> >> --- a/openbios-devel/arch/sparc32/ofmem_sparc32.c >> +++ b/openbios-devel/arch/sparc32/ofmem_sparc32.c >> @@ -61,7 +61,7 @@ ucell ofmem_arch_get_heap_top(void) >> >> ucell ofmem_arch_get_virt_top(void) >> { >> - return (ucell)TOP_OF_RAM; >> + return (ucell)0xff000000; >> } >> >> So when we are auto-allocating from OFMEM, rather than starting from beneath >> the internal heap, we simply start auto-allocating from 0xff000000 downwards >> which should leave the 0xffc00000 region being used by kadb well alone. A >> quick test with the patch shows that my Solaris 8 image can still boot both >> normally and into kadb. > > Yes! In kadb I get! > > FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc > .vmunix loaded - 0x7c000 bytes used > > Unfortunately it's not as helpful as it became under Solaris 2.6+ : Especially when someone hasn't use it for the long time. Actually it's pretty good: kadb> :c OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc Begin traceback... sp = f0186b20 Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 f0186d88 f01e2ff4 Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 ff000008 ff000008 4400fe1 Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0 Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0 f01e2b1c ffffffff Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570 Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1 End traceback... fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874 stopped at 0: unimp 0x0 kadb> $c PR_BASE() + 0 kadb> f0054f44?ai _writekmsg+0x68: _writekmsg+0x68: call _mpprom_write_nl7 kadb> f0005250?ai _firsthighinstr+0xd8: _firsthighinstr+0xd8: call _early_startup kadb> Woo-hoo! -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 11:07 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>>> >>>> [...] >>>> >>>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 >>>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 >>>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc >>>> >>>> ^^^^ this one >>> >>> >>> Wherever that's coming from, that looks like an allocator doing descending >>> addresses. >>> >>> >>>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 >>>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc >>>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 >>>> OFMEM: Non-free virtual memory claimed! >>>> >>>> ^^^^ overlaps with this one. >>> >>> >>> This allocator, whatever it is has been doing ascending addresses. This >>> actually looks like you simply ran out of room. >> >> Ops. Good catch! >> Mark, can we just allocate more RAM, or do we have serious problem? >> >>> You might change that patch rather than rounding up to the next 2^n, don't >>> bother aligning to anything more than 0x2000. >> >> You mean >> >> } else if ( align > 0x2000) { >> align = 0x2000; >> } else { > > This would probably break allocation for IOMMU table, it needs to be > aligned (physically) to table size (like 32MB). Hmm. The successful log in the previous mail was produced with this code... Will remove it and test again. -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 09:27, Artyom Tarasenko wrote: > Unfortunately it's not as helpful as it became under Solaris 2.6+ : > > kadb> :c > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc > Begin traceback... sp = f0186b20 > Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 > Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 > f0186d88 f01e2ff4 > Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 > ff000008 ff000008 4400fe1 > Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 > Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 > Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 ^^^^^^^^ From memory the 0xf005... address range in Solaris 8 was used for dynamic kernel modules. So I'd start using kadb/remote GDB to poke around 0xf0054494 in memory until you find some strings that can help you identify which module it is for clues. BTW does "boot disk -v" give you any suitable output now? ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Blue Swirl 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>> >>> [...] >>> >>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc >>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 >>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 >>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc >>> >>> ^^^^ this one >> >> >> Wherever that's coming from, that looks like an allocator doing descending >> addresses. >> >> >>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc >>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 >>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc >>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 >>> OFMEM: Non-free virtual memory claimed! >>> >>> ^^^^ overlaps with this one. >> >> >> This allocator, whatever it is has been doing ascending addresses. This >> actually looks like you simply ran out of room. > > Ops. Good catch! > Mark, can we just allocate more RAM, or do we have serious problem? > >> You might change that patch rather than rounding up to the next 2^n, don't >> bother aligning to anything more than 0x2000. > > You mean > > } else if ( align > 0x2000) { > align = 0x2000; > } else { This would probably break allocation for IOMMU table, it needs to be aligned (physically) to table size (like 32MB). > > ? Then it crashes allocating the same address (0xffc66000) as in the > previous log. > Or, don't bother at all? > > } else if ( align > 0x2000) { > align = 0; > } else { > > Then it dies pretty early: > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7f000 -> 006f7f000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7e000 -> 006f7e000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00000000 > OFMEM: ofmem_map_page_range 00000000 -> 006f60000 00014000 mode 000000bc > kmem_alloc failed, nbytes 81920 > kmem_alloc > boot-block startup failed > > Artyom > > -- > Regards, > Artyom Tarasenko > > linux/sparc and solaris/sparc under qemu blog: > http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 09:27, Artyom Tarasenko wrote: >> So when we are auto-allocating from OFMEM, rather than starting from beneath >> the internal heap, we simply start auto-allocating from 0xff000000 downwards >> which should leave the 0xffc00000 region being used by kadb well alone. A >> quick test with the patch shows that my Solaris 8 image can still boot both >> normally and into kadb. > > Yes! In kadb I get! Great - I'll spin up a couple of patches for this. > FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc > .vmunix loaded - 0x7c000 bytes used > > Unfortunately it's not as helpful as it became under Solaris 2.6+ : > > kadb> :c > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc > Begin traceback... sp = f0186b20 > Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 > Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 > f0186d88 f01e2ff4 > Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 > ff000008 ff000008 4400fe1 > Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 > Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 > Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 > Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0 > Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0 > f01e2b1c ffffffff > Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570 > Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1 > End traceback... > fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874 > stopped at 0: unimp 0x0 > kadb> bt > symbol not found > kadb> > > But still it's definitely a progress! Indeed :) I remember when I got this far with Solaris 8, my next step was to extract vmunix from the ISO image and run it through objdump - while it didn't contain full debug information, it did contain function name symbols which was enough for me to work out where the problem was. Note that it may be worth grabbing vmunix from the original boot CD and checking that too, just in case kernels with extra debug information are used for the installation media but not for a HD image. ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 06 Apr '13

06 Apr '13

On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: > [...] > OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 > OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc > > ^^^^ this one Wherever that's coming from, that looks like an allocator doing descending addresses. > OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 > OFMEM: Non-free virtual memory claimed! > > ^^^^ overlaps with this one. This allocator, whatever it is has been doing ascending addresses. This actually looks like you simply ran out of room. You might change that patch rather than rounding up to the next 2^n, don't bother aligning to anything more than 0x2000.

3 3

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 06 Apr '13

06 Apr '13

On 2013-Apr-5 21:50 , Artyom Tarasenko wrote: >> >You might change that patch rather than rounding up to the next 2^n, don't >> >bother aligning to anything more than 0x2000. > You mean > > } else if ( align > 0x2000) { > align = 0x2000; > } else { Yeah, that's what I meant. Evidently the extra storage you were consuming by rounding everything up to 2^n wasn't the problem.

1 0

[PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Artyom Tarasenko 06 Apr '13

06 Apr '13

Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> --- arch/sparc32/lib.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/sparc32/lib.c b/arch/sparc32/lib.c index 483069c..215ddcc 100644 --- a/arch/sparc32/lib.c +++ b/arch/sparc32/lib.c @@ -19,6 +19,8 @@ #define NCTX_SWIFT 0x100 #define LOWMEMSZ 32 * 1024 * 1024 +/* Avoid mapping the first page to make NULL-dereferencing more obvious */ +#define LOWMEM_START PAGE_SIZE #ifdef CONFIG_DEBUG_MEM #define DPRINTF(fmt, args...) \ @@ -403,7 +405,8 @@ init_mmu_swift(void) ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); // 1:1 mapping for RAM - ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + ofmem_arch_map_pages(LOWMEM_START, LOWMEM_START, LOWMEMSZ, + ofmem_arch_default_translation_mode(LOWMEM_START)); /* * Flush cache -- 1.7.1

1 0

[PATCH 1/2] Fix NULL-dereferencing in sunparts_open
by Artyom Tarasenko 06 Apr '13

06 Apr '13

Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> --- packages/sun-parts.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/packages/sun-parts.c b/packages/sun-parts.c index 2ee9613..272f7c0 100644 --- a/packages/sun-parts.c +++ b/packages/sun-parts.c @@ -109,7 +109,7 @@ sunparts_open( sunparts_info_t *di ) [(id)][,][filespec] */ - if ( strlen(str) ) { + if ( str && strlen(str) ) { /* Detect the arguments */ if ((*str >= '0' && *str <= '9') || (*str >= 'a' && *str < ('a' + 8)) || (*str == ',')) { push_str(str); -- 1.7.1

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 05 Apr '13

05 Apr '13

On 05/04/13 08:35, Artyom Tarasenko wrote: >> Actually there is another option - does the previous allocation before this >> one that returns 0xffc67000 as the virtual address? In that case it could >> indicate that va=0x0 doesn't have a special meaning after all. >> >> Is it possible for you to post the complete log output from an unpatched >> OpenBIOS for us to look at so we can see the complete pattern of >> allocations? > > The with the unpatched one it dies pretty early, right after claiming va=0x0. > See the the attachment. Got it. Hmmm definitely a special behaviour when va == NULL seems to be the more likely explanation for the moment. Let me know if anything changes with my latest patch. Otherwise I think you'd have to disassemble the boot loader a bit to see where the va = NULL is coming from. If it's a constant 0x0 then that would definitely confirm that the value has a special behaviour. ATB, Mark.

2 1

[commit] r1111 - trunk/openbios-devel/drivers
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 12:34:38 2013 New Revision: 1111 URL: http://tracker.coreboot.org/trac/openbios/changeset/1111 Log: macio: Remove unnecessary newworld check openpic_init is only called on newworld machines. Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/macio.c Modified: trunk/openbios-devel/drivers/macio.c ============================================================================== --- trunk/openbios-devel/drivers/macio.c Fri Apr 5 12:34:10 2013 (r1110) +++ trunk/openbios-devel/drivers/macio.c Fri Apr 5 12:34:38 2013 (r1111) @@ -167,43 +167,41 @@ fword("finish-device"); - if (is_newworld()) { - u32 *interrupt_map; - int len, i; + u32 *interrupt_map; + int len, i; - /* patch in interrupt parent */ - dnode = find_dev(buf); + /* patch in interrupt parent */ + dnode = find_dev(buf); - target_node = find_dev("/pci/mac-io"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci/mac-io/escc/ch-a"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/escc/ch-a"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci/mac-io/escc/ch-b"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/escc/ch-b"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci/mac-io/ata-1"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/ata-1"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci/mac-io/ata-2"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/ata-2"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci/mac-io/ata-3"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/ata-3"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci/mac-io/via-cuda"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/via-cuda"); + set_int_property(target_node, "interrupt-parent", dnode); - target_node = find_dev("/pci"); - set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci"); + set_int_property(target_node, "interrupt-parent", dnode); - interrupt_map = (u32 *)get_property(target_node, "interrupt-map", &len); - for (i = 0; i < 8; i++) { - interrupt_map[(i * 7) + PCI_INT_MAP_PIC_HANDLE] = (u32)dnode; - } - set_property(target_node, "interrupt-map", (char *)interrupt_map, len); + interrupt_map = (u32 *)get_property(target_node, "interrupt-map", &len); + for (i = 0; i < 8; i++) { + interrupt_map[(i * 7) + PCI_INT_MAP_PIC_HANDLE] = (u32)dnode; } + set_property(target_node, "interrupt-map", (char *)interrupt_map, len); } DECLARE_NODE(ob_macio, INSTALL_OPEN, sizeof(int), "Tmac-io");

1 0

[commit] r1110 - trunk/openbios-devel/drivers
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 12:34:10 2013 New Revision: 1110 URL: http://tracker.coreboot.org/trac/openbios/changeset/1110 Log: pci: Set interrupts property only on newworld machines Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/pci.c Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Fri Apr 5 12:33:57 2013 (r1109) +++ trunk/openbios-devel/drivers/pci.c Fri Apr 5 12:34:10 2013 (r1110) @@ -854,7 +854,7 @@ if (config->irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts", config->irq_line)); - set_int_property(dev, "interrupts", config->irq_pin); + NEWWORLD(set_int_property(dev, "interrupts", config->irq_pin)); } set_int_property(dev, "min-grant", pci_config_read8(addr, PCI_MIN_GNT));

1 0

[commit] r1109 - trunk/openbios-devel/drivers
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 12:33:57 2013 New Revision: 1109 URL: http://tracker.coreboot.org/trac/openbios/changeset/1109 Log: pci/macio: Add missing interrupt-parent properties Based on patch from Andreas Tobler. Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> CC: Andreas Tobler <andreast(a)fgznet.ch> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/macio.c trunk/openbios-devel/drivers/pci.c Modified: trunk/openbios-devel/drivers/macio.c ============================================================================== --- trunk/openbios-devel/drivers/macio.c Fri Apr 5 12:33:22 2013 (r1108) +++ trunk/openbios-devel/drivers/macio.c Fri Apr 5 12:33:57 2013 (r1109) @@ -183,11 +183,23 @@ target_node = find_dev("/pci/mac-io/escc/ch-b"); set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci/mac-io/ata-1"); + set_int_property(target_node, "interrupt-parent", dnode); + + target_node = find_dev("/pci/mac-io/ata-2"); + set_int_property(target_node, "interrupt-parent", dnode); + + target_node = find_dev("/pci/mac-io/ata-3"); + set_int_property(target_node, "interrupt-parent", dnode); + + target_node = find_dev("/pci/mac-io/via-cuda"); + set_int_property(target_node, "interrupt-parent", dnode); + target_node = find_dev("/pci"); set_int_property(target_node, "interrupt-parent", dnode); interrupt_map = (u32 *)get_property(target_node, "interrupt-map", &len); - for (i = 0; i < 4; i++) { + for (i = 0; i < 8; i++) { interrupt_map[(i * 7) + PCI_INT_MAP_PIC_HANDLE] = (u32)dnode; } set_property(target_node, "interrupt-map", (char *)interrupt_map, len); Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Fri Apr 5 12:33:22 2013 (r1108) +++ trunk/openbios-devel/drivers/pci.c Fri Apr 5 12:33:57 2013 (r1109) @@ -375,7 +375,7 @@ */ #if defined(CONFIG_PPC) phandle_t dev = get_cur_dev(); - u32 props[7 * 4]; + u32 props[7 * 8]; int i; #if defined(CONFIG_PPC) @@ -384,7 +384,7 @@ return; #endif - for (i = 0; i < (7*4); i+=7) { + for (i = 0; i < (7*8); i+=7) { props[i+PCI_INT_MAP_PCI0] = 0; props[i+PCI_INT_MAP_PCI1] = 0; props[i+PCI_INT_MAP_PCI2] = 0; @@ -393,7 +393,7 @@ props[i+PCI_INT_MAP_PIC_INT] = arch->irqs[i / 7]; props[i+PCI_INT_MAP_PIC_POL] = 3; } - set_property(dev, "interrupt-map", (char *)props, 7 * 4 * sizeof(props[0])); + set_property(dev, "interrupt-map", (char *)props, 7 * 8 * sizeof(props[0])); props[PCI_INT_MAP_PCI0] = 0; props[PCI_INT_MAP_PCI1] = 0;

1 0

[commit] r1108 - trunk/openbios-devel/drivers
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 12:33:22 2013 New Revision: 1108 URL: http://tracker.coreboot.org/trac/openbios/changeset/1108 Log: macio: Fix ide interrupts initialization interrupts and #interrupt-cells are newworld properties. Also oldworld interrupts were not properly set, i.e. second one was always set to 0 instead of correct value. Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/ide.c Modified: trunk/openbios-devel/drivers/ide.c ============================================================================== --- trunk/openbios-devel/drivers/ide.c Fri Apr 5 12:33:03 2013 (r1107) +++ trunk/openbios-devel/drivers/ide.c Fri Apr 5 12:33:22 2013 (r1108) @@ -1611,9 +1611,11 @@ } props[1] = 0x00000000; /* XXX level triggered on real hw */ props[3] = 0x00000000; - set_property(dnode, "interrupts", - (char *)&props, 4*sizeof(props[0])); - set_int_property(dnode, "#interrupt-cells", 2); + NEWWORLD(set_property(dnode, "interrupts", + (char *)&props, 4*sizeof(props[0]))); + NEWWORLD(set_int_property(dnode, "#interrupt-cells", 2)); + + props[1] = props[2]; OLDWORLD(set_property(dnode, "AAPL,interrupts", (char *)&props, 2*sizeof(props[0])));

1 0

[commit] r1107 - trunk/openbios-devel/config/scripts
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 12:33:03 2013 New Revision: 1107 URL: http://tracker.coreboot.org/trac/openbios/changeset/1107 Log: Allow powerpc-unknown-linux-gnu- toolchain prefix crossdev on gentoo builds crosscompiler with powerpc-unknown-linux-gnu- prefix. Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/config/scripts/switch-arch Modified: trunk/openbios-devel/config/scripts/switch-arch ============================================================================== --- trunk/openbios-devel/config/scripts/switch-arch Fri Apr 5 11:35:17 2013 (r1106) +++ trunk/openbios-devel/config/scripts/switch-arch Fri Apr 5 12:33:03 2013 (r1107) @@ -97,7 +97,7 @@ select_prefix() { - for TARGET in ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- do if type ${TARGET}gcc > /dev/null 2>&1 then

1 0

[commit] r1106 - trunk/openbios-devel/arch/ppc/qemu
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 11:35:17 2013 New Revision: 1106 URL: http://tracker.coreboot.org/trac/openbios/changeset/1106 Log: PPC: Add the old-world bootcode device dev:,%BOOT to the bootdevice list By adding the bootcode device to the bootdevice list as processed by load, we automatically attempt to invoke the bootcode loader as required. As a consequence of this, we can now remove the separate C codepath used in order to facilitate an old-world boot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Graf <agraf(a)suse.de> CC: Andreas Färber <afaerber(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c trunk/openbios-devel/arch/ppc/qemu/main.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Fri Apr 5 11:35:08 2013 (r1105) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Fri Apr 5 11:35:17 2013 (r1106) @@ -855,7 +855,7 @@ } /* Setup default boot devices */ - snprintf(buf, sizeof(buf), "%s:,\\\\:tbxi %s:,\\ppc\\bootinfo.txt", boot_path, boot_path); + snprintf(buf, sizeof(buf), "%s:,\\\\:tbxi %s:,\\ppc\\bootinfo.txt %s:,%%BOOT", boot_path, boot_path, boot_path); push_str(buf); fword("encode-string"); push_str("boot-device"); Modified: trunk/openbios-devel/arch/ppc/qemu/main.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/main.c Fri Apr 5 11:35:08 2013 (r1105) +++ trunk/openbios-devel/arch/ppc/qemu/main.c Fri Apr 5 11:35:17 2013 (r1106) @@ -39,141 +39,6 @@ #define ELF_DPRINTF(fmt, args...) SUBSYS_DPRINTF("ELF", fmt, ##args) #define NEWWORLD_DPRINTF(fmt, args...) SUBSYS_DPRINTF("NEWWORLD", fmt, ##args) -static char * -get_device( const char *path ) -{ - int i; - static char buf[1024]; - - for (i = 0; i < sizeof(buf) && path[i] && path[i] != ':'; i++) - buf[i] = path[i]; - buf[i] = 0; - - return buf; -} - -static int -get_partition( const char *path ) -{ - while ( *path && *path != ':' ) - path++; - - if (!*path) - return -1; - path++; - - if (!strchr(path, ',')) /* check if there is a ',' */ - return -1; - - return atol(path); -} - -static char * -get_filename( const char * path , char **dirname) -{ - static char buf[1024]; - char *filename; - - while ( *path && *path != ':' ) - path++; - - if (!*path) { - *dirname = NULL; - return NULL; - } - path++; - - while ( *path && isdigit(*path) ) - path++; - - if (*path == ',') - path++; - - strncpy(buf, path, sizeof(buf)); - buf[sizeof(buf) - 1] = 0; - - filename = strrchr(buf, '\\'); - if (filename) { - *dirname = buf; - (*filename++) = 0; - } else { - *dirname = NULL; - filename = buf; - } - - return filename; -} - - -static void -encode_bootpath( const char *spec, const char *args ) -{ - char path[1024]; - phandle_t chosen_ph = find_dev("/chosen"); - char *filename, *directory; - int partition; - - if (spec) - return; - - filename = get_filename(spec, &directory); - partition = get_partition(spec); - if (partition == -1) - snprintf(path, sizeof(path), "%s:,%s\\%s", get_device(spec), - directory, filename); - else - snprintf(path, sizeof(path), "%s:%d,%s\\%s", get_device(spec), - partition, directory, filename); - - ELF_DPRINTF("bootpath %s bootargs %s\n", path, args); - set_property( chosen_ph, "bootpath", path, strlen(path)+1 ); - if (args) - set_property( chosen_ph, "bootargs", args, strlen(args)+1 ); -} - -#define OLDWORLD_BOOTCODE_BASEADDR (0x3f4000) - -static void -oldworld_boot( void ) -{ - int fd; - int len, total; - const char *path = "hd:,%BOOT"; - char *bootcode; - - if ((fd = open_io(path)) == -1) { - ELF_DPRINTF("Can't open %s\n", path); - return; - } - - - total = 0; - bootcode = (char*)OLDWORLD_BOOTCODE_BASEADDR; - while(1) { - if (seek_io(fd, total) == -1) - break; - len = read_io(fd, bootcode, 512); - bootcode += len; - total += len; - } - - close_io( fd ); - - if (total == 0) { - ELF_DPRINTF("Can't read %s\n", path); - return; - } - - encode_bootpath(path, "Linux"); - - if( ofmem_claim( OLDWORLD_BOOTCODE_BASEADDR, total, 0 ) == -1 ) - fatal_error("Claim failed!\n"); - - call_elf(0, 0, OLDWORLD_BOOTCODE_BASEADDR); - - return; -} - static void check_preloaded_kernel(void) { unsigned long kernel_image, kernel_size; @@ -213,9 +78,5 @@ check_preloaded_kernel(); } - if (boot_device == 'c') { - oldworld_boot(); - } - update_nvram(); }

1 0

[commit] r1105 - in trunk/openbios-devel: config/examples forth/debugging include/libopenbios libopenbios packages
by repository service 05 Apr '13

05 Apr '13

Author: mcayland Date: Fri Apr 5 11:35:08 2013 New Revision: 1105 URL: http://tracker.coreboot.org/trac/openbios/changeset/1105 Log: loader: implement new loader type for CHRP/Apple partition bootcode (%BOOT) One of the primary reasons that issues with the quik bootloader were not detected earlier was because arch/ppc/qemu/main.c has a separate code path for forcing an old-world boot when -boot c is passed to QEMU. This commit implements the bootcode loader as a core OpenBIOS loader which enables old-world payloads such as quik to be executed using: load hd:,%BOOT go Note that we also fix a bug in mac-parts.c to ensure that we don't try and interpose a filesystem package when %BOOT is passed as a filename. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Graf <agraf(a)suse.de> CC: Andreas Färber <afaerber(a)suse.de> Added: trunk/openbios-devel/include/libopenbios/bootcode_load.h trunk/openbios-devel/libopenbios/bootcode_load.c Modified: trunk/openbios-devel/config/examples/ppc_config.xml trunk/openbios-devel/forth/debugging/client.fs trunk/openbios-devel/libopenbios/build.xml trunk/openbios-devel/libopenbios/load.c trunk/openbios-devel/packages/mac-parts.c Modified: trunk/openbios-devel/config/examples/ppc_config.xml ============================================================================== --- trunk/openbios-devel/config/examples/ppc_config.xml Thu Apr 4 13:26:41 2013 (r1104) +++ trunk/openbios-devel/config/examples/ppc_config.xml Fri Apr 5 11:35:08 2013 (r1105) @@ -26,6 +26,7 @@ <option name="CONFIG_VGA_DEPTH" type="integer" value="8"/> <option name="CONFIG_LOADER_AOUT" type="boolean" value="false"/> <option name="CONFIG_LOADER_BOOTINFO" type="boolean" value="true"/> + <option name="CONFIG_LOADER_BOOTCODE" type="boolean" value="true"/> <option name="CONFIG_LOADER_ELF" type="boolean" value="true"/> <option name="CONFIG_LOADER_FCODE" type="boolean" value="false"/> <option name="CONFIG_LOADER_FORTH" type="boolean" value="false"/> Modified: trunk/openbios-devel/forth/debugging/client.fs ============================================================================== --- trunk/openbios-devel/forth/debugging/client.fs Thu Apr 4 13:26:41 2013 (r1104) +++ trunk/openbios-devel/forth/debugging/client.fs Fri Apr 5 11:35:08 2013 (r1105) @@ -27,6 +27,9 @@ variable state-valid 0 state-valid ! +variable want-bootcode +0 want-bootcode ! + variable file-size : !load-size file-size ! ; @@ -44,6 +47,7 @@ 5 constant aout 10 constant fcode 11 constant forth +12 constant bootcode : init-program ( -- ) Added: trunk/openbios-devel/include/libopenbios/bootcode_load.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/include/libopenbios/bootcode_load.h Fri Apr 5 11:35:08 2013 (r1105) @@ -0,0 +1,22 @@ +/* + * Creation Date: <2010/03/22 18:00:00 mcayland> + * Time-stamp: <2010/03/22 18:00:00 mcayland> + * + * <bootcode_load.h> + * + * Raw bootcode (%BOOT) loader + * + * Copyright (C) 2013 Mark Cave-Ayland (mark.cave-ayland(a)ilande.co.uk) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation + * + */ + +#ifndef _H_BOOTCODELOAD +#define _H_BOOTCODELOAD + +extern int bootcode_load(ihandle_t dev); + +#endif /* _H__H_BOOTCODELOAD */ Added: trunk/openbios-devel/libopenbios/bootcode_load.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/libopenbios/bootcode_load.c Fri Apr 5 11:35:08 2013 (r1105) @@ -0,0 +1,71 @@ +/* + * Raw bootcode loader (CHRP/Apple %BOOT) + * Written by Mark Cave-Ayland 2013 + */ + +#include "config.h" +#include "kernel/kernel.h" +#include "libopenbios/bindings.h" +#include "libopenbios/bootcode_load.h" +#include "libc/diskio.h" +#include "drivers/drivers.h" +#define printf printk +#define debug printk + +#define OLDWORLD_BOOTCODE_BASEADDR (0x3f4000) + +int +bootcode_load(ihandle_t dev) +{ + int retval = -1, count = 0, fd; + unsigned long bootcode, loadbase, offset; + + /* Mark the saved-program-state as invalid */ + feval("0 state-valid !"); + + fd = open_ih(dev); + if (fd == -1) { + goto out; + } + + /* Default to loading at load-base */ + fword("load-base"); + loadbase = POP(); + +#ifdef CONFIG_PPC + /* However Old World Macs need to load to a different address */ + if (is_oldworld()) { + loadbase = OLDWORLD_BOOTCODE_BASEADDR; + } +#endif + + bootcode = loadbase; + offset = 0; + + while(1) { + if (seek_io(fd, offset) == -1) + break; + count = read_io(fd, (void *)bootcode, 512); + offset += count; + bootcode += count; + } + + /* If we didn't read anything then exit */ + if (!count) { + goto out; + } + + /* Initialise saved-program-state */ + PUSH(loadbase); + feval("saved-program-state >sps.entry !"); + PUSH(offset); + feval("saved-program-state >sps.file-size !"); + feval("bootcode saved-program-state >sps.file-type !"); + + feval("-1 state-valid !"); + +out: + close_io(fd); + return retval; +} + Modified: trunk/openbios-devel/libopenbios/build.xml ============================================================================== --- trunk/openbios-devel/libopenbios/build.xml Thu Apr 4 13:26:41 2013 (r1104) +++ trunk/openbios-devel/libopenbios/build.xml Fri Apr 5 11:35:08 2013 (r1105) @@ -3,6 +3,7 @@ <library name="openbios" type="static" target="target"> <object source="aout_load.c" condition="LOADER_AOUT"/> <object source="bindings.c"/> + <object source="bootcode_load.c" condition="LOADER_BOOTCODE"/> <object source="bootinfo_load.c" condition="LOADER_BOOTINFO"/> <object source="client.c"/> <object source="console_common.c"/> Modified: trunk/openbios-devel/libopenbios/load.c ============================================================================== --- trunk/openbios-devel/libopenbios/load.c Thu Apr 4 13:26:41 2013 (r1104) +++ trunk/openbios-devel/libopenbios/load.c Fri Apr 5 11:35:08 2013 (r1105) @@ -36,6 +36,10 @@ #include "libopenbios/forth_load.h" #endif +#ifdef CONFIG_LOADER_BOOTCODE +#include "libopenbios/bootcode_load.h" +#endif + struct sys_info sys_info; void *elf_boot_notes = NULL; @@ -92,4 +96,13 @@ } #endif +#ifdef CONFIG_LOADER_BOOTCODE + /* Check for a "raw" %BOOT bootcode payload */ + feval("want-bootcode @"); + valid = POP(); + if (valid) { + bootcode_load(dev); + } +#endif + } Modified: trunk/openbios-devel/packages/mac-parts.c ============================================================================== --- trunk/openbios-devel/packages/mac-parts.c Thu Apr 4 13:26:41 2013 (r1104) +++ trunk/openbios-devel/packages/mac-parts.c Fri Apr 5 11:35:08 2013 (r1105) @@ -89,8 +89,12 @@ parnum = atol(parstr); /* Detect if we are looking for the bootcode */ - if (strcmp(argstr, "%BOOT") == 0) + if (strcmp(argstr, "%BOOT") == 0) { want_bootcode = 1; + feval("1 want-bootcode !"); + } else { + feval("0 want-bootcode !"); + } } DPRINTF("parstr: %s argstr: %s parnum: %d\n", parstr, argstr, parnum); @@ -285,16 +289,10 @@ set_property(chosen_ph, "bootpath", bootpath, strlen(bootpath) + 1); } - - /* If the filename was %BOOT then it's not a real filename, so clear argstr before - attempting interpose */ - if (want_bootcode) { - argstr = strdup(""); - } - + /* If we have been asked to open a particular file, interpose the filesystem package with the passed filename as an argument */ - if (strlen(argstr)) { + if (!want_bootcode && strlen(argstr)) { push_str( argstr ); PUSH_ph( ph ); fword("interpose");

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 05 Apr '13

05 Apr '13

On 05/04/13 02:23, Artyom Tarasenko wrote: >> That's interesting. You're asking for a page size (0x2000) on a non-page >> boundary (0xffc6.5000). The complaint is because it extends far enough to >> overlap with what the map_page_range above (0xffc6.6000). > > Yes. After looking more carefully I think it goes wrong before this point: > > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7f000 -> 006f7f000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7e000 -> 006f7e000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00014000 > OFMEM: bad alignment 81920 > > ^^^ here is something OpenBIOS doesn't like. Ah yes. Since in the case where va == NULL we've set align = size, we still need to round align to the nearest power of 2. Does the attached patch help at all? Note that this is just a proof-of-concept patch. Since the specification is quite clear about this behaviour, if it works then I'll move the power of 2 rounding directly into OFMEM so cases like this are handled automatically. ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 05 Apr '13

05 Apr '13

On 04/04/13 20:35, Artyom Tarasenko wrote: > SunOS crashes at the same place as with your previous patch. (Which is > probably a good sign). > > There is one interesting thing when I try to boot kadb: > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc66000 -> 006f7a000 00001000 mode 000000bc So 0xffc66000 must be being returned back to client for it to use during subsequent calculations... > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000 Can you definitely confirm that virt == va after this second call to ofmem_claim_virt()? (i.e. confirm that va isn't being rounded to 0xffc65000 when passing in va = 0xffc64000 somehow?). ATB, Mark.

2 2

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 05 Apr '13

05 Apr '13

On 2013-Apr-4 15:35 , Artyom Tarasenko wrote: > OFMEM: ofmem_map_page_range ffc66000 -> 006f7a000 00001000 mode 000000bc > ... > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000 > OFMEM: Non-free virtual memory claimed! That's interesting. You're asking for a page size (0x2000) on a non-page boundary (0xffc6.5000). The complaint is because it extends far enough to overlap with what the map_page_range above (0xffc6.6000). The question is where those two addresses are coming from? 0xffc6.6000 and 0xffc6.5000 are in the range Solaris would expect for Openboot - whoever came up with 0xffc6.5000 got it wrong, if he needs 0x2000 bytes, he needed to ask for 0xffc6.4000. > > Does IEEE-1275 say something about this case? This is simply a matter of overlapping address ranges. Somewhere an allocator is getting the wrong result.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 04 Apr '13

04 Apr '13

On 03/04/13 11:14, Artyom Tarasenko wrote: > It seems to be an unrelated problem, double allocation of the page 0 > is still a double allocation. > > OTOH maybe the hint address 0 is an explicit invitation to get a next > free chunk? Very interesting. That could actually be right for two reasons: 1. 0x1000 is a multiple of page size 2. If you're not checking the return result, then what is the sense in requesting the same allocation (va = 0) twice? So yes, I'd definitely try adding some test code to check if va == 0, and if so, set align = size before calling ofmem_claim_virt(). ATB, Mark.

2 2

[commit] r1104 - trunk/openbios-devel/arch/ppc/qemu
by repository service 04 Apr '13

04 Apr '13

Author: afaerber Date: Thu Apr 4 13:26:41 2013 New Revision: 1104 URL: http://tracker.coreboot.org/trac/openbios/changeset/1104 Log: ppc: Fix is_apple() for PReP It was returning true for ARCH_PREP although not an Apple device. Limit it to Old World and New World Macs. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Fri Mar 22 15:16:46 2013 (r1103) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Thu Apr 4 13:26:41 2013 (r1104) @@ -76,7 +76,7 @@ int is_apple(void) { - return 1; + return is_oldworld() || is_newworld(); } int is_oldworld(void)

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 03 Apr '13

03 Apr '13

On 03/04/13 08:02, Artyom Tarasenko wrote: >> Per IEEE 1275, 6.3.2.4, the claim method is supposed to entirely ignore the >> virtual address if you provide an alignment. With a non-zero alignment, it's >> supposed to allocate from a pool of its own address space. > > Thanks, this is a good starting point. Can you give some comments to an > OpenSolaris comment below? > http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L79 > > /* > * resource allocation group: OBP and IEEE 1275-1994. > * prom_alloc is platform dependent on SPARC. > */ > > What is exactly platform dependent? While the above is true for the IEEE 1275 claim word, there is definitely a different behaviour for the old romvec memalloc() method. Bear in mind that the parameters look like this in gdb: Breakpoint 1, obp_memalloc (va=0xf0040000 <Address 0xf0040000 out of bounds>, size=262144, align=262144) at /home/build/src/openbios/openbios-git/openbios-devel/arch/sparc32/lib.c:273 However if we pass the align parameter to the virtual allocator too, as per my suggestion, the boot loader then blows up with the following message: Alloc of 0x40000 bytes at 0xf0040000 refused. So the old romvec routines clearly expect the specified virtual address to be allocated, even if an align parameter is passed. Currently we assume that this is just a physical alignment, so any clarification on this behaviour would be quite useful. Of course we'll know a lot more if you can post the debug output requested in my previous email :) ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 03 Apr '13

03 Apr '13

On 2013-Apr-2 17:37 , Artyom Tarasenko wrote: >> >to: >> > >> >virt = ofmem_claim_virt(pointer2cell(va), size, align); >> > >> >Does that fix the bug for you? >> > > At least, it seems to die some instructions later, thanks! Will debug more. > Does it mean that obp_memalloc is actually using the first argument > just as a hint? As the OpenSolaris header suggests? Per IEEE 1275, 6.3.2.4, the /claim/ method is supposed to entirely ignore the virtual address if you provide an alignment. With a non-zero alignment, it's supposed to allocate from a pool of its own address space.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 03 Apr '13

03 Apr '13

On 02/04/13 22:37, Artyom Tarasenko wrote: >> Ah I think I may see the bug here - what if you change arch/sparc32/lib.c >> line 276 in obp_memalloc() from: >> >> virt = ofmem_claim_virt(pointer2cell(va), size, 0); >> >> to: >> >> virt = ofmem_claim_virt(pointer2cell(va), size, align); >> >> Does that fix the bug for you? >> > > At least, it seems to die some instructions later, thanks! Will debug more. > Does it mean that obp_memalloc is actually using the first argument > just as a hint? As the OpenSolaris header suggests? (goes away and tests) Hmmmm I'm not sure that does the right thing as the change causes my Solaris 8 boot to crash. Basically if align is not set to zero then the virtual address is ignored, and OFMEM simply allocates a chunk of memory on the specified alignment. From my boot here with this change: Breakpoint 1, obp_memalloc (va=0xf0040000 <Address 0xf0040000 out of bounds>, size=262144, align=262144) at /home/build/src/openbios/openbios-git/openbios-devel/arch/sparc32/lib.c:273 273 phys = ofmem_claim_phys(-1, size, align); (gdb) p/x align $1 = 0x40000 (gdb) next 276 virt = ofmem_claim_virt(pointer2cell(va), size, align); (gdb) p/x phys $2 = 0x6f40000 (gdb) next 279 ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); (gdb) p/x virt $3 = 0xffc40000 (gdb) next 281 return cell2pointer(virt); (gdb) p/x virt $4 = 0xffc40000 (gdb) next 282 } (gdb) 0x001134e8 in ?? () (gdb) cont Continuing. Remote connection closed So it would seem that the caller is definitely expecting to get a VA of 0xf0040000 back. In fact looking at http://fxr.watson.org/fxr/source/sun4/os/startup.c?v=OPENSOLARIS#L818 the caller only accepts the same VA being returned as an indication of success. This does remind me of a problem on SPARC64 where we get warnings from the bootloader because we are trying to reallocate the same region. Perhaps the right question to ask is what should the behaviour be if a region is allocated twice? For example, what should happen in this case below: virt1 = ofmem_claim(0xf0004000, 0x2000, 0); virt2 = ofmem_claim(0xf0004000, 0x1000, 0); If the virtual address 0xf0004000 is already claimed and mapped, should the old mapping be completely removed, or would we have to do something more complex such as split the mapped region into a new physical region and remap the first half of the split virtual region to the new physical region? Also for reference, can you post a tar.gz of your output with both CONFIG_DEBUG_OBP and CONFIG_DEBUG_OFMEM enabled for the build (but without my modification) so we can see the duplicate memalloc? ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 02 Apr '13

02 Apr '13

On 02/04/13 20:12, Artyom Tarasenko wrote: > After some debugging, I think the problem is in the current > obp_memalloc realization: it calls ofmem_claim_virt which > expects the address to be precise and thus can not be called > twice for the same virtual address. > > Looking at the OpenSolaris headers ( > http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L83 ) > > extern caddr_t prom_alloc(caddr_t virthint, size_t size, uint_t align); > > it seems that "virthint" is just a hint for a virtual address, so > prom_alloc (which is our obp_memalloc) shall not fail unless the whole > RAM is exhausted. > The comment on lines 70-71 says: > > "The alloc function should guarantee that it will never return an > invalid pointer." > > Someone cares to fix? Ah I think I may see the bug here - what if you change arch/sparc32/lib.c line 276 in obp_memalloc() from: virt = ofmem_claim_virt(pointer2cell(va), size, 0); to: virt = ofmem_claim_virt(pointer2cell(va), size, align); Does that fix the bug for you? ATB, Mark.

2 1

setting the reg property of the mac-io node
by Programmingkid 02 Apr '13

02 Apr '13

I am trying to set the reg property of the mac-io node so it matches the properties of a real Beige G3 computer. Does anyone know the file that this information is kept in? Mac OS X is very sensitive to the value of properties in Open Firmware. One wrong value is enough to stop Mac OS X from booting. Since OpenBIOS has a ton of missing and different values for properties with respect to the Beige G3, I theorized that this might be the reason why OpenBIOS can't make Mac OS X run. Any help with locating the reg property for the mac-io node would be great.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 02 Apr '13

02 Apr '13

After some debugging, I think the problem is in the current obp_memalloc realization: it calls ofmem_claim_virt which expects the address to be precise and thus can not be called twice for the same virtual address. Looking at the OpenSolaris headers ( http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L83 ) extern caddr_t prom_alloc(caddr_t virthint, size_t size, uint_t align); it seems that "virthint" is just a hint for a virtual address, so prom_alloc (which is our obp_memalloc) shall not fail unless the whole RAM is exhausted. The comment on lines 70-71 says: "The alloc function should guarantee that it will never return an invalid pointer." Someone cares to fix? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [Qemu-devel] OpenBios in Sparc can't handle long kernel command lines.
by Mark Cave-Ayland 30 Mar '13

30 Mar '13

On 22/03/13 05:19, Rob Landley wrote: > If I do this: > > qemu-system-sparc -nographic -no-reboot -kernel image -hda hda.sqf > -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 > PATH=/usr/distcc:/bin:/sbin console=ttyS0 HOST=sparc CPUS=1 > DISTCC_HOSTS=10.0.2.2:31322/1 FTP_SERVER=10.0.2.2 FTP_PORT=31307 > NATIVE_BUILD=lfs-bootstrap ' -hdb hdb.img -hdc lfs-bootstrap.hdc -m 256 > > qemu goes: > > ^[[H^[[JConfiguration device id QEMU version 1 machine id 32 > CPUs: 1 x FMI,MB86904 > Unhandled Exception 0x00000007 > PC = 0xffd07d28 NPC = 0xffd07d2c > Stopping execution > > And then hangs. I've never figured out why it clears the screen first > (none of the other targets do), but I _have_ figured out that the > unhandled exception is "kernel command line too long". Because 197 bytes > is just too much data for Sparc to cope with. This is actually a bug in OpenBIOS which declares the command line storage like this: static void arch_init( void ) { static char cmdline[128]; .... kernel_cmdline = (const char *) fw_cfg_read_i32(FW_CFG_KERNEL_CMDLINE); if (kernel_cmdline) { size = strlen(kernel_cmdline); memcpy(cmdline, kernel_cmdline, size); obp_arg.argv[1] = cmdline; } cmdline[size] = '\0'; .... } Would increasing it to 256 bytes be enough? I can't say I've ever come across command lines in a normal environment with more than about 80 characters, but I don't see an issue with increasing it. ATB, Mark.

3 2

Re: [OpenBIOS] selecting a sparc framebuffer from command line
by Mark Cave-Ayland 30 Mar '13

30 Mar '13

On 27/03/13 16:43, Artyom Tarasenko wrote: >> So as a stepping stone, should we create an FCode ROM for TCX? > > Sounds reasonable to me, but > - afaik the current TCX implementation is written in C, no Forth. So > maybe it's easier to keep the current implementation in OpenBIOS and > just add some kind of auto-detection. > - I'm not a graphic guy. :) I run qemu -nographic whenever possible. > So I'd wait till someone from the graphic side comments on it. > > Blue? Mark? I'm actually slightly ahead of you here. Take a look at my OpenBIOS console patchset I posted a couple of weeks ago, and in particular this patch: http://www.openfirmware.info/pipermail/openbios/2013-March/007491.html. Both tcx.fs and vga.fs were deliberately designed so that with minimum effort they can be converted to an Fcode payload suitable for a display device, similar to as mentioned here: http://docs.oracle.com/cd/E19683-01/806-1379-10/displydv.html. The minor downside is that we'd have to specify fcode-utils as a dependency for building the resulting Fcode images, but that's not insurmountable. So yes, if QEMU are happy to host the FCode binaries then it would be great if we could specify the SPARC cg3 framebuffer using something like: -device cg3,rom=QEMU,cg3.bin Obviously the in-built QEMU,cg3.bin would be the default file if rom= was not specified, but it means that people booting using real SUN OBP images can point to a real SUNW Fcode display ROM and use that if desired with the same patch. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 28 Mar '13

28 Mar '13

On Thu, Mar 28, 2013 at 4:04 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Thu, Mar 28, 2013 at 3:23 PM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: > >> obp_nextnode() is actually very simple in that it just calls the Forth >> "peer" word. Do you see the same phandles if you cycle through the device >> tree using "peer" directly from the OpenBIOS prompt? >> >> 0 peer >> dup u. peer > > 0 > 0 peer dup u. ffd2e31c ok > 1 > peer u. 0 ok > > I guess '/' has no peers, one would have to descend. > > Otherwise it looks sane: > > 0 > ffd2e438 ok > 1 > peer dup u. ffd2e4dc ok > 1 > peer dup u. ffd2e684 ok > 1 > peer dup u. ffd2e6fc ok > 1 > peer dup u. ffd2e7e0 ok > 1 > peer dup u. ffd34050 ok > 1 > peer dup u. ffd35a58 ok > 1 > peer dup u. ffd35afc ok > 1 > peer dup u. ffd35ba8 ok > 1 > peer dup u. ffd36360 ok > 1 > peer dup u. ffd3972c ok > 1 > peer dup u. 0 ok > > ffd3972c - is the same value as in the show-devs output. No, that's a wrong trail. The address of the "FMI,MB86904" node is just different depending on whether the -prom-env 'auto-boot?=false' is used. Might be a bug (all other nodes don't depend on the qemu command line), but irrelevant to this case. If I boot with auto-boot?=false and then boot disk it shows the proper address, but crashes the same way. Will give it another try next week(end). -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 28 Mar '13

28 Mar '13

On 28/03/13 13:52, Artyom Tarasenko wrote: >> Can you put together a quick patch for obp_child() and obp_nextnode() so >> that if CONFIG_DEBUG_OBP is enabled, they also output the package name in >> the debug string as well as the phandle? Take a look at how obp_proplen uses >> get-package-property in order to get hold of the "name" property from the >> package. >> >> (Or in fact, for an even quicker hack, the (void) POP() in obp_proplen() is >> dropping a pointer to a string itself. So if you display that instead then >> for your output above you should see the package name displayed) > > Ok. Did the later, and now it looks even stranger: > > obp_proplen(0xffd35ba8, name) = 6 (iommu) > obp_nextnode(0xffd35ba8) = 0xffd36360 > obp_proplen(0xffd36360, name) = 5 (obio) > obp_nextnode(0xffd36360) = 0xffd39724 > obp_proplen(0xffd39724, name) = 12 (FMI,MB86904) > obp_nextnode(0xffd39724) = 0x0 > Unhandled Exception 0x00000007 > > But: > 0> show-devs > ffd2e31c / > [...] > ffd35ba8 /iommu > [...] > ffd36360 /obio (hierarchical) > [...] > ffd3972c /FMI,MB86904 (cpu) > > Why does obp_nextnode(0xffd36360) return 0xffd39724 ? According to > show-devs it must be 0xffd3972c ! Yeah... that doesn't like quite right at all :/ obp_nextnode() is actually very simple in that it just calls the Forth "peer" word. Do you see the same phandles if you cycle through the device tree using "peer" directly from the OpenBIOS prompt? 0 peer dup u. peer dup u. peer dup u. peer ..etc.. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 28 Mar '13

28 Mar '13

On 28/03/13 08:38, Artyom Tarasenko wrote: > Back to the original topic: > > Here is the boot log with romvec debug: > > Configuration device id QEMU version 1 machine id 32 > CPUs: 1 x FMI,MB86904 > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Mar 26 2013 13:29 > Type 'help' for detailed information > Trying disk... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > obp_nextnode(0x0) = 0xffd4531c > obp_child(0xffd4531c) = 0xffd45438 > obp_proplen(0xffd45438, name) = 8 > obp_nextnode(0xffd45438) = 0xffd454dc > obp_proplen(0xffd454dc, name) = 9 > obp_nextnode(0xffd454dc) = 0xffd45684 > obp_proplen(0xffd45684, name) = 8 > obp_nextnode(0xffd45684) = 0xffd456fc > obp_proplen(0xffd456fc, name) = 7 > obp_nextnode(0xffd456fc) = 0xffd457e0 > obp_proplen(0xffd457e0, name) = 8 > obp_nextnode(0xffd457e0) = 0xffd4b084 > obp_proplen(0xffd4b084, name) = 9 > obp_nextnode(0xffd4b084) = 0xffd4ca8c > obp_proplen(0xffd4ca8c, name) = 7 > obp_nextnode(0xffd4ca8c) = 0xffd4cb30 > obp_proplen(0xffd4cb30, name) = 15 > obp_nextnode(0xffd4cb30) = 0xffd4cbdc > obp_proplen(0xffd4cbdc, name) = 6 > obp_nextnode(0xffd4cbdc) = 0xffd4d394 > obp_proplen(0xffd4d394, name) = 5 > obp_nextnode(0xffd4d394) = 0xffd50758 > obp_proplen(0xffd50758, name) = 12 > obp_nextnode(0xffd50758) = 0x0 > obp_devopen(/iommu/sbus/espdma/esp/sd@0,0) = 0xffc831f8 > obp_devseek(fd 0xffc831f8, hi 0, lo 3637248) = 0 > obp_devread(fd 0xffc831f8, buf 0x4000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3645440) = 0 > obp_devread(fd 0xffc831f8, buf 0x6000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3653632) = 0 > obp_devread(fd 0xffc831f8, buf 0x8000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3661824) = 0 > obp_devread(fd 0xffc831f8, buf 0xa000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3670016) = 0 > obp_devread(fd 0xffc831f8, buf 0xc000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3678208) = 0 > obp_devread(fd 0xffc831f8, buf 0xe000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3686400) = 0 > obp_devread(fd 0xffc831f8, buf 0x10000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3694592) = 0 > obp_devread(fd 0xffc831f8, buf 0x12000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3702784) = 0 > obp_devread(fd 0xffc831f8, buf 0x14000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3710976) = 0 > obp_devread(fd 0xffc831f8, buf 0x16000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3719168) = 0 > obp_devread(fd 0xffc831f8, buf 0x18000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3727360) = 0 > obp_devread(fd 0xffc831f8, buf 0x1a000, nbytes 8192) = 8192 > obp_devseek(fd 0xffc831f8, hi 0, lo 3743744) = 0 > obp_devread(fd 0xffc831f8, buf 0x1c000, nbytes 8192) = 8192 > obp_devclose(0xffc831f8) = 1 > obp_nextnode(0x0) = 0xffd4531c > obp_child(0xffd4531c) = 0xffd45438 > obp_proplen(0xffd45438, name) = 8 > obp_nextnode(0xffd45438) = 0xffd454dc > obp_proplen(0xffd454dc, name) = 9 > obp_nextnode(0xffd454dc) = 0xffd45684 > obp_proplen(0xffd45684, name) = 8 > obp_nextnode(0xffd45684) = 0xffd456fc > obp_proplen(0xffd456fc, name) = 7 > obp_nextnode(0xffd456fc) = 0xffd457e0 > obp_proplen(0xffd457e0, name) = 8 > obp_nextnode(0xffd457e0) = 0xffd4b084 > obp_proplen(0xffd4b084, name) = 9 > obp_nextnode(0xffd4b084) = 0xffd4ca8c > obp_proplen(0xffd4ca8c, name) = 7 > obp_nextnode(0xffd4ca8c) = 0xffd4cb30 > obp_proplen(0xffd4cb30, name) = 15 > obp_nextnode(0xffd4cb30) = 0xffd4cbdc > obp_proplen(0xffd4cbdc, name) = 6 > obp_nextnode(0xffd4cbdc) = 0xffd4d394 > obp_proplen(0xffd4d394, name) = 5 > obp_nextnode(0xffd4d394) = 0xffd50758 > > ^^^^ is that correct? > > obp_proplen(0xffd50758, name) = 12 > obp_nextnode(0xffd50758) = 0x0 > Unhandled Exception 0x00000007 > PC = 0x00401a04 NPC = 0x00401a08 > Stopping execution > > Now, the last obp_nextnode looks suspicious. It looks like the boot > process is iterating over the devices in / without descending, but I > don't see the node 0xffd50758. The last two known ones are /iommu > (0xffd4cbdc) and /obio (0xffd4d394) Interesting. Perhaps it could be being added by something earlier in the bootcode? Can you put together a quick patch for obp_child() and obp_nextnode() so that if CONFIG_DEBUG_OBP is enabled, they also output the package name in the debug string as well as the phandle? Take a look at how obp_proplen uses get-package-property in order to get hold of the "name" property from the package. (Or in fact, for an even quicker hack, the (void) POP() in obp_proplen() is dropping a pointer to a string itself. So if you display that instead then for your output above you should see the package name displayed) ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Lennart Sorensen 28 Mar '13

28 Mar '13

On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote: > That would explain it, but are you sure that was already so in the > SunOS 4.x times? > > $ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 > 15+0 records in > 15+0 records out > 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s > $ file sunos4.bb > sunos4.bb: sparc executable not stripped > $ sparc64-linux-gnu-objdump -x sunos4.bb > > sunos4.bb: file format a.out-sunos-big > sunos4.bb > architecture: sparc, flags 0x0000003e: > EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS > start address 0x00440000 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 00001a58 00000000 00000000 00000020 2**3 > CONTENTS, ALLOC, LOAD, CODE > 1 .data 00000310 00001a58 00001a58 00001a78 2**3 > CONTENTS, ALLOC, LOAD, DATA > 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 > ALLOC > sparc64-linux-gnu-objdump: sunos4.bb: File truncated The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it. I am not sure if all sun machines used openboot with forth. Anyone know? -- Len Sorensen

4 10

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Lennart Sorensen 27 Mar '13

27 Mar '13

On Wed, Mar 27, 2013 at 06:04:07PM +0100, Artyom Tarasenko wrote: > On Wed, Mar 27, 2013 at 5:44 PM, Lennart Sorensen > <lsorense(a)csclub.uwaterloo.ca> wrote: > > On Tue, Mar 26, 2013 at 04:07:15PM -0400, wrote: > >> On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote: > >> > That would explain it, but are you sure that was already so in the > >> > SunOS 4.x times? > >> > > >> > $ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 > >> > 15+0 records in > >> > 15+0 records out > >> > 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s > >> > $ file sunos4.bb > >> > sunos4.bb: sparc executable not stripped > >> > $ sparc64-linux-gnu-objdump -x sunos4.bb > >> > > >> > sunos4.bb: file format a.out-sunos-big > >> > sunos4.bb > >> > architecture: sparc, flags 0x0000003e: > >> > EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS > >> > start address 0x00440000 > >> > > >> > Sections: > >> > Idx Name Size VMA LMA File off Algn > >> > 0 .text 00001a58 00000000 00000000 00000020 2**3 > >> > CONTENTS, ALLOC, LOAD, CODE > >> > 1 .data 00000310 00001a58 00001a58 00001a78 2**3 > >> > CONTENTS, ALLOC, LOAD, DATA > >> > 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 > >> > ALLOC > >> > sparc64-linux-gnu-objdump: sunos4.bb: File truncated > >> > >> The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ > >> is a 110336 byte a.out binary by the looks of it. > >> > >> I am not sure if all sun machines used openboot with forth. Anyone know? > > > > Well I found a page that said the sun4/110 does not use forth (and > > apparently this made the firmware interface vastly faster to work with > > than the ones written in forth). So at least some early sparc boxes > > had a sun3 style firmware. Probably meant the boot code would be different > > too on those. > > > > My guess would be that the sun4/1xx and sun4/2xx were not openboot, > > while the sparcstation and sparcserver models probable all are. > > So probably sun4c and sun4m were the first with openboot then. Sure is > > hard to find good details on these old things. > > It doesn't look like FCode: > > $ hexdump -C sunos4.bb |head > 00000000 01 03 01 07 00 00 1a 58 00 00 03 10 00 00 c5 88 |.......X........| > 00000010 00 00 06 cc 00 44 00 00 00 00 00 00 00 00 00 00 |.....D..........| > 00000020 30 80 00 43 00 1b c0 10 00 1b d0 10 00 1b e0 10 |0..C............| > 00000030 00 1b f0 10 00 1c 00 10 00 1c 10 10 00 1c 20 10 |.............. .| > > There is no marker fd 03, mentioned by Tarl. > > But still it's somehow strange a.out: I tried objdump from Linux/sparc > and from Solaris/Sparc. Both of them can't extract the symbols, in > spite of claiming that "HAS_DEBUG, HAS_SYMS". The one I looked at says: boot.sun4c.sunos.4.1.3: file format a.out-sunos-big boot.sun4c.sunos.4.1.3 architecture: sparc, flags 0x00000002: EXEC_P start address 0x00300000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016960 00000000 00000000 00000020 2**3 CONTENTS, ALLOC, LOAD, CODE 1 .data 00004580 00016960 00016960 00016980 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00018550 0001aee0 0001aee0 00000000 2**3 ALLOC SYMBOL TABLE: no symbols -- Len Sorensen

1 0

Re: [OpenBIOS] selecting a sparc framebuffer from command line
by Artyom Tarasenko 27 Mar '13

27 Mar '13

On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer <breuerr(a)mc.net> wrote: > On 3/26/2013 12:24 PM, Artyom Tarasenko wrote: >> On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer <breuerr(a)mc.net> wrote: >>> On 3/26/2013 6:13 AM, Artyom Tarasenko wrote: >>>> It looks like we will have more framebuffers beside TCX in the near future. >>>> One way to use them would be to make new machines combining a base >>>> machine name with a framebuffer name, like ss5tcx and ss5cg3, but I >>>> guess this would produce too many machines if we have more than 2 >>>> framebuffers. >>>> >>>> Should the "-vga" option be (mis)used for selecting a framebuffer? >>>> They are not called "VGA" in the wild, but maybe the name VGA is >>>> obvious enough for a modern user? After all there is already a "-hda" >>>> option in the SPARCStation-5 emulation command line, although in the >>>> non-emulating world no one calls scsi disk "hda". >>>> >>>> Or should an architecture-specific option, like -framebuffer be added? >>>> >>> >>> I would like to see -device used. With a better sbus framework, adding >>> multiple video devices on sparc32 should be really easy to do. >>> >>> I just looked at how "-device cirrus-vga" works. To get -device to >>> override the default video, we need to add minimal support into vl.c to >>> recognize each video device and handle the default_vga flag. Then >>> sparc32 could limit itself to handling either VGA_NONE or VGA_STD when >>> it adds the default video. >> >> Oh, that's even better! >> And then how would the OpenBIOS find out what framebuffer to use? > > For a single display device, can it do just like OBP? Run all FCode > roms, then find the display device in the device tree. > > For multiple devices, how to select the primary? Possibly just use the > first one found. OBP provides some control over this with > sbus-probe-list. As a parallel question, for a PC with 2 PCI video > cards, which one gets used as the BIOS display? Just trying > "qemu-system-i386 -device cirrus-vga -device cirrus-vga" gives an error > about RAMBlock already registered. > >> Would -device cg3 add the FCode ROM? Or do we need another -device for that? > > The FCode ROM should be integrated with the device, similar to a PCI > device with an expansion rom. The SBUS specification defines a rom to > be at offset 0 of the slot. Probably setup a memory region container > for each sbus slot so that the device addresses are relative to the slot > base and isolated from the system address space. > > For the existing TCX, looks like it also has space for a rom at offset > 0. See ftp://ftp.rodents-montreal.org/pub/mouse/docs/Sun/S24/memory-map > > So as a stepping stone, should we create an FCode ROM for TCX? Sounds reasonable to me, but - afaik the current TCX implementation is written in C, no Forth. So maybe it's easier to keep the current implementation in OpenBIOS and just add some kind of auto-detection. - I'm not a graphic guy. :) I run qemu -nographic whenever possible. So I'd wait till someone from the graphic side comments on it. Blue? Mark? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 26 Mar '13

26 Mar '13

[ oops. Re-sending to entire alias. ] On 2013-Mar-26 15:28 , Artyom Tarasenko wrote: >> >It shouldn't be a.out. The bootloader (on blocks 1-15) of a Solaris disk is >> >an fcode file (compiled forth). >> > > That would explain it, but are you sure that was already so in the > SunOS 4.x times? Ah. Sorry, missed the SunOS 4.x comment. That was before my time (I started at Sun in 1994, when we had just transitioned to Solaris 2), so I wouldn't know for sure. If the first two bytes of the bootloader are "fd 03", it's FCode (That's the "fcode-version3"). Otherwise it may be a.out

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 26 Mar '13

26 Mar '13

On 2013-Mar-26 04:33 , Artyom Tarasenko wrote: > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > Unhandled Exception 0x00000007 > PC = 0x00401a04 NPC = 0x00401a08 > Stopping execution > > > Is the OpenBIOS guess correct and SunOS 4.x actually does have an a.out loader? It shouldn't be a.out. The bootloader (on blocks 1-15) of a Solaris disk is an fcode file (compiled forth).

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 26 Mar '13

26 Mar '13

On 26/03/13 08:33, Artyom Tarasenko wrote: > Hi Mark, > > [adding the OpenBIOS mailing list, hoping to get some more feedback] > > by the way, currently Jean Michel has to use the proprietary OBP. > There seems to be a problem with loading the SunOS 4.x under OpenBIOS: > > $ sparc-softmmu/qemu-system-sparc -L pc-bios -nographic -hda disk-solaris-1.1.2 > > Configuration device id QEMU version 1 machine id 32 > CPUs: 1 x FMI,MB86904 > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Aug 19 2012 13:36 > Type 'help' for detailed information > Trying disk... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > Unhandled Exception 0x00000007 > PC = 0x00401a04 NPC = 0x00401a08 > Stopping execution > > > Is the OpenBIOS guess correct and SunOS 4.x actually does have an a.out loader? Yes, that looks good to me. From memory the Solaris 8 bootloader is an a.out bootloader based at 0x4000, and the kernel loads at 0x400000 so you're definitely getting into the kernel image. The quick and easy way to get a rough idea as to where the failure lies is to copy the kernel ELF image from your Solaris disk image and run objdump on it to find out the name of the function where the exception occurs based upon the exception address. If you're already in the kernel panic() function, then use a sparc-linux-gdb attached to QEMU with a breakpoint to get a stack backtrace at the exception point, which again should give you an idea of where the issue is based upon the function names. HTH, Mark.

2 1

Booting SunOS from OpenBIOS
by Artyom Tarasenko 26 Mar '13

26 Mar '13

Hi Mark, [adding the OpenBIOS mailing list, hoping to get some more feedback] by the way, currently Jean Michel has to use the proprietary OBP. There seems to be a problem with loading the SunOS 4.x under OpenBIOS: $ sparc-softmmu/qemu-system-sparc -L pc-bios -nographic -hda disk-solaris-1.1.2 Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Aug 19 2012 13:36 Type 'help' for detailed information Trying disk... Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@0,0 Jumping to entry point 00004000 for type 00000005... switching to new context: Unhandled Exception 0x00000007 PC = 0x00401a04 NPC = 0x00401a08 Stopping execution Is the OpenBIOS guess correct and SunOS 4.x actually does have an a.out loader? Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[patch] Add Mac OS X building directions to readme file
by Programmingkid 22 Mar '13

22 Mar '13

This patch gives the user a link in the README file, to directions on how to build on Mac OS X. The current directions in the README file are not enough. signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Index: README =================================================================== --- README (revision 1102) +++ README (working copy) @@ -35,6 +35,10 @@ make run - run unix example. + +*Please refer to these directions when building on Mac OS X: +http://www.openfirmware.info/How_to_build_OpenBIOS_on_Mac_OS_X + How OpenBIOS works ------------------

1 0

Re: [OpenBIOS] [PATCH 1/2] loader: implement new loader type for CHRP/Apple partition bootcode (%BOOT)
by Programmingkid 22 Mar '13

22 Mar '13

On Mar 22, 2013, at 2:05 PM, Mark Cave-Ayland wrote: > On 22/03/13 17:54, Programmingkid wrote: > >> I did a "svn revert -R ." to make it completely like the online repo. Then I copied and paste your patch from gmail to a text file. Then I applied it using the patch command like this: "patch -p2< patch.txt". > > Maybe your mailer is mangling the raw patchset? Does the attached work? > > > ATB, > > Mark. > <0001-loader-implement-new-loader-type-for-CHRP-Apple-part.patch><0002-PPC-Add-the-old-world-bootcode-device-dev-BOOT-to-th.patch> Thanks for the files. They successfully patched my repo. I was able to boot from my quik enabled debian hard drive image file and from a Debian and Apple cd. The only issue I saw was with this message being printed in the serial console: >> Not a bootable ELF image. Other than that the patches look good.

1 0

[PATCH V2 1/5] allow powerpc-unknown-linux-gnu- toolchain prefix
by Amadeusz Sławiński 22 Mar '13

22 Mar '13

crossdev on gentoo builds crosscompiler with powerpc-unknown-linux-gnu- prefix Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> --- config/scripts/switch-arch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch index a9c911b..28b3b45 100755 --- a/config/scripts/switch-arch +++ b/config/scripts/switch-arch @@ -97,7 +97,7 @@ archname() select_prefix() { - for TARGET in ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- do if type ${TARGET}gcc > /dev/null 2>&1 then -- 1.8.1.5

1 4

[PATCH] ppc: Fix is_apple() for PReP
by Andreas Färber 22 Mar '13

22 Mar '13

It was returning true for ARCH_PREP although not an Apple device. Limit it to Old World and New World Macs. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> --- arch/ppc/qemu/init.c | 2 +- 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index a8fc320..8efbeeb 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -76,7 +76,7 @@ enum { int is_apple(void) { - return 1; + return is_oldworld() || is_newworld(); } int is_oldworld(void) -- 1.7.10.4

2 1

[RFC PATCH 0/2] implement device nodes needed by xnu kernel
by Amadeusz Sławiński 22 Mar '13

22 Mar '13

Following patches implement /uni-n and /pci/mac-io/via-cuda/power-mgt With them xnu kernel no longer panics when recognizing machine type. Amadeusz

3 6

[PATCH 1/2] loader: implement new loader type for CHRP/Apple partition bootcode (%BOOT)
by Mark Cave-Ayland 22 Mar '13

22 Mar '13

One of the primary reasons that issues with the quik bootloader were not detected earlier was because arch/ppc/qemu/main.c has a separate code path for forcing an old-world boot when -boot c is passed to QEMU. This commit implements the bootcode loader as a core OpenBIOS loader which enables old-world payloads such as quik to be executed using: load hd:,%BOOT go Note that we also fix a bug in mac-parts.c to ensure that we don't try and interpose a filesystem package when %BOOT is passed as a filename. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Graf <agraf(a)suse.de> CC: Andreas Färber <afaerber(a)suse.de> --- openbios-devel/config/examples/ppc_config.xml | 1 + openbios-devel/forth/debugging/client.fs | 4 ++ openbios-devel/include/libopenbios/bootcode_load.h | 22 ++++++ openbios-devel/libopenbios/bootcode_load.c | 71 ++++++++++++++++++++ openbios-devel/libopenbios/build.xml | 1 + openbios-devel/libopenbios/load.c | 13 ++++ openbios-devel/packages/mac-parts.c | 16 ++--- 7 files changed, 119 insertions(+), 9 deletions(-) create mode 100644 openbios-devel/include/libopenbios/bootcode_load.h create mode 100644 openbios-devel/libopenbios/bootcode_load.c diff --git a/openbios-devel/config/examples/ppc_config.xml b/openbios-devel/config/examples/ppc_config.xml index ccb616d..5bb789f 100644 --- a/openbios-devel/config/examples/ppc_config.xml +++ b/openbios-devel/config/examples/ppc_config.xml @@ -26,6 +26,7 @@ <option name="CONFIG_VGA_DEPTH" type="integer" value="8"/> <option name="CONFIG_LOADER_AOUT" type="boolean" value="false"/> <option name="CONFIG_LOADER_BOOTINFO" type="boolean" value="true"/> + <option name="CONFIG_LOADER_BOOTCODE" type="boolean" value="true"/> <option name="CONFIG_LOADER_ELF" type="boolean" value="true"/> <option name="CONFIG_LOADER_FCODE" type="boolean" value="false"/> <option name="CONFIG_LOADER_FORTH" type="boolean" value="false"/> diff --git a/openbios-devel/forth/debugging/client.fs b/openbios-devel/forth/debugging/client.fs index 24b1ec7..9da9b33 100644 --- a/openbios-devel/forth/debugging/client.fs +++ b/openbios-devel/forth/debugging/client.fs @@ -27,6 +27,9 @@ create saved-program-state saved-program-state.size allot variable state-valid 0 state-valid ! +variable want-bootcode +0 want-bootcode ! + variable file-size : !load-size file-size ! ; @@ -44,6 +47,7 @@ variable file-size 5 constant aout 10 constant fcode 11 constant forth +12 constant bootcode : init-program ( -- ) diff --git a/openbios-devel/include/libopenbios/bootcode_load.h b/openbios-devel/include/libopenbios/bootcode_load.h new file mode 100644 index 0000000..147783a --- /dev/null +++ b/openbios-devel/include/libopenbios/bootcode_load.h @@ -0,0 +1,22 @@ +/* + * Creation Date: <2010/03/22 18:00:00 mcayland> + * Time-stamp: <2010/03/22 18:00:00 mcayland> + * + * <bootcode_load.h> + * + * Raw bootcode (%BOOT) loader + * + * Copyright (C) 2013 Mark Cave-Ayland (mark.cave-ayland(a)ilande.co.uk) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation + * + */ + +#ifndef _H_BOOTCODELOAD +#define _H_BOOTCODELOAD + +extern int bootcode_load(ihandle_t dev); + +#endif /* _H__H_BOOTCODELOAD */ diff --git a/openbios-devel/libopenbios/bootcode_load.c b/openbios-devel/libopenbios/bootcode_load.c new file mode 100644 index 0000000..3644997 --- /dev/null +++ b/openbios-devel/libopenbios/bootcode_load.c @@ -0,0 +1,71 @@ +/* + * Raw bootcode loader (CHRP/Apple %BOOT) + * Written by Mark Cave-Ayland 2013 + */ + +#include "config.h" +#include "kernel/kernel.h" +#include "libopenbios/bindings.h" +#include "libopenbios/bootcode_load.h" +#include "libc/diskio.h" +#include "drivers/drivers.h" +#define printf printk +#define debug printk + +#define OLDWORLD_BOOTCODE_BASEADDR (0x3f4000) + +int +bootcode_load(ihandle_t dev) +{ + int retval = -1, count = 0, fd; + unsigned long bootcode, loadbase, offset; + + /* Mark the saved-program-state as invalid */ + feval("0 state-valid !"); + + fd = open_ih(dev); + if (fd == -1) { + goto out; + } + + /* Default to loading at load-base */ + fword("load-base"); + loadbase = POP(); + +#ifdef CONFIG_PPC + /* However Old World Macs need to load to a different address */ + if (is_oldworld()) { + loadbase = OLDWORLD_BOOTCODE_BASEADDR; + } +#endif + + bootcode = loadbase; + offset = 0; + + while(1) { + if (seek_io(fd, offset) == -1) + break; + count = read_io(fd, (void *)bootcode, 512); + offset += count; + bootcode += count; + } + + /* If we didn't read anything then exit */ + if (!count) { + goto out; + } + + /* Initialise saved-program-state */ + PUSH(loadbase); + feval("saved-program-state >sps.entry !"); + PUSH(offset); + feval("saved-program-state >sps.file-size !"); + feval("bootcode saved-program-state >sps.file-type !"); + + feval("-1 state-valid !"); + +out: + close_io(fd); + return retval; +} + diff --git a/openbios-devel/libopenbios/build.xml b/openbios-devel/libopenbios/build.xml index 04e3800..8c1fe3f 100644 --- a/openbios-devel/libopenbios/build.xml +++ b/openbios-devel/libopenbios/build.xml @@ -3,6 +3,7 @@ <library name="openbios" type="static" target="target"> <object source="aout_load.c" condition="LOADER_AOUT"/> <object source="bindings.c"/> + <object source="bootcode_load.c" condition="LOADER_BOOTCODE"/> <object source="bootinfo_load.c" condition="LOADER_BOOTINFO"/> <object source="client.c"/> <object source="console_common.c"/> diff --git a/openbios-devel/libopenbios/load.c b/openbios-devel/libopenbios/load.c index 2a2a7f9..1d50a82 100644 --- a/openbios-devel/libopenbios/load.c +++ b/openbios-devel/libopenbios/load.c @@ -36,6 +36,10 @@ #include "libopenbios/forth_load.h" #endif +#ifdef CONFIG_LOADER_BOOTCODE +#include "libopenbios/bootcode_load.h" +#endif + struct sys_info sys_info; void *elf_boot_notes = NULL; @@ -92,4 +96,13 @@ void load(ihandle_t dev) } #endif +#ifdef CONFIG_LOADER_BOOTCODE + /* Check for a "raw" %BOOT bootcode payload */ + feval("want-bootcode @"); + valid = POP(); + if (valid) { + bootcode_load(dev); + } +#endif + } diff --git a/openbios-devel/packages/mac-parts.c b/openbios-devel/packages/mac-parts.c index 85d53f8..c29b554 100644 --- a/openbios-devel/packages/mac-parts.c +++ b/openbios-devel/packages/mac-parts.c @@ -89,8 +89,12 @@ macparts_open( macparts_info_t *di ) parnum = atol(parstr); /* Detect if we are looking for the bootcode */ - if (strcmp(argstr, "%BOOT") == 0) + if (strcmp(argstr, "%BOOT") == 0) { want_bootcode = 1; + feval("1 want-bootcode !"); + } else { + feval("0 want-bootcode !"); + } } DPRINTF("parstr: %s argstr: %s parnum: %d\n", parstr, argstr, parnum); @@ -285,16 +289,10 @@ macparts_open( macparts_info_t *di ) set_property(chosen_ph, "bootpath", bootpath, strlen(bootpath) + 1); } - - /* If the filename was %BOOT then it's not a real filename, so clear argstr before - attempting interpose */ - if (want_bootcode) { - argstr = strdup(""); - } - + /* If we have been asked to open a particular file, interpose the filesystem package with the passed filename as an argument */ - if (strlen(argstr)) { + if (!want_bootcode && strlen(argstr)) { push_str( argstr ); PUSH_ph( ph ); fword("interpose"); -- 1.7.10.4

1 1

[commit] r1103 - in trunk/openbios-devel: forth/debugging packages
by repository service 22 Mar '13

22 Mar '13

Author: mcayland Date: Fri Mar 22 15:16:46 2013 New Revision: 1103 URL: http://tracker.coreboot.org/trac/openbios/changeset/1103 Log: mac-parts.c: Fix auto-partition selection for the dir word. Commit r1100 fixed the quik bootloader but broke automatic partition selection for the dir word. Differentiate between the package having no arguments (argstr == NULL) and the package having empty arguments (argstr == ""), and alter the dir word to use the latter version to invoke the automatic partition selection code when required. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/forth/debugging/client.fs trunk/openbios-devel/packages/mac-parts.c Modified: trunk/openbios-devel/forth/debugging/client.fs ============================================================================== --- trunk/openbios-devel/forth/debugging/client.fs Sat Mar 9 00:37:44 2013 (r1102) +++ trunk/openbios-devel/forth/debugging/client.fs Fri Mar 22 15:16:46 2013 (r1103) @@ -126,7 +126,7 @@ : dir ( "{paths}<cr>" -- ) linefeed parse - ascii , left-split + ascii , split-after 2dup open-dev dup 0= if drop cr ." Unable to locate device " type Modified: trunk/openbios-devel/packages/mac-parts.c ============================================================================== --- trunk/openbios-devel/packages/mac-parts.c Sat Mar 9 00:37:44 2013 (r1102) +++ trunk/openbios-devel/packages/mac-parts.c Fri Mar 22 15:16:46 2013 (r1103) @@ -79,6 +79,10 @@ } else { argstr = str; } + + /* Make sure argstr is not null */ + if (argstr == NULL) + argstr = strdup(""); /* Convert the id to a partition number */ if (parstr && strlen(parstr)) @@ -89,10 +93,6 @@ want_bootcode = 1; } - /* Make sure argstr is not null */ - if (argstr == NULL) - argstr = strdup(""); - DPRINTF("parstr: %s argstr: %s parnum: %d\n", parstr, argstr, parnum); DPRINTF("want_bootcode %d\n", want_bootcode); @@ -126,7 +126,7 @@ * Implement partition selection as per the PowerPC Microprocessor CHRP bindings */ - if (str == NULL || parnum == 0) { + if (argstr == NULL || parnum == 0) { /* According to the spec, partition 0 as well as no arguments means the whole disk */ offs = (long long)0; size = (long long)__be32_to_cpu(dmap.sbBlkCount) * bs;

1 0

[PATCH] mac-parts.c: Fix auto-partition selection for the dir word.
by Mark Cave-Ayland 16 Mar '13

16 Mar '13

Commit r1100 fixed the quik bootloader but broke automatic partition selection for the dir word. Differentiate between the package having no arguments (argstr == NULL) and the package having empty arguments (argstr == ""), and alter the dir word to use the latter version to invoke the automatic partition selection code when required. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Graf <agraf(a)suse.de> --- openbios-devel/forth/debugging/client.fs | 2 +- openbios-devel/packages/mac-parts.c | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/openbios-devel/forth/debugging/client.fs b/openbios-devel/forth/debugging/client.fs index d454d22..24b1ec7 100644 --- a/openbios-devel/forth/debugging/client.fs +++ b/openbios-devel/forth/debugging/client.fs @@ -126,7 +126,7 @@ variable file-size : dir ( "{paths}<cr>" -- ) linefeed parse - ascii , left-split + ascii , split-after 2dup open-dev dup 0= if drop cr ." Unable to locate device " type diff --git a/openbios-devel/packages/mac-parts.c b/openbios-devel/packages/mac-parts.c index 12c94e5..85d53f8 100644 --- a/openbios-devel/packages/mac-parts.c +++ b/openbios-devel/packages/mac-parts.c @@ -79,6 +79,10 @@ macparts_open( macparts_info_t *di ) } else { argstr = str; } + + /* Make sure argstr is not null */ + if (argstr == NULL) + argstr = strdup(""); /* Convert the id to a partition number */ if (parstr && strlen(parstr)) @@ -89,10 +93,6 @@ macparts_open( macparts_info_t *di ) want_bootcode = 1; } - /* Make sure argstr is not null */ - if (argstr == NULL) - argstr = strdup(""); - DPRINTF("parstr: %s argstr: %s parnum: %d\n", parstr, argstr, parnum); DPRINTF("want_bootcode %d\n", want_bootcode); @@ -126,7 +126,7 @@ macparts_open( macparts_info_t *di ) * Implement partition selection as per the PowerPC Microprocessor CHRP bindings */ - if (str == NULL || parnum == 0) { + if (argstr == NULL || parnum == 0) { /* According to the spec, partition 0 as well as no arguments means the whole disk */ offs = (long long)0; size = (long long)__be32_to_cpu(dmap.sbBlkCount) * bs; -- 1.7.10.4

2 1

[PATCH 00/16] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 15 Mar '13

15 Mar '13

As mentioned in my previous email on-list, OpenBIOS currently contains two consoles - a C based console and a Forth based console. The Forth based console is currently broken, but is more feature complete than the C console, whilst also being more portable across different architectures. This patchset performs the following functions: - Fix various bugs in the Forth console - Optimise performance using low-level C graphics routines - Add simple IEEE1275-like initialisers for TCX and VGA graphics - Switch TCX and VGA drivers over to use the new console using the standard is-install word Once this patchset is committed, a further patchset will follow to remove all of the duplicate C console code, remove packages/video.c and unify the console input/routines into libopenbios. Mark Cave-Ayland (16): display.fs: Fix up default-font word. display.fs: Fix fb8-delete-lines within the inbuilt Forth terminal emulator. terminal.fs: Fix linefeeds on the bottom line of the Forth console. terminal.fs: Fix backspace sequence in Forth terminal. video: Create new video_common.c file for shared video primitive routines. video_common.c: Move primitive graphic operations into libopenbios/video_common.c. pci: Modify PCI display devices so that open and close words are not created automatically during initialisation. video: Create tcx.fs and vga.fs to simulate Fcode video initialisation code. display.fs: pass the colour depth in bytes to the Forth terminal routines. video_common.c: create low-level video_mask_blit() function. video_common.c: create low-level video_invert_rect() function. display.fs: Fix fb8 routines to work with bit depths > 8. video_common.c: create low-level video_fill_rect() function. display.fs: optimise scrolling by copying/deleting multiple scanlines at once. display.fs: Add vertical font-spacing as per the existing C console implementation. video: switch VGA and TCX drivers over to Forth console using is-install. openbios-devel/arch/sparc32/console.c | 12 - openbios-devel/arch/sparc32/openbios.c | 2 +- openbios-devel/drivers/build.xml | 2 + openbios-devel/drivers/pci.c | 14 +- openbios-devel/drivers/pci.h | 1 + openbios-devel/drivers/sbus.c | 2 + openbios-devel/drivers/tcx.fs | 13 + openbios-devel/drivers/vga.fs | 13 + openbios-devel/drivers/vga_vbe.c | 2 +- openbios-devel/forth/device/display.fs | 172 +++++------ openbios-devel/forth/device/font.fs | 4 + openbios-devel/forth/device/terminal.fs | 10 +- openbios-devel/include/libopenbios/video.h | 24 ++ openbios-devel/include/packages/video.h | 6 +- openbios-devel/libopenbios/build.xml | 1 + openbios-devel/libopenbios/console_common.c | 1 + openbios-devel/libopenbios/video_common.c | 444 +++++++++++++++++++++++++++ openbios-devel/packages/video.c | 279 +---------------- 18 files changed, 607 insertions(+), 395 deletions(-) create mode 100644 openbios-devel/drivers/tcx.fs create mode 100644 openbios-devel/drivers/vga.fs create mode 100644 openbios-devel/include/libopenbios/video.h create mode 100644 openbios-devel/libopenbios/video_common.c -- 1.7.10.4

4 20

Re: [OpenBIOS] [PATCH 00/16] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 11 Mar '13

11 Mar '13

On 10/03/13 19:31, Blue Swirl wrote: >> Based on a quick Debian 3.1 CDROM boot test, it looks like scrolling >> and clear screen does not work at all. Text is also offset by one line >> down and one column right. Okay - is this on SPARC? I have a feeling the offset by one is simply because apparently the OF line# and column# variables are zero based while the ANSI terminal position is one based. > NetBSD 4.0 also suffers from lack of scrolling and clear screen, but > characters are positioned correctly. SPARC again? If so, can you point me towards the ISO and I'll try it here? > On the positive side, reverse text now works and I guess the screen > flashes show BEL handling. :) ATB, Mark.

2 1

Re: [OpenBIOS] [PATCH 00/16] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 11 Mar '13

11 Mar '13

On 10/03/13 20:52, Blue Swirl wrote: > I used the following to fix the warning, please squash into patch #5: > > diff --git a/include/libopenbios/video.h b/include/libopenbios/video.h > index 13bf143..1840981 100644 > --- a/include/libopenbios/video.h > +++ b/include/libopenbios/video.h > @@ -17,7 +17,7 @@ typedef struct osi_fb_info { > int rb, w, h, depth; > } osi_fb_info_t; > > -struct { > +extern struct video_info { > int has_video; > osi_fb_info_t fb; > unsigned long *pal; /* 256 elements */ > diff --git a/libopenbios/video_common.c b/libopenbios/video_common.c > index 11aeec7..621f032 100644 > --- a/libopenbios/video_common.c > +++ b/libopenbios/video_common.c > @@ -23,6 +23,7 @@ > #include "packages/video.h" > #include "drivers/vga.h" > > +struct video_info video; > > unsigned long > get_color( int col_ind ) Thanks - I will do that. > It looks like Forth version is a bit too buggy, for example > 1b emit ." [H" > should position cursor to top left corner of the screen (like HEAD), > but with the patch set it does nothing except leaves a stray '0' on > the stack! Thanks for the hint - I think that it should be fairly easy to fix (I temporarily force debugger output to the serial port when working on the video routines). I'm quite tempted to make this a permanent behaviour when CONFIG_DEBUG_VIDEO_CONSOLE is enabled, and change the default to "false" so that this becomes a developer option. ATB, Mark.

1 0

Re: [OpenBIOS] [PATCH 00/16] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 11 Mar '13

11 Mar '13

On 10/03/13 18:16, Blue Swirl wrote: > I'm getting these warnings during build, perhaps something is not correct: > LINK openbios-builtin.elf > libopenbios.a(console_common.o): warning: multiple common of `video' > libsparc32.a(openbios.o): warning: previous common is here > libopenbios.a(video_common.o): warning: multiple common of `video' > libsparc32.a(openbios.o): warning: previous common is here > libpackages.a(video.o): warning: multiple common of `video' > libsparc32.a(openbios.o): warning: previous common is here > GEN openbios-builtin.elf.syms Thanks for testing :) Okay I see you patch for that - I'll update my patchset accordingly. > Based on a quick Debian 3.1 CDROM boot test, it looks like scrolling > and clear screen does not work at all. Text is also offset by one line > down and one column right. Right I'll take a look at that. Am I right in thinking that the codes we need to implement are those in Annex B of the IEEE1275 specification? So that would be CSI n S, CSI n T and CSI n J? > Some usual messages (CPUs, UUID) are not going to screen but that's probably OK. Yeah. I can fix those, but it requires changing the video struct which I can do for a later patchset. ATB, Mark.

1 0

Re: [OpenBIOS] [PATCH 00/16] Switch to standards-compliant Forth console from C console
by Blue Swirl 10 Mar '13

10 Mar '13

On Sun, Mar 10, 2013 at 7:31 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sun, Mar 10, 2013 at 6:16 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Sun, Mar 10, 2013 at 4:50 PM, Mark Cave-Ayland >> <mark.cave-ayland(a)ilande.co.uk> wrote: >>> As mentioned in my previous email on-list, OpenBIOS currently contains two >>> consoles - a C based console and a Forth based console. The Forth based console >>> is currently broken, but is more feature complete than the C console, whilst also >>> being more portable across different architectures. >>> >>> This patchset performs the following functions: >>> >>> - Fix various bugs in the Forth console >>> - Optimise performance using low-level C graphics routines >>> - Add simple IEEE1275-like initialisers for TCX and VGA graphics >>> - Switch TCX and VGA drivers over to use the new console using the standard >>> is-install word >>> >>> Once this patchset is committed, a further patchset will follow to remove all of >>> the duplicate C console code, remove packages/video.c and unify the console >>> input/routines into libopenbios. >> >> I'm getting these warnings during build, perhaps something is not correct: >> LINK openbios-builtin.elf >> libopenbios.a(console_common.o): warning: multiple common of `video' >> libsparc32.a(openbios.o): warning: previous common is here >> libopenbios.a(video_common.o): warning: multiple common of `video' >> libsparc32.a(openbios.o): warning: previous common is here >> libpackages.a(video.o): warning: multiple common of `video' >> libsparc32.a(openbios.o): warning: previous common is here >> GEN openbios-builtin.elf.syms I used the following to fix the warning, please squash into patch #5: diff --git a/include/libopenbios/video.h b/include/libopenbios/video.h index 13bf143..1840981 100644 --- a/include/libopenbios/video.h +++ b/include/libopenbios/video.h @@ -17,7 +17,7 @@ typedef struct osi_fb_info { int rb, w, h, depth; } osi_fb_info_t; -struct { +extern struct video_info { int has_video; osi_fb_info_t fb; unsigned long *pal; /* 256 elements */ diff --git a/libopenbios/video_common.c b/libopenbios/video_common.c index 11aeec7..621f032 100644 --- a/libopenbios/video_common.c +++ b/libopenbios/video_common.c @@ -23,6 +23,7 @@ #include "packages/video.h" #include "drivers/vga.h" +struct video_info video; unsigned long get_color( int col_ind ) >> >> Based on a quick Debian 3.1 CDROM boot test, it looks like scrolling >> and clear screen does not work at all. Text is also offset by one line >> down and one column right. > > NetBSD 4.0 also suffers from lack of scrolling and clear screen, but > characters are positioned correctly. > > On the positive side, reverse text now works and I guess the screen > flashes show BEL handling. It looks like Forth version is a bit too buggy, for example 1b emit ." [H" should position cursor to top left corner of the screen (like HEAD), but with the patch set it does nothing except leaves a stray '0' on the stack! > >> >> Some usual messages (CPUs, UUID) are not going to screen but that's probably OK. >> >>> >>> >>> Mark Cave-Ayland (16): >>> display.fs: Fix up default-font word. >>> display.fs: Fix fb8-delete-lines within the inbuilt Forth terminal >>> emulator. >>> terminal.fs: Fix linefeeds on the bottom line of the Forth console. >>> terminal.fs: Fix backspace sequence in Forth terminal. >>> video: Create new video_common.c file for shared video primitive >>> routines. >>> video_common.c: Move primitive graphic operations into >>> libopenbios/video_common.c. >>> pci: Modify PCI display devices so that open and close words are not >>> created automatically during initialisation. >>> video: Create tcx.fs and vga.fs to simulate Fcode video >>> initialisation code. >>> display.fs: pass the colour depth in bytes to the Forth terminal >>> routines. >>> video_common.c: create low-level video_mask_blit() function. >>> video_common.c: create low-level video_invert_rect() function. >>> display.fs: Fix fb8 routines to work with bit depths > 8. >>> video_common.c: create low-level video_fill_rect() function. >>> display.fs: optimise scrolling by copying/deleting multiple scanlines >>> at once. >>> display.fs: Add vertical font-spacing as per the existing C console >>> implementation. >>> video: switch VGA and TCX drivers over to Forth console using >>> is-install. >>> >>> openbios-devel/arch/sparc32/console.c | 12 - >>> openbios-devel/arch/sparc32/openbios.c | 2 +- >>> openbios-devel/drivers/build.xml | 2 + >>> openbios-devel/drivers/pci.c | 14 +- >>> openbios-devel/drivers/pci.h | 1 + >>> openbios-devel/drivers/sbus.c | 2 + >>> openbios-devel/drivers/tcx.fs | 13 + >>> openbios-devel/drivers/vga.fs | 13 + >>> openbios-devel/drivers/vga_vbe.c | 2 +- >>> openbios-devel/forth/device/display.fs | 172 +++++------ >>> openbios-devel/forth/device/font.fs | 4 + >>> openbios-devel/forth/device/terminal.fs | 10 +- >>> openbios-devel/include/libopenbios/video.h | 24 ++ >>> openbios-devel/include/packages/video.h | 6 +- >>> openbios-devel/libopenbios/build.xml | 1 + >>> openbios-devel/libopenbios/console_common.c | 1 + >>> openbios-devel/libopenbios/video_common.c | 444 +++++++++++++++++++++++++++ >>> openbios-devel/packages/video.c | 279 +---------------- >>> 18 files changed, 607 insertions(+), 395 deletions(-) >>> create mode 100644 openbios-devel/drivers/tcx.fs >>> create mode 100644 openbios-devel/drivers/vga.fs >>> create mode 100644 openbios-devel/include/libopenbios/video.h >>> create mode 100644 openbios-devel/libopenbios/video_common.c >>> >>> -- >>> 1.7.10.4 >>> >>> >>> -- >>> OpenBIOS http://openbios.org/ >>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>> Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] [PATCH 00/16] Switch to standards-compliant Forth console from C console
by Blue Swirl 10 Mar '13

10 Mar '13

On Sun, Mar 10, 2013 at 6:16 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sun, Mar 10, 2013 at 4:50 PM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> As mentioned in my previous email on-list, OpenBIOS currently contains two >> consoles - a C based console and a Forth based console. The Forth based console >> is currently broken, but is more feature complete than the C console, whilst also >> being more portable across different architectures. >> >> This patchset performs the following functions: >> >> - Fix various bugs in the Forth console >> - Optimise performance using low-level C graphics routines >> - Add simple IEEE1275-like initialisers for TCX and VGA graphics >> - Switch TCX and VGA drivers over to use the new console using the standard >> is-install word >> >> Once this patchset is committed, a further patchset will follow to remove all of >> the duplicate C console code, remove packages/video.c and unify the console >> input/routines into libopenbios. > > I'm getting these warnings during build, perhaps something is not correct: > LINK openbios-builtin.elf > libopenbios.a(console_common.o): warning: multiple common of `video' > libsparc32.a(openbios.o): warning: previous common is here > libopenbios.a(video_common.o): warning: multiple common of `video' > libsparc32.a(openbios.o): warning: previous common is here > libpackages.a(video.o): warning: multiple common of `video' > libsparc32.a(openbios.o): warning: previous common is here > GEN openbios-builtin.elf.syms > > Based on a quick Debian 3.1 CDROM boot test, it looks like scrolling > and clear screen does not work at all. Text is also offset by one line > down and one column right. NetBSD 4.0 also suffers from lack of scrolling and clear screen, but characters are positioned correctly. On the positive side, reverse text now works and I guess the screen flashes show BEL handling. > > Some usual messages (CPUs, UUID) are not going to screen but that's probably OK. > >> >> >> Mark Cave-Ayland (16): >> display.fs: Fix up default-font word. >> display.fs: Fix fb8-delete-lines within the inbuilt Forth terminal >> emulator. >> terminal.fs: Fix linefeeds on the bottom line of the Forth console. >> terminal.fs: Fix backspace sequence in Forth terminal. >> video: Create new video_common.c file for shared video primitive >> routines. >> video_common.c: Move primitive graphic operations into >> libopenbios/video_common.c. >> pci: Modify PCI display devices so that open and close words are not >> created automatically during initialisation. >> video: Create tcx.fs and vga.fs to simulate Fcode video >> initialisation code. >> display.fs: pass the colour depth in bytes to the Forth terminal >> routines. >> video_common.c: create low-level video_mask_blit() function. >> video_common.c: create low-level video_invert_rect() function. >> display.fs: Fix fb8 routines to work with bit depths > 8. >> video_common.c: create low-level video_fill_rect() function. >> display.fs: optimise scrolling by copying/deleting multiple scanlines >> at once. >> display.fs: Add vertical font-spacing as per the existing C console >> implementation. >> video: switch VGA and TCX drivers over to Forth console using >> is-install. >> >> openbios-devel/arch/sparc32/console.c | 12 - >> openbios-devel/arch/sparc32/openbios.c | 2 +- >> openbios-devel/drivers/build.xml | 2 + >> openbios-devel/drivers/pci.c | 14 +- >> openbios-devel/drivers/pci.h | 1 + >> openbios-devel/drivers/sbus.c | 2 + >> openbios-devel/drivers/tcx.fs | 13 + >> openbios-devel/drivers/vga.fs | 13 + >> openbios-devel/drivers/vga_vbe.c | 2 +- >> openbios-devel/forth/device/display.fs | 172 +++++------ >> openbios-devel/forth/device/font.fs | 4 + >> openbios-devel/forth/device/terminal.fs | 10 +- >> openbios-devel/include/libopenbios/video.h | 24 ++ >> openbios-devel/include/packages/video.h | 6 +- >> openbios-devel/libopenbios/build.xml | 1 + >> openbios-devel/libopenbios/console_common.c | 1 + >> openbios-devel/libopenbios/video_common.c | 444 +++++++++++++++++++++++++++ >> openbios-devel/packages/video.c | 279 +---------------- >> 18 files changed, 607 insertions(+), 395 deletions(-) >> create mode 100644 openbios-devel/drivers/tcx.fs >> create mode 100644 openbios-devel/drivers/vga.fs >> create mode 100644 openbios-devel/include/libopenbios/video.h >> create mode 100644 openbios-devel/libopenbios/video_common.c >> >> -- >> 1.7.10.4 >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] RFC: Rework of OpenBIOS terminal/console
by Mark Cave-Ayland 09 Mar '13

09 Mar '13

On 09/03/13 12:57, Blue Swirl wrote: > I did some work on the control sequence handling in 2007 and 2009 > based on what Debian 3.1 and NetBSD 4.0 expect of the OpenBIOS > console. Later versions of Debian and other distros use fbdev console > which is independent of this. > > Based on a quick comparison, both Forth and C versions implement a lot > of control characters. > > Only in Forth version (or real implementation instead of dummy): > BEL, VT, Esc-E, Esc-L, Esc-m, Esc-P, Esc-p, Esc-q, Esc-s > > Esc-K seems to be simpler in Forth than C version, which has three > separate modes. Similarly Esc-J handling does not seem to match. > > Only in C console: > CAN, SUB > > But I have no objection, I can retest Debian 3.1 and NetBSD 4.0 > afterwards and try to fix or reimplement if something is missing since > the differences seem to be minor. Great! I've done some testing here, and I do have a proof-of-concept patchset which works well. The problem is that in order to maintain bisectability for each feature, the vast majority of commits end up having to back-out certain parts of previous commits in order to maintain a working binary until the switch occurs. My plan is to break out the Forth terminal fixes into a separate patchset and commit them straight away, and then post a separate patch series that does the switch. Once this is in done, it should be possible to further tidy up the console/graphic initialisation by moving the low-level C console code from the various architectures into libopenbios/console_common.c to remove even more redundancy. ATB, Mark.

1 0

RFC: Rework of OpenBIOS terminal/console
by Mark Cave-Ayland 09 Mar '13

09 Mar '13

Hi all, Whilst looking at the possibility of supporting additional graphics cards in OpenBIOS, I noticed that there are actually two terminal consoles built in: a standards-compliant Forth one in forth/device/terminal.fs and a C-based one in libopenbios/console_common.c (which is the default). Some experimentation with the Forth console shows that with some minor fixes it can be made to work, and in fact produces better console output in many cases because the fb8-* and terminal words are implemented correctly. With this in mind, I'd like to propose switching over to the Forth console and removing the C console entirely. Would anyone have any major objections to doing this? ATB, Mark.

2 1

[commit] r1102 - trunk/openbios-devel/arch/ppc/qemu
by repository service 09 Mar '13

09 Mar '13

Author: agraf Date: Sat Mar 9 00:37:44 2013 New Revision: 1102 URL: http://tracker.coreboot.org/trac/openbios/changeset/1102 Log: PPC: Handle trap_error on ppc64 When running on ppc64, we have to disable MSR_SF before we issue a lis instruction. All exceptions were doing this, except for the error trap. This isn't crucial, because when we got there we're already screwed up, but let's not confuse users by jumping to invalid addresses. Signed-off-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Sun Mar 3 10:02:29 2013 (r1101) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Sat Mar 9 00:37:44 2013 (r1102) @@ -296,6 +296,14 @@ EXCEPTION_EPILOGUE trap_error: + lis r1, 0x8000 /* r1=0x80000000 */ + add. r1,r1,r1 /* r1=r1+r1 (high 32bit !0) */ + beq 1f + + mfmsr r1 /* unset MSR_SF */ + clrldi r1,r1,1 + mtmsrd r1 +1: mflr r3 LOAD_REG_FUNC(r4, unexpected_excep) mtctr r4

1 0

[commit] r1101 - trunk/openbios-devel
by repository service 03 Mar '13

03 Mar '13

Author: blueswirl Date: Sun Mar 3 10:02:29 2013 New Revision: 1101 URL: http://tracker.coreboot.org/trac/openbios/changeset/1101 Log: build: improve subdir rules Use subdirectory build rules from QEMU. They allow a parallel build of all available subdirectory targets. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/Makefile Modified: trunk/openbios-devel/Makefile ============================================================================== --- trunk/openbios-devel/Makefile Thu Feb 28 00:06:10 2013 (r1100) +++ trunk/openbios-devel/Makefile Sun Mar 3 10:02:29 2013 (r1101) @@ -15,18 +15,24 @@ $(MAKE) -C $$dir clean; \ done -build: - @printf "Building..." +build: start-build @for dir in $(ODIRS); do \ $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \ ( echo "error:"; tail -15 $$dir/build.log; exit 1 ) \ done -build-verbose: +SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGETS)) +SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory) + +quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1)) + +build-verbose: start-build $(SUBDIR_RULES) + +subdir-%: + $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C obj-$* V="$(V)" all,) + +start-build: @echo "Building..." - @for dir in $(ODIRS); do \ - $(MAKE) -C $$dir || exit 1; \ - done run: @echo "Running..."

1 0

Re: [OpenBIOS] testing Max OS X boot on latest trunk (revision 1080)
by Amadeusz Sławiński 28 Feb '13

28 Feb '13

On Thu, Feb 28, 2013 at 10:23:02PM +0100, Kristian Valind wrote: > Are you sure you're sending the right log files? > > "Welcome to OpenBIOS v1.0 built on Dec 18 2012 10:41" > > > I'm not sure if I'm stating the already obvious, but with the lastest git > revision of qemu and the latest svn of openbios the Darwin 8.0.1 kernel > loads just fine for me on the g3beige machine. Making use of the emulated > Heathrow (and thus mounting root) is a whole other matter however. > > Kristian Seems like someone checked moderation queue, it's old message, from december. I did resend it http://lists.openbios.org/pipermail/openbios/2012-December/007243.html Amadeusz

1 0

testing Max OS X boot on latest trunk (revision 1080)
by Amadeusz Sławiński 28 Feb '13

28 Feb '13

Here are results of my testing booting OS X on latest trunk Logs in attachment Not patched ones (fails without get-key-map): 10.0.log 10.2.log 10.4.log Patched with gsoc get-key-map patch: 10.0-gkm.log 10.2-gkm-panic.log 10.4-gkm.log Patched with gsoc divide by 0: 10.2-gkm-dvb0.log Logs from patched boot without CIF: all-without-cif.log 10.2 ones show that there is need for some solution regarding division by 0, some notes from my talks with Mark: My g5 machine returns 0 when dividing by 0, no warnings are printed: 0 > 0 0 / ok 1 > . ok 0 > 0 0 > 2 0 / ok 1 > . ok 0 > 0 Question is how to implement it, or maybe just use gsoc patch? Also it seems that Mac OS X seems to provide it's own fill-rectangle and draw-rectangle it prints: FILL-RECTANGLE isn't unique. and also similar message when I apply gsoc draw-rectangle patch so it seems that this one isn't needed Another problem is that it seems to be unable to open/load kernel. On graphic side of things it seems to draw things better than with gsoc patches, graphics are not weirdly resized, but there is not much to see except boot folder graphic (10.0)/white apple(10.2, 10.4). Amadeusz

2 1

[commit] r1100 - trunk/openbios-devel/packages
by repository service 28 Feb '13

28 Feb '13

Author: mcayland Date: Thu Feb 28 00:06:10 2013 New Revision: 1100 URL: http://tracker.coreboot.org/trac/openbios/changeset/1100 Log: mac-parts.c: Fix /packages/mac-parts boot when the package arguments are empty. Commit r1072 removed a couple of NULL pointer checks for package arguments, however if the arguments are empty in Forth then they are converted back to a NULL pointer which causes an exception when dereferenced. Add the checks back in which fixes boot of the debian_lenny_powerpc_small.qcow2 test image with quik once again. Based upon an earlier patch by Alexander Graf <agraf(a)suse.de>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/packages/mac-parts.c Modified: trunk/openbios-devel/packages/mac-parts.c ============================================================================== --- trunk/openbios-devel/packages/mac-parts.c Sat Feb 16 13:08:33 2013 (r1099) +++ trunk/openbios-devel/packages/mac-parts.c Thu Feb 28 00:06:10 2013 (r1100) @@ -68,7 +68,7 @@ [(id)][,][filespec] */ - if ( strlen(str) ) { + if ( str && strlen(str) ) { /* Detect the arguments */ if ((*str >= '0' && *str <= '9') || (*str == ',')) { push_str(str); @@ -126,7 +126,7 @@ * Implement partition selection as per the PowerPC Microprocessor CHRP bindings */ - if (parnum == 0) { + if (str == NULL || parnum == 0) { /* According to the spec, partition 0 as well as no arguments means the whole disk */ offs = (long long)0; size = (long long)__be32_to_cpu(dmap.sbBlkCount) * bs;

1 0

[PATCH] ppc: Don't do relative branches from relocated memory
by Andreas Färber 25 Feb '13

25 Feb '13

On startup, OpenBIOS copies exception vectors to 0x00000000. Therefore jumps cannot be performed relative to the compile-time address to outside the relocated exception vectors. QEMU's g3beige and mac99 did not run into this so far, but prep does. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> --- arch/ppc/qemu/start.S | 4 +++- 1 Datei geändert, 3 Zeilen hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 5c86d74..66987a0 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -302,7 +302,9 @@ trap_error: bctr VECTOR( 0x100, "SRE" ): - b _entry + LOAD_REG_IMMEDIATE(r3, _entry) + mtctr r3 + bctr ILLEGAL_VECTOR( 0x200 ) -- 1.7.10.4

2 1

[PATCH] mac-parts.c: Fix /packages/mac-parts boot when the package arguments are empty.
by Mark Cave-Ayland 25 Feb '13

25 Feb '13

Commit r1072 removed a couple of NULL pointer checks for package arguments, however if the arguments are empty in Forth then they are converted back to a NULL pointer which causes an exception when dereferenced. Add the checks back in which fixes boot of the debian_lenny_powerpc_small.qcow2 test image with quik once again. Based upon an earlier patch by Alexander Graf <agraf(a)suse.de>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> CC: Alexander Garf <agraf(a)suse.de> --- openbios-devel/packages/mac-parts.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openbios-devel/packages/mac-parts.c b/openbios-devel/packages/mac-parts.c index d0cba05..12c94e5 100644 --- a/openbios-devel/packages/mac-parts.c +++ b/openbios-devel/packages/mac-parts.c @@ -68,7 +68,7 @@ macparts_open( macparts_info_t *di ) [(id)][,][filespec] */ - if ( strlen(str) ) { + if ( str && strlen(str) ) { /* Detect the arguments */ if ((*str >= '0' && *str <= '9') || (*str == ',')) { push_str(str); @@ -126,7 +126,7 @@ macparts_open( macparts_info_t *di ) * Implement partition selection as per the PowerPC Microprocessor CHRP bindings */ - if (parnum == 0) { + if (str == NULL || parnum == 0) { /* According to the spec, partition 0 as well as no arguments means the whole disk */ offs = (long long)0; size = (long long)__be32_to_cpu(dmap.sbBlkCount) * bs; -- 1.7.10.4

2 1

Macintosh device tree
by Programmingkid 24 Feb '13

24 Feb '13

I am investigating the device tree of the mac99 model. It looks like it is wrong. The part that I am concerned with is the via-cuda node. Both my iMac and iBook don't even have a via-cuda. They both have a via-pmu@16000 node. I'm hoping someone has an original blue and white PowerMac G3. I would like the full device tree printout from it. The question I am trying to answer is does any newworld Mac have a via-cuda? If they don't, we know that it should be changed to a via-pmu@16000 node.

3 5

[PATCH 1/4] allow powerpc-unknown-linux-gnu- toolchain prefix
by Amadeusz Sławiński 24 Feb '13

24 Feb '13

crossdev on gentoo builds crosscompiler with powerpc-unknown-linux-gnu- prefix Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> --- config/scripts/switch-arch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch index a9c911b..28b3b45 100755 --- a/config/scripts/switch-arch +++ b/config/scripts/switch-arch @@ -97,7 +97,7 @@ archname() select_prefix() { - for TARGET in ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- do if type ${TARGET}gcc > /dev/null 2>&1 then -- 1.8.1.4

3 6

[PATCH] Fix mac label whole partition case
by Alexander Graf 23 Feb '13

23 Feb '13

Commit r1072 removed the check for NULL pointer strings in the mac partition lookup. However, without that check we would end up dereferencing this string pointer later, breaking my Debian Lenny test image. Add the check back in. This fixes Lenny with quik again. Signed-off-by: Alexander Graf <agraf(a)suse.de> --- packages/mac-parts.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/packages/mac-parts.c b/packages/mac-parts.c index d0cba05..330d8a0 100644 --- a/packages/mac-parts.c +++ b/packages/mac-parts.c @@ -126,7 +126,7 @@ macparts_open( macparts_info_t *di ) * Implement partition selection as per the PowerPC Microprocessor CHRP bindings */ - if (parnum == 0) { + if (str == NULL || parnum == 0) { /* According to the spec, partition 0 as well as no arguments means the whole disk */ offs = (long long)0; size = (long long)__be32_to_cpu(dmap.sbBlkCount) * bs; -- 1.6.0.2

3 5

[PATCH] build: improve subdir rules
by Blue Swirl 16 Feb '13

16 Feb '13

Use subdirectory build rules from QEMU. They allow a parallel build of all available subdirectory targets. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- Makefile | 18 ++++++++++++------ 1 files changed, 12 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 3526b75..172f450 100644 --- a/Makefile +++ b/Makefile @@ -15,18 +15,24 @@ clean: $(MAKE) -C $$dir clean; \ done -build: - @printf "Building..." +build: start-build @for dir in $(ODIRS); do \ $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \ ( echo "error:"; tail -15 $$dir/build.log; exit 1 ) \ done -build-verbose: +SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGETS)) +SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory) + +quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1)) + +build-verbose: start-build $(SUBDIR_RULES) + +subdir-%: + $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C obj-$* V="$(V)" all,) + +start-build: @echo "Building..." - @for dir in $(ODIRS); do \ - $(MAKE) -C $$dir || exit 1; \ - done run: @echo "Running..." -- 1.7.2.5

1 0

[commit] r1099 - in trunk/openbios-devel: . config/scripts config/xml
by repository service 16 Feb '13

16 Feb '13

Author: blueswirl Date: Sat Feb 16 13:08:33 2013 New Revision: 1099 URL: http://tracker.coreboot.org/trac/openbios/changeset/1099 Log: build: support disjoint build directory Support building in any directory, not just in-tree build. Use VPATH for non-Forth files. Forth compiler does not support explicit paths, so drop source path prefixes added by XML and rely on directories passed with -I flag. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/.gitignore trunk/openbios-devel/Makefile trunk/openbios-devel/Makefile.target trunk/openbios-devel/config/scripts/switch-arch trunk/openbios-devel/config/xml/dictionary.xsl trunk/openbios-devel/config/xml/object.xsl Modified: trunk/openbios-devel/.gitignore ============================================================================== --- trunk/openbios-devel/.gitignore Sun Feb 3 17:50:11 2013 (r1098) +++ trunk/openbios-devel/.gitignore Sat Feb 16 13:08:33 2013 (r1099) @@ -1,2 +1,3 @@ obj-* .stgit-* +config-host.mak Modified: trunk/openbios-devel/Makefile ============================================================================== --- trunk/openbios-devel/Makefile Sun Feb 3 17:50:11 2013 (r1098) +++ trunk/openbios-devel/Makefile Sat Feb 16 13:08:33 2013 (r1099) @@ -1,5 +1,4 @@ -ODIRS=$(wildcard obj-*) -TARGETS=$(subst obj-,,$(ODIRS)) +include config-host.mak all: requirements info build Modified: trunk/openbios-devel/Makefile.target ============================================================================== --- trunk/openbios-devel/Makefile.target Sun Feb 3 17:50:11 2013 (r1098) +++ trunk/openbios-devel/Makefile.target Sat Feb 16 13:08:33 2013 (r1099) @@ -6,7 +6,6 @@ include config.mak ODIR := . -SRCDIR := .. HOSTCC := gcc HOSTCFLAGS+= -O2 -g -DFCOMPILER -DBOOTSTRAP $(CROSSCFLAGS) @@ -38,6 +37,10 @@ quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1)) +VPATH_SUFFIXES = %.c %.h %.S %.fs +set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath $(PATTERN) $1))) +$(call set-vpath, $(SRCDIR)) + # # pre rules # Modified: trunk/openbios-devel/config/scripts/switch-arch ============================================================================== --- trunk/openbios-devel/config/scripts/switch-arch Sun Feb 3 17:50:11 2013 (r1098) +++ trunk/openbios-devel/config/scripts/switch-arch Sat Feb 16 13:08:33 2013 (r1099) @@ -117,21 +117,18 @@ echo "<option name=\"$option\" type=\"boolean\" value=\"true\" />" } -if ! test -f utils/dist/debian/rules; then - echo "switch-arch must be run from the top-level source directory" >&2 - exit 1 -fi -# This is needed because viewvc messes with the permissions of executables: -chmod 755 utils/dist/debian/rules -chmod 755 config/scripts/switch-arch -chmod 755 config/scripts/reldir +SRCDIR=`dirname "$0"`/../.. +BUILDDIR=`pwd` + +# make source path absolute +SRCDIR=`cd "$SRCDIR"; pwd` if test "x$HOSTARCH" = "x"; then archname fi -VERSION=`head VERSION` +VERSION=`head $SRCDIR/VERSION` echo "Configuring OpenBIOS on $HOSTARCH for $*" @@ -156,8 +153,8 @@ arch_list="" for target in $target_list; do arch=`echo $target | sed s/.*-//g` - if ! test -f config/examples/${arch}_config.xml; then - echo "Cannot find config/examples/${arch}_config.xml" >&2 + if ! test -f $SRCDIR/config/examples/${arch}_config.xml; then + echo "Cannot find $SRCDIR/config/examples/${arch}_config.xml" >&2 exit 1 fi if ! echo $arch_list | grep -q "$arch"; then @@ -269,7 +266,8 @@ cross="yes" fi crosscflags $HOSTARCH $ARCH - OBJDIR=obj-$ARCH + OBJDIR=$BUILDDIR/obj-$ARCH + ODIRS="$ODIRS $OBJDIR" printf "Initializing build tree $OBJDIR..." rm -rf "$OBJDIR" @@ -294,9 +292,9 @@ mkdir -p $OBJDIR/host/include mkdir -p $OBJDIR/host/kernel mkdir -p $OBJDIR/forth - ln -s ../../../include/arch/$BASEARCH $OBJDIR/target/include/asm + ln -s $SRCDIR/include/arch/$BASEARCH $OBJDIR/target/include/asm #compile the host binary with target settings instead - #ln -s ../../../include/arch/$HOSTARCH $OBJDIR/host/include/asm + #ln -s $SRCDIR/include/arch/$HOSTARCH $OBJDIR/host/include/asm if [ "$mol" = "yes" ]; then printf "\nUsing MOL path $MOLPATH...\n" mkdir -p $OBJDIR/target/arch/ppc/mol @@ -324,11 +322,9 @@ fi echo "ok." - cd $OBJDIR - SRCDIR=.. - ODIR=. + ODIR=$OBJDIR - printf "Creating target Makefile..." + printf "Creating target config.mak..." echo "ARCH=$ARCH" > $ODIR/config.mak if [ "$cross" = "yes" ]; then echo "TARGET=$TARGET" >> $ODIR/config.mak @@ -338,7 +334,10 @@ echo "HOSTARCH?=$HOSTARCH" >> $ODIR/config.mak echo "CROSSCFLAGS=$CROSSCFLAGS" >> $ODIR/config.mak echo "VERSION=\"$VERSION\"" >> $ODIR/config.mak + echo "SRCDIR=$SRCDIR" >> $ODIR/config.mak + echo "ok." + printf "Creating target rules.mak..." ln -s $SRCDIR/config/xml/rules.xml $ODIR/rules.xml echo "<?xml version=\"1.0\"?><config>" > $ODIR/config.xml # Generic @@ -381,8 +380,9 @@ fi cat $SRCDIR/config/examples/${ARCH}_config.xml >> $ODIR/config.xml + cd $ODIR echo "</config>" >> $ODIR/config.xml - ln -s ../Makefile.target $ODIR/Makefile + ln -s $SRCDIR/Makefile.target $ODIR/Makefile xsltproc $SRCDIR/config/xml/xinclude.xsl $SRCDIR/build.xml > $ODIR/build-full.xml xsltproc $SRCDIR/config/xml/makefile.xsl $ODIR/build-full.xml > $ODIR/rules.mak echo "ok." @@ -392,5 +392,12 @@ xsltproc $SRCDIR/config/xml/config-forth.xsl $ODIR/config.xml > $ODIR/forth/config.fs echo "ok." - cd $SRCDIR + cd $BUILDDIR done + +if [ "$SRCDIR" != "$BUILDDIR" ]; then + ln -s $SRCDIR/Makefile $BUILDDIR +fi + +echo "ODIRS=$ODIRS" >> $BUILDDIR/config-host.mak +echo "TARGETS=$arch_list" >> $BUILDDIR/config-host.mak Modified: trunk/openbios-devel/config/xml/dictionary.xsl ============================================================================== --- trunk/openbios-devel/config/xml/dictionary.xsl Sun Feb 3 17:50:11 2013 (r1098) +++ trunk/openbios-devel/config/xml/dictionary.xsl Sat Feb 16 13:08:33 2013 (r1099) @@ -56,7 +56,6 @@ <xsl:value-of select="$dictname"/><xsl:text>-DICTIONARY:=$(</xsl:text> <xsl:value-of select="$dictname"/><xsl:text>-DICTIONARY) </xsl:text> - <xsl:text>$(SRCDIR)/</xsl:text> <xsl:value-of select="$path"/> <xsl:value-of select="@source"/> <xsl:text>
</xsl:text> @@ -122,6 +121,8 @@ </xsl:if> </xsl:for-each> +  + <xsl:text> -I$(SRCDIR)</xsl:text>  <xsl:text> -I$(ODIR)/forth</xsl:text> Modified: trunk/openbios-devel/config/xml/object.xsl ============================================================================== --- trunk/openbios-devel/config/xml/object.xsl Sun Feb 3 17:50:11 2013 (r1098) +++ trunk/openbios-devel/config/xml/object.xsl Sat Feb 16 13:08:33 2013 (r1099) @@ -52,7 +52,6 @@ <xsl:text>.o: </xsl:text>  - <xsl:text>$(SRCDIR)/</xsl:text> <xsl:value-of select="$path"/> <xsl:value-of select="@source"/>

1 0

Re: [OpenBIOS] Macintosh device tree
by Programmingkid 16 Feb '13

16 Feb '13

On second thought you and others can still help. The device tree to the 450 MHz blue and white Power Mac G3 would help. To print out the device tree you will need these items: The blue and white G3, another computer with an ethernet port, and a ethernet crossover cable. You might be able to substitute the crossover cable with a regular ethernet patch cable if you use another more recent Mac like a MacPro or MacBook Pro. The other computer can be a Mac or PC. First connect the cable into each computer's ethernet port. Start up the blue and white G3 while holding down the command-option-o-f keys. This will bring up Open Firmware. Type in this command to start a telnet server: “ enet:telnet,10.0.0.2” io On the other computer, make sure its ethernet ip address is set to something like 10.0.0.1. You can do this in the Network pane under System Preferences in Mac OS X. Under Windows you would use something like the Network control panel. On the other computer, you will also want to open some console and start the telnet command like this: telnet 10.0.0.2 If everything worked, then the blue and white G3's screen will go black and its output will appear on the telnet session. Type these commands to print the device tree: dev / ls Also type this command to give us info on the model string: .properties Yes, the period is there on purpose. Once you are done with that, the info for the via-cuda and uninorth nodes would help as well. These commands will print out some useful info: dev via-cuda .properties words I think this would bring up info on the uninorth node: dev uni-n@f8000000 .properties words If the dev command doesn't work, it might be because the node might have a @<some hex number> text attached to it. I can help any one who needs help with this issue. Copy and paste the output from these commands and send them to the mailing list. Thank you to anyone who can help. This much needed information will really help push the mac99 target along. On Feb 3, 2013, at 9:03 PM, Programmingkid wrote: > Thanks for the help, but it turns out I needed an early iMac's device tree. > > On Feb 3, 2013, at 8:00 PM, Mike Erwin wrote: > >> For some reason this mail didn't go through... >> >> Mike Erwin >> musician, naturalist, pixel pusher, hacker extraordinaire >> >> >> On Sat, Feb 2, 2013 at 7:14 PM, Mike Erwin <significant.bit(a)gmail.com> wrote: >> I have several machines of that vintage. How do I get the device tree? Let me know which ones would be useful. >> >> 450MHz blue & white G3 >> 500MHz Powerbook G3 >> dual 500MHz (I think) graphite G4 >> a few Quicksilver G4s (my favorite model) >> >> Mike Erwin >> musician, naturalist, pixel pusher, hacker extraordinaire >> >> >> On Sat, Feb 2, 2013 at 4:27 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: >> I am investigating the device tree of the mac99 model. It looks like it is wrong. The part that I am concerned with is the via-cuda node. Both my iMac and iBook don't even have a via-cuda. They both have a via-pmu@16000 node. I'm hoping someone has an original blue and white PowerMac G3. I would like the full device tree printout from it. The question I am trying to answer is does any newworld Mac have a via-cuda? If they don't, we know that it should be changed to a via-pmu@16000 node. >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >> >> >

2 1

Re: [OpenBIOS] Macintosh device tree
by Programmingkid 16 Feb '13

16 Feb '13

On Feb 3, 2013, at 9:47 PM, Programmingkid wrote: > > On Feb 3, 2013, at 7:17 PM, Amadeusz Sławiński wrote: > >> On Mon, Feb 04, 2013 at 12:24:26AM +0100, Andreas Färber wrote: >>> Am 02.02.2013 22:27, schrieb Programmingkid: >>>> I am investigating the device tree of the mac99 model. It looks like it is wrong. The part that I am concerned with is the via-cuda node. Both my iMac and iBook don't even have a via-cuda. They both have a via-pmu@16000 node. I'm hoping someone has an original blue and white PowerMac G3. I would like the full device tree printout from it. The question I am trying to answer is does any newworld Mac have a via-cuda? If they don't, we know that it should be changed to a via-pmu@16000 node. >>> >>> I have one around, and it has a via-cuda@16000 node. There's a >>> power-mgt@0 node at the same level (under mac-io@5) but no pmu node. >> >> With regards to mac99 target I would rather be concerned with lack of /uni-n, as >> darwin seems to check for this (it panics when checking machine type) Do you think this is a QEMU or OpenBIOS issue?

3 2

Beige G3 device tree
by Programmingkid 15 Feb '13

15 Feb '13

I finally obtained a Beige G3 for comparing with our emulated model. The model is very wrong. No wonder Mac OS X won't boot. What it expects a Beige G3 to look like is not being supplied. It is going to take a lot of changes to QEMU and OpenBIOS to fix things. My current guess why Mac OS X stops where it does is because of the missing ide@20000 node under the mac-io@10 node. Here is a real Beige G3's device tree: Children of the node: 86748104: / [AAPL,Gossamer MacRISC] Node Adr Node Name Compatible 86753208: /cpus@0 86753488: /PowerPC,750@0 86754536: /l2-cache@0,0 86756192: /chosen@0 86756496: /memory@0 86756824: /openprom@0 86757016: /AAPL,ROM@FFC00000 [AAPL,ROM] 86757600: /options@0 86758784: /aliases@0 /packages@0 /deblocker@0,0 /disk-label@0,0 /obp-tftp@0,0 /mac-files@0,0 /mac-parts@0,0 /aix-boot@0,0 /fat-files@0,0 /iso-9660-files@0,0 /xcoff-loader@0,0 /terminal-emulator@0,0 /pci@80000000 [grackle] /mac-io@10 [heathrow] /mesh@10000 [mesh] /sd@0,0 [sd] /st@0,0 [st] /bmac@11000 [bmac] /escc@13000 [escc CHRP,es0] /ch-a@13020 [ch-a CHRP,es2] /ch-b@13000 [ch-b CHRP,es3] /davbus@14000 /sound@0,0 [awacs screamer] /swim3@15000 [swim3] /nvram@60000 [nvram] /ide@20000 [heathrow-ata] /disk@0,0 /ide@21000 [heathrow-ata] /disk@0,0 /via-cuda@16000 [via-cuda] /adb@0,0 [adb] /keyboard@0,0 /mouse@1,0 /pram@0,0 /rtc@0,0 [rtc] /power-mgt@0,0 [power-mgt] /ATY,mach64_3DU@12 /perch@0 [Wings] \ Properties of the root node 0 > .properties name device-tree model Power Macintosh compatible AAPL,Gossamer MacRISC AAPL,cpu-id 00000000 #address-cells 00000001 #size-cells 00000001 clock-frequency 03FB97A0 \ mac-io node properties name mac-io device_type dbdma model AAPL,343S1201 reg 00008000 00000000 00000000 00000000 00000000 02008010 00000000 F3000000 00000000 00080000 assigned-addresses 02008010 00000000 F3000000 00000000 00080000 ranges 00000000 02008010 00000000 F3000000 00080000 #address-cells 00000001 #size-cells 00000001 vendor-id 0000106B device-id 00000010 revision-id 00000001 class-code 00FF0000 min-grant 00000000 max-latency 00000000 devsel-speed 00000001 AAPL,address F3000000 compatible heathrow 0 > dev mesh@10000 ok 0 > .properties name mesh device_type scsi model AAPL,343S1146 reg 00010000 00000100 00008000 00000200 clock-frequency 02FAF080 AAPL,interrupts 0000000C 00000000 AAPL,connector scsi compatible mesh 0 > dev /nvram@60000 ok 0 > .properties name nvram device_type nvram compatible nvram reg 00060000 00020000 existing 00000000 00002000 0 > dev ide@20000 ok 0 > ls Children of the node: 86825168: /ide@20000 [heathrow-ata] Node Adr Node Name Compatible 86832680: /disk@0,0 0 > .properties name ide device_type ide AAPL,connector ata compatible heathrow-ata AAPL,bus-id 00000000 reg 00020000 00002000 00008800 00000200 AAPL,pio-timing 00000526 00000085 00000025 00000025 00000025 00000000 00000000 00000000 AAPL,interrupts 00000000 00000002 #address-cells 00000001

1 0

[PATCH] build: support disjoint build directory
by Blue Swirl 09 Feb '13

09 Feb '13

Support building in any directory, not just in-tree build. Use VPATH for non-Forth files. Forth compiler does not support explicit paths, so drop source path prefixes added by XML and rely on directories passed with -I flag. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- .gitignore | 1 + Makefile | 3 +- Makefile.target | 5 +++- config/scripts/switch-arch | 47 +++++++++++++++++++++++++------------------ config/xml/dictionary.xsl | 3 +- config/xml/object.xsl | 1 - 6 files changed, 35 insertions(+), 25 deletions(-) diff --git a/.gitignore b/.gitignore index e6b5c59..38e6dd8 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ obj-* .stgit-* +config-host.mak diff --git a/Makefile b/Makefile index 74e462c..3526b75 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,4 @@ -ODIRS=$(wildcard obj-*) -TARGETS=$(subst obj-,,$(ODIRS)) +include config-host.mak all: requirements info build diff --git a/Makefile.target b/Makefile.target index 934b95a..913fb13 100644 --- a/Makefile.target +++ b/Makefile.target @@ -6,7 +6,6 @@ include config.mak ODIR := . -SRCDIR := .. HOSTCC := gcc HOSTCFLAGS+= -O2 -g -DFCOMPILER -DBOOTSTRAP $(CROSSCFLAGS) @@ -38,6 +37,10 @@ AS_FLAGS+= -g quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1)) +VPATH_SUFFIXES = %.c %.h %.S %.fs +set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath $(PATTERN) $1))) +$(call set-vpath, $(SRCDIR)) + # # pre rules # diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch index a9c911b..b91af7c 100755 --- a/config/scripts/switch-arch +++ b/config/scripts/switch-arch @@ -117,21 +117,18 @@ config_set_boolean() echo "<option name=\"$option\" type=\"boolean\" value=\"true\" />" } -if ! test -f utils/dist/debian/rules; then - echo "switch-arch must be run from the top-level source directory" >&2 - exit 1 -fi -# This is needed because viewvc messes with the permissions of executables: -chmod 755 utils/dist/debian/rules -chmod 755 config/scripts/switch-arch -chmod 755 config/scripts/reldir +SRCDIR=`dirname "$0"`/../.. +BUILDDIR=`pwd` + +# make source path absolute +SRCDIR=`cd "$SRCDIR"; pwd` if test "x$HOSTARCH" = "x"; then archname fi -VERSION=`head VERSION` +VERSION=`head $SRCDIR/VERSION` echo "Configuring OpenBIOS on $HOSTARCH for $*" @@ -156,8 +153,8 @@ done arch_list="" for target in $target_list; do arch=`echo $target | sed s/.*-//g` - if ! test -f config/examples/${arch}_config.xml; then - echo "Cannot find config/examples/${arch}_config.xml" >&2 + if ! test -f $SRCDIR/config/examples/${arch}_config.xml; then + echo "Cannot find $SRCDIR/config/examples/${arch}_config.xml" >&2 exit 1 fi if ! echo $arch_list | grep -q "$arch"; then @@ -269,7 +266,8 @@ for ARCH in $arch_list; do cross="yes" fi crosscflags $HOSTARCH $ARCH - OBJDIR=obj-$ARCH + OBJDIR=$BUILDDIR/obj-$ARCH + ODIRS="$ODIRS $OBJDIR" printf "Initializing build tree $OBJDIR..." rm -rf "$OBJDIR" @@ -294,9 +292,9 @@ for ARCH in $arch_list; do mkdir -p $OBJDIR/host/include mkdir -p $OBJDIR/host/kernel mkdir -p $OBJDIR/forth - ln -s ../../../include/arch/$BASEARCH $OBJDIR/target/include/asm + ln -s $SRCDIR/include/arch/$BASEARCH $OBJDIR/target/include/asm #compile the host binary with target settings instead - #ln -s ../../../include/arch/$HOSTARCH $OBJDIR/host/include/asm + #ln -s $SRCDIR/include/arch/$HOSTARCH $OBJDIR/host/include/asm if [ "$mol" = "yes" ]; then printf "\nUsing MOL path $MOLPATH...\n" mkdir -p $OBJDIR/target/arch/ppc/mol @@ -324,11 +322,9 @@ for ARCH in $arch_list; do fi echo "ok." - cd $OBJDIR - SRCDIR=.. - ODIR=. + ODIR=$OBJDIR - printf "Creating target Makefile..." + printf "Creating target config.mak..." echo "ARCH=$ARCH" > $ODIR/config.mak if [ "$cross" = "yes" ]; then echo "TARGET=$TARGET" >> $ODIR/config.mak @@ -338,7 +334,10 @@ for ARCH in $arch_list; do echo "HOSTARCH?=$HOSTARCH" >> $ODIR/config.mak echo "CROSSCFLAGS=$CROSSCFLAGS" >> $ODIR/config.mak echo "VERSION=\"$VERSION\"" >> $ODIR/config.mak + echo "SRCDIR=$SRCDIR" >> $ODIR/config.mak + echo "ok." + printf "Creating target rules.mak..." ln -s $SRCDIR/config/xml/rules.xml $ODIR/rules.xml echo "<?xml version=\"1.0\"?><config>" > $ODIR/config.xml # Generic @@ -381,8 +380,9 @@ for ARCH in $arch_list; do fi cat $SRCDIR/config/examples/${ARCH}_config.xml >> $ODIR/config.xml + cd $ODIR echo "</config>" >> $ODIR/config.xml - ln -s ../Makefile.target $ODIR/Makefile + ln -s $SRCDIR/Makefile.target $ODIR/Makefile xsltproc $SRCDIR/config/xml/xinclude.xsl $SRCDIR/build.xml > $ODIR/build-full.xml xsltproc $SRCDIR/config/xml/makefile.xsl $ODIR/build-full.xml > $ODIR/rules.mak echo "ok." @@ -392,5 +392,12 @@ for ARCH in $arch_list; do xsltproc $SRCDIR/config/xml/config-forth.xsl $ODIR/config.xml > $ODIR/forth/config.fs echo "ok." - cd $SRCDIR + cd $BUILDDIR done + +if [ "$SRCDIR" != "$BUILDDIR" ]; then + ln -s $SRCDIR/Makefile $BUILDDIR +fi + +echo "ODIRS=$ODIRS" >> $BUILDDIR/config-host.mak +echo "TARGETS=$arch_list" >> $BUILDDIR/config-host.mak diff --git a/config/xml/dictionary.xsl b/config/xml/dictionary.xsl index 52d836a..664df0f 100644 --- a/config/xml/dictionary.xsl +++ b/config/xml/dictionary.xsl @@ -56,7 +56,6 @@ <xsl:value-of select="$dictname"/><xsl:text>-DICTIONARY:=$(</xsl:text> <xsl:value-of select="$dictname"/><xsl:text>-DICTIONARY) </xsl:text> - <xsl:text>$(SRCDIR)/</xsl:text> <xsl:value-of select="$path"/> <xsl:value-of select="@source"/> <xsl:text>
</xsl:text> @@ -122,6 +121,8 @@ </xsl:if> </xsl:for-each> +  + <xsl:text> -I$(SRCDIR)</xsl:text>  <xsl:text> -I$(ODIR)/forth</xsl:text> diff --git a/config/xml/object.xsl b/config/xml/object.xsl index 7af54ab..cf521f5 100644 --- a/config/xml/object.xsl +++ b/config/xml/object.xsl @@ -52,7 +52,6 @@ <xsl:text>.o: </xsl:text>  - <xsl:text>$(SRCDIR)/</xsl:text> <xsl:value-of select="$path"/> <xsl:value-of select="@source"/> -- 1.7.2.5

1 0

Re: [OpenBIOS] testing Mac OS X boot on latest trunk (revision 1085) + divide by zero patch
by Programmingkid 07 Feb '13

07 Feb '13

> On 13.01.13 16:43, Mark Cave-Ayland wrote: > > > On 12/01/13 16:05, Amadeusz Sławiński wrote: > > > > > > >> > I used the latest proposed divide by zero patch > > >> > >> > So it seems like it is almost there. > > >> > >> > Seems like it still can't load kernel when run with boot cd:,\\:tbxi > > >> > Mac OS X 10.0 > > >> http://asmblr.net/scrot/2013-01-12-155737_1366x768_scrot.png > >> > >> > Mac OS X 10.2 > > >> http://asmblr.net/scrot/2013-01-12-155642_1366x768_scrot.png > >> > >> > Mac OS X 10.4 > > >> http://asmblr.net/scrot/2013-01-12-155935_1366x768_scrot.png > >> > >> > >> > However when I specify partition to use it loads: > > >> > Mac OS X 10.0 (boot cd:9,\\:tbxi) > > >> http://asmblr.net/scrot/2013-01-12-163133_1366x768_scrot.png > >> > >> > Mac OS X 10.2 (boot cd:9,\\:tbxi) > > >> http://asmblr.net/scrot/2013-01-12-163300_1366x768_scrot.png > >> > >> > Mac OS X 10.4 (boot cd:3,\\:tbxi) > > >> http://asmblr.net/scrot/2013-01-12-163419_1366x768_scrot.png > > > > > > > This should now be fixed in SVN trunk. > > > > > > > > I believe I have now committed all outstanding patches based upon > > > > William's main GSOC patchset, and performed a QEMU CDROM boot test > > > > across all of SPARC32, SPARC64 and PPC to confirm that I haven't > > > > introduced any regressions across any of my test images. Thank you > > > > everyone for your help, patience and testing. > > > > > > > > Interestingly enough, commits 1081 and 1082 appear to have fixed the key > > > > issues with OpenBIOS's PPC MMU code and as a result, the following > > > > kernels will now at least boot from ISO images in QEMU: > > > > > > > > Darwin > > > > FreeBSD > > > > NetBSD > > > > HelenOS > > > > Fedora Linux > > > > SuSE Linux > > > > > > > > I think the remainder of the bugs during kernel initialisation are > > > > related to either missing/erroneous properties in the OpenBIOS device > > > > tree, or bugs in QEMU's device emulation/Mac hardware model. This will > > > > likely require some assistance from the QEMU people to fix. > > > I can confirm the statement from Mark regarding FreeBSD. So far I can > boot but I fail due to the fact that some interrupt-parents are not > populated. Namely for via-cuda and for ata-1/2/3. Adding these lets the > boot continue until I hang somewhere in a cpu_idle routine. Still > investigating. > > One thing the qemu people might clarify, is -M mac99 ok to use? Or what > would be the preferred Mac model and which cpu? > My trials go with mac99 and -cpu G4 on the 32-bit qemu. > > I think once I solved the spinning in the cpu_idle routine I'm near > completing the boot. > > Thank you all for this effort! > > Andreas > Would you have a patch for this interrupt-parent property? If it helps, here is the what I found in an G3 iMac: via-pmu properties 0 > .properties name via-pmu device_type via-pmu compatible pmu reg 00016000 00002000 interrupts 00000019 00000001 interrupt-parent ff90fa00 pmu-version 00d07e0c AAPL,clock-id 73706920 73703331 AAPL,clock-data 01de2000 00000044 00008000 00000000 00000000 00000044 00008000 00000044 00000010 6e756c6c 6e756c6c 012ad400 I think the mac99 model might be better at making Mac OS X boot on QEMU than the Beige G3 model. I personally would stick with the G3 processor. It has less features than the G4 so it might be easier to work with and emulate.

2 2

[Patch] Fix model string
by Programmingkid 07 Feb '13

07 Feb '13

This patch corrects the model string so OpenBIOS reports a value of PowerMac1,1. This string represents the blue and white Power Mac G3. signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Index: arch/ppc/qemu/init.c =================================================================== --- arch/ppc/qemu/init.c (revision 1098) +++ arch/ppc/qemu/init.c (working copy) @@ -734,12 +734,12 @@ /* model */ - push_str("PowerMac2,1"); + push_str("PowerMac1,1"); fword("model"); /* compatible */ - push_str("PowerMac2,1"); + push_str("PowerMac1,1"); fword("encode-string"); push_str("MacRISC"); fword("encode-string");

2 2

[PATCH] SPARC32 : microSPARC-II identification
by Olivier DANET 03 Feb '13

03 Feb '13

For the microSPARC-II = Fujitsu MB86904 = Sun STP1012PGA, PSR.IMPL=0 and PSR.VERS=4 This CPU model is used as default by QEMU when emulating a SparcStation-4 or SparcStation-5 Signed-off-by: Olivier DANET <odanet(a)caramail.com> diff a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -244,9 +244,9 @@ static const struct cpudef sparc_defs[] .iu_version = 0x04 << 24, /* Impl 0, ver 4 */ .name = "FMI,MB86904", .psr_impl = 0, - .psr_vers = 5, + .psr_vers = 4, .impl = 0, - .vers = 5, + .vers = 4, .dcache_line_size = 0x10, .dcache_lines = 0x200, .dcache_assoc = 1,

2 1

[commit] r1098 - trunk/openbios-devel/arch/sparc32
by repository service 03 Feb '13

03 Feb '13

Author: blueswirl Date: Sun Feb 3 17:50:11 2013 New Revision: 1098 URL: http://tracker.coreboot.org/trac/openbios/changeset/1098 Log: SPARC32: microSPARC-II identification For the microSPARC-II = Fujitsu MB86904 = Sun STP1012PGA, PSR.IMPL=0 and PSR.VERS=4. This CPU model is used as default by QEMU when emulating a SparcStation-4 or SparcStation-5. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/openbios.c Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Thu Jan 31 22:37:13 2013 (r1097) +++ trunk/openbios-devel/arch/sparc32/openbios.c Sun Feb 3 17:50:11 2013 (r1098) @@ -244,9 +244,9 @@ .iu_version = 0x04 << 24, /* Impl 0, ver 4 */ .name = "FMI,MB86904", .psr_impl = 0, - .psr_vers = 5, + .psr_vers = 4, .impl = 0, - .vers = 5, + .vers = 4, .dcache_line_size = 0x10, .dcache_lines = 0x200, .dcache_assoc = 1,

1 0

Re: [OpenBIOS] Fix double nvram entry on newworld
by Alexander Graf 03 Feb '13

03 Feb '13

Am 02.02.2013 um 14:05 schrieb Blue Swirl <blauwirbel(a)gmail.com>: > On Thu, Jan 31, 2013 at 3:10 PM, Alexander Graf <agraf(a)suse.de> wrote: >> >> On 30.01.2013, at 11:29, Amadeusz Sławiński wrote: >> >>> Fix double nvram entry on newworld >>> >>> There are two nvram entries on newworld (for example qemu -M mac99) >>> >>> The first one (nvram@fff04000) has initialized .properties while the >>> other one has words. >>> >>> 0 > dev / ls >>> ... >>> fff75e24 pci@f2000000 >>> fff77848 nvram@fff04000 >>> fff778e0 nvram >>> ok >>> 0 > dev /nvram@fff04000 ok >>> 0 > words >>> ok >>> 0 > .properties >>> name "nvram" >>> #bytes 2000 >>> reg fff04000 00004000 >>> device_type "nvram" >>> compatible "nvram,flash" >>> ok >>> 0 > dev /nvram@0 ok >>> 0 > words close open seek write read size >>> ok >>> 0 > .properties >>> name "nvram" >>> ok >>> >>> This patch fixes initialization, so only one node is created >>> containing both .properties and words. >>> >>> 0 > dev / ls >>> ... >>> fff75e24 pci@f2000000 >>> fff77868 nvram@fff04000 >>> ok >>> 0 > dev /nvram@fff04000 ok >>> 0 > words close open seek write read size >>> ok >>> 0 > .properties >>> name "nvram" >>> #bytes 2000 >>> reg fff04000 00004000 >>> device_type "nvram" >>> compatible "nvram,flash" >>> ok >>> >>> Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> >> >> Blue, once this patch is in the tree, do you think you could rebuild OpenBIOS for QEMU, so that it will land in 1.4? > > Sorry, it didn't happen before the freeze. I'm not sure if new > OpenBIOS images qualifies as a bug fix. I would say yes ;). Anthony, any objections from your side? Alex > Most of the changes since > r1063 (now in QEMU) are bug fixes, though: > a5af2b3 macio.c: Fix double nvram entry on newworld > ff86ced SPARC32: WIM register update delay > 8e9793b SPARC32: Clear FP register > c23f9f7 esp.c: fix SCSI command code displayed in do_command() debug statement. > 39988d6 esp.c: fix TEST_UNIT_READY SCSI command length. > 75e29de Revert configuration change from previous commit. > d5df782 video.c: Fix compilation when CONFIG_DEBUG_CONSOLE_VIDEO is > set to false. > 91119ec video.c: Fix incorrect sized type in fill_rect(). > 3caf41b mac-parts.c: Update bootpath to reflect the chosen partition > if unspecified. > ec237bb Switch partition argument parsing to use left-parse-string as > per CHRP bindings. > e4ada76 PPC: Mimic Apple's OpenFirmware behaviour if a divide by zero occurs. > 7e64c09 mac-parts.c: Add Apple_Bootstrap to partition types considered > for Mac boot. > 5b48904 PPC: Fix filll word used by BootX > 1711362 Ignore any attempts to emit a character to stdout when stdout > is set to 0. > 6294e00 adb_kbd.c: Implement dummy get-key-map word for the ADB > keyboard package. > 1484d2b PPC: Fix mapping of OpenBIOS ROM in RAM copy within OFMEM > 69c27c4 PPC: Fix next slot eviction > 1be3a15 video.c: Place framebuffer address in frame-buffer-adr > e11cacd mac-parts.c: Fix detection of wrapped HFS+ volumes. > 7694794 PPC: Implement filll (fill long) word for QEMU/PPC as required by BootX. > 1fbbbd2 Redefine "to" word in device.fs to allow the current package > to be set like a standard value. > 1da510f Rework mac-parts.c to use CHRP-compliant partition search, > followed by Apple OF partition search. > b70a1f7 PPC: Rework assignment of keyboard devalias. > dd37f6b Add a default "decode-unit" word for devices that don't > implement their own. > 7a370cc PPC: Add keyboard device alias as a duplicate of stdin. > 58106df Fix dir cd:,\ (no partition specified) when reading from Mac partitions. > 5f23f2c Improve dir word by reducing complexity and adding some more > diagnostics. > a78e3b4 The spin word is set by BootX when Mac OS X is booting. > 37d2f65 PPC32: Enable local variables for the PPC32 build. > 538d404 Implementation of Forth local variables for OpenBIOS. > 5bb1484 amd64: Fix compilation from last commit to implement "dir" > word for HFS+ filesystem. > 0495b71 Add initial implementation of "dir" word for HFS+ filesystems. > 21ed61f Fix HFS+ display for non-ASCII characters. > 5b22479 Fix bug related to opening backup volumes in libhfsp's volume_open(). > f095c85 ppc qemu: Increase PCI hole for heathrow > >> >> >> Thanks, >> >> Alex >> >>> >>> diff -uNr a/drivers/macio.c b/drivers/macio.c >>> --- a/drivers/macio.c 2013-01-28 12:16:54.849868216 +0100 >>> +++ b/drivers/macio.c 2013-01-28 12:17:27.595867493 +0100 >>> @@ -57,12 +57,6 @@ >>> } else { >>> nvram_offset = NW_IO_NVRAM_OFFSET; >>> nvram_size = NW_IO_NVRAM_SIZE; >>> - push_str("/"); >>> - fword("find-device"); >>> - fword("new-device"); >>> - push_str("nvram"); >>> - fword("device-name"); >>> - fword("finish-device"); >>> } >>> nvram = (char*)addr + nvram_offset; >>> snprintf(buf, sizeof(buf), "%s/nvram", path); >>> >>> -- >>> OpenBIOS http://openbios.org/ >>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>> Free your System - May the Forth be with you >>

3 3

Fix double nvram entry on newworld
by Amadeusz Sławiński 02 Feb '13

02 Feb '13

Fix double nvram entry on newworld There are two nvram entries on newworld (for example qemu -M mac99) The first one (nvram@fff04000) has initialized .properties while the other one has words. 0 > dev / ls ... fff75e24 pci@f2000000 fff77848 nvram@fff04000 fff778e0 nvram ok 0 > dev /nvram@fff04000 ok 0 > words ok 0 > .properties name "nvram" #bytes 2000 reg fff04000 00004000 device_type "nvram" compatible "nvram,flash" ok 0 > dev /nvram@0 ok 0 > words close open seek write read size ok 0 > .properties name "nvram" ok This patch fixes initialization, so only one node is created containing both .properties and words. 0 > dev / ls ... fff75e24 pci@f2000000 fff77868 nvram@fff04000 ok 0 > dev /nvram@fff04000 ok 0 > words close open seek write read size ok 0 > .properties name "nvram" #bytes 2000 reg fff04000 00004000 device_type "nvram" compatible "nvram,flash" ok Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> diff -uNr a/drivers/macio.c b/drivers/macio.c --- a/drivers/macio.c 2013-01-28 12:16:54.849868216 +0100 +++ b/drivers/macio.c 2013-01-28 12:17:27.595867493 +0100 @@ -57,12 +57,6 @@ } else { nvram_offset = NW_IO_NVRAM_OFFSET; nvram_size = NW_IO_NVRAM_SIZE; - push_str("/"); - fword("find-device"); - fword("new-device"); - push_str("nvram"); - fword("device-name"); - fword("finish-device"); } nvram = (char*)addr + nvram_offset; snprintf(buf, sizeof(buf), "%s/nvram", path);

5 5

G3 iMac device tree
by Programmingkid 01 Feb '13

01 Feb '13

Here is the device tree with properties of a G3 iMac: G3 iMac Device tree 0 > dev / ok 0 > ls ff83d640: /cpus ff83d8f0: /PowerPC,750@0 ff83dcb0: /l2-cache ff83e930: /chosen ff83eb48: /memory@0 ff83ede8: /openprom ff83ef90: /client-services ff840280: /rom@ff800000 ff840480: /boot-rom@fff00000 ff8406b0: /macos ff8407b8: /options ff8408c0: /aliases ff8413a8: /packages ff841488: /deblocker ff841e20: /disk-label ff8428e8: /obp-tftp ff84c1c8: /telnet ff84cac8: /mac-parts ff84e270: /mac-files ff851128: /hfs-plus-files ff855f48: /fat-files ff857d40: /iso-9660-files ff858ba0: /bootinfo-loader ff85a878: /xcoff-loader ff85b310: /pe-loader ff85bd60: /elf-loader ff85d408: /usb-hid-class ff85ff48: /usb-ms-class ff862b98: /usb-audio-class ff8d0710: /sbp2-disk ff8d30b0: /ata-disk ff8d4e18: /atapi-disk ff8d6d60: /bootpath-search ff8dd6f0: /terminal-emulator ff8dd800: /firewire-disk-mode ff8f20b8: /pseudo-hid ff8f21b8: /keyboard ff8f28b0: /mouse ff8f2e48: /eject-key ff8f3318: /pseudo-sound ff8f3648: /multiboot ff906638: /diagnostics ff906718: /nvram@fff04000 ff907318: /uni-n@f8000000 ff9075e0: /i2c@f8001000 ff907ea8: /cereal ff9085d8: /pci@f0000000 ff943eb0: /uni-north-agp@b ff944198: /ATY,Rage128Pk@10 ff94ce58: /ivad@0 ff909748: /pci@f2000000 ff90ba48: /mac-io@17 ff90fa00: /interrupt-controller@40000 ff90fc50: /gpio@50 ff90fdb8: /extint-gpio1 ff90ffd8: /programmer-switch ff910188: /escc-legacy@12000 ff9103f8: /ch-a@12004 ff9105f8: /ch-b@12000 ff9107f8: /escc@13000 ff910a80: /ch-a@13020 ff9114a8: /ch-b@13000 ff911e40: /davbus@14000 ff912178: /sound ff912a08: /timer@15000 ff912c18: /via-pmu@16000 ff9161f0: /rtc ff916960: /power-mgt ff94d030: /usb-power-mgt ff916c48: /i2c@18000 ff917550: /cereal ff94cb00: /i2c-modem ff917c98: /ata-4@1f000 ff91a508: /disk ff91ac68: /ata-3@20000 ff91d4d8: /disk ff91dc38: /ata-3@21000 ff9204a8: /disk ff920b50: /radio@30000 ff927190: /usb@18 ff94b9e8: /hub@1 ff94bbf0: /device@2 ff94bd68: /interface@0 ff94bf28: /mouse@3 ff92ee18: /usb@19 ff94af48: /hub@1 ff94b150: /device@1 ff94b2c8: /keyboard@0 ff94b658: /eject-key@1 ff90a8d0: /pci@f4000000 ff936bc0: /firewire@e ff93f4a8: /ethernet@f ff94d1f0: /ethernet-phy 0 > .properties model PowerMac2,2 compatible PowerMac2,2 MacRISC2 MacRISC Power Macintosh serial-number <removed> customer-sw-config color-code 0000 scb# 00000000 theater-mode name device-tree copyright Copyright 1983-2001 Apple Computer, Inc. All Rights Reserved device_type bootrom system-id 0000000000000 #address-cells 00000001 #size-cells 00000001 clock-frequency 05f3e279 AAPL,add-fcode-file ff81f498

1 0

Device tree from G3 iBook
by Programmingkid 01 Feb '13

01 Feb '13

I thought this device tree will help any one who might want to work on the Mac99 target. It is the device tree from a G3 iBook. 0 > dev / ok 0 > ls ff83d628: /cpus ff83d8d8: /PowerPC,750@0 ff83dcb8: /l2-cache ff83e938: /chosen ff83eb50: /memory@0 ff83edf0: /openprom ff83ef98: /client-services ff840288: /rom@ff800000 ff840488: /boot-rom@fff00000 ff8406c0: /macos ff8407c8: /options ff8408d0: /aliases ff8413b8: /packages ff841498: /deblocker ff841e30: /disk-label ff8428f8: /obp-tftp ff84c1d8: /telnet ff84cad8: /mac-parts ff84e280: /mac-files ff851138: /hfs-plus-files ff855f58: /fat-files ff857d50: /iso-9660-files ff858bb0: /bootinfo-loader ff85a888: /xcoff-loader ff85b320: /pe-loader ff85bd70: /elf-loader ff85d418: /usb-hid-class ff85ff58: /usb-ms-class ff862ba8: /usb-audio-class ff8d0720: /sbp2-disk ff8d30c0: /ata-disk ff8d4e28: /atapi-disk ff8d6d70: /bootpath-search ff8dd700: /terminal-emulator ff8dd810: /firewire-disk-mode ff8f20c8: /pseudo-hid ff8f21c8: /keyboard ff8f28c0: /mouse ff8f2e58: /eject-key ff8f3328: /pseudo-sound ff8f3658: /multiboot ff906648: /diagnostics ff906728: /nvram@fff04000 ff907328: /uni-n@f8000000 ff9075f0: /i2c@f8001000 ff907eb8: /cereal ff9085e8: /pci@f0000000 ff93b1f0: /uni-north-agp@b ff93b4d8: /ATY,RageM_Lp@10 ff909758: /pci@f2000000 ff90ba40: /mac-io@17 ff90f9f8: /interrupt-controller@40000 ff90fc48: /gpio@50 ff90fdb0: /extint-gpio1 ff90ffd0: /programmer-switch ff910188: /extint-gpio12 ff910360: /i2s@10000 ff910590: /i2s-a@10000 ff9108c0: /sound ff910f70: /i2s-b@11000 ff911148: /escc-legacy@12000 ff9113b8: /ch-a@12004 ff9115b8: /ch-b@12000 ff9117b8: /escc@13000 ff911a40: /ch-a@13020 ff912468: /ch-b@13000 ff912de8: /timer@15000 ff912ff8: /via-pmu@16000 ff9165d0: /rtc ff916d20: /adb ff916ed8: /keyboard@2 ff917c80: /mouse@3 ff918068: /power-mgt ff953fb8: /usb-power-mgt ff918380: /battery@0 ff9184a8: /backlight@f300 ff918648: /i2c@18000 ff918f50: /cereal ff953c68: /i2c-modem ff919698: /ata-4@1f000 ff91bd88: /disk ff91c4e8: /ata-3@20000 ff91ebd8: /disk ff91f338: /ata-3@21000 ff921a28: /disk ff928400: /usb@18 ff90a8c8: /pci@f4000000 ff936828: /ethernet@f ff954178: /ethernet-phy

2 2

[commit] r1097 - trunk/openbios-devel/drivers
by repository service 31 Jan '13

31 Jan '13

Author: mcayland Date: Thu Jan 31 22:37:13 2013 New Revision: 1097 URL: http://tracker.coreboot.org/trac/openbios/changeset/1097 Log: macio.c: Fix double nvram entry on newworld There are two nvram entries on newworld (for example qemu -M mac99) The first one (nvram@fff04000) has initialized .properties while the other one has words. 0 > dev / ls ... fff75e24 pci@f2000000 fff77848 nvram@fff04000 fff778e0 nvram ok 0 > dev /nvram@fff04000 ok 0 > words ok 0 > .properties name "nvram" reg fff04000 00004000 device_type "nvram" compatible "nvram,flash" ok 0 > dev /nvram@0 ok 0 > words close open seek write read size ok 0 > .properties name "nvram" ok This patch fixes initialization, so only one node is created containing both .properties and words. 0 > dev / ls ... fff75e24 pci@f2000000 fff77868 nvram@fff04000 ok 0 > dev /nvram@fff04000 ok 0 > words close open seek write read size ok 0 > .properties name "nvram" reg fff04000 00004000 device_type "nvram" compatible "nvram,flash" ok Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/macio.c Modified: trunk/openbios-devel/drivers/macio.c ============================================================================== --- trunk/openbios-devel/drivers/macio.c Sat Jan 26 13:50:15 2013 (r1096) +++ trunk/openbios-devel/drivers/macio.c Thu Jan 31 22:37:13 2013 (r1097) @@ -57,12 +57,6 @@ } else { nvram_offset = NW_IO_NVRAM_OFFSET; nvram_size = NW_IO_NVRAM_SIZE; - push_str("/"); - fword("find-device"); - fword("new-device"); - push_str("nvram"); - fword("device-name"); - fword("finish-device"); } nvram = (char*)addr + nvram_offset; snprintf(buf, sizeof(buf), "%s/nvram", path);

1 0

Re: [OpenBIOS] Mac OS X panic - qemu fix
by Programmingkid 30 Jan '13

30 Jan '13

On Jan 29, 2013, at 9:25 AM, Amadeusz Sławiński wrote: > Hey, you may want to try this patch against qemu > https://lists.nongnu.org/archive/html/qemu-ppc/2013-01/msg00392.html > it fixes, some of panics I have seen when trying to boot darwin/OS X > > On normal (not mac99) qemu machine, I was able to get to "Waiting for > root device" on darwinppc, OS X 10.2, OS X 10.4 I also see waiting for root device on Mac OS 10.2. Mac OS 10.0 has a kernel panic. Excellent job. This patch is a step in the right direction. Too bad this patch comes a day after QEMU 1.3.1 is released. Hopefully it will be included in the next release. Does anyone know what is wrong with the Mac99 target? I think it has the potential of being a better target than an emulated Beige G3.

3 2

new world (qemu -mac99), double nvram entry
by Amadeusz Sławiński 29 Jan '13

29 Jan '13

When looking at qemu -mac99 I noticed that there are two nvram entries in openbios: The first one (nvram@fff04000) has initialized .properties while the other one has words. 0 > dev / ls ... fff75e24 pci@f2000000 fff77848 nvram@fff04000 fff778e0 nvram ok 0 > dev /nvram@fff04000 ok 0 > words ok 0 > .properties name "nvram" #bytes 2000 reg fff04000 00004000 device_type "nvram" compatible "nvram,flash" ok 0 > dev /nvram@0 ok 0 > words close open seek write read size ok 0 > .properties name "nvram" ok Attached patch fixes initialization, so only one node is created containing both .properties and words. 0 > dev / ls ... fff75e24 pci@f2000000 fff77868 nvram@fff04000 ok 0 > dev /nvram@fff04000 ok 0 > words close open seek write read size ok 0 > .properties name "nvram" #bytes 2000 reg fff04000 00004000 device_type "nvram" compatible "nvram,flash" ok Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net>

2 1

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland 27 Jan '13

27 Jan '13

On 25/01/13 19:31, Blue Swirl wrote: > PenguinPPC used to have them online, but not anymore. Wayback Machine > still remembers: > http://web.archive.org/web/20090107130842/http://penguinppc.org/historical/… > > Other trees are also there: > http://web.archive.org/web/20081120133742/http://penguinppc.org/historical/… That's very useful. I'm tempted to archive these and put them somewhere on the wiki, as once these are gone it's going to be hard to find them again. Also - I notice in the link above that g3_beige_266 doesn't have a CMD646 controller? The g3_bw does though. ATB, Mark.

4 4

G3Beige OpenFirmware Tree?
by Mark Cave-Ayland 27 Jan '13

27 Jan '13

Hi all, Having spent a bit of time over the past week getting a bit further with booting the Darwin kernel, I'm now at the point where I can see that the reason the boot fails is because the CMD646ATA::start() method is failing in the driver here: http://www.opensource.apple.com/source/CMD646ATA/CMD646ATA-1.0.6f1/CMD646AT… I suspect it's a strange interaction between the CMD646ATA and CMD646Root drivers, but I was wondering if anyone had a complete OpenFirmware tree output from a real G3 Beige machine so I can compare the various properties between the real device tree and the QEMU device tree? Google appears to be struggling with this one. Many thanks, Mark.

6 15

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland 27 Jan '13

27 Jan '13

On 25/01/13 21:50, Artyom Tarasenko wrote: > A comment in FreeBSD ofw_pcibus.c says: > > /* > * Any AAPL,interrupts property gets priority and is > * fully specified (i.e. does not need routing) > */ > > https://github.com/oza/FreeBSD-8.0-dyntick/blob/master/sys/powerpc/ofw/ofw_… > > Could it be that multiple entries in the AAPL,interrupts properties > mean that the corresponding device has multiple interrupt lines? Interesting. My last thought was that if you are behind a PCI bridge then the first interrupt line may be that of the bridge device? I've also noticed that the mac-io IDE driver also fails in its start method, so I'm wondering if this something more generic related to the IDE layer which isn't quite right in OpenBIOS? I might try and see if I can install some kind of XCOFF gdb and take a look to see if I can work out from stepping through the function exactly which part is failing. ATB, Mark.

1 1

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland 27 Jan '13

27 Jan '13

On 26/01/13 22:14, Artyom Tarasenko wrote: > At least something. I haven't looked into the qemu-ppc implementation of cmd646, > does it support DMA? (qemu-sparc64 doesn't ant that's the reason why > Linux cmd646 driver fails). That's a good point. I see there are functions in QEMU's hw/ide/cmd646.c called bmdma_read() and bmdma_write() which would suggest that DMA is supported? ATB, Mark.

2 1

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland 26 Jan '13

26 Jan '13

On 25/01/13 20:54, Artyom Tarasenko wrote: >> Thanks for doing this. So I've had a play with PearPC and I can make the >> CMD646ATA fail during its start method similar to the way that QEMU does by >> commenting out the IDE interface IRQ entry from the "interrupt-map" >> property. This seems to support my theory that the problem is related to >> interrupt mapping. > > Looks very similar to sparc64/sun4u problems I struggled ~ a half a year ago. Great - thanks for the insight! >> Now AIUI g3beige is an "Old World" Mac and so the interrupt information >> should be held in the "AAPL,interrupts" property. I've verified that both >> QEMU and OpenBIOS calculate the irq_line in the same way (based upon device >> id), however I do see that some of the "AAPL,interrupts" values contain more >> than one integer. I wonder what this is supposed to represent? > > Could it be that the irq line is wired to the interrupt controller not > as a PCI irq line? Similarly to the sun4u machines? > Have you looked in the Linux/PPC cmd646 driver for the insights? I've checked in the QEMU/OpenBIOS source that the PCI irq_line is set correctly, and that does go through a Grackle <-> PCI IRQ mapping function so I would think it is okay. Aside from ProgrammingKid's comments, AFAICT from my test images here the Linux CMD64x driver appears to be working okay - at least the driver loads and manages to probe the CDROM correctly. ATB, Mark.

2 1

[PATCH] SPARC32 : Clear FP register
by Olivier DANET 26 Jan '13

26 Jan '13

The Frame Pointer register is used in "__switch_context_nosave" (switch.S) which is called at the end of the startup sequence (entry.S). This register should be initialized before use. (The SparcV8 standard states, page 75 : "Supervisor software may not assume that any particular processor or memory state, except for the PSR’s ET and S bits, has been initialized after a reset trap." diff a/openbios-devel/arch/sparc32/entry.S b/openbios-devel/arch/sparc32/entry.S --- a/openbios-devel/arch/sparc32/entry.S +++ b/openbios-devel/arch/sparc32/entry.S @@ -452,6 +452,7 @@ highmem: wr %g3, PSR_ET, %psr WRITE_PAUSE + set 0, %fp call __switch_context_nosave nop Signed-off-by: Olivier DANET <odanet(a)caramail.com>

2 1

[PATCH] SPARC32 : WIM register update delay
by Olivier DANET 26 Jan '13

26 Jan '13

The SparcV8 standard states, page 134 : "If any of the three instructions after a write state register instruction reads any ﬁeld that was changed by the original write state register instruction, the contents of that ﬁeld read by that instruction are undeﬁned." The restore instruction depends on the %WIM register, three NOPs must be inserted. diff a/openbios-devel/arch/sparc32/wuf.S b/openbios-devel/arch/sparc32/wuf.S --- a/openbios-devel/arch/sparc32/wuf.S +++ b/openbios-devel/arch/sparc32/wuf.S @@ -121,7 +121,7 @@ fnwin_patch1: srl %t_wim, 7, %twin_tmp2 fnwin_patch2: and %twin_tmp1, 0xff, %twin_tmp1 wr %twin_tmp1, 0x0, %wim /* Make window 'I' invalid */ - + WRITE_PAUSE restore %g0, %g0, %g0 /* Restore to window 'O' */ /* Trapped from kernel, we trust that the kernel does not Signed-off-by: Olivier DANET <odanet(a)caramail.com>

2 2

[commit] r1096 - trunk/openbios-devel/arch/sparc32
by repository service 26 Jan '13

26 Jan '13

Author: blueswirl Date: Sat Jan 26 13:50:15 2013 New Revision: 1096 URL: http://tracker.coreboot.org/trac/openbios/changeset/1096 Log: SPARC32: WIM register update delay The SparcV8 standard states, page 134: "If any of the three instructions after a write state register instruction reads any field that was changed by the original write state register instruction, the contents of that field read by that instruction are undefined." The restore instruction depends on the %WIM register, three NOPs must be inserted. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/wuf.S Modified: trunk/openbios-devel/arch/sparc32/wuf.S ============================================================================== --- trunk/openbios-devel/arch/sparc32/wuf.S Sat Jan 26 13:50:13 2013 (r1095) +++ trunk/openbios-devel/arch/sparc32/wuf.S Sat Jan 26 13:50:15 2013 (r1096) @@ -131,6 +131,7 @@ /* LOCATION: Window 'O' */ restore %g0, %g0, %g0 + WRITE_PAUSE /* LOCATION: Window 'W' */

1 0

[commit] r1095 - trunk/openbios-devel/arch/sparc32
by repository service 26 Jan '13

26 Jan '13

Author: blueswirl Date: Sat Jan 26 13:50:13 2013 New Revision: 1095 URL: http://tracker.coreboot.org/trac/openbios/changeset/1095 Log: SPARC32: Clear FP register The Frame Pointer register is used in "__switch_context_nosave" (switch.S) which is called at the end of the startup sequence (entry.S). This register should be initialized before use. (The SparcV8 standard states, page 75: "Supervisor software may not assume that any particular processor or memory state, except for the PSR's ET and S bits, has been initialized after a reset trap." Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/entry.S Modified: trunk/openbios-devel/arch/sparc32/entry.S ============================================================================== --- trunk/openbios-devel/arch/sparc32/entry.S Mon Jan 21 00:49:16 2013 (r1094) +++ trunk/openbios-devel/arch/sparc32/entry.S Sat Jan 26 13:50:13 2013 (r1095) @@ -452,6 +452,7 @@ wr %g3, PSR_ET, %psr WRITE_PAUSE + set 0, %fp call __switch_context_nosave nop

1 0

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Artyom Tarasenko 25 Jan '13

25 Jan '13

On Fri, Jan 25, 2013 at 9:54 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > Hi Mark, > > On Fri, Jan 25, 2013 at 5:20 PM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> On 25/01/13 09:48, Mark Morgan Lloyd wrote: >> >>>> On 24/01/13 09:27, Mark Morgan Lloyd wrote: >>>> >>>>> I've got one of those machines, set up for OS and Linux (i.e. it's a bit >>>>> fragile and I'd rather not try installing anything else on it). If that >>>>> sounds useful tell me what to do. >>>> >>>> >>>> Thanks! I think perhaps a tarball of /proc/device-tree from Linux is >>>> what I need? There may be a utility to dump the tree from OS X too, >>>> but I'm not exactly sure what it is. >>> >>> >>> My OS is 9 (I think), I only use it for transferring control to Linux. >>> You have off-list mail created as below, note error messages of the type >>> indicated: >>> >>> 0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree >>> tar: Removing leading `/' from member names >>> tar: /proc/device-tree/perch: file changed as we read it >>> .. >>> >>> Let me know if there's anything else I can do to help. >> >> >> Hi Mark, >> >> Thanks for doing this. So I've had a play with PearPC and I can make the >> CMD646ATA fail during its start method similar to the way that QEMU does by >> commenting out the IDE interface IRQ entry from the "interrupt-map" >> property. This seems to support my theory that the problem is related to >> interrupt mapping. > > Looks very similar to sparc64/sun4u problems I struggled ~ a half a year ago. > >> Now AIUI g3beige is an "Old World" Mac and so the interrupt information >> should be held in the "AAPL,interrupts" property. I've verified that both >> QEMU and OpenBIOS calculate the irq_line in the same way (based upon device >> id), however I do see that some of the "AAPL,interrupts" values contain more >> than one integer. I wonder what this is supposed to represent? > > Could it be that the irq line is wired to the interrupt controller not > as a PCI irq line? Similarly to the sun4u machines? A comment in FreeBSD ofw_pcibus.c says: /* * Any AAPL,interrupts property gets priority and is * fully specified (i.e. does not need routing) */ https://github.com/oza/FreeBSD-8.0-dyntick/blob/master/sys/powerpc/ofw/ofw_… Could it be that multiple entries in the AAPL,interrupts properties mean that the corresponding device has multiple interrupt lines? Artyom -- Regards, Artyom Tarasenko http://tyom.blogspot.com/search/label/qemu

1 0

Re : Re: [PATCH] ESP : Debug SCSI command
by Olivier DANET 21 Jan '13

21 Jan '13

>----- Message d'origine ----- >De : Blue Swirl >Envoyés : 20.01.13 16:58 >À : Mark Cave-Ayland >Objet : Re: [OpenBIOS] [PATCH] ESP : Debug SCSI command > >On Sun, Jan 20, 2013 at 3:23 PM, Mark Cave-Ayland ><mark.cave-ayland(a)ilande.co.uk> wrote: >> On 17/01/13 20:32, Blue Swirl wrote: >> >>> On Mon, Jan 14, 2013 at 9:26 PM, Olivier DANET<odanet(a)caramail.com> >>> wrote: >>>> >>>> [PATCH] ESP : Debug SCSI command >>> >>> >>> Please drop this line in the future. >>> >>>> The SCSI command code is at position 1, the first byte is the message_out >>>> byte (=0x80, constant) >>>> >>>> diff a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c >>>> --- a/openbios-devel/drivers/esp.c >>>> +++ b/openbios-devel/drivers/esp.c >>>> @@ -106,7 +106,7 @@ do_command(esp_private_t *esp, sd_privat >>>> // Clear interrupts to avoid guests seeing spurious interrupts >>>> (void)esp->ll->regs[ESP_INTRPT]; >>>> >>>> - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, >>>> esp->buffer[0], status); >>>> + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, >>>> esp->buffer[1], status); >>>> >>>> /* Target didn't want all command data? */ >>>> if ((status& ESP_STAT_TCNT) != ESP_STAT_TCNT) { >>>> >>>> >>>> >>>> Signed-off-by: Olivier DANET<odanet at caramail.com> >>> >>> >>> See the other message. >>> >>> Otherwise the patch is correct. >> >> >> Do you want me to tidy up and commit these patches? I'm happy to do that >> with the Signed-off-by. > >That would be most kind of you, thank you. > >> >> >> ATB, >> >> Mark. Thank you both for reviewing these patches. I will post others soon, they will not change much to QEMU though. Regards Olivier

2 1

[commit] r1094 - trunk/openbios-devel/drivers
by repository service 21 Jan '13

21 Jan '13

Author: mcayland Date: Mon Jan 21 00:49:16 2013 New Revision: 1094 URL: http://tracker.coreboot.org/trac/openbios/changeset/1094 Log: esp.c: fix SCSI command code displayed in do_command() debug statement. The SCSI command code is at position 1, the first byte is the message_out byte (=0x80, constant). Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/esp.c Modified: trunk/openbios-devel/drivers/esp.c ============================================================================== --- trunk/openbios-devel/drivers/esp.c Mon Jan 21 00:49:14 2013 (r1093) +++ trunk/openbios-devel/drivers/esp.c Mon Jan 21 00:49:16 2013 (r1094) @@ -106,7 +106,7 @@ // Clear interrupts to avoid guests seeing spurious interrupts (void)esp->ll->regs[ESP_INTRPT]; - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[1], status); /* Target didn't want all command data? */ if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) {

1 0

[commit] r1093 - trunk/openbios-devel/drivers
by repository service 21 Jan '13

21 Jan '13

Author: mcayland Date: Mon Jan 21 00:49:14 2013 New Revision: 1093 URL: http://tracker.coreboot.org/trac/openbios/changeset/1093 Log: esp.c: fix TEST_UNIT_READY SCSI command length. "TEST UNIT READY" is a 6 bytes SCSI command (00h/LUN/reserved/reserved/reserved/Control) and it is preceded by a IDENTIFY (0x80) message_out byte. The ESP transfer size is therefore 7 bytes. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/esp.c Modified: trunk/openbios-devel/drivers/esp.c ============================================================================== --- trunk/openbios-devel/drivers/esp.c Thu Jan 17 00:05:39 2013 (r1092) +++ trunk/openbios-devel/drivers/esp.c Mon Jan 21 00:49:14 2013 (r1093) @@ -197,11 +197,11 @@ test_unit_ready(esp_private_t *esp, sd_private_t *sd) { /* Setup command = Test Unit Ready */ - memset(esp->buffer, 0, 6); + memset(esp->buffer, 0, 7); esp->buffer[0] = 0x80; esp->buffer[1] = TEST_UNIT_READY; - if (do_command(esp, sd, 6, 0)) { + if (do_command(esp, sd, 7, 0)) { DPRINTF("test_unit_ready id %d failed\n", sd->id); return 0; }

1 0

Re: [OpenBIOS] [PATCH] ESP : Debug SCSI command
by Mark Cave-Ayland 20 Jan '13

20 Jan '13

On 17/01/13 20:32, Blue Swirl wrote: > On Mon, Jan 14, 2013 at 9:26 PM, Olivier DANET<odanet(a)caramail.com> wrote: >> [PATCH] ESP : Debug SCSI command > > Please drop this line in the future. > >> The SCSI command code is at position 1, the first byte is the message_out byte (=0x80, constant) >> >> diff a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c >> --- a/openbios-devel/drivers/esp.c >> +++ b/openbios-devel/drivers/esp.c >> @@ -106,7 +106,7 @@ do_command(esp_private_t *esp, sd_privat >> // Clear interrupts to avoid guests seeing spurious interrupts >> (void)esp->ll->regs[ESP_INTRPT]; >> >> - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); >> + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[1], status); >> >> /* Target didn't want all command data? */ >> if ((status& ESP_STAT_TCNT) != ESP_STAT_TCNT) { >> >> >> Signed-off-by: Olivier DANET<odanet at caramail.com> > > See the other message. > > Otherwise the patch is correct. Do you want me to tidy up and commit these patches? I'm happy to do that with the Signed-off-by. ATB, Mark.

2 1

[PATCH] ESP : Debug SCSI command
by Olivier DANET 17 Jan '13

17 Jan '13

[PATCH] ESP : Debug SCSI command The SCSI command code is at position 1, the first byte is the message_out byte (=0x80, constant) diff a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c --- a/openbios-devel/drivers/esp.c +++ b/openbios-devel/drivers/esp.c @@ -106,7 +106,7 @@ do_command(esp_private_t *esp, sd_privat // Clear interrupts to avoid guests seeing spurious interrupts (void)esp->ll->regs[ESP_INTRPT]; - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[1], status); /* Target didn't want all command data? */ if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) { Signed-off-by: Olivier DANET <odanet at caramail.com>

2 1

[PATCH] ESP : TEST_UNIT_READY SCSI command length
by Olivier DANET 17 Jan '13

17 Jan '13

[PATCH] ESP : TEST_UNIT_READY SCSI command length "TEST UNIT READY" is a 6 bytes SCSI command (00h/LUN/reserved/reserved/reserved/Control) and it is preceded by a IDENTIFY (0x80) message_out byte. the ESP transfer size is therefore 7 bytes. diff a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c --- a/openbios-devel/drivers/esp.c +++ b/openbios-devel/drivers/esp.c @@ -197,11 +197,11 @@ static unsigned int test_unit_ready(esp_private_t *esp, sd_private_t *sd) { /* Setup command = Test Unit Ready */ - memset(esp->buffer, 0, 6); + memset(esp->buffer, 0, 7); esp->buffer[0] = 0x80; esp->buffer[1] = TEST_UNIT_READY; - if (do_command(esp, sd, 6, 0)) { + if (do_command(esp, sd, 7, 0)) { DPRINTF("test_unit_ready id %d failed\n", sd->id); return 0; } Signed-off-by: Olivier DANET <odanet at caramail.com>

2 1

[commit] r1092 - trunk/openbios-devel/config/examples
by repository service 17 Jan '13

17 Jan '13

Author: mcayland Date: Thu Jan 17 00:05:39 2013 New Revision: 1092 URL: http://tracker.coreboot.org/trac/openbios/changeset/1092 Log: Revert configuration change from previous commit. Accidentally manged to leave CONFIG_DEBUG_CONSOLE_VIDEO set to false from testing. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/config/examples/sparc32_config.xml Modified: trunk/openbios-devel/config/examples/sparc32_config.xml ============================================================================== --- trunk/openbios-devel/config/examples/sparc32_config.xml Wed Jan 16 23:51:51 2013 (r1091) +++ trunk/openbios-devel/config/examples/sparc32_config.xml Thu Jan 17 00:05:39 2013 (r1092) @@ -11,7 +11,7 @@ <option name="CONFIG_DEBUG_INTERPRETER" type="boolean" value="false"/> <option name="CONFIG_DEBUG_CONSOLE" type="boolean" value="true"/> <option name="CONFIG_DEBUG_CONSOLE_SERIAL" type="boolean" value="true"/> - <option name="CONFIG_DEBUG_CONSOLE_VIDEO" type="boolean" value="false"/> + <option name="CONFIG_DEBUG_CONSOLE_VIDEO" type="boolean" value="true"/> <option name="CONFIG_DEBUG_ESP" type="boolean" value="false"/> <option name="CONFIG_DEBUG_SUN_PARTS" type="boolean" value="false"/> <option name="CONFIG_DEBUG_OBP" type="boolean" value="false"/>

1 0

[PATCH] SPARC32 : Palette registers
by Olivier DANET 16 Jan '13

16 Jan '13

[PATCH] SPARC32 : Palette addressing The dac[] global for the palette exists only when CONFIG_DEBUG_CONSOLE_VIDEO is defined diff a/openbios-devel/packages/video.c b/openbios-devel/packages/video.c --- a/openbios-devel/packages/video.c +++ b/openbios-devel/packages/video.c @@ -187,12 +186,14 @@ set_color( int ind, unsigned long color if( video.fb.depth == 8 ) OSI_SetColor( ind, color ); #elif defined(CONFIG_SPARC32) +#if defined(CONFIG_DEBUG_CONSOLE_VIDEO) if( video.fb.depth == 8 ) { dac[0] = ind << 24; dac[1] = ((color >> 16) & 0xff) << 24; // Red dac[1] = ((color >> 8) & 0xff) << 24; // Green dac[1] = (color & 0xff) << 24; // Blue } +#endif #else vga_set_color(ind, ((color >> 16) & 0xff), ((color >> 8) & 0xff), Signed-off-by: Olivier DANET <odanet(a)caramail.com>

2 1

[commit] r1091 - in trunk/openbios-devel: config/examples packages
by repository service 16 Jan '13

16 Jan '13

Author: mcayland Date: Wed Jan 16 23:51:51 2013 New Revision: 1091 URL: http://tracker.coreboot.org/trac/openbios/changeset/1091 Log: video.c: Fix compilation when CONFIG_DEBUG_CONSOLE_VIDEO is set to false. The dac[] global for the palette exists only when CONFIG_DEBUG_CONSOLE_VIDEO is defined. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/config/examples/sparc32_config.xml trunk/openbios-devel/packages/video.c Modified: trunk/openbios-devel/config/examples/sparc32_config.xml ============================================================================== --- trunk/openbios-devel/config/examples/sparc32_config.xml Wed Jan 16 23:51:38 2013 (r1090) +++ trunk/openbios-devel/config/examples/sparc32_config.xml Wed Jan 16 23:51:51 2013 (r1091) @@ -11,7 +11,7 @@ <option name="CONFIG_DEBUG_INTERPRETER" type="boolean" value="false"/> <option name="CONFIG_DEBUG_CONSOLE" type="boolean" value="true"/> <option name="CONFIG_DEBUG_CONSOLE_SERIAL" type="boolean" value="true"/> - <option name="CONFIG_DEBUG_CONSOLE_VIDEO" type="boolean" value="true"/> + <option name="CONFIG_DEBUG_CONSOLE_VIDEO" type="boolean" value="false"/> <option name="CONFIG_DEBUG_ESP" type="boolean" value="false"/> <option name="CONFIG_DEBUG_SUN_PARTS" type="boolean" value="false"/> <option name="CONFIG_DEBUG_OBP" type="boolean" value="false"/> Modified: trunk/openbios-devel/packages/video.c ============================================================================== --- trunk/openbios-devel/packages/video.c Wed Jan 16 23:51:38 2013 (r1090) +++ trunk/openbios-devel/packages/video.c Wed Jan 16 23:51:51 2013 (r1091) @@ -187,12 +187,14 @@ if( video.fb.depth == 8 ) OSI_SetColor( ind, color ); #elif defined(CONFIG_SPARC32) +#if defined(CONFIG_DEBUG_CONSOLE_VIDEO) if( video.fb.depth == 8 ) { dac[0] = ind << 24; dac[1] = ((color >> 16) & 0xff) << 24; // Red dac[1] = ((color >> 8) & 0xff) << 24; // Green dac[1] = (color & 0xff) << 24; // Blue } +#endif #else vga_set_color(ind, ((color >> 16) & 0xff), ((color >> 8) & 0xff),

1 0

[commit] r1090 - trunk/openbios-devel/packages
by repository service 16 Jan '13

16 Jan '13

Author: mcayland Date: Wed Jan 16 23:51:38 2013 New Revision: 1090 URL: http://tracker.coreboot.org/trac/openbios/changeset/1090 Log: video.c: Fix incorrect sized type in fill_rect(). 256 colour framebuffers are arrays of chars, not short integers. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/packages/video.c Modified: trunk/openbios-devel/packages/video.c ============================================================================== --- trunk/openbios-devel/packages/video.c Sun Jan 13 16:27:00 2013 (r1089) +++ trunk/openbios-devel/packages/video.c Wed Jan 16 23:51:38 2013 (r1090) @@ -159,7 +159,7 @@ while( ww-- ) *p++ = col; } else { - char *p = (char *)((unsigned short*)pp + x); + char *p = (char *)(pp + x); while( ww-- ) *p++ = col;

1 0

[PATCH] 256 colours framebuffer fill
by Olivier DANET 14 Jan '13

14 Jan '13

[PATCH] 256 colours framebuffer fill 256 colours framebuffers are arrays of chars, not short integers. diff a/openbios-devel/packages/video.c b/openbios-devel/packages/video.c --- a/openbios-devel/packages/video.c +++ b/openbios-devel/packages/video.c @@ -159,8 +159,7 @@ fill_rect( int col_ind, int x, int y, in while( ww-- ) *p++ = col; } else { - char *p = (char *)((unsigned short*)pp + x); - + char *p = pp + x; while( ww-- ) *p++ = col; } Signed-off-by: Olivier DANET <odanet(a)caramail.com>

1 0

About the Apple_Bootstrap patch
by Programmingkid 13 Jan '13

13 Jan '13

I just wanted to note that I see this error message when loading my Debian cd image: WARNING: Bootstrap partition type is wrong: "Apple_HFS" type should be: "Apple_Bootstrap".

2 1