Re: [PATCH] c-user: Clarify time formats

[Joel Sherrill]

Occurred to me that coarse was also a term in the list that I didn't
think was discussed.

Sorry for not catching it in the initial review.

--joel

On Thu, Dec 16, 2021 at 8:44 AM Sebastian Huber
 wrote:
>
> On 16/12/2021 15:36, Joel Sherrill wrote:
> > Will bintime and sbintime show up in the index?
>
> Thanks for the review, I added index entries for them.
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Clarify time formats

[Sebastian Huber]

On 17/12/2021 16:10, Joel Sherrill wrote:

Occurred to me that coarse was also a term in the list that I didn't
think was discussed.


Yes, but this belongs to another section.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Clarify time formats

[Joel Sherrill]

On Fri, Dec 17, 2021 at 9:38 AM Sebastian Huber
 wrote:
>
> On 17/12/2021 16:10, Joel Sherrill wrote:
> > Occurred to me that coarse was also a term in the list that I didn't
> > think was discussed.
>
> Yes, but this belongs to another section.

OK. Just needs defining.

--joel

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems] Remove powerpc/haleakala board

[Joel Sherrill]

Closes #4302.
---
 bsps/powerpc/haleakala/README  |  51 
 bsps/powerpc/haleakala/config/haleakala.cfg|  27 --
 bsps/powerpc/haleakala/include/bsp.h   | 107 
 bsps/powerpc/haleakala/include/bsp/irq.h   | 168 
 bsps/powerpc/haleakala/include/mmu_405.h   |  77 --
 bsps/powerpc/haleakala/include/tm27.h  |   1 -
 bsps/powerpc/haleakala/irq/irq.c   | 237 -
 bsps/powerpc/haleakala/irq/irq_init.c  |  96 ---
 bsps/powerpc/haleakala/start/bspstart.c| 190 -
 bsps/powerpc/haleakala/start/linkcmds  | 274 ---
 bsps/powerpc/haleakala/start/mmu_405.c | 293 -
 bsps/powerpc/haleakala/start/mmu_405asm.S  |  83 --
 bsps/powerpc/haleakala/start/start.S   | 237 -
 spec/build/bsps/optconsolebaud.yml |   1 -
 spec/build/bsps/powerpc/haleakala/abi.yml  |  18 --
 spec/build/bsps/powerpc/haleakala/bsphaleakala.yml |  72 -
 spec/build/bsps/powerpc/haleakala/optsprg.yml  |  15 --
 spec/build/bsps/powerpc/haleakala/optvecbase.yml   |  16 --
 spec/build/bsps/powerpc/haleakala/start.yml|  14 -
 19 files changed, 1977 deletions(-)
 delete mode 100644 bsps/powerpc/haleakala/README
 delete mode 100644 bsps/powerpc/haleakala/config/haleakala.cfg
 delete mode 100644 bsps/powerpc/haleakala/include/bsp.h
 delete mode 100644 bsps/powerpc/haleakala/include/bsp/irq.h
 delete mode 100644 bsps/powerpc/haleakala/include/mmu_405.h
 delete mode 100644 bsps/powerpc/haleakala/include/tm27.h
 delete mode 100644 bsps/powerpc/haleakala/irq/irq.c
 delete mode 100644 bsps/powerpc/haleakala/irq/irq_init.c
 delete mode 100644 bsps/powerpc/haleakala/start/bspstart.c
 delete mode 100644 bsps/powerpc/haleakala/start/linkcmds
 delete mode 100644 bsps/powerpc/haleakala/start/mmu_405.c
 delete mode 100644 bsps/powerpc/haleakala/start/mmu_405asm.S
 delete mode 100644 bsps/powerpc/haleakala/start/start.S
 delete mode 100644 spec/build/bsps/powerpc/haleakala/abi.yml
 delete mode 100644 spec/build/bsps/powerpc/haleakala/bsphaleakala.yml
 delete mode 100644 spec/build/bsps/powerpc/haleakala/optsprg.yml
 delete mode 100644 spec/build/bsps/powerpc/haleakala/optvecbase.yml
 delete mode 100644 spec/build/bsps/powerpc/haleakala/start.yml

diff --git a/bsps/powerpc/haleakala/README b/bsps/powerpc/haleakala/README
deleted file mode 100644
index 115ae63..000
--- a/bsps/powerpc/haleakala/README
+++ /dev/null
@@ -1,51 +0,0 @@
-# Adapted from Virtex BSP
-
-BSP NAME:   Haleakala
-BOARD:  AMCC/UDTech Haleakala 405Exr eval board
-BUS:N/A
-CPU FAMILY: ppc
-CPU:PowerPC 405EXr
-COPROCESSORS:   N/A
-MODE:   32 bit mode
-
-DEBUG MONITOR:
-
-PERIPHERALS
-===
-TIMERS: 405EXr internal
-SERIAL PORTS:   405EXr internal
-REAL-TIME CLOCK:DS1338
-DMA:405EXr internal
-VIDEO:  none
-SCSI:   none
-NETWORKING: 405EXr internal
-
-DRIVER INFORMATION
-==
-CLOCK DRIVER:   PPC Decrementer
-IOSUPP DRIVER:  N/A
-SHMSUPP:N/A
-TIMER DRIVER:   N/A
-TTY DRIVER: shared
-
-STDIO
-=
-PORT:   Console port 0
-ELECTRICAL: RS-232
-BAUD:   9600-115200
-BITS PER CHARACTER: 8
-PARITY: None
-STOP BITS:  1
-
-Notes
-=
-
-Board description
--
-clock rate:400 MHz
-ROM:   64MByte FLASH
-RAM:   256MByte DDR DRAM
-
-
-Porting

diff --git a/bsps/powerpc/haleakala/config/haleakala.cfg 
b/bsps/powerpc/haleakala/config/haleakala.cfg
deleted file mode 100644
index 57feb35..000
--- a/bsps/powerpc/haleakala/config/haleakala.cfg
+++ /dev/null
@@ -1,27 +0,0 @@
-#
-#  Config file for a PowerPC 405 based card
-#  mhamel
-#
-
-include $(RTEMS_ROOT)/make/custom/default.cfg
-
-RTEMS_CPU=powerpc
-
-#  This contains the compiler options necessary to select the CPU model
-#  and (hopefully) optimize for it.
-#
-CPU_CFLAGS = -mcpu=405
-
-# optimize flag: typically -0, could use -O4 or -fast
-# -O4 is ok for RTEMS
-# NOTE: some level of -O may be actually required by inline assembler
-CFLAGS_OPTIMIZE_V = -O1 -g
-
-# The following two lines enable compiling and linking on per element.
-CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections
-LDFLAGS = -Wl,--gc-sections
-
-define bsp-post-link
-   $(default-bsp-post-link)
-   $(OBJCOPY) -O srec $(basename $@)$(EXEEXT) $(basename $@)$(DOWNEXT)
-endef
diff --git a/bsps/powerpc/haleakala/include/bsp.h 
b/bsps/powerpc/haleakala/include/bsp.h
deleted file mode 100644
index 71ea09b..000
--- a/bsps/powerpc/haleakala/include/bsp.h
+++ /dev/null
@@ -1,107 +0,0 @@
-/**
- * @file
- *
- * @ingroup RTEMSBSPsPowerPCHaleakala
- *
- * @brief Global BSP definitions.
- */
-
-/*  bsp.h
- *
- *  Gen

Re: Ticket 4503

[Joel Sherrill]

Zack, did you ever make any progress on this?

I'm just looking at tickets and wondered.

On Sat, Dec 11, 2021 at 9:41 AM Gedare Bloom  wrote:
>
> On Thu, Nov 18, 2021 at 7:22 PM zack leung  wrote:
> >
> > bump
> >
> > On Mon, 18 Oct 2021 at 23:58, zack leung  wrote:
> >
> > > bump
> > >
> > >
> > > On Sat, 25 Sept 2021 at 00:26, zack leung 
> > > wrote:
> > >
> > >> bump
> > >>
> > >> On Thu, 9 Sept 2021 at 02:17, zack leung 
> > >> wrote:
> > >>
> > >>> >Thanks! I guess i'm really unsure about how the pointer relates to the
> > >>> amount of memory that you can use. I assume the Malloc keeps track of 
> > >>> the
> > >>> sections being used in the heap. Does this function Allocate 2 blocks 
> > >>> since
> > >>> the pointer is set to
> > >>>
> > >>> (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
> > >>>
>
> No, this is calculating the size of 'this block' considering that it's
> allocated memory starts at "alloc_begin" and it ends at the
> "next_block" heap block metadata or header. You should read about how
> malloc implementations generally work. The allocated memory has some
> metadata before it to implement the linked data structures necessary
> to support dynamic allocation. So a block is the header + allocated
> range. Only the allocated range plus any excess before the next
> block's header is considered usable.
>
> > >>> >(I know it's a bit naive to assume this given my first question)
> > >>>
> > >>> think the method is _Heap_Size_of_alloc_area. It may need a wrapper
> > >>> added to the protected heap wrapper for safety. I don't know if it has 
> > >>> one.
> > >>> It should be the equivalent functionality.
> > >>> > How would i implement a wrapper and what safety measures need to be
> > >>> implemented. So far it's checking if :  the block is not in the heap 
> > >>> and if
> > >>> it's been previously used. Is the usable memory in the heap calculated 
> > >>> by:
> > >>> the size of the block * # of blocks?
> > >>>
>
> You would have to see if the Protected Heap implementation has some
> additional metadata between the end of an allocated range in one block
> and the block header in the next. I don't think it matters too much
> because most of the 'protected' aspects have to do with free block
> management. But that should be confirmed.
>
> The check is not "if it's been previously used" I suggest that you
> look at what the invoked function does and how it is documented. Avoid
> making assumptions based on names.
>
> The usable memory is NOT the size of the block * # of blocks, because
> the size of the block includes the header.
>
> > >>> Thanks, Zack
> > >>>
> > >>> -- Forwarded message -
> > >>> From: Joel Sherrill 
> > >>> Date: Wed, 8 Sept 2021 at 20:30
> > >>> Subject: Re: Ticket 4503
> > >>> To: Gedare Bloom 
> > >>> Cc: zack leung , rtems-de...@rtems.org <
> > >>> devel@rtems.org>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom  wrote:
> > >>>
> >  Hi Zack,
> > 
> >  https://devel.rtems.org/ticket/4503
> > 
> >  The malloc implementation exists in the score as the Heap Manager.
> >  search for "Heap_" within cpukit to get some ideas where to look.
> > 
> > >>>
> > >>> I think the method is _Heap_Size_of_alloc_area. It may need a wrapper
> > >>> added to the protected heap wrapper for safety. I don't know if it has 
> > >>> one.
> > >>> It should be the equivalent functionality.
> > >>>
> > >>> newlib's malloc.h will need looking at to make sure we provide the right
> > >>> methods.
> > >>>
> > >>>
> > >>>
> > 
> >  @Joel are these two tickets duplicates?
> >  https://devel.rtems.org/ticket/4503
> >  https://devel.rtems.org/ticket/4271
> > 
> > >>>
> > >>> Yes. Closed #4271 and merged comments.
> > >>>
> > >>> --joel
> > >>>
> > >>>
> > 
> > 
> >  -Gedare
> > 
> >  On Tue, Sep 7, 2021 at 7:14 PM zack leung 
> >  wrote:
> > 
> > > I was wondering about ticket 4503. I was wondering where The required
> > > functionality should be in the underlying score/ capability used can 
> > > be
> > > found to write this function. Also how does this relate  to
> > >
> > > Add common malloc family extension method malloc_usable_size()
> > > ?
> > > Thanks
> > > Zack
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> > 
> > 
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-docs] Update package list for Ubuntu

[Ryan Long]

Updated the latest version referenced of Ubuntu to 21.04, updated
package list, and identified what packages need to still be installed
afterwards to pass sb-check.

Closes #4110
---
 user/hosts/posix.rst | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index 818eb25..6fbf401 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -137,23 +137,23 @@ prefix under your home directory as recommended and end 
up on the SD card.
 Ubuntu
 ~~
 
-The latest version is Ubuntu 18.04.1 LTS 64-bit. This section also includes
+The latest version is Ubuntu 21.04.1 LTS 64-bit. This section also includes
 Xubuntu. A minimal installation was used and the following packages installed:
 
 .. code-block:: none
 
-  $ sudo apt-get build-dep build-essential gcc-defaults g++ gdb git \
-  unzip pax bison flex texinfo unzip python3-dev libpython-dev \
-  libncurses5-dev zlib1g-dev
+  $ sudo apt-get build-dep build-essential gcc-defaults g++ gdb unzip \
+  pax bison flex texinfo python3-dev libpython2-dev libncurses5-dev \
+  zlib1g-dev
 
-Note that in previous versions of Ubuntu, the package libpython-dev was
+Note that in previous versions of Ubuntu, the package libpython2-dev was
 python2.7-dev. The name of packages changes over time. You need the
 package with Python development libraries for C/C++ programs. The following
 is needed for recent versions:
 
 .. code-block:: none
 
-  $ sudo apt-get install python-dev
+  $ sudo apt-get install python git
 
 It is likely necessary that you will have to enable the Ubuntu Source
 Repositories.  Users have suggested the following web pages which have
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] Update package list for Ubuntu

[Karel Gardas]

On 12/17/21 10:35 PM, Ryan Long wrote:
> diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
> index 818eb25..6fbf401 100644
> --- a/user/hosts/posix.rst
> +++ b/user/hosts/posix.rst
> @@ -137,23 +137,23 @@ prefix under your home directory as recommended and end 
> up on the SD card.
>  Ubuntu
>  ~~
>  
> -The latest version is Ubuntu 18.04.1 LTS 64-bit. This section also includes
> +The latest version is Ubuntu 21.04.1 LTS 64-bit. This section also includes

This is certainly not correct. Either you mean 20.04.03 LTS or you mean
regular Ubuntu which is 21.10 of this time (and no "LTS" attached!).

Simply your version "21.04.1 LTS" is non existent in this galaxy...

Cheers,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] Update package list for Ubuntu

[Ryan Long]

Ah, I thought they only put the .04 on the LTS releases. I'll change 
that and send in V2.


On 12/17/2021 3:49 PM, Karel Gardas wrote:

On 12/17/21 10:35 PM, Ryan Long wrote:

diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index 818eb25..6fbf401 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -137,23 +137,23 @@ prefix under your home directory as recommended and end 
up on the SD card.
  Ubuntu
  ~~
  
-The latest version is Ubuntu 18.04.1 LTS 64-bit. This section also includes

+The latest version is Ubuntu 21.04.1 LTS 64-bit. This section also includes

This is certainly not correct. Either you mean 20.04.03 LTS or you mean
regular Ubuntu which is 21.10 of this time (and no "LTS" attached!).

Simply your version "21.04.1 LTS" is non existent in this galaxy...

Cheers,
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] Update package list for Ubuntu

[Karel Gardas]

On 12/17/21 10:49 PM, Karel Gardas wrote:
> On 12/17/21 10:35 PM, Ryan Long wrote:
>> diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
>> index 818eb25..6fbf401 100644
>> --- a/user/hosts/posix.rst
>> +++ b/user/hosts/posix.rst
>> @@ -137,23 +137,23 @@ prefix under your home directory as recommended and 
>> end up on the SD card.
>>  Ubuntu
>>  ~~
>>  
>> -The latest version is Ubuntu 18.04.1 LTS 64-bit. This section also includes
>> +The latest version is Ubuntu 21.04.1 LTS 64-bit. This section also includes
> 
> This is certainly not correct. Either you mean 20.04.03 LTS or you mean

Sorry typo, zero should not be in 03. Here is what I run:

$ cat /etc/os-release |grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04.3 LTS"

and is canonical name of the distro...

Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] Update package list for Ubuntu

[Karel Gardas]

On 12/17/21 10:52 PM, Ryan Long wrote:
> Ah, I thought they only put the .04 on the LTS releases. I'll change
> that and send in V2.

No LTS line is 12.04, 14.04, 16.04, 18.04, 20.04 and next future is
22.04. Always released in April of the year (hence .04) and the number
before it is obviously year number.

Basically since LTS does not change that much or should not besides
security fixes and perhaps hardware support, then you can freely use
"Ubuntu 20.04.x LTS" since I guess RTEMS will not find difference
between .1, .2, .3 spins of 20.04.

Thanks,
Karel

> 
> On 12/17/2021 3:49 PM, Karel Gardas wrote:
>> On 12/17/21 10:35 PM, Ryan Long wrote:
>>> diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
>>> index 818eb25..6fbf401 100644
>>> --- a/user/hosts/posix.rst
>>> +++ b/user/hosts/posix.rst
>>> @@ -137,23 +137,23 @@ prefix under your home directory as recommended
>>> and end up on the SD card.
>>>   Ubuntu
>>>   ~~
>>>   -The latest version is Ubuntu 18.04.1 LTS 64-bit. This section also
>>> includes
>>> +The latest version is Ubuntu 21.04.1 LTS 64-bit. This section also
>>> includes
>> This is certainly not correct. Either you mean 20.04.03 LTS or you mean
>> regular Ubuntu which is 21.10 of this time (and no "LTS" attached!).
>>
>> Simply your version "21.04.1 LTS" is non existent in this galaxy...
>>
>> Cheers,
>> Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems.org downtime this weekend

[Joel Sherrill]

Hi

Amar is planning on doing some upgrades over the weekend and various
rtems.org services will be up and down as he works.

We will let you know when it is done.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel